[Snort-devel] Evading Snort via splitting ACKs

Martin Roesch 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
fail.

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.

     -Marty


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.
> Bianco
> 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
> silently
>> return to await a properly formed tcp packet is a broken
> implimentation.
>> 
>> 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.
> 
> David

-- 
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 mailing list