Your network's first barrier against unwanted infiltrators is your firewall. You do have a firewall in place, right? If you think you don't need one, monitor your incoming network traffic some time: you might be amazed by the attention you're receiving. For instance, one of our home computers has never run a publicly accessible service, but it's hit 10-150 times per day by Web, FTP, and SSH connection requests from unfamiliar hosts. Some of these could be legitimate, perhaps web crawlers creating an index; but when the hits are coming from dialup12345.nowhere.aq in faraway Antarctica, it's more likely that some script kiddie is probing your ports. (Or the latest Windows worm is trying in vain to break in.)
Linux has a wonderful firewall built right into the kernel, so you have no excuse to be without one. As a superuser, you can configure this firewall with interfaces called ipchains and iptables. ipchains models a stateless packet filter. Each packet reaching the firewall is evaluated against a set of rules. Stateless means that the decision to accept, reject, or forward a packet is not influenced by previous packets.
iptables, in contrast, is stateful: the firewall can make decisions based on previous packets. Consider this firewall rule: "Drop a response packet if its associated request came from server.example.com." iptables can manage this because it can associate requests with responses, but ipchains cannot. Overall, iptables is significantly more powerful, and can express complex rules more simply, than ipchains.
ipchains is found in kernel Versions 2.2 and up, while iptables requires kernel Version 2.4 or higher. The two cannot be used together: one or the other is chosen when the kernel is compiled.
 Kernel 2.0 has another interface called ipfwadm, but it's so old we won't cover it.
A few caveats before you use the recipes in this chapter:
We're definitely not providing a complete course in firewall security. ipchains and iptables can implement complex configurations, and we're just scratching the surface. Our goal, as usual, is to present useful recipes.
The recipes work individually, but not necessarily when combined. You must think carefully when mixing and matching firewall rules, to make sure you aren't passing or blocking traffic unintentionally. Assume all rules are flushed at the beginning of each recipe, using iptables -F or ipchains -F as appropriate. [Recipe 2.17]
The recipes do not set default policies (-P option) for the chains. The default policy specifies what to do with an otherwise unhandled packet. You should choose intelligent defaults consistent with your site security policy. One example for iptables is:
# iptables -P INPUT DROP # iptables -P OUTPUT ACCEPT # iptables -P FORWARD DROP
and for ipchains:
# ipchains -P input DENY # ipchains -P output ACCEPT # ipchains -P forward DENY
These permit outgoing traffic but drop incoming or forwarded packets.
The official site for iptables is http://www.netfilter.org, where you can also find the Linux 2.4 Packet Filtering Howto at http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html. Another nice iptables article is at http://www.samag.com/documents/s=1769/sam0112a/0112a.htm.
Our Firewall Philosophy
In designing a set of firewall rules for a Linux host, there are several different models we could follow. They correspond to different positions or functions of the host in your network.
For this chapter, we decided to take the first approach?single computer?as our model. The other models are also valid and common, but they require a more detailed understanding of topics beyond the scope of this book, such as IP routing, routing protocols (RIP, OSPF, etc.), address translation (NAT/NAPT), etc.
We also assume your single computer has source address verification turned on, to prevent remote hosts from pretending to be local. [Recipe 2.1] Therefore we don't address such spoofing directly in the firewall rules.