[Bro-Dev] [JIRA] (BIT-1535) conn.log conn_state field or documentation is wrong

Robin Sommer (JIRA) jira at bro-tracker.atlassian.net
Thu Mar 3 07:58:00 PST 2016

     [ https://bro-tracker.atlassian.net/browse/BIT-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robin Sommer reassigned BIT-1535:

    Assignee: Robin Sommer

> 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
>            Assignee: Robin Sommer
> 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

More information about the bro-dev mailing list