Is there still justification for denying transit for ms-sql slammer ports?
Thanks,
Joe
probably not, but that's really a local-to-your-asn decision.
Is there still justification for denying transit for ms-sql slammer ports?
Well MS-SQL Worm propagation attempts and MS-SQL version overflow attempts account for 62% of the activity on our Internet facing IDS.
Jeff Rosowski wrote:
Is there still justification for denying transit for ms-sql slammer
ports?Well MS-SQL Worm propagation attempts and MS-SQL version overflow
attempts account for 62% of the activity on our Internet facing IDS.
It changes from 40% to 70% here at AS8867, as well.
Gadi.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joe Maimon wrote:
Is there still justification for denying transit for ms-sql slammer ports?
on my "at work" small network, slammer (or slammer like) traffic is
still around 2% of inbound blocked traffic. (just a dead end off
of asn 6467)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chip Mefford wrote:
on my "at work" small network, slammer (or slammer like) traffic is
still around 2% of inbound blocked traffic. (just a dead end off
of asn 6467)
Almost every time I update our border ingress ACL (which removes the ACL
for as long as it takes to load the new one, perhaps a few seconds) it
triggers IDS alerts on 1433/1434, often specifically the slammer packet
itself. (usually thanks to AS209)
The SANS ISC currently gives an "Internet Survival Time" of 24 minutes
for an unpatched windows box. I would give an unpatched Windows server
with an old copy of MSSQL a considerably shorter lifespan 
Jeff
Joe Maimon wrote:
Is there still justification for denying transit for ms-sql slammer ports?
Thanks,
Joe
Thanks all for your responses. To me it appears that
a) If you block 135/445 you should block slammer as well
b) If the number of potential infected hosts connected to your network can threaten your service, you should block.
c) If you are more concerned about eliminating crap on the net than in accomodating every whim of your users and are not doing pure transit, block it.
d) Microsoft should consider migrating to a new port for sql server.
e) if you are doing pure transit and not blocking anything, nobody will expect you to block slammer either.
f) slammers half life is incredibly long
Does anybody have any idea of the rate of NEW slammer infections?
Thanks,
Joe
f) slammers half life is incredibly long
Worms have a very long life on the Internet, we still see swen.. and we
still see (although interesting) niche worms that attacked just one
specific personal firewall. 
Does anybody have any idea of the rate of NEW slammer infections?
The net is an incredible maze, it still happens (or more to the point
RE-happens). But I believe that if you will look at the IP's (or at
least DHCP ranges) sending the packets, you will find some similarities.
Gadi.
See:
http://www.bbcworld.com/content/clickonline_archive_14_2005.asp?pageid=665&co_pageid=3
Took 8 seconds for an unprotected PC to get infected. I would give the
IST at under 1min from my personal experience - plus my firewall records 2
hits on port 445 every minute from external infected systems.
-Hank
I dunno about that. I know it was more than a year ago, but at NANOG
Miami, someone brought either SQL slammer or a vulnerable laptop and
killed the network for a while. Running tcpdump on my notebook, I noticed
fairly constant slammer probes while there. We still block it here, and
the last time we accidentally removed that filter, a colo customer was
promptly infected.
excellent, you made the choice for your asn... Joe should evaluate his
network's risk/behaviour/profile and see if it's still relevant for him...
much like he evaluates his requirements to recieve email from folks via
the use of the SPEWS list, which blocks my mail servers 
Perhaps a better question is:
Is there now justification for allowing transit for ms-sql slammer ports?
- bri
Joe Maimon wrote:
That depends. Do you believe in end-to-end or walled-garden?
End to end, but I'm afraid current realities do not always permit that approach and we must occasionally build walls.
Sure, I wish people would fully step up to the plate and demand robust software/protocols. Secure, strong encryption and software that isn't filled with buffer overflows and other ludicrously should-be-over-the-hill bugs. Etc etc..
This is the part where the crickets chirp, and everyone laughs at me.
So, if people want to screw up their own machines in isolation, that's fine but when it takes down half your network....
- bri
I think there always has been some justification. Here is a very
small sample of real traffic that I can assure is not Slammer traffic,
but it is being filtered nonetheless (IP addresses removed):
May 12 09:15:30.598 CDT[...] denied udp removed(53) -> removed(1434), 1 packet
May 12 09:26:30.210 CDT[...] denied tcp removed(80) -> removed(1434), 1 packet
May 12 09:32:23.122 CDT[...] denied tcp removed(80) -> removed(1434), 1 packet
May 12 09:42:38.558 CDT[...] denied udp removed(123) -> removed(123), 1 packet
May 12 10:12:50.422 CDT[...] denied udp removed(53) -> removed(1434), 1 packet
Some have suggested adjusting filters so that the src port is > 1023,
which may be somewhat less harmful, but then others may object to this
being an unacceptable hole.
You can design networks, educate people, build tools, and write secure
software to deal with all of the security problems, which will be very
expensive and slow or you can count down from 2^320 til you approach 0,
perhaps in large jumps, which is the way of the IP/TCP packet filters.
That might be just as slow and expensive, but unfortunately results in
complete dismantling of the system.
Perhaps there are better alternatives, but I think they probably fall
in between those two.
John
Looks like a good justification to *NOT* filter. Somebody nuked the reply
packets for 2 DNS lookups and 2 hits to web pages just because the user's
machine picked 1434 as the ephemeral port. Oh, and one machine that
got slapped across the face for having the temerity to ask what time it was. 
For TCP, you can filter it statefully, don't allow connections inbound
to 1433/1434, 135-139, etc.
For UDP, you could risk allowing source 53/123/etc either "period",
or "to >1023"
or "to 1434"
depending on the your taste, or just tolerate the collateral damage.
(And yes, there's always the wise-arse using nmap -g53 or -g123 etc)
Jeff