What's new

Discussion on improving the firewall

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

HELLO_wORLD

Very Senior Member
Hello to all.

In a constant quest to improve security of the firewall, I recently added some rules to deal with port scan.
The idea of this thread is to share our experiences and experimentation to make our firewalls better.
It is open to comments, critics, improvements, etc...

Here is my iptables mangle table. Some rules are put there by the firmware, other (bolemo_xxx) are mine.
The way it works is as follow: it creates two recent lists bad_bl and scan_bl
When a new connection attempt is made from WAN to specific UDP and TCP ports I don’t use, it bans the IP for 30 seconds (bad_bl) for any connection. The logic is if you attempt a connection to these ports, there is not reason for it, therefore I assume you have bad intentions.
When a new TCP or UDP connection is made more than 10 times on the last 30 seconds, it bans the IP for 30 seconds (scan_bl) for any new connection, however, if a connection is established or related with the same IP, it is instantly unbanned (as http for example can have more than 10 new requests incoming in 30 seconds).

The result is satisfying so far. ShieldsUp scan does not detect any open port (all stealth), including open ones like 80 or 443.
However, from WAN, I can reach for example my http(s) services without being blocked.

The flaw I can see in this is if a port scanner is not incremental and establishes a connection on port 80 for example, it will not be in the banned scan list.

However, this can allow to build a list of port scanners active toward my ip, and therefore regularly add them in an aegis blocklist for example.

Code:
-A PREROUTING -d 192.168.0.0/24 -i brwan -j DROP
-A PREROUTING -i brwan -j bolemo_ddos
-A INPUT -i brwan -p tcp -m tcp --tcp-flags URG URG -j DROP
-A OUTPUT -o brwan -p icmp -m icmp --icmp-type 3 -j DROP
-A bolemo_ddos -m conntrack --ctstate INVALID -j DROP
-A bolemo_ddos -m recent --update --seconds 30 --name bad_bl --rsource -j DROP
-A bolemo_ddos -p tcp -j bolemo_tcp
-A bolemo_ddos -p udp -j bolemo_udp
-A bolemo_ddos -p icmp -m icmp --icmp-type 8 -m limit --limit 20/sec -j RETURN
-A bolemo_ddos -p icmp -m icmp --icmp-type 8 -j DROP
-A bolemo_pscan -m state --state RELATED,ESTABLISHED -m recent --remove --name scan_bl --rsource -j RETURN
-A bolemo_pscan -m state --state NEW -m recent --update --seconds 30 --reap --hitcount 10 --name scan_bl --rsource -j DROP
-A bolemo_pscan -m recent --set --name scan_bl --rsource -j RETURN
-A bolemo_tcp -p tcp -m multiport --dports 20:23,79,88,119,139,445,5000 -m state --state NEW -m recent --set --name bad_bl --rsource -j DROP
-A bolemo_tcp -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j DROP
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 10000/sec --limit-burst 100 -j RETURN
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A bolemo_tcp -j bolemo_pscan
-A bolemo_udp -p udp -m multiport --dports 79,88,137,138,445,1900 -m state --state NEW -m recent --set --name bad_bl --rsource -j DROP
-A bolemo_udp -j bolemo_pscan
 
FYI. ShieldsUP (and perhaps most other similar utilities) only scans TCP, not UDP. I know it mentions it in the "fineprint", but I've had more than a few ppl not notice or bother reading. So don't assume total stealthiness based solely on its results.
 
FYI. ShieldsUP (and perhaps most other similar utilities) only scans TCP, not UDP. I know it mentions it in the "fineprint", but I've had more than a few ppl not notice or bother reading. So don't assume total stealthiness based solely on its results.
Yes, I noticed, and I made the rules for TCP and UDP.
Hackers are probably using smarter scanners than ShieldsUP too, not going incrementally, using different IPs, etc... So these rules are working for basic port scan, but smart aggressive port scan operated with some ressources cannot be avoided, unless having heavy time/cpu consuming detection, en even then... not worth for our routers.
Anyone needing high end complex protection probably already have invested in high end routers and firewalls.

The idea is to bring as much protection as possible without impacting much performance and requiring engineer skills for users.
 
Hello to all.

