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 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.
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:
ADMIN$ cat /etc/hosts.allow
sshd: 192.168.1.
ADMIN$ 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:
ANU007TIGER$ 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;
}
ANU007TIGER# /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
ANU007TIGER#
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.
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.
NOTES:
[1] http://www.netfilter.org/
[2] 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.
[3] Some might say that writing your own iptables rulesets is like acting as your own lawyer....
Sunday, September 12, 2010
Anu
