SYN-ACK Packets With Data
We haven't had an event like this in a while... "Odd Packets"! I was going through some honeypot packet captures with tcpflow, when I got this error message:
$ tcpflow -r ../allpackets Wifipcap() tcpflow: TCP PROTOCOL VIOLATION: SYN with data! (length=970)
It has been a while since I got SYN packets with data! So I had to look closer:
$ tcpdump -r ../allpackets -nX 'tcp[13]=2 && ip[2:2]- ((ip[0]&0x0f)*4)-(tcp[12]>>4)*4>0' reading from file ../allpackets, link-type EN10MB (Ethernet)
Nothing! Is tcpflow wrong? Well... I may be a bit too picky with tcp[13]=2. Lets make Judy proud and use a bitmask:
tcpdump -r /tmp/allpackets -xn 'tcp[13]&2=2 && ip[2:2]- ((ip[0]&0x0f)*4)-(tcp[12]>>4)*4>0' reading from file /tmp/anon2, link-type EN10MB (Ethernet) 08:43:59.138235 IP 192.0.2.1.9090 > 192.0.2.2.27450: Flags [S.], seq 159625496:159626466, ack 770903892, win 12960, length 970 0x0000: 4508 03f2 530f 4000 2e06 71eb c000 0201 0x0010: c000 0202 2382 6b3a 0983 b118 2df3 0f54 0x0020: 5012 32a0 6ec5 0000 0000 0000 0000 0000 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
Here we got it. It was actually a SYN-ACK, not a SYN that had the payload. The payload was all 0x00 (I truncated the output).
There was no SYN going to that IP address, so this was an unsolicited response ("backscatter"). Has anybody seen traffic like this? So far, this was the only packet I have seen. The original source IP was 112.74.152.143. DoS agains the analyst? Or some kind of new TCP based reflective DoS off a real broken service?
Application Security: Securing Web Apps, APIs, and Microservices | Washington | Dec 13th - Dec 18th 2024 |
Comments
Using TFO to send a bunch of zeros doesn’t seem to make much sense for any legitimate use, though.
For anyone who wants to catch payload-carrying SYNs with iptables, there’s a nifty trick at the bottom of this page: http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html
Anonymous
Jan 30th 2016
8 years ago