In a constant quest to improve security of the firewall, I recently added some rules to deal with port scan.
The idea of this thread is to share our experiences and experimentation to make our firewalls better.
It is open to comments, critics, improvements, etc...

Here is my iptables mangle table. Some rules are put there by the firmware, other (bolemo_xxx) are mine.
The way it works is as follow: it creates two recent lists bad_bl and scan_bl
When a new connection attempt is made from WAN to specific UDP and TCP ports I don’t use, it bans the IP for 30 seconds (bad_bl) for any connection. The logic is if you attempt a connection to these ports, there is not reason for it, therefore I assume you have bad intentions.
When a new TCP or UDP connection is made more than 10 times on the last 30 seconds, it bans the IP for 30 seconds (scan_bl) for any new connection, however, if a connection is established or related with the same IP, it is instantly unbanned (as http for example can have more than 10 new requests incoming in 30 seconds).

The result is satisfying so far. ShieldsUp scan does not detect any open port (all stealth), including open ones like 80 or 443.
However, from WAN, I can reach for example my http(s) services without being blocked.

The flaw I can see in this is if a port scanner is not incremental and establishes a connection on port 80 for example, it will not be in the banned scan list.

However, this can allow to build a list of port scanners active toward my ip, and therefore regularly add them in an aegis blocklist for example.

Code:
-A PREROUTING -d 192.168.0.0/24 -i brwan -j DROP
-A PREROUTING -i brwan -j bolemo_ddos
-A INPUT -i brwan -p tcp -m tcp --tcp-flags URG URG -j DROP
-A OUTPUT -o brwan -p icmp -m icmp --icmp-type 3 -j DROP
-A bolemo_ddos -m conntrack --ctstate INVALID -j DROP
-A bolemo_ddos -m recent --update --seconds 30 --name bad_bl --rsource -j DROP
-A bolemo_ddos -p tcp -j bolemo_tcp
-A bolemo_ddos -p udp -j bolemo_udp
-A bolemo_ddos -p icmp -m icmp --icmp-type 8 -m limit --limit 20/sec -j RETURN
-A bolemo_ddos -p icmp -m icmp --icmp-type 8 -j DROP
-A bolemo_pscan -m state --state RELATED,ESTABLISHED -m recent --remove --name scan_bl --rsource -j RETURN
-A bolemo_pscan -m state --state NEW -m recent --update --seconds 30 --reap --hitcount 10 --name scan_bl --rsource -j DROP
-A bolemo_pscan -m recent --set --name scan_bl --rsource -j RETURN
-A bolemo_tcp -p tcp -m multiport --dports 20:23,79,88,119,139,445,5000 -m state --state NEW -m recent --set --name bad_bl --rsource -j DROP
-A bolemo_tcp -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j DROP
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 10000/sec --limit-burst 100 -j RETURN
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A bolemo_tcp -j bolemo_pscan
-A bolemo_udp -p udp -m multiport --dports 79,88,137,138,445,1900 -m state --state NEW -m recent --set --name bad_bl --rsource -j DROP
-A bolemo_udp -j bolemo_pscan
I like your idea but I still think that the best approach for this is to use Single Packet Authorization (SPA).
A basic outline for using fwknop to conceal an SSH daemon with Single Packet Authorization (SPA) involves the following steps. This assumes an SPA client system (hostname: spaclient), and an SPA server system spaserver.domain.com where fwknopd is installed and the SSH daemon listens:
  1. Generate encryption and HMAC keys with fwknop --key-gen.
  2. Transfer the keys you just generated fwknopd to the server (this is where SSHD is listening too).
  3. Start fwknopd and deploy a default-drop firewall policy against all inbound SSH connections.
  4. From anywhere on the Internet, use the fwknop client to send an SPA packets and have fwknopd open the firewall.
  5. Use your SSH client as usual now that you have access. No one else can even see that SSHD is listening.
 
Last edited:
I like your idea but I still think that the best approach for this is to use Single Packet Authorization (SPA).
A basic outline for using fwknop to conceal an SSH daemon with Single Packet Authorization (SPA) involves the following steps. This assumes an SPA client system (hostname: spaclient), and an SPA server system spaserver.domain.com where fwknopd is installed and the SSH daemon listens:
  1. Generate encryption and HMAC keys with fwknop --key-gen.
  2. Transfer the keys you just generated fwknopd to the server (this is where SSHD is listening too).
  3. Start fwknopd and deploy a default-drop firewall policy against all inbound SSH connections.
  4. From anywhere on the Internet, use the fwknop client to send an SPA packets and have fwknopd open the firewall.
  5. Use your SSH client as usual now that you have access. No one else can even see that SSHD is listening.
