It seems we have a new worm hitting Microsoft SQL server servers on port
1434.
Agreed... shutting down MSSQL stopped the flood here.... now to find it and remove it
* Avleen Vig <lists-nanog@silverwraith.com> [20030124 22:44]:
It seems we have a new worm hitting Microsoft SQL server servers on port
1434.
A preliminary look at some of our NetFlow data shows a suspect ICMP payload
delivered to one of our downstream colo customer boxes followed by a
70 Mbit/s burst from them. The burst consisted of traffic to seemingly random
destinations on 1434/udp. This customer typically does about 0.250 Mbit/s
so this was a bit out of their profile. 
Needless to say, we shut them
down per a suspected security incident. The ICMP came from 66.214.194.31
though that could quite easily be forged or just another compromised box.
We're seeing red to many networks all over the world though our network seems
to have quieted down a bit. Sounds like a DDoS in the works.
Anyone else able to corroborate/compare notes?
-jr
* Avleen Vig (lists-nanog@silverwraith.com) [030124 23:50] writeth:
It seems we have a new worm hitting Microsoft SQL server servers on port
1434.
Affirmative. Be sure to block 1434 UDP on both the inbound and the
outbound. Infected servers are VERY NOISY.
Yes, I am seeing this big time. Are you sure its SQL server ? Thats normally 1433 no ? Are there any other details somewhere about this ?
Anyone else dealing with this tonight? Its kind of nasty
-Scotty
Yep - we are seeing 3 compromised SQL boxes right now.
Mark Radabaugh
Amplex
(419) 720-3635
We detected this traffic and blocked it. It was more wide-spread within
our network than the usual DDoS attacks we see. Curious to hear how
significant this one is or will be.
Duplicated info.. But this is an old worm ;-(
http://www.cert.org/advisories/CA-1996-01.html
Pete Ashdown wrote:
We are seeing this too.
We are seeing the gige interfaces on multiple customer aggregation
switches at multiple locations add several hundred Mbps each. All the
traffic is destined for udp port 1434 with a randomized source address. We
are doing "ip verify unicast source reachable-via any" which stops most of
the random addresses. We've temporarily had to block udp port 1434.
It seems we have a new worm hitting Microsoft SQL server servers on port
1434.
+----------------- H U R R I C A N E - E L E C T R I C -----------------+
USD10 to the first person who spots a CNN reporter speculating to Saddam's
involvement.
We were hit hard by this as well. It appears to be a buffer overflow
exploit, as blocking the ports on my router and restarting MS SQL put a stop
to it.
Thanks,
Adam Debus
Network Administrator, ReachONE Internet
adam@reachone.com
We had to go through each VLAN to determine which boxes were compromised,
looks like W2K SQL.
This thing is spreading fast.
-D
0. Pete Ashdown <pashdown@xmission.com> farted:
Yes, I am seeing this big time. Are you sure its SQL server ? Thats
normally 1433 no ? Are there any other details somewhere about this ?
<snip>
All MS SQL servers listen to 1434 reguardless of the other ports they listen
on. Depending on configuration depends on what other ports it uses (due to
various security models), but 1434 is a constant in all configurations
according to a quick search and a read on the last MS SQL vulnerability
found in 7/2002.
Jack Bates
BrightNet Oklahoma
1434 is the SQL Server Resolution Service.
Unfortunately, this appears to be a whole new thing, I was unable to find
anything more recent then May of 2002 about security issues with this port.
Thanks,
Adam Debus
Network Administrator, ReachONE Internet
adam@reachone.com
Thanks, I have blocked the infected hosts in my customer colo space. Its an eye opener how much traffic they generate on the local collision domain they are on 
---Mike
I'm seeing obscene amounts of 1434/udp traffic at my transit and peering
points. I've filtered it out in both directions everywhere my network
touches the outside world. It's almost 20% of my traffic at this point.
I think I've calmed the internal storm so far, but we'll see.
I saw refence to an ICMP "trigger" packet. Is there any info on this and
is it possible to filter for it w/o killing all ICMP traffic? It'd be
nice to know I won't have any more routers or switches fall over tonight.
Colo customers seem to be the worst off, the rate limiting kills the
router or the traffic kills the backbone. decisions, decisions...
-S
Note, further analysis makes me believe that the ICMP we saw immediately
beforehand was a coincidence and unrelated. The origin of the ICMP has
been traced to a customer application.
-jr
* Josh Richards <jrichard@cubicle.net> [20030125 00:21]: