Not too long ago, Arch Linux released an update on their distribution, stating that they are removing support for tcp_wrappers. For the most part, this doesn’t seem to be a big deal. They aren’t a world-renown distribution like Ubuntu or Red Hat, so its unlikely that unless its a kernel-based decision, the world is going to break and shatter. However, this does raise an interesting point in terms of security…just how secure is tcp_wrappers?
I’ll be the first one to admit that tcp_wrappers makes firewall management the funnest thing since slicing one’s own bread. But, if what the post says is true, and an update hasn’t been made since 1997, is kernel 0.x (if lucky 1.x) security measures still viable today? If you think about it, the format for /etc/hosts.allow and hosts.deny is pretty simplistic. If you want to allow everyone access on one port, just do <port name or number>: ALL. By default, /etc/hosts.deny usually has ALL:ALL to block all other connections not specified in hosts.allow. Like I said, pretty darn simplistic. Of course, there’s these rare times where you’ll have to do more than just that, but, alas its a different story.
In comes iptables. a front-end of sorts to netfilter, and has been highly popular in the Linux security realm. Its also pretty robust, as well. iptables can be thought of the son of tcp_wrappers. It allows you to do the same thing the father can do, but its gained a different sense of intelligence that in some ways surpasses the father. It also has more room to grow as the kernel has matured more since the early days of tcp_wrappers’ existence.
The problem with iptables, though, is that with its robustness, comes a lot more trickery in getting simple firewall rules to work. Now, this isn’t to say that iptables shouldn’t be learned, no. Just the contrary, what looks frightening at first, will look like a cute little baby line once you actually know what you’re doing. On a personal note, my biggest fear with iptables I had was writing a line to block me out of SSH with it (since I don’t use a standard port for SSH to begin with), but I quickly overcame that once I got it to work.
For an example, we’ll try this:
iptables -t nat -A PREROUTING -p tcp –dport 80 -j REDIRECT –to-port 8080
At first you might be looking like at it like, “what the hookey is that?!” Well, it’s actually quite simple if you look at in parts, instead of just one huge line of firewall goodness.
“-t nat” – Use the NAT table in iptables (there’s NAT, INPUT, OUTPUT, and SECURITY…most rules will be of the first three though). This can be thought of like the filesystem for iptable rules.
“-A PREROUTING” – Add this rule to the prerouting chain. This is more so the folder in the filesystem, that holds all the rules neatly.
“-p tcp” – Part of the rule is to filter traffic that use TCP.
“–dport 80″ – Look for TCP traffic that’s coming into the system on port 80 (HTTP)
“-j REDIRECT” – What job do we want the rule to do? Redirect the packet to…
“–to-port 8080″ – …8080.
Basically, this line is saying redirect all traffic coming in on port 80 to port 8080, because the server is behind a NAT. This is, in layman terms, port forwarding. Its not as easy as trying to do it in a home router, but iptables gives you a lot more power, with actually pretty simple syntax.
Ultimately, I’m going to miss the simplistic method of tcp_wrappers acting as my firewall, but iptables is more versatile, and to a bigger extent, powerful. I don’t think I’ll be missing the father for long.