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? asked 09 Jun '13, 07:16  staticchanger edited 09 Jun '13, 10:36 |
One Answer:
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 ♦♦ 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 ♦♦ |
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
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.
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
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?
@Landi, well, since the IP destination is whited out, I suspect the trace was taken on the public side of the FW :-)