My friend and associate Aaron writes:
Hey I was wondering if you had any experience with the SmoothWall firewall? Seems that a lot of techie people like it and it’s open source, and it’s GUI.
Its all IPTABLES to me Aaron.
But no, I hadn’t heard of SmoothWall, thanks for the pointer.
There are lots of different scripts (Bastille, Linux Firewall IPcop, etc.) to set them up, but what I always wonder is why does an end user need to configure a firewall?
In other words, the scripts automate starting and stopping IPTABLES and manipulating the chains. But who needs the warm friendly automation? I know IPTABLES is in the background, and I know how to manipulate and save chains from the CLI.
I am always interested to see what different scripts do. At the home office here, I am currently using Trustix Firewall 4.7. This is the software part of a very sweet looking hardware platform, XSentry.
Which has a warm fuzzy Java GUI that runs on Windows. I am very interested to see their way to setup the NAT. I always use mangling, and sometimes if I am in a hurry, MASQ; but they are actually allowing these packets across the FORWARD chain on a selective basis.
I was very interested to see that they use a new module that I have just read about too, the recent module. I provided a link to the author’s pages, but this module is included in the netfilter or iptables package now. If you want to see how the Trustix firewall uses that target you should get your own copy, but I will provide an example of the recent use that I am thinking about using.
I have servers on the network that are more or less my own private servers, and as such, they are locked down pretty well against most casual use, specifically, I only allows ssh connections from certain locations. I used to see not infrequent dictionary attacks and other repeated (unsuccessful) attempts to access the servers from unauthorized locations. So I had blocked all but the few addresses that I would ordinarily use to access the servers.
Unfortunately, this means when I travel or am out of my own office, its very problematic to access the servers. The RECENT target will actually allow me to allow a single attempt to log on every x minutes. If x is even one minute, a dictionary attack is severely hampered. On the other hand, if I am unsuccessful in logging in, I am not locked out for an unreasonable amount of time even if x is say 5 minutes. (A second unsuccessful attempt would be pretty frustrating then…)
Here’s the way I think that would look on the CLI:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT ... iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 -j LOGDROP iptables -A INPUT -p tcp --dport 22 -m recent --set -j ACCEPT
It turns out that even a successful connection attempt blocks further access for the interval specified. I will have to deal with that unpleasantness before I put this anywhere in production.