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."

Comments

Works for me...

[Rorschach1]

Though I usually just use the power switch. Can't beat a powered-off firewall for security.

Re:Works for me...

[Jonny Ringo]

I actually just light mine on fire. It just makes sense, than once the fire catches to the cords I know I'm secure.

Re:Works for me...

[shogun]

But it's a firewall. The flames can't go outside the box!

Hey its fine if its on the inside or the outside of the case, but not both.

...and? We do this all the time

[TicTacTux]

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...

Re:...and? We do this all the time

[moonbender]

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.

Re:...and? We do this all the time

[TicTacTux]

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...

Re:...and? We do this all the time

[morcheeba]

Yeah, all one has to worry about is that machine is used as a proxy to break into all local machines; running with a rooted firewall is just as bad a running without a firewall. You could still run local processes by remote mounting some drive on the internet.

Re:...and? We do this all the time

[gid]

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.

Re:...and? We do this all the time

[Deadplant]

you miss the point, this is halted system, not just a system with no drives mounted. I other words no user processes can start at all. It is therefore impossible for a virus to run, the only kind of exploit possible would be one that directly exploits a flaw in the kernel (a fairly rare thing). and beyond that, it would probably have to be an exploit designed for this kind of system specifically since most exploits assume it's possible to execute a process (like a shell, or an 'rm -rf' or something)

Re:...and? We do this all the time

[bfree]

if your going to go to this much trouble would you really let it run a kernel which had the capability to mount a hardisk?

Re:...and? We do this all the time

[tricorn]

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:

#!/bin/sh
mount proc /proc -t proc
mount -o ro /usr
/etc/rc.d/init.d/network start
/etc/rc.d/init.d/ipchains start
umount /usr
exec /bin/sh

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.

Er, aren't there better ways to do this?

[oGMo]

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?

[gid]

Well if you have drives mounted, even read only, then someone could potentially get in and bounce off the firewall to attack another machine on the inside of your firewall using processes and utilities on the drive that you mounted. Whereas if you didn't have the drive mounted to begin with, then no one could get in, even you! And that's the point.

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?

[gorilla]

You could have two firewalls, one with the current configuration, and one being preped for the next configuration. When you are ready to change them, just flip them.

Re:Er, aren't there better ways to do this?

[Junta]

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...

Re:Er, aren't there better ways to do this?

[garcia]

it also doesn't support any program that needs user space to run (ie DHCP and the like). He said it would not be good for those having dynamic setups (most users AFAIK).

nice idea but little use for most I would guess.

Re:Er, aren't there better ways to do this?

[spencerogden]

Couldn't set up one box to handle dynamic connections, and then put this behind it? It would be extreme, but this is an extreme technique for the extremely paranoid.

Re:Er, aren't there better ways to do this?

[jmv]

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.

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?

[liquidsin]

that's what I thought too. not sure how complicated it could get, but I was supposing you could have one normal firewall handling your dhcp/pppoe (for us dsl users) and then the halted firewall behind that. it's settings would remain static, so even if someone got through the first firewall and got root, they would have nowhere to go from there but to the runlevel 0 box.

Re:Er, aren't there better ways to do this?

[dpilot]

Or just run "lcap CAP_SYS_ADMIN" to drop mount
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 /proc/kmem. There are more things you can remove from the kernel capabilities bounding set to lock your system 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?

[drodver]

Better yet is if you setup your halted firewall as a bridge you owuldn't need a second firewall, just another regular server behind the firewall doing whatever it is you want. The regular server won;t even know the firewall is there.

Re:Er, aren't there better ways to do this?

[jmv]

Well the first such a module does is preventing loading/unloading of modules...

Re:Er, aren't there better ways to do this?

[wtarreau]

the read-only mount only lasts until the equivalent of mount -o remount rw is executed,

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 /etc is noexec BTW).

Willy

Re:Er, aren't there better ways to do this?

[liquidsin]

the thing is, I want to be able to use pppoe. would the halted firewall / bridge be able to do that? I'm thinking this could turn into a fun project with some old spare 486's.

Re:Er, aren't there better ways to do this?

[rew]

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.


I like the fact that my firewall logs "breakin attempts". If for instance I intend to open up my "ssh" port but the "last week" shows lots of attempts to talk to my ssh port, I know that something is going on, and that I should reconsider the decision.

Roger.

Replace INIT

[Skweetis]

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.

Another interesting consept: Invisible Firewall

[bob@dB.org]

introduction from http://www.openlysecure.org/openbsd/how-to/invisib le_firewall.html

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.

Re:Another interesting consept: Invisible Firewall

[douglips]

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.

Re:Another interesting consept: Invisible Firewall

[Chang]

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

Re:Another interesting consept: Invisible Firewall

[Phil Gregory]

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.)

Re:Another interesting consept: Invisible Firewall

[Rick the Red]

Here's a thought -- could you do this with 4 network cards in one box:

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

[Rick the Red]

So you're saying it's both feasable and stupid? :-)

Re:Another interesting consept: Invisible Firewall

[swb]

You would think so. FreeBSD's natd can rewrite to a specific address rather than the named address, but there was nothing in my cursory inspection that said it could do so when operating in pure bridged mode.

Re:Another interesting consept: Invisible Firewall

[Rick the Red]

After more thought, I agree. If you put an IP address on the box, you (or, rather, I :-) miss the point.

Still, doesn't the idea that you could hack the router if it were the same box as the invisible firewall imply that you could hack a separate router behind an invisible firewall? In which case it's not much of a firewall, is it?

I think I'll stick to my 'standard' firewall and not try anything exotic like halting it or making it invisible. I think just having a firewall makes me more secure than most folks, anyway. Lot's of people (or bots) "jiggle the doorknob" but so far nothing's made it in.

Re:Another interesting consept: Invisible Firewall

[evilviper]

It would actually be more secure to have an invisible firewall than a normal one.

I wonder if doing it through the loopback would be possible-I've never done loopback on anything but the IP level, but that's despite the point.

In order for the packets to get through to the NAT box / internal network it has to go through that packet filtering bridge first. That means you'd be able to filter out all the abnormal packets, before they reach any machine with an IP address that might be confused by them. This would be an improvement over giving the world the ability to ping and connect to the firewall directly.

With a stealth firewall... you can't exploit the TCP/IP stack, PF/IPF as easially, or any running network apps (SSH). Just think, even if the nearly impossible happens, and a packet payload that exploits the stealth firewall, what would you do with it? You might crash it, but you can't have it listen on a port to allow you to connect... Even if you are able to get to the internal network, you won't be able to connect to the firewall box and modify the ruleset.

Which leads us to why it's less secure to have an IP address on your packet filtering bridge. If they can get through AND find an exploit, then they can connect to the firewall box and modify the rules.

When was the last time you heard someone say their systems were 'too secure'? If you don't have the resources to impliment this scheme, a normal setup is much better than nothing at all. And to tell you the truth, I'd feel more secure with a default OpenBSD installation (perhaps shutting off sendmail) with Packet Filtering & NAT enabled, than I would on a write protected & halted Linux firewall.

Re:Another interesting consept: Invisible Firewall

[evilviper]

To what are you refering? The invisible firewall in question is a 'packet-filtering bridge' which does indeed do all of it's filtering at the network layer.

Difference betwwen this and Read only media?

[raumdass]

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?

Re:Difference betwwen this and Read only media?

[anti-snot]

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.

Re:Difference betwwen this and Read only media?

[sjames]

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?

[JimR]

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?

Re:Logging?

[booyah]

Same place I log anyways

Dot matrix printer on LP1 :-)

try to erase THAT log :-)

-booyah

Re:Logging?

[Stary]

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.

Re:Logging?

[doorbot.com]

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.

Re:Logging?

[geschild]

On a more serious and realistic note: I made the following suggestion to the maintainer of the Debian security FAQ.

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?

[Foxman98]

would be fairly easy...

see we have this thing these days....

it's called "fire"

i have portable "fire creation device".

commonly called a "lighter"

;-p

Re:Logging?

[cnvogel]

One could reverse-feed the paper and print all X's over it :-)

Re:Logging?

[ddstreet]

i have portable "fire creation device".
commonly called a "lighter"

especially on machines that still have dot matrix printers attached, it would probably be much easier to just use the Halt and Catch Fire instruction!

I figured this out in a much different way

[Binestar]

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.

Re:I figured this out in a much different way

[bfree]

Instead of shutting everything down simply have three boxes. At any given time one box is live on the edge of the network which is configured to simply switch all traffic between the two other boxes (thats a static config, it may take a bit of hacking to come up with a switching solution but it should be easy enough). The two other boxes are the real firewalls so you can update and test the new box and when ready signal the outer box to switch, then next change prep the other box. lather, rinse and repeat as neccessary.

Re:I figured this out in a much different way

[Lumpy]

??? reboot for routing changes? all the time..

I rewrite my firewall floppy, change floppy press reboot.

If your users cant stand not having internet access for the 78 seconds it takes for a reboot then they need ritlain and a reality check.

NOT a recommended config

[peril]

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

Re:NOT a recommended config

[SilentChris]

Break a Furby apart to learn its internal electronics (and try to reprogram its main chip to speak curse words) = A hacking "experiment" with "great knowledge" learned by the experimenter.

Creating an invulnerable firewall that only needs to be configured once and will forever be secure = A "game".

?

brilliant!

[Mr. Slippery]

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!

[swb]

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.

Re:brilliant!

[bfree]

tell that to Linus, there is a web server in kernel 2.4 unless I'm very much mistaken! So who wants to run their webserver at runlevel 0?

Re:brilliant!

[Tony-A]

I'm still a newbie, but I don't think the stunt is restricted to kernel only. Just shut down everything that is no longer necessary to keep running.
Instead of Microsoft Window's install or change something and reboot, you have to reboot to install or change anything. You just shut down and turn off all the nice unixy tools for yourself and any potential attacker.

Re:You could try something even more secure...

[ajakk]

Or you could try not trolling and read the actual article. The author
talks about whether or not this could be done in OpenBSD as well because
of its good kernel level firewall utilities.

What about logging?

[TeamSPAM]

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

[FreeLinux]

This isn't much of a firewall when there is no logging or alerting. With this approach you basically have a solid state packet filter and if that's what you want, a Linksys box would still be a better solution.

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

[omega9]

I don't see a problem in logging to a remote syslog server. It's the first logical thought anyway.

1. The firewall will be halted so we can't double duty and use it as a central syslog server as well
   
2. Therefore we must point it to our central syslog, if not another syslog
   
3. If we're not using central logging, why the hell not?!?
   

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

[duffbeer703]

Who in their right mind would make the firewall a central logging server anyway?

Do you store your valuables on the front steps of your house?

Re:Not much of a Firewall

[omega9]

I wasn't getting at using the firewall as a central syslog as in the central syslog. I should have worded it a little better!

OpenBSD

[Motheius]

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.

Great idea..

[omega9]

I just read the dead tree version of this about a week ago while sipping some coffee. It's an interesting idea to say the least, but I don't think the practice of turning the machine off and still expecting it to work will be widely accepted by any large production environment.

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 /.'d so I can't check my facts, but I thought it mentioned it was possible with a 2.4 kernel as well.

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?

[SClitheroe]

The kernel is still executing, as is IPChains (obviously)..If IPChains has any exploits, what is to stop a hacker from being able to modify the firewall configuration in memory, thus punching holes in the firewall?

Re:What is the benefit of this?

[entropi]

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.

Re:What is the benefit of this?

[autocracy]

IPchains would be really tought to exploit because it doesn't answer to packets, just modifies them. The only exploit possible would be a kernel level one that has NO user space involvement - including listening ports. Challenge!

Re:Logging CAN be done in this setup.

[BlueUnderwear]

Wouldn't this still need a locally running klogd to forward the messages to the remote syslogger?

It's a bridge

[booch]

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.

My way or the HIGHWAY BUB!

[aphor]

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...

[Elequin]

Couldn't one simply also remove K88syslog from /etc/rc.d/rc0.d/ and log all messages to a remote syslog server?

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

[davidu]

A much more secure solution would be to have a firewall with no IP addresses.

Memoirs of an Invisible Firewall

