Re: Isolated box...

[Doug Hughes <Doug . Hughes @ Eng . Auburn . EDU>]

>
>Hi all,
>
>This may not be entirely relevant for firewalls, but I think it is
>close, so...
>
>I have an opportunity to get a couple of old Sun IPCs to use to
>provide services such as RARP, bootp/dhcp, bootparams, etc as well as
>some network listening.  RARP under SunOS 4.1.n needs the /dev/nit
>device, which I do not want to put on an "open" machine.
>
>Would stripping all services from /etc/inetd, stopping nfs, NIS, etc,
>basically only allowing console logins, and only supporting sendmail
>going out, ftp going out, pulling unneeded devices/filesystem
>types/etc out of the kernel, etc be sufficient protection for this
>box, or are there some other parameters that would need to be tweaked
>either in the kernel at run time or in some header files?
>
Sounds like you've got the hang of it. Get rid of everything out of
inetd.. Heck, you might not want to even run it at all.. Not
having an /etc/exports file means NFS won't start. You could comment
out the biods to for that matter if you're not mounting anything. 
Sounds like you wouldn't need sendmail at all. Heck, you could even
not have a default route out of this puppy.. People can bombard it
all they want, and it wouldn't know how to reply if it didn't have
the route. We use this technique on some of our NFS servers. You can
add a static route by hand, do your thing, and delete it when you're
done if you need to.
 Once you've done this, the device is essentially inaccessible except
via console. Don't need to run sendmail daemon at all either.

>Basically I would like to lock that /dev/nit device into a controled
>environment.  It would be a pain in the but to administer, but it
>should not require much in the way of maintenance.
>
You wouldn't even have to update security holes since nobody can log
in to it. You can can remove all the ptys and ttys except for the
console (unless you plan on running windows, in which case you'll need
a couple for terminals windows.

it might be a bit ugly, because you'll have to update
the databases by hand, which, as you said, will be a pain
in the but to administer. 

tradeoff: If these are for those broadcast protocols as you mentioned,
you might want to not make it totally inaccessible to your internal net,
but just remove the route to the outside world. (at your discretion). This
will make administration easier while lessening battened down security
somewhat.

[ This message has been posted to the firewalls list. Please do not CC
  myself if you reply to the list. I will read replies sent to the list, and
  don't need two. Thanks. ]

--
____________________________________________________________________________
Doug Hughes					Engineering Network Services
System/Net Admin  				Auburn University
			doug @
 eng .
 auburn .
 edu
		Pro is to Con as progress is to congress