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 bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev