Using SuSE Linux 9.1 as a network firewall

NB - this page is an updated version of a page that is buried in the e-nor archive - I have added it here because it has a lot of historical signifance for, and similarities to, the next page about using SuSE Linux 11.4 as a network firewall.

SuSE linux Personal 9.1 is designed as a replacement for the normal Microsoft Windows operating system, so hasn`t really been designed as a basis for server or network functions.

It is therefore very GUI orientated, with the firewall configuration being done via YAST using a tool called SuSEfirewall2. This allows for the setting up of various parts of the Linux firewall engine, but doesn`t allow the individualised rule control which is required for a proper network firewall.

So it is neccessary to remove any firewall configuration produced by SuSEfirewall2, then use iptables to produce the rule set we actually want to use. Iptables v1.2.9 is included in the installation of SuSE Linux Personal 9.1, the binary lives in /usr/sbin/, along with iptables-restore and iptables-save.

IPv6 versions live in the same place.

When the Linux firewall engine is enabled via SuSEfirewall2 via YAST, then two things happen :-

a rule set is created for use by the kernel - this rule set can be viewed by using "iptables -L" at the command line
entries are added to the boot up sequence directories contained in /etc/init.d/

Note that in SuSE Linux Personal 9.1, the boot up sequence directories are in /etc/init.d, not in /etc/rc.d/. The directory /etc/rc.d/ still exists, but is just a link to the real directory /etc/init.d/

The SuSEfirewall2 initialisation files are placed in /etc/init.d/rc3.d, /etc/init.d/rc4.d, and /etc/init.d/rc5.d, so that the firewall is operational for run levels 3, 4, and 5.

The conversion process

As well as removing the effects of SuSEFirewall2, and using iptables to configure the kernel firewall engine, there are other changes that can be made which make SuSE Linux more suitable for use as a network firewall -

changing the run level so that we don`t have the GUI cluttering up linux
getting rid of the splash screen during bootup, so that we see what is happening during boot up

Removing SuSEfirewall2

The easiest way to remove both of the above effects of SuSEfirewall2 is to use YAST. On the GUI,

select YAST
select the "Security and users" icon
select "Firewall"
on the first page, select "Stop Firewall and remove from Boot Process"

If this first page doesn`t appear, go through the process of configuring SuSEfirewall2 by successively clicking on "Next" then "Continue", then repeat the above sequence.

YAST has now entirely disabled any configuration of the kernel firewall engine by SuSEfirewall2, as it has removed the SuSEfirewall2 initilisation files from /etc/init/rc3.d, /etc/init.d/rc4.d and /etc/init.d/rc5.d, so nothing loads during boot up

It has also put in a minimal default ruleset of "Accept" on the default chains - which is something we definitely don`t want, as the computer is now wide open.

So don`t do the above until you are ready to do the next bits.

Using iptables to configure the firewall

Some time previous to this modification of SuSE Linux 9.1, I had written a bash shell script which utilised iptables to create a ruleset for use by the kernel in an installation of Red Hat Linux 9.

This same script was imported into SuSE Linux, and saved in /ipt/, and run from there. The rule set is loaded into kernel space, and is available for the kernel to use.

However two problems emerge :

after a reboot the rule set is lost
ip forwarding is by default disabled

So we have to do some configuration of SuSE Linux.

Setting up a storage location

Because we are going to be running SuSE Linux without a full iptables initialisation script, we have to create a storage location for the rule set, so that the rule set can be recovered during the bootup process.

Red Hat used /etc/sysconfig/iptables, so that seems good enough for SuSE Linux as well.

We need to create this manually as an empty file, I used Vi as root, but any method will do, as long as iptables can write to it and read from it.

After manually running the shell script, the rule set is in kernel space, and stays there until a reboot.

So after running the shell script, use the iptables-save command to extract the rule set from kernel space, and push it in to our storage location in user space, by using redirection of the standard output :-

        iptables-save > /etc/sysconfig/iptables

That has the rule set saved, for later restoration after a reboot or switch on.

If a new version of the shell script is produced, this process has to be repeated.

