{"id":12,"date":"2003-05-23T09:57:08","date_gmt":"2003-05-23T14:57:08","guid":{"rendered":"http:\/\/192.168.33.66\/wp\/?p=12"},"modified":"2009-12-30T22:09:35","modified_gmt":"2009-12-31T03:09:35","slug":"dayair-firewall","status":"publish","type":"post","link":"http:\/\/www.wildow.com\/blog\/?p=12","title":{"rendered":"Egress Filtering: Fencing in the Bad Guys"},"content":{"rendered":"

<\/strong><\/span>March 20, 2003
\nBy Carla Schroder<\/a>
\nhttp:\/\/networking.earthweb.com\/netsysm\/article.php\/10954_2168251_1<\/span><\/span><\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

The bottom line — filtering outgoing traffic is just as important as filtering incoming.<\/p>\n

What to Block and How to Block It<\/strong><\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Sample Rules<\/strong><\/p>\n

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.”<\/p>\n

First, define the usual variables. Use what suits you; these sample values are listed so that the examples will make better sense:<\/p>\n

#!\/bin\/sh\r\nLAN_IP=\"192.168.0.2\"\r\nLAN_NET_RANGE=\"192.168.0.0\/16\"\r\nIFACE= \"eth0\"\r\nLO_IFACE=\"lo\"\r\nLO_IP=\"127.0.0.1\"\r\nIPTABLES=\/usr\/sbin\/iptables\r\n<\/span><\/pre>\n
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.<\/p>\n
$IPTABLES -P INPUT DROP\r\n$IPTABLES -P OUTPUT DROP\r\n$IPTABLES -P FORWARD DROP\r\n<\/span><\/pre>\n
We must enable loopback, or many things will break.<\/p>\n
$IPTABLES -A INPUT -i lo -p all -j ACCEPT\r\n$IPTABLES -A OUTPUT -o lo -p all -j ACCEPT\r\n<\/span><\/pre>\n
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.<\/p>\n
$IPTABLES -A INPUT -j LOG\r\n$IPTABLES -A OUTPUT -j LOG<\/span><\/pre>\n
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.<\/span><\/span><\/p>\n
$IPTABLES -A INPUT -d lo -j REJECT--reject-with icmp-port-unreachable\r\n<\/span><\/pre>\n
There are many options for the type of response sent. Some others are:<\/p>\n
$IPTABLES -A INPUT -d lo -j REJECT--reject-with icmp-network-unreachable\r\n$IPTABLES -A INPUT -d lo -j REJECT--reject-with icmp-host-unreachable\r\n<\/span><\/pre>\n
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:<\/p>\n
$IPTABLES -A INPUT -i $IFACE -s $LAN_IP -j DROP\r\n$IPTABLES -A OUTPUT -o $IFACE -s ! $LAN_IP -j DROP\r\n<\/span><\/pre>\n
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.<\/p>\n
$IPTABLES -A INPUT -p icmp --icmp-type echo-request -j ACCEPT\r\n$IPTABLES -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT\r\n$IPTABLES -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT\r\n$IPTABLES -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT\r\n<\/span><\/pre>\n
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):<\/p>\n
$IPTABLES -I OUTPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT\r\n<\/span><\/pre>\n
Access to Services<\/strong><\/p>\n
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:<\/p>\n
$IPTABLES -A INPUT -p UDP -i $IFACE --dport 67 --sport 68 -j ACCEPT<\/span><\/pre>\n
Suppose you are not running your own mail server but must instead connect to  an outside server:<\/p>\n
$IPTABLES -A INPUT -p tcp --destination-port 25 \\ -m state --state NEW,ESTABLISHED -j ACCEPT<\/span><\/pre>\n
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.<\/p>\n
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.<\/p>\n
Resources<\/strong><\/p>\n
Linux Firewalls, Second Edition<\/span> by Bob Ziegler
\nBuilding Secure Servers with Linux<\/span> By Michael D. Bauer
\nHacking Exposed Windows 2000<\/span> by Joel Scambray, Stuart McClure
\nThe Netfilter\/$IPTABLES Project<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
March 20, 2003 By Carla Schroder http:\/\/networking.earthweb.com\/netsysm\/article.php\/10954_2168251_1<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-12","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/12","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=12"}],"version-history":[{"count":2,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/12\/revisions"}],"predecessor-version":[{"id":350,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/12\/revisions\/350"}],"wp:attachment":[{"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=12"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=12"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=12"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}