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."
This solution is more secure than a floppy would be. Write-access to the flopy can be forbidden, but all the other processes and security holes remain as possible targets.
Switch back to Slashdot's D1 system.
Bit of a shame if you want to log any attacks
on the firewall though.
With no disks mounted where can you log it to?
#exclude <ms/windows.h>
The most interesting thing I see with this is why?
It can't be managed. It can't be monitored. It can't be logged.
This may be fine as a novelty, but running a network secured with such a hack is silly.
Let's talk about shutting down all userspace processes on a box except syslog and snort and I say you've got an interesting box.
OTW - it seems just like a game.
--Adrian
This method causes the firewall to act as a bridge instead of a router. The advantage is that the firewall is not IP-addressable. To hack it, you'd have to go down to the MAC layer, which is generally only possible if you're on the same network segment.
I read the SysAdmin article a month ago and thought the same thing. The OpenBSD Invisible Firewall is a much better solution -- you can't hack it from the outside, but you can still make any changes necessary without causing downtime.
Software sucks. Open Source sucks less.
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.
I think you just reinvented the embedded system.
Why? That whole system runs in runlevel 0. No user accounts, no login, no getty, no daemons - just the bare kernel plus an open console.
Disadvantage: You must employ your weary bones and walk over to do some maintenance...
Use The Source, Luke!
Who says the firewall and the nat have to be the same box? Just because this is usually one device doesn't mean it must always be that way
If your data needs that much security, you shouldn't have it connected to the internet in the first place.
Aren't we forgetting the most important security feature of a firewall...? There's no logging! This is fly by the seat of your pants security if you ask me. You gonna hang a lucky rabbit's foot over the thing?
Or one could use the MagicSys keys built into the kernel and simply use a standard keyboard :)
int func(int a);
func((b += 3, b));
Y'all know that a halt() call that specifies a non-powerdown halt is basically a no-op, right? I mean, it does check that you're running as root, but then it does nothing:
From linux-2.4.14/arch/i386/kernel/process.c
void machine_halt(void)
{
}
(the machine_power_off routine also does nothing unless there is a poweroff function enabled; since, the halt isn't actually doing a poweroff (or it won't be doing a good job of routing after that) it presumably isn't set).
All that's being done by the process desc ribed in the article is a) bring down all running services except for the network; b) make init wait to die (I haven't looked at init to see if it waits for a normal ctrl-alt-del interrupt, then do a reboot, or if it just sets the kernel to handle ctl-alt-del and reboot all by itself). It doesn't even kill all other running processes that might be running, just the ones that were started by init (e.g. getty) and processes that remain in those process groups. If someone starts up a background job, it will still be there. There's nothing magic about run level 0 - it is just a convention that init uses.
Not all drives are unmounted - the root device will still be mounted read-only, maybe /proc and other pseudo-file systems will still be there. init is still running. This is a lower level of security than starting the kernel up by running a shell script that enables the network and ipchains, then sleeps forever. You could even have that shell script leave you in a plain old shell if you want to do be able to do something else (you'd have to know how to mount filesystems and remember to unmount them (since init won't be running, you can't just do a simple "shutdown" anymore), etc).
Here's an example script that might be used. Start it by passing "init=/netstart" (or wherever you put the script) to the kernel when you reboot:
/proc -t proc /usr
/etc/rc.d/init.d/network start
/etc/rc.d/init.d/ipchains start /usr /bin/sh
#!/bin/sh
mount proc
mount -o ro
umount
exec
If there's a hole in the TCP stack itself, or in the IPchains routing, that opens up some vulnerability, it doesn't really matter if there's a simple /bin/sh running or not (if you really want to be secure, have the shell script exec a simple C program that checks to make sure it is PID 1; does a kill(-1, SIGKILL) and then sigsuspend() in a loop; now you're safe unless someone's hacked your kernel, libc or compiler).
I note that in 2.2, if process 1 exits, it kills the kernel; in 2.4, it gives a "Kernel panic: Attempted to kill init!". In either case, the effect is the same: ctrl-alt-del is disabled, and the kernel stops routing packets.