Update to using Red Hat Linux 9 as a network firewall

Introduction to this webpage

This web page is an update to the previous one, about using Red Hat Linux as a firewall.

It has sections on

An improved way of booting up the firewall
Better correlation between the kernel view and the user view of the ruleset
More ports opened, with source address filtering
An updated script

If you haven`t read the first page, this page will not make much sense.

Booting up the firewall

In the first web page, I described three ways of starting up the firewall - and only one of them really worked.

There is however now a better way - we remove the requirement to enable ip forwarding from the firewall shell script and do it via another Linux configuration file, /etc/sysctl.conf

This file contains a line which sets the default condition that the ip packet forwarding is not enabled. We change that, so the default condition is for ip packet forwarding to be enabled.

Open /etc/sysctl.conf in Vi, and look for the line

      net.ipv4.ip_forward = 0

Change it to

      net.ipv4.ip_forward = 1

We now don`t need it in the shell script. The script included at the bottom of this page now doesn`t enable ip packet forwarding.

We also now don`t need to, and definitely don`t want to, run the script from the /etc/rc.d/rc.local initialisation script.

Instead, run the script manually from the command line, and then use the command line instruction

      service iptables save

This saves the ruleset into the iptables configuration file /etc/sysconfig/iptables.

At start-up, the iptables initialisation script in /etc/rc.d/init.d restores the ruleset from this file.

The iptables initialisation script runs before the network initialisation script, so by the time the network cards have been enabled, the iptables ruleset is in place, and we have now eliminated any period of time during the start-up process when the firewall is open to attack.

The ruleset - kernel view v user view

Having started down the road of using the iptables configuration file /etc/sysconfig/iptables instead of running the shell script at boot-up time, I noted that there are considerable differences in the way the configuration file stores the ruleset and the way they are listed in the shell script.

And more than that, the kernel stores the ruleset in a different way again.

So the shell script has been substantially rearranged, so that the user view of the ruleset more closely matches the kernel view of the rule set.

This rearrangement revealed that the order of the rules in the ruleset was somewhat inefficient, packets that are definitely not wanted were travelling quite far through the ruleset before getting dropped. This wastes resources.

So a bit more rule shuffling was done, one or two rules were dropped, and one or two were added.

Now packets that are definitely not wanted are dropped right at the head of the filter table ruleset.

The nat table rules have been seperated out from the filter table rules, and now head the ruleset, as they do in the kernel view.

Additional rules

Some specific business requirements have resulted in more ports having to be opened.

NetBIOS

The first one is NetBIOS - this is very bad news, as NetBIOS is famously insecure, and is regularily used as a mechanism to attack computers.

Fortunately, the specific requirement in this case is for workstations behind the firewall to use NetBIOS to talk to a specific server outside the firewall - so it is possible to specify a particular IP address as the source of incoming packets.

This doesn`t guarantee security, as attackers can spoof the source ip address - but it will slow them down a bit. And they still have to negotiate the stateful packet filtering, which adds another layer of protection.

Remote Desktop

The second one is Microsoft Windows XP Remote Desktop facility.

Again, this opens up a known hole in the protection given by the firewall.

Fortunately, the requirement here is for one or two workstations to act as the client, and to control a specific computer outside the firewall.

So the clients inside the firewall are not themselves opened up, and they initiate the connections with the external computer through the firewall, so stateful packet filtering can still be employed.

Additionally, since the external target for remote control is one specific computer, the source ip address on incoming packets can be used within the ruleset as an extra layer of protection. However the former comment about spoofing applies again.

Finally ...

Here is the firewall script - version 17c - as before, it is a bash shell script, not an html page, and was written using Vi. It should be possible to download it from here as a shell script through your browser. Some browsers actually manage to display it as a web page.

And remember, this script does not enable ip packet forwarding, this has to be done elsewhere.

Return to the Firewall index page