-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 2 Jan 2002, Jeff Schaller wrote:
> I have a half-baked idea that I'm working on that involves a
> secure linux box. Mine will be a firewall, but the idea could be
> extended to an IDS or basic web server or etc.
>
You might wish to check out some of the existing work on Coyote Linux or
LRP. There are several linux routers/firewalls on a floppy.
> The idea is that the linux box is a write-once box; all setup and
> configuration is done on another system. For example, I currently
> create a kernel/filesystem image on a 3.5" floppy that boots and
> runs the system. It currently doesn't use (mount) any hard drive
> or CD-ROM, but it could.
>
This is a good idea, but you would have to be prepared to burn a new
floppy and reboot the firewall every time you wish to make a configuration
change.
> The kernel on the filesystem doesn't include floppy support; you
> could extend this idea to making the floppy's filesystem minix and
> then include only minix fs support.
I don't understand you here, you could load the default system via an
initrd but using minix doesn't buy you anything. In any event floppies
can be write protected so not having floppy support in your kernel only
makes your life more difficult. In any event if someone has the access to
mount your floppy they have access to do many other bad things, including
modprobing new stuff into your kernel.
>
> The permissions on the filesystem are stripped to bare minimums,
> and then chattr -i'd.
Remember to use something like LIDS to make the kernel and file attributes
inviolate otherwise someone could just chattr +i your files, or access the
raw device.
>
> The startup sequence runs a one-time init script which sets up the
> firewall rules and services, and then removes most of the
> remaining programs ("rm", "ipchains", "mount", etc).
>
Again, you obviously aren't going to be doing any remote administration on
this host anymore, but an attacker could always upload their own mount,
ipchains executables (maybe even handcoded in ASM if space is tight).
> There would be no network access/login to the box -- console,
> only, if you want to log in and attempt to do something. If you
> want to make changes, you make them on the host system and
> re-create the boot floppy.
>
If you have to network access to the box, only console, than many of you
security precautions will not measurably increase your security, they will
only frustrate you and make your job harder. There is a common
misconception that being a big pain in the butt is synonymous with
security. If you have no network accessible daemons then there is no
reasonable way that someone could take over your box (the few unreasonable
methods can then be more easily tracked down).
> I like the idea of using a boot floppy because I can remove files
> I don't need when I'm done with them; on a CDROM, I can't do that.
>
If you plan on removing files then you will have to make your floppy
read/write. If someone does get access to the system then this lowers the
bar for trojaning system binaries. If you don't plan on doing any admin
work directly on the system then leave the filesystem readonly.
> So, I like imagining this setup against various attack scenarios,
> such as the interesting example put forward by Kurt a few posts
> ago where the attack mounts another filesystem over the top of one
> of yours. In Jeff's half-baked plan, that wouldn't be possible
> because the mount program is gone. There'd be no compiler, or even
> room to upload a compiled binary. (A /tmp directory is created
> with the minimum amount of space needed for temporary stuff during
> bootup).
>
If the attacker can run programs on your machine, they can likely upload
their own. Not having /sbin/mount wouldn't prevent them from issuing the
mount() system call with their own binary. Just think how much fun it
would be to upload a copy of busybox.
> I'm calling it half-baked because I haven't finished it or the
> article describing it (and I haven't done those because I haven't
> finished working out how I want all the details to work).
I think that you might have something wrt using chattr/LIDS, readonly
filesystems and not doing config tasks on the same system as is doing the
packet filtering. You can make the system almost impossible to break
into and to then subsequently trojan. Just don't make the system too much
of a pain to use, at least without good reason, and be aware that if you
are burning new disks everytime you make a config change you might be
creating extra downtime.
- --
Mark Tinberg <[EMAIL PROTECTED]>
Network Security Engineer, SecurePipe Inc.
Remember: Wherever you go, there you are!
Key fingerprint = AF6B 0294 EE33 D802 F7A1 38A4 CF52 5FE0 7470 E5F7
Your daily fortune . . .
The control of the production of wealth is the control of human life itself.
-- Hilaire Belloc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/
iEYEARECAAYFAjw1FYYACgkQz1Jf4HRw5ffCRQCfZT8K7zJWJ/gVfBCwKz35JFEW
td0AnAz4ui4J3TcoImU/A8kfqRUH/RGp
=mww1
-----END PGP SIGNATURE-----
