[Snort-devel] Evading Snort via splitting ACKs
roesch at ...402...
Wed Sep 25 06:30:07 EDT 2002
FWIW, I have seen FTP servers send out packets on data connections without
the ACK flag being set. I always thought that it was non-RFC compliant, but
in the cases where I've seen it happen it's never caused the file xfer to
Anyway, the 1.9 ruleset should be replacing all of the "flags: A+;" checks
with "flow: established;" in the very near future, so this will cease to be
an issue very shortly.
On 9/24/02 9:12 AM, "Marc Norton" <marc.norton at ...402...> wrote:
> The Comer/Stevens book indicates the Final Ack of the 3 way handshake
> may in fact have data with it, in fact his example code finishes the
> connection and then passes the packet to a data handling routine to
> process any associated data. I believe TTCP in fact needs this feature
> to operate, but I have not used that in a few years so I may off there.
> The payload in the final ack of a connection handshake is not all that
> unusual in my experience. I find it very unusual to hear of an IP stack
> accepting a TCP packet with data but without an ACK flag on an
> established connection. After all the ack field is crucial to
> maintaining the proper and complete picture of session sequencing. But,
> alas the actual strictness of this requirement and it's implementation
> is not covered well in the literature. And, as you point out,
> implementations are often found lacking. If you checked out Stevens Vol
> II let us know, it's an interesting point.
> -----Original Message-----
> From: snort-devel-admin at lists.sourceforge.net
> [mailto:snort-devel-admin at lists.sourceforge.net] On Behalf Of David J.
> Sent: Monday, September 23, 2002 4:15 PM
> To: Phil Wood
> Cc: snort-devel at lists.sourceforge.net
> Subject: Re: [Snort-devel] Evading Snort via splitting ACKs
> On Mon, 2002-09-23 at 14:46, Phil Wood wrote:
>> I do believe that you can formulate a packet that looks like tcp with
>> the exception of an ack bit, and has as much data you can cram in to
>> it or multiple fragments, up to 65,635 octets. Also, a rule that
>> expects the ack bit will no be exercised under those conditions.
>> However, a tcp implimentation that doesn't drop the segment and
>> return to await a properly formed tcp packet is a broken
>> Or, I don't understand RFC 793 all that well.
> I think you do understand RFC 793, but not all TCP implementors did. My
> informal testing has shown that Microsoft's TCP (at least in NT4, the
> box I tested against) correctly failed to reply to my query. But all
> Linux boxes processed it just fine. I haven't tried Sun or HP yet,
> or newer versions of Windows.
> I just rechecked RFC 793, and it confirms that the ACK flag isn't really
> optional on an established connection, though I'd like to see what the
> Stevens book has to say on the subject when I get home.
Martin Roesch - Founder/CTO Sourcefire Inc. - (410) 290-1616
Sourcefire: Professional Snort Sensor and Management Console appliances
roesch at ...402... - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org
More information about the Snort-devel