tion address, protocol, and (Web hosting domains) interface to be used
tion address, protocol, and interface to be used for the test. Other arguments, such as port numbers or TOS bit settings, are optional. 4. Execute each test command and note the output. The output of each test will be a single word indicating the final target of the datagram after running it through the firewall configuration — that is, where the processing ended. For ipchains and iptables, user-specified chains will be tested in addition to the built-in ones. 5. Compare the output of each test against the desired result. If there are any discrepancies, you will need to analyse your ruleset to determine where you’ve made the error. If you’ve written your test commands into a script file, you can easily rerun the test after correcting any errors in your firewall configuration. It’s a good practice to flush your rulesets completely and rebuild them from scratch, rather than to make changes dynamically. This helps ensure that the active configuration you are testing actually reflects the set of commands in your configuration script. Let’s take a quick look at what a manual test transcript would look like for our na ve example with ipchains. You will remember that our local network in the example was 172.16.1.0 with a netmask of 255.255.255.0, and we were to allow TCP connections out to web servers on the net. Nothing else was to pass our forward chain. Start with a transmission that we know should work, a connection from a local host to a web server outside: # ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 accepted Note the arguments had to be supplied and the way they’ve been used to describe a datagram. The output of the command indicates that that the datagram was accepted for forwarding, which is what we hoped for. Now try another test, this time with a source address that doesn’t belong to our network. This one should be denied: # ipchains -C forward -p tcp -s 172.16.2.0 1025 -d 44.136.8.2 80 -i eth0 denied Try some more tests, this time with the same details as the first test, but with different protocols. These should be denied, too: # ipchains -C forward -p udp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied # ipchains -C forward -p icmp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied Try another destination port, again expecting it to be denied: # ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 23 -i eth0 denied You’ll go a long way toward achieving peace of mind if you design a series of exhaustive tests. While this can sometimes be as difficult as designing the firewall configuration, it’s also the best way of knowing that your design is providing the security you expect of it. A Sample Firewall Configuration We’ve discussed the fundamentals of firewall configuration. Let’s now look at what a firewall configuration might actually look like. The configuration in this example has been designed to be easily extended and customized. We’ve provided three versions. The first version is implemented using the ipfwadm command (or the ipfwadm-wrapper script), the second uses ipchains, and the third uses iptables. The example doesn’t attempt to exploit user-defined chains, but it will show you the similarities and differences between the old and new firewall configuration tool syntaxes: