Subject: Re: r/o filesystem restrictions for firewall?
To: Jon Lindgren <jlindgren@slk.com>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
List: port-sparc
Date: 10/24/2000 10:50:40
On Mon, Oct 23, 2000 at 04:01:54PM -0400, Jon Lindgren wrote:
> On Mon, 23 Oct 2000, Manuel Bouyer wrote:
> 
> > If you intend to let users to log in, then you'll need a writeable /dev
> > too.
> 
> Aha.  Is this just for the chown of /dev/tty, or are there other side
> effects?

Yes, that's it. But this is mandatory. Also if you let user log in you may
want accounting.

> 
> > Here's what I've done for my sparc machines I use as telnet/ssh gateway:
> > /, /usr, /netroot and /tripwire are on a R/O filesystem (in my case a scsi
> > disk which have the appropriate jumper, but this shouldn't matter).
> > /netroot/home, /netroot/dev and /netroot/var are mounted R/W, noexec for all
> > and nodev for /netroot/home & /netroot/var (/netroot/dev is writable by
> > root ony anyway, and you can play with chflags to limit what can be done).
> > As you guessed, inetd & ssh are chrooted to /netroot.
> > /netroot has only a limited set of binaries (not mount, for example),
> > /netroot/dev a limited set of devices (tty/pty, zero, null, ... no disks of
> > course).
> > 
> > inside /var there are symlinks to /netroot/var for appropriate directories
> > (log, acct, run). /netroot/etc is a symlink to /netroot/var/netetc, so that
> > passwd, skey & all are writable.
> 
> Ahhh... a different approach.  Something makes me shy away from using NFS
> and having a local disk, but I will re-examine my motives for such thoughts. 

Note that I don't use NFS: 2 local disks, one RO and one RW

> 
> My current choice would be to make it a standalone entity which boots,
> does ipnat and ipf, and resets itself every n minutes/days/etc...

What do you want to do with this machine exactly ?
ipnat/ipf, or telnet/ssh/ftp/whatever gateway for internal or external users ?
These 2 functionnalities should be on different machines. The ipnat/ipf machine
is the one which protects your internal network so it should be as
safe as possible. This implies no network services running on it, and
management done only from console (and console in a safe place, of course).

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--