Using OpenBSD (and linux could work too) it is possible to create a bridging firewall with no IPs that simply scrubs packets as they come through the interface.

One could always add a dialup modem to the machine in case remote access was neccessary but when you have two nics neither of which have IP addresses or running services it makes a machine a whole hell of a lot more useful then a linux machine in halted mode which could EASILY run into weird memory/timing issues. (which the author didn't bring up)

-davidu

logging...

[painkillr]

If the filesystem is down, then does this mean that logging is halted?

Or could you re-direct the logs?

Best way I've found for secure firewalls...

[Macphisto]

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.

Re:Why use a whole computer?

[EllF]

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.

Re:Logging? - syslog

[Anonymous Coward]

There's no syslog running anymore.

Dumbass.

Why run an OS at all?

[Mignon]

Now that you've read my provocative title, I'll tone it down a bit:

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.

Re:Why run an OS at all?

[Webmonger]

You have to run the userspace tool ('ipchains'/'iptables') to configure the firewall each time you boot.

Halted firewall vs bridge

[chrysalis]

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.

Re:Halted firewall vs bridge

[bfree]

It's about choice, you can run your bridging firewall with no assigned IP address halted! It's not about how to do it. I thought about just running the kernel on a firewall device I may be designing (which is basically the same is it not). I pictured (possibly) a device that booted up and grabbed a kernel from a trusted network if it's present and reboots with it if it is, if not it is left with nothing but the kernel running (some oddities I had noticed in audio and networking had left me certain a lot could keep running). Call me mad but I envisioned hard coding the iptables into the kernel (I'm still not sure I'd actually run anything on the box, I would like to just run the kernel but that makes the updating more hackish). Whatever you want to do this is another way to secure the system (if it's appropriate for you).

Hmmmmm TUX?

[TrebleJunkie]

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.

Re:Hmmmmm TUX?

[Make]

complex kernel bloat as kernel-based web servers tends to have the security holes you want to move away from when killing all processes...

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?

[stepson]

No, you wouldn't be able to. As init moves through the run levels, it umounts the disks, so I don't know where you'd get the data to serve web pages from ...

Really, all this discussion is insane. Just run OpenBSD, don't do anything stupid, and you'll be just fine ...

better still..

[Hooya]

is the system i have at home. i look at each incoming packet on paper and then pass it on the the lan if it looks legit. the only way to punch a hole in the firewall is with a shotgun at my belly..

Old news

[pHalec]

Bah, I've got an old Pentium with some faulty memory that crashes on a regular basis.

It's been reliably packet-forwarding for me for over a month with a kernel-oops on screen.

Re:Logging? - syslog

[JimR]

As other people have pointed out there will be no
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.

how does that work?

[ethereal]

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?

[grnbrg]

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?

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?

[autocracy]

Common mistake in kernel compiles: exclusion of certain APM features that are taken for granted - including the one that actually does the power down. Unless you get the power cut, kernel level code still executes. Therefore, it's a slightly tweaked kernel.

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?

[anthony_dipierro]

If your data needs that much security, you shouldn't have it connected to the internet in the first place.

I am somtimes amazed

[thunderbee]

...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.

*BSD's securelevel combined with chflags ...

[gd]

... can achieve almost the same thing.

man securelevel
man chflags

SunScreen...

[Psarchasm]

SunScreen has been doing this for quite some time.

Read about it here

2.4 kernel?

[uslinux.net]

So the obvious question: how long before someone attempts this with the 2.4 kernel and IPTables?

er..

[einstein]

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.
---

Re:er..

[SomeOtherGuy]

Yea -- same thing happened to me...the disk fried put the firewall kept routing packets for 2 months -- granted I was running a remote syslog -- if the syslog was local, I am sure it would have halted at some point. The only way I found out about it was when I telneted in to vi a conf file and it would not save!

But...

[Klowner]

Then how would I telnet to my firewall from school?

*dodges flying shoes*

;)

Klowner

Solving the rebooting "problem"

[vrmlguy]

There seem to be a lot of comments along the lines of "Yeah, but you have to reboot to change the config, and that takes down your firewall". I see this as an opportunity, not a problem.

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"

