As every packets of data needs to be serviced by the WAN port, it could fall victim to a simple Dos. Here are a few kernel parameters that might help against this. There are other settings that could be done depending on the environment you find yourself. These could be parametised by means of a configuration control and introduced to the system at any time (after bootup). # drop tcp reply on closed ports /sbin/sysctl net.inet.tcp.blackhole=2 # drop udp packets on closed port /sbin/sysctl net.inet.udp.blackhole=1 # max number of icmp per second /sbin/sysctl net.inet.icmp.icmplim=100 # max number of open sockets /sbin/sysctl kern.ipc.somaxconn=2048
From the m0n0wall days, the WAN was an open DNS server so I had to create a custom rule to block all Port 53 request on the WAN side.
Wait, really? I am not seeing this on any of the firewalls I have in production.
Yeah, well at least for m0n0wall, I noticed one day that my firewall states page had the usual long list of DNS 53 connections, but noticed that some of them were sourced from the Internet (instead of my local network) and relaying on port 53. I checked my firewall rules and the only rule it had enabled was the one to "Block private networks" and no other rule existed to allow any inbound access from the Internet. I later found out that "DNS forwarder" was the cause of this. It acts as a relay for the local network machines but also appears to make a hole in the firewall. I got my laptop, went out and connected to another ISP and set it to use the WAN address of my m0n0wall machine as the DNS lookup. To my surprise, the laptop was getting successful lookups using nslookup and my IP was showing up on the firewall states (via the Internet) I couldn't figure how to fix it (other than disable the DNS forwarder which I liked using), so on a lark I created a WAN rule to block all DNS.
Block TCP/UDP * * WAN address 53 (DNS)
That solved my issue, granted that was many years ago and I just by instinct made sure to have that rule on any future m0n0wall machines I built for myself or customers. I haven't tried turning it off and doing the same experiment on SmallWall yet to see if that is an issue anymore or not. When I get some time, I can give it a try.
I just did some nmaps scans of other firewalls and there was nothing on 53.
I can confirm for SmallWall, using the same config file from a m0n0wall machine, disabled the rule to block 53 and SmallWall still has the service blocked from the WAN side without needing an additional rule. That's cool, one more firewall rule I can remove now.