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.
Interesting article, but I'm wondering what the benefits are of running IPCHAINS (or whatever) at init 0 as opposed to running a stripped down linux distro from read-only media or a RAM disk?
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
Yes as it is this is not very useful for general purpose filtering but, If you were to modify the kernel to output the log info to a "logging" machine and provided some known secure hooks to manage the ipchains then you would have a complete solution.
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
Hmmm.
I wonder if you could keep enough of the filesystem up to run, say, firewalling and TUX. (TUX *is* a kernel-resident www server, correct?)
If so, that's a neat possibility. Serve web pages off a machine runlevel 0 machine.
I use LEAF/LRP based routers a lot, I'm going to fiddle with one of them and see if I can't get them to run halted.
Ed R.Zahurak
You know, oblivion keeps looking better every day.
...at the ability of some to (re)discover very mundane things. Even not halted, just booting up the kernel into bash instead of init provides an excellent level of security. It's been standard (at least for some people I know and me) practice for years! We even developed a linux firewall (in beta right now) doing just that.
In my opinion, Scientology is a cult you should avoid.
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.
... can achieve almost the same thing.
man securelevel
man chflags
gd
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?
That's a tremendous waste of a computer. If that's all you're doing, you might as well use a network appliance for a firewall.
-------------------------
Stupid people suck.
The main drawback of course would be that changing iptables rules would be a painful process of rebooting and maybe 30 seconds of downtime (in an optimally configured setup).
There has to be a simple way to hack the kernel to "revive" from runlevel 0 with certain key presses locally?
If so, this would make another powerful method of running production Linux firewalls. IMPOSSIBLE to root remotely, and you can change iptables rules without downtime locally.
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!
A strange but maybe working idea would be memory that you could writeprotect. I dunno if this has been done yet but it would make servers damn hard to hack if you could specify what memory can be written and not by hardware settings. Like a separate chip thats not interfaced to the processor but sits between memory and cpu and has an own interface for settings. A chip that just blatantly says no when anything other than read are passed thru to that memory adress. It should be very hard to brake the apps that was protected. Strange idea, strange and probably silly....
HTTP/1.1 400
er... syslogd is a user space processes, and is exploitable. Holy just defeated the purpose of a halted system, Batman!
Can you say "fork bomb"? I can:
/bin/true ]
/dev/urandom > /dev/null &
coyote# while [
> do
> cat
> done
Just did this on my coyote box and it's still passing traffic and logging remotely. Here's an entry from my syslog server:
Feb 8 19:14:54 hades kernel: VM: killing process cat
Feb 8 19:15:47 hades kernel: Packet log: input DENY eth1 PROTO=17 10.34.64.1:67 255.255.255.255:68 L=328 S=0x00 I=15781 F=0x0000 T=255 (#22)
One you hit your memory limit, you aren't launching anything else.
:-)
-- I speak only for myself.
I have gotten annoyed by amount of these this configuration is impossible to root remotely posts.
I mean how do you know? Linux kernel is a piece of software too and has contained a major amount of holes. You can never know whether it would be possible to break in to the host using some remote exploitable vulnerability in kernel, the chances are just small.
Even worse, if somebody manages to break in, you have no log information what so ever that would help you to notice what happened.