[Snort-devel] RE: [Snort-users] Why flags PA?
cec at ...56...
Wed Nov 29 10:19:09 EST 2000
On Wed, 29 Nov 2000, Reckhard, Tobias wrote:
> Hi Guy and thanks for the response.
> > One of the reasons it alerts on a PA flags is to minimize the false
> > positive. You will only get an alert upon successful connections.
> I understand that this is what the 'A' flag, which indicates that the ACK
> bit must be set, will do. I do not see the reason for requiring the PSH bit
> to be set.
> > If you want to see all the attempts, you either have to modify the
> > signatures, add you own signatures or use your firewall logs to see if an
> > attempt to specific a port occurred.
> Thanks for the explanation (honestly), but I know that. I'm just wondering
> why the PSH bit is used in so many Snort rules. It seems like an invitation
> to avoid detection by Snort to simply make sure the attack client one uses
> does not set the PSH bit. Or am I missing something?
My understanding of the TCP agrees with yours. PUSH is not a necessary
flag to have either end of the TCP connection receive the data contained
in a packet. ACK (I believe) is necessary. I've been holding off on
mentioning this to the list because I've been tied up with a few other
The basic answer is that the TCP specifications don't require a PUSH flag
to see data. Most implementations would put one there out of standard
practice. This means that the bulk of TCP connections will have the PUSH
flag set. Handcrafted packets would not necessarily have the PUSH flag
There are a couple of solutions to this. One is to change all rules to
have: "flags: A+". This will be true if ACK plus any other flag is set.
Here's the problem, not all flag combinations yield a valid data
packet. I could perform a denial of service attack on your NIDS if I
flooded you with packets containing an attack signature and an invalid
flag combination (e.g. ACK | RST), the victim machine would ignore the
data, the NIDS would flase alarm. (hmm, I may need to fix this in the TCP
Another solution is to double the number of rules so that every rule had
one instance with flags = ACK, another with flags = PUSH|ACK. The problem
here is obvious, double the number of rules.
My suggestion would be that we add a new flag type to the flag checker,
possibly something like: 'D' which would indicate a set of valid Data
flags. This would return a value of TRUE with normal packets where the
flags are set to PUSH|ACK, and with crafted packets where just the ACK
Dr. Christopher E. Cramer
Assistant Research Professor
Duke University, Department of Electrical and Computer Engineering
114 Hudson Hall, Box 90291, Durham, NC 27708-0291
PH: 919-660-5248 FAX: 919-660-5293 email: cec at ...56...
More information about the Snort-devel