[Dshield] TCP Port 1433 Syn Flood DOS Attack

Jon R. Kibler Jon.Kibler at aset.com
Mon Mar 10 21:42:19 GMT 2003


Greetings:

This morning I came in to find my firewall had just about rolled over and died from an apparent 'Syn Flood' style attack on TCP port 1433. Between the FW and IDS logs, it had consumed about the entire 4GB of the /var partition in less than 3 hours. It appears that by the time I got the attacker's ISP to block the attack, we had been hit somewhere around 70,000-75,000 times. (It is hard to tell the exact number of hits with all the dropped and duplicate log entries. Only about 1900 entries got submitted to DShield as our current log parser doesn't handle log entries such as 'the above entry was repeated 250 times.' Plus, I figure that we got hit another 3,000-7,000+ times after I turned off logging for that IP.)

The only way I was able to get control of the system was to unplug the network, let the queued backlog be processed, and then insert a rule to DROP all packets from the offending IP (instead of LOG+IDS) before bring the network back up. The initial onslaught of packets had been so fast and furious that the monitoring process that should have paged me never got a chance to run until after I had disconnected from the network. 

Whenever I would reconnect to the network, we would get an initial burst of packets at about 50-60 packets/sec, which after 2 or 3 minutes would slow down to 25-30 packets/sec and remain at that level for another 15 to 20 minutes, and then gradually slow down to 5-10 packets/second. Another interesting characteristic was that the entire data stream would periodically stop for 2-5+ minutes at a time and then resume at the 50-60 packets/sec rate.

Has anyone seen a similar attack?

I have heard that the SQL Slammer worm can generate attacks of up to 30K packets, but that the packets are a mixture of TCP port 1433 and UDP port 1434, but I never once saw a port 1434 probe.

I have enclosed a couple of dropped packets following the signature paragraph if anyone sees anything familiar about the packets they think may provide some clue as to what was going on here. (I am not a TCP/IP protocol expert, but I find it interesting that long sequences of packets -- all dropped at our end -- have the same originating port number and packet sequence number. Under normal circumstances, shouldn't the packet sequence be different for each packet, even if the prior packet had been dropped?)

Any thoughts/feedback anyone may have will be GREATLY appreciated.

Jon R. Kibler
A.S.E.T., Inc.
Charleston, SC  USA



> ETHER:  ----- Ether Header -----
> ETHER:  
> ETHER:  Packet 1 arrived at 10:01:2.47
> ETHER:  Packet size = 62 bytes
> ETHER:  Destination = 0:0:0:0:0:0, 
> ETHER:  Source      = 0:0:0:0:0:0, 
> ETHER:  Ethertype = 0800 (IP)
> ETHER:  
> IP:   ----- IP Header -----
> IP:   
> IP:   Version = 4
> IP:   Header length = 20 bytes
> IP:   Type of service = 0x00
> IP:         xxx. .... = 0 (precedence)
> IP:         ...0 .... = normal delay
> IP:         .... 0... = normal throughput
> IP:         .... .0.. = normal reliability
> IP:   Total length = 48 bytes
> IP:   Identification = 18219
> IP:   Flags = 0x4
> IP:         .1.. .... = do not fragment
> IP:         ..0. .... = last fragment
> IP:   Fragment offset = 0 bytes
> IP:   Time to live = 112 seconds/hops
> IP:   Protocol = 6 (TCP)
> IP:   Header checksum = 39fc
> IP:   Source address = 66.166.143.108, h-66-166-143-108.SNDACAGL.covad.net
> IP:   Destination address = 207.2.232.139, asetgate.aset.com
> IP:   No options
> IP:   
> TCP:  ----- TCP Header -----
> TCP:  
> TCP:  Source port = 3870
> TCP:  Destination port = 1433 
> TCP:  Sequence number = 644074735
> TCP:  Acknowledgement number = 0
> TCP:  Data offset = 28 bytes
> TCP:  Flags = 0x02
> TCP:        ..0. .... = No urgent pointer
> TCP:        ...0 .... = No acknowledgement
> TCP:        .... 0... = No push
> TCP:        .... .0.. = No reset
> TCP:        .... ..1. = Syn
> TCP:        .... ...0 = No Fin
> TCP:  Window = 16384
> TCP:  Checksum = 0xb174
> TCP:  Urgent pointer = 0
> TCP:  Options: (8 bytes)
> TCP:    - Maximum segment size = 1460 bytes
> TCP:    - No operation
> TCP:    - No operation
> TCP:    - Option 4 (unknown - 0 bytes) 
> TCP:  
> 
> 
>            0: 0000 0000 0000 0000 0000 0000 0800 4500    ..............E.
>           16: 0030 472b 4000 7006 39fc 42a6 8f6c cf02    .0G+ at .p.9üB..l..
>           32: e88b 0f1e 0599 2663 ccef 0000 0000 7002    ......&c......p.
>           48: 4000 b174 0000 0204 05b4 0101 0402         @..t..........
> 
> ETHER:  ----- Ether Header -----
> ETHER:  
> ETHER:  Packet 2 arrived at 10:01:2.51
> ETHER:  Packet size = 62 bytes
> ETHER:  Destination = 0:0:0:0:0:0, 
> ETHER:  Source      = 0:0:0:0:0:0, 
> ETHER:  Ethertype = 0800 (IP)
> ETHER:  
> IP:   ----- IP Header -----
> IP:   
> IP:   Version = 4
> IP:   Header length = 20 bytes
> IP:   Type of service = 0x00
> IP:         xxx. .... = 0 (precedence)
> IP:         ...0 .... = normal delay
> IP:         .... 0... = normal throughput
> IP:         .... .0.. = normal reliability
> IP:   Total length = 48 bytes
> IP:   Identification = 18224
> IP:   Flags = 0x4
> IP:         .1.. .... = do not fragment
> IP:         ..0. .... = last fragment
> IP:   Fragment offset = 0 bytes
> IP:   Time to live = 112 seconds/hops
> IP:   Protocol = 6 (TCP)
> IP:   Header checksum = 39f7
> IP:   Source address = 66.166.143.108, h-66-166-143-108.SNDACAGL.covad.net
> IP:   Destination address = 207.2.232.139, asetgate.aset.com
> IP:   No options
> IP:   
> TCP:  ----- TCP Header -----
> TCP:  
> TCP:  Source port = 3870
> TCP:  Destination port = 1433 
> TCP:  Sequence number = 644074735
> TCP:  Acknowledgement number = 0
> TCP:  Data offset = 28 bytes
> TCP:  Flags = 0x02
> TCP:        ..0. .... = No urgent pointer
> TCP:        ...0 .... = No acknowledgement
> TCP:        .... 0... = No push
> TCP:        .... .0.. = No reset
> TCP:        .... ..1. = Syn
> TCP:        .... ...0 = No Fin
> TCP:  Window = 16384
> TCP:  Checksum = 0xb174
> TCP:  Urgent pointer = 0
> TCP:  Options: (8 bytes)
> TCP:    - Maximum segment size = 1460 bytes
> TCP:    - No operation
> TCP:    - No operation
> TCP:    - Option 4 (unknown - 0 bytes) 
> TCP:  
> 
> 
>            0: 0000 0000 0000 0000 0000 0000 0800 4500    ..............E.
>           16: 0030 4730 4000 7006 39f7 42a6 8f6c cf02    .0G0 at .p.9.B..l..
>           32: e88b 0f1e 0599 2663 ccef 0000 0000 7002    ......&c......p.
>           48: 4000 b174 0000 0204 05b4 0101 0402         @..t..........
>



More information about the list mailing list