Sample "Hello, World" Application

From brandon.sterne at gmail.com Sun Apr 1 21:04:39 2018 From: brandon.sterne at gmail.com (Brandon Sterne) Date: Sun, 1 Apr 2018 21:04:39 -0700 Subject: [Bro] Bro behind a TLS reverse proxy Message-ID: 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: ``` [guest-vm-bro]$ cat ~/bro-custom/detect-http-request.bro ##! Basic rule to detect HTTP request @load base/protocols/http module HTTP; event http_request(c: connection, method: string, original_URI: string, unescaped_URI: string, version: string) &priority=3 { print "HTTP request. URI: ", original_URI; } event connection_established(c: connection) { print "Connection: ", c; } [guest-vm-bro]$ sudo /usr/local/bro/bin/bro -C -i eth1 ~/bro-custom/detect-http-request.bro listening on eth1 ``` Everything works as expected when requests are sent as plaintext to nginx port 80: ``` [host-os]$ curl http://uis.local/sample/ Sample "Hello, World" Application snip... [guest-vm-bro]$ sudo /usr/local/bro/bin/bro -C -i eth1 ~/bro-custom/detect-http-request.bro listening on eth1 Connection: , [id=[orig_h=192.168.43.1, orig_p=53030/tcp, resp_h=192.168.43.10, resp_p=80/tcp], orig=[size=0, state=4, num_pkts=1, num_bytes_ip=64, flow_label=0, l2_addr=0a:00:27:00:00:03], resp=[size=0, state=4, num_pkts=0, num_bytes_ip=0, flow_label=0, l2_addr=08:00:27:18:49:26], start_time=1522451133.083394, duration=0.000023, service={ }, history=Sh, uid=CSecNs4PkfexRaPAp4, tunnel=, vlan=, inner_vlan=, dpd=, conn=, extract_orig=F, extract_resp=F, thresholds=, dce_rpc=, dce_rpc_state=, dce_rpc_backing=, dhcp=, dnp3=, dns=, dns_state=, ftp=, ftp_data_reuse=F, ssl=, http=, http_state=, irc=, krb=, modbus=, mysql=, ntlm=, radius=, rdp=, rfb=, sip=, sip_state=, snmp=, smtp=, smtp_state=, socks=, ssh=, syslog=] HTTP request. URI: , /sample/ ``` Note the last line, where the http_request event triggered correctly. When I send the request to the TLS encrypted nginx port, however, I only see the connection_established event fire: ``` [host-os]$ curl -k https://uis.local/sample/ Sample "Hello, World" Application snip... Connection: , [id=[orig_h=192.168.43.1, orig_p=53078/tcp, resp_h=192.168.43.10, resp_p=443/tcp], orig=[size=0, state=4, num_pkts=1, num_bytes_ip=64, flow_label=0, l2_addr=0a:00:27:00:00:03], resp=[size=0, state=4, num_pkts=0, num_bytes_ip=0, flow_label=0, l2_addr=08:00:27:18:49:26], start_time=1522451394.887197, duration=0.000024, service={ }, history=Sh, uid=Ce2kbh4wXUDiXtRC1i, tunnel=, vlan=, inner_vlan=, dpd=, conn=, extract_orig=F, extract_resp=F, thresholds=, dce_rpc=, dce_rpc_state=, dce_rpc_backing=, dhcp=, dnp3=, dns=, dns_state=, ftp=, ftp_data_reuse=F, ssl=, http=, http_state=, irc=, krb=, modbus=, mysql=, ntlm=, radius=, rdp=, rfb=, sip=, sip_state=, snmp=, smtp=, smtp_state=, socks=, ssh=, syslog=] ``` A similar event pattern happens if I change the Bro agent to listen on the loopback interface: ``` [host-os]$ curl http://uis.local/sample/ Sample "Hello, World" Application snip... [host-os]$ curl -k https://uis.local/sample/ Sample "Hello, World" Application snip... [guest-vm-bro]$ sudo /usr/local/bro/bin/bro -C -i lo ~/bro-custom/detect-http-request.bro listening on lo Connection: , [id=[orig_h=127.0.0.1, orig_p=58658/tcp, resp_h=127.0.0.1, resp_p=8080/tcp], orig=[size=0, state=4, num_pkts=1, num_bytes_ip=60, flow_label=0, l2_addr=], resp=[size=0, state=4, num_pkts=0, num_bytes_ip=0, flow_label=0, l2_addr=], start_time=1522451684.380294, duration=-1513581075.701362, service={ }, history=Sh, uid=C3NJSO38EkH9aVSRe8, tunnel=, vlan=, inner_vlan=, dpd=, conn=, extract_orig=F, extract_resp=F, thresholds=, dce_rpc=, dce_rpc_state=, dce_rpc_backing=, dhcp=, dnp3=, dns=, dns_state=, ftp=, ftp_data_reuse=F, ssl=, http=, http_state=, irc=, krb=, modbus=, mysql=, ntlm=, radius=, rdp=, rfb=, sip=, sip_state=, snmp=, smtp=, smtp_state=, socks=, ssh=, syslog=] Connection: , [id=[orig_h=127.0.0.1, orig_p=58660/tcp, resp_h=127.0.0.1, resp_p=8080/tcp], orig=[size=0, state=4, num_pkts=1, num_bytes_ip=60, flow_label=0, l2_addr=], resp=[size=0, state=4, num_pkts=0, num_bytes_ip=0, flow_label=0, l2_addr=], start_time=1522451702.019632, duration=-1513505330.101316, service={ }, history=Sh, uid=CqvuUv2nDCAjXdUcAg, tunnel=, vlan=, inner_vlan=, dpd=, conn=, extract_orig=F, extract_resp=F, thresholds=, dce_rpc=, dce_rpc_state=, dce_rpc_backing=, dhcp=, dnp3=, dns=, dns_state=, ftp=, ftp_data_reuse=F, ssl=, http=, http_state=, irc=, krb=, modbus=, mysql=, ntlm=, radius=, rdp=, rfb=, sip=, sip_state=, snmp=, smtp=, smtp_state=, socks=, ssh=, syslog=] ``` In this case, I don't receive an http_request event for either the plaintext or encrypted request sent to nginx. The last case I tested was sending a request directly to the app server from the guest VM running Bro. In this case I only saw the connection_established event again, not the http_request event: ``` [guest-vm-bro]$ curl localhost:8080/sample/ Sample "Hello, World" Application snip... Connection: , [id=[orig_h=127.0.0.1, orig_p=58664/tcp, resp_h=127.0.0.1, resp_p=8080/tcp], orig=[size=0, state=4, num_pkts=1, num_bytes_ip=60, flow_label=0, l2_addr=], resp=[size=0, state=4, num_pkts=0, num_bytes_ip=0, flow_label=0, l2_addr=], start_time=1522451893.753416, duration=-1512682034.693552, service={ }, history=Sh, uid=CdewMq37K1zzhpTl91, tunnel=, vlan=, inner_vlan=, dpd=, conn=, extract_orig=F, extract_resp=F, thresholds=, dce_rpc=, dce_rpc_state=, dce_rpc_backing=, dhcp=, dnp3=, dns=, dns_state=, ftp=, ftp_data_reuse=F, ssl=, http=, http_state=, irc=, krb=, modbus=, mysql=, ntlm=, radius=, rdp=, rfb=, sip=, sip_state=, snmp=, smtp=, smtp_state=, socks=, ssh=, syslog=] ``` This was with Bro still listening on lo interface. This case surprises me. It's a simple GET request to a local HTTP server on 8080, so I'm curious why this doesn't trigger an http_request event. Just to be complete, I also re-ran this last test with Bro listening on eth1, and neither the connection_established or the http_request event fired. I would love some help if any of you are willing to provide it. My two questions are essentially: 1. What needs to be observed by the agent for a http_request event to fire? 2. Does Bro treat traffic traversing the localhost only differently than traffic it receives over the network? Thanks very much, in advance, for reading through this and for helping me to understand what is happening in this case. Best, Brandon Sterne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180401/7f5abcfc/attachment.html From rahulbroids at gmail.com Sun Apr 1 23:43:40 2018 From: rahulbroids at gmail.com (rahul rakesh) Date: Mon, 2 Apr 2018 12:13:40 +0530 Subject: [Bro] Snort 2 Bro Utility Message-ID: Dear Team, Can anyone please share snort2bro utility as i just wanted to know how the conversion is done. It will help me writing signatures. Regards, Rahul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180402/2eb46f1b/attachment.html From ambros.novak.89 at gmail.com Mon Apr 2 03:35:20 2018 From: ambros.novak.89 at gmail.com (Ambros Novak) Date: Mon, 2 Apr 2018 06:35:20 -0400 Subject: [Bro] Original file name in Extracted files Message-ID: <3D256AB8-AD30-476B-B69E-3CAB039D48EA@gmail.com> Hello! How can the original file name be added to the extracted file name? Thanks you for your help. AN ?? From philosnef at gmail.com Mon Apr 2 06:22:15 2018 From: philosnef at gmail.com (erik clark) Date: Mon, 2 Apr 2018 09:22:15 -0400 Subject: [Bro] gluing together suricata and bro alerts in kibana Message-ID: I am trying to make splunk like searchs in Kibana, but can't figure out how the syntax works. EG: I have alert.signature == myalert, with http.hostname == somedomain. In bro, I rewrote host to http_host, and want to see the intersection of: conn.log (conn id) http.log (http.hostname from suricata events linked to http_host bro events here) alert.signature (from suricata events) So the result would be in a table I would hope, or soething like that: http_host, http.http_content_type, http.http_method, http.http_user_agent, http.http_response_body_printable, payload_printable, fileinfo.filename, dest_ip, src_ip, conn_id Drop down events like what you normally get would be fine as well. Hope this helps explain what I am trying to do. I am still struggling with lucerne search syntax and the front end. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180402/9dd4831e/attachment.html From patrick.kelley at criticalpathsecurity.com Mon Apr 2 06:43:27 2018 From: patrick.kelley at criticalpathsecurity.com (Patrick Kelley) Date: Mon, 2 Apr 2018 09:43:27 -0400 Subject: [Bro] Snort 2 Bro Utility In-Reply-To: References: Message-ID: Rahul, That utility has been long deprecated, largely due to difference in approach by Snort and Bro. I'll share the demo signature below. As always, feel free to reach out directly, should you need. signature my-first-sig { ip-proto == tcp dst-port == 80 payload /.*root/ event "Found root!" } On Mon, Apr 2, 2018 at 2:43 AM, rahul rakesh wrote: > Dear Team, > Can anyone please share snort2bro utility as i just wanted to > know how the conversion is done. It will help me writing signatures. > > > > Regards, > Rahul > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > -- *Patrick Kelley, CISSP, C|EH, ITIL* *CTO* patrick.kelley at criticalpathsecurity.com (o) 770-224-6482 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180402/ad78ccd7/attachment.html From jsiwek at corelight.com Mon Apr 2 08:03:38 2018 From: jsiwek at corelight.com (Jon Siwek) Date: Mon, 2 Apr 2018 10:03:38 -0500 Subject: [Bro] [BRO-ISSUE]: bro crash when so many Repoter::Error calls In-Reply-To: References: Message-ID: <35cd8c39-f61a-acab-d01c-8887e3e6b1c9@corelight.com> On 1/25/18 10:18 AM, Myth Ren wrote: > ? ? I'm using bro 2.5.1 for network security monitoring , the message > queue is kafka componment (the bro-to-kafka plugin version is v0.5.0, > librdkafka version is v0.9.5). The plugins from Bro v2.5.1 may be a bit old to continue using. I'd generally suggest trying to update to newest version of everything. > Below listed information is backtrace from core dump. (more on gist > ) > #4? 0x00000000005fee8f in Reporter::Error (this=, > fmt=fmt at entry=0x7fe36c719d70 "Kafka send failed: %s") at > /opt/download/bro/src/Reporter.cc:76 #5? 0x00007fe36c717fa9 in > logging::writer::KafkaWriter::DoWrite (this=0x6369270, > num_fields=, fields=, vals=0x69d2080) > at /opt/download/bro/aux/plugins/kafka/src/KafkaWriter.cc:156 #6 This is basically the problem: this version of KafkaWriter is directly using Reporter calls and that's not thread-safe. Here would be the way to fix it for your reference (in case you simply can't update things): https://github.com/apache/metron-bro-plugin-kafka/commit/4968b6537f663c1de061d0cf0aedb42f43ab12ee - Jon From pssunu6 at gmail.com Mon Apr 2 22:46:48 2018 From: pssunu6 at gmail.com (ps sunu) Date: Tue, 3 Apr 2018 11:16:48 +0530 Subject: [Bro] jzeolla-metron-bro-plugin-kafka In-Reply-To: References: Message-ID: Thanks Zeolla , its working fine with ssl key , again thanks On Fri, Mar 30, 2018 at 5:14 AM, Zeolla at GMail.com wrote: > Please see my response in https://github.com/JonZeolla/jzeolla-metron-bro- > plugin-kafka/issues/3 > > The summary is, in theory yes but I've never tested it. It uses > librdkafka underneath, which has ssl support. See > https://github.com/edenhill/librdkafka/wiki/Using-SSL-with-librdkafka and > https://github.com/apache/metron-bro-plugin-kafka/blob/master/README.md > > Any configuration value accepted by librdkafka can be added to the > kafka_conf configuration table. > > Jon > > On Thu, Mar 29, 2018, 12:05 ps sunu wrote: > >> Hi, >> is jzeolla-metron-bro-plugin-kafka support with ssl key >> support ? i am not finding any example for this >> >> https://github.com/JonZeolla/jzeolla-metron-bro-plugin-kafka >> >> >> Regards, >> Sunu >> _______________________________________________ >> Bro mailing list >> bro at bro-ids.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > > -- > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180403/2d40a2f2/attachment.html From mfernandez at mitre.org Tue Apr 3 02:15:40 2018 From: mfernandez at mitre.org (Fernandez, Mark I) Date: Tue, 3 Apr 2018 09:15:40 +0000 Subject: [Bro] Intel::FILE_NAME and SMB_files behavior questions In-Reply-To: References: Message-ID: Hi James, >> I don?t think the Intel framework supports wildcards ? is there a way to alert >> on files transferred that match a regex such as ?Temp\\[a-zA-Z]{8}.tmp?, >> or even: ?Temp\\*.tmp?? Use the ?file_over_new_connection? event. You could get the file name from the SMB info in the ?c : connection? input argument to the event handler. Here is some sample code: event file_over_new_connection(f:fa_file, c:connection, is_orig:bool) { if ( f?$source && f$source == "SMB" && c?$smb_state && c$smb_state?$current_file ) { local smb_path = c$smb_state$current_file$path; local smb_name = c$smb_state$current_file$name; . . .Do regex pattern matching on smb_path and/or smb_name. . . . . .Use Notice framework to raise an alert. . . } } Cheers, Mark From: bro-bounces at bro.org [mailto:bro-bounces at bro.org] On Behalf Of James Gordon Sent: Saturday, March 31, 2018 6:14 PM To: bro at bro-ids.org Subject: [Bro] Intel::FILE_NAME and SMB_files behavior questions Hey everyone, I have a few questions on behavioral issues with the intel framework and SMB / SMB file logging: 1. I?m not sure if this is expected behavior or not, but it doesn?t look like filenames parsed in smb_files.log are properly being logged in files.log. We had a red team exercise recently where our red team was able to successfully retrieve the ntds.dit file off of one of our domain controllers. This transfer occurred over SMB, so I figured we could add ntds.dit to the Intel framework so that next time we don?t have to dig in logs to find out that our domain is owned ? we?ll have a handy alert to tell us ** I did some testing with this though, and while I see ?ntds.dit? logged clearly in the name field in smb_files.log, I don?t have a corresponding entry in files.log for this file transfer, and therefore no Intel match. What makes this weirder is I have other irrelevant files from this connection logged in files.log, that I didn?t actually touch or move during this connection: bro at SObro:/nsm/bro/logs/current$ cat /opt/bro/share/bro/intel/intel.dat | grep ntds.dit ntds.dit Intel::FILE_NAME domain ownage - update your resume! F bro at SObro:/nsm/bro/logs/2018-03-31$ zcat smb_files.16\:00\:00-17\:00\:00.log.gz | bro-cut uid id.orig_h id.resp_h id.resp_p action name | grep ntds.dit C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 445 SMB::FILE_OPEN share path\\and more\\more\\my testing directory\\ntds.dit C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 445 SMB::FILE_OPEN share path\\and more\\more\\my testing directory \\ntds.dit C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 445 SMB::FILE_OPEN share path\\and more\\more\\my testing directory \\ntds.dit C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 445 SMB::FILE_OPEN share path\\and more\\more\\my testing directory \\ntds.dit C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 445 SMB::FILE_OPEN ntds.dit C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 445 SMB::FILE_OPEN ntds.dit C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 445 SMB::FILE_OPEN ntds.dit C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 445 SMB::FILE_OPEN ntds.dit If I search for ?ntds.dit? in files log, I get nothing. If I search for the connection UID in files.log, there are some files logged ? but not the only file I actually transferred over this connection! bro@ SObro:/nsm/bro/logs/2018-03-31$ zcat files.16\:00\:00-17\:00\:00.log.gz | bro-cut conn_uids tx_hosts rx_hosts source filename | grep C35jBF1HlcrVNLiXW2 C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 SMB desktop.ini C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 SMB share path\\and more\\more\\not my testing directory!? \\desktop.ini C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 SMB share path\\and more\\more\\my testing directory \\random file that lives at this path.exe C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 SMB desktop.ini C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 SMB favorites\\desktop.ini C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 SMB Random excel file that lives in my testing directory.xls C35jBF1HlcrVNLiXW2 1.1.1.1 2.2.2.2 SMB random executable that lives in my testing directory.exe Is there something wrong with my Bro instance? I feel like filenames from smb_files ?name? field should *all* be fed into files.log. I tested this with two different share paths and similar results ? everything gets logged as I would expect in smb_files.log but this filename never shows up in files.log. How can I reliably alert on file names transferred over SMB? 2. As part of the above red team exercise, I found (what I suspect) are some instances of Meterpeter being transferred from popped hosts back to the adversary system over SMB. These were logged in ?smb_files.log? with names like: ?Temp\\PBetVKZU.tmp? and ?Temp\\FapcPatS.tmp?. I don?t think the Intel framework supports wildcards ? is there a way to alert on files transferred that match a regex such as ?Temp\\[a-zA-Z]{8}.tmp?, or even: ?Temp\\*.tmp?? 3. Unrelated to the Intel framework - it seems like smb_files.log is super noisy. If I browse to a share drive, a massive amount of the contents of the share are enumerated in the smb_files log without taking any action (with the ?action? field indicating SMB::FILE_OPEN). This feels like expected behavior in SMB. Is there any way to ?filter? the log to only log files that are actually opened, written to, moved, deleted, or had any real operation occur against them? We?re running Bro 2.5.3 in Security Onion (Ubuntu 14.04). The intel framework is loaded and successfully fires on other indicators we have running. Thanks! James Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180403/6fba69b9/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6341 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180403/6fba69b9/attachment-0001.bin From email4myth at gmail.com Tue Apr 3 03:06:14 2018 From: email4myth at gmail.com (Myth Ren) Date: Tue, 3 Apr 2018 18:06:14 +0800 Subject: [Bro] [BRO-ISSUE]: bro crash when so many Repoter::Error calls In-Reply-To: <35cd8c39-f61a-acab-d01c-8887e3e6b1c9@corelight.com> References: <35cd8c39-f61a-acab-d01c-8887e3e6b1c9@corelight.com> Message-ID: currently i'm using Apache/metron-kafka-plugin v0.1 and the problem is gone. thanks Jon. 2018-04-02 23:03 GMT+08:00 Jon Siwek : > > > On 1/25/18 10:18 AM, Myth Ren wrote: > > I'm using bro 2.5.1 for network security monitoring , the message >> queue is kafka componment (the bro-to-kafka plugin version is v0.5.0, >> librdkafka version is v0.9.5). >> > > The plugins from Bro v2.5.1 may be a bit old to continue using. I'd > generally suggest trying to update to newest version of everything. > > Below listed information is backtrace from core dump. (more on gist < >> https://gist.github.com/MythRen/b55220647ca28654c6f7e1db12ee6036>) >> > > #4 0x00000000005fee8f in Reporter::Error (this=, >> fmt=fmt at entry=0x7fe36c719d70 "Kafka send failed: %s") at >> /opt/download/bro/src/Reporter.cc:76 #5 0x00007fe36c717fa9 in >> logging::writer::KafkaWriter::DoWrite (this=0x6369270, >> num_fields=, fields=, vals=0x69d2080) >> at /opt/download/bro/aux/plugins/kafka/src/KafkaWriter.cc:156 #6 >> > > This is basically the problem: this version of KafkaWriter is directly > using Reporter calls and that's not thread-safe. Here would be the way to > fix it for your reference (in case you simply can't update things): > > https://github.com/apache/metron-bro-plugin-kafka/commit/496 > 8b6537f663c1de061d0cf0aedb42f43ab12ee > > - Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180403/0037db70/attachment.html From roberixion at gmail.com Tue Apr 3 03:10:52 2018 From: roberixion at gmail.com (=?UTF-8?Q?Rober_Fern=C3=A1ndez?=) Date: Tue, 3 Apr 2018 12:10:52 +0200 Subject: [Bro] window size Message-ID: Hi, Is there any way to get the window size in a connection tcp? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180403/57515de8/attachment.html From slagell at illinois.edu Tue Apr 3 06:05:19 2018 From: slagell at illinois.edu (Slagell, Adam J) Date: Tue, 3 Apr 2018 13:05:19 +0000 Subject: [Bro] window size In-Reply-To: References: Message-ID: <633F86C9-2927-4340-A96A-A590056F524F@illinois.edu> There is no such single value for a connection, right? It adapts and changes. So what would you be looking for then? > On Apr 3, 2018, at 5:11 AM, Rober Fern?ndez wrote: > > Hi, > Is there any way to get the window size in a connection tcp? > > Thanks > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From jazoff at illinois.edu Wed Apr 4 15:01:37 2018 From: jazoff at illinois.edu (Azoff, Justin S) Date: Wed, 4 Apr 2018 22:01:37 +0000 Subject: [Bro] Bro behind a TLS reverse proxy In-Reply-To: References: Message-ID: <665D44F3-E658-4DFD-BF1E-2B9CD681ADC4@illinois.edu> > On Apr 2, 2018, at 12:04 AM, Brandon Sterne 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 From seth at corelight.com Thu Apr 5 06:16:47 2018 From: seth at corelight.com (Seth Hall) Date: Thu, 05 Apr 2018 09:16:47 -0400 Subject: [Bro] Intel::FILE_NAME and SMB_files behavior questions In-Reply-To: References: Message-ID: On 31 Mar 2018, at 18:14, James Gordon wrote: > I have a few questions on behavioral issues with the intel framework > and SMB / SMB file logging: > > 1. I?m not sure if this is expected behavior or not, but it > doesn?t look like filenames parsed in smb_files.log are properly > being logged in files.log. I checked in our autogenerated documentation and I'm now noticing a glaring lack of documentation about *what* that log represents. :( That log is meant to represent that an action against a file was seen. Considering that since SMB is a file system protocol you will see a lot of actions that aren't necessarily file transfers. Most of what I've typically seen in smb_files.log is files being opened. This seems be a very common action in SMB, I don't know all of the reasons that an application might open a file but not read nor write to it but it's definitely seen a lot. I think that it could be a way for the client to get a timestamp for a remote file or other metadata. Other actions that fits into that log are file renames and deletes. File renames are represented through the "name" and "prev_name" fields. Deletes just give the name of the file before it was deleted. The important field to look at is the "action" field since that's where the log tells you what the client was actually doing. Here are all of the potential actions that you will typically see there... FILE_OPEN, FILE_RENAME, FILE_DELETE, If you wanted, you could add FILE_CLOSE as action that you want logged if you add this to your local.bro (I chose to leave this out by default since it didn't seem to provide much extra context, but had a great increase in log size)... redef SMB::logged_file_actions += { SMB::FILE_CLOSE }; You could also have it include FILE_WRITE and FILE_READ, but those are really not great to include and lead to a massive increase in log size but I felt like transfers were better represented through the files.log anyway. Generally if data is seen as being transferred that will be represented in files.log since that's the aggregation point for all "files" seen by Bro. smb_files.log can be really helpful if you need to know when someone is poking around at files even if they aren't transferring them and there is a lot of information there that can be useful forensically (MAC times being the big one in my mind). If you have thoughts on other SMB logs that you'd like to see or if you have thoughts on extensions to the smb_files.log I'd love to hear them! There is definitely no right or wrong answer to what should be in those logs or even what logs should exist. .Seth -- Seth Hall * Corelight, Inc * www.corelight.com From gordonjamesr at gmail.com Thu Apr 5 08:24:15 2018 From: gordonjamesr at gmail.com (James Gordon) Date: Thu, 5 Apr 2018 08:24:15 -0700 Subject: [Bro] Intel::FILE_NAME and SMB_files behavior questions In-Reply-To: References:

