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."
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.
You mean the part where he mentions the need to edit the rc0.d scripts, to stop killall, network, and ipchains from running? So that the needed services survive the shutdown?
It's not a case of ust configuring your firewall, and running shutdown -now. Some tweaking is definitly required. But it's an interesting idea....
The teklling part is that the target of the article is a 2.2 kernel with IPChains. I'd be much more interested in knowing if this is possible with a 2.4 kernel and IPTables....
Brian Greenberg
This is shit, the kernel itself is not swapable, never ever is going to be any part of a monolithic kernel in swap, at least without it being a little less monolithic.
And by the way you don't need huge amounts of ram to route traffic, with 16Mb you have almost enougth to route a satellite link (high speed pipe, very high latency), and I'm pretty sure you can route with only 4 megs (and a 386sx12), been there, done that.
The rest it's ok, and true, but I managed to know it by watching a crashed kernel route & NAT a network (it was a 2.3.x dev. version).
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.
LinuxBIOS is a full linux kernel, just loaded from flash ram. You're still running an OS.
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.
the read-only mount only lasts until the equivalent of mount -o remount rw is executed,
/etc is noexec BTW).
My home firewall has a read-only root which you cannot remount read-write because the filesystem doesn't support read-write and is compressed (cramfs). The config is on a read-only fs which I remount rw when needed. System updates are a bit more difficult, but at least I cannot have a binary replaced with a rootkit. (forgot to say that
Willy
If the attacker has root, she can just mmap /dev/kmem and remove the module forcibly.
and probably others as well.
If that's your goal, and you don't mind hacking the kernel a bit to accomplish the trick - why not use the ATX soft power? It wouldn't require a specialized debugging isa card, just an ATX board and power supply.
If you're interested in this, also see FreeBSD's kern.securelevel facility. From the init(8) manpage:
/dev/mem, and
/dev/kmem may not be opened for writing; kernel modules (see
The kernel runs with four different levels of security. Any super-user
process can raise the security level, but no process can lower it. The
security levels are:
-1 Permanently insecure mode - always run the system in level 0 mode.
This is the default initial value.
0 Insecure mode - immutable and append-only flags may be turned off.
All devices may be read or written subject to their permissions.
1 Secure mode - the system immutable and system append-only flags may
not be turned off; disks for mounted filesystems,
kld(4)) may not be loaded or unloaded.
2 Highly secure mode - same as secure mode, plus disks may not be
opened for writing (except by mount(2)) whether mounted or not.
This level precludes tampering with filesystems by unmounting them,
but also inhibits running newfs(8) while the system is multi-user.
In addition, kernel time changes are restricted to less than or
equal to one second. Attempts to change the time by more than this
will log the message ``Time adjustment clamped to +1 second''.
3 Network secure mode - same as highly secure mode, plus IP packet
filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and
dummynet(4) configuration cannot be adjusted.
If the security level is initially nonzero, then init leaves it
unchanged. Otherwise, init raises the level to 1 before going multi-user
for the first time. Since the level can not be reduced, it will be at
least 1 for subsequent operation, even on return to single-user. If a
level higher than 1 is desired while running multi-user, it can be set
before going multi-user, e.g., by the startup script rc(8), using
sysctl(8) to set the ``kern.securelevel'' variable to the required secu
rity level.
No, it's still needed. By itself, the kernel can only log to its ring buffer in memory. To send kernel messages to a remote syslog server, you need klogd to grab them and send them to syslogd, which sends them to the remote server.
It's probably possible to add this functionality to the kernel, but it's not there now.
$ find
well if you knew Linux's packet filtering (iptables(8)) you would know it's all kernel level and doesn't require a running process. the kernel doesn't even use up a PID like kjournald or keventd for the filtering. going into a halted state makes sure your firewall isn't doing anything else (like sshd or ftpd) that would compromise security, but of course you couldn't change anything without rebooting.