By Bri 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 -o $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 $EXT_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....
Bri 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. Bri can be reached at bri@hackinglinuxexposed.com.
Copyright Bri Hatch, 2002
This is the October 08, 2002 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.