Mirrored from http://www.samag.com/documents/s=1824/sam0201d/0201d.htm

Halted Firewalls

Mike Murray

As systems administrators, its often funny how new and interesting
information ends up in our hands. Sometimes, its through an intentional
course of study; other times, it seems to arrive by accident. Thats
exactly how the concept of using a halted Linux computer as a firewall
occurred to me. I was at work, perusing an internal corporate mailing
list and saw a message about something that was once present in Linux.
The message referred to a method for shutting down a Linux box while
ipchains is still running, and having the box continue to perform
firewall tasks. My first response was to stifle a laugh a firewall that
works while in a halted state? I contacted the author (with a bit too
much sarcasm in my letter), and was sent a link to an old discussion
thread on the Firewalls list about a rumored feature in the 2.0.x
kernels. This feature allowed you to run shutdown -h (halt) on the
machine, and the firewall would remain active but with no drives mounted
and no processes running. That is, the firewall would be in run level 0,
but still be filtering packets. However, the list mentioned that this no
longer worked in the 2.2.x series kernels.

I knew that I couldnt leave it alone, however. I set out to make a 2.2.x
box perform a similar function, and I hoped that I would be able to do
it without having to patch the kernel in any way. It turns out that I
can.

Perfect Security?

I realized the security implications of such a possibility. Assuming
that the firewall could be cleanly shut down, having removed all process
space and file systems, there would be no way for any attacker to gain
access to the system. This is because there is a complete lack of
process space, and there are no drives mounted. Thus, an attacker could
not run code on the system outside of code that he or she could directly
introduce into kernel space. This would require writing shell code to
produce the desired results, which would not be a trivial task.

Note that this doesnt make the firewall invulnerable to denial of
service-type attacks. In fact, with respect to denial of service and
resource-exhaustion attacks, this machine is no more secure than any
ordinary Linux-based firewall. However, it can also be said that it is
not significantly more vulnerable to that type of attacks.

Because this method does ensure that no user will ever gain controlling
access to the firewall itself, there is definitely a huge security
benefit. Its a step in the direction of the old adage that the only
perfectly secure machine is one turned off and locked in a room.

Implementation

My test machine was an x86-based Red Hat 6.2 machine with two Ethernet
cards. No special system or kernel modifications were made. To begin, I
searched the run control scripts, thinking they would be the most likely
place to find a hint of what was to come. Specifically, I focused upon
the scripts for rc0 (the script that runs when halting the machine). It
turns out that this was all I had to do. I started removing scripts,
working entirely by trial-and-error.

After a relatively short period of time, I concluded that for Red Hat
Linux 6.2, removing the following scripts will allow this behavior to
occur:

/etc/rc.d/rc0.d/S00killall
/etc/rc.d/rc0.d/K90network
/etc/rc.d/rc0.d/K92ipchains

Removing these three scripts keeps the network up, and keeps ipchains
running. Note that removal of the killall script is necessary because
its task is to recurse through the /etc/rc.d/rc0.d/ directory and run
all scripts that start with a K. This script would run the K90 network
and K92 ipchains scripts, which would kill the network and ipchains.

Explanation

The design of Linux is as a monolithic kernel. When the machine is
halted, the kernel still resides in memory, even when the machine runs
through the shutdown process. The usual method to prevent this from
being evident is to kill all possible access to the kernel during the
shutdown process, which is accomplished by killing all running
processes, shutting down all of the machines network interfaces, and
unmounting the filesystems. This prevents the kernel from performing any
intentional tasks while the machine is halted. However, the kernel is
still running as a scheduler and memory manager at that point.

Because the kernel is still running, any kernel-based tasks that we can
run in normal use can be run while halted. Of course, most tasks require
some form of input and output, either through the shell (user input),
the file system, or the network (as in this case). Thus, we must force
the machine to allow that interface to continue to exist even while the
machine is halted. This is the effect of removing the K90network script.
It no longer forces the Ethernet cards to be stopped.

Additionally, any kernel-based services that are required (e.g.,
ipchains) must be kept running. The default behavior of the system is to
flush all ipchains rules when the machine is halted. If that happens,
the firewall wont be working at this point, so the machine must be
forced to leave the ipchains ruleset in place by removing the script
that would flush all the rules.

Limitations

Given that only utilities that run in kernel space will be left intact
upon halt, the major limitation for this task is that any type of IP
addressing that requires a user-space daemon (e.g., PPP, DHCP) to run
will be unable to function in this case. This places a limit upon the
usefulness of using this on most dynamic connections. Similarly, any
sort of user-space proxy server (e.g., Socks5) will be killed on halt.
Thus, only packet filtering and NAT are possible with this setup.

The other consideration is that with drives unmounted, all swap space is
removed from the machine. This shouldnt be difficult in a machine that
is handling even large amounts of traffic, given sufficient amounts of
memory. However, in an older machine with fewer resources, it is
possible to experience performance issues with extremely large amounts
of traffic.

Conclusions

This discovery seems interesting as an exercise, at the very least. It
gives us a model for improved security in machines that are dedicated to
a specific task. I am curious to see whether this type of experiment is
possible in other free Unixes (especially OpenBSD, given kernel space
IPSec and pppoe). And, while there is limited application for home use,
it seems that this type of firewall could be used in small to mid-size
business applications to provide extremely secure packet-filtering
ability. Or, perhaps this could be used to create a very secure and very
high-bandwidth firewall/router for larger business tasks.

Mike Murray is an expatriate Canadian who works as a Scientific
Technologist for nCircle Network Security, where he has performed
various tasks in the areas of systems administration, network security,
and development. He is a graduate of the University of Toronto with a
degree in Philosophy. He can be reached at: mmurray@ncircle.com.