Re: The Morris worm to Nimda, how little we've learned or gained

[Rich Kulawiec <rsk () magpage com>]

On Sun, Jan 06, 2002 at 09:43:10PM -0500, Paul D. Robertson wrote:
> Solaris is a three day exercise to unwind enough stuff and compile 
> IPFilter into the kernel to block enough to be comfortable, futz with 
> runlevels...  

Yes, it is.  Repeating the exercise for other Unix/Linux OSs gets rather
tedious as well, which is one of the reasons that I've mostly fixed on
OpenBSD for "single-service boxes".

But on the upside, there are now enough tools to allow me to install
J. Random Unix/Linux distribution and figure out what it's running,
then start shutting down everything that I possibly can in an attempt
to minimize the exposure.  In particular, I make a lot of use of two
pieces of open-source freeware: "lsof" and "nmap".  "lsof" is a very
nice tool for figuring out which processes have which files (including
network sockets) open.  "nmap" is a port-scanner with all kind of nifty
options.  Between the two of them, I can usually manage to figure out
what services are being offered, where they're being offered, what process(es)
are involved, and what I need to turn off in /etc/rc* or /etc/inetd.conf
or whatever to disable them.

The problem, though, as you pointed out elsewhere in your note, is that
sometimes the requisite functionality (e.g. Solaris requiring rpcbind to
serve fonts) is handled in a way that makes it hard to turn off everything
that I'd really like to.

A second problem is that I'd like to avoid this entire process; but I'm
not aware of any Unix/Linux distribution whose install procedure includes
taking the user through a dialog that advises them what they're opening
vs. what they're closing.

A third problem is that some distributions conflate the meaning of "install
this piece of software" with "install and ENABLE this piece of software".
There are often times I'd like to do one, but reserve the decision
on the other until a later time (if at all).

To be honest, I don't know of a really good approach to address this.
One thought that occurs to me is that software authors might consider
including, in addition to the ubiquitous "README" and "INSTALL" files
that are part of many (most?) open-source packages, a file called...
hmmm, let's call it "IMPACT" because it somewhat reminds me of an
environment impact statement...which would detail what files/directories
are modified when this package is installed, what network port(s) it
listens on, what processes it will run, etc.  But I'm not sure if this
is a useful idea or not.  Comments?

---Rsk
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards