RE: SQL Slammer Variant?

From: Wilson, Aaron J. (
Date: 04/01/03

  • Next message: "Re: POP3 logon attempts"
    From: "Wilson, Aaron J." <>
    Date: Tue, 1 Apr 2003 13:17:06 -0800 

    #1 applies to us, and is a great idea. It has stopped today, maybe there's
    some significance being April 1 =). But when if/when it picks back up we'll
    have a go at it.

    Thanks for the suggestion.


    -----Original Message-----
    From: crucible []
    Sent: Tuesday, April 01, 2003 4:53 AM
    Cc: Wilson, Aaron J.
    Subject: Re: SQL Slammer Variant?


    If you're pretty sure that the traffic is originating internally and is
    spoofed, here are a couple of things you could do:

    - If you have internal routers, add source address spoofing filters to
       each of their interfaces. You could turn on logging for matches based
       on that rule and at least narrow down which of your networks this is
       coming from. This is a good thing to have in any event. People on your
       internal network shouldn't be sending spoofed packets.

    - If you don't have internal routers and you've got just one big
       switched network, then the source MAC address of the spoofed packets
       should hopefully be in the packet captures of your IDS logs. Use this
       information in combination with your switch management tools to figure
       out where the traffic is coming from.


    crucible <>
    Excellent. The weather machine is nearly completed. What do you say to that
    broccoli? Stop mocking me! -- Stewie from Family Guy
    Wilson, Aaron J. wrote:
    > I am witnessing SQL Slammer IDS events on an internal sensor that 
    > aren't coming from one particular source.  In fact, every packet sent 
    > has a unique and random source IP as well as a unique and random 
    > destination IP.  The data in the packet matches the one shown at 
    >  We have UDP 1434 
    > blocked around the perimeter and believe this traffic to be 
    > originating from a system within the internal network.
    > The rate of packets at around 2-6 packets per minute isn't as high as 
    > the original SQL Slammer traffic I have been seeing (at thousands of 
    > packets per minute).  But this is going to be difficult to track down 
    > on a large network.  If it spreads, 2-6 packets per minute per 
    > infected host with thousands of internal systems...
    > The first spell was between 03/27/2003 1023 and 1100 PST.  It picked 
    > up again at 1431 PST on 3/28/2003 and hasn't stopped yet.
    > Thoughts?  Similar experiences?  Note to coworkers - if this is a 
    > practical joke on me it's a good one.
    > -Aaron
    Powerful Anti-Spam Management and More...
    SurfControl E-mail Filter puts the brakes on spam,
    viruses and malicious code. Safeguard your business
    critical communications. Download a free 30-day trial:

  • Next message: "Re: POP3 logon attempts"

    Relevant Pages

    • Re: [opensuse] SuseFirewall IPv4 vs IPv6
      ... # network security threats. ... # Opening ports for LAN services in the external zone defeats the ... # this setting only works for packets destined for the local machine. ... # If the protocol is icmp then port is interpreted as icmp type ...
    • Re: Ethernet issue: works one way but not another
      ... packets transmitted, 5 packets received, 0% packet loss ... (This is when connected directly to internet through ... FBSD, I have been working with BSDI at the isp I work for for the last ... As for my network topology, I have an internal network that goes ...
    • Re: Update: UDP 770 Potential Worm
      ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
    • Re: IDSIPS that can handle one Gig
      ... especially with 64-byte UDP packets. ... There are plenty of network IPS's ... IDS/IPS devices through use of fragments. ... Find out quickly and easily by testing it with real-world attacks from ...
    • Re: iptables and dhcp
      ... > the same physical network segment as the firewall and the remote DHCP ... You used INPUT and not FORWARD chain ... # This target allows packets to be marked in the mangle table ...