This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

incoming TCP Retransmissions saturate WAN

0

My internet slowed to a halt, and after checking the obvious things I suspected a DOS attack. Wireshark shows an astronomical number of TCP retransmissions coming from an IP on the internet. What does this mean?alt text

Pcap file: http://www.cloudshark.org/captures/64f2c70a977c

asked 09 Jun '13, 07:16

staticchanger's gravatar image

staticchanger
11113
accept rate: 0%

edited 09 Jun '13, 10:36

indeed looks like DOS, especially since the delta times in no way fit retransmission intervals. The IP though refers to google so I guess someone is faking their source IP or totally other possibility -> one of your network devices indeed retransmits this one single packet like hell (which is in my opinion more unlikely).

Do you see the tcp handshake before the burst? That would exclude s.o. faking the packet

(09 Jun '13, 08:37) Landi

Nope, just this same packet over and over. I requested a static IP change and that fixed the problem. (for me anyway). I'm just curious as to what type of attack it is, and if there's a way to prevent it in the future.

(09 Jun '13, 09:19) staticchanger

Normally your firewall should prevent incoming packets without pre-established tcp sessions. If there really is no handshake before this flood of packets - I'd check the firewall first

(09 Jun '13, 09:26) Landi

If you switched static IP, are you able to share the tracefile on www.cloudshark.org? Or maybe after rewriting the IP header with a tool like tcprewrite or bittwiste?

(09 Jun '13, 09:28) SYN-bit ♦♦

@Landi, well, since the IP destination is whited out, I suspect the trace was taken on the public side of the FW :-)

(09 Jun '13, 09:30) SYN-bit ♦♦

One Answer:

0

Well, it means that either someone is sending you the same packet over and over again to fill your WAN link. In the 68ms in your image, I see 35 full size packets. This results in a bandwidth usage of (1000/68)*35*1514*8/1000000 = ~6 Mbit/s of traffic. Is that your WAN bandwidth? Is the absolute sequence number 0 (click on the sequence number in the packet details and look at the hex value in the hex-data)?

It could also be that one of the packets is bouncing back and forth, either routed or switched. Could you check whether the IP identification (ip.id) and TTL (ip.ttl) are the same in each packet?

answered 09 Jun '13, 09:26

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

edited 09 Jun '13, 09:54

Sake, I almost follow the arithmetic here, but how did you determine the 351514 (bytes?) figure from the above screenshot?

(09 Jun '13, 09:52) griff

Oops, the *'s were interpreted as Italic start and Italic stop. I corrected the calculation :-)

(09 Jun '13, 09:55) SYN-bit ♦♦

Thanks. ;-) Makes much more sense.

(09 Jun '13, 10:11) griff

Here is the capture file if anyone is interested.

(09 Jun '13, 10:34) staticchanger

The ip.id is unique for every packet, so the packet is not bouncing back and forth. As there are only small gaps between the ip.id values it is probably not a google host, but someone else flooding this to you.

Just curious, if you ping 74.125.130.155 and make a trace, what IP TTL does the response have?

(09 Jun '13, 10:58) SYN-bit ♦♦