Building Firewalls with iptables, Part 2
Exposing any system, no matter how briefly, to an untrusted network is suicidal. A firewall is absolutely vital, and fortunately, the Linux world offers an excellent free firewall utility in netfilter/iptables. Carla Schroder takes a deeper look at iptables with additional rules and scripts for basic firewalling and sharing Internet connections.
Last week in Part 1 we began uncovering some of the mysteries of tables and chains, and how to build iptables rules. This week we will dig more into writing rules for basic firewalling, sharing an Internet connection, and scripting.
Paying for Our SYNs
We can't close off all ports; that will shut us off completely. We also can't just specify that certain ports will remain open, since it's impossible to predict which ports non-service programs will grab. And simply allowing traffic destined for specific ports does nothing to prevent malicious bits from waltzing right on in. So what exactly can we do to set up an effective rule that allows the good guys to pass through while preventing the bad ones from accessing our network?
For starters, we can take advantage of the syn flag set to prevent unauthorized access. While iptables examines only headers, not payload, it still does a lot of useful packet analysis based on the headers. For example, when Web surfing, a request goes from your PC to a web server out there somewhere. The web server then responds and sends packets back to you, grabbing the first convenient ephemeral (temporary) port on your system. Other than responding to your request, the server has no reason whatsoever to be sending traffic your way. We can take advantage of this by setting up a rule that blocks all incoming TCP connections that are not initiated by your system:
# iptables -t filter -A INPUT -i eth0 -p tcp --syn -j DROP
-i names the network interface, -p names which protocol, and --syn means TCP packets with the syn flag set. This also illustrates the importance of understanding TCP/IP. SYN is used to initiate a TCP connection. If you're not running any servers on your end, there's no reason for anyone to be sending you SYN packets.
At this point, someone usually wails, "Why can't it be EASY?" Yes, there are easier ways to build firewalls. There are nice hardware widgets as well as software utilities for constructing rulesets (see Resources), but Grasshopper, you know as well as I do, the easy way is not always the best way. And if an old fossil like me can figure this stuff out, anyone can.
Stateful Packet Inspection
The previous example rule looks at each packet individually, rather than in context, and relies on the information in the header. If everyone were truthful and benevolent, this would be enough. (Heck, if everyone were truthful and benevolent, we wouldn't need firewalls in the first place, would we?) iptables inspects the source and destination IP addresses, the source and destination ports, the sequence numbers of incoming packets, the TCP sequencing information, and the status from the header flags (SYN, ACK, FIN, RST, etc.). In other words, it tracks entire connection sessions, making filtering decisions in context.