Setting up a configuration script

Browsing through the various initialisation scripts, it appeared that the best place to put an initial script for the firewall is in /etc/init.d/boot.local

Note that SuSE Linux Personal 9.1 has a directory /etc/init.d/boot.d/ as well as the normal start up directories /etc/init.d/rc0.d/ through to /etc/init.d/rc6.d/

The link files in this directory are run before the link files in the main initialisation link files in /etc/init.d/rc3.d/, etc, so form a pre-initialisation phase of the whole linux bootup process.

One of the strong advantages of initialising the firewall from this pre-initialisation phase is that the firewall rule set is in place before the network cards are enabled in the later initialisation phase, so we avoid the risk of a period of time when the linux box is wide open to attack.

As an aside, during shutdown, I think we should also be okay, as the network cards are disabled as part of the shutdown process, but the kernel will still be seeing the firewall ruleset.

The script that we put into /etc/init.d/boot.local is required to enable ip forwarding, and to restore the ruleset to kernel space.

The first one is easily done by redirecting standard output from the echo command, and so forcing a character change in the file /proc/sys/net/ipv4/ip_forward - the relevant line in the script is -

       echo "1" > /proc/sys/net/ipv4/ip_forward

The second one also requires redirection - because we are running without a full iptables initialisation script, the iptables-restore command doesn`t have a location to recover data from.

We therefore have to redirect the standard input of this command to the location we have created.

The relevant line in the script is therefore -

        iptables-restore < /etc/sysconfig/iptables

This line recovers the stored ruleset and pushes it into kernel space for the kernel to use.

The whole script that I am currently using is as follows - it includes some echo statements so that you can see it happening during the boot up process ( provided you inhibit the splash screens ).

       echo "  ."

       echo "  ."

       echo "  Check that ip forwarding is not enabled"

       echo "0" > /proc/sys/net/ipv4/ip_forward

       echo "  ."

       echo "  ."

       echo "  Restore the firewall ruleset to kernel space"

       iptables-restore < /etc/sysconfig/iptables

       echo "  ."

       echo "  ."

       echo "  Enable ip forwarding through the firewall"

       echo "1" > /proc/sys/net/ipv4/ip_forward

       echo "  ."

       echo "  ."

       echo "  Firewall is configured"

       echo "  ."

       echo "  ."

With the inclusion of this script, we now have a working network firewall, but there is some tidying up we can do, to optimise the performance of SuSE Linux as a network firewall, rather than as a user workstation.

Removing the splash screen

The splash screen that SuSE put on hides the reporting of the boot up process - there are several advantages in being able to see this reporting, including :-

we can see the implementation of the above script
we get a specific reference to which network card is eth0 and which is eth1.

If you configure the network cards through YAST, then you don`t have this information, as YAST refers to them as eth-id-xx:xx:xx:xx:xx, where of course the series of x`s is the MAC address of the card.

You don`t get this information either from the files where the configuration data is stored in /etc/sysconfig/network/. The two files are called ifcfg-eth-id-xx:xx:xx:xx:xx:xx.

The only place that I have found that specifically uses the device names of eth0 and eth1 is in the reporting of the initilisation of the network cards during bootup.

To inhibit the splash screen, open /etc/sysconfig/bootsplash in a text editor, and change the last line from "yes" to "no".

Removing the GUI

The GUI can be removed by changing the default run level from run level 5 to run level 3.

Open the file /etc/inittab in a text editor, and change the line

        id:5:initdefault:

so that it reads

        id:3:initdefault:

Note that SuSE Linux suffers from the same problem that Red Hat Linux 9 suffers from - if you alternate between run level 3 and run level 5 by using the command line instruction "init 3" or "init 5" several times, then eventually the GUI becomes corrupt, it won`t load, and linux hangs.

Finally

At the present time, all I can add is that it works, SuSE Linux Personal 9.1 can be set up to act as a network firewall. Whether it is better than using Red Hat Linux 9, I can`t at present say.

website design by ron-t

website hosting by freevirtualservers.com

+ +