[Bro] RST handling

[Robin Sommer]

On Sun, Aug 12, 2007 at 22:45 -0400, Adayadil Thomas wrote:

> I would like to know from bro standpoint and in general.

The general problem here is that a passive NIDS can never be sure
about what the endpoints' state of a connection is. A NIDS monitors
the traffic and uses a bunch of heuristics to understand what's
going on but it's unrealistic to assume that each host on the
Internet conforms with the RFCs. On the one hand an attacker can
always craft non-conforming traffic; on the other hand, and worse,
there's just a larger number of software out there which interprets
the standards rather "liberally" (and sometimes cannot even be
blamed for that because standards often ignore corner-case and
rarely specifcy behaviour for non-conforming traffic). 

This is the case for keeping track of TCP states, as in your
example, and also for lots of the classic evasion attacks like
overlapping TCP payload. 

Bro tries hard to detect ambigious cases; that's what all these
"weirds" are about. And it has a large number of options to tweak
the details of its processing (e.g., there are timeouts which tell
Bro how long to wait after the presumed end of connection before
actually timing the state out, allowing for more packets to arrive
during this interval like duplicated resets). That's as much as it
can do however.

An active system (i.e., a NI*P*S) can do more if you are willing to
accept the impact that it may have on your network traffic. In
general, a NIPS can either simply block all traffic which it can't
reliably interpret or it can try to normalize it by rewriting the
packets into a more well-defined state. 

Robin

-- 
Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org 
LBNL/ICSI    * Fax   +1 (510) 666-2956 *   www.icir.org