Egress filtering for a healthier Internet.
By Brian Hatch.
The Slammer/Sapphire/etc worm really ruined my Internet experience for a few days. Yes, patches were available. Yes, people should have blocked inbound access to their windows boxes when not needed. These and many other explanations about what could have been done were discussed all over. However one thing that seems to have been overlooked in many sources is that it was the outbound packets that were killing us, and we shouldn't have been subject to them at all.
We are used to thinking of security as a defensive battle: keep the bad guys out of our systems. We set up our firewalls to block known attacks, block any inbound packets that don't go to permitted ports, restrict inbound packets from untrusted sources, keep spam out by blocking connections from machines on DNSBLs[1]. These are all defensive barriers we erect in front of our servers to keep the bad guys out.
The problem is that sooner or later there will be a breach of those barriers. Perhaps a bug exists in one of the services that you do need to permit. Perhaps your firewall rules were too weak. The problem is that once you are cracked, the cracker is on the inside of the firewall, and is uninhibited by your inbound rulesets.
Blocking inappropriate inbound access is a very good and necessary thing. However people need to start blocking inappropriate outbound access too. If your machine is just a mail server, then it needs to be able to send out packets from and to port 25, but it doesn't need to be able to make an HTTP connection. If you run a DNS server, it doesn't need to be able to support outbound FTP. And for goodness sake, if your network is w.x.y.z, packets from other addresses should never leave your boarders.
When your computer is compromised, you are no longer the innocent party trying to defend yourself, to other machines you have become the attacker. You owe it to others to make outbound attacks more difficult to the cracker or worms that have managed to get onto your machine.
Outbound packet security is called egress filtering. It's no harder to implement than the ingress filtering rules you should already have. Had the Slammer hosts been behind firewalls with proper egress filters, the outbound attacks would never have been dropped at their firewall/router.
As always, the best rule when creating firewalls/access lists is to list those packets which should be allowed and deny the rest. Be very restrictive! Better to break a few applications during testing than to leave holes open. If you have a completely new network, it is easy to block everything and open ports as needed. if you have an existing network, you should run a sniffer, logging the type of network activity you experience currently, and then create your rules to match them.[2]
So, let's take an example of the following server. We'll create both ingress and egress filters such that it does exactly what it needs, and no more.
Our sample machine runs Apache, Postfix, and allows inbound SSH access from the local network only. It needs to be able to look up DNS entries for it's Apache logfiles and to support a few DNSBL lists for preventing inbound spam. Here are the iptables rules you'd create on this host to support this configuration:
Full Version: Egress Filtering
| CODE |
| #!/bin/sh # Define a few variables for ease of use MYIP=123.456.789.012 MYNET=123.456.789.0/24 ETHERNET="eth0" # This machine makes all DNS requests to a single # DNS server, rather than asking the roots directly. DNSSERVER=210.987.654.321 # Set the policy to be DROP. In other words, should a packet # not match any rule, it will be dropped by default. We'll # put this before the flush to make sure that while this script # runs, we are secure by default. iptables -P INPUT DROP iptables -P OUTPUT DROP # Flush all tables. iptables -F iptables -F INPUT iptables -F OUTPUT # Let's allow all packets on the local (127.1) network interface. iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Drop all inbound packets that claim to be from us.. iptables -A INPUT -i $ETHERNET -s $MYIP -j DROP # Drop all outbound packets that claim not to be from us. iptables -A OUTPUT -o $ETHERNET -s ! $MYIP -j DROP # Block inbound from RFC1918 networks iptables -A INPUT -i $ETHERNET -s 10.0.0.0/8 -j DROP # Add other such rules here to block 172.16/12, 192.168./16 # and other networks, multicast, and flag settings that you # should not expect from legitimate traffic. # # Remember, this example is to show egress filtering, not a # full firewall implementation. # Allow inbound HTTP from everywhere iptables -A INPUT -i $ETHERNET -p tcp -d $MYIP --dport 80 -j ACCEPT iptables -A OUTPUT -o $ETHERNET -p tcp -s $MYIP --sport 80 ! --syn -j ACCEPT # Allow inbound SSH from local network iptables -A INPUT -i $ETHERNET -p tcp -d $MYIP --dport 22 -s $MYNET -j ACCEPT iptables -A OUTPUT -o $ETHERNET -p tcp -s $MYIP --sport 22 -d $MYNET ! --syn -j ACCEPT # Allow outbound DNS to our nameserver[3] iptables -A OUTPUT -o $ETHERNET -p udp -s $MYIP --dport 53 -d $DNSSERVER -j ACCEPT iptables -A INPUT -i $ETHERNET -p udp -d $MYIP --sport 53 -s $DNSSERVER -j ACCEPT # Log any rejects to syslog so we can debug iptables -A INPUT -j LOG iptables -A OUTPUT -j LOG |
Many firewalls simply create rules on the INPUT chain. The OUTPUT rules above comprise our egress filters. As you can see, an egress filter will usually look pretty close to an ingress filter, so generating them is pretty simple, just reverse the -d / --dport (destination address / destination port) and -s / --sport (source address / source port) arguments. I like to include ! --syn where appropriate to prevent the initial packet of the TCP three way handshake, just to be verbose.
The above code is by no means a complete firewall. You'll want to include changes to some /proc entries[4], drop source routed packets and packets from the non-routable RFC-1918 networks, include some NAT or connection tracking modules, etc. I heartily recommend "Linux Firewalls, Second Edition" by Bob Ziegler - it has excellent iptables and ipchains info and sample configurations.
You can implement egress filtering on both the host itself, and on your firewalls. To protect those Windows boxes on your network, the firewall may be the only appropriate place. If a cracker gets onto your machine, rather than an automated worm, he/she would be able to undo your iptables rules quite easily, so it's always a good idea to include rules on the firewall as well.
The one thing I'd like you to take away from this article is that egress filtering is a good thing. Here are just a few reasons:
* You won't be a source of attacks, and will thus be less likely to be blackholed as a bad netizen, or break the AUP of your ISP.
* You're less likely to need to admit you were broken into. (Image is important for big companies.)
* Most attacks use TCP, and if you drop the outgoing SYN packet, you'll never establish the session, and the drain on your network will be minimal.
* You're more likely to find when an attacker is calling out to get his/her tools, or prevent them altogether.
* You're more likely to see when an upgrade of your software changes it's network requirements in a way you don't like.
* You'll find when internal users are acting differently than you expect.
* You'll keep spyware and other software from 'calling home'
Many of the firewall-creation scripts you find on the Internet do include egress filtering as well. If you are using one that does not, you can modify it to do so fairly easily. Or you can look for one that was designed with more paranoia from the beginning.
Copyright Brian Hatch, 2003
Oh yeah! Preaching the good word brother! Can I get a Hallelujah? Hallelujah!!!! 
So many hacks out there rely on almost complete open outbound access and this prevents all of those hacks. Although, they are adapting of course to start requestiong tools and things on port 80. All of my servers are unable to talk to anything on the outside world except in a reply to the services they host.
So my webserver can only go outbound on source port 80 and destination port >1023 which helps protect it because it is very difficult to force a server (without already having tools on the box) to do forged packets with only src 80 and dst <1024 as an initator packet. This is the same for all of my servers except for my virus ones which have a specific need to go to the virus site to update their signatures which is a specific range of IPs.
This also can work in a client environment but you need to be able to say I will only allow these protocols outbound or even better yet setup a proxy for only what you want to allow outbound. Generally it can be restricted quite heavily (although some folk will hate you).
Brother dillinja keep spreading that good good word! Hallelujah Brother!
--P.G.
So many hacks out there rely on almost complete open outbound access and this prevents all of those hacks. Although, they are adapting of course to start requestiong tools and things on port 80. All of my servers are unable to talk to anything on the outside world except in a reply to the services they host.
So my webserver can only go outbound on source port 80 and destination port >1023 which helps protect it because it is very difficult to force a server (without already having tools on the box) to do forged packets with only src 80 and dst <1024 as an initator packet. This is the same for all of my servers except for my virus ones which have a specific need to go to the virus site to update their signatures which is a specific range of IPs.
This also can work in a client environment but you need to be able to say I will only allow these protocols outbound or even better yet setup a proxy for only what you want to allow outbound. Generally it can be restricted quite heavily (although some folk will hate you).
Brother dillinja keep spreading that good good word! Hallelujah Brother!
--P.G.
Would the general rule of thumb for setting up inbound/outbound rulesets for, say a newly set up network, be block all, then only open what is absolutly neccessary?
Would you say egress filtering be on par (in terms of importance over all) with ingress protection?
Would you say egress filtering be on par (in terms of importance over all) with ingress protection?
ABSO-FRIGGEN-LUTELY! As all security proffesional knows start with the most restricted and then open only what is necessary. Ingress and egress should be equal in importance, especially when we are talking servers. This adds a HUGE level of additional protection and as we all know defense in depth is the only way to go and the addition of egress filtering is a great addition to that. In fact you could even have a deny all on your egress filter, period (ok if you are running IPTables you want to add your established rule in there). Your statefull firewall will take care of the return traffic from your servers no problem!
I don't care what the security level is, definitly configure both inbound and outbound access lists equally. And don't get lazy! If you want windows update (you lamer) to update your systems only allow access to the windows update IP range and only on port 80 (or is it 443). And remember that these servers are not clients! You should not be surfing the web on them! If you were running linux you woulnd't even have a GUI at all on them would you? So just because you are running a system which for some reason deems it neccessary to run a full GUI and web browser on all servers don't use it! Restrict that access!
And you linux folk, yeah I know you have 22 outbound open don't you? Well cut it out, why do you need to SSH from a production server (well yes I can think of a few reasons too)? It opens up a hole that a hacker could exploit and creates a secure channel of communications that you may or may not actually want (not to mention the VPN capabilities).
And don't get me started on ICMP folk, don't let the bastards know you are there!
--P.G.
PS: If I sound a bit nuts on this topic I've been on a crusade to get companies to to complete egress filtering and I fight daily with the server admins who can't get it through their heads that servers are servers and NOT workstations!
I don't care what the security level is, definitly configure both inbound and outbound access lists equally. And don't get lazy! If you want windows update (you lamer) to update your systems only allow access to the windows update IP range and only on port 80 (or is it 443). And remember that these servers are not clients! You should not be surfing the web on them! If you were running linux you woulnd't even have a GUI at all on them would you? So just because you are running a system which for some reason deems it neccessary to run a full GUI and web browser on all servers don't use it! Restrict that access!
And you linux folk, yeah I know you have 22 outbound open don't you? Well cut it out, why do you need to SSH from a production server (well yes I can think of a few reasons too)? It opens up a hole that a hacker could exploit and creates a secure channel of communications that you may or may not actually want (not to mention the VPN capabilities).
And don't get me started on ICMP folk, don't let the bastards know you are there!
--P.G.
PS: If I sound a bit nuts on this topic I've been on a crusade to get companies to to complete egress filtering and I fight daily with the server admins who can't get it through their heads that servers are servers and NOT workstations!
Thanks packet 
It is indeed a worthy crusade....bit of a bummer though if you wanted to play quake III from your FTP server!
It is indeed a worthy crusade....bit of a bummer though if you wanted to play quake III from your FTP server!
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
