Justin Azoff created BIT-1535:
---------------------------------
Summary: conn.log conn_state field or documentation is wrong
Key: BIT-1535
URL: https://bro-tracker.atlassian.net/browse/BIT-1535
Project: Bro Issue Tracker
Issue Type: Problem
Components: Bro
Affects Versions: 2.4
Reporter: Justin Azoff
There is an issue where the conn.log conn_state field will contain RSTR, which
according to the documentation means "Established, responder aborted."
The problem that I notice is that I see log entries where conn_state is RSTR,
but conn_history does not contain an 'h'. Additionally, the resp_h is
absolutely not running a service on resp_p and the orig_h is usually in the
process of a tcp scan.
Here are the top frequencies of RSTR without an h over about a weeks worth of
conn logs:
{code}
38193 RSTR Fr
3662 RSTR DFr
1801 RSTR DFdrR
1248 RSTR DRr
432 RSTR DrF
232 RSTR Far
128 RSTR DdAFrR
79 RSTR DFadrR
64 RSTR DrR
58 RSTR DdAFarR
{code}
Compared to histories that did contain an h:
{code}
425398 RSTR ShADadFr
204149 RSTR ShADadFrR
156303 RSTR ShADdFar
141795 RSTR ShADadFRRr
105704 RSTR ShADadfr
79697 RSTR ShADadr
63493 RSTR ShADaFr
51704 RSTR ShADadFrrrr
42075 RSTR ShADdar
37678 RSTR ShADadfRr
{code}
I don't have a pcap for this, but I believe many of the weird connections are
related to scans or backscatter.
I'm not sure if the code is wrong or the documentation is wrong, but I don't
see how a fin+reset connection could be classified as established.
Also, One thing that would be a nice documentation addition is the answer to
this question:
Given a conn.log entry, how do determine if there was a connection established?
I thought it would be if the state was in 'SF S1 S2 S3 RSTO RSTR', but RSTR is
problematic...
--
This message was sent by Atlassian JIRA
(v7.1.0-OD-06-005#71002)
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
