Firewalls are mostly used in enterprise companies to restrict access to certain ports and services. The difference between proxies and firewalls is that proxies can filter or modify content that passes through them. Firewalls work on a lower lever, filtering access to certain ports, certain services, or tcp or udp traffic. With that being said, why would an average computer user want a firewall? Of course, there is increased security, since only the ports that you need are open, meaning you can deny ping requests or telnet sessions ever being opened. Most average users don’t really care about security though, since malicious users usually will try to go after big-name servers. However, a practical use of setting up a firewall at home is to allow to computers or more to exist on the network at the same time. Most people nowadays buy home routers made by Linksys or D-Link, but those can be expensive. For a firewall, all you really need is a computer with two NIC cards. You can buy one really cheap either from ebay or from a local computer store. Make sure it is working when you start the computer, and assign it with a static ip address, usually 192.168.0.1. Make sure you can ping that ip address. If you only have one more computer to connect, you can connect it straight to the firewall, but make sure that you use a crossover cable, because it is a peer-to-peer connection. If you have more than one computer to connect, would like to have the potential to link other computers, or simply don’t want to deal with crossover cables, you can get yourself a small hub or switch to put between your firewall and your internal network. There’s no point in putting a router there, since it creates unneeded redundancy. Assign the internal node a static ip address also, for example 192.168.0.5. If the internal node can ping the firewall at the static ip address 192.168.0.1, then you are golden. Otherwise, there is something wrong with the cables or with the switch/hub. Since assigning static ips is a pain, we want DHCP to do the work for us. So, install and configure dnsmasq, in order to make sure it is running. If you configure your internal nodes to automatically assign themselves an IP address from a DHCP server at boot up and point them to the firewall, they should have an automatic IP address on startup. Test this setup thoroughly to make sure it is working. That is the easy part. The hard part is getting iptables to work, which you’ll have to install in order to have the firewall running. What we want to do is NAT (Network Address Translation), which takes all the packets originating at the internal nic, and modifies the origin to be the external nic, thereby abstracting the internal computers from the rest of the world. First of all, you need to make sure that your kernel supports iptables. Most distributions come with iptables configured, but you need to make sure. Since I use Gentoo, the kernel usually doesn’t have it. I therefore used genkernel after many frustrating recompiles, but ideally this configuration guide should let you know what to have enabled in your .config file. After you know your kernel is working and supports iptables (I suggest building everything as modules), make some basic rules to know that it’s working. Now, in order to get everything flowing nicely together, you can do two things. You can either install firestarter, a firewall GUI which will setup the rules for you, or you can do it by hand. Here is what you would need to type in order for iptables to work with NAT:
First we flush our current rules
# iptables -F
# iptables -t nat -F
Setup default policies to handle unmatched traffic
# iptables -P INPUT ACCEPT
# iptables -P OUTPUT ACCEPT
# iptables -P FORWARD DROP
Copy and paste these examples ...
# export LAN=eth0
# export WAN=eth1
Then we lock our services so they only work from the LAN
# iptables -I INPUT 1 -i ${LAN} -j ACCEPT
# iptables -I INPUT 1 -i lo -j ACCEPT
# iptables -A INPUT -p UDP --dport bootps -i ! ${LAN} -j REJECT
# iptables -A INPUT -p UDP --dport domain -i ! ${LAN} -j REJECT
(Optional) Allow access to our ssh server from the WAN
# iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT
Drop TCP / UDP packets to privileged ports
# iptables -A INPUT -p TCP -i ! ${LAN} -d 0/0 --dport 0:1023 -j DROP
# iptables -A INPUT -p UDP -i ! ${LAN} -d 0/0 --dport 0:1023 -j DROP
Finally we add the rules for NAT
# iptables -I FORWARD -i ${LAN} -d 192.168.0.0/255.255.0.0 -j DROP
# iptables -A FORWARD -i ${LAN} -s 192.168.0.0/255.255.0.0 -j ACCEPT
# iptables -A FORWARD -i ${WAN} -d 192.168.0.0/255.255.0.0 -j ACCEPT
# iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE
Tell the kernel that ip forwarding is OK
# echo 1 > /proc/sys/net/ipv4/ip_forward
# for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done
This is so when we boot we don't have to run the rules by hand
# /etc/init.d/iptables save
# rc-update add iptables default
# nano /etc/sysctl.conf
Add/Uncomment the following lines:
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
If you have a dynamic internet address you probably want to enable this:
net.ipv4.ip_dynaddr = 1
Courtesy of a gentoo linux howto.
From there on, try to access google from one your internal computers. If everything is done correctly it should work. Granted, some ports will be blocked by your firewall, so you will need to open them on a need-per-port basis.
Planet of the Ecks 