[Bro] Bro behind a TLS reverse proxy

[Michał Purzyński]

To help with the investigation, I also observed a similar behavior on some
CentOS 7.x hosts, when capturing traffic into a pcap on a live system would
result in some packets being saved with the 70's timestamp.

The question remain - is that a kernel bug, a network card bug, a driver
bug?

On Mon, Apr 9, 2018 at 1:33 PM, Seth Hall <seth at corelight.com> wrote:

> I don't know how it happened, but the timestamp for the SYN/ACK packet in
> your pcap is March 22, 1970. Bro uses the timestamps from packets to track
> it's notion of time moving forward and with Bro's internal clock being
> shoved around by nearly 50 years twice in the span of three packets will
> throw it off pretty badly (lots of timeouts take place). ;)
>
> Any clue why the timestamp on that packet would be like that? It's just
> the one packet in your pcap that is messed up too.
>
> .Seth
>
> On 9 Apr 2018, at 11:56, Brandon Sterne wrote:
>
> Hi Justin,
>
> Thank you for the reply. I don't think it is the MTU that is preventing
> the sensor from decoding the traffic correctly. I ran the same test case
> with snaplen=65535 and still received only the connection_established
> event:
>
> [vagrant at localhost security-gateway]$ sudo bro -C -i lo snaplen=65535
> rules/bro/detect-http-request.bro
> <params>, line 1: listening on lo, capture length 65535 bytes
>
> Connection: , [id=[orig_h=127.0.0.1, orig_p=34902/tcp, resp_h=127.0.0.1,
> resp_p=80/tcp], orig=[size=0, state=4, num_pkts=1, num_bytes_ip=60,
> flow_label=0], resp=[size=0, state=4, num_pkts=0, num_bytes_ip=0,
> flow_label=0], start_time=1523289116.669146, duration=-1516793840.109909,
> service={
>
> }, history=Sh, uid=Ch6Tqk39qjgHi6li88, tunnel=<uninitialized>,
> dpd=<uninitialized>, conn=<uninitialized>, extract_orig=F, extract_resp=F,
> thresholds=<uninitialized>, dhcp=<uninitialized>, dnp3=<uninitialized>,
> dns=<uninitialized>, dns_state=<uninitialized>, ftp=<uninitialized>,
> ftp_data_reuse=F, ssl=<uninitialized>, http=<uninitialized>,
> http_state=<uninitialized>, irc=<uninitialized>, krb=<uninitialized>,
> modbus=<uninitialized>, mysql=<uninitialized>, radius=<uninitialized>,
> rdp=<uninitialized>, sip=<uninitialized>, sip_state=<uninitialized>,
> snmp=<uninitialized>, smtp=<uninitialized>, smtp_state=<uninitialized>,
> socks=<uninitialized>, ssh=<uninitialized>, syslog=<uninitialized>]
>
> I'm attaching the script I'm using and the pcap for the same request,
> taken with:
> sudo tcpdump -i lo -s 0 -w port8080.pcap
>
> Thanks,
> Brandon
>
>
> On Wed, Apr 4, 2018 at 3:01 PM, Azoff, Justin S <jazoff at illinois.edu>
> wrote:
>
>>
>> > On Apr 2, 2018, at 12:04 AM, Brandon Sterne <brandon.sterne at gmail.com>
>> wrote:
>> >
>> > Hello,
>> >
>> > I am attempting to get Bro working sitting behind a reverse proxy
>> (nginx), which is receiving connections, terminating TLS, and forwarding
>> cleartext HTTP to a local app server (Tomcat). I have a really simple test
>> case that demonstrates the problem I'm running into, which is that Bro HTTP
>> events are only detected when requests are sent plaintext (without TLS).
>> Here is the test case I'm using:
>>
>> The output you have included is not enough to tell what is wrong.
>> Minimally, full conn.log entries are required to figure out what bro is
>> seeing.  Even better would be a full pcap of the traffic that bro is not
>> properly decoding.
>>
>> To just guess, i'd say your problem is that the MTU on lo is 65536 and
>> bro is not configured by default to handle that.  Throwing a
>>
>> redef Pcap::snaplen = 65536
>>
>> in your script may get things working.
>>
>>
>> —
>> Justin Azoff
>>
>>
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
> --
> Seth Hall * Corelight, Inc * www.corelight.com
>
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180409/3e9a634b/attachment.html