Assuming the state of a connection is established, and data has been
transferred to and fro
and then the server sends a RST packet (or two) [1] to the client and
the session ends soon after.
From an IDS/IPS standpoint,
- should the session be transitioned to closed upon seeing the first RST ?
- if not, is the session marked as SEEN_RST or something and timed out ?
From an IPS point of view (which does not allow stateless traffic)
knowing when to remove the connection is critical. is'nt it ?
I would like to know from bro standpoint and in general.
Thanks a lot for any information/viewpoint.
-Ashley
[1] Why does the server send two RST as in the example below --
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.