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

TCP SYN Flood interpretation

0
1

I am trying to interpret a packet capture. I am thinking it is a SYN flood to the same ip address. It looks like it cannot do the 3 way TCP handshake. How do you interpret it? I am not sure how to upload the capture file.

42  1.280976    172.17.4.95 172.17.4.95 TCP 58  37176 → 111 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
43  1.281072    172.17.4.95 172.17.4.95 TCP 58  111 → 37176 [SYN, ACK] Seq=0 Ack=1 Win=32792 Len=0 MSS=16396
44  1.281086    172.17.4.95 172.17.4.95 TCP 54  37176 → 111 [RST] Seq=1 Win=0 Len=0
45  1.281184    172.17.4.95 172.17.4.95 TCP 58  37176 → 135 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
46  1.281190    172.17.4.95 172.17.4.95 TCP 54  135 → 37176 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

asked 14 Jul '16, 08:29

dblackwell's gravatar image

dblackwell
6●1●2●2
accept rate: 0%

edited 14 Jul '16, 08:32

grahamb's gravatar image

grahamb ♦
19.8k●3●30●206

You can share a capture in a publicly accessible spot, e.g. CloudShark, Google Drive, Dropbox etc. and then edit the question with a link to the capture file.

(14 Jul '16, 08:33) grahamb ♦

One Answer:

0

Hard to say without more knowledge about your architecture and more of the PCAP to look at....same IPs for client/server is definitely misleading.

A SYN flood typically appears as many IPs (DDOS) sending a SYN to the server or one IP using it's range of port numbers (0 to 65535) to send SYNs to the server. Since 172.17.4.95:37176 sent the SYN and then responded to the SYN,ACK with a RST, that would not be the behavior expected of an attacker SYN flooding a server. The attacker would want to initiate a bunch of half-open connections, not RST them and allow the resources to be reallocated.

Also, see https://ask.wireshark.org/answer_link/3290/

answered 19 Jul '16, 13:15

BruteForce's gravatar image

BruteForce
120●3
accept rate: 9%

I was waiting for the capture file, but agreed.

From the limited trace availability I'd guess this is a port scan (e.g., from nmap) not a SYN flood.

(19 Jul '16, 13:39) JeffMorriss ♦

I'm missing one point in this explanation - if it was a port scan, the scanner should be interested in the answers, so it probably wouldn't use the target address as forged source one?

So either the port scanner is really a remotely controlled malware running on the same machine, but then it would be quite stupid to reveal itself by scanning the ports on the same machine where it is running, or the packets actually come from outside and use the address of the destination as source, but in such case their sender cannot ever get the responses.

So I'd be interested in the source mac address of the SYN packets.

(19 Jul '16, 13:58) sindy

Oh, my thought was it was just an intentional port scan being run on the local machine. But I guess it's true that the RST in frame 44 could just as well be because the SYN,ACK in frame 43 was unexpected (out of the blue). Too bad I don't think TCP tells you why the RST was sent; in SCTP the ABORTs tell you when they're because an OOTB packet was received.

(21 Jul '16, 19:03) JeffMorriss ♦