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."
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...
Use The Source, Luke!
Difference is, even with read only media, an intruder can still do what he wants in memory (although rebooting will wipe it clean). With this, there is nothing running but the kernel and kernel memory... not even a ramdisk to fiddle with.
IPF can run in stealth mode. In this mode a packets TTL isn't decreased when the packet traverses the firewall. It is invisible to the netork at large.
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...
XML is like violence. If it doesn't solve the problem, use more.
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.
My amazing wife - Artist, Author, Philosopher - Laurie M
-davidu
# Hack the planet, it's important.
ipchains isn't running. it's used before the halt to set the rules, and those rules simply aren't cleared out when the system switches to halted mode. but to make changes you'd need to run ipchains again, which would be another process, which can't happen with this configuration.
SunScreen has been doing this for quite some time.
Read about it here
http://windows.scares.us
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.
no need for it. the fw is acting as a *client* for syslog. syslog would be running on the log server.
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
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...
Help save the critically endangered Blue Iguana
Or just run "lcap CAP_SYS_ADMIN" to drop mount /proc/kmem. There are more things you can remove from the kernel capabilities bounding set to lock your system down.
capability. Unfortunately, you drop a bunch of other capabilities too. While you're at it, run "lcap CAP_SYS_BOOT" to prevent reboots, and "lcap CAP_LINUX_IMMUTABLE" to prevent those immutable and append-only attributes from getting changes, "lcap CAP_SYS_MODULE" to lock your modules in place, and prevent further loading, and "lcap CAP_SYS_RAWIO" to close down
Of course, by the time you're done, your system is about as easy to administer as if it were halted. Not to mention log rotation requiring a reboot.
The living have better things to do than to continue hating the dead.