[lkaos]

Or one could use the MagicSys keys built into the kernel and simply use a standard keyboard :)

Re:Solving the rebooting "problem"

[Jon Howard]

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.

Re:Solving the rebooting "problem"

[cgleba]

Just kill every process except init and unmount filesystems.

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.

Re:Solving the rebooting "problem"

[vrmlguy]

Why not? Mostly because I've been around long enough to remember using ISA debug cards. In my dottering old age, the soft power switch (and MagicSys keys) slipped my mind. ;-) Actually, I did realize that there were several ways to acomplish the goal. One that I didn't mention: Since the kernel is (I think) sitting in a spin loop, you could probably have it polling LPTBase+1 watching for someone to short the NOPAPER pin on the parallel port.

Re:Why use a whole computer?

[TheAwfulTruth]

And costs $5 a month to run. Full size computers are power pigs.

What a waste...

[IAmSancho]

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.

Cheap rackmount solutions?

[iamsure]

Okay, so do anyone know of a cheap place to get rackmount 1U's, like, with just a pentium, network card and cdrom?

Take this idea, a cheap rackmount, a readonly boot medium, and you have a very very secure device.

Possibly the ultimate in security? :)

Re:Logging? - syslog

[gaj]

no need for it. the fw is acting as a *client* for syslog. syslog would be running on the log server.

Rebooting Drawback - simple "revive" kernel patch?

[Laven]

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.

Correction

[mmurray]

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

Use hardware remote access

[ErikTheRed]

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...

Re:Use hardware remote access

[prog-guru]

Check out the PC Weasel

It is an ISA or now a PCI card that does pretty much the same, and you telnet to it. It emulates a video card, has cables to connect the keyboard and to the power button header on your motherboard.

Re:Use hardware remote access

[Tassach]

The only beef I have with them, is that the remote console is simply a telnet port connection. Kinda kills the point of securing the box, ssh only, etc, when you have this card giving telnet access to the box

This is only a problem if you are foolish enough to put the management cards on the same backbone as everything else. The intelligent way to set up a system like this would be to have the management cards on their own, independent network. For the truly paranoid, you could have this network completely isolated from your "real" network. A more practical approach would be to have the administrative network hidden behind a well-secured and monitored gateway machine.

Re:Use hardware remote access

[ErikTheRed]

Actually these new ones work in either text or graphics mode, and use SSL-encrypted HTTP connections. All login & remote access stuff is handled via Java applets, which makes a brute-force attack considerably more difficult.

I'm more secure

[Anonymous Coward]

Cool! I just halted my BlackIce service. If I hadn't read this article, I would never have known that doing that would make me more secure.

Thanks Slashdot :) You rock. I don't have to worry about my hard drive shares being exposed now...

Eh, slippin' straw man.

[oGMo]

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.

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.

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.

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.

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.

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 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.

"And if you're screwed, you're screwed." Duh.

More secure...?

[st0mp]

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?

Re:More secure...?

[gaudior]

Please read the previous postings. As has been noted, there are several solutions for remote logging, including:

• Hardcopy on a parallel or serial printer
  
• Sending syslog-style data stream out a serial port to another computer
  
• Remote syslog facility
  

and probably others as well.

Re:More secure...?

[st0mp]

er... syslogd is a user space processes, and is exploitable. Holy just defeated the purpose of a halted system, Batman!

Misguided

[Anonymous Coward]

I have a weirdo-paranoid firewall/NAT-box running an ultra-stripped-down OpenBSD. I have put weirdo-paranoid security on it. The only open port is ssh, and you have to be inside my home network to reach it.

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

[srichman]

The other consideration is that with drives unmounted, all swap space is removed from the machine. This shouldn't be difficult in a machine that is handling even large amounts of traffic, given sufficient amounts of memory. However, in an older machine with fewer resources, it is possible to experience performance issues with extremely large amounts of traffic.

Kernel memory doesn't swap in Linux. So, even if you could have swap space in a halted firewall box, it wouldn't be used at all

Real Secure machine?

[miffo.swe]

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....

but...

[Syberghost]

It plays hell with your uptime. We all know that's more important to /. users than security, right?

