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.