Educause Security Discussion
mailing list archives
Re: Data in SYN Packets
From: scott hollatz <shollatz () D UMN EDU>
Date: Tue, 27 Mar 2007 10:54:45 -0500
-----BEGIN PGP SIGNED MESSAGE-----
In our IPS log I see the following entry *TCP C2S Ambiguity: Data in
SYN Packet* daily directed towards our DNS server. These packets are
coming from four or so different addresses in China. I did a brief
Google search with results being a few or more years old. A couple of
the posts reported the same *Data in SYN Packet* with the
originating addresses also from China.
Can anybody shed light on this?
Well, it may be somebody is actually deploying this RFC:
1644 T/TCP -- TCP Extensions for Transactions Functional
Specification. R. Braden. July 1994. (Format: TXT=87362 bytes)
(Updates RFC1379) (Status: EXPERIMENTAL)
(Executive summary from the RFC: follows)
TCP A (Client) TCP B (Server)
#1 SYN-SENT* --> <SYN,data1,FIN,CC=x> --> CLOSE-WAIT*
(TAO test OK)
#2 TIME-WAIT <-- <SYN,ACK(FIN),data2,FIN,CC=y,CC.ECHO=x>
#3 TIME-WAIT --> <ACK(FIN),CC=x> --> CLOSED
Most of the deployment I've seen has been broken spamware that did it
basically in a fire-n-forget mode, targeting the fact that at least one
high-market-share vendor's TCP stack was buggy and would queue up the
whole SMTP transaction without bothering to actually check everything, so
spamware could send a SYN EHLO MAIL FROM RCPT TO DATA <text> . in one long
fragmented packet and it would actually work. Gaak.
The original observation was to TCP 53 not TCP 25.
The above scenario is interesting, though, but the SMTP transaction
would fail on MTAs which implement a pre-greet strategy similar to what's
scott hollatz net shollatz () d UMn eDu
information technology systems and services tel +1 218 726 8851
university of minnesota duluth mn usa fax +1 218 726 7674
"Asn aD ta zlAp em uT zt33rg"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (SunOS)
-----END PGP SIGNATURE-----