Message-ID: Hey Seth and Mark, First off, thanks for the info! Mark, I'll work on flushing out that code - looks like exactly what I need to alert on those types of filenames (if there turns out to be value there :) ) Seth - in my testing on this, I was transferring a text document titled 'ntds.dit' over an SMB connection that Bro was monitoring. I think my confusion on this is over what the SMB analyzer chooses to send into files.log. I would expect to see the filename of a file that was written over that connection, where in this case I had files that were opened (as you mentioned, probably just by the client caching timestamps), but not the file that was actually sent over that connection. In my original email, I'd mentioned a red team 'adversary' pulled the ntds.dit file off a domain controller and sent it to his system over an SMB connection. For this connection, I have an smb_files log entry AND a files.log entry that log a filename of: temp//ntds.dit being transferred. When I created a test text document named 'ntds.dit' and sent it to a remote fileshare, bro recorded the correct name in smb_files.log, but nothing about that file in files.log! I'd like to rephrase my questions a little: 1.When does a filename seen over SMB appear in files.log? As far as flushing out some of the noise in smb_files.log - would it be possible to only log FILE_OPEN's where the file has a 'time accessed' timestamp that falls in the duration of the connection? This might not be foolproof, but could cut down on file_open noise substantially. Just brainstorming on this - but it seems like that would eliminate a lot of the noise where the smb client "opens" a file but really just grabs that file's timestamps or other metadata. On Thu, Apr 5, 2018 at 6:16 AM, Seth Hall wrote: > > On 31 Mar 2018, at 18:14, James Gordon wrote: > > I have a few questions on behavioral issues with the intel framework and >> SMB / SMB file logging: >> >> 1. I?m not sure if this is expected behavior or not, but it doesn?t look >> like filenames parsed in smb_files.log are properly being logged in >> files.log. >> > > I checked in our autogenerated documentation and I'm now noticing a > glaring lack of documentation about *what* that log represents. :( > > That log is meant to represent that an action against a file was seen. > Considering that since SMB is a file system protocol you will see a lot of > actions that aren't necessarily file transfers. Most of what I've > typically seen in smb_files.log is files being opened. This seems be a > very common action in SMB, I don't know all of the reasons that an > application might open a file but not read nor write to it but it's > definitely seen a lot. I think that it could be a way for the client to > get a timestamp for a remote file or other metadata. Other actions that > fits into that log are file renames and deletes. File renames are > represented through the "name" and "prev_name" fields. Deletes just give > the name of the file before it was deleted. > > The important field to look at is the "action" field since that's where > the log tells you what the client was actually doing. Here are all of the > potential actions that you will typically see there... > FILE_OPEN, > FILE_RENAME, > FILE_DELETE, > > If you wanted, you could add FILE_CLOSE as action that you want logged if > you add this to your local.bro (I chose to leave this out by default since > it didn't seem to provide much extra context, but had a great increase in > log size)... > > redef SMB::logged_file_actions += { SMB::FILE_CLOSE }; > > You could also have it include FILE_WRITE and FILE_READ, but those are > really not great to include and lead to a massive increase in log size but > I felt like transfers were better represented through the files.log > anyway. Generally if data is seen as being transferred that will be > represented in files.log since that's the aggregation point for all "files" > seen by Bro. smb_files.log can be really helpful if you need to know when > someone is poking around at files even if they aren't transferring them and > there is a lot of information there that can be useful forensically (MAC > times being the big one in my mind). > > If you have thoughts on other SMB logs that you'd like to see or if you > have thoughts on extensions to the smb_files.log I'd love to hear them! > There is definitely no right or wrong answer to what should be in those > logs or even what logs should exist. > > .Seth > > -- > Seth Hall * Corelight, Inc * www.corelight.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180405/5b5a1df5/attachment.html From seth at corelight.com Thu Apr 5 13:16:41 2018 From: seth at corelight.com (Seth Hall) Date: Thu, 05 Apr 2018 16:16:41 -0400 Subject: [Bro] Intel::FILE_NAME and SMB_files behavior questions In-Reply-To: References:

