Slashdot Mirror
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."
I used to run my ipfwadm firewall kind of like this. I replaced INIT with an ipfwadm replacement I wrote that read ipf style rules from a config file and applied them to the kernel chains, then suspended. This was all on a ramdisk. It worked pretty well, although the ramdisk had to be replaced to change rules, which was kind of inconvenient.
We were offering a linux-firewall, VPN solution to a hospital and turns out one of the machines we sent out had a bad token ring card, that mixed with an obscure bug in the Token ring driver, (Which has since been fixed) it would cause linux to die quite often. To the point where the computer would accept no keyboard input, would cease logging, and for all intents and purposes was a dead box. Yet the machine continued to route traffic and continued to function as a VPN.
Any listening ports were ignored, but the routing still took place. I never thought of it as a way to make the router more secure, but I guess in that way it makes since. It would really suck to have to completely shutdown everything to have to malke routing changes though, so I'm not sure this is the best solution for high availability router use.
Do you Gentoo!?
This is a very interesting idea.
It only works with firewalling that's inside the kernel - packet filtering and NAT. But what if kernel modules were added to handle some of the features now run in user space?
Indeed, what if kernel modules were added to handle non-firewalling tasks instead? Could a kernel module provide a useful network service? You start the machine up, it loads the kernel and "halts" but still provides the service. Something goes wrong? Just power cycle; there's no disk access, no way for an attack or malfunction to make a persistant alteration in the machine.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
This is kind of ridiculous because it requres you to take the whole firewall down to make rule changes. Why not just blackhole all packets with the firewall's interface addresses as destination, and leave a local serial console with password authentication and idled running?
Alternately, this is kind-of a solution for embedded firewalls or something.. maybe for tiny flash-card bootable network probes (remember firewalls are routers and can be made to do nasty things too) that you boot and then eject the flash media...
--- Nothing clever here: move along now...
At home, I run two servers - one inside the firewall with NFS services and so on, and the firewall itself, which is a self-sufficient machine except during boot, where it netboots from the NFS server. After that point, its two NICs are only used for routing packets. All administration takes place through the serial port, which init respawns /bin/sh onto. The system runs off of a ramdisk loaded during the netboot. I've found this to be a nice solution, and it rules out any possibility of breach since the machine is only accessible through a serial port hardwired to the server - ethernet interfaces are configured to only route packets.
The LinkSys DSL Routers, while nice, are not perfect solutions. I run one on the inside of my network, and I've noticed that it passes along packets that I have not explicitly told it to pass. One of the features that doesn't seem to be touted these days is that it "senses" specific types of packets and "intelligently" allows them through. The trouble with this is that the router is not doing stateful packet inspection - it's just guessing based on port number. Not a *huge* deal for most people, but I most certainly would not trust such a system to be my primary border defense.
Cheap and easy, but not as good as the real thing. When it comes to security, I'd rather have a locked-down debian box that I built from source than a piece of plastic that I bought at Staples.
We who were living are now dying
With a little patience
There have been some great comments to this article (which I haven't read) but I got to wondering: if you're going to run in a sort of comatose state where your only ability to change the system is to reboot it, why bother booting in the first place?
My idea was to use the Linix BIOS or something similar, and run your packet filtering from there. Then you can forget the hard drive and floppy (though you'd probably want that floppy to be able to flash your BIOS with updates and the like.)
Does this make sense to anyone? Or is there something I'm overlooking like maybe that while running as a BIOS, Linux wouldn't be able to talk to the network interfaces, say?
I guess if you're going to go to that kind of trouble, you might as well have an embedded system, or run from flash RAM, as others have mentioned. Still, it's always fun to get hardware and software to do things beyond what they were designed to do.
This is roughly equivalent to a briding firewall with no assigned IP address. No one can ever connect remotely.
A bridging firewall as the advantage of still being administrable from the local console.
{{.sig}}
If you're seriously paranoid about it, get an old dot-matrix printer and hook it up as the logging output device. You'll have a logging device that nobody could alter no matter how compromised the system gets, without having to mount anything read-write.
Tomorrow will be cancelled due to lack of interest
Dang, why stop there, write something in ASM and flash it right on the bios. Wasn't there a linux bios project awhile back? :) I wonder how much progress they've made.
I had my firewall's IDE controller go up in smoke, but the Linux kept chuggin' along. I couldn't log in or do anthing to the box, and the display was full of errors, but it still was routing for the rest of the network. now that was security.
---
I post links to stuff here
As the article points out, the kernel continues to run when halted, so the first part of the solution is to signal the kernel to transition out of run-level 0 in a safe way. There used to be ISA cards for debugging that had a push-button at the end of a cable; when pushed, an interrupt was triggered to invoke the debugger. I can't see any reason why the Linux kernel couldn't be patched to watch for that interrupt while halted and restart the boot process, say from the point where a boot disk is mounted. The second step would be to modify the init.d scripts affecting the IP stack to abort if the NICs are already configured.
The end result would be a firewall with a button that, when pressed, would cause the system to "wake up" and allow configuration changes to be made. When you're all done, just do another "init 0". To guard against forgetful netadmins, you may want a watchdog process that also does an "init 0" fifteen minutes after the system comes up.
I can't see any show stoppers to this idea. What do you think?
Nothing for 6-digit uids?
Tom Limoncelli presented a paper on this exact subject a few years ago. It's entitled Tricks You Can Do If Your Firewall Is a Bridge and covers a number of useful things you can do with bridging firewalls.
--Phil (My firewall is just an OpenBSD box. I like it that way.)
355/113 -- Not the famous irrational number PI, but an incredible simulation!