That is very clever if you need private services accessible from outside.
I personally don’t have SSH open on WAN.
However, I have some services (web, mail...) that need to be open, but mainly for my own need from outside, so for these, I could use a SPA.

Thank you, I will definitely look into this. :)
 
However, this can allow to build a list of port scanners active toward my ip, and therefore regularly add them in an aegis blocklist for example.

Sounds like a never-ending task - and this defeats the reason for the firewall in the first place...

Look at whitelists instead...
 
Hello to all.

In a constant quest to improve security of the firewall, I recently added some rules to deal with port scan.
The idea of this thread is to share our experiences and experimentation to make our firewalls better.
It is open to comments, critics, improvements, etc...

Here is my iptables mangle table. Some rules are put there by the firmware, other (bolemo_xxx) are mine.
The way it works is as follow: it creates two recent lists bad_bl and scan_bl
When a new connection attempt is made from WAN to specific UDP and TCP ports I don’t use, it bans the IP for 30 seconds (bad_bl) for any connection. The logic is if you attempt a connection to these ports, there is not reason for it, therefore I assume you have bad intentions.
When a new TCP or UDP connection is made more than 10 times on the last 30 seconds, it bans the IP for 30 seconds (scan_bl) for any new connection, however, if a connection is established or related with the same IP, it is instantly unbanned (as http for example can have more than 10 new requests incoming in 30 seconds).

The result is satisfying so far. ShieldsUp scan does not detect any open port (all stealth), including open ones like 80 or 443.
However, from WAN, I can reach for example my http(s) services without being blocked.

The flaw I can see in this is if a port scanner is not incremental and establishes a connection on port 80 for example, it will not be in the banned scan list.

However, this can allow to build a list of port scanners active toward my ip, and therefore regularly add them in an aegis blocklist for example.

Code:
-A PREROUTING -d 192.168.0.0/24 -i brwan -j DROP
-A PREROUTING -i brwan -j bolemo_ddos
-A INPUT -i brwan -p tcp -m tcp --tcp-flags URG URG -j DROP
-A OUTPUT -o brwan -p icmp -m icmp --icmp-type 3 -j DROP
-A bolemo_ddos -m conntrack --ctstate INVALID -j DROP
-A bolemo_ddos -m recent --update --seconds 30 --name bad_bl --rsource -j DROP
-A bolemo_ddos -p tcp -j bolemo_tcp
-A bolemo_ddos -p udp -j bolemo_udp
-A bolemo_ddos -p icmp -m icmp --icmp-type 8 -m limit --limit 20/sec -j RETURN
-A bolemo_ddos -p icmp -m icmp --icmp-type 8 -j DROP
-A bolemo_pscan -m state --state RELATED,ESTABLISHED -m recent --remove --name scan_bl --rsource -j RETURN
-A bolemo_pscan -m state --state NEW -m recent --update --seconds 30 --reap --hitcount 10 --name scan_bl --rsource -j DROP
-A bolemo_pscan -m recent --set --name scan_bl --rsource -j RETURN
-A bolemo_tcp -p tcp -m multiport --dports 20:23,79,88,119,139,445,5000 -m state --state NEW -m recent --set --name bad_bl --rsource -j DROP
-A bolemo_tcp -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j DROP
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 10000/sec --limit-burst 100 -j RETURN
-A bolemo_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A bolemo_tcp -j bolemo_pscan
-A bolemo_udp -p udp -m multiport --dports 79,88,137,138,445,1900 -m state --state NEW -m recent --set --name bad_bl --rsource -j DROP
-A bolemo_udp -j bolemo_pscan
Hi hos do i setup the firewall? Do I write the code in console via telnet or ssh?

hannez
 
Hi hos do i setup the firewall? Do I write the code in console via telnet or ssh?

hannez
The lines I posted in this thread are custom iptables rules I am using.
They are not related with aegis (which does use iptables but for another type of protection, and is a lot more user friendly and automated).