Message-ID: <752C045B-2898-413E-B9D3-387E95244E70@corelight.com> On 5 Apr 2018, at 11:24, James Gordon wrote: > Seth - in my testing on this, I was transferring a text document > titled > 'ntds.dit' over an SMB connection that Bro was monitoring. I think my > confusion on this is over what the SMB analyzer chooses to send into > files.log. I would expect to see the filename of a file that was > written > over that connection, where in this case I had files that were opened > (as > you mentioned, probably just by the client caching timestamps), but > not the > file that was actually sent over that connection. Now that starts to sound more like a bug or packet loss. :) Any details about the connection where you'd expect to see the file or other logs that showed up that were related would be appreciated. In an ideal world I'd also ask for a PCAP, but that sounds unlikely... maybe? Basically I'd like to hear any more of the specifics about what Bro *did* see so that we can possibly figure out what did actually happen. .Seth -- Seth Hall * Corelight, Inc * www.corelight.com From greg.grasmehr at caltech.edu Thu Apr 5 16:36:40 2018 From: greg.grasmehr at caltech.edu (Greg Grasmehr) Date: Thu, 5 Apr 2018 16:36:40 -0700 Subject: [Bro] Worker System Memory Exhaustion Message-ID: <20180405233640.7affge272ncxqfs5@dakine> Hello List, We're running Bro version 2.5-467 and shunting connections in an Arista 5100 via the excellent Dumbno. The system is essentially a Bro-in-a-box with 251G RAM and a Myricom SNF+ card. Bro spawns 32 workers to monitor a 10G link that averages roughly 5G and spikes to 7 on occasion. Logs are rotated every 1/2 hour. The current configuration has been running for about 2 weeks and thus far the only problem I have encountered is that given enough time, the workers will eventually exhaust all of the available system memory including scratch. Currently I am running a watcher process which slowly restarts the workers once available memory is < 4G and this has solved the problem, but this seems an imperfect solution thus I am wondering if anyone knows the source of the apparent memory leak? Loaded scripts are attached and thanks in advance for any informative illumination on this issue. -- Sincerely, Greg Grasmehr California Institute of Technology (Caltech) I ain't got a gat, but I have a soldering gun - W.A.Y. GPGMe: 38E2 F9BD A95E 9824 20AB 331A 9E29 D1A1 AAEE 5F42 pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x9E29D1A1AAEE5F42 -------------- next part -------------- A non-text attachment was scrubbed... Name: loaded_scripts.11:19:27-11:30:00.log.gz Type: application/x-gzip Size: 2863 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180405/c41254e6/attachment.gz From jazoff at illinois.edu Fri Apr 6 05:24:37 2018 From: jazoff at illinois.edu (Azoff, Justin S) Date: Fri, 6 Apr 2018 12:24:37 +0000 Subject: [Bro] Worker System Memory Exhaustion In-Reply-To: <20180405233640.7affge272ncxqfs5@dakine> References: <20180405233640.7affge272ncxqfs5@dakine> Message-ID: > On Apr 5, 2018, at 7:36 PM, Greg Grasmehr wrote: > > Hello List, > > We're running Bro version 2.5-467 and shunting connections in an Arista > 5100 via the excellent Dumbno. The system is essentially a Bro-in-a-box > with 251G RAM and a Myricom SNF+ card. Bro spawns 32 workers to monitor > a 10G link that averages roughly 5G and spikes to 7 on occasion. Logs > are rotated every 1/2 hour. Cool :-) > The current configuration has been running for about 2 weeks and thus > far the only problem I have encountered is that given enough time, the > workers will eventually exhaust all of the available system memory > including scratch. Less cool :-( > Currently I am running a watcher process which slowly restarts the > workers once available memory is < 4G and this has solved the problem, > but this seems an imperfect solution thus I am wondering if anyone knows > the source of the apparent memory leak? Loaded scripts are attached and > thanks in advance for any informative illumination on this issue. try commenting out @load misc/scan from local.bro. If you have a lot of address space and bro is before any firewall as opposed to after it, this is likely the source of the problems. If that fixes it there are other scan detection implementations that are a bit more efficient. ? Justin Azoff From hovsep.sanjay.levi at gmail.com Fri Apr 6 07:07:24 2018 From: hovsep.sanjay.levi at gmail.com (Hovsep Levi) Date: Fri, 6 Apr 2018 14:07:24 +0000 Subject: [Bro] Worker System Memory Exhaustion In-Reply-To: References: <20180405233640.7affge272ncxqfs5@dakine> Message-ID: This was a battle we endured for many many moons (12+ months), look to the archives for the pain and suffering. Final solution : Enable multiple loggers (now part of Bro), disable writing logs to disk and stream logs to Kafka. (Thank you KafkaLogger author) Reasoning : At some point Bro's log writing cannot keep up with the volume. Believed to be a bottleneck with the the default architecture using a single "Logger" node. Possible alternative : Enable multiple loggers, but when writing to disk you might have a possible race condition with filenames and dates. Also you'll have multiple logs for each rotation interval (ex: 4 loggers means 4 conn.log, 4 http.log, 4 ssh.log, etc...) ^ Hovsep -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180406/c5a262e8/attachment.html From jazoff at illinois.edu Fri Apr 6 07:23:40 2018 From: jazoff at illinois.edu (Azoff, Justin S) Date: Fri, 6 Apr 2018 14:23:40 +0000 Subject: [Bro] Worker System Memory Exhaustion In-Reply-To: References: <20180405233640.7affge272ncxqfs5@dakine> Message-ID: > On Apr 6, 2018, at 10:07 AM, Hovsep Levi wrote: > > This was a battle we endured for many many moons (12+ months), look to the archives for the pain and suffering. > > Final solution : Enable multiple loggers (now part of Bro), disable writing logs to disk and stream logs to Kafka. (Thank you KafkaLogger author) > > Reasoning : At some point Bro's log writing cannot keep up with the volume. Believed to be a bottleneck with the the default architecture using a single "Logger" node. > > Possible alternative : Enable multiple loggers, but when writing to disk you might have a possible race condition with filenames and dates. Also you'll have multiple logs for each rotation interval (ex: 4 loggers means 4 conn.log, 4 http.log, 4 ssh.log, etc...) > > > ^ Hovsep > Ah, yeah, it could be that too. Things got better for the most part once the logger node was introduced, so this hasn't been the problem for people recently. I think most of the remaining problems with the logger node scaling are limited to extremely large log volumes and people who had AMD systems with many slow cores.. I think you had one of those. In any case, that is easy to check for by looking at broctl top and monitoring the log lag. If the logs are not behind, the problem is something else. https://gist.github.com/JustinAzoff/01396a34c8f92d4dda1b is a script for munin that will output how old the most recent record in the conn.log is. You can just run it manually though: [jazoff at bro-dev ~]$ curl -o log_lag.py https://gist.githubusercontent.com/JustinAzoff/01396a34c8f92d4dda1b/raw/2dba7fdf93915748948b238c20de965b4636cb9e/log_lag.py [jazoff at bro-dev ~]$ python log_lag.py lag.value 5.526168 The number should be 5-10s and not growing. ? Justin Azoff From pssunu6 at gmail.com Fri Apr 6 08:19:42 2018 From: pssunu6 at gmail.com (ps sunu) Date: Fri, 6 Apr 2018 20:49:42 +0530 Subject: [Bro] docker bro with pf_ring Message-ID: How to configure docker bro with pfring any proper steps have to try ? Regards, sunu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180406/54119728/attachment-0001.html From cpearson at uidaho.edu Fri Apr 6 10:02:02 2018 From: cpearson at uidaho.edu (Pearson, Carl (cpearson@uidaho.edu)) Date: Fri, 6 Apr 2018 17:02:02 +0000 Subject: [Bro] Worker System Memory Exhaustion In-Reply-To: References: <20180405233640.7affge272ncxqfs5@dakine> Message-ID: I endorse commenting out "@load misc/scan", that really stabilized memory usage in our environment. We also commented out "@load misc/detect-traceroute" and that seemed to help as well. >From your description I don't know if this applies to your situation, but for what it's worth we use PF_RING and experienced high resource utilization initially due to PF_RING not loading correctly. The issue tracker for it is here: https://bro-tracker.atlassian.net/browse/BIT-1864 - TL;DR, change pfringclusterid in broctl.cfg to 21; if pfringclusterid is set to 0 PF_RING doesn't actually do anything even though everything will indicate it's running. Again, don't know if it applies but thought I'd throw it out there. :) Thanks, Carl University of Idaho -----Original Message----- From: bro-bounces at bro.org On Behalf Of Azoff, Justin S Sent: Friday, April 6, 2018 05:25 To: Greg Grasmehr Cc: bro at bro.org Subject: Re: [Bro] Worker System Memory Exhaustion > On Apr 5, 2018, at 7:36 PM, Greg Grasmehr wrote: > > Hello List, > > We're running Bro version 2.5-467 and shunting connections in an > Arista > 5100 via the excellent Dumbno. The system is essentially a > Bro-in-a-box with 251G RAM and a Myricom SNF+ card. Bro spawns 32 > workers to monitor a 10G link that averages roughly 5G and spikes to 7 > on occasion. Logs are rotated every 1/2 hour. Cool :-) > The current configuration has been running for about 2 weeks and thus > far the only problem I have encountered is that given enough time, the > workers will eventually exhaust all of the available system memory > including scratch. Less cool :-( > Currently I am running a watcher process which slowly restarts the > workers once available memory is < 4G and this has solved the problem, > but this seems an imperfect solution thus I am wondering if anyone > knows the source of the apparent memory leak? Loaded scripts are > attached and thanks in advance for any informative illumination on this issue. try commenting out @load misc/scan from local.bro. If you have a lot of address space and bro is before any firewall as opposed to after it, this is likely the source of the problems. If that fixes it there are other scan detection implementations that are a bit more efficient. ? Justin Azoff _______________________________________________ Bro mailing list bro at bro-ids.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From greg.grasmehr at caltech.edu Fri Apr 6 10:57:09 2018 From: greg.grasmehr at caltech.edu (Greg Grasmehr) Date: Fri, 6 Apr 2018 10:57:09 -0700 Subject: [Bro] Worker System Memory Exhaustion In-Reply-To: References: <20180405233640.7affge272ncxqfs5@dakine>

Message-ID: <20180406175709.mx4xt7tg2ktvx2wz@dakine> Fast Intel CPU and the live logs write to a RAID 1 virtual disk built on enterprise SSD drives, logs are archived to a virtual disk RAID 10 built on 15K SAS spindles. I will give your debugging a try and see what it says. Thanks all and have a good weekend. Greg On 04/06/18 14:23:40, Azoff, Justin S wrote: > > > On Apr 6, 2018, at 10:07 AM, Hovsep Levi wrote: > > > > This was a battle we endured for many many moons (12+ months), look to the archives for the pain and suffering. > > > > Final solution : Enable multiple loggers (now part of Bro), disable writing logs to disk and stream logs to Kafka. (Thank you KafkaLogger author) > > > > Reasoning : At some point Bro's log writing cannot keep up with the volume. Believed to be a bottleneck with the the default architecture using a single "Logger" node. > > > > Possible alternative : Enable multiple loggers, but when writing to disk you might have a possible race condition with filenames and dates. Also you'll have multiple logs for each rotation interval (ex: 4 loggers means 4 conn.log, 4 http.log, 4 ssh.log, etc...) > > > > > > ^ Hovsep > > > > Ah, yeah, it could be that too. Things got better for the most part once the logger node was introduced, so this hasn't been the problem for people recently. > > I think most of the remaining problems with the logger node scaling are limited to extremely large log volumes and people who had AMD systems with many slow cores.. I think you had one of those. > > In any case, that is easy to check for by looking at broctl top and monitoring the log lag. If the logs are not behind, the problem is something else. > > https://gist.github.com/JustinAzoff/01396a34c8f92d4dda1b > > is a script for munin that will output how old the most recent record in the conn.log is. You can just run it manually though: > > [jazoff at bro-dev ~]$ curl -o log_lag.py https://gist.githubusercontent.com/JustinAzoff/01396a34c8f92d4dda1b/raw/2dba7fdf93915748948b238c20de965b4636cb9e/log_lag.py > [jazoff at bro-dev ~]$ python log_lag.py > lag.value 5.526168 > > > The number should be 5-10s and not growing. > > ? > Justin Azoff > > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From greg.grasmehr at caltech.edu Fri Apr 6 11:03:04 2018 From: greg.grasmehr at caltech.edu (Greg Grasmehr) Date: Fri, 6 Apr 2018 11:03:04 -0700 Subject: [Bro] Worker System Memory Exhaustion In-Reply-To: References: <20180405233640.7affge272ncxqfs5@dakine> Message-ID: <20180406180304.7tgor2e36ebn7a77@dakine> Thanks Carl, will consider this avenue too. Greg On 04/06/18 17:02:02, Pearson, Carl (cpearson at uidaho.edu) wrote: > I endorse commenting out "@load misc/scan", that really stabilized memory usage in our environment. We also commented out "@load misc/detect-traceroute" and that seemed to help as well. > > From your description I don't know if this applies to your situation, but for what it's worth we use PF_RING and experienced high resource utilization initially due to PF_RING not loading correctly. The issue tracker for it is here: https://bro-tracker.atlassian.net/browse/BIT-1864 - TL;DR, change pfringclusterid in broctl.cfg to 21; if pfringclusterid is set to 0 PF_RING doesn't actually do anything even though everything will indicate it's running. Again, don't know if it applies but thought I'd throw it out there. :) > > Thanks, > Carl > University of Idaho > > -----Original Message----- > From: bro-bounces at bro.org On Behalf Of Azoff, Justin S > Sent: Friday, April 6, 2018 05:25 > To: Greg Grasmehr > Cc: bro at bro.org > Subject: Re: [Bro] Worker System Memory Exhaustion > > > > On Apr 5, 2018, at 7:36 PM, Greg Grasmehr wrote: > > > > Hello List, > > > > We're running Bro version 2.5-467 and shunting connections in an > > Arista > > 5100 via the excellent Dumbno. The system is essentially a > > Bro-in-a-box with 251G RAM and a Myricom SNF+ card. Bro spawns 32 > > workers to monitor a 10G link that averages roughly 5G and spikes to 7 > > on occasion. Logs are rotated every 1/2 hour. > > Cool :-) > > > The current configuration has been running for about 2 weeks and thus > > far the only problem I have encountered is that given enough time, the > > workers will eventually exhaust all of the available system memory > > including scratch. > > Less cool :-( > > > Currently I am running a watcher process which slowly restarts the > > workers once available memory is < 4G and this has solved the problem, > > but this seems an imperfect solution thus I am wondering if anyone > > knows the source of the apparent memory leak? Loaded scripts are > > attached and thanks in advance for any informative illumination on this issue. > > try commenting out > > @load misc/scan > > from local.bro. > > If you have a lot of address space and bro is before any firewall as opposed to after it, this is likely the source of the problems. > > If that fixes it there are other scan detection implementations that are a bit more efficient. > > ? > Justin Azoff > > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From greg.grasmehr at caltech.edu Fri Apr 6 13:31:55 2018 From: greg.grasmehr at caltech.edu (Greg Grasmehr) Date: Fri, 6 Apr 2018 13:31:55 -0700 Subject: [Bro] Worker System Memory Exhaustion In-Reply-To: References: <20180405233640.7affge272ncxqfs5@dakine> Message-ID: <20180406203155.js2h2e3lc4bdauuu@dakine> I think Justin hit the nail on the head, we monitor two full /16, 3 /24 and 2 partial /16, in front of any local FW devices; similar to LBL. Commenting out misc/scan did the trick, memory is now being freed as one would expect. We already know we have TONS of scanners traversing the network, so probably don't need this at all although I am interested in hearing of good alternatives. Thanks again everyone, greatly appreciate the help. Greg > try commenting out > > @load misc/scan > > from local.bro. > > If you have a lot of address space and bro is before any firewall as opposed to after it, this is likely the source of the problems. > > If that fixes it there are other scan detection implementations that are a bit more efficient. > > ? > Justin Azoff > From jazoff at illinois.edu Fri Apr 6 13:45:50 2018 From: jazoff at illinois.edu (Azoff, Justin S) Date: Fri, 6 Apr 2018 20:45:50 +0000 Subject: [Bro] Worker System Memory Exhaustion In-Reply-To: <20180406203155.js2h2e3lc4bdauuu@dakine> References: <20180405233640.7affge272ncxqfs5@dakine> <20180406203155.js2h2e3lc4bdauuu@dakine> Message-ID: <3F9460A4-0060-45DC-80B6-474DF1559851@illinois.edu> > On Apr 6, 2018, at 4:31 PM, Greg Grasmehr wrote: > > I think Justin hit the nail on the head, we monitor two full /16, 3 /24 > and 2 partial /16, in front of any local FW devices; similar to LBL. > Commenting out misc/scan did the trick, memory is now being freed as one > would expect. > > We already know we have TONS of scanners traversing the network, so > probably don't need this at all although I am interested in hearing of > good alternatives. > > Thanks again everyone, greatly appreciate the help. > > Greg https://github.com/ncsa/bro-simple-scan https://github.com/initconf/scan-NG both are available in bro-pkg. I'm obviously partial to simple-scan, but Aashish is closer to you if you need someone to blame if it breaks :-) ? Justin Azoff From asharma at lbl.gov Fri Apr 6 14:08:13 2018 From: asharma at lbl.gov (Aashish Sharma) Date: Fri, 6 Apr 2018 14:08:13 -0700 Subject: [Bro] Worker System Memory Exhaustion In-Reply-To: <3F9460A4-0060-45DC-80B6-474DF1559851@illinois.edu> References: <20180405233640.7affge272ncxqfs5@dakine> <20180406203155.js2h2e3lc4bdauuu@dakine> <3F9460A4-0060-45DC-80B6-474DF1559851@illinois.edu> Message-ID: <20180406210812.GL7186@MacPro-2331.local> [ sorry to chime late - still catching up on the thread ] Greg, I generally shunt (disable) sumstats on all my clusters. back in the day, while early adapting I had memory issues in cluster and since then I have disabled it every where for years now. Basically: in /usr/local/bro/share/bro/base/frameworks/sumstats/main.bro to completely make sumstats ineffective - Add a return at the top of "function observe" --- /home/bro/master/share/bro/base/frameworks/sumstats/main.bro 2018-04-06 14:02:05.131016000 -0700 +++ /home/bro/master/share/bro/base/frameworks/sumstats/main.bro.dis 2018-04-06 14:01:54.384697000 -0700 @@ -402,6 +402,9 @@ function create(ss: SumStat) function observe(id: string, key: Key, obs: Observation) { + ### this retun disables the sumstats + return; + if ( id !in reducer_store ) return; As of scan-detection: Justin did us a favor by releasing bro-simple-scan - its simpler and effective and flags >90-95% of scans flagged by scan-NG. scan-NG needs configurations - see : scan-config.bro in there. We've been using scan-NG for > 2years and is our work horse for dynamic firewall blocking. very minimal FPs compared to old-scan. I have never used stock misc/scan because it was only flagged < 10% of scanners for us when I ran comparisons many many years ago and memory issues. may be start with bro-simple-scan and move to scan-NG if you really find stuff missing. Send me pcaps if scan-NG is missing something. I'd be curious about those kinds of scans. > Aashish is closer to you if you need someone to blame if it breaks :-) Totally! :) Aashish On Fri, Apr 06, 2018 at 08:45:50PM +0000, Azoff, Justin S wrote: > > > On Apr 6, 2018, at 4:31 PM, Greg Grasmehr wrote: > > > > I think Justin hit the nail on the head, we monitor two full /16, 3 /24 > > and 2 partial /16, in front of any local FW devices; similar to LBL. > > Commenting out misc/scan did the trick, memory is now being freed as one > > would expect. > > > > We already know we have TONS of scanners traversing the network, so > > probably don't need this at all although I am interested in hearing of > > good alternatives. > > > > Thanks again everyone, greatly appreciate the help. > > > > Greg > > https://github.com/ncsa/bro-simple-scan > > https://github.com/initconf/scan-NG > > both are available in bro-pkg. I'm obviously partial to simple-scan, but > Aashish is closer to you if you need someone to blame if it breaks :-) > > > ? > Justin Azoff > > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From paul_nash at harvard.edu Fri Apr 6 14:16:12 2018 From: paul_nash at harvard.edu (Nash, Paul Edward) Date: Fri, 6 Apr 2018 21:16:12 +0000 Subject: [Bro] Sample log header generator? Message-ID: Hi All, For a given distribution of Bro, is there a simple way to generate the header portions for all of the various (network/protocol related) log files? Specifically, I?m looking for the names of the individuals fields (the #fields line). My goal is to use the information to automatically generate back-end splunk configuration files prior to upgrading a live system. While the field names don?t change often, they have in the past. Relying on live data to generate the individual logs isn?t ideal as actual traffic must be observed or you have to have a sample pcap for every protocol. While sample logs do exist in the ?testing? directory, I don?t see a quick way to grab samples for each log type that would be repeatable for future releases. Thanks, -Paul -- Paul Nash HUIT IT Security Operations 617.998.5126 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180406/5ba5e7d2/attachment.html From michalpurzynski1 at gmail.com Fri Apr 6 14:17:47 2018 From: michalpurzynski1 at gmail.com (=?utf-8?Q?Micha=C5=82_Purzy=C5=84ski?=) Date: Fri, 6 Apr 2018 14:17:47 -0700 Subject: [Bro] Worker System Memory Exhaustion In-Reply-To: <3F9460A4-0060-45DC-80B6-474DF1559851@illinois.edu> References: <20180405233640.7affge272ncxqfs5@dakine> <20180406203155.js2h2e3lc4bdauuu@dakine> <3F9460A4-0060-45DC-80B6-474DF1559851@illinois.edu> Message-ID: <74AACCE6-B557-406F-A11C-605253B7A9B4@gmail.com> I?ve been monitoring /20 and several small subnets plus internal /8 with Justin?s simple scans and it?s excellent. Highly recommended. It?s also faster when it comes to detection. > On Apr 6, 2018, at 1:45 PM, Azoff, Justin S wrote: > > >> On Apr 6, 2018, at 4:31 PM, Greg Grasmehr wrote: >> >> I think Justin hit the nail on the head, we monitor two full /16, 3 /24 >> and 2 partial /16, in front of any local FW devices; similar to LBL. >> Commenting out misc/scan did the trick, memory is now being freed as one >> would expect. >> >> We already know we have TONS of scanners traversing the network, so >> probably don't need this at all although I am interested in hearing of >> good alternatives. >> >> Thanks again everyone, greatly appreciate the help. >> >> Greg > > https://github.com/ncsa/bro-simple-scan > > https://github.com/initconf/scan-NG > > both are available in bro-pkg. I'm obviously partial to simple-scan, but > Aashish is closer to you if you need someone to blame if it breaks :-) > > > ? > Justin Azoff > > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From hhoffman at ip-solutions.net Fri Apr 6 14:30:06 2018 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Fri, 06 Apr 2018 21:30:06 +0000 Subject: [Bro] Sample log header generator? In-Reply-To: References: Message-ID: Hi Paul, Not sure if this is, exactly, what you're looking for as it doesn't break it down per version of Bro but it maybe enough: https://www.bro.org/sphinx/script-reference/log-files.html Cheers, Harry On Fri, Apr 6, 2018, 5:25 PM Nash, Paul Edward wrote: > Hi All, > > For a given distribution of Bro, is there a simple way to generate the > header portions for all of the various (network/protocol related) log > files? Specifically, I?m looking for the names of the individuals fields > (the #fields line). My goal is to use the information to automatically > generate back-end splunk configuration files prior to upgrading a live > system. While the field names don?t change often, they have in the past. > Relying on live data to generate the individual logs isn?t ideal as actual > traffic must be observed or you have to have a sample pcap for every > protocol. > > > > While sample logs do exist in the ?testing? directory, I don?t see a quick > way to grab samples for each log type that would be repeatable for future > releases. > > > > Thanks, > > -Paul > > > > -- > > Paul Nash > > HUIT IT Security Operations > > 617.998.5126 > > > _______________________________________________ > 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/20180406/b4342170/attachment.html From dopheide at gmail.com Fri Apr 6 14:31:26 2018 From: dopheide at gmail.com (Mike Dopheide) Date: Fri, 6 Apr 2018 16:31:26 -0500 Subject: [Bro] Worker System Memory Exhaustion In-Reply-To: <74AACCE6-B557-406F-A11C-605253B7A9B4@gmail.com> References: <20180405233640.7affge272ncxqfs5@dakine> <20180406203155.js2h2e3lc4bdauuu@dakine> <3F9460A4-0060-45DC-80B6-474DF1559851@illinois.edu> <74AACCE6-B557-406F-A11C-605253B7A9B4@gmail.com> Message-ID: So why not just replace the core misc/scan.bro with Justin's that seems clearly better? -Dop On Fri, Apr 6, 2018 at 4:17 PM, Micha? Purzy?ski wrote: > I?ve been monitoring /20 and several small subnets plus internal /8 with > Justin?s simple scans and it?s excellent. Highly recommended. It?s also > faster when it comes to detection. > > > On Apr 6, 2018, at 1:45 PM, Azoff, Justin S wrote: > > > > > >> On Apr 6, 2018, at 4:31 PM, Greg Grasmehr > wrote: > >> > >> I think Justin hit the nail on the head, we monitor two full /16, 3 /24 > >> and 2 partial /16, in front of any local FW devices; similar to LBL. > >> Commenting out misc/scan did the trick, memory is now being freed as one > >> would expect. > >> > >> We already know we have TONS of scanners traversing the network, so > >> probably don't need this at all although I am interested in hearing of > >> good alternatives. > >> > >> Thanks again everyone, greatly appreciate the help. > >> > >> Greg > > > > https://github.com/ncsa/bro-simple-scan > > > > https://github.com/initconf/scan-NG > > > > both are available in bro-pkg. I'm obviously partial to simple-scan, but > > Aashish is closer to you if you need someone to blame if it breaks :-) > > > > > > ? > > Justin Azoff > > > > > > _______________________________________________ > > Bro mailing list > > bro at bro-ids.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > > _______________________________________________ > 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/20180406/06d9e03d/attachment.html From assaf.morami at gmail.com Mon Apr 9 07:05:43 2018 From: assaf.morami at gmail.com (Assaf) Date: Mon, 9 Apr 2018 17:05:43 +0300 Subject: [Bro] internal error: file analyzer instantiation failed Message-ID: Hi to all. :-) When running: bro -r my.pcap -b -C base/protocols/rdp (ubuntu server 16.04 - bro version 2.4.1) I'm getting an error: Error: 1521789435.202907 internal error: file analyzer instantiation failed I've found nothing on google or the docs. How can I fix this? Thanks, Assaf. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180409/0c71e0be/attachment.html From brandon.sterne at gmail.com Mon Apr 9 08:56:04 2018 From: brandon.sterne at gmail.com (Brandon Sterne) Date: Mon, 9 Apr 2018 08:56:04 -0700 Subject: [Bro] Bro behind a TLS reverse proxy In-Reply-To: <665D44F3-E658-4DFD-BF1E-2B9CD681ADC4@illinois.edu> References: <665D44F3-E658-4DFD-BF1E-2B9CD681ADC4@illinois.edu> Message-ID: 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 , 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=, dpd=, conn=, extract_orig=F, extract_resp=F, thresholds=, dhcp=, dnp3=, dns=, dns_state=, ftp=, ftp_data_reuse=F, ssl=, http=, http_state=, irc=, krb=, modbus=, mysql=, radius=, rdp=, sip=, sip_state=, snmp=, smtp=, smtp_state=, socks=, ssh=, syslog=] 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 wrote: > > > On Apr 2, 2018, at 12:04 AM, Brandon Sterne > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180409/4d51b35f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: detect-http-request.bro Type: application/octet-stream Size: 471 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180409/4d51b35f/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: port8080.pcap Type: application/octet-stream Size: 2777 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180409/4d51b35f/attachment-0001.obj From seth at corelight.com Mon Apr 9 13:33:53 2018 From: seth at corelight.com (Seth Hall) Date: Mon, 09 Apr 2018 16:33:53 -0400 Subject: [Bro] Bro behind a TLS reverse proxy In-Reply-To: References: <665D44F3-E658-4DFD-BF1E-2B9CD681ADC4@illinois.edu> Message-ID: <61069FD8-7D1F-409E-98A3-FA3BD01EC991@corelight.com> 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 > , 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=, > dpd=, conn=, extract_orig=F, > extract_resp=F, > thresholds=, dhcp=, > dnp3=, > dns=, dns_state=, ftp=, > ftp_data_reuse=F, ssl=, http=, > http_state=, irc=, krb=, > modbus=, mysql=, radius=, > rdp=, sip=, sip_state=, > snmp=, smtp=, > smtp_state=, > socks=, ssh=, syslog=] > > 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 > wrote: > >> >>> On Apr 2, 2018, at 12:04 AM, Brandon Sterne >>> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180409/4dcc601b/attachment.html From michalpurzynski1 at gmail.com Mon Apr 9 15:34:08 2018 From: michalpurzynski1 at gmail.com (=?UTF-8?B?TWljaGHFgiBQdXJ6ecWEc2tp?=) Date: Mon, 9 Apr 2018 15:34:08 -0700 Subject: [Bro] Bro behind a TLS reverse proxy In-Reply-To: <61069FD8-7D1F-409E-98A3-FA3BD01EC991@corelight.com> References: <665D44F3-E658-4DFD-BF1E-2B9CD681ADC4@illinois.edu> <61069FD8-7D1F-409E-98A3-FA3BD01EC991@corelight.com> Message-ID: 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 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 > , 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=, > dpd=, conn=, extract_orig=F, extract_resp=F, > thresholds=, dhcp=, dnp3=, > dns=, dns_state=, ftp=, > ftp_data_reuse=F, ssl=, http=, > http_state=, irc=, krb=, > modbus=, mysql=, radius=, > rdp=, sip=, sip_state=, > snmp=, smtp=, smtp_state=, > socks=, ssh=, syslog=] > > 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 > wrote: > >> >> > On Apr 2, 2018, at 12:04 AM, Brandon Sterne >> 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 From brandon.sterne at gmail.com Mon Apr 9 16:25:51 2018 From: brandon.sterne at gmail.com (Brandon Sterne) Date: Mon, 9 Apr 2018 16:25:51 -0700 Subject: [Bro] Bro behind a TLS reverse proxy In-Reply-To: References: <665D44F3-E658-4DFD-BF1E-2B9CD681ADC4@illinois.edu> <61069FD8-7D1F-409E-98A3-FA3BD01EC991@corelight.com> Message-ID: This is very interesting. It is totally reproducible with CentOS 7 VMs, but I confirmed the testcase works as expected with an Ubuntu Server VM. On a freshly provisioned C7 VM, I see "That 70s Packet" when I capture from the loopback interface, but not when I capture from the external interface: ```[vagrant at localhost pcaps]$ tshark -t ud -r lo-port80.pcap 1 2018-04-09 23:16:28 ::1 -> ::1 TCP 94 58156 > http [SYN] Seq=0 Win=43690 Len=0 MSS=65476 SACK_PERM=1 TSval=8358348 TSecr=0 WS=64 2 2018-04-09 23:16:28 ::1 -> ::1 TCP 74 http > 58156 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 3 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 74 43060 > http [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=8358349 TSecr=0 WS=64 4 1971-02-20 11:53:55 127.0.0.1 -> 127.0.0.1 TCP 74 http > 43060 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=8358349 TSecr=8358349 WS=64 5 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 43060 > http [ACK] Seq=1 Ack=1 Win=43712 Len=0 TSval=8358349 TSecr=8358349 6 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 HTTP 139 GET / HTTP/1.1 7 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 http > 43060 [ACK] Seq=1 Ack=74 Win=43712 Len=0 TSval=8358349 TSecr=8358349 8 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 83 [TCP segment of a reassembled PDU] 9 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 43060 > http [ACK] Seq=74 Ack=18 Win=43712 Len=0 TSval=8358351 TSecr=8358351 10 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 103 [TCP segment of a reassembled PDU] 11 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 43060 > http [ACK] Seq=74 Ack=55 Win=43712 Len=0 TSval=8358351 TSecr=8358351 12 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 103 [TCP segment of a reassembled PDU] 13 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 43060 > http [ACK] Seq=74 Ack=92 Win=43712 Len=0 TSval=8358351 TSecr=8358351 14 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 106 [TCP segment of a reassembled PDU] 15 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 43060 > http [ACK] Seq=74 Ack=132 Win=43712 Len=0 TSval=8358351 TSecr=8358351 16 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 87 [TCP segment of a reassembled PDU] 17 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 43060 > http [ACK] Seq=74 Ack=153 Win=43712 Len=0 TSval=8358351 TSecr=8358351 18 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 68 [TCP segment of a reassembled PDU] 19 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 43060 > http [ACK] Seq=74 Ack=155 Win=43712 Len=0 TSval=8358351 TSecr=8358351 20 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 HTTP 512 HTTP/1.0 200 OK (text/html) 21 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 43060 > http [ACK] Seq=74 Ack=601 Win=44800 Len=0 TSval=8358351 TSecr=8358351 22 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 http > 43060 [FIN, ACK] Seq=601 Ack=74 Win=43712 Len=0 TSval=8358351 TSecr=8358351 23 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 43060 > http [FIN, ACK] Seq=74 Ack=602 Win=44800 Len=0 TSval=8358351 TSecr=8358351 24 2018-04-09 23:16:28 127.0.0.1 -> 127.0.0.1 TCP 66 http > 43060 [ACK] Seq=602 Ack=75 Win=43712 Len=0 TSval=8358351 TSecr=8358351 [vagrant at localhost pcaps]$ tshark -t ud -r eth1-port80.pcap 1 2018-04-09 21:06:26 192.168.43.1 -> 192.168.43.10 TCP 78 53640 > http [SYN, ECN, CWR] Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=240784579 TSecr=0 SACK_PERM=1 2 2018-04-09 21:06:26 192.168.43.10 -> 192.168.43.1 TCP 74 http > 53640 [SYN, ACK, ECN] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=556841 TSecr=240784579 WS=64 3 2018-04-09 21:06:26 192.168.43.1 -> 192.168.43.10 TCP 66 53640 > http [ACK] Seq=1 Ack=1 Win=131744 Len=0 TSval=240784579 TSecr=556841 4 2018-04-09 21:06:26 192.168.43.1 -> 192.168.43.10 HTTP 415 GET / HTTP/1.1 5 2018-04-09 21:06:26 192.168.43.10 -> 192.168.43.1 TCP 66 http > 53640 [ACK] Seq=1 Ack=350 Win=30080 Len=0 TSval=556842 TSecr=240784579 6 2018-04-09 21:06:26 192.168.43.10 -> 192.168.43.1 TCP 83 [TCP segment of a reassembled PDU] 7 2018-04-09 21:06:26 192.168.43.1 -> 192.168.43.10 TCP 66 53640 > http [ACK] Seq=350 Ack=18 Win=131744 Len=0 TSval=240784581 TSecr=556843 8 2018-04-09 21:06:26 192.168.43.10 -> 192.168.43.1 TCP 103 [TCP segment of a reassembled PDU] 9 2018-04-09 21:06:26 192.168.43.1 -> 192.168.43.10 TCP 66 53640 > http [ACK] Seq=350 Ack=55 Win=131712 Len=0 TSval=240784581 TSecr=556844 10 2018-04-09 21:06:26 192.168.43.10 -> 192.168.43.1 TCP 103 [TCP segment of a reassembled PDU] 11 2018-04-09 21:06:26 192.168.43.1 -> 192.168.43.10 TCP 66 53640 > http [ACK] Seq=350 Ack=92 Win=131648 Len=0 TSval=240784581 TSecr=556844 12 2018-04-09 21:06:26 192.168.43.10 -> 192.168.43.1 TCP 106 [TCP segment of a reassembled PDU] 13 2018-04-09 21:06:26 192.168.43.1 -> 192.168.43.10 TCP 66 53640 > http [ACK] Seq=350 Ack=132 Win=131616 Len=0 TSval=240784581 TSecr=556844 14 2018-04-09 21:06:26 192.168.43.10 -> 192.168.43.1 TCP 87 [TCP segment of a reassembled PDU] 15 2018-04-09 21:06:26 192.168.43.10 -> 192.168.43.1 HTTP 466 HTTP/1.0 200 OK (text/html) 16 2018-04-09 21:06:26 192.168.43.1 -> 192.168.43.10 TCP 66 53640 > http [ACK] Seq=350 Ack=153 Win=131616 Len=0 TSval=240784581 TSecr=556844 17 2018-04-09 21:06:26 192.168.43.1 -> 192.168.43.10 TCP 66 53640 > http [ACK] Seq=350 Ack=554 Win=131200 Len=0 TSval=240784581 TSecr=556844 18 2018-04-09 21:06:26 192.168.43.1 -> 192.168.43.10 TCP 66 53640 > http [FIN, ACK] Seq=350 Ack=554 Win=131200 Len=0 TSval=240784581 TSecr=556844 19 2018-04-09 21:06:26 192.168.43.10 -> 192.168.43.1 TCP 66 http > 53640 [ACK] Seq=554 Ack=351 Win=30080 Len=0 TSval=556844 TSecr=240784581 ``` It's a good question, Micha?. Whose bug is this? I'm happy to go chase it down with the right audience if we can answer this question. Thanks for taking the time to look. Cheers, Brandon On Mon, Apr 9, 2018 at 3:34 PM, Micha? Purzy?ski wrote: > 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 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 >> , 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=, >> dpd=, conn=, extract_orig=F, extract_resp=F, >> thresholds=, dhcp=, dnp3=, >> dns=, dns_state=, ftp=, >> ftp_data_reuse=F, ssl=, http=, >> http_state=, irc=, krb=, >> modbus=, mysql=, radius=, >> rdp=, sip=, sip_state=, >> snmp=, smtp=, smtp_state=, >> socks=, ssh=, syslog=