[Bro-Dev] [JIRA] (BIT-1264) HTTP response not detected on nonstandard port

[Jon Siwek (JIRA)]

    [ https://bro-tracker.atlassian.net/browse/BIT-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18216#comment-18216 ] 

Jon Siwek commented on BIT-1264:
--------------------------------

The difference here is in [likely_server_ports|https://www.bro.org/sphinx/scripts/base/init-bare.bro.html?highlight=likely_server_ports#id-likely_server_ports].

Because 80/tcp is in the likely_server_ports set, Bro correctly infers the packets belong to the responder, then your signature matches.

Because 4321/tcp isn't in the set, Bro thinks the packets are from the originator, then the signature doesn't match because it requires checking against the responder's payload.  And if you did force the signature to match by taking away the "is responder" condition, the HTTP analyzer would still ignore the content because it looks like data coming from the originator without having fully set up a TCP connection -- that's generally a situation where the current HTTP analyzer doesn't deal well.

> HTTP response not detected on nonstandard port
> ----------------------------------------------
>
>                 Key: BIT-1264
>                 URL: https://bro-tracker.atlassian.net/browse/BIT-1264
>             Project: Bro Issue Tracker
>          Issue Type: Problem
>          Components: Bro
>    Affects Versions: git/master
>         Environment: CentOS 6
>            Reporter: Jimmy Jones
>         Attachments: relaxed.bro, relaxed-http.sig, sample-small2-rsp.pcap, sample-small-rsp.pcap
>
>
> Using the attached bro script I've tweaked the HTTP signature to match on http responses without the corresponding HTTP request TCP session. I know in a proper setup you should never get single sided traffic, but certainly when using bro as a tool you have to deal with it sometimes.
> Bro handles this fine when the HTTP is on port 80, but not when on port 4321 (see attached PCAPs). I'm curious as to why?



--
This message was sent by Atlassian JIRA
(v6.4-OD-05-009#64003)