Information Security News mailing list archives
Ten minute Firewall
From: InfoSec News <isn () c4i org>
Date: Wed, 9 Oct 2002 02:22:34 -0500 (CDT)
+------------------------------------------------------------------+ | Linux Security: Tips, Tricks, and Hackery | | Published by Onsight, Inc. | | | | 08-October-2002 | | http://www.hackinglinuxexposed.com/articles/20021008.html | +------------------------------------------------------------------+ This issue sponsored by: Onsight, Inc, your source for open-source solutions. Onsight offers on-site training on Basic Perl programming, Advanced Perl programming, CGI programming using Perl, Tcl/Tk, XML and JavaScript. All courses are hands-on, designed by real-world consultants and fully customizable. Because all classes are on-site, our overhead is low and our prices consistently beat those of our competitors. Every Onsight instructor is a seasoned consultant able to provide back-end web programming, network security, system administration and other support services. For more information, visit http://www.onsight.com/ -------------------------------------------------------------------- Ten minute Firewall By Brian Hatch Summary: Create a simple but effective firewall for your home network in ten minutes or less. Newsletter Subscription Note: Welcome to the Linux Security: Tips, Tricks, and Hackery newsletter. Folks who were subscribed to the old ITWorld list are slowly signing up to the new one. Feel free to pass this message on to others. If you wish to subscribe and receive the newsletter each week in your email, go to http://lists.onsight.com/. For the last four months I've been living in a temporary apartment while our house was being remodeled and my servers have been in storage. For four months our daily computing lives have been reduced to two laptops directly attached to the Internet via DSL. This wasn't much of a problem for my machine, since it runs Linux and has a very paranoid set of iptables rulesets. My fiancee's, however, runs Windows 98, with enough vulnerabilities to fill an encyclopedia. So now that we're settled down, it's time to set up our LAN and get a proper firewall in place. Each major version of Linux has had a different firewalling software suite. 2.0 kernels had ipfwadm, 2.2 had ipchains, and 2.4 has iptables. (2.4 can support ipchains-style rules if you load the ipchains module.) Each offers great improvements from its predecessors. Iptables, aka Netfilter[1] offers extreemly powerful network controls, and can route packets to and from different machines and ports in ways beyond belief and understanding. Because of it's potential compexity, iptables can be intimidating. There are many Firewall scripts[2] out and about on the Internet, as well as some excellent firewall books[3]. If you want the nitty gritty, these are the places to go. Instead, here I intend to help you whip up a firewall in ten minutes or less. First, some lame ASCII art: LAN 192.168.1.0/24 +--- machine | Internet ----- Firewall ----+ +--- machine | +--- machine We're going to use a dedicated firewall machine with two network cards, and put all our machines behind it on the LAN. Let's assume we pick 192.168.1.0/24 as the LAN network, offering us a maximum of 254 hosts back there. We'll use 192.168.1.1 for the firewall's LAN IP address (let's assume this is eth0) and assume that the IP address for the Internet side is 300.3.3.3 on eth1. Our firewall won't do much. We'll turn off all services except for ssh, which you should lock down by configuring your TCP Wrappers to deny all hosts except the lan: machine$ cat /etc/hosts.allow sshd: 192.168.1. machine$ cat /etc/hosts.deny ALL: ALL The only other thing we'll run on the firewall is a DHCPD server to distribute IP addresses to the LAN machines. We'll configure iptables to re-write all outbound packets from LAN hosts, thus masquerading all outbound connections as if they came from the firewall itself. This setup should work for any kind of Internet connectivity you have, be it dedicated DSL, dialup modem, or anything. The only tricky part may be making sure you have some way to know the IP address given to you by your ISP. While I'll call it 300.3.3.3 here, it's up to you to figure out what it is, and find some way to re-run our configuration should it change. First, let's set up our DHCP server by creating an /etc/dhcpd.conf file. We need to specify a blank configuration for the Internet-connected side (300.3.3.0/24, presumably) and then our actual data for inside: firewall$ cat /etc/dhcpd.conf subnet 300.3.3.0 netmask 255.255.255.0 { } subnet 192.168.1.0 netmask 255.255.255.0 { allow bootp; option routers 192.168.1.1; option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; # Adjust these lines option domain-name "example.com"; option domains-name-servers A.B.C.D E.F.G.H; range dynamic-bootp 192.168.1.50 192.168.1.254; default-lease-time 18000; max-lease-time 18000; get-lease-hostnames on; } firewall# /etc/init.d/dhcp start Internet Software Consortium DHCP Server 2.0pl4 Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved. Please contribute if you find this software useful. For info, please visit http://www.isc.org/dhcp-contrib.html Listening on LPF/eth1/00:10:18:77:bd:28/192.168.1.0 Sending on LPF/eth1/00:10:18:77:bd:28/192.168.1.0 Listening on LPF/eth0/00:e0:74:28:e9:e6/300.3.3.0 Sending on LPF/eth0/00:e0:74:28:e9:e6/300.3.3.0 Sending on Socket/fallback/fallback-net firewall# Ok, now that we've gotten our DHCP server started, internal machines will be able to use DHCP to get an address in the 192.168.1.50 - 192.168.1.254 range. I like to leave some IPs on the Class C for non-DHCP hosts, so 192.168.1.2-49 are available for these machines if you wish. Ok, time to create your firewall rules. Create a startup script in / etc/init.d and link to it from the /etc/rcX.d directories as appropriate for your machine. Rather than hit each section piece by piece, I'll comment the script itself. #!/bin/sh # Definitions EXT_INTERFACE=eth1 EXT_IP=300.3.3.3 INT_INTERFACE=eth0 INT_IP=192.168.1.1 # Ok, let's load some of the modules we'll need to # support NAT and protocols that act stupid. modprobe iptable_nat modprobe ip_conntrack_ftp ip_nat_ftp modprobe ip_conntrack_irc ip_nat_irc # Whew. Now that all those are out of the way, down to # the nitty gritty. Let's set up our iptables rules. # Flush any existing tables iptables --flush iptables -t nat --flush # Drop packets on the Internet side going to/from the private use # multicast, reserved, and loopback networks. Perform egress # filtering as well, to make sure we don't spoof others. for network in 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 \ 224.0.0.0/4 240.0.0.0/5 127.0.0.1/32 do iptables -A INPUT -i $EXT_INTERFACE -s $network -j DROP iptables -A OUTPUT -i $EXT_INTERFACE -s $network -j DROP done # Ok, now time to tell iptables that we want it to # re-write all connections that initiate from inside # to use it's external interface IP address, and re-write # any of the responses appropriately. iptables -t nat -F iptables -t nat -A POSTROUTING -o $INT_INTERFACE \ -j SNAT --to-source $EXT_IP # End of script That's it. If you lock down your firewall so it is secure, then you can provide Internet connectivity for your internal machines, while keeping them from being directly accessible from the internet. Undoubtably some folks will point out that there are many things I've left out, and I agree. For example this is a classic case of 'default allow' programming, which is a tried and true bad idea. You can create much more complicated firewall scripts that will protect against lots of things not covered here. For the paranoid folks with a good amount of time on their hands, you should write your scripts to explicitly define appropriate connections both inbound and outbound. But for a ten minute firewall installation, this solution offers a good deal of security beyond your typically direct-connected box.[4] These days there seem to be hundreds of ready-to-go firewall scripts out there. I'd love to hear folks impressions and recomendations of those they've used in the past. I'll collect and summarize them next week for folks. Personally, I always write my own[5] Next week: firewall related /proc entries. NOTES: [1] http://www.netfilter.org/ [2] For example http://www.linux-firewall-tools.com/ftp/firewall/ standalone.firewall.1 [3] See our recomendations at http://www.hackinglinuxexposed.com/ books/ [4] This type of firewall protects crackers from getting to your computers directly. But any vulnerabilities in your client software or protocol-related hacks are still are not protected. [5] Some might say that writing your own iptables rulesets is like acting as your own lawyer.... ------------- Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. It seems like lately he's spent more time patching his fiancee's Windows 98 machine than he has spent sleeping. Now that the machine is back behind a firewall, he can bask in the artificial feeling of security with it's single point of failure. Of course Microsoft code counts as several on it's own. Brian can be reached at brian () hackinglinuxexposed com. -------------------------------------------------------------------- This newsletter is distributed by Onsight, Inc. The list is managed with MailMan (http://www.list.org). You can subscribe, unsubscribe, or change your password by visiting http://lists.onsight.com/ or by sending email to linux_security-request () lists onsight com. Archives of this and previous newsletters are available at http://www.hackinglinuxexposed.com/articles/ -------------------------------------------------------------------- Copyright 2002, Brian Hatch. - ISN is currently hosted by Attrition.org To unsubscribe email majordomo () attrition org with 'unsubscribe isn' in the BODY of the mail.
Current thread:
- Ten minute Firewall InfoSec News (Oct 10)