Run Your Firewall Halted for Extra Security

n8willis writes: "There's a great article over at the SysAdmin magazine site that presents a unique approach to improving network security: run your firewall in a halted state. This means runlevel 0; no processes running and no disks mounted, but with packet filtering still on. The author heard a rumor of this capability in the 2.0 series kernels, and he's managed to get it working in 2.2 as well."

Comments

...and? We do this all the time

[TicTacTux]

See floppyfw. Does not even *need* a HD to boot. Floppies can be write-protected. Even an old 486 will do that trick.

Amazing what queer pranks people invent in place of a rather obvious solution...

Re:Er, aren't there better ways to do this?

[Junta]

Of course mounting drives read-only, operating out of a ramdisk is still not as secure as this approach if you can afford a very static set of firewall rules.

In this state, the system is incapable of even offering a shell without a full reboot. Once you give it the ability to offer a running process to hijack and potentially have a shell open, the read-only mount only lasts until the equivalent of mount -o remount rw is executed, and then all bets are off. Same of a ramdisk (unless the ramdisk has no ide driver or whatever). But in any case a danger in having it so that you can change firewalling rules is that if they get in, *they* can change rules too.... So, at least in theory, a halted firewall is more secure than even the most anal tactics along the lines you describe. Of course, the chances of an exploit being so severe as to offer root shell is remote, but you can never be too paranoid in some cases.

All this being said, if you have a system dedicated to firewalling by itself, and you are worth your salt as a network administrator, setting up a tight firewall is child's play. If it is coming down the input chain and it is not coming from a specific address range over the correct interface, drop. Maybe allow ssh if you critically need remote admin capabilities, but if something goes wrong with your firewall, you probably need to be there in person anyway.

And if someone untrusted can get into your network and come over the trusted interface into your firewall, well, your network has a lot more problems than a less than perfect firewall...

Re:Another interesting consept: Invisible Firewall

[douglips]

The problem with that is your LAN needs to be all on routable addresses. NAT won't work if the firewall has no IP address...

For exposed servers this would work well, not so much for the 18 Windows boxen you have Joe Salesguy using.

More Secure Solution

[davidu]

A much more secure solution would be to have a firewall with no IP addresses.

Memoirs of an Invisible Firewall

Using OpenBSD (and linux could work too) it is possible to create a bridging firewall with no IPs that simply scrubs packets as they come through the interface.

One could always add a dialup modem to the machine in case remote access was neccessary but when you have two nics neither of which have IP addresses or running services it makes a machine a whole hell of a lot more useful then a linux machine in halted mode which could EASILY run into weird memory/timing issues. (which the author didn't bring up)

-davidu

SunScreen...

[Psarchasm]

SunScreen has been doing this for quite some time.

Read about it here

Re:Logging?

[doorbot.com]

Bit of a shame if you want to log any attacks
on the firewall though.

If you can get this to work with IPFilter/PF you could use the "dup to" method to send the packet out a third NIC to a packet logging machine. Now you can have a transparent firewall, which is not accessible at all, but you can still have some logging features. One possible design for this would be two SBCs in a 1U case... one is the "halted" firewall and the other is the logging machine.

I don't know if this is possible with NetFilter or IPChains, however.

Correction

[mmurray]

Hi all...

As the author of the article being discussed, I wanted to point out one of my own errors. I discussed the lack of swap-space as a limitation to the setup; however, the linux kernel isn't pageable, so swap space would have no effect on the performance of the firewalling code.

I've had a few people point that out, so I wanted to post that correction publically.

Feel free to email me at mmurray@ncircle.com if you have questions or commments... :)

Mike

Use hardware remote access

[ErikTheRed]

Frankly, with all of the discussion centered around administering a machine that's at runlevel 0 or fully stealthed with no IPs, etc., I'm surprised that no one (so far) has mentioned hardware-based remote access products such as Compaq's Remote Insight boards (many other server vendors have similar products).

For ~$500 you get a board that replaces your keyboard, mouse, and video controllers, has its own built-in ethernet adapter (that is invisible to the rest of the computer - it's dedicated to remote access) and an SSL-secured web server. You can completely control the machine via a java applet. You can even cold-boot it if it's in a hung state (and, of course, view any errors on the screen while the machine's in a hung state). Other features include a virtual floppy drive that allows you to copy data to and from the machine (you can even boot off of the virtual floppy). There's plenty of additional coolness; the only downside is that Compaq cards only work in Compaq Proliant servers, HP cards only work in HP servers, etc...

Swap

[srichman]

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.

Kernel memory doesn't swap in Linux. So, even if you could have swap space in a halted firewall box, it wouldn't be used at all