March 12, 2003 at 10:05 am
We are not ready to go to SQL 2000 sp3. We are on SP2 and wish to stay on this Service Pack for awhile.
We blocked UDB port 1434 and were not effected by the virus. Is there a patch that I should be installing? If so, which one is it?
Thanks,
Jeff
"Keep Your Stick On the Ice" ..Red Green
March 12, 2003 at 10:13 am
March 12, 2003 at 10:43 am
Be sure that when you install MS02-061, that should you install the HotFix that comes after it (dealing with a handle leak... article 317748), don't overwrite any files. It'll overwrite the patch.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
March 12, 2003 at 3:30 pm
Remember that blocking 1434 from outside the network will not stop intrusions or the worms from inside the network. Of course you may have meant access to port 1434 from any machine, but normally people don't, they just think about outside access.
--
Chris Hedgate @ Apptus Technologies (http://www.apptus.se)
March 20, 2003 at 8:57 am
Excuse me, i have some questions,
1. How does this slammer virus work? i found that the affected host will send large
amount of multicast packet. how does it lead to the server to produce high volume
of network traffic ?
2. Does anyone know where i can get more information about this virus ?
March 20, 2003 at 9:26 am
SQL Slammer works by exploiting a buffer overflow vulnerability in the SQL Server 2000 listener service. Basically this is what happens:
(1) Specially crafted UDP packet hits port 1434.
(2) Unpatched SQL Server can't handle packet properly. This results in the "infection."
(3) The infected system now executes code to generate the same sorts of packets to random (actually pseudo-random, but random enough) IP addresses. It also picks a pseudo-random source address because UDP is a "fire and forget" type of protocol.
(4) The infected servers spits out as many of these packets as fast as it can.
Reasons why it can bring down a network:
(1) The entire payload is 376 bytes. This is within the size of 1 UDP packet. In other words, servers aren't having to send out fragmented packets that have to be reassembled (like with Code Red and Nimda). Likewise, destination systems don't have to do the reassembly.
(2) It's based on UDP, meaning the handshake to establish a connection as with TCP isn't necessary. The overhead traffic isn't there. It can just spit out packets.
(3) All SQL Server 2000 systems listen on UDP 1434 and this cannot be changed.
As for more info, check out the alert Allen gave. Also:
http://www.eeye.com/html/Research/Flash/AL20030125.html
http://www.cert.org/advisories/CA-2003-04.html
http://www.caida.org/outreach/papers/2003/sapphire/sapphire.html
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply