The main problem with the CF card solution is that the CF card has no "write-protect" feature. The original reason this topic was brought up in the first place was that floppy-based routers have easily switched write-protect tabs, allowing one to easily edit the floppy if necessary, then switch it back to write-protect mode for normal operation. Now, someone else has pointed out that there are a few USB memory keys which have write-protect tabs, which would make them an ideal substitute for the floppy-based router. --- Michael <mogmios@mlug.missouri.edu> wrote:

Better yet get a small (cheap) CF card and CF to IDE converter and use that. Very reliable and can be put together with a GB of space for little more than a floppy drive. About $20 usually.

Kelsay, Brian - Kansas City, MO wrote:

...

I ran a firewall off one with Freesco for something like 2 years. If a floppy isn't going to work in this mode, you find out real quick when you try to format it and use rawwrite to put the .img file on it.

__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

On 3/4/06, Leo Mauler <webgiant@yahoo.com> wrote:

The main problem with the CF card solution is that the CF card has no "write-protect" feature. The original reason this topic was brought up in the first place was that floppy-based routers have easily switched write-protect tabs, allowing one to easily edit the floppy if necessary, then switch it back to write-protect mode for normal operation.

Now, someone else has pointed out that there are a few USB memory keys which have write-protect tabs, which would make them an ideal substitute for the floppy-based router.

Another possible solution is to simply run the firewall in a 'halted' state. I'll explain. Basically when you halt the machine, everything shuts down, all userspace programs are killed, all filesystems are unmounted (and unmountable), modules unloaded, etc… and you're left with a machine that's dead to the world, and a message that tells you that you can turn off the PC. BUT in fact, the machine is alive and well - the kernel itself is still loaded, in memory, and fully functioning with full access to everything the kernel gets access to: all hardware, memory, etc. The trick is (and you can try this at home folks!) to remove the networking and iptables stop scripts from /etc/init.d (or wherever yours are located). This keeps the interfaces up, networking alive, and ipchains loaded and continuing to operate when you do 'shutdown -h now'. Try it - move the stop scripts to /root/ and halt the machine, you'll see it still responds to ping, etc... Because everything in userspace is killed, there is no way to run any hacks or attacks against the firewall (with the exception of kernel vulnerabilities... but those still would require an active userspace to feasibly exploit and make use of), since there are no services running - only networking and ipchains. Also, all of your disks are UNMOUNTED, no chance of writing to any files, adding users, or making any other sneaky changes. Of course, you'll still need to take great care when building your kernel - i.e. no 'kernel automounter', etc… and make sure you build a monolithic kernel - no modules. At the same time, build it to the very bare minimum absolutely necessary to operate, no extras. When you want to edit or change the configuration of iptables, you will of course need to reboot - by physically hitting the reset or power button - log in as normal to make your changes, and then halt the system again by rebooting (explanation is to follow). On older machines, this will not be as fast as simply flipping the write-protect tab on the floppy, making your changes, and reloading iptables, BUT, it is damn secure, with no funny hardware business. You'll want to set up two kernels to choose to boot from, with the default being the kernel built for the halted machine. Set up a runlevel with only networking and iptables to start, then immediately halt the machine. Another runlevel should be set up as normal. Have each kernel boot to its respective runlevels (the minimal monolithic boots to the halted state runlevel, while the full kernel boots to a fully running system). Now, if the power should fail, you're not stuck with a fully running vulnerable system and you can still get to it when you need to make any configuration changes. As for logs, you can also choose to keep the logging daemon running, configured to dump the logs to an internal logging server, or simply not have logs (who would want that?!). And if you're hardcore, SNMP is OK too. I think I've covered most all of the bases there, let me know if you've any questions – I've been running my firewall like this for years. Thanks, -Lucas

I always forget about that option, but wouldn't you want at least one other process running other than networking and iptables? I like to get reports from time to time of attempted break-ins. Since the drives are not mounted there would need to be a way to gather this information and report it somewhere, like via email or writing to a remote drive? Perhaps even a CD? Writing to a remote CD might get a bit costly under heavy fire, but nmight be attractive for a commercial server.

Well...yes, exactly. But, at the end of my *long* spiel, I did mention that it's optional to keep the syslog daemon running, configured to log to a remote server (internal), and you would be able to gather your logs and run reports on them this way... That, and unless you're using packet-writing, burning to CD would still require a mounted filesystem to dump the logs to in order to burn the CD, as well as the extra effort of writing scripts to automatically burn the CD's (if going the multi-session route) and the daily (or every few days) routine of dropping fresh CD-R's in the drive. In all, it's an extremely good, reliable, *secure* and easy solution to keep your firewall secure, while maintaining ease of configuration and the flexibility of a full system without having to do the whole 1.44 - 1.8 MB distro-on-a-floppy or LiveCD act, neither of which provide easy ways of keeping logs (unless you configure the syslog daemon on the floppy to dump to a remote server, not much space left on those for logs, or the CD version which will lose it's config after a power outage...) On the other hand, unless you're in Molten Core combat, and are noticing lots of lag due to heavy repeated hits to your IP, who needs logs of attempted break-ins when they're not successful? :-)

On Wed, 2006-03-15 at 12:03 -0600, sirsky wrote:

On the other hand, unless you're in Molten Core combat, and are noticing lots of lag due to heavy repeated hits to your IP, who needs logs of attempted break-ins when they're not successful? :-)

If this were Slashdot, you'd be getting a +3 for WoW reference. :) -- Jason D. Clinton <me@jasonclinton.com>