Hi,
I'm new to this list, but we were talking about network security,
what-to-do-after-intrusion, etc. on debian-isp (excellent list with some
very talented ppl).
Though I'd give u my two cents...
> > 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.
> >
> > 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.
That would be far wiser as then you could make configuration changes.
> 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.
Wouldn't it be better to only allow ssh access to the box, and disable
every other service? Then you could run whatever you want to on the
floppy/box (within reason) without fear of ppl gaining access. Another way
would to be disable remote access altogether, and only allow console
access (near 100% security, but... well... inconvenient for you).
> >
> > 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.
My point exactly... think embedded system...
>
> 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.
> >
Rewritable CD-ROM?
> 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.
Maybe I don't get what you want to do fully, but... why are you removing
commands like rm and mount? If you are removing them from floppy... what
happens next time you boot? The files would already be removed first time
you run it, and you wouldn't be able to run ipchains or iptables or
whatever anymore. OR if you mean, copy the whole disk to a RAMDISK or
something and run it from there... er... that doesn't do very much either.
You seem to be going down some strange path that I can't quite see...
perhaps others understand this?
> > 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.
Well, apparently a /tmp is created with only minimal space, so no files
COULD be uploaded. Last time I checked busybox wasn't THAT small that it
could fix in a few Kbs.
> > 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.
Just seems kinda strange to do things that way. We've rolled out a few
"firewall-in-a-box" products/servers before. The box had 2 ethernet cards.
One labeled IN the other OUT (for the sysadmins that don't get it...
could've said DMZ and all that jazz). It didn't do anything TOO fancy...
it ran off floppy (we supplied 2 with each server, in case one got damaged
or something). It was plug-n-play more or less... didn't need to know
anything about your IPs and didn't need preconfiguration unless your setup
is very strange. It more or less "bridged" the two ethernet segments, and
in the middle performed some filtering and checking. For example, it could
be set to drop ALL packets from an IP that is performing port scanning and
such. Most people put it between their router and their own network hosts.
And every few months to 6 months, we mailed out new/upgraded floppies to
everyone (if they chose our service upgrade plans). Easy and works.
Sincerely,
Jason
http://www.zentek-international.com
