Having gone back to check the research*, I think there are some
misunderstandings, some of which may contribute substantially
incorrect conclusions and recommendations. Let's try to correct these.
Reading some of your other posts to this thread (e.g. "Windows is for
games, and if you can play games on it, it shouldn't be in the
datacenter. Explain to your manager that he can have his nice game
systems, and when he wants to grow up and do real computing, hope to
god that someone out there has kept the last strictly Serious
Computing platform alive and well."), perhaps you didn't expect to be
taken so seriously in the first place.
I'm not sure that the sadmind worm is a richly rewarding case to
study, but since I've read the notes, I'll provide a crib sheet in the
name of the understanding you've invoked (ironically one way or the
other, it would seem): the worm was transmitted not from NT 4.0 and
Win2k IIS servers to Solaris 7 and earlier boxes but from Solaris
machines to IIS servers, where you seem to have got the premise
backwards. Moreover, just about every piece of software involved is
for products at or past end of support life, so the sadmind worm's
relevance to designing an environment these days is conceptual. The
sadmind facility itself hasn't been shipped at all since Solaris 9, so
you don't have to worry about it at all if you're running Solaris 10
or OpenSolaris. If you're running Solaris 9, you should follow Sun's
guidelines for the several vulnerabilities that have emerged since
worm, which is either to disable it completely or to deploy it with
stronger security modes which aren't set by default. If, however,
you're still running legacy operating systems for which there is no
ongoing patch support (IIRC that's anything pre-Solaris 9) or for
which there is effectively no ongoing security research to feed
patches that are available only through supplemental support contracts
(I believe Sun offered this to Solaris 7 customers who signed up for
it before EOSL), reducing network attack surface is absolutely
critical, and you'll want to consider radical steps such as running
these boxes on separate network infrastructure, with access to your
environment's network services, particularly file services and remote
execution (including sadmind), kept to an absolute minimum and
enforced by measures such as packet filters, preferably supplemented
by additional transport security, something to which I'll return.
Additional caveat: because the sadmind bug in question was in releases
that are no longer shipping or supported, exploit code and
documentation isn't available from sources such as Metasploit, so I'm
that much more reliant on the account of it from the research
previously cited, all of which documents behaviour saying that
sadmind's network scanning was not limited to subnets but to anything
under the last two octets of an address space of a randomly selected
first two octets.
What I proposed previously was more or less the application of
techniques from RFC3013 within enterprises rather than at ISP
perimeters. This technique has ample limitations (it's relatively
expensive to do this with hardware, and it doesn't scale well with
dynamic deployments), but enterprises have employed it where they've
not been as aggressive in implementing secure network protocols as,
for example Bellovin suggested nearly fifteen years ago (see the
overview to RFC1948, where, whatever his intentions at the time,
"strong authentication" should at this point be understood to include
not just initial authentication but session integrity). I suggested
ssh port forwarding because it's something of a reasonable middle
ground as far as shims go, even if it can get ugly for something like
RPC services (better to implement ONC+ functionality for strong
authentication and session integrity using GSSAPI with something like
Kerberos).
I've tried to make as much sense of your posts as possible, but it's
not clear why people should either still be worrying about the sadmind
worm per se today or drawing the conclusion that there are any reasons
specific to or generaliseable from it to run Windows and *nix boxes on
separate subnets or for that matter to consider subnet segregation a
security practise at all. In light of amply documented and long-
standing exploits available through a wealth of tools, subnets protect
against datalink, transport, and session layer attacks about as well
as silk purses protect the contents of your wallet from pickpockets:
they shouldn't even give you the slightest sense of confidence that
you've undertaken adequate security measures.
* I read the following and a bit more:
http://www.sophos.com/security/analyses/viruses-and-spyware/unixsadmind.html
http://www.f-secure.com/v-descs/sadmind.shtml
http://www.noh.ro/craiu.com/papers/papers/sadmind.html
http://www.cert.org/advisories/CA-2001-11.html
http://www.cert.org/advisories/CA-1999-16.html
http://www.securityfocus.com/advisories/2016
http://www.securityfocus.com/infocus/1291
Am 29 Jan 2010 um 16:26 schrieb john g4lt:
Your best protection is knowledge of how things broke in the past to
prevent future occurences, not in whiz-bang hardware
On Fri, Jan 29, 2010 at 9:01 AM, Bayard Bell <[email protected]
> wrote:
Running exploitable code with a wide-open listener is bad, so if you
don't want chained attacks from one exploitable service to the
other, you're going to need a better protection baseline than subnet
segregation (which shouldn't be mistaken for a form of security
domain, certainly not if you're running on the same switch domain
without at least a packet filter, preferably stateful, between
domains), to deal with older attack patterns. Better yet would be to
disable or patch exploitable services or limit accessibility of the
service via firewalling and secured port forwarding (e.g. ssh for
protection against address spoofing and session hijacking).
Am 29 Jan 2010 um 14:33 schrieb john g4lt:
IIS with Solaris boxes in the same subnet is Bad. ever hear of the
sadmind worm? it infected via a IIS host and ran the sadmind
exploit on all Solaris boxes in its subnet
_______________________________________________
opensolaris-discuss mailing list
[email protected]
