Run Your Firewall Halted for Extra Security 390
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."
Works for me... (Score:4, Funny)
Re:Works for me... (Score:2, Funny)
...and? We do this all the time (Score:5, Informative)
See floppyfw [zelow.no]. 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...
Re:...and? We do this all the time (Score:4, Insightful)
Re:...and? We do this all the time (Score:4, Insightful)
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 hardware remote access (Score:5, Informative)
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...
Hrm, there is also SPARC (Score:3, Insightful)
The Compaq cards do have an upside, however, in that the way you describe them it seems that you can foobar the 'parent' machine and still use the card. It does use power from the parent machine, so both SPARC's OpenPrompt and this card will be null if the host machine loses power.
I really wish x86 engineers would develop something similar to a server-class BIOS implementation. Don't get me wrong, modern x86 CPUs are great, but the BIOS has got to grow up.
Re:...and? We do this all the time (Score:4, Interesting)
Re:...and? We do this all the time (Score:3, Informative)
Re:...and? We do this all the time (Score:4, Insightful)
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.
Re:...and? We do this all the time (Score:2)
Er, aren't there better ways to do this? (Score:3, Insightful)
This might be fine for a firewall whose rules never change, but if you want to actually do something to it, you can't have it halted, and rebooting will just cause downtime.
Why don't you just run with drives mounted read-only, or have everything copied to a ramdisk? Surely you can verify a rule to allow remote access from only certain locations if this is your problem, or even require serial console access.
Re:Er, aren't there better ways to do this? (Score:3)
This definitely isn't a method for everyone, it's for really paraniod, stable networks that don't change. If your network doesn't fit this description, then your way might be the next best thing.
Re:Er, aren't there better ways to do this? (Score:3, Insightful)
Re:Er, aren't there better ways to do this? (Score:5, Informative)
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...
Re:Er, aren't there better ways to do this? (Score:2)
True... unless you write a small module that, when loaded, prevents and filesystem from being mounted read-write. That, plus a boot passwd to prevent reboots insures that nothing gets changed in case of attack.
Re:Er, aren't there better ways to do this? (Score:3, Informative)
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.
Re:Er, aren't there better ways to do this? (Score:2)
Eh, slippin' straw man. (Score:2)
And in addition, as others have said, you can afford not to log it, and if---just when you think you can "afford a very static set of firewall rules"---you reboot, you can afford network downtime. This sucks.
OK, now this is a kind of straw man and slippery slope. Just because you "offer a shell", doesn't mean anyone can get it. Running a getty off the serial port isn't going to be susceptible to remote attacks. Only stuff you put on the network is a problem. And if they've got physical access, all bets are off anyway. Just because you're running processes doesn't make you vulnerable.
It isn't necessarily the case it'll be "child's play," but it will be possible. If you're not experienced, you shouldn't let this novelty solution lull you into thinking you're secure. Ask or hire someone with experience to help.
"And if you're screwed, you're screwed." Duh.
Re:Er, aren't there better ways to do this? (Score:2, Informative)
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
Re:Er, aren't there better ways to do this? (Score:2, Insightful)
nice idea but little use for most I would guess.
Re:Er, aren't there better ways to do this? (Score:2)
Re:Er, aren't there better ways to do this? (Score:2)
Re:Er, aren't there better ways to do this? (Score:2)
Re:Er, aren't there better ways to do this? (Score:2)
Replace INIT (Score:3, Interesting)
Another interesting consept: Invisible Firewall (Score:5)
In the stone age of firewalling, a firewall was a fairly complicated device that was less-than-trivial to factor into your network. It needed an IP address on it's outside, and another on the inside. This immediately created subnetting problems, forcing wasted IP allocation and overall disquietude amongst the cognoscenti. It also meant that your firewall was very visible to the world, and its function was rather obvious and easy to deduce. There had to be a better way. And now there is...
Dream with me for a moment: A black box, shimmering in the soft LED-green glow of the network cabinet. You take the network cable from your router, which previously went into a switch, and stick it in one of the snappy plugs in the back of the box. There's one more plug on the black box, so you grab another cable and hook the box up to the switch. You step back, and suddenly: everything looks the same. You go to all your computers. As far as you can tell from inside and outside the network, the box doesn't exist. It does nothing. A few minutes later, you have a monitor and keyboard hooked up to the back of the box. You quickly and easily begin to tweak a file that gives you fine grained control over access to your network. You shut off all access to your mailserver from the outside world except on port 25.
It's a bridge (Score:5, Insightful)
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.
Re:Another interesting consept: Invisible Firewall (Score:4, Informative)
For exposed servers this would work well, not so much for the 18 Windows boxen you have Joe Salesguy using.
Re:Another interesting consept: Invisible Firewall (Score:4, Insightful)
Re:Another interesting consept: Invisible Firewall (Score:2)
net0 == firewall's no-IP link to your ISP
net1 == firewall's no-IP link to the router.
You do the invisible firewall thing between net0 and net1.
net2 == router's ISP-provided public IP link to the firewall.
You run a crossover cable from net1 to net2 to connect the "firewall" to the "router".
net3 == router's private IP link to the internal network.
You do the NAT between net2 and net3.
One box thus acts as both the invisible firewall and the NAT/router. Feasable? Stupid?
Re:Another interesting consept: Invisible Firewall (Score:2)
Re:Another interesting consept: Invisible Firewall (Score:2)
SunScreen... (Score:4, Informative)
Read about it here [sun.com]
Re:Another interesting consept: Invisible Firewall (Score:3, Interesting)
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 [bell-labs.com] 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.)
Difference betwwen this and Read only media? (Score:2, Interesting)
Re:Difference betwwen this and Read only media? (Score:3, Informative)
Re:Difference betwwen this and Read only media? (Score:2)
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.
There's nothing special about kernel memory. The real security is in the fact that there is minimal code running. Less code= less bugs = less opportunities for a security related bug.
The same effect can be had (with better versatility) by writing a small and thoroughly audited control program, and disabling disk I/O, exec, etc by loading a kernel module after booting. Naturally, the simpler the control program, the more secure you're likely to be.
Other neat tricks might include having the control program only communicate through a non IP ethernet protocol to a hardwired MAC address, and a watchdog which is pinged by a single threaded control program. It would be quite hard for an attacker to get any code inserted into that AND manage to keep the watchdog going. Bonus points for using all inline functions, not linking against libc, and staying off of the stack.
Logging? (Score:4, Insightful)
on the firewall though.
With no disks mounted where can you log it to?
Re:Logging? (Score:5, Insightful)
Dot matrix printer on LP1
try to erase THAT log
-booyah
Re:Logging? (Score:3, Funny)
see we have this thing these days....
it's called "fire"
i have portable "fire creation device".
commonly called a "lighter"
;-p
Re:Logging? (Score:5, Interesting)
Re:Logging? (Score:2, Insightful)
Do logging to the serial port in syslog format as if is a serial connection. Do this on all your servers. Hang a multiplexer in the middle (perhaps you have an old one from the modem pool still lying around gathering dust).
On the multiplexer you hang a seperate box and make it's serial TTy's go to a syslog daemon. Can be a Pentium class computer. Give it ample RAM (some 32MB EDO-simms out of those boxes from 5 years back. You _did_ gut them for parts did you?), 1 HD for the OS and 1 for the logs, about 1 GB each should be more than enough. NO NETWORK. NONE. WHATSOEVER.
Depending on your needs you either hang a simple CD-burner in it, a simple CD-burner with a Lego robot to change your cd's (*cough*) or a real SCSI cd-changer of of a cheap scsi-card.
You log to the HD of that log-box. You run a script that does nothing but check the size of the log and perhaps how fast it is currently growing. When it approaches 600 or 700 MB you dump the log to CD-ROM. Depending on your needs and how fast the log fills you then make it page you when it runs out of CD's (changer) or out of space.
Takes less storage.
(If you really want the complete security of paper logs, at least get an old line-printer from somewhere. If your machine freaks out it will at least be able to keep up untill its paper runs out. No such luck with a simple matrix printer).
Re:Logging? (Score:4, Informative)
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.
Re:Logging? - syslog (Score:3, Insightful)
Dumbass.
Re:Logging? - syslog (Score:3, Informative)
Re:Logging? - syslog (Score:2, Funny)
syslog running in runlevel 0.
I guess you could always run the video out into
a VCR... or use a serial console and a line printer.
I figured this out in a much different way (Score:4, Interesting)
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.
NOT a recommended config (Score:4, Insightful)
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
Re:NOT a recommended config (Score:3, Insightful)
Creating an invulnerable firewall that only needs to be configured once and will forever be secure = A "game".
?
brilliant! (Score:4, Interesting)
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.
Re:brilliant! (Score:5, Insightful)
I think you just reinvented the embedded system.
What about logging? (Score:2, Insightful)
I'm a little bit ignorant around the linux firewall setup, but don't you want your firewall to do some logging? Without logging how would you figure out where a DoS attack was coming from? Someone port scanning you? Wouldn't you want to know if someone tried to access a service you blocked with your firewall? This method seems to be nice armor for your firewall, but you have no idea who just whacked you upside your head.
Not much of a Firewall (Score:3, Insightful)
There are a lot of things that can be done but, one has to ask: Other than doing it for the sake of doing it, what's the point?
Re:Not much of a Firewall (Score:2)
If you aren't using central logging, your shop isn't running as effecient as at could be. Also, if you're not using central logging at large, it doesn't mean you can't use it for special cases. Unless you're just not sure how to set it up.
Look into syslog's -r option, IIRC.
Re:Not much of a Firewall (Score:2)
Do you store your valuables on the front steps of your house?
OpenBSD (Score:3, Informative)
Great idea.. (Score:2)
Essentially, I don't see why any process that runs entirely in kernel space couldn't be handled the same way. It has sparked my interest enough to build a test machine to try out this kind of thing. The site is already
Also, that was the most interesting article of the issue. It slightly miffs me that I can read it online for free, but their magazine just cost me ~5$.
What is the benefit of this? (Score:3, Insightful)
Re:What is the benefit of this? (Score:3, Informative)
Re:What is the benefit of this? (Score:2)
My way or the HIGHWAY BUB! (Score:3, Interesting)
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...
More on logging... (Score:2, Insightful)
This is a really neat idea, although I imagine still not practical. To make any configuration changes, it'd be a pain.
More Secure Solution (Score:5, Informative)
-davidu
logging... (Score:2, Insightful)
Or could you re-direct the logs?
Best way I've found for secure firewalls... (Score:3, Interesting)
Why run an OS at all? (Score:5, Interesting)
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 [slashdot.org] 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.
Halted firewall vs bridge (Score:4, Interesting)
A bridging firewall as the advantage of still being administrable from the local console.
Hmmmmm TUX? (Score:2, Interesting)
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.
Re:Hmmmmm TUX? (Score:2, Interesting)
moving userland code to the kernel does not improve security, worse, the code is now running as root instead of your favorite apache user. killing processes like login, sshd, syslogd etc. does. (ok you can argue about killing syslogd improving security as you can't read any log files anymore)
Re:Hmmmmm TUX? (Score:2, Interesting)
Really, all this discussion is insane. Just run OpenBSD, don't do anything stupid, and you'll be just fine
better still.. (Score:2, Funny)
Old news (Score:2, Funny)
It's been reliably packet-forwarding for me for over a month with a kernel-oops on screen.
how does that work? (Score:2)
Maybe this is a stupid question, but on all of my boxes, after I run shutdown -h and all of the killall scripts are run, it runs S01halt, which then calls either halt or reboot. This either stops the processor (soft power down) or else reboots the thing. The author didn't mention how he avoided this problem in his efforts - if you want the box to run in run level 0, you have to also disable the script that runs at that run level that shuts down the machine. Otherwise your machine really will be halted and there won't be any firewalling going on. Or more precisely, everything will be firewalled :) Did he not mention this problem, or did I just miss it somehow?
Assuming that this works, I don't see a whole lot of advantage to this over just using a firewall that's booted from a read-only floppy firewall distribution. Except that if you could come back from run level 0 (not sure if you can or not) then you could remount the disks, make a change to your firewalling rules, and then return to the halted mode. That might be a minor advantage over floppyfw systems.
Re:how does that work? (Score:2, Informative)
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
Re:how does that work? (Score:2)
So what about the removal of the scripts? That doesn't have anything to do with the box shutting down, but rather turning off the ethnet interfaces. Also in Redhat, the IPchains kill script flushes the chain. So we disable it. I do disagree with his removal of the killall script, but that's another story for another time.
This is all explained 2/3 of the way down the page. Enjoy!
overkill? (Score:4, Insightful)
I am somtimes amazed (Score:2, Interesting)
*BSD's securelevel combined with chflags ... (Score:2, Interesting)
man securelevel
man chflags
2.4 kernel? (Score:2)
er.. (Score:4, Interesting)
---
Re:er.. (Score:2)
But... (Score:3, Funny)
*dodges flying shoes*
;)
Klowner
Solving the rebooting "problem" (Score:5, Interesting)
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?
Re:Solving the rebooting "problem" (Score:4, Insightful)
Re:Solving the rebooting "problem" (Score:4, Interesting)
Bind "init 3" to a key-combination in inittab and voila!
I'm pretty sure it will work however I have no interest in testing it.
What a waste... (Score:2, Interesting)
Cheap rackmount solutions? (Score:3, Insightful)
Take this idea, a cheap rackmount, a readonly boot medium, and you have a very very secure device.
Possibly the ultimate in security?
Rebooting Drawback - simple "revive" kernel patch? (Score:2, Interesting)
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.
Correction (Score:5, Informative)
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
I'm more secure (Score:2, Funny)
Thanks Slashdot
More secure...? (Score:5, Insightful)
Misguided (Score:2)
It would be a lot easier to crack the very few daemons (apache, etc) running on my Linux box on the other side (that the firewall routes) than to crack the firewall itself. I could imagine someone exploiting apache, getting ssh access to the Linux box somehow, and thus ending up behind the firewall.
At that point, the security of the firewall can be as good as it wants to (which IMHO it is), but the network it's supposed to protect has compromised due to the ports it DOES forward. Why would said cracker even bother to try to exploit the firewall (with one port open, mind you) at that point? To open up ports, perhaps, but he can just use existing forwarded services to do his dirty work.
Bottom line? Every sysadmin already knows this, but firewalls do not make your box magically secure. A secure firewall only goes so far.
Swap (Score:4, Informative)
Versus an empty "netstat"? (Score:3)
If there's not a single process listening on sockets (shown by netstat), then only the kernel is around doing it's masquerading, routing, etc., just as per runlevel 0.
While it's a cute trick, why limit *all* your potential functionality (flipping on ftp for 15 minutes, to let a buddy upload a file).
-me
Solving the RAM issue (Score:3, Insightful)
Would it be possible to create a system that uses Static RAM (Smart cards, whatever) and have two sticks of it inserted?
One that you boot from and read the firewall rules and such out of, and another 8 meg or so stick that is used just for proccessing things.
Some types of flash cards now days have read write tabs on them, after your OS has loaded and all and you have got things how you want it, halt it, and then switch the tab on your main memory stick so that it is read only.
The 8 meg stick would have previously been assigned to be used for working with packets and such that the firewalls needs to do.
Even better of course would be if you could get a CPU with a nice sized Cache on it (hmmmm, K6-3s, hehe. External cache up to what, 8 megs?
Re:You could try something even more secure... (Score:3, Insightful)
talks about whether or not this could be done in OpenBSD as well because
of its good kernel level firewall utilities.
Re:Logging CAN be done in this setup. (Score:3, Insightful)
Re:Why use a whole computer? (Score:3, Interesting)
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.
Re:Why use a whole computer? (Score:2)