Is there still justification for denying transit for ms-sql slammer ports? Thanks, Joe
On Wed, 11 May 2005, Christopher L. Morrow wrote:
Is there still justification for denying transit for ms-sql slammer ports?
probably not, but that's really a local-to-your-asn decision.
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. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Wed, 11 May 2005, Jon Lewis wrote:
On Wed, 11 May 2005, Christopher L. Morrow wrote:
Is there still justification for denying transit for ms-sql slammer ports?
probably not, but that's really a local-to-your-asn decision.
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 :)
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 SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgkBh0STXFHxUucwRAjQ6AJsFHzi9/bof9L7kM+6pFfybkzNMJwCffZ2+ 76QYWAivNlOOT7DREixKMgU= =HIV3 -----END PGP SIGNATURE-----
-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCgkREot2VatFbXMERAhbeAJ9GLe6HUa8nuOB5AeYfbSEcyfEsNwCgiqG+ flADbuPxyxr06xaBIRROcXw= =lqFY -----END PGP SIGNATURE-----
On Wed, 11 May 2005, Jeff Kell wrote:
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 :-)
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
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.
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 Valdis.Kletnieks@vt.edu wrote:
On Thu, 12 May 2005 04:15:07 -1000, Brian Russo said:
Is there now justification for allowing transit for ms-sql slammer ports?
That depends. Do you believe in end-to-end or walled-garden?
-- Brian Russo <brian@entropy.net> (808) 277 8623
On Thu, 12 May 2005 04:15:07 -1000 Brian Russo <brian@entropy.net> wrote:
Perhaps a better question is:
Is there now justification for allowing transit for ms-sql slammer ports?
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
On Thu, 12 May 2005 12:23:19 CDT, John Kristoff said:
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
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. ;)
Valdis.Kletnieks@vt.edu wrote:
On Thu, 12 May 2005 12:23:19 CDT, John Kristoff said:
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
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
participants (11)
-
Brian Russo -
Chip Mefford -
Christopher L. Morrow -
Gadi Evron -
Hank Nussbacher -
Jeff Kell -
Jeff Rosowski -
Joe Maimon -
John Kristoff -
Jon Lewis -
Valdis.Kletnieks＠vt.edu