[2778] in bugtraq
Re: BoS: amodload.tar.gz - dynamic SunOS modules
daemon@ATHENA.MIT.EDU (Dan Stromberg)
Fri Jun 21 17:04:48 1996
Date: Fri, 21 Jun 1996 10:57:15 -0700
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Dan Stromberg <strombrg@hydra.acs.uci.edu>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
der Mouse wrote:
> >> So for today, the best defense is really to take pro-active action
> >> and prevent intruders from gaining access to your network. This can
> >> be done with a combination of firewalls and having a continuous
> >> security assessment program in place where you scan your network for
> >> vulnerabilities and correct. You can test your own machine with a
> >> scanner from www.iss.net.
>
> I trust Christopher Klaus will forgive me for being a bit suspicious
> when I notice that his recommend "best defense" just happens to be what
> his company is selling.
For what it's worth, I do consider firewalls a pretty good option,
especially if the security behind the firewall isn't neglected. I don't
have anything vaguely resembling a vested interest in firewall sales.
That said, not every site (including ours) really has the option of
Using a firewall.
> > With writeable CDROM drives around $700, has anybody considered
> > setting up their system [...] and then backing the disk to WCDROM?
>
> As someone else pointed out, all that does is speed up recovery; it
> doesn't harden the system against attacks any.
Doing something analogous thing over NFS really can be a tremendous win,
tho.
1) It means you don't have to worry about running out of time for
applying every last security fix, on new machines
2) Done with some forethought, it can be used to bring old machines up
to date quickly on holes that were exposed after the machines were set
up. To a large extent, this can very nearly outmode "scheduled security
evaluations." and their aftereffects.
3) It opens up opportunities for lots of "nice, but there's no time for
that" modifications that wouldn't happen otherwise - like... applying
vendor patches; putting TCP wrappers, Wietse's rpcbind, and klaxon on
everything; turning off echo, chargen, &c..
IE, such an approach can yield more secure configurations, in less time.
...and it doesn't only benefit security.
To gain the most benefit, ya gotta do make the changes procedurally,
rather than trying to keep a "perfect disk image" around to be copied.
It takes a little longer to set up each modification, but you can then
use that some modification code on new releases of an OS without
overhauling your disk image, not to mention use the modifications
against multiple vendor's OSes.
There's a mailing list dedicated to this sort of thing:
auto-net-request@math.gatech.edu
Our particular (free) implementation is described at
http://www.oac.uci.edu/support/dcs/automation/autoinstall.html, but it
is tightly coupled with our environment. The scripts are ftp'able.