If you don’t know iptables, you probably should not go further for now as using these rules requires some knowledge of iptables, and they are experimental and to share/discuss with other users here concerned also by security and how we can improve it.
These rules probably would need to be adapted a little for each user to comply the specifics of their systems (LAN layout, services open or not, etc...)
 
hi
I have some issues with dos attacks here are som logs from the voxel/netgear gui.
[DoS Attack: ACK Scan] from source: 34.242.85.100, port 443, Thursday, March 18, 2021 21:43:14
[DoS Attack: RST Scan] from source: 1.0.0.1, port 443, Thursday, March 18, 2021 21:42:56
[DoS Attack: ACK Scan] from source: 34.242.85.100, port 443, Thursday, March 18, 2021 21:42:56
[DoS Attack: ACK Scan] from source: 1.0.0.1, port 443, Thursday, March 18, 2021 21:42:53
[DoS Attack: ACK Scan] from source: 34.242.85.100, port 443, Thursday, March 18, 2021 21:42:47
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:33:46
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:31:43
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:30:40
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:30:09
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:29:53
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:29:45
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 20:14:08

Do u have some recomendations on how to mitigate the attacks? Is there some rules in iptables that i can use?

Best regards Hannez
 
hi
I have another question regarding ping response. I have disabled ping response in routers gui but shieldsup indicates a ping response is there a way to fix this?
 
@hannez0101
Most of these reported DOS attacks are on port 443 (https), do you have a web server?

NETGEAR DOS attacks reporting is not very accurate and can also be false positives.
One solution is install aegis and add the IP addresses that you want to block if you don’t trust them, like this 157.240.200.34 you have. It will still appear in the NG DOS attack, but will be blocked.
If you don’t have a web server, it is not very important, but you can block to be sure.

For the ping, if you disabled it in the router’s preferences, it should be blocked. Strange that it is still pingable.

What are your current iptables rules ? Filet, nat and mangle.
 
Hi what command do I use for filter nat and mangnle output? I have another question regarding wlan. I have disabled the wlan modules in the GUI but still my said shows up in kismet. Is there any commands I can use to permanently disable the 2 wlan modules?

best Regards Johannes
 
hi
I have some issues with dos attacks here are som logs from the voxel/netgear gui.
[DoS Attack: ACK Scan] from source: 34.242.85.100, port 443, Thursday, March 18, 2021 21:43:14
[DoS Attack: RST Scan] from source: 1.0.0.1, port 443, Thursday, March 18, 2021 21:42:56
[DoS Attack: ACK Scan] from source: 34.242.85.100, port 443, Thursday, March 18, 2021 21:42:56
[DoS Attack: ACK Scan] from source: 1.0.0.1, port 443, Thursday, March 18, 2021 21:42:53
[DoS Attack: ACK Scan] from source: 34.242.85.100, port 443, Thursday, March 18, 2021 21:42:47
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:33:46
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:31:43
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:30:40
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:30:09
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:29:53
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 21:29:45
[DoS Attack: ACK Scan] from source: 157.240.200.34, port 443, Thursday, March 18, 2021 20:14:08

Do u have some recomendations on how to mitigate the attacks? Is there some rules in iptables that i can use?

Best regards Hannez
Never trust the Netgear logs, its mostly false positives and misleading. for example your mysterious dos attack is Facebook https://www.abuseipdb.com/check/157.240.200.34
 
Hi what command do I use for filter nat and mangnle output? I have another question regarding wlan. I have disabled the wlan modules in the GUI but still my said shows up in kismet. Is there any commands I can use to permanently disable the 2 wlan modules?

best Regards Johannes
Here you go:
Code:
iptables -t mangle -S
iptables -t filter -S
iptables -t nat -S
Because iptables reports a warning, it might not be a complete list, so you can also use these commands to study your tables,
Code:
iptables -t mangle -L
iptables -t filter -L
iptables -t nat -L
Also, note that the filter table is the default one, so just using
iptables -S or iptables -L (without a -t argument) is similar to using -t filter.

For the wlan modules, I believe you can disable them. Don’t know the command, but you could likely find it searching in this forum, asking in a new thread if it is not already there.
I would also have a look at the @kamoj Addon that gives you easy access to numerous settings and options directly from the router’s web page.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top