[Snort-sigs] Why not to use flags:AP

Matthew Watchinski mwatchinski at ...435...
Thu Jul 22 08:05:18 EDT 2004

Lately I've been noticing a lot of rules coming into this list that use "flags:AP" and not the flow keyword.  So I thought it would be relevant to outline why flags:AP isn't used anymore in the snort rule set.  I hope this is useful to everyone.


      Why not to use flags:AP in a Snort rule

Years and versions ago, the only way to write a TCP rule 
that examined packet content was to use the flags keyword.
This refers to the flags bits set in the TCP header that
indicate the state of the TCP connection. However, there
were and are problems with using the flags keyword - namely
there is no idea of "state".

An established TCP session involves the notion of the
three-way handshake.  This means that a client host requests
a connection to a server port by sending it a TCP packet
with the SYN flag set.  If the server listens at the requested
port, it returns a packet with both the SYN and ACK flags set.
Finally, if the client still wants to connect, it sends a 
packet to the server with the ACK flag set.  Now, data can
be sent legitimately between the client and server.

When the keyword flow is used with a qualifier of established
(flow:to_server,established or flow:to_client,established),
it means that Snort will only look at connections that have
gone through the three-way handshake and are real established
connections.  This is quite important and represents a great
improvement over the more primitive keyword flags.  Snort is
now capable of keeping track of state - in this case, of
established connections.

Compare this to the "flag:AP".  This tells Snort to look for
any TCP packet with both the ACK and PUSH flags set.  This
does not have any idea of state or of established connections.
In "normal" traffic, you should only see this type of traffic
in established sessions.  But, there are several problems.
First, content can be pushed with just the ACK flag set.  It
isn't necessary to have the PUSH flag set to send content.

The second is that a malicious user could attack your Snort
host by sending bogus TCP packets with the ACK and PUSH
flags set and include the content that would cause a Snort
rule to fire.  In fact, there were tools created, such as
stick and snot, just to create denial of service attacks 
against Snort boxes by sending these bogus packets with
 the exclusive intention of generating boatloads of alerts 
and essentially causing a denial of service against the 
analyst examining the alerts.

Snort has evolved substantially in its ability to examine
traffic statefully.  Make sure that you write rules that
take advantage of these improvements by using the flow
keyword with the qualifier of established when writing
rules to examine content of normal TCP traffic.  

The flags keyword is still used infrequently mostly
when looking for specific flag setting, perhaps that
might be found in a denial of service.  Most times,
though, the flow keyword with the established 
qualifier will nicely supersede the flags keyword.

For more information on stateful TCP connections,
take a look at the most excellent reference:

TCP/IP Illustrated Volume 1 - The Protocols
W. Richard Stevens

More information about the Snort-sigs mailing list