Hello, http://www.drdobbs.com/halted-firewalls/199101324
What do you think of it? :) any similar feature in OpenBSD? :D copied the short text: ========================================================= Halted Firewalls By Mike Murray, January 08, 2002 Murray shows how to configure a Linux box so the firewall will continue to filter packets after the machine has been shut down. Halted Firewalls Mike Murray 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. 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 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 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. It’s 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 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. 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 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. 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: mmur...@ncircle.com. =========================================================
