Re: Unix Hardening for FW installation

["Marcus J. Ranum" <mjr () nfr net>]

> %The NFR appliance (which I happened to do the first round of
> %system integration for) was built in the manner described above.
> %I took the bootstrap, added a kernel and filesystem, a minimum
> %of devices, and then coded my own version of init and everything
> %above kernel space.
>
> This is the same design methodology which we used in our Firebox.
> But, we don't have any filesystems which are for generic use.
> We use compressed read-only images which we uncompress during
> startup.
>
> This way, there is never filesystem "state" to worry about.

Right!

For the NFR appliance we had to worry about hard disk state,
since we're storing data, and need it to be persistent across
upgrades. Since it's CDROM bootable, we need to accept that the
kernel and bootup utilities may change but the filesystem
layout (which is basically a few directories anyhow) won't.

This is truly "hardening" an O/S -- starting from tabula rasa
and building from there. But the majority of sysadmins who
have to "harden" a box don't have the luxury of making a
pure appliance. Users don't typically like to work in a
filesystem/compiler/editor/user/shell-less environment. ;)

For generic multiuser systems about the only hardening I can
think of that makes sense is:
        1) put in ip_filt
        2) allow nothing incoming to the machine except ssh, dns, and
                established connections
                - this assumes the users read mail from a pop server elsewhere
                - this assumes the users can be trained to use ssh/scp/etc.
        3) periodically have the system sweep itself for port listeners
                (checking for users who have their own processes)
        4) (for advanced use) disable the ability to set execute
                permissions by non-root users

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr