Egress Filtering: Fencing in the Bad Guys - Page 2

By Carla Schroder | Posted Mar 20, 2003
Page 2 of 2   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

It's critical to prevent the big bad outside world from connecting to localhost. Note the use of REJECT rather than DROP. REJECT sends a response, whereas DROP does not -- it simply drops the packet cold, with no further processing or response. REJECT is better against certain types of attacks, such as port scanning, since it doesn't leave any dead sockets and tells the scanner to go away -- no one is home.

$IPTABLES -A INPUT -d lo -j REJECT--reject-with icmp-port-unreachable 

There are many options for the type of response sent. Some others are:

$IPTABLES -A INPUT -d lo -j REJECT--reject-with icmp-network-unreachable
$IPTABLES -A INPUT -d lo -j REJECT--reject-with icmp-host-unreachable

IP spoofing is a favorite ploy of leet haxors (elite hackers) to hide their backtrail. Drop incoming packets that claim to originate from your host, and drop outgoing packets that do not. Many rulesets come in pairs. We're letting packets out on the assumption that our incoming packets have been examined and the bad guys blocked:

$IPTABLES -A INPUT -i $IFACE -s $LAN_IP -j DROP
$IPTABLES -A OUTPUT -o $IFACE -s ! $LAN_IP -j DROP 

Restrict outgoing and incoming ICMP. Poor old ping has been put to many nefarious uses. In this example, we permit simple echo requests (ping) and simple echo replies (pong), both incoming and outgoing. Some admins like to completely block all ICMP requests. This usually is not a good idea, as many network functions and applications need ping to work properly. However, there's no hard-and-fast rule for this.

$IPTABLES -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
$IPTABLES -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
$IPTABLES -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT 

iptables does stateful packet filtering, so we can do things like the following, which allows established connections to send packets out (assuming, of course, that the inbound rules have done their job and not let anything malicious in):

$IPTABLES -I OUTPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT 

Access to Services

Here is a rule to allow DHCP. Use this only where it is necessary. For example, a network gateway with a static external IP won't need to talk to a DHCP server; however, your internal hosts may need to connect to an internal DHCP server. Note that ports are limited to UDP 67 and 68; TCP 67/68 are not allowed. Again, be very specific about what to allow:

$IPTABLES -A INPUT -p UDP -i $IFACE --dport 67 --sport 68 -j ACCEPT

Suppose you are not running your own mail server but must instead connect to an outside server:

$IPTABLES -A INPUT -p tcp --destination-port 25 \ -m state --state NEW,ESTABLISHED -j ACCEPT

To fine tune your rulesets, put sniffers on both sides of your firewalls or border routers and study the logs. Look at what hits your defenses and what escapes. Hopefully there will be no rude surprises, but if so, it is always better to know! This is where little old laptops that aren't much good for anything else are real handy -- set them up as portable network monitoring stations.

Again, I wish to emphasize this is not even close to being a complete firewall script. See the resources listed below for reference materials; the internet is also full of good tutorials and sample firewall scripts to study. If you're using some other means of packet filtering, the main concept of egress filtering still applies: don't let bad packets escape your network.

Resources

Linux Firewalls, Second Edition by Bob Ziegler
Building Secure Servers with Linux By Michael D. Bauer
Hacking Exposed Windows 2000 by Joel Scambray, Stuart McClure
The Netfilter/$IPTABLES Project


» See All Articles by Columnist Carla Schroder


Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter