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

Robin Sommer (JIRA) jira at bro-tracker.atlassian.net
Fri Mar 4 20:34:01 PST 2016


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

Robin Sommer updated BIT-1535:
------------------------------
    Resolution: Merged  (was: Fixed)
        Status: Closed  (was: Merge Request)

> 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
(v7.2.0-OD-03-010#72000)


More information about the bro-dev mailing list