Bonus points to anybody who does this and then submits an nmap fingerprint of it...

Can't use it, either.

[mfh]

Just testing my user id #56 really. :)

BSD kern.securelevel

[nivedita]

If you're interested in this, also see FreeBSD's kern.securelevel facility. From the init(8) manpage:
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, /dev/mem, and
/dev/kmem may not be opened for writing; kernel modules (see
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.

Re:Logging? - syslog

[Tuck]

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.

how

[Suppafly]

How does this work? It would seem like packet filtering would require a process or two.. how can you having it working at a runlevel which has no processes running?

Re:how

[CjKing2k]

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.

logging?

[einhverfr]

If you think that freesco has logging that could be more robust, try running syslog on a halted system ;)

Hrm, there is also SPARC

[clump]

Management is one reason I like SPARC so much. IE, connect a serial line to even a decade+ old Sun Pizzabox and manage via OpenPrompt. Even if the operating system is hosed you can still reach the OK prompt and reboot, or perform other tasks. Further, you can use the OK prompt to do network boots out of the box.

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:Hrm, there is also SPARC

[ErikTheRed]

Yes, you can continue to use the cards if the machine is 100% fubared (they have their own on-board i960 and RAM to handle remote access functions). They also have a port for an external DC power source (adapter included) (the older ones had on-board NiCad battery packs that had to be replaced every 2-3 years), so yes they do work even if the server is turned off.

On another note, most Compaq servers made in the last 5-6 years have what they call IRC - Integrated Remote Console. Basically, you plug a modem (or LAN-controlled serial device) into COM1 or COM2 and you can remote-control (text-mode only) and cold-boot the server (you have to do some setup from the Compaq System Utility Partition first).

The newest Compaq Servers have the Remote Insight functionality described in my last post integrated on the mobo. The only downside is that you have to purchase a software key to get the graphical remote control (text-mode is included with the base package), but that's still an improvement because you don't lose the slot (important for your 1U pizza-box servers).

Versus an empty "netstat"?

[PhotoGuy]

Why not just avoid starting all services, and verify with "netstat" that there's no processes listening.

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

Why all the cards?

[Raetsel]

Or... you could just use one of these:

• D-Link DFE-570tx 4-port 32bit PCI fast Ethernet adapter
  Phobos P430 (same thing)
  Adaptec 6944a Discontinued model, cheaper -- still 4-port, still 10/100

  Or, if you're lucky enough to be playing with 64 bit PCI @ 66 MHz... there's the newer Adaptec stuff.

  Adaptec 64044 4-port 64bit/66MHz PCI fast Ethernet adapter

Not cheap in any case -- but it'll sure open up some PCI slots!

Now, to answer the Rick's "Feasible? Stupid?" question...

• Feasible? Certainly. These cards are basically 4 Ethernet chipsets put on one card. The Phobos one uses an Intel DS21143 setup, and can be addressed with generic Linux drivers (tulip.o) as 4 separate devices.

  Stupid? Possibly. Everything coming in from the internet has to pass through the bridge first, and thus pass its' rules. Nothing can directly address it. Pretty much perfectly invulnerable. The only real vulnerability would be a DoS, but that depends on the rules you've plugged into the firewall. In any case, it's impossible to directly compromise the firewall portion of the machine.

  Having the machine providing other services does mean, however, that if something is somehow compromised that your firewall is compromised too -- it's a risk you have to weigh yourself.

  Imagine you're running a webserver on the machine -- with a vulnerable CGI. Someone discovers this, and takes over what they think is "only" a webserver -- only to find they've taken over your company's firewall, too! Ouch.

Something worth considering though -- it'd make for less hardware, and it's something I find attractive for home use -- a combined worry-free firewall + home file server + seamless internet access... nice idea.

Re:Why all the cards?

[Rick the Red]

Or... you could just use one of these:

A clear improvement on my off-the-cuff nuts-in-retrospect idea, but I've found it much easier to mix different brands of network cards on my firewall. When you reboot, how can you be sure what was net0 isn't now net2? With 4 identical interfaces, the combinations are, well, 4! = 24, so you have a 1 in 24 chance that the system will reboot to a functional configuration? Help me out here, as I'm not familiar with these cards: is what I suggest a danger, or will it always come up in the same order?

