Firewall problems

Problems creating a firewall

Creating a firewall is pretty hard work. You'll have to think up all functionality your firewall will have to accomodate, you'll have to translate that functionality into rules that operate on network packets, then translate those rules into IPtables commands, and then you'll have to group all those commands in a script. The script will have to be made executable, must be invoked automatically at boot time, and stored in some logical place. That's not trivial. It requires intimate knowledge and understanding of networking, of IPtables/Netfilter, and some basic knowledge of scripting and linux. And then you need to review, adapt, expound the firewall you're creating, and the complexities you're encountering multiply.

Problems checking a firewall

After you've created your firewall, you'll have to test it. This might reveal that some packet is getting through that you'd rather not let through, or that some packet is dropped that you'd actually want to receive. Or logging is incomplete, or -just as bad- overcomplete. When this happens, you'll have to find the cause and fix it. But can you easily read the configuration of your firewall? Can your collegue? Can you still read and understand your firewall if the problem occurs five months after you've created it? And what if you suddenly need to log packets that get dropped or accepted - can you easily find the rules that you need to put logging on?

Problems maintaining a firewall

To maintain a firewall requires you to be able to check it, add new functionality, and remove functionality that's no longer needed. However, since the order in which rules are executed is important, it is entirely possible that adding a set of rules in one place of the firewall, breaks the working of it in another. And the same holds for the removal of rules:

• adding a rule that allows certain packets might interfere with rules that log or mark (some of) those packets further down the firewall;
• removing a rule that used to block certain packets does not always mean that the packets now arrive successfully - maybe another rule further down the firewall also blocks (a part of) the packets, or maybe you've not set an "allow" rule for (all of) the packets;
• conversely, removing a rule that used to allow certain packets does not always mean that the packets will now get blocked - maybe another rule further down the firewall still allows (a part of) the packets.

In essence, this proves that any single change to the functionality of the firewall requires a re-evaluation of the whole firewall, checking it's programmed working as-of-now to the intended functionality. Furthermore, if you've actually written code to perform some of your firewalling for you, with conditional statements, with variables and checks, with loops and arrays and whatnot, then you're in even deeper water. What if functionality is required that you haven't coded for: can you easily adapt your code to this new functionality? Have you documented and commented your code? Is it even your code, or is it from a sloppy collegue?

Problems when using Netfilter/IPtables

The forementioned problems can quite easily arise when you or your organization create your own firewall scripts using Linux Netfilter/IPtables. These scripts are usually simple shellscripts with many long lines of IPtables invocations, along the lines of

iptables -A FORWARD -i ipsec+ -o $LAN -s 172.30.50.0/24 -d 172.24.9.15 -j LNX
iptables -A FORWARD -i $LAN -o ipsec+ -s 172.24.9.15 -d 172.30.50.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ipsec+ -o $LAN -s 172.30.50.0/24 -d 172.24.8.0/21 -j SMB_MGMT
iptables -A FORWARD -i $LAN -o ipsec+ -s 172.24.8.0/21 -d 172.30.50.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp -i ipsec+ -o $LAN -s 172.30.50.0/24 -d 172.24.9.1 -m multiport --dport 135,1228,5001,5002,5003,5004 -j ACCEPT
iptables -A FORWARD -p tcp -i $LAN -o ipsec+ -s 172.24.9.1 -d 172.30.50.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ipsec+ -o $DMZ1 -s 172.30.50.0/24 -d 172.24.16.0/24 -j SMB_MGMT
iptables -A FORWARD -i ipsec+ -o $DMZ1 -s 172.30.50.0/24 -d 172.24.16.0/24 -j LNX
iptables -A FORWARD -p tcp -i ipsec+ -o $DMZ1 -s 172.30.50.0/24 -d 172.24.16.0/24 --dport 1433 -j ACCEPT
iptables -A FORWARD -i ipsec+ -o $DMZ1 -s 172.30.50.0/24 -d 172.24.16.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $DMZ1 -o ipsec+ -s 172.24.16.0/24 -d 172.30.50.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT

It will be clear that reading, editing, maintaining this type of firewall is pretty hard on the brains.

• hard to read
• hard to code without syntax errors
• much much typing (or cutting & pasting)

Solutions to these problems

Some of the problems mentioned above cannot be fixed for you, just by us providing you with a firewall script. For instance, no matter how good our firewall script is, it'll never give you intimate knowledge and understanding of networking, on which to base your firewall rules. However, a good firewall script can tackle several issues for you:

• a good firewall script shows your firewall rules in a very readable form;
• a good firewall script offers structure and order;
• a good firewall script does not impose undue restrains on your ability to code the firewall, i.e. it should not be hard to code anything in the script that you could also code with your own homegrown IPtables scripts
• a good firewall script saves you coding, i.e. must need less effort to create the firewall you need than it would to create your own IPtables script.