Louwrentius

I started a small new Google project for a new script I wrote called LFS. It stands for Linux Firewall Script.

I run a small Linux box as an internet router that doubles as a firewall. The firewall is configured using iptables. In my opinion, iptables is not the easiest tool to use and may have a steep learning curve for people new to it.

The goal of LFS is to provide an easier interface to iptables. It also adds some features that by default are not or difficult to setup using only iptables. The most important additional feature is the use of objects and groups. Object groups can be used to make a single rule affect multiple hosts, networks or services.

LFS uses a single configuration file which contains the firewall rules. Rules look like this:

nat 192.168.1.0/24 88.32.44.144 eth0
port_forward 88.32.44.144 192.158.1.10 80/tcp 8080/tcp

Or by using variables:

nat "$INTERNAL_NETWORK" "$EXTERNAL_IP" "$NAT_INTERFACE"
port_forward "$EXTERNAL_IP"  "$INTERNAL_HTTP_SERVER" "80/tcp" "8080/tcp"

Please visit the project page for some examples.

When configuring my new firewall using iptables, I noticed something very peculiar. Even if all input, forward and output traffic was dropped, DHCP traffic to and from my DHCP server was not blocked even if there were no rules permitting this traffic.

I even flushed all rules, put a drop all rule on all chains and only allowed SSH to the box. It did not matter. The DHCP server received the DHCP requests and happily answered back.

How on earth is this possible? In my opinion, a firewall should block all traffic no matter what.

But at least I found out the cause of this peculiar behaviour. The ISC DHCP daemon does not use the TCP/UDP/IP stack of the kernel. It uses RAW sockets. Raw sockets bypass the whole netfilter mechanism and thus the firewall.

So remember: applications using RAW sockets cannot be fire walled by default. Applications need root privileges to use RAW sockets, so RAW sockets thankfully cannot be used by arbitrary unprivileged users on a system, but never the less. Be aware of this issue.

Please understand that if a serious security vulnerability is found in the ISC DHCP daemon, you cannot protect your daemon with a local firewall on your system. Patching or disabling would then be the only solution.