[Full-disclosure] Getting Off the Patch
lists at isecom.org
Mon Jan 17 16:02:55 GMT 2011
> Excellent example. I'd like to also throw one in that has network connectivity consequences. Regarding SQL Slammer - what would have given 100% protection from Slammer. Outside of the obvious ones like firewalls and such which are already deployed. That's a "real life" example, and I'm interesting in what controls would have already been in place.
I responded tot he previous example but I should have focused on this
one. There's some interesting things about slammer that I really
didn't understand. Why was the SQL service reachable over the
Internet? Why hasn't server access been limited to only packets within
a TTL of 1 or locally only if so required? Why hasn't the server been
better managed to prevent applications from running or connecting
however they want?
Even something as simple as least privilege and a host-based
white-list hooking all apps and services running would have been able
to prevent something from starting here. I see this as a server not
fit for Internet use be marketed for Internet use without a good way
to limit damage. Now I'm not an MS server expert so I can't say
specific solutions but I do know that the MS Windows systems I've seen
are shy of elegant solutions to create op controls for various vectors
(in-server being a big one). From a network perspective, ingress
filtering to white-list types of commands allowed, including
size-restrictions, would have helped.
But really, you say no firewalls and no filtering the port/service
because? I don't know. Maybe you're saying for all those who have
small businesses, just a couple servers, and don't do any segregation
of network then perhaps NAT alone helped some of those small
businesses escape the dreaded slammer by not passing that port back in
to their server.
But really, the results of slammer, like the results of many of these
Internet scourges popping up, there's a case to be said for too much
black-list authentication for prevention filtering and not enough
control on what can run and what it can do/send/listen. For example,
why should any secured system run something off a USB key that's
plugged in? That's just not taking operational control over the
server. So in such cases, the lack of a patch didn't affect those who
had control over what reached that particular port.
I know the OSSTMM isn't the easiest thing to read for some but it is
about trying to make a model that can be re-designed in more specific
and more eloquent ways to help more people understand some basic
aspects to making controls. But if it's not for you and you think that
op-controls can't protect where patches are needed then just feel free
to do your own thing the way you want to.
Pete Herzog - Managing Director - pete at isecom.org
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.badpeopleproject.org
Full-Disclosure is hosted and sponsored by Secunia.