Slashdot Mirror
Why iptables (Linux 2.4 Firewalling) Rocks
Jay writes: "There's a story on Linux 2.4's new Stateful firewalling.
Rusty and friends have vastly improved Linux capabilities, allowing it
to filter against many stealth scans and DoS attacks. Their code rewrite brings powerful "stateful" firewalling that was originally impossible under Linux. The muchly improved packet mangling allows
not only better transparent proxies, but load-sharing clusters and stuff. Actually, the coolest thing about the new architecture is that it's designed so anybody can add filtering methods, for stuff like rate limiting and MAC address-based filtering."
Inserting a proxy when the client doesn't have knowledge isn't something to be proud of; it breaks browsers, violates the end-to-end principle at the IP layer, and brings some serious privacy/data integrity problems to light.
This just requires that the person inside your building be a little smarter. MAC addresses can be changed, so all that is required is to wait until a trusted box goes offline, and then just borrow its MAC address.
Of course, this eliminates a good portion of those who would try to hack in. Just don't rely on it to be fool-proof.
I was always tempted to use a laptop running Linux to spoof one of the main campus Unix systems at Dartmouth when it went down for backups, but never did. (I think they had some public systems on the same subnet as the machine room.)
As it stands now (or previously... in ipchains), rules were defined in a way that could be reduced to a regular expression, which as everyone knows are fast and don't require a stack to interpret.
However, as soon as you introduce "state" into a grammar, you require of yourself a stack, which means that additional memory is going to be needed to store these values to aid in parsing the grammar.
This doesn't sound too bad, even though it may slow the process of packet interpretation, but it seems like there still would be a signifigant performance hit on busy servers.
Also, since these rules have state, I wonder if there will be ways send packets that will cause something similar to a stack overflow (infinite recursion) by sending it a quasi-infite series of packets.
(Imaging sending a C++ compiler the following ..
[I can't send what I want, a string of open parens, so this will have to suffice. /. lameness filter]
String= (*
Eventually there will be a stack overflow from all the parens.
I think I can sum up the one and only advantage (if you can call it that) that iptables has over ipf (aka ipfilter) in one short sentence...
You can run iptables in Linux.
Linux has its uses, don't get me wrong, but I'll take an OpenBSD firewall over any Linux firewall, regardless of which distro, or firewalling software it runs. The TCP stack in the BSDs is much more robust than the Linux stack, and its just plain faster.
Don't belive me? That's fine, but don't go flaming me unless you have actually used both Linux and *BSD firewalls extensively.
9 little greeblys sitting on a plate...
Do not meddle in the affairs of dragons, for you are crunchy, and taste good with ketchup.
I needed to block a list of thousands of ip addresses at the firewall. Here's how I did it:
First, I read the sample code for how to implement user-space queueing. That's where you pass a packet to a user-space program so it can decide what to do with it. Then I made some trivial changes to that program so that it looks for a file in a certain directory with a name equal to the IP address in the packet header.
If the file exists (i.e. an open() call succeeds), then the packet is denied; otherwise it is allowed. Anytime I want to add a new IP address to the blocking list, I just create a file in that directory. Since I run reiserfs, the test for file existence is as efficient as a hashtable lookup, but much simpler to code.
Not as sophisticated as a commercial firewall program, but not as much overhead, either. (Simplistic) benchmarks show no significant increase in network latency. Works for me!
The Web is like Usenet, but
the elephants are untrained.
Try out Firestarter (Disclaimer: I wrote the program, so I'm biased). Supports both ipchains and netfilter, several nics, NAT/Masq, ToS/ICMP filtering etc.
I, just like you, got really tired of editing scripts all day long, the end result is this GNOME program. First the program presents a wizard for quickly setting up a firewall, then you can monitor the firewall hits you get and close/open/stealth ports with just a few clicks. Easy of use was the goal with this program.
I was eagerly waiting for Linux 2.4 from the day I heard somewhere it would support ipfilter. I run mostly BSD boxes, due to personal preference, while still keeping a few Linux systems up and running. All systems run perfectly well and cause me little grief, if any at all.
However, once again the Linux camp is "doing things their own way" and contributing even more to the separation between different Unix flavors (as well as making those sigs that go something like "Linux - the Unix defragmentation tool" even funnier). Don't get me wrong, iptables seems to have a few cool features that are not present in ipfilter, but just why was ipfilter not used instead ? It is present in a few platforms already (runs on all BSD's, as well as Solaris / SunOS and IRIX), it is tried and tested, and it does most of the stuff iptables does. And it can probably be extended to do everything iptables does as well, with some extra work. But the Linux folks, however talented and bright they undoubtedly are, and however good a kernel they have produced, have just taken a completely silly route this time. Not only have they duplicated effort towards the same (or at least, a very similar) end, they have also created another headache for busy sysadmins who maintain a few different systems. I had high hopes on ipfilter being "officially" supported under Linux (the ipfilter code mentions sketchy support for Linux, which I have admittedly not tested, but from the looks of it it has not been maintained for a long time --- the most recent kernel mentioned in the HISTORY file is 2.0.34, the last reference to Linux appears in 1998), but now I will be forced to get rid of the only Linux box I still maintain as a server (for various reasons, none of which related to the quality of the OS --- that little box has run great for ages, and causes me no grief at all) if I ever need firewalling for it. Yes, I could learn to work with iptables (and I probably will anyway, out of curiosity), but the Linux folks could probably learn to cooperate better with the rest of the world in certain aspects. It really is a shame, because I honestly think Linux is great --- the mindset of some of it's users (and by the looks of it, some developers as well) is however a different matter...
For those of you not familiar with stateful firewalling, it is an incredibly good thing. I've gone from using ipfwadm to using ipchains to finally using ipfilter on BSD. Because of ipf's support of stateful filtering, my firewall rulesets were *much* simpler. Given that many (most?) problems associated with firewalls is the complexity of the configuration, this is a Very Good Thing(tm). After migrating from linux/ipchains to BSD/ipf, I was able to add serious protection for my network, including my high ports (which often run the most vulnerable services, namely RPC services). I haven't used netfilter/iptables, but it looks to be a *huge* step forward for Linux.
All that being said, I have a major problem with this article. It seems to suggest to users that FTP monitoring to handle active FTP clients is a good idea. In fact, this is a *terrible* idea. I got to watch Dug Song et al at BlackHat walk right through a CheckPoint FW1 system like it wasn't even there by exploiting some assumptions that FW1 made when monitoring FTP for the PORT commands. It sounds to me like the netfilter/iptables support for FTP functions in a very similar manner as FW1. If you must support FTP through your firewall, make your users use passive FTP. Every modern FTP client and every modern FTP server that I've seen all support passive FTP. Of course, a better approach is to encourage secure communications, like scp or SSL.
Bottom line, the best firewall design is the simplest one possible that gets the job done. Adding neato features like payload monitoring to poke extra holes in the firewall is diametrically opposite this philosophy.
Also, please remember that a firewall only serves as a method of blocking traffic between network segments. It does not magically secure network traffic from viewing, spoofing, manipulating, or hijacking (you need to use protocols that support strong authentication and strong cryptography to achieve this). It does not secure the applications or systems which you allow traffic to touch (you need to use secure OSes under secure configurations to accomplish this). It does not magically protect your systems against insider threats (you need to have good people working for you, restrictions on outside connectivity, and thorough physical security to accomplish this). Remember, crunchy on the outside and soft and gooey on the inside is great for candy, bad for networks.