P.S. I assumed readers could guess I was speaking of the home environment. If I were doing this for a business I could justify the expense of separate boxes; heck, I could justify the expense of new boxes! :-) Silly me, it's dangerous to make assumptions on /.

There, I just created one with 4 lines of shell.

[kcurrie]

Can you say "fork bomb"? I can:

coyote# while [ /bin/true ]
> do
> cat /dev/urandom > /dev/null &
> 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.

:-)

Interface roulette

[Raetsel]

First, let me qualify my experience. I am familiar with OpenBSD -- what I use for my firewall -- not Linux. I have done many boxes with multiple identical cards, and never had them 'come up' in a different configuration than I had originally configured. Ever. I never gave it much thought, and I really have no idea exactly how it's prevented -- MAC address, perhaps? It'd make sense, at least to me...

I don't believe there'd be any danger of cards randomizing on every reboot -- there are far too many people out there using multiple interfaces to not allow that problem -- if there was one -- to be addressed.

Now, as far as this solution being aimed at home use... There are many people who wish to run services from their home network. Mail, file services, a proxy for their websurfing while at work... not all these services are 100% secure. Yes, I know I used business examples, but the same vulnerabilities could happen at home. Heck, when Code Red went around, look at all the home-based servers that were affected! The home/business line is very blurred.

Re:Interface roulette

[Rick the Red]

My experience is admittedly limited. Right now I'm running a Coyote Linux firewall, and I'm configuring a new/used OpenBSD firewall to replace it. From the Coyote Linux FAQ:

Q: I'm having problems with running two of the same NICs.
A: It's not suggested to use two of the same brand and make because it makes diagnosing problems rather difficult.

I've heard the same advice from other sources, as well. Specifically the problem was with Plug and Play ISA devices; perhaps PCI isn't a problem, in which case I wasted $3 when I bought one $9 card and one $12 card just so they'd be different :-)

Thanks for all the advice!

Games with init...

[Christopher B. Brown]

• First glance... They must be insane. That can't possibly work.
• Second glance... Maybe it can work... If it does, it's certainly immune to buffer exploits in wu-ftpd.
• Third glance... Seems like a slick idea. It sure would entertain portscanners when there are no ports there to get at.
• Fourth glance. Unfortunately, I can't use it on my firewall, as I need pppoe running.

The interesting lesson, though, "kiddies," is that there are some interesting games to be played if you look at init with a view to rearchitecting how it works.

Typically, init is a program that starts some services, starts up some gettys , and then we can log in and do the traditional Unix stuff that we usually don't think much about.

In this case, the system essentially runs init-less.

Another approach would be to build a highly customized init that doesn't run the whole of user space, but rather just runs a few firewall-related programs.

• Mount a filesystem;
• Run an IP-chain loader;
• Perhaps run pppoe ;
• Unmount the filesystem, maybe.

And you have something smaller that doesn't work quite as hard getting things going, but leaves pppoe around to do a little bit of work.

Other approaches could be taken to build quite different things:

• CLienUX (possibly not capitalized quite rightly) is a system where libc does on-the-fly path rewriting to support accessing some standard pathnames (/usr, /usr/bin) on a system with an exceedingly nonstandard set of naming conventions.

  Throw in that shell scripts in Bash are deprecated; it is considered preferable to have your programs written in Forth.

• One might create a Lisp Machine running atop Linux by having init be a master Lisp process that takes over the system. Throw in a helper process or two (X, maybe, and SSH) and you've got something with a userspace just a mite different from what people are accustomed to...

Re:Why use a whole computer?

[macemoneta]

LinkSys added stateful packet inspection in a recent firmware update (listed as SPI on the configuration). I havent't tested it, so I can't vouch for the implementation.

Solving the RAM issue

[Com2Kid]

Some people so far have mentioned that even having anything loaded in RAM creates a danger.

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? :) :) :) ) and just run almost everything directly out of that after booting. Though that would require some really nifty programming more then likely. :) It would DEFINTLY not be something that any random hacker would suspect, hehe.