As systems administrators, it's often funny how new and interesting
information ends up in our hands. Sometimes, it's through an
intentional course of study; other times, it seems to arrive by
accident. That's 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 couldn't 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.
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 doesn't 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
Because this method does ensure that no user will ever gain controlling
access to the firewall itself, there is definitely a huge security
benefit. It's a step in the direction of the old adage that
the only perfectly secure machine is one turned off and locked in
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:
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
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 machine's 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 won't 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.
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 shouldn't 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.
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.
Fi rewalls Discussion thread (archived on SecurityPortal):
Mike Murray is an expatriot 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: firstname.lastname@example.org.