Egress Filtering: Fencing in the Bad Guys
Carla Schroder presents the golden rule for egress filtering -- don't let bad packets escape your network -- and explains why it's just as important to control outgoing traffic from your network as it is to filter incoming.
Carefully constructing walls and moats to keep the bad guys out of our systems is an everyday task. It's equally important to build walls and moats to keep them in, should they successfully penetrate our defenses.
Let's go ahead and review why filtering outbound traffic is so critical, as I still encounter decision makers who just don't get it. Consider Slammer and Code Red, for example, or Slapper and Scalper, or Distributed Denials of Service (DDoS). None of these would have had such a large impact if egress filtering were routinely implemented.
These are just the tip of the iceberg, though; as there's also spyware phoning home, backdoors, Trojans, attacks launched from your systems, employees running activities they shouldn't, and connection hijacking to contend with. And not all "bad" outgoing packets are the result of malice, as a misconfigured router might be lurking in a network. It's important to stop these from spewing wrong packets into the world, too.
The bottom line -- filtering outgoing traffic is just as important as filtering incoming.
What to Block and How to Block It
The idea is to permit only packets from trusted hosts to leave your network. Rule #1 never changes: turn off everything that is not needed. Mail servers don't need FTP or port 53, web servers don't need port 25, and so forth. This works at two levels: individual hosts and border routers. In other words, the goal is to ensure anything bad that escapes from a particular machine will get dropped at the border.
iptables is an extremely flexible tool that permits very fine-grained management of services, making it perfect for writing firewall rules. There's a bit of a learning curve to it, but it's well worth the effort to learn how to properly use this tool. Write iptables rules everywhere you can -- build a standalone firewall/router and use it on individual Linux hosts, for example. Depending solely on border defenses is simply not enough; layers of protection are good and iptables is free, so make the most of it.
Another alternative is the freeware edition of ZoneAlarm, which is an excellent tool for Windows clients, but you may need the commercial version to get sufficient functionality for your needs. In other words, while the free edition will work for most casual home users, business users will likely need the more fine-grained control of the Pro edition.
The following is not a complete firewall script -- don't blame me if the code samples provided below don't offer complete protection for your system. Rather than a netfilter howto, the following examples are simply useful and valuable iptables rules. Every system is different and has different needs, but keep in mind the overall concept -- "deny all; allow only as needed."
First, define the usual variables. Use what suits you; these sample values are listed so that the examples will make better sense:
Our default policy is DROP. A packet that matches none of the rules will be unceremoniously dropped. Routers should not disable forwarding, rather the workstations should not allow forwarding, unless there's a really good reason for enabling it.
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
We must enable loopback, or many things will break.
$IPTABLES -A INPUT -i lo -p all -j ACCEPT
$IPTABLES -A OUTPUT -o lo -p all -j ACCEPT
Log all dropped packets to syslog for later study. This is useful for refining rules and debugging. Logging is very flexible in iptables, as it is possible to create individual logs for each chain or protocol.
$IPTABLES -A INPUT -j LOG
$IPTABLES -A OUTPUT -j LOG