From noreply at bro.org Tue Sep 1 00:00:21 2015 From: noreply at bro.org (Merge Tracker) Date: Tue, 1 Sep 2015 00:00:21 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509010700.t8170LbL019523@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------------- #6 [1] bro-plugins jswaro [2] 2015-08-24 Adding initial conversion of TCPRS to a plugin [3] [1] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [2] jswaro https://github.com/jswaro [3] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin From jira at bro-tracker.atlassian.net Tue Sep 1 14:50:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Tue, 1 Sep 2015 16:50:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1467) several tests are broken in scripts/policy/protocols/ssl In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21923#comment-21923 ] Daniel Thayer commented on BIT-1467: ------------------------------------ Even after fixing the test canonifiers, these tests still fail on all Jenkins VMs: scripts.policy.protocols.ssl.validate-certs (the "validation_status" field differs from the baseline) scripts.policy.protocols.ssl.validate-ocsp (the "ocsp_status" field differs from the baseline) scripts.policy.protocols.ssl.validate-certs-cluster (the "validation_status" and "cert_chain_fuids" fields differ from baseline) > several tests are broken in scripts/policy/protocols/ssl > -------------------------------------------------------- > > Key: BIT-1467 > URL: https://bro-tracker.atlassian.net/browse/BIT-1467 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > Fix For: 2.5 > > > Due to recent bug fixes in the btest repo (see BIT-1455), it was > discovered that several tests in the bro repo now fail due to problems > with their canonifier. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Tue Sep 1 14:51:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Tue, 1 Sep 2015 16:51:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1467) several tests are broken in scripts/policy/protocols/ssl In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer reassigned BIT-1467: ---------------------------------- Assignee: Johanna Amann > several tests are broken in scripts/policy/protocols/ssl > -------------------------------------------------------- > > Key: BIT-1467 > URL: https://bro-tracker.atlassian.net/browse/BIT-1467 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > Assignee: Johanna Amann > Fix For: 2.5 > > > Due to recent bug fixes in the btest repo (see BIT-1455), it was > discovered that several tests in the bro repo now fail due to problems > with their canonifier. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Tue Sep 1 15:50:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 1 Sep 2015 17:50:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1470) Implemented Functions in Notice Framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1470: ------------------------------ Status: Merge Request (was: Open) > Implemented Functions in Notice Framework > ----------------------------------------- > > Key: BIT-1470 > URL: https://bro-tracker.atlassian.net/browse/BIT-1470 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.3 > Reporter: Wendy Edwards > Attachments: main_mod.bro, notice_main.patch > > > I modified the main.bro file in the notice framework (see https://github.com/bro/bro/blob/master/scripts/base/frameworks/notice/main.bro) to implement the functions "notice_tags" and "execute_with_notice." The patch (notice_main.patch) and the modified file (main_mod.bro) are both attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From noreply at bro.org Wed Sep 2 00:00:17 2015 From: noreply at bro.org (Merge Tracker) Date: Wed, 2 Sep 2015 00:00:17 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509020700.t8270Hss003042@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ---------- ---------- ------------- ---------- ----------------------------------------- BIT-1470 [1] Bro Wendy Edwards - 2015-09-01 - Normal Implemented Functions in Notice Framework Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------------- #6 [2] bro-plugins jswaro [3] 2015-08-24 Adding initial conversion of TCPRS to a plugin [4] [1] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [2] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [3] jswaro https://github.com/jswaro [4] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin From jira at bro-tracker.atlassian.net Wed Sep 2 13:31:00 2015 From: jira at bro-tracker.atlassian.net (dop (JIRA)) Date: Wed, 2 Sep 2015 15:31:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1471) find-filtered-trace: minor documentation update In-Reply-To: References: Message-ID: dop created BIT-1471: ------------------------ Summary: find-filtered-trace: minor documentation update Key: BIT-1471 URL: https://bro-tracker.atlassian.net/browse/BIT-1471 Project: Bro Issue Tracker Issue Type: Problem Components: Documentation Affects Versions: git/master Environment: CentOS 7, bro-master Reporter: dop Priority: Trivial Attachments: detect_filtered_doc.patch Just noticed that "detect_filtered_trace" should be "FilteredTraceDetection::enable". Updated the text reported to the user, not sure if the bro docs section in the comments in appropriate. Patch attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Wed Sep 2 14:10:01 2015 From: jira at bro-tracker.atlassian.net (Adam Slagell (JIRA)) Date: Wed, 2 Sep 2015 16:10:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1458) Lots of binpac exceptions in SIP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Slagell reassigned BIT-1458: --------------------------------- Assignee: Vlad Grigorescu > Lots of binpac exceptions in SIP > -------------------------------- > > Key: BIT-1458 > URL: https://bro-tracker.atlassian.net/browse/BIT-1458 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Environment: Linux 3.19, Ubuntu 14.04 LTS, Asterisk for VOIP, plain SIP plus RDP no encryption > Reporter: Michal Purzynski > Assignee: Vlad Grigorescu > Attachments: badsip-19AUG2015_anon.pcapng, sip2.pcap, sip3.pcap, sip-scan-detailed.pcap > > > There's quite a bit of binpac exception in dpd.log on office sensors, that can see SIP traffic. The log message is always the same (I think). > 1439957552.911869 ChGboH2ZriUae63ufg 23.92.80.45 5089 10.252.40.4 5060 udp SIP Binpac exception: binpac exception: string mismatch at /home/mpurzynski/src/bro/bro-2.4-pfring/src/analyzer/protocol/sip/sip-protocol.pac:70: \x0aexpected pattern: ":"\x0aactual data: " 496704993 2096249773 IN IP4 23.92.80.45\x0d\x0as=sipcli\x0d\x0ac=IN IP4 23.92.80.45\x0d\x0at=0 0\x0d\x0am=audio 5097 RTP/AVP 18 0 8 101\x0d\x0aa=fmtp:101 0-15\x0d\x0aa=rtpmap:18 G729/8000\x0d\x0aa=rtpmap:0 PCMU/8000\x0d\x0aa=rtpmap:8 PCMA/8000\x0d\x0aa=rtpmap:101 telephone-event/8000\x0d\x0aa=ptime:20\x0d\x0aa=sendrecv\x0d\x0a" > What kind of data do you want me to attach, to help debugging the issue? -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Wed Sep 2 15:56:01 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Wed, 2 Sep 2015 17:56:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1471) find-filtered-trace: minor documentation update In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21924#comment-21924 ] Daniel Thayer commented on BIT-1471: ------------------------------------ I believe the text is correct (though probably not as clear as it should be). The "FilteredTraceDetection::enable" boolean determines whether or not the "find-filtered-trace.bro" script will warn the user when it determines that a trace file contains TCP traffic consisting only of control packets, whereas the "detect_filtered_trace" boolean is used internally by Bro in the TCP reassembler. See BIT-1119 for more info. > find-filtered-trace: minor documentation update > ------------------------------------------------ > > Key: BIT-1471 > URL: https://bro-tracker.atlassian.net/browse/BIT-1471 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Documentation > Affects Versions: git/master > Environment: CentOS 7, bro-master > Reporter: dop > Priority: Trivial > Labels: documentation > Attachments: detect_filtered_doc.patch > > > Just noticed that "detect_filtered_trace" should be "FilteredTraceDetection::enable". Updated the text reported to the user, not sure if the bro docs section in the comments in appropriate. Patch attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From noreply at bro.org Thu Sep 3 00:00:20 2015 From: noreply at bro.org (Merge Tracker) Date: Thu, 3 Sep 2015 00:00:20 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509030700.t8370K1b025705@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ---------- ---------- ------------- ---------- ----------------------------------------- BIT-1470 [1] Bro Wendy Edwards - 2015-09-01 - Normal Implemented Functions in Notice Framework Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------------- #6 [2] bro-plugins jswaro [3] 2015-08-24 Adding initial conversion of TCPRS to a plugin [4] [1] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [2] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [3] jswaro https://github.com/jswaro [4] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin From jira at bro-tracker.atlassian.net Thu Sep 3 07:55:00 2015 From: jira at bro-tracker.atlassian.net (dop (JIRA)) Date: Thu, 3 Sep 2015 09:55:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1471) find-filtered-trace: minor documentation update In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21925#comment-21925 ] dop commented on BIT-1471: -------------------------- Right you are! So I guess the real confusion is just the comment: ## Flag to enable filtered trace file detection and warning message. Thanks Daniel. > find-filtered-trace: minor documentation update > ------------------------------------------------ > > Key: BIT-1471 > URL: https://bro-tracker.atlassian.net/browse/BIT-1471 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Documentation > Affects Versions: git/master > Environment: CentOS 7, bro-master > Reporter: dop > Priority: Trivial > Labels: documentation > Attachments: detect_filtered_doc.patch > > > Just noticed that "detect_filtered_trace" should be "FilteredTraceDetection::enable". Updated the text reported to the user, not sure if the bro docs section in the comments in appropriate. Patch attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Thu Sep 3 08:53:00 2015 From: jira at bro-tracker.atlassian.net (Aashish Sharma (JIRA)) Date: Thu, 3 Sep 2015 10:53:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1472) Bif for a new function to calculates haversine distance between two geoip locations In-Reply-To: References: Message-ID: Aashish Sharma created BIT-1472: ----------------------------------- Summary: Bif for a new function to calculates haversine distance between two geoip locations Key: BIT-1472 URL: https://bro-tracker.atlassian.net/browse/BIT-1472 Project: Bro Issue Tracker Issue Type: New Feature Components: Bro Affects Versions: 2.4 Reporter: Aashish Sharma Merge request for: topic/aashish/haversine ## ## Calculates haversine distance between two geoip locations ## ## ## lat1, long1, lat2, long2 ## ## Returns: distance in miles ## function haversine_distance%(lat1:double, long1:double, lat2:double, long2:double %): double accompanying bro policy in base/utils/haversine_distance_ip.bro module GLOBAL; ## Returns the haversine distance between two IP addresses based on GeoIP ## database locations ## ## ## orig: the address of orig connection ## resp: the address of resp server ## Returns: the GeoIP distance between orig and resp in miles function haversine_distance_ip(orig: addr, resp: addr): double -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Thu Sep 3 14:32:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Thu, 3 Sep 2015 16:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1458) Lots of binpac exceptions in SIP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1458: --------------------------------- Status: Merge Request (was: Open) Assignee: (was: Vlad Grigorescu) > Lots of binpac exceptions in SIP > -------------------------------- > > Key: BIT-1458 > URL: https://bro-tracker.atlassian.net/browse/BIT-1458 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Environment: Linux 3.19, Ubuntu 14.04 LTS, Asterisk for VOIP, plain SIP plus RDP no encryption > Reporter: Michal Purzynski > Attachments: badsip-19AUG2015_anon.pcapng, sip2.pcap, sip3.pcap, sip-scan-detailed.pcap > > > There's quite a bit of binpac exception in dpd.log on office sensors, that can see SIP traffic. The log message is always the same (I think). > 1439957552.911869 ChGboH2ZriUae63ufg 23.92.80.45 5089 10.252.40.4 5060 udp SIP Binpac exception: binpac exception: string mismatch at /home/mpurzynski/src/bro/bro-2.4-pfring/src/analyzer/protocol/sip/sip-protocol.pac:70: \x0aexpected pattern: ":"\x0aactual data: " 496704993 2096249773 IN IP4 23.92.80.45\x0d\x0as=sipcli\x0d\x0ac=IN IP4 23.92.80.45\x0d\x0at=0 0\x0d\x0am=audio 5097 RTP/AVP 18 0 8 101\x0d\x0aa=fmtp:101 0-15\x0d\x0aa=rtpmap:18 G729/8000\x0d\x0aa=rtpmap:0 PCMU/8000\x0d\x0aa=rtpmap:8 PCMA/8000\x0d\x0aa=rtpmap:101 telephone-event/8000\x0d\x0aa=ptime:20\x0d\x0aa=sendrecv\x0d\x0a" > What kind of data do you want me to attach, to help debugging the issue? -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Thu Sep 3 14:33:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Thu, 3 Sep 2015 16:33:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1458) Lots of binpac exceptions in SIP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21926#comment-21926 ] Vlad Grigorescu commented on BIT-1458: -------------------------------------- topic/vladg/bit-1458 reworks the analyzer a bit, and fixes any errors in the attached PCAPs. > Lots of binpac exceptions in SIP > -------------------------------- > > Key: BIT-1458 > URL: https://bro-tracker.atlassian.net/browse/BIT-1458 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Environment: Linux 3.19, Ubuntu 14.04 LTS, Asterisk for VOIP, plain SIP plus RDP no encryption > Reporter: Michal Purzynski > Attachments: badsip-19AUG2015_anon.pcapng, sip2.pcap, sip3.pcap, sip-scan-detailed.pcap > > > There's quite a bit of binpac exception in dpd.log on office sensors, that can see SIP traffic. The log message is always the same (I think). > 1439957552.911869 ChGboH2ZriUae63ufg 23.92.80.45 5089 10.252.40.4 5060 udp SIP Binpac exception: binpac exception: string mismatch at /home/mpurzynski/src/bro/bro-2.4-pfring/src/analyzer/protocol/sip/sip-protocol.pac:70: \x0aexpected pattern: ":"\x0aactual data: " 496704993 2096249773 IN IP4 23.92.80.45\x0d\x0as=sipcli\x0d\x0ac=IN IP4 23.92.80.45\x0d\x0at=0 0\x0d\x0am=audio 5097 RTP/AVP 18 0 8 101\x0d\x0aa=fmtp:101 0-15\x0d\x0aa=rtpmap:18 G729/8000\x0d\x0aa=rtpmap:0 PCMU/8000\x0d\x0aa=rtpmap:8 PCMA/8000\x0d\x0aa=rtpmap:101 telephone-event/8000\x0d\x0aa=ptime:20\x0d\x0aa=sendrecv\x0d\x0a" > What kind of data do you want me to attach, to help debugging the issue? -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Thu Sep 3 15:27:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Thu, 3 Sep 2015 17:27:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1469: --------------------------------- Fix Version/s: 2.5 > dpd.log contains lots of binpac exceptions for RDP > -------------------------------------------------- > > Key: BIT-1469 > URL: https://bro-tracker.atlassian.net/browse/BIT-1469 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC, Bro > Affects Versions: git/master > Environment: RHEL 6.6, 2.4-10 bro build from git > Reporter: Gary Faulkner > Labels: analyzer > Fix For: 2.5 > > Attachments: rdp-31AUG15.pcap > > > RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP connections. > The following log line is an example of the error that repeats continuously during the activity: > 1441031469.413008 CPNcey4q2i8mGVUvEg 74.91.23.83 62082 10.10.81.207 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > The 10.x.x.x IP is the redacted local IP. The other IP is the scanner. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Thu Sep 3 15:37:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Thu, 3 Sep 2015 17:37:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21927#comment-21927 ] Vlad Grigorescu commented on BIT-1469: -------------------------------------- I looked into this, and I don't think that it's trivial to solve correctly. We could easily ignore traffic that generates this warning, but we risk allowing some types of evasion. The issue is exhibited in frame 38 of the attached PCAP, among others. > TPKT, Version: 3, Length: 8 > ISO 8073/X.224 COTP Connection-Oriented Transport Protocol > Length: 2 > PDU Type: DT Data (0x0f) > Data (1 byte) > > 0000 28 ( > Data: 28 DT_Data tries to parse the PDU Type, a uint8 (application_defined_type), and another uint8 (application_type). In this case, there are not 3 bytes available to process. We could trust the lengths, but comments in the code indicate that they're often incorrect. I'm also unsure if these short packets are designed to be reassembled by the application. Curious to hear other people's thoughts, but I think bumping this back to 2.5 is a reasonable step for now. > dpd.log contains lots of binpac exceptions for RDP > -------------------------------------------------- > > Key: BIT-1469 > URL: https://bro-tracker.atlassian.net/browse/BIT-1469 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC, Bro > Affects Versions: git/master > Environment: RHEL 6.6, 2.4-10 bro build from git > Reporter: Gary Faulkner > Labels: analyzer > Fix For: 2.5 > > Attachments: rdp-31AUG15.pcap > > > RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP connections. > The following log line is an example of the error that repeats continuously during the activity: > 1441031469.413008 CPNcey4q2i8mGVUvEg 74.91.23.83 62082 10.10.81.207 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > The 10.x.x.x IP is the redacted local IP. The other IP is the scanner. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Thu Sep 3 19:49:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Thu, 3 Sep 2015 21:49:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1458) Lots of binpac exceptions in SIP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann reassigned BIT-1458: ---------------------------------- Assignee: Johanna Amann > Lots of binpac exceptions in SIP > -------------------------------- > > Key: BIT-1458 > URL: https://bro-tracker.atlassian.net/browse/BIT-1458 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Environment: Linux 3.19, Ubuntu 14.04 LTS, Asterisk for VOIP, plain SIP plus RDP no encryption > Reporter: Michal Purzynski > Assignee: Johanna Amann > Attachments: badsip-19AUG2015_anon.pcapng, sip2.pcap, sip3.pcap, sip-scan-detailed.pcap > > > There's quite a bit of binpac exception in dpd.log on office sensors, that can see SIP traffic. The log message is always the same (I think). > 1439957552.911869 ChGboH2ZriUae63ufg 23.92.80.45 5089 10.252.40.4 5060 udp SIP Binpac exception: binpac exception: string mismatch at /home/mpurzynski/src/bro/bro-2.4-pfring/src/analyzer/protocol/sip/sip-protocol.pac:70: \x0aexpected pattern: ":"\x0aactual data: " 496704993 2096249773 IN IP4 23.92.80.45\x0d\x0as=sipcli\x0d\x0ac=IN IP4 23.92.80.45\x0d\x0at=0 0\x0d\x0am=audio 5097 RTP/AVP 18 0 8 101\x0d\x0aa=fmtp:101 0-15\x0d\x0aa=rtpmap:18 G729/8000\x0d\x0aa=rtpmap:0 PCMU/8000\x0d\x0aa=rtpmap:8 PCMA/8000\x0d\x0aa=rtpmap:101 telephone-event/8000\x0d\x0aa=ptime:20\x0d\x0aa=sendrecv\x0d\x0a" > What kind of data do you want me to attach, to help debugging the issue? -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Thu Sep 3 20:25:01 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Thu, 3 Sep 2015 22:25:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1458) Lots of binpac exceptions in SIP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21928#comment-21928 ] Johanna Amann commented on BIT-1458: ------------------------------------ I merged this -- however, might it perhaps make sense to add a testcase with some of this traffic, just to prevent this case from occuring again in the future if we extend the analyzer? > Lots of binpac exceptions in SIP > -------------------------------- > > Key: BIT-1458 > URL: https://bro-tracker.atlassian.net/browse/BIT-1458 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Environment: Linux 3.19, Ubuntu 14.04 LTS, Asterisk for VOIP, plain SIP plus RDP no encryption > Reporter: Michal Purzynski > Assignee: Johanna Amann > Attachments: badsip-19AUG2015_anon.pcapng, sip2.pcap, sip3.pcap, sip-scan-detailed.pcap > > > There's quite a bit of binpac exception in dpd.log on office sensors, that can see SIP traffic. The log message is always the same (I think). > 1439957552.911869 ChGboH2ZriUae63ufg 23.92.80.45 5089 10.252.40.4 5060 udp SIP Binpac exception: binpac exception: string mismatch at /home/mpurzynski/src/bro/bro-2.4-pfring/src/analyzer/protocol/sip/sip-protocol.pac:70: \x0aexpected pattern: ":"\x0aactual data: " 496704993 2096249773 IN IP4 23.92.80.45\x0d\x0as=sipcli\x0d\x0ac=IN IP4 23.92.80.45\x0d\x0at=0 0\x0d\x0am=audio 5097 RTP/AVP 18 0 8 101\x0d\x0aa=fmtp:101 0-15\x0d\x0aa=rtpmap:18 G729/8000\x0d\x0aa=rtpmap:0 PCMU/8000\x0d\x0aa=rtpmap:8 PCMA/8000\x0d\x0aa=rtpmap:101 telephone-event/8000\x0d\x0aa=ptime:20\x0d\x0aa=sendrecv\x0d\x0a" > What kind of data do you want me to attach, to help debugging the issue? -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Thu Sep 3 20:25:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Thu, 3 Sep 2015 22:25:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1458) Lots of binpac exceptions in SIP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1458: ------------------------------- Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Lots of binpac exceptions in SIP > -------------------------------- > > Key: BIT-1458 > URL: https://bro-tracker.atlassian.net/browse/BIT-1458 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Environment: Linux 3.19, Ubuntu 14.04 LTS, Asterisk for VOIP, plain SIP plus RDP no encryption > Reporter: Michal Purzynski > Assignee: Johanna Amann > Attachments: badsip-19AUG2015_anon.pcapng, sip2.pcap, sip3.pcap, sip-scan-detailed.pcap > > > There's quite a bit of binpac exception in dpd.log on office sensors, that can see SIP traffic. The log message is always the same (I think). > 1439957552.911869 ChGboH2ZriUae63ufg 23.92.80.45 5089 10.252.40.4 5060 udp SIP Binpac exception: binpac exception: string mismatch at /home/mpurzynski/src/bro/bro-2.4-pfring/src/analyzer/protocol/sip/sip-protocol.pac:70: \x0aexpected pattern: ":"\x0aactual data: " 496704993 2096249773 IN IP4 23.92.80.45\x0d\x0as=sipcli\x0d\x0ac=IN IP4 23.92.80.45\x0d\x0at=0 0\x0d\x0am=audio 5097 RTP/AVP 18 0 8 101\x0d\x0aa=fmtp:101 0-15\x0d\x0aa=rtpmap:18 G729/8000\x0d\x0aa=rtpmap:0 PCMU/8000\x0d\x0aa=rtpmap:8 PCMA/8000\x0d\x0aa=rtpmap:101 telephone-event/8000\x0d\x0aa=ptime:20\x0d\x0aa=sendrecv\x0d\x0a" > What kind of data do you want me to attach, to help debugging the issue? -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Thu Sep 3 20:55:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Thu, 3 Sep 2015 22:55:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1458) Lots of binpac exceptions in SIP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21929#comment-21929 ] Vlad Grigorescu commented on BIT-1458: -------------------------------------- Yeah, I agree. The existing btest's Baseline did need to be updated with this fix (there was a SIP message that was previously missed), so we do have a test exhibiting this problem, but we should probably do more. We also have no tests for the SIP over TCP analyzer. I was going to make a ticket to add one for that (I had some issues finding a test trace). > Lots of binpac exceptions in SIP > -------------------------------- > > Key: BIT-1458 > URL: https://bro-tracker.atlassian.net/browse/BIT-1458 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Environment: Linux 3.19, Ubuntu 14.04 LTS, Asterisk for VOIP, plain SIP plus RDP no encryption > Reporter: Michal Purzynski > Assignee: Johanna Amann > Attachments: badsip-19AUG2015_anon.pcapng, sip2.pcap, sip3.pcap, sip-scan-detailed.pcap > > > There's quite a bit of binpac exception in dpd.log on office sensors, that can see SIP traffic. The log message is always the same (I think). > 1439957552.911869 ChGboH2ZriUae63ufg 23.92.80.45 5089 10.252.40.4 5060 udp SIP Binpac exception: binpac exception: string mismatch at /home/mpurzynski/src/bro/bro-2.4-pfring/src/analyzer/protocol/sip/sip-protocol.pac:70: \x0aexpected pattern: ":"\x0aactual data: " 496704993 2096249773 IN IP4 23.92.80.45\x0d\x0as=sipcli\x0d\x0ac=IN IP4 23.92.80.45\x0d\x0at=0 0\x0d\x0am=audio 5097 RTP/AVP 18 0 8 101\x0d\x0aa=fmtp:101 0-15\x0d\x0aa=rtpmap:18 G729/8000\x0d\x0aa=rtpmap:0 PCMU/8000\x0d\x0aa=rtpmap:8 PCMA/8000\x0d\x0aa=rtpmap:101 telephone-event/8000\x0d\x0aa=ptime:20\x0d\x0aa=sendrecv\x0d\x0a" > What kind of data do you want me to attach, to help debugging the issue? -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From noreply at bro.org Fri Sep 4 00:00:22 2015 From: noreply at bro.org (Merge Tracker) Date: Fri, 4 Sep 2015 00:00:22 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509040700.t8470MVF016096@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ---------- ---------- ------------- ---------- ----------------------------------------- BIT-1470 [1] Bro Wendy Edwards - 2015-09-01 - Normal Implemented Functions in Notice Framework Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------------- #6 [2] bro-plugins jswaro [3] 2015-08-24 Adding initial conversion of TCPRS to a plugin [4] [1] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [2] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [3] jswaro https://github.com/jswaro [4] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin From jira at bro-tracker.atlassian.net Fri Sep 4 04:52:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 06:52:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1396) Logs disappearing on broctl restart In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21930#comment-21930 ] Seth Hall commented on BIT-1396: -------------------------------- Aashish, one more ping on this before we close it. :) > Logs disappearing on broctl restart > ----------------------------------- > > Key: BIT-1396 > URL: https://bro-tracker.atlassian.net/browse/BIT-1396 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: 2.4 > Reporter: Aashish Sharma > Priority: High > Fix For: 2.4 > > > Noticed that on certain restarts of bro-2.4-beta, logs arbitrarily disappear. > Restarts happen as > - broctl check; broctl restart > - broctl check; broctl restart --clean > - broctl restart > or some variant - not precisely sure. But all log files for that duration of restarts are missing -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 04:56:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 06:56:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21931#comment-21931 ] Seth Hall commented on BIT-1469: -------------------------------- Does anyone have packets they can contribute that tickle this issue? It would be nice to have an answer to Vlad's question on if these are packets that need to be reassembled. > dpd.log contains lots of binpac exceptions for RDP > -------------------------------------------------- > > Key: BIT-1469 > URL: https://bro-tracker.atlassian.net/browse/BIT-1469 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC, Bro > Affects Versions: git/master > Environment: RHEL 6.6, 2.4-10 bro build from git > Reporter: Gary Faulkner > Labels: analyzer > Fix For: 2.5 > > Attachments: rdp-31AUG15.pcap > > > RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP connections. > The following log line is an example of the error that repeats continuously during the activity: > 1441031469.413008 CPNcey4q2i8mGVUvEg 74.91.23.83 62082 10.10.81.207 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > The 10.x.x.x IP is the redacted local IP. The other IP is the scanner. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:10:01 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:10:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1461) Bro Mgr Scripts Fail After Threat Intel Feed Add In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1461: --------------------------- Priority: Low (was: Normal) > Bro Mgr Scripts Fail After Threat Intel Feed Add > ------------------------------------------------ > > Key: BIT-1461 > URL: https://bro-tracker.atlassian.net/browse/BIT-1461 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.5 > Reporter: Tim Jackson > Priority: Low > > Getting the following on check after inclusion of 3rd party threat intel feeds. Unsure of how to continue > manager scripts failed. > internal error: Value not found in enum mappimg. Module: Intel, var: undefined, var size: 9 > /opt/bro/share/broctl/scripts/check-config: line 28: 30661 Aborted (core dumped) ${bro} "$@" > proxy scripts are ok. > calidcbrosrv001-eth1-1 scripts are ok. > calidcbrosrv001-eth1-2 scripts are ok. > Thanks > Tim -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:11:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:11:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1460: --------------------------- Labels: analyzer (was: ) > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:13:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:13:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1438) Code example from the documentation fails with "unknown identifier" error In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1438: --------------------------- Resolution: Fixed Status: Closed (was: Open) > Code example from the documentation fails with "unknown identifier" error > ------------------------------------------------------------------------- > > Key: BIT-1438 > URL: https://bro-tracker.atlassian.net/browse/BIT-1438 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro, Documentation > Affects Versions: 2.3 > Environment: ArchLinux > Reporter: earl eiland > Labels: event, script > > event protocol_confirmation(c: connection, atype: Analyzer::Tag, aid: count) > { > local service_id = split_string_all("a-b--cd", /(\-)+/); > } > Executing this script fails with "unknown identifier split_string_all, at or near ?split_string_all??. > The split_string_all command is taken directly from the documentation: https://www.bro.org/sphinx/scripts/base/bif/strings.bif.bro.html#id-split_string_all -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:21:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:21:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1428) Customizable email subject lines In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21932#comment-21932 ] Seth Hall commented on BIT-1428: -------------------------------- I've been considering writing a simple mail or mailer framework for a while anyway. This could be a good reason to start on that so that adding support for extending code like this is much more straightforward. > Customizable email subject lines > -------------------------------- > > Key: BIT-1428 > URL: https://bro-tracker.atlassian.net/browse/BIT-1428 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Vern Paxson > > There should be a hook of some sort to allow customizing email Subject lines. In particular, I want emails sent for alarm summaries to include the hostname of the Bro that's sending them (since at ICSI we run two concurrent Bros). Looking at *pp_send* in *base/frameworks/notice/actions/pp-alarms.bro* I don't see any way to do this currently. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:23:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:23:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1418) SSH::Login_By_Password_Guesser is not implemented In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1418: --------------------------- Affects Version/s: 2.5 > SSH::Login_By_Password_Guesser is not implemented > ------------------------------------------------- > > Key: BIT-1418 > URL: https://bro-tracker.atlassian.net/browse/BIT-1418 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.5 > Reporter: Vern Paxson > > While that tag for this notice is defined, it's commented as not implemented. Seth indicated this is because it requires drawing upon distributed information, which doesn't have an apt framework yet. But this is precisely the sort of good-value, non-trivial-behavior notice that Bro should support. Presumably this can be done without requiring extensive inter-cluster-node communication. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:23:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:23:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1418) SSH::Login_By_Password_Guesser is not implemented In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21933#comment-21933 ] Seth Hall commented on BIT-1418: -------------------------------- This should be possible to implement with Broker's distributed key-value store in 2.5 > SSH::Login_By_Password_Guesser is not implemented > ------------------------------------------------- > > Key: BIT-1418 > URL: https://bro-tracker.atlassian.net/browse/BIT-1418 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.5 > Reporter: Vern Paxson > > While that tag for this notice is defined, it's commented as not implemented. Seth indicated this is because it requires drawing upon distributed information, which doesn't have an apt framework yet. But this is precisely the sort of good-value, non-trivial-behavior notice that Bro should support. Presumably this can be done without requiring extensive inter-cluster-node communication. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:24:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1413) README files misidentified by GitHub In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21934#comment-21934 ] Seth Hall commented on BIT-1413: -------------------------------- Vlad, are you up for doing this? > README files misidentified by GitHub > ------------------------------------ > > Key: BIT-1413 > URL: https://bro-tracker.atlassian.net/browse/BIT-1413 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Documentation > Reporter: Vlad Grigorescu > Fix For: 2.5 > > > If a README file doesn't have an extension, GitHub will parse it as Markdown. Because our README files are ReST, this results in some ugly (and not very useful) READMEs when visiting the repository on GitHub. > For example, see: https://github.com/bro/btest#readme > There are two options we could take to fix this: rename README to README.rst, or create a symlink. I tried out the symlink option here, and I think the result is much more useful: https://github.com/grigorescu/btest#readme > The affected repos are: > binpac > bro > bro-aux > bro-plugins > bro-scripts > broccoli > broccoli-perl > broccoli-python > broccoli-ruby > broctl (broctl's README just instructs users to see doc/broctl.rst. This could just be a symlink) > broker > bromagic (this can probably be deleted?) > btest > capstats > time-machine > trace-summary -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:24:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1413) README files misidentified by GitHub In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1413: ------------------------------ Assignee: Vlad Grigorescu > README files misidentified by GitHub > ------------------------------------ > > Key: BIT-1413 > URL: https://bro-tracker.atlassian.net/browse/BIT-1413 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Documentation > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > Fix For: 2.5 > > > If a README file doesn't have an extension, GitHub will parse it as Markdown. Because our README files are ReST, this results in some ugly (and not very useful) READMEs when visiting the repository on GitHub. > For example, see: https://github.com/bro/btest#readme > There are two options we could take to fix this: rename README to README.rst, or create a symlink. I tried out the symlink option here, and I think the result is much more useful: https://github.com/grigorescu/btest#readme > The affected repos are: > binpac > bro > bro-aux > bro-plugins > bro-scripts > broccoli > broccoli-perl > broccoli-python > broccoli-ruby > broctl (broctl's README just instructs users to see doc/broctl.rst. This could just be a symlink) > broker > bromagic (this can probably be deleted?) > btest > capstats > time-machine > trace-summary -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:26:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:26:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1411) SQL_Injection_Victim is a misleading name In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21935#comment-21935 ] Seth Hall commented on BIT-1411: -------------------------------- This is a good point and now I wish I had named it differently in the first place. I went with victim though because it's typical use was to discover cases where attackers were actively mapping out a database which made the target into a victim. :) I wonder if we're past the point where this is really changeable? We have to be careful changing stuff like this that people are relying on. I suppose it could be fine as long as it's included in the list of breaking changes that we've started writing for releases. > SQL_Injection_Victim is a misleading name > ----------------------------------------- > > Key: BIT-1411 > URL: https://bro-tracker.atlassian.net/browse/BIT-1411 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vern Paxson > > I suggest changing the name of this notice to {{SQL_Injection_Target}}. Having "victim" in the name implies to me that the attack succeeded, which is not what the associated logic is about. > Indeed, I even wonder if this notice is useful. The information should be directly available from {{SQL_Injection_Attacker}} notices (though it doesn't appear to be currently set up to provide this - why not?). -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:33:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:33:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1378) Include extract_files in archives In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1378: ------------------------------ Assignee: Daniel Thayer > Include extract_files in archives > --------------------------------- > > Key: BIT-1378 > URL: https://bro-tracker.atlassian.net/browse/BIT-1378 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.3 > Environment: Linux > Reporter: james.lay > Assignee: Daniel Thayer > Labels: cleanup, file > > Request to see about getting extract_files included in the 'normal' archiving process -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:33:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:33:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1398) PPPoE PCAP stripping laters In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1398: --------------------------- Labels: full_packet_capture (was: ) > PPPoE PCAP stripping laters > --------------------------- > > Key: BIT-1398 > URL: https://bro-tracker.atlassian.net/browse/BIT-1398 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Ubuntu 12.04.5 , pf_ring > Reporter: Jason > Labels: full_packet_capture > > Recently I discovered what I believe to be a problem with Bro's packet collection of PPPoE traffic. This occurs both on the wire and when reading in PCAP. > Here is a sample SSL session over PPPoE as captured by tcpdump: > 12:58:27.914864568 PPPoE [ses 0x279a] IP 192.168.110.235.25095 > 192.168.162.218.443: Flags [S], seq 2317077818, win 65535, options [mss 1380,nop,wscale 9,sackOK,TS val 139402792 ecr 0], length 0 > 12:58:28.091544568 PPPoE [ses 0x279a] IP 192.168.162.218.443 > 192.168.110.235.25095: Flags [S.], seq 2303200074, ack 2317077819, win 5792, options [mss 1460,sackOK,TS val 1200789536 ecr 139402792,nop,wscale 7], length 0 > 12:58:28.092020568 PPPoE [ses 0x279a] IP 192.168.110.235.25095 > 192.168.162.218.443: Flags [.], ack 1, win 513, options [nop,nop,TS val 139402972 ecr 1200789536], length 0 > 12:58:28.092579568 PPPoE [ses 0x279a] IP 192.168.110.235.25095 > 192.168.162.218.443: Flags [P.], seq 1:257, ack 1, win 513, options [nop,nop,TS val 139402972 ecr 1200789536], length 256 > 12:58:28.268976568 PPPoE [ses 0x279a] IP 192.168.162.218.443 > 192.168.110.235.25095: Flags [.], ack 257, win 54, options [nop,nop,TS val 1200789713 ecr 139402972], length 0 > Running this capture through Bro results in a valid ssl.log: > 1431435508.092579 C2fjf233dO59LO7sj9 192.168.110.235 25095 192.168.162.218 443 TLSv10 TLS_DHE_RSA_WITH_AES_256_CBC_SHA - some_website.com 7e710c9504f77e9fc8d18121ed965a25119c673b6b4e0a07b5bfcd5baadae534 - T - - - - -- > But the resulting PCAP coming out of Bro for the same packets looks like this: > 12:58:27.914864256 40:00:3f:06:da:8a > 45:00:00:3c:aa:49, ethertype Unknown (0x6e36), length 82: > 12:58:28.091544552 40:00:30:06:93:d4 > 45:00:00:3c:00:00, ethertype Unknown (0x36ec), length 82: > 12:58:28.092020256 40:00:3f:06:da:84 > 45:00:00:34:aa:57, ethertype Unknown (0x6e36), length 74: > 12:58:28.092579152 40:00:3f:06:d9:82 > 45:00:01:34:aa:59, ethertype Unknown (0x6e36), length 330: > 12:58:28.268976656 40:00:30:06:00:42 > 45:00:00:34:93:9a, ethertype Unknown (0x36ec), length 74: > Please let me know if you need any additional information. > Jason -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:37:00 2015 From: jira at bro-tracker.atlassian.net (Jan Grashoefer (JIRA)) Date: Fri, 4 Sep 2015 07:37:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1428) Customizable email subject lines In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21936#comment-21936 ] Jan Grashoefer commented on BIT-1428: ------------------------------------- Meanwhile: I am using broctl's MailSubjectPrefix to customize mail subjects per host manually (see [https://www.bro.org/sphinx/components/broctl/README.html#option-reference]). > Customizable email subject lines > -------------------------------- > > Key: BIT-1428 > URL: https://bro-tracker.atlassian.net/browse/BIT-1428 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Vern Paxson > > There should be a hook of some sort to allow customizing email Subject lines. In particular, I want emails sent for alarm summaries to include the hostname of the Bro that's sending them (since at ICSI we run two concurrent Bros). Looking at *pp_send* in *base/frameworks/notice/actions/pp-alarms.bro* I don't see any way to do this currently. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:38:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:38:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1378) Include extract_files in archives In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21937#comment-21937 ] Seth Hall commented on BIT-1378: -------------------------------- Daniel, would you mind exploring the ramifications of this? There are a lot of considerations that need to be taken into effect. - Compressing? (probably don't want to because of load) - Moving across file systems? - Probably don't want to allow this due to the extra disk io it could cause. - How would this look on clusters? - Logs are all centralized, how could we get a similar experience with files? > Include extract_files in archives > --------------------------------- > > Key: BIT-1378 > URL: https://bro-tracker.atlassian.net/browse/BIT-1378 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.3 > Environment: Linux > Reporter: james.lay > Assignee: Daniel Thayer > Labels: cleanup, file > > Request to see about getting extract_files included in the 'normal' archiving process -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:40:01 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:40:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21938#comment-21938 ] Seth Hall commented on BIT-1363: -------------------------------- It actually sort of is supported, but it's hacky. If you give lb_procs=10 and lb_method=myricom it will work. :) Anyway, you're right that this will take a teeny bit of extra effort to get it fully supported correctly. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:42:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:42:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1314) Detect "quantum insert" type of attacks In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1314: --------------------------- Resolution: Fixed Status: Closed (was: Open) This is already merged into master and is usable from there and will be a standard feature of 2.5. > Detect "quantum insert" type of attacks > --------------------------------------- > > Key: BIT-1314 > URL: https://bro-tracker.atlassian.net/browse/BIT-1314 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: David Andr? > > Add detection for "quantum insert" type of attacks. Since the leaked information is classified, I will try to explain in unclassified form what it is about. > The idea is that you have a passive adversary that sniff your TCP sequence numbers and inject its malicious payload faster than the real server. > One of the leaked documents mentions as an alerting mechanism to detect duplicate TCP sequence numbers from same source, where at least 10% of the beginning of the content of the two packets differs. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:47:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:47:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1047) Delete old scripts before installing new ones In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21940#comment-21940 ] Seth Hall commented on BIT-1047: -------------------------------- What's the status on this ticket? Have we arrived at a decision with how to handle it? We could certainly fix it in pieces too by merging Jon's branch related to deleting scripts before installing. That would fix a lot of people's trouble. It should be a good time to do it now too since we're still pretty early in the 2.5 cycle. Daniel, would you mind taking this on? > Delete old scripts before installing new ones > --------------------------------------------- > > Key: BIT-1047 > URL: https://bro-tracker.atlassian.net/browse/BIT-1047 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Fix For: 2.5 > > > People keep having problems when they install a new Bro version > over the installation of an old one because scripts that have disappeared in the new version will keep sticking around from the previous installation. > We should simply remove the old scripts/base and scripts/policy before installing anything new. People aren't supposed to edit in there so that should be safe. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:47:01 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:47:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1047) Delete old scripts before installing new ones In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1047: ------------------------------ Assignee: Daniel Thayer > Delete old scripts before installing new ones > --------------------------------------------- > > Key: BIT-1047 > URL: https://bro-tracker.atlassian.net/browse/BIT-1047 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Assignee: Daniel Thayer > Fix For: 2.5 > > > People keep having problems when they install a new Bro version > over the installation of an old one because scripts that have disappeared in the new version will keep sticking around from the previous installation. > We should simply remove the old scripts/base and scripts/policy before installing anything new. People aren't supposed to edit in there so that should be safe. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:48:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 4 Sep 2015 07:48:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1460: --------------------------------- Status: Merge Request (was: Open) > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:48:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 4 Sep 2015 07:48:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21941#comment-21941 ] Vlad Grigorescu commented on BIT-1460: -------------------------------------- The issue here is src/analyzer/protocol/dns/DNS.cc lines 58-68: {quote} // There is a great deal of non-DNS traffic that runs on port 53. // This should weed out most of it. if ( dns_max_queries > 0 && msg.qdcount > dns_max_queries ) { analyzer->ProtocolViolation("DNS_Conn_count_too_large"); analyzer->Weird("DNS_Conn_count_too_large"); EndMessage(&msg); return 0; } {quote} topic/vladg/bit-1460 makes dns_max_queries redef-able, and bumps up the limit from 5 to 25. Since multicast is so chatty, it might make sense to special case it and allow for a higher limit. That being said, I'm not sure there's much of a downside to setting the max a bit higher. > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:51:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:51:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-854) problem with VLAN/MPLS packet dumping In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-854: -------------------------- Resolution: Duplicate Status: Closed (was: Open) > problem with VLAN/MPLS packet dumping > ------------------------------------- > > Key: BIT-854 > URL: https://bro-tracker.atlassian.net/browse/BIT-854 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > > report from Carsten Langer: > {noformat} > By the way: you have in my opinion a problem with packet dumping. If the > trace contains VLAN or MPLS, you strip off VLAN/MPLS and if then you > dump the packet, then the dumped trace is missing the Ethernet header > for these packets, while the Ethernet header is still there for packets > which did not have VLAN/MPLS. My previous GTP-detunneling did the same > mistake, now I have introduced a fake Ethernet header so that if the > packet is dumped, is still has its Ethernet header. > {noformat} -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:51:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:51:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-854) problem with VLAN/MPLS packet dumping In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21942#comment-21942 ] Seth Hall commented on BIT-854: ------------------------------- This is related to BIT-1398 but that includes some more information so I'm going to close this one. > problem with VLAN/MPLS packet dumping > ------------------------------------- > > Key: BIT-854 > URL: https://bro-tracker.atlassian.net/browse/BIT-854 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > > report from Carsten Langer: > {noformat} > By the way: you have in my opinion a problem with packet dumping. If the > trace contains VLAN or MPLS, you strip off VLAN/MPLS and if then you > dump the packet, then the dumped trace is missing the Ethernet header > for these packets, while the Ethernet header is still there for packets > which did not have VLAN/MPLS. My previous GTP-detunneling did the same > mistake, now I have introduced a fake Ethernet header so that if the > packet is dumped, is still has its Ethernet header. > {noformat} -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:52:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:52:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-835) Porting Drop and Catch-n-release to 2.0 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21943#comment-21943 ] Seth Hall commented on BIT-835: ------------------------------- We should be able to get a very nice version of this into 2.5 with the Broker key-value store and the net control framework. We just need someone to take it on once enough of the infrastructure is in place. > Porting Drop and Catch-n-release to 2.0 > --------------------------------------- > > Key: BIT-835 > URL: https://bro-tracker.atlassian.net/browse/BIT-835 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Aashish Sharma > Fix For: 2.5 > > Attachments: drop.bro, drop-catch-n-release.patch, scan.bro, test-drop-connectivity, test-restore-connectivity > > > The following patch ports the drop.bro to bro-2.0+ (along with catch-n-release functionality) > [originally written for bro-1.5.3 and prior versions by Jim Mellander and Robin Sommer|policies] > Also attaching scan.bro (which is ported to 2.0) > scan.bro and drop.bro files need to go into policy/protocols/conn/ folder. > Also adding test-drop-connectivity and test-restore-connectivity scripts which should go into aux/broctl/bin/ > This patch and policies have been operational at LBNL for a few months now with bro-2.0. > (sorry haven't created my own branch to commit these) \\- please let me know if this need to be otherwise. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 05:52:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 07:52:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-835) Porting Drop and Catch-n-release to 2.0 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-835: -------------------------- Fix Version/s: 2.5 > Porting Drop and Catch-n-release to 2.0 > --------------------------------------- > > Key: BIT-835 > URL: https://bro-tracker.atlassian.net/browse/BIT-835 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Aashish Sharma > Fix For: 2.5 > > Attachments: drop.bro, drop-catch-n-release.patch, scan.bro, test-drop-connectivity, test-restore-connectivity > > > The following patch ports the drop.bro to bro-2.0+ (along with catch-n-release functionality) > [originally written for bro-1.5.3 and prior versions by Jim Mellander and Robin Sommer|policies] > Also attaching scan.bro (which is ported to 2.0) > scan.bro and drop.bro files need to go into policy/protocols/conn/ folder. > Also adding test-drop-connectivity and test-restore-connectivity scripts which should go into aux/broctl/bin/ > This patch and policies have been operational at LBNL for a few months now with bro-2.0. > (sorry haven't created my own branch to commit these) \\- please let me know if this need to be otherwise. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 06:02:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 4 Sep 2015 08:02:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1414) Make PIE option availalbe during compiling In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1414: --------------------------------- Resolution: Cannot Reproduce Status: Closed (was: Open) > Make PIE option availalbe during compiling > ------------------------------------------ > > Key: BIT-1414 > URL: https://bro-tracker.atlassian.net/browse/BIT-1414 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.3 > Environment: We would like to request PIE support be built in and available in the Bro binary. > Reporter: Jeff > -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 06:04:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 4 Sep 2015 08:04:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1413) README files misidentified by GitHub In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21944#comment-21944 ] Vlad Grigorescu commented on BIT-1413: -------------------------------------- Sure. I'll go with the symlink idea. > README files misidentified by GitHub > ------------------------------------ > > Key: BIT-1413 > URL: https://bro-tracker.atlassian.net/browse/BIT-1413 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Documentation > Reporter: Vlad Grigorescu > Assignee: Vlad Grigorescu > Fix For: 2.5 > > > If a README file doesn't have an extension, GitHub will parse it as Markdown. Because our README files are ReST, this results in some ugly (and not very useful) READMEs when visiting the repository on GitHub. > For example, see: https://github.com/bro/btest#readme > There are two options we could take to fix this: rename README to README.rst, or create a symlink. I tried out the symlink option here, and I think the result is much more useful: https://github.com/grigorescu/btest#readme > The affected repos are: > binpac > bro > bro-aux > bro-plugins > bro-scripts > broccoli > broccoli-perl > broccoli-python > broccoli-ruby > broctl (broctl's README just instructs users to see doc/broctl.rst. This could just be a symlink) > broker > bromagic (this can probably be deleted?) > btest > capstats > time-machine > trace-summary -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 06:16:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 08:16:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-809) HTTP file extraction not correct In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-809: -------------------------- Resolution: Fixed Status: Closed (was: Open) I just tested and this bug no longer exists in Bro. There was a lot of work done on internal file handling for the 2.4 release. > HTTP file extraction not correct > -------------------------------- > > Key: BIT-809 > URL: https://bro-tracker.atlassian.net/browse/BIT-809 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.0 > Reporter: dalton > Labels: HTTP > > I'm trying to use BRO to look at some pipelined HTTP traffic. I'm asking for file extraction but one of the extracted files is the wrong size. In the attached pcap, packet BIT-225 shows the content length as 41931. In the http.log file, I see this: > > 1312412117.323323 d8RHszXqnfi 192.168.123.105 37621 74.208.60.21 80 7 GET crev.info /images/interface/resources.png http://crev.info/ Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; HTC Dream Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 0 *41931* 200 OK \\- \\- \\- (empty) \\- \\- \\- image/png \\- http-item_192.168.123.105:37621-74.208.60.21:80_resp_7.dat > 1312412117.710518 d8RHszXqnfi 192.168.123.105 37621 74.208.60.21 80 8 GET crev.info /images/interface/navbar_li.png http://crev.info/ Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; HTC Dream Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 0 928 200 OK \\- \\- \\- (empty) \\- \\- \\- application/octet-stream \\- http-item_192.168.123.105:37621-74.208.60.21:80_resp_7.dat > > output dir listing: > \---\- > \-rw-r--r-\- 1 dporter dporter 1150 2012-04-10 21:59 http-item_192.168.123.105:37621-74.208.60.21:80_resp_10.dat > \-rw-r--r-\- 1 dporter dporter 60901 2012-04-10 21:59 http-item_192.168.123.105:37621-74.208.60.21:80_resp_1.dat > \-rw-r--r-\- 1 dporter dporter 72217 2012-04-10 21:59 http-item_192.168.123.105:37621-74.208.60.21:80_resp_2.dat > \-rw-r--r-\- 1 dporter dporter 330 2012-04-10 21:59 http-item_192.168.123.105:37621-74.208.60.21:80_resp_3.dat > \-rw-r--r-\- 1 dporter dporter 851 2012-04-10 21:59 http-item_192.168.123.105:37621-74.208.60.21:80_resp_4.dat > \-rw-r--r-\- 1 dporter dporter 716 2012-04-10 21:59 http-item_192.168.123.105:37621-74.208.60.21:80_resp_5.dat > \-rw-r--r-\- 1 dporter dporter 3408 2012-04-10 21:59 http-item_192.168.123.105:37621-74.208.60.21:80_resp_6.dat > \-rw-r--r-\- 1 dporter dporter *32931* 2012-04-10 21:59 http-item_192.168.123.105:37621-74.208.60.21:80_resp_7.dat > \-rw-r--r-\- 1 dporter dporter 771040 2012-04-10 21:59 http-item_192.168.123.105:37621-74.208.60.21:80_resp_9.dat > \---\- > > > The content length is correct in http.log, but the output file (..._resp_7) has length 32931. > Also, why does http.log indicate that both resources.png AND navbar_li.png are both written to resp_7.dat ? > > The results from xplico and wireshark when run on this pcap file look correct to me. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 06:19:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 08:19:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-789) An example of a BiF : computing Conficker P2P ports In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-789: -------------------------- Resolution: No longer applies Status: Closed (was: Open) Bifs like this can be written as plugins now and more and more examples of writing Bifs like this are showing up in various places. > An example of a BiF : computing Conficker P2P ports > --------------------------------------------------- > > Key: BIT-789 > URL: https://bro-tracker.atlassian.net/browse/BIT-789 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: git/master > Reporter: juliensentier > Attachments: 0012-A-patch-with-a-BiF-to-compute-the-Conficker-P2P-port.patch > > > The goal of this patch is to show how to make your own BiF rather than being actually used. > The BiF file contains a function which computes the Conficker P2P ports for an IP address. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 06:24:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 08:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-939) HTTP parser refact & redesign required In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-939: -------------------------- Resolution: Incomplete Status: Closed (was: Open) This ticket is old and unfortunately light on details. If you have more details (packets captures, specific places where things are failing, etc) that would be helpful and we could reopen this ticket. > HTTP parser refact & redesign required > -------------------------------------- > > Key: BIT-939 > URL: https://bro-tracker.atlassian.net/browse/BIT-939 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: drmckay > Fix For: 2.5 > > > Hi, > In the HTTP parser implementation you following an old, obsoleted rfc from 1999. There is a newer version: http://tools.ietf.org/html/rfc3986 > Please, review and refact your code (unescapeURI() redesign also needed, to minimalize false positives). > Thanks. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 06:26:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 08:26:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1026) runtime error with local set of record with optional fields In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1026: --------------------------- Resolution: No longer applies Status: Closed (was: Open) I'm going to close this since we typically recommend that people use the function-style initializers for sets/tables/vectors now. > runtime error with local set of record with optional fields > ----------------------------------------------------------- > > Key: BIT-1026 > URL: https://bro-tracker.atlassian.net/browse/BIT-1026 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: dmandelb > Fix For: 2.5 > > > This code: > {noformat} > type Foo: record { > a: count &optional; > b: count &optional; > }; > event bro_init() { > local foos: set[Foo] = {}; > add foos[[$a=0]]; > print(foos); > } > {noformat} > Gives this output: > {noformat} > error in and /home/dmandelb/reps/test.bro, line 7: index type doesn't match table ([a=0, b=] and list of any) > { > } > {noformat} -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 06:27:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 08:27:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-898) Confusion over the accept_input field in communication code In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-898: -------------------------- Resolution: No longer applies Status: Closed (was: Open) This code is all going away and/or being refactored now. > Confusion over the accept_input field in communication code > ----------------------------------------------------------- > > Key: BIT-898 > URL: https://bro-tracker.atlassian.net/browse/BIT-898 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.5 > > > The communication framework configuration include a field named accept_input which isn't named well and seems to be over used. The result of it is that state is synchronized between the manager and workers which shouldn't be happening. This will require some discussion before removing the functionality though because pushing data from the manager to workers can be useful on clusters where data is read with the input framework and needs to be distributed to the workers. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 06:29:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 08:29:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1033) add script based on BBN's ICMP analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21950#comment-21950 ] Seth Hall commented on BIT-1033: -------------------------------- Vlad, you want to take this on? I agree that it would be a neat script to add in. > add script based on BBN's ICMP analyzer > --------------------------------------- > > Key: BIT-1033 > URL: https://bro-tracker.atlassian.net/browse/BIT-1033 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: git/master > Reporter: dmandelb > Fix For: 2.5 > > Attachments: 0001-add-script-based-on-BBN-s-ICMP-analyzer.patch > > -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 06:29:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 08:29:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1033) add script based on BBN's ICMP analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1033: ------------------------------ Assignee: Vlad Grigorescu > add script based on BBN's ICMP analyzer > --------------------------------------- > > Key: BIT-1033 > URL: https://bro-tracker.atlassian.net/browse/BIT-1033 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: git/master > Reporter: dmandelb > Assignee: Vlad Grigorescu > Fix For: 2.5 > > Attachments: 0001-add-script-based-on-BBN-s-ICMP-analyzer.patch > > -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 07:57:00 2015 From: jira at bro-tracker.atlassian.net (Gary Faulkner (JIRA)) Date: Fri, 4 Sep 2015 09:57:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21951#comment-21951 ] Gary Faulkner commented on BIT-1469: ------------------------------------ I can try to get another capture of the scanning activity if it would help. > dpd.log contains lots of binpac exceptions for RDP > -------------------------------------------------- > > Key: BIT-1469 > URL: https://bro-tracker.atlassian.net/browse/BIT-1469 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC, Bro > Affects Versions: git/master > Environment: RHEL 6.6, 2.4-10 bro build from git > Reporter: Gary Faulkner > Labels: analyzer > Fix For: 2.5 > > Attachments: rdp-31AUG15.pcap > > > RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP connections. > The following log line is an example of the error that repeats continuously during the activity: > 1441031469.413008 CPNcey4q2i8mGVUvEg 74.91.23.83 62082 10.10.81.207 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > The 10.x.x.x IP is the redacted local IP. The other IP is the scanner. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 08:30:02 2015 From: jira at bro-tracker.atlassian.net (Gary Faulkner (JIRA)) Date: Fri, 4 Sep 2015 10:30:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21952#comment-21952 ] Gary Faulkner commented on BIT-1469: ------------------------------------ I'm attaching a new pcap that should have the packets that triggered the following 4 log entries: 1441379884.683573 CGPOHznCQJ9G58EF5 96.62.17.17 16168 xxx.xxx.62.201 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380002.167146 CmS94x2tcBToBTE1Rc 96.62.17.17 25347 xxx.xxx.98.199 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380035.230494 CkAfMN3ZndOhBJCs7d 96.62.17.17 27894 xxx.xxx.64.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380086.101330 CTOK0y3yGu8YAq3MNi 96.62.17.17 31730 xxx.xxx.193.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > dpd.log contains lots of binpac exceptions for RDP > -------------------------------------------------- > > Key: BIT-1469 > URL: https://bro-tracker.atlassian.net/browse/BIT-1469 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC, Bro > Affects Versions: git/master > Environment: RHEL 6.6, 2.4-10 bro build from git > Reporter: Gary Faulkner > Labels: analyzer > Fix For: 2.5 > > Attachments: rdp-31AUG15.pcap > > > RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP connections. > The following log line is an example of the error that repeats continuously during the activity: > 1441031469.413008 CPNcey4q2i8mGVUvEg 74.91.23.83 62082 10.10.81.207 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > The 10.x.x.x IP is the redacted local IP. The other IP is the scanner. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 08:31:00 2015 From: jira at bro-tracker.atlassian.net (Gary Faulkner (JIRA)) Date: Fri, 4 Sep 2015 10:31:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Faulkner updated BIT-1469: ------------------------------- Attachment: bad-rdp-04SEP15.pcap > dpd.log contains lots of binpac exceptions for RDP > -------------------------------------------------- > > Key: BIT-1469 > URL: https://bro-tracker.atlassian.net/browse/BIT-1469 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC, Bro > Affects Versions: git/master > Environment: RHEL 6.6, 2.4-10 bro build from git > Reporter: Gary Faulkner > Labels: analyzer > Fix For: 2.5 > > Attachments: bad-rdp-04SEP15.pcap, rdp-31AUG15.pcap > > > RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP connections. > The following log line is an example of the error that repeats continuously during the activity: > 1441031469.413008 CPNcey4q2i8mGVUvEg 74.91.23.83 62082 10.10.81.207 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > The 10.x.x.x IP is the redacted local IP. The other IP is the scanner. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 08:32:00 2015 From: jira at bro-tracker.atlassian.net (Gary Faulkner (JIRA)) Date: Fri, 4 Sep 2015 10:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21952#comment-21952 ] Gary Faulkner edited comment on BIT-1469 at 9/4/15 10:31 AM: ------------------------------------------------------------- I'm attaching a new pcap that should have the packets that triggered the following 3 log entries: 1441380002.167146 CmS94x2tcBToBTE1Rc 96.62.17.17 25347 xxx.xxx.98.199 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380035.230494 CkAfMN3ZndOhBJCs7d 96.62.17.17 27894 xxx.xxx.64.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380086.101330 CTOK0y3yGu8YAq3MNi 96.62.17.17 31730 xxx.xxx.193.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 was (Author: gfaulkner): I'm attaching a new pcap that should have the packets that triggered the following 4 log entries: 1441379884.683573 CGPOHznCQJ9G58EF5 96.62.17.17 16168 xxx.xxx.62.201 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380002.167146 CmS94x2tcBToBTE1Rc 96.62.17.17 25347 xxx.xxx.98.199 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380035.230494 CkAfMN3ZndOhBJCs7d 96.62.17.17 27894 xxx.xxx.64.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380086.101330 CTOK0y3yGu8YAq3MNi 96.62.17.17 31730 xxx.xxx.193.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > dpd.log contains lots of binpac exceptions for RDP > -------------------------------------------------- > > Key: BIT-1469 > URL: https://bro-tracker.atlassian.net/browse/BIT-1469 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC, Bro > Affects Versions: git/master > Environment: RHEL 6.6, 2.4-10 bro build from git > Reporter: Gary Faulkner > Labels: analyzer > Fix For: 2.5 > > Attachments: bad-rdp-04SEP15.pcap, rdp-31AUG15.pcap > > > RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP connections. > The following log line is an example of the error that repeats continuously during the activity: > 1441031469.413008 CPNcey4q2i8mGVUvEg 74.91.23.83 62082 10.10.81.207 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > The 10.x.x.x IP is the redacted local IP. The other IP is the scanner. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 08:33:00 2015 From: jira at bro-tracker.atlassian.net (Gary Faulkner (JIRA)) Date: Fri, 4 Sep 2015 10:33:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21952#comment-21952 ] Gary Faulkner edited comment on BIT-1469 at 9/4/15 10:32 AM: ------------------------------------------------------------- I'm attaching a new pcap that should have the packets that triggered the following 3 log entries: 1441380002.167146 CmS94x2tcBToBTE1Rc 96.62.17.17 25347 xxx.xxx.98.199 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380035.230494 CkAfMN3ZndOhBJCs7d 96.62.17.17 27894 xxx.xxx.64.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380086.101330 CTOK0y3yGu8YAq3MNi 96.62.17.17 31730 xxx.xxx.193.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 bad-rdp-04SEP15.pcap should have the above 3 conversations. was (Author: gfaulkner): I'm attaching a new pcap that should have the packets that triggered the following 3 log entries: 1441380002.167146 CmS94x2tcBToBTE1Rc 96.62.17.17 25347 xxx.xxx.98.199 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380035.230494 CkAfMN3ZndOhBJCs7d 96.62.17.17 27894 xxx.xxx.64.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441380086.101330 CTOK0y3yGu8YAq3MNi 96.62.17.17 31730 xxx.xxx.193.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > dpd.log contains lots of binpac exceptions for RDP > -------------------------------------------------- > > Key: BIT-1469 > URL: https://bro-tracker.atlassian.net/browse/BIT-1469 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC, Bro > Affects Versions: git/master > Environment: RHEL 6.6, 2.4-10 bro build from git > Reporter: Gary Faulkner > Labels: analyzer > Fix For: 2.5 > > Attachments: bad-rdp-04SEP15.pcap, rdp-31AUG15.pcap > > > RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP connections. > The following log line is an example of the error that repeats continuously during the activity: > 1441031469.413008 CPNcey4q2i8mGVUvEg 74.91.23.83 62082 10.10.81.207 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > The 10.x.x.x IP is the redacted local IP. The other IP is the scanner. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 08:47:00 2015 From: jira at bro-tracker.atlassian.net (Gary Faulkner (JIRA)) Date: Fri, 4 Sep 2015 10:47:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Faulkner updated BIT-1469: ------------------------------- Attachment: bad-rdp-04SEP15-2.pcap > dpd.log contains lots of binpac exceptions for RDP > -------------------------------------------------- > > Key: BIT-1469 > URL: https://bro-tracker.atlassian.net/browse/BIT-1469 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC, Bro > Affects Versions: git/master > Environment: RHEL 6.6, 2.4-10 bro build from git > Reporter: Gary Faulkner > Labels: analyzer > Fix For: 2.5 > > Attachments: bad-rdp-04SEP15-2.pcap, bad-rdp-04SEP15.pcap, rdp-31AUG15.pcap > > > RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP connections. > The following log line is an example of the error that repeats continuously during the activity: > 1441031469.413008 CPNcey4q2i8mGVUvEg 74.91.23.83 62082 10.10.81.207 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > The 10.x.x.x IP is the redacted local IP. The other IP is the scanner. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 08:49:00 2015 From: jira at bro-tracker.atlassian.net (Gary Faulkner (JIRA)) Date: Fri, 4 Sep 2015 10:49:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21953#comment-21953 ] Gary Faulkner commented on BIT-1469: ------------------------------------ Sorry, let's try this again with snaplen set to 1514. bad-rdp-04SEP15-2.pcap should have the full packet for the following alerts: 1441381279.831679 Cma3pM3jbrVTDV5Ev8 96.62.17.17 61206 xxx.xxx.64.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441381310.466655 C0XEFADoqNaRk8P1h 96.62.17.17 63543 xxx.xxx.62.134 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 1441381326.717656 Cfg1pMVWT81RwKF52 96.62.17.17 64869 xxx.xxx.193.242 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > dpd.log contains lots of binpac exceptions for RDP > -------------------------------------------------- > > Key: BIT-1469 > URL: https://bro-tracker.atlassian.net/browse/BIT-1469 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC, Bro > Affects Versions: git/master > Environment: RHEL 6.6, 2.4-10 bro build from git > Reporter: Gary Faulkner > Labels: analyzer > Fix For: 2.5 > > Attachments: bad-rdp-04SEP15-2.pcap, bad-rdp-04SEP15.pcap, rdp-31AUG15.pcap > > > RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP connections. > The following log line is an example of the error that repeats continuously during the activity: > 1441031469.413008 CPNcey4q2i8mGVUvEg 74.91.23.83 62082 10.10.81.207 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > The 10.x.x.x IP is the redacted local IP. The other IP is the scanner. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 09:05:01 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 4 Sep 2015 11:05:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1396) Logs disappearing on broctl restart In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer reassigned BIT-1396: ---------------------------------- Assignee: Daniel Thayer > Logs disappearing on broctl restart > ----------------------------------- > > Key: BIT-1396 > URL: https://bro-tracker.atlassian.net/browse/BIT-1396 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: 2.4 > Reporter: Aashish Sharma > Assignee: Daniel Thayer > Priority: High > Fix For: 2.4 > > > Noticed that on certain restarts of bro-2.4-beta, logs arbitrarily disappear. > Restarts happen as > - broctl check; broctl restart > - broctl check; broctl restart --clean > - broctl restart > or some variant - not precisely sure. But all log files for that duration of restarts are missing -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 09:14:00 2015 From: jira at bro-tracker.atlassian.net (Aashish Sharma (JIRA)) Date: Fri, 4 Sep 2015 11:14:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1396) Logs disappearing on broctl restart In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21954#comment-21954 ] Aashish Sharma commented on BIT-1396: ------------------------------------- Please close it! If I encounter this again, I will request a new ticket !!! > Logs disappearing on broctl restart > ----------------------------------- > > Key: BIT-1396 > URL: https://bro-tracker.atlassian.net/browse/BIT-1396 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: 2.4 > Reporter: Aashish Sharma > Assignee: Daniel Thayer > Priority: High > Fix For: 2.4 > > > Noticed that on certain restarts of bro-2.4-beta, logs arbitrarily disappear. > Restarts happen as > - broctl check; broctl restart > - broctl check; broctl restart --clean > - broctl restart > or some variant - not precisely sure. But all log files for that duration of restarts are missing -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 09:17:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 4 Sep 2015 11:17:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1396) Logs disappearing on broctl restart In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1396: ------------------------------- Resolution: Cannot Reproduce Fix Version/s: (was: 2.4) Status: Closed (was: Reopened) > Logs disappearing on broctl restart > ----------------------------------- > > Key: BIT-1396 > URL: https://bro-tracker.atlassian.net/browse/BIT-1396 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: 2.4 > Reporter: Aashish Sharma > Assignee: Daniel Thayer > Priority: High > > Noticed that on certain restarts of bro-2.4-beta, logs arbitrarily disappear. > Restarts happen as > - broctl check; broctl restart > - broctl check; broctl restart --clean > - broctl restart > or some variant - not precisely sure. But all log files for that duration of restarts are missing -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From asharma at lbl.gov Fri Sep 4 09:24:06 2015 From: asharma at lbl.gov (Aashish Sharma) Date: Fri, 4 Sep 2015 09:24:06 -0700 Subject: [Bro-Dev] [JIRA] (BIT-835) Porting Drop and Catch-n-release to 2.0 In-Reply-To: References: Message-ID: <20150904162227.GA30813@yaksha.lbl.gov> > We just need someone to take it on once enough of the infrastructure is in place. I'd take this one! On Fri, Sep 04, 2015 at 07:52:00AM -0500, Seth Hall (JIRA) wrote: > > [ https://bro-tracker.atlassian.net/browse/BIT-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21943#comment-21943 ] > > Seth Hall commented on BIT-835: > ------------------------------- > > We should be able to get a very nice version of this into 2.5 with the Broker key-value store and the net control framework. We just need someone to take it on once enough of the infrastructure is in place. > > > Porting Drop and Catch-n-release to 2.0 > > --------------------------------------- > > > > Key: BIT-835 > > URL: https://bro-tracker.atlassian.net/browse/BIT-835 > > Project: Bro Issue Tracker > > Issue Type: New Feature > > Components: Bro > > Affects Versions: git/master > > Reporter: Aashish Sharma > > Fix For: 2.5 > > > > Attachments: drop.bro, drop-catch-n-release.patch, scan.bro, test-drop-connectivity, test-restore-connectivity > > > > > > The following patch ports the drop.bro to bro-2.0+ (along with catch-n-release functionality) > > [originally written for bro-1.5.3 and prior versions by Jim Mellander and Robin Sommer|policies] > > Also attaching scan.bro (which is ported to 2.0) > > scan.bro and drop.bro files need to go into policy/protocols/conn/ folder. > > Also adding test-drop-connectivity and test-restore-connectivity scripts which should go into aux/broctl/bin/ > > This patch and policies have been operational at LBNL for a few months now with bro-2.0. > > (sorry haven't created my own branch to commit these) \\- please let me know if this need to be otherwise. > > > > -- > This message was sent by Atlassian JIRA > (v7.0.0-OD-02-259#70102) > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev From jira at bro-tracker.atlassian.net Fri Sep 4 09:26:00 2015 From: jira at bro-tracker.atlassian.net (Aashish Sharma (JIRA)) Date: Fri, 4 Sep 2015 11:26:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-835) Porting Drop and Catch-n-release to 2.0 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21955#comment-21955 ] Aashish Sharma commented on BIT-835: ------------------------------------ I'd take this one! On Fri, Sep 04, 2015 at 07:52:00AM -0500, Seth Hall (JIRA) wrote: We just need someone to take it on once enough of the infrastructure is in place. > Porting Drop and Catch-n-release to 2.0 > --------------------------------------- > > Key: BIT-835 > URL: https://bro-tracker.atlassian.net/browse/BIT-835 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Aashish Sharma > Fix For: 2.5 > > Attachments: drop.bro, drop-catch-n-release.patch, scan.bro, test-drop-connectivity, test-restore-connectivity > > > The following patch ports the drop.bro to bro-2.0+ (along with catch-n-release functionality) > [originally written for bro-1.5.3 and prior versions by Jim Mellander and Robin Sommer|policies] > Also attaching scan.bro (which is ported to 2.0) > scan.bro and drop.bro files need to go into policy/protocols/conn/ folder. > Also adding test-drop-connectivity and test-restore-connectivity scripts which should go into aux/broctl/bin/ > This patch and policies have been operational at LBNL for a few months now with bro-2.0. > (sorry haven't created my own branch to commit these) \\- please let me know if this need to be otherwise. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:04:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 4 Sep 2015 13:04:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1336) ElasticSearch indices in UTC In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21956#comment-21956 ] Vlad Grigorescu commented on BIT-1336: -------------------------------------- The fix for this is in topic/vladg/es-fixes in the bro-plugins repo, although the defaults were kept the same. > ElasticSearch indices in UTC > ---------------------------- > > Key: BIT-1336 > URL: https://bro-tracker.atlassian.net/browse/BIT-1336 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Assignee: Seth Hall > Priority: Trivial > Fix For: 2.5 > > > For improved compatibility with Kibana and other ElasticSearch frontends, the timestamps on the Bro indices should be changed to UTC. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:04:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 4 Sep 2015 13:04:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1336) ElasticSearch indices in UTC In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1336: --------------------------------- Status: Merge Request (was: Open) Assignee: (was: Seth Hall) > ElasticSearch indices in UTC > ---------------------------- > > Key: BIT-1336 > URL: https://bro-tracker.atlassian.net/browse/BIT-1336 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: 2.4 > Reporter: Vlad Grigorescu > Priority: Trivial > Fix For: 2.5 > > > For improved compatibility with Kibana and other ElasticSearch frontends, the timestamps on the Bro indices should be changed to UTC. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:19:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:19:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1472) Bif for a new function to calculates haversine distance between two geoip locations In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1472: ------------------------------ Assignee: Daniel Thayer > Bif for a new function to calculates haversine distance between two geoip locations > ----------------------------------------------------------------------------------- > > Key: BIT-1472 > URL: https://bro-tracker.atlassian.net/browse/BIT-1472 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Aashish Sharma > Assignee: Daniel Thayer > Labels: bif, function > > Merge request for: > topic/aashish/haversine > ## ## Calculates haversine distance between two geoip locations > ## > ## > ## lat1, long1, lat2, long2 > ## > ## Returns: distance in miles > ## function haversine_distance%(lat1:double, long1:double, lat2:double, long2:double %): double > accompanying bro policy in base/utils/haversine_distance_ip.bro > module GLOBAL; > ## Returns the haversine distance between two IP addresses based on GeoIP > ## database locations > ## > ## > ## orig: the address of orig connection > ## resp: the address of resp server > ## Returns: the GeoIP distance between orig and resp in miles > function haversine_distance_ip(orig: addr, resp: addr): double -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:19:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:19:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1472) Bif for a new function to calculates haversine distance between two geoip locations In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21957#comment-21957 ] Seth Hall commented on BIT-1472: -------------------------------- We need to update to the libGeoIP2 API anyway and we could pull these as BiFs into the new plugin that would be created. > Bif for a new function to calculates haversine distance between two geoip locations > ----------------------------------------------------------------------------------- > > Key: BIT-1472 > URL: https://bro-tracker.atlassian.net/browse/BIT-1472 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Aashish Sharma > Labels: bif, function > > Merge request for: > topic/aashish/haversine > ## ## Calculates haversine distance between two geoip locations > ## > ## > ## lat1, long1, lat2, long2 > ## > ## Returns: distance in miles > ## function haversine_distance%(lat1:double, long1:double, lat2:double, long2:double %): double > accompanying bro policy in base/utils/haversine_distance_ip.bro > module GLOBAL; > ## Returns the haversine distance between two IP addresses based on GeoIP > ## database locations > ## > ## > ## orig: the address of orig connection > ## resp: the address of resp server > ## Returns: the GeoIP distance between orig and resp in miles > function haversine_distance_ip(orig: addr, resp: addr): double -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:23:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:23:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1470) Implemented Functions in Notice Framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1470: ------------------------------ Assignee: Daniel Thayer > Implemented Functions in Notice Framework > ----------------------------------------- > > Key: BIT-1470 > URL: https://bro-tracker.atlassian.net/browse/BIT-1470 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.3 > Reporter: Wendy Edwards > Assignee: Daniel Thayer > Attachments: main_mod.bro, notice_main.patch > > > I modified the main.bro file in the notice framework (see https://github.com/bro/bro/blob/master/scripts/base/frameworks/notice/main.bro) to implement the functions "notice_tags" and "execute_with_notice." The patch (notice_main.patch) and the modified file (main_mod.bro) are both attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:25:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:25:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1469: ------------------------------ Assignee: Vlad Grigorescu > dpd.log contains lots of binpac exceptions for RDP > -------------------------------------------------- > > Key: BIT-1469 > URL: https://bro-tracker.atlassian.net/browse/BIT-1469 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC, Bro > Affects Versions: git/master > Environment: RHEL 6.6, 2.4-10 bro build from git > Reporter: Gary Faulkner > Assignee: Vlad Grigorescu > Labels: analyzer > Fix For: 2.5 > > Attachments: bad-rdp-04SEP15-2.pcap, bad-rdp-04SEP15.pcap, rdp-31AUG15.pcap > > > RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP connections. > The following log line is an example of the error that repeats continuously during the activity: > 1441031469.413008 CPNcey4q2i8mGVUvEg 74.91.23.83 62082 10.10.81.207 3389 tcp RDP Binpac exception: binpac exception: out_of_bound: DT_Data:application_type: 3 > 2 > The 10.x.x.x IP is the redacted local IP. The other IP is the scanner. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:27:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:27:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1462) heap overflow in ARP_Analyzer::IsARP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1462: --------------------------- Resolution: Fixed Status: Closed (was: Open) > heap overflow in ARP_Analyzer::IsARP > ------------------------------------ > > Key: BIT-1462 > URL: https://bro-tracker.atlassian.net/browse/BIT-1462 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Justin Azoff > Assignee: Robin Sommer > Attachments: arp_bug.pcap > > > {code} > # bro -r arp_bug.pcap > ================================================================= > ==8775==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6310008c07fe at pc 0x00000099a56e bp 0x7fffd1826e60 sp 0x7fffd1826e58 > READ of size 2 at 0x6310008c07fe thread T0 > #0 0x99a56d in analyzer::arp::ARP_Analyzer::IsARP(unsigned char const*, int) /scratch/bro-clean/src/analyzer/protocol/arp/ARP.cc:24:2 > #1 0x855781 in NetSessions::NextPacket(double, pcap_pkthdr const*, unsigned char const*, int) /scratch/bro-clean/src/Sessions.cc:246:12 > #2 0x7ba30f in net_packet_dispatch(double, pcap_pkthdr const*, unsigned char const*, int, iosource::PktSrc*) /scratch/bro-clean/src/Net.cc:281:2 > #3 0xda1c1b in iosource::PktSrc::Process() /scratch/bro-clean/src/iosource/PktSrc.cc:423:3 > #4 0x7ba7bf in net_run() /scratch/bro-clean/src/Net.cc:330:4 > #5 0x641d9c in main /scratch/bro-clean/src/main.cc:1199:3 > #6 0x7fc0ba545b44 in __libc_start_main /tmp/buildd/glibc-2.19/csu/libc-start.c:287 > #7 0x5ee98c in _start (/scratch/bro-clean/build/src/bro+0x5ee98c) > {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:27:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:27:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1468) logging documentation incomplete In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1468: ------------------------------ Assignee: Daniel Thayer > logging documentation incomplete > -------------------------------- > > Key: BIT-1468 > URL: https://bro-tracker.atlassian.net/browse/BIT-1468 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.5 > > > https://www.bro.org/development/logging.html currently is incomplete; e.g. rotation is empty and the next section contains a sentence missing a link. > I am not even sure if we link that page from anywhere, and what its relationship to https://www.bro.org/sphinx-git/frameworks/logging.html is - but it is one of the top search results on google. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:31:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:31:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1460: ------------------------------ Assignee: Seth Hall > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Seth Hall > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:31:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:31:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1460: ------------------------------ Assignee: Robin Sommer (was: Seth Hall) > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Robin Sommer > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:32:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21958#comment-21958 ] Seth Hall commented on BIT-1460: -------------------------------- It might make sense to go ahead and merge this into master and see if it causes performance problems for anyone. > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Robin Sommer > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:32:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1451) File extraction limits broken In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1451: ------------------------------ Assignee: Seth Hall > File extraction limits broken > ----------------------------- > > Key: BIT-1451 > URL: https://bro-tracker.atlassian.net/browse/BIT-1451 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.4 > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.5 > > > As reported by Jason Batchelor on the mailing list, Bro 2.4 doesn't seem to be respecting file extraction limits. I suspect this is due to the file reassembly changes that went into Bro 2.4. We need to create a test case for this situation once we figure out how to reliably make it fail. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:37:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:37:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1450) Improve Python API In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21959#comment-21959 ] Seth Hall commented on BIT-1450: -------------------------------- Justin is going to watch this ticket and maybe look into doing this. > Improve Python API > ------------------ > > Key: BIT-1450 > URL: https://bro-tracker.atlassian.net/browse/BIT-1450 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Broker > Affects Versions: 2.4 > Reporter: Robin Sommer > Fix For: 2.5 > > > The Python API is a bit cumbersome still as it requires (1) manually wrapping values with {{data}} instances, and (2) also generally reflects C semantics a bit too much, leading to some "unPythonic" idioms. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:40:01 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:40:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1444) Connection logging for ESP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1444: ------------------------------ Assignee: Vlad Grigorescu > Connection logging for ESP > -------------------------- > > Key: BIT-1444 > URL: https://bro-tracker.atlassian.net/browse/BIT-1444 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Jimmy Jones > Assignee: Vlad Grigorescu > > I'd like to be able to track ESP (IPSec) connections in conn.log. Although ESP is encrypted, the ability to track volumes and pattern of life etc would be beneficial when doing intrusion analysis. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:44:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:44:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1444) Connection logging for ESP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1444: --------------------------- Priority: Low (was: Normal) > Connection logging for ESP > -------------------------- > > Key: BIT-1444 > URL: https://bro-tracker.atlassian.net/browse/BIT-1444 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Jimmy Jones > Assignee: Vlad Grigorescu > Priority: Low > > I'd like to be able to track ESP (IPSec) connections in conn.log. Although ESP is encrypted, the ability to track volumes and pattern of life etc would be beneficial when doing intrusion analysis. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:44:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:44:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1444) Connection logging for ESP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21960#comment-21960 ] Seth Hall commented on BIT-1444: -------------------------------- Let's get some packet captures attached to this ticket. That going to be the best way to support this. We will look into supporting a mechanism where we can report how much unsupported traffic is seen until we support the IPSec protocols. > Connection logging for ESP > -------------------------- > > Key: BIT-1444 > URL: https://bro-tracker.atlassian.net/browse/BIT-1444 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Jimmy Jones > Assignee: Vlad Grigorescu > Priority: Low > > I'd like to be able to track ESP (IPSec) connections in conn.log. Although ESP is encrypted, the ability to track volumes and pattern of life etc would be beneficial when doing intrusion analysis. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:47:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:47:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1441) Logrotation cannot be set when using path_func In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1441: --------------------------- Fix Version/s: 2.5 > Logrotation cannot be set when using path_func > ---------------------------------------------- > > Key: BIT-1441 > URL: https://bro-tracker.atlassian.net/browse/BIT-1441 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Environment: SLC6, PF_RING, broctl > Reporter: Jan Grashoefer > Fix For: 2.5 > > Attachments: path_func_bug.bro > > > I had a problem using Bro's filtering on my Bro cluster (using broctl). I wanted to create separate logfiles in JSON format for some streams. As the file name should include the current date, I specified a path_func. So far everything worked as expected. Then I tried to disable the logrotation for these files by setting interv = 0. Unfortunately this did not work. Setting a fixed path, disabling logrotation worked as intended (see [http://try.bro.org/#/trybro/saved/14143] an example of the code I used). > I investigated this issue and think, I have discovered a problem. The rotation interval for a writer is determined in CreateWriter in manager.cc (see [https://github.com/bro/bro/blob/2b1cd66f17194a30b90490965cbdffdd71c18c09/src/logging/Manager.cc#L1064]) based on the filter. The filter again is determined by writer and path (I don't understand why the name of the filter is not used but there may be reasons). To see whether the interval is set correctly I added some debug output here. Then I did a test specifying a filter for HTTP using path_func and a filter for CONN using a fixed path. > On my worker I get the expected output (except the interval seems wrong): > {quote} 0.000000/1437813255.656896 [logging] Set interval for 'packet_filter' (filter 'default') to '86400.000000' > 0.000000/1437813255.658523 [logging] Set interval for 'loaded_scripts' (filter 'default') to '86400.000000' > 0.000000/1437813255.685123 [logging] Set interval for 'communication' (filter 'default') to '86400.000000' > 1437813255.644956/1437813255.709181 [logging] Set interval for 'stats' (filter 'default') to '86400.000000' > 1437813255.644965/1437813255.710468 [logging] Set interval for 'weird' (filter 'default') to '86400.000000' > 1437813255.822196/1437813255.834760 [logging] Set interval for 'reporter' (filter 'default') to '86400.000000' > 1437813256.015793/1437813256.027556 [logging] Set interval for 'software' (filter 'default') to '86400.000000' > 1437813256.015793/1437813256.039455 [logging] Set interval for 'files' (filter 'default') to '86400.000000' > 1437813256.015793/1437813256.040269 [logging] Set interval for 'http' (filter 'default') to '86400.000000' > 1437813256.015793/1437813256.040504 [logging] Set interval for '/var/opt/bro/logs-json/http-2015-07-25' (filter 'http_json') to '0.000000' > 1437813257.512453/1437813257.523782 [logging] Set interval for 'x509' (filter 'default') to '86400.000000' > 1437813260.645607/1437813260.656385 [logging] Set interval for 'conn' (filter 'default') to '86400.000000' > 1437813260.645607/1437813260.656526 [logging] Set interval for '/var/opt/bro/logs-json/conn' (filter 'conn_json') to '0.000000' > 1437813262.827012/1437813262.839179 [logging] Set interval for 'dns' (filter 'default') to '86400.000000' > 1437813263.401981/1437813263.411552 [logging] Set interval for 'ssl' (filter 'default') to '86400.000000' > 1437813293.565530/1437813293.575182 [logging] Set interval for 'kerberos' (filter 'default') to '86400.000000'{quote} > But on the manager I get the following: > {quote}1437813085.377826/1437813085.387819 [logging] Set interval for 'loaded_scripts' (filter 'default') to '3600.000000' > 1437813085.377826/1437813085.400927 [logging] Set interval for 'communication' (filter 'default') to '3600.000000' > 1437813089.408731/1437813089.409921 [logging] Set interval for 'reporter' (filter '') to '3600.000000' > 1437813089.410046/1437813089.411141 [logging] Set interval for 'weird' (filter '') to '3600.000000' > 1437813089.410046/1437813089.411314 [logging] Set interval for 'packet_filter' (filter '') to '3600.000000' > 1437813089.411802/1437813089.412948 [logging] Set interval for 'stats' (filter '') to '3600.000000' > 1437813089.444066/1437813089.445155 [logging] Set interval for 'files' (filter '') to '3600.000000' > 1437813089.453163/1437813089.454249 [logging] Set interval for 'software' (filter '') to '3600.000000' > 1437813089.472973/1437813089.474123 [logging] Set interval for 'dns' (filter '') to '3600.000000' > 1437813089.507522/1437813089.508617 [logging] Set default interval for '/var/opt/bro/logs-json/http-2015-07-25' (filter '') > 1437813089.508759/1437813089.509852 [logging] Set interval for 'http' (filter '') to '3600.000000' > 1437813089.523751/1437813089.524868 [logging] Set interval for 'x509' (filter '') to '3600.000000', > 1437813089.983185/1437813089.984342 [logging] Set interval for 'ssl' (filter '') to '3600.000000' > 1437813093.316215/1437813093.317350 [logging] Set interval for 'ftp' (filter '') to '3600.000000' > 1437813094.076354/1437813094.077442 [logging] Set interval for 'conn' (filter '') to '3600.000000' > 1437813094.077580/1437813094.078657 [logging] Set interval for '/var/opt/bro/logs-json/conn' (filter '') to '0.000000' > 1437813100.949465/1437813100.950567 [logging] Set interval for 'syslog' (filter '') to '3600.000000'{quote} > On the manager you can see, that for all worker-generated logs the filter is not known and that the interval for my HTTP-JSON log is set to the default value (Note: The instantiating filter is not known because it is not set in the call in SendAllWritersTo - see [https://github.com/bro/bro/blob/2b1cd66f17194a30b90490965cbdffdd71c18c09/src/logging/Manager.cc#L1174]). So why does it work on the worker? Its because the path of the filter is determined and set during the write: The first write triggers determining the path by the filter. Then the writer is created and path of writer and filter match. The writers on the manager seem to be created without a write and therefore the filter cannot be determined. > At first I tried to fix the issue by using the name of the filter but as seen in the debug output, the name is not set. I also thought about setting the interval using the WriterBackend::WriterInfo, which is passed to CreateWriter and has a field for the interval, but there is also the postprocessor set in the CreateWriter method. Unfortunately I don't understand how logging is distributed between manager and worker in detail, so I do not know how I can fix this issue. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:50:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:50:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1435) &read_expire does not work for embedded table In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1435: --------------------------- Priority: Low (was: Normal) > &read_expire does not work for embedded table > --------------------------------------------- > > Key: BIT-1435 > URL: https://bro-tracker.atlassian.net/browse/BIT-1435 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Liang Zhu > Priority: Low > Fix For: 2.5 > > > I have a script read_expire_test.bro containing: > {noformat} > type embedded_table: table[string] of string &read_expire=1sec; > global level2_table: table[string] of embedded_table; > global level1_table: table[string] of string &read_expire=1sec; > event bro_init() > { > level2_table["t1"] = table(); > level2_table["t1"]["t2"] = "t2"; > level1_table["t"] = "t"; > print "level2_table:"; > print level2_table; > print "level1_table:"; > print level1_table; > } > event bro_done() > { > print "----------------"; > print "level2_table:"; > print level2_table; > print "level1_table:"; > print level1_table; > } > {noformat} > If I run this script through some trace (just to delay some time and let timeout work), > for example, > {noformat} > bro --pseudo-realtime -C -r test.pcap read_expire_test.bro > {noformat} > the level1_table is cleaned up as expected. However, the embedded table in level2_table is not cleaned up. By running the script, bro does not give any error message or warning, so I assume &read_expire in the following statement > {noformat} > type embedded_table: table[string] of string &read_expire=1sec; > {noformat} > is supposed to work? -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:51:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:51:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1430) Cross compilation support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1430: --------------------------- Fix Version/s: 2.5 > Cross compilation support > ------------------------- > > Key: BIT-1430 > URL: https://bro-tracker.atlassian.net/browse/BIT-1430 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Seth Hall > Fix For: 2.5 > > > From an email Cody sent to the bro-dev list:: > {quote}Hi, > Would you guys consider making cross compile easier on your roadmap? > The platform I tried to have it running was OpenWRT, which has its own > problems such as the libresolv is a stub in the most popular C library > choice uClibc, that is causing some troubles. What I mean is, even > without these problems, any cross compile would fail because of of the > use of bicfl. > Apparently somebody had gone through the painful process 10 years ago: > http://mailman.icsi.berkeley.edu/pipermail/bro/2005-July/001318.html > This fella has created a set of patches of CMake files for 2.3.1-2: > http://inspirated.com/2015/06/08/release-bro-2-3-1-2-on-openwrt > Which is hosted on this github page: > https://github.com/krkhan/openwrt-bro/tree/master/bro/patches > The build he created would fail because old versions are not being > hosted on your site, but more importantly the patches are obsolete as > of 2.4. Those patches are not huge, it would be great if you guys > would consider making it easier. > Thanks, > Cody > {quote} -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:56:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 4 Sep 2015 13:56:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-874) Handling Modbus exception FC In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-874: -------------------------------- Labels: Modbus analyzer exception fc (was: , Modbus analyser, exception fc) > Handling Modbus exception FC > ---------------------------- > > Key: BIT-874 > URL: https://bro-tracker.atlassian.net/browse/BIT-874 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master > Reporter: dina > Labels: Modbus, analyzer, exception, fc > Fix For: 2.5 > > > event modbus_exception is a general exception and the 'fc' that is returned here is 'original_request_fc'+128. This means if I send a request with Fc=3 and something goes bad,I will get this exception with fc=131. I thought it would be useful to immediately subtract this value and show in the log exact Fc where the exception was triggered. A small function for this I put before in modbus/utils.bro (on my branch), but its not in the topic/robin/modbus-merge branch. > I suggest to implement this functionality. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:56:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 4 Sep 2015 13:56:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-875) Modbus REF parameter In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-875: -------------------------------- Labels: Modbus REF analyzer offset (was: Modbus REF analyser, offset) > Modbus REF parameter > -------------------- > > Key: BIT-875 > URL: https://bro-tracker.atlassian.net/browse/BIT-875 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master > Reporter: dina > Labels: Modbus, REF, analyzer, offset > Fix For: 2.5 > > > By Modbus specification, different FC implicitly use different parts of the PLC memory. Looking on the wire only, we do not see this. I think it would be useful to include this knowledge about where is the specific data from a packet supposed to be written in logs immediately. > For example, fc=3,6,16 work with PLC memory addresses that are >40000, fc=4 work with values 30000-40000. On the wire we only see the REF parameter which is typically 0-10000 (so its a 'local' offset), thus we do not see the memory offset there. This part is implemented in the client by adding different offsets to the REF value in each packet. (e.g., if fc=3,6,16 use offset 40000 so real_ref=40000+ref). I used these offsets to make logs in the .bro script in my branch. > This division of 10000 addresses is sth I see as a practice on forums and some unofficial manuals, but its not defined in the specification. I assume that, based on PLC capacity, there could be different kind of division between different parts of the memory map. > I suggest that we make a configuration file that defines the division of PLC memory space and which offsets do specific FCs use. As default, we can put this division which i see as common practice. In specific cases, users can change that config file to do proper remapping. > Seth, you can find a a bit more about this division (and exact offsets per each FC) here: http://www.simplymodbus.ca/faq.htm -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 11:58:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 13:58:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1274) Moving GeoIP Code to Plugin In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1274: --------------------------- Resolution: Won't Fix Status: Closed (was: Open) Thanks for working on the plugin! I think we're going to go in a slightly different direction by implementing the new GeoIP2 API in a plugin and deprecate support for the legacy API and databases. You can track the status of that in ticket BIT-1472. If you would like to take on any of that work, let us know and I'm sure that Daniel would turn that ticket over to you. :) > Moving GeoIP Code to Plugin > --------------------------- > > Key: BIT-1274 > URL: https://bro-tracker.atlassian.net/browse/BIT-1274 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: AK > Fix For: 2.5 > > Attachments: ak.patch > > > I've started moving the GeoIP code to a plugin. The branch of Bro I'm working from is here: https://github.com/anthonykasza/bro/tree/topic/akasza/geoplugin. > The source for the plugin is here: https://github.com/anthonykasza/Bro_GeoIP. > Any pointers would be appreciated. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 12:41:01 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 4 Sep 2015 14:41:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1468) old copy of logging documentation on website In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1468: ------------------------------- Summary: old copy of logging documentation on website (was: logging documentation incomplete) > old copy of logging documentation on website > -------------------------------------------- > > Key: BIT-1468 > URL: https://bro-tracker.atlassian.net/browse/BIT-1468 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.5 > > > https://www.bro.org/development/logging.html currently is incomplete; e.g. rotation is empty and the next section contains a sentence missing a link. > I am not even sure if we link that page from anywhere, and what its relationship to https://www.bro.org/sphinx-git/frameworks/logging.html is - but it is one of the top search results on google. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 12:45:01 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 4 Sep 2015 14:45:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1468) old copy of logging documentation on website In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21963#comment-21963 ] Daniel Thayer commented on BIT-1468: ------------------------------------ This was just an old copy of the one being maintained in the bro git repo. I couldn't find any links to this doc, so I just removed it. > old copy of logging documentation on website > -------------------------------------------- > > Key: BIT-1468 > URL: https://bro-tracker.atlassian.net/browse/BIT-1468 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.5 > > > https://www.bro.org/development/logging.html currently is incomplete; e.g. rotation is empty and the next section contains a sentence missing a link. > I am not even sure if we link that page from anywhere, and what its relationship to https://www.bro.org/sphinx-git/frameworks/logging.html is - but it is one of the top search results on google. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 12:45:01 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 4 Sep 2015 14:45:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1468) old copy of logging documentation on website In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1468: ------------------------------- Resolution: Fixed Status: Closed (was: Open) > old copy of logging documentation on website > -------------------------------------------- > > Key: BIT-1468 > URL: https://bro-tracker.atlassian.net/browse/BIT-1468 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Daniel Thayer > Fix For: 2.5 > > > https://www.bro.org/development/logging.html currently is incomplete; e.g. rotation is empty and the next section contains a sentence missing a link. > I am not even sure if we link that page from anywhere, and what its relationship to https://www.bro.org/sphinx-git/frameworks/logging.html is - but it is one of the top search results on google. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 12:50:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 4 Sep 2015 14:50:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1470) Implemented Functions in Notice Framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1470: ------------------------------- Status: Open (was: Merge Request) > Implemented Functions in Notice Framework > ----------------------------------------- > > Key: BIT-1470 > URL: https://bro-tracker.atlassian.net/browse/BIT-1470 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.3 > Reporter: Wendy Edwards > Assignee: Daniel Thayer > Attachments: main_mod.bro, notice_main.patch > > > I modified the main.bro file in the notice framework (see https://github.com/bro/bro/blob/master/scripts/base/frameworks/notice/main.bro) to implement the functions "notice_tags" and "execute_with_notice." The patch (notice_main.patch) and the modified file (main_mod.bro) are both attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 14:18:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 4 Sep 2015 16:18:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1470) Implemented Functions in Notice Framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21964#comment-21964 ] Daniel Thayer commented on BIT-1470: ------------------------------------ I created branch "topic/dnthayer/ticket1470" in the bro git repo. I also changed a few tag names so that they match the corresponding Notice::Info field name. > Implemented Functions in Notice Framework > ----------------------------------------- > > Key: BIT-1470 > URL: https://bro-tracker.atlassian.net/browse/BIT-1470 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.3 > Reporter: Wendy Edwards > Assignee: Daniel Thayer > Attachments: main_mod.bro, notice_main.patch > > > I modified the main.bro file in the notice framework (see https://github.com/bro/bro/blob/master/scripts/base/frameworks/notice/main.bro) to implement the functions "notice_tags" and "execute_with_notice." The patch (notice_main.patch) and the modified file (main_mod.bro) are both attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 14:36:00 2015 From: jira at bro-tracker.atlassian.net (Wendy Edwards (JIRA)) Date: Fri, 4 Sep 2015 16:36:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1473) system_env hanging In-Reply-To: References: Message-ID: Wendy Edwards created BIT-1473: ---------------------------------- Summary: system_env hanging Key: BIT-1473 URL: https://bro-tracker.atlassian.net/browse/BIT-1473 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3 Environment: Encountered on Linux/Security Onion VM running on VMWare Fusion Reporter: Wendy Edwards Attachments: exit.py, test.py, test_system_enva.bro, test_system_envb.bro Noticed that "system_env" hangs when executing commands involving printing text, and I needed to do a "" to halt it. I?m uploading two examples. The file test_system_enva.bro calls exit.py and exits on its own. The file test_system_envb.bro calls test.py and does not exit on its own. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 15:08:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 4 Sep 2015 17:08:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1473) system_env hanging In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1473: ------------------------------- Resolution: Works for Me Status: Closed (was: Open) The second example doesn't actually hang, it just looks like it hangs due to the print output. > system_env hanging > ------------------ > > Key: BIT-1473 > URL: https://bro-tracker.atlassian.net/browse/BIT-1473 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Encountered on Linux/Security Onion VM running on VMWare Fusion > Reporter: Wendy Edwards > Attachments: exit.py, test.py, test_system_enva.bro, test_system_envb.bro > > > Noticed that "system_env" hangs when executing commands involving printing text, and I needed to do a "" to halt it. I?m uploading two examples. The file test_system_enva.bro calls exit.py and exits on its own. The file test_system_envb.bro calls test.py and does not exit on its own. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 20:24:01 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 22:24:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-835) Porting Drop and Catch-n-release to 2.0 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-835: ----------------------------- Assignee: Aashish Sharma > Porting Drop and Catch-n-release to 2.0 > --------------------------------------- > > Key: BIT-835 > URL: https://bro-tracker.atlassian.net/browse/BIT-835 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Aashish Sharma > Assignee: Aashish Sharma > Fix For: 2.5 > > Attachments: drop.bro, drop-catch-n-release.patch, scan.bro, test-drop-connectivity, test-restore-connectivity > > > The following patch ports the drop.bro to bro-2.0+ (along with catch-n-release functionality) > [originally written for bro-1.5.3 and prior versions by Jim Mellander and Robin Sommer|policies] > Also attaching scan.bro (which is ported to 2.0) > scan.bro and drop.bro files need to go into policy/protocols/conn/ folder. > Also adding test-drop-connectivity and test-restore-connectivity scripts which should go into aux/broctl/bin/ > This patch and policies have been operational at LBNL for a few months now with bro-2.0. > (sorry haven't created my own branch to commit these) \\- please let me know if this need to be otherwise. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 20:24:01 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 4 Sep 2015 22:24:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-835) Porting Drop and Catch-n-release to 2.0 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21966#comment-21966 ] Seth Hall commented on BIT-835: ------------------------------- Assigned! > Porting Drop and Catch-n-release to 2.0 > --------------------------------------- > > Key: BIT-835 > URL: https://bro-tracker.atlassian.net/browse/BIT-835 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Aashish Sharma > Assignee: Aashish Sharma > Fix For: 2.5 > > Attachments: drop.bro, drop-catch-n-release.patch, scan.bro, test-drop-connectivity, test-restore-connectivity > > > The following patch ports the drop.bro to bro-2.0+ (along with catch-n-release functionality) > [originally written for bro-1.5.3 and prior versions by Jim Mellander and Robin Sommer|policies] > Also attaching scan.bro (which is ported to 2.0) > scan.bro and drop.bro files need to go into policy/protocols/conn/ folder. > Also adding test-drop-connectivity and test-restore-connectivity scripts which should go into aux/broctl/bin/ > This patch and policies have been operational at LBNL for a few months now with bro-2.0. > (sorry haven't created my own branch to commit these) \\- please let me know if this need to be otherwise. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Fri Sep 4 21:15:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 4 Sep 2015 23:15:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-835) Porting Drop and Catch-n-release to 2.0 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21967#comment-21967 ] Johanna Amann commented on BIT-835: ----------------------------------- Note that there already is a version of catch and release in the netcontrol branch - though possibly not as nice as this one. > Porting Drop and Catch-n-release to 2.0 > --------------------------------------- > > Key: BIT-835 > URL: https://bro-tracker.atlassian.net/browse/BIT-835 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Aashish Sharma > Assignee: Aashish Sharma > Fix For: 2.5 > > Attachments: drop.bro, drop-catch-n-release.patch, scan.bro, test-drop-connectivity, test-restore-connectivity > > > The following patch ports the drop.bro to bro-2.0+ (along with catch-n-release functionality) > [originally written for bro-1.5.3 and prior versions by Jim Mellander and Robin Sommer|policies] > Also attaching scan.bro (which is ported to 2.0) > scan.bro and drop.bro files need to go into policy/protocols/conn/ folder. > Also adding test-drop-connectivity and test-restore-connectivity scripts which should go into aux/broctl/bin/ > This patch and policies have been operational at LBNL for a few months now with bro-2.0. > (sorry haven't created my own branch to commit these) \\- please let me know if this need to be otherwise. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From noreply at bro.org Sat Sep 5 00:00:22 2015 From: noreply at bro.org (Merge Tracker) Date: Sat, 5 Sep 2015 00:00:22 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509050700.t8570M4M009955@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------------- ------------ ---------- ------------- ---------- ------------------------------------ BIT-1460 [1] BinPAC Michal Purzynski Robin Sommer 2015-09-04 - Normal DPD query too large on multicast DNS BIT-1336 [2] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------------- #6 [3] bro-plugins jswaro [4] 2015-08-24 Adding initial conversion of TCPRS to a plugin [5] [1] BIT-1460 https://bro-tracker.atlassian.net/browse/BIT-1460 [2] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [3] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [4] jswaro https://github.com/jswaro [5] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin From jira at bro-tracker.atlassian.net Sat Sep 5 06:37:00 2015 From: jira at bro-tracker.atlassian.net (Jimmy Jones (JIRA)) Date: Sat, 5 Sep 2015 08:37:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1444) Connection logging for ESP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21968#comment-21968 ] Jimmy Jones commented on BIT-1444: ---------------------------------- Thanks Seth. Wireshark sample captures wiki has a few - https://wiki.wireshark.org/SampleCaptures#IPsec_-_ESP_Payload_Decryption_and_Authentication_Checking_Examples > Connection logging for ESP > -------------------------- > > Key: BIT-1444 > URL: https://bro-tracker.atlassian.net/browse/BIT-1444 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Jimmy Jones > Assignee: Vlad Grigorescu > Priority: Low > > I'd like to be able to track ESP (IPSec) connections in conn.log. Although ESP is encrypted, the ability to track volumes and pattern of life etc would be beneficial when doing intrusion analysis. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Sat Sep 5 19:47:00 2015 From: jira at bro-tracker.atlassian.net (Vern Paxson (JIRA)) Date: Sat, 5 Sep 2015 21:47:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1411) SQL_Injection_Victim is a misleading name In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21969#comment-21969 ] Vern Paxson commented on BIT-1411: ---------------------------------- Boy I hope we're not past the where we can fix stuff like this. There needs to be some model of deprecating/obsoleting deficient elements of the environment. Ideally, we'd have mechanisms which can flag for users which parts of their setups have been deprecated and how to fix them. But in any case, let's not be ossified! > SQL_Injection_Victim is a misleading name > ----------------------------------------- > > Key: BIT-1411 > URL: https://bro-tracker.atlassian.net/browse/BIT-1411 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vern Paxson > > I suggest changing the name of this notice to {{SQL_Injection_Target}}. Having "victim" in the name implies to me that the attack succeeded, which is not what the associated logic is about. > Indeed, I even wonder if this notice is useful. The information should be directly available from {{SQL_Injection_Attacker}} notices (though it doesn't appear to be currently set up to provide this - why not?). -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Sat Sep 5 20:34:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Sat, 5 Sep 2015 22:34:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21970#comment-21970 ] Johanna Amann commented on BIT-1460: ------------------------------------ I think I concur. I will merge this into master with the limit at 25 and into 2.4.1 with the limit at 5 (so the only difference is that people in 2.4.1 will be able to redef it if they want to - but there will be no surprising change of how things work). > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Johanna Amann > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Sat Sep 5 20:34:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Sat, 5 Sep 2015 22:34:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann reassigned BIT-1460: ---------------------------------- Assignee: Johanna Amann (was: Robin Sommer) > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Johanna Amann > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From noreply at bro.org Sun Sep 6 00:00:26 2015 From: noreply at bro.org (Merge Tracker) Date: Sun, 6 Sep 2015 00:00:26 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509060700.t8670QP3015089@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------------- ------------- ---------- ------------- ---------- ------------------------------------ BIT-1460 [1] BinPAC Michal Purzynski Johanna Amann 2015-09-05 - Normal DPD query too large on multicast DNS BIT-1336 [2] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------------- #6 [3] bro-plugins jswaro [4] 2015-08-24 Adding initial conversion of TCPRS to a plugin [5] [1] BIT-1460 https://bro-tracker.atlassian.net/browse/BIT-1460 [2] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [3] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [4] jswaro https://github.com/jswaro [5] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin From jira at bro-tracker.atlassian.net Sun Sep 6 13:22:00 2015 From: jira at bro-tracker.atlassian.net (Matthias Vallentin (JIRA)) Date: Sun, 6 Sep 2015 15:22:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1411) SQL_Injection_Victim is a misleading name In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21971#comment-21971 ] Matthias Vallentin commented on BIT-1411: ----------------------------------------- {quote} There needs to be some model of deprecating/obsoleting deficient elements of the environment. {quote} How about adding a {{&deprecate}} attribute to such elements? Then we can inform users in one release cycle that the labeled functionality will cease to exist with the next release (or whatever deprecation policy we chose). > SQL_Injection_Victim is a misleading name > ----------------------------------------- > > Key: BIT-1411 > URL: https://bro-tracker.atlassian.net/browse/BIT-1411 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vern Paxson > > I suggest changing the name of this notice to {{SQL_Injection_Target}}. Having "victim" in the name implies to me that the attack succeeded, which is not what the associated logic is about. > Indeed, I even wonder if this notice is useful. The information should be directly available from {{SQL_Injection_Attacker}} notices (though it doesn't appear to be currently set up to provide this - why not?). -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Sun Sep 6 14:03:00 2015 From: jira at bro-tracker.atlassian.net (Vern Paxson (JIRA)) Date: Sun, 6 Sep 2015 16:03:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1411) SQL_Injection_Victim is a misleading name In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21972#comment-21972 ] Vern Paxson commented on BIT-1411: ---------------------------------- @Matthias: perhaps. That works for values/types that can have attributes associated with them, but not for things like language features. Maybe that's the common enough case that we should go this route. I'm thinking then the syntax might be something like &deprecate=expr, where evaluates to a string displayed at compile time (though perhaps only if a show-me-deprecation flag is used). The string could include information (or a link to a discussion) on how to migrate. > SQL_Injection_Victim is a misleading name > ----------------------------------------- > > Key: BIT-1411 > URL: https://bro-tracker.atlassian.net/browse/BIT-1411 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vern Paxson > > I suggest changing the name of this notice to {{SQL_Injection_Target}}. Having "victim" in the name implies to me that the attack succeeded, which is not what the associated logic is about. > Indeed, I even wonder if this notice is useful. The information should be directly available from {{SQL_Injection_Attacker}} notices (though it doesn't appear to be currently set up to provide this - why not?). -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Sun Sep 6 17:43:00 2015 From: jira at bro-tracker.atlassian.net (Matthias Vallentin (JIRA)) Date: Sun, 6 Sep 2015 19:43:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1474) Improve signaling of deprecated code In-Reply-To: References: Message-ID: Matthias Vallentin created BIT-1474: --------------------------------------- Summary: Improve signaling of deprecated code Key: BIT-1474 URL: https://bro-tracker.atlassian.net/browse/BIT-1474 Project: Bro Issue Tracker Issue Type: New Feature Components: Bro Affects Versions: git/master Reporter: Matthias Vallentin Based on discussion in BIT-1411, we need a better mechanism for deprecating code. In particular, Vern suggested the attribute {{&deprecate=expr}} syntax where {{expr}} would be an expression that evaluates at the point of use of the deprecated construct and would show the user a hint on how to migrate. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Sun Sep 6 17:46:00 2015 From: jira at bro-tracker.atlassian.net (Matthias Vallentin (JIRA)) Date: Sun, 6 Sep 2015 19:46:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1411) SQL_Injection_Victim is a misleading name In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21973#comment-21973 ] Matthias Vallentin commented on BIT-1411: ----------------------------------------- I like this syntax and the proposed semantics. I've created a new ticket (BIT-1474) to track the addition of deprecation functionality explicitly. > SQL_Injection_Victim is a misleading name > ----------------------------------------- > > Key: BIT-1411 > URL: https://bro-tracker.atlassian.net/browse/BIT-1411 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vern Paxson > > I suggest changing the name of this notice to {{SQL_Injection_Target}}. Having "victim" in the name implies to me that the attack succeeded, which is not what the associated logic is about. > Indeed, I even wonder if this notice is useful. The information should be directly available from {{SQL_Injection_Attacker}} notices (though it doesn't appear to be currently set up to provide this - why not?). -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From jira at bro-tracker.atlassian.net Sun Sep 6 17:52:00 2015 From: jira at bro-tracker.atlassian.net (Vern Paxson (JIRA)) Date: Sun, 6 Sep 2015 19:52:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1474) Improve signaling of deprecated code In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21974#comment-21974 ] Vern Paxson commented on BIT-1474: ---------------------------------- One thing to add is the need for some sort of option/context such that users can control when the message about the deprecated variable gets displayed. > Improve signaling of deprecated code > ------------------------------------ > > Key: BIT-1474 > URL: https://bro-tracker.atlassian.net/browse/BIT-1474 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Matthias Vallentin > Labels: language > > Based on discussion in BIT-1411, we need a better mechanism for deprecating code. In particular, Vern suggested the attribute {{&deprecate=expr}} syntax where {{expr}} would be an expression that evaluates at the point of use of the deprecated construct and would show the user a hint on how to migrate. -- This message was sent by Atlassian JIRA (v7.0.0-OD-02-259#70102) From noreply at bro.org Mon Sep 7 00:00:18 2015 From: noreply at bro.org (Merge Tracker) Date: Mon, 7 Sep 2015 00:00:18 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509070700.t8770I7f001282@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------------- ------------- ---------- ------------- ---------- ------------------------------------ BIT-1460 [1] BinPAC Michal Purzynski Johanna Amann 2015-09-05 - Normal DPD query too large on multicast DNS BIT-1336 [2] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------------- #6 [3] bro-plugins jswaro [4] 2015-08-24 Adding initial conversion of TCPRS to a plugin [5] [1] BIT-1460 https://bro-tracker.atlassian.net/browse/BIT-1460 [2] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [3] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [4] jswaro https://github.com/jswaro [5] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin From noreply at bro.org Tue Sep 8 00:00:22 2015 From: noreply at bro.org (Merge Tracker) Date: Tue, 8 Sep 2015 00:00:22 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509080700.t8870MOH005328@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------------- ------------- ---------- ------------- ---------- ------------------------------------ BIT-1460 [1] BinPAC Michal Purzynski Johanna Amann 2015-09-05 - Normal DPD query too large on multicast DNS BIT-1336 [2] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------------- #6 [3] bro-plugins jswaro [4] 2015-08-24 Adding initial conversion of TCPRS to a plugin [5] [1] BIT-1460 https://bro-tracker.atlassian.net/browse/BIT-1460 [2] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [3] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [4] jswaro https://github.com/jswaro [5] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin From Breanna.S.Devore-McDonald.1 at nd.edu Tue Sep 8 00:07:24 2015 From: Breanna.S.Devore-McDonald.1 at nd.edu (Breanna Devore-McDonald) Date: Tue, 8 Sep 2015 03:07:24 -0400 Subject: [Bro-Dev] Greetings and Where To Start Message-ID: Hello, My name is Breanna and I am a junior Computer Science/ Cyber Security undergrad at the University of Notre Dame. I am currently in a Data Structures course which requires me to find an interesting open-source project to *hopefully* contribute to, using the knowledge I should gain throughout the semester in optimizing code using data structures. I am very interested in the Bro project and would love to find a way to contribute, however, I have no idea where to start. Do you think there's any place in the Bro code where I could help? (Or maybe, if it seems Bro is not the right fit for me, do you know of any projects that could fit?) Any help is greatly appreciated! -Breanna -- Breanna DeVore-McDonald University of Notre Dame '17 Computer Science bdevorem at nd.edu 530-276-4805 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20150908/aa855319/attachment.html From jira at bro-tracker.atlassian.net Tue Sep 8 07:09:01 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 8 Sep 2015 09:09:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1411) SQL_Injection_Victim is a misleading name In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22000#comment-22000 ] Jon Siwek commented on BIT-1411: -------------------------------- Didn't look at the particulars of this ticket, but just wanted to note that "&deprecated" should already exist in the 2.4 release in case it's helpful here. > SQL_Injection_Victim is a misleading name > ----------------------------------------- > > Key: BIT-1411 > URL: https://bro-tracker.atlassian.net/browse/BIT-1411 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vern Paxson > > I suggest changing the name of this notice to {{SQL_Injection_Target}}. Having "victim" in the name implies to me that the attack succeeded, which is not what the associated logic is about. > Indeed, I even wonder if this notice is useful. The information should be directly available from {{SQL_Injection_Attacker}} notices (though it doesn't appear to be currently set up to provide this - why not?). -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 07:14:00 2015 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 8 Sep 2015 09:14:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1474) Improve signaling of deprecated code In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22001#comment-22001 ] Jon Siwek commented on BIT-1474: -------------------------------- I had already done "&deprecated" (as part of 2.4 I believe). But don't think I allowed it to be assigned an expression which could contain more info or had a global flag to disable the warnings. (Just trying to provide input on what's already available, but both those ideas do seem like useful features to add). > Improve signaling of deprecated code > ------------------------------------ > > Key: BIT-1474 > URL: https://bro-tracker.atlassian.net/browse/BIT-1474 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Matthias Vallentin > Labels: language > > Based on discussion in BIT-1411, we need a better mechanism for deprecating code. In particular, Vern suggested the attribute {{&deprecate=expr}} syntax where {{expr}} would be an expression that evaluates at the point of use of the deprecated construct and would show the user a hint on how to migrate. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 10:33:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Tue, 8 Sep 2015 12:33:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22002#comment-22002 ] Seth Hall commented on BIT-1363: -------------------------------- Coming back around to this, I just discovered (after seeing multiple references to the contrary) that AF_Packet actually does per-flow balancing which means that this isn't a viable mechanism for Bro. My testing just showed each flow of a connection being balanced out to two separate Bro processes.  Does anyone know if there is something incomplete from the configuration that was merged into Bro? I can't find anything in AF_Packet docs that I've been reading that suggests otherwise. I think that this might not be a mechanism that we are able to use for load balancing since it's not bidirectional. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 12:38:00 2015 From: jira at bro-tracker.atlassian.net (Jan Grashoefer (JIRA)) Date: Tue, 8 Sep 2015 14:38:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22003#comment-22003 ] Jan Grashoefer commented on BIT-1363: ------------------------------------- Is PF_RING bidirectional? From what I can see, PCAP_PF_RING_USE_CLUSTER_PER_FLOW is set. This does not indicate any bidirectional handling. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 15:04:00 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Tue, 8 Sep 2015 17:04:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22004#comment-22004 ] Michal Purzynski commented on BIT-1363: --------------------------------------- How are you testing it? Question: would the conn_state = SF and history = ShADadfR if packets went two different processes, each direction? I think not, and I use currently a clustered AF_PACKET on a stage system (bro-master) and that's how my connections look like. Also, more "traditional' IDS like Suricata work really well with AF_PACKET clustering and yes, they are doing session reassembly - and each thread gets both directions. Have you enabled clustering, actually? > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 15:07:00 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Tue, 8 Sep 2015 17:07:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22005#comment-22005 ] Michal Purzynski commented on BIT-1363: --------------------------------------- ./networking/packet_mmap.txt - PACKET_FANOUT_HASH: schedule to socket by skb's packet hash (the only one that's symmetric) I've also tested it on netsniff-ng and similar and got both directions in a single process, each time. The code that got merged into Bro recently, about af_packet, lacks TPACKET_V3 support, but that's another thing (a huge performance optimization). > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 15:10:01 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Tue, 8 Sep 2015 17:10:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22006#comment-22006 ] Michal Purzynski commented on BIT-1363: --------------------------------------- Last part, just in case I've followed the kernel code. The function that calculates hash of incoming packet is wrapper into many others, but in the very end, this piece of code gets called. static inline u32 __flow_hash_from_keys(struct flow_keys *keys) { u32 hash; /* get a consistent hash (same value on both flow directions) */ if (((__force u32)keys->dst < (__force u32)keys->src) || (((__force u32)keys->dst == (__force u32)keys->src) && ((__force u16)keys->port16[1] < (__force u16)keys->port16[0]))) { swap(keys->dst, keys->src); swap(keys->port16[0], keys->port16[1]); } hash = __flow_hash_3words((__force u32)keys->dst, (__force u32)keys->src, (__force u32)keys->ports); if (!hash) hash = 1; return hash; } > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 15:11:00 2015 From: jira at bro-tracker.atlassian.net (Jan Grashoefer (JIRA)) Date: Tue, 8 Sep 2015 17:11:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22007#comment-22007 ] Jan Grashoefer commented on BIT-1363: ------------------------------------- See e.g. for Kernel 3.14: [https://github.com/torvalds/linux/blob/v3.14/net/core/flow_dissector.c#L221] You?scared?the?crap?out?of?me, Seth :D > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 15:16:00 2015 From: jira at bro-tracker.atlassian.net (Aaron (JIRA)) Date: Tue, 8 Sep 2015 17:16:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1475) Exec::Run does not complete In-Reply-To: References: Message-ID: Aaron created BIT-1475: -------------------------- Summary: Exec::Run does not complete Key: BIT-1475 URL: https://bro-tracker.atlassian.net/browse/BIT-1475 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3 Environment: Centos 6.6 Reporter: Aaron I'm having trouble running an external program in the callback function for an event when processing a pcap file. It seems to work in bro_init, however, which confuses me. The working file will print out the output of the "ls" command, whereas the not-working file will not print out anything no matter how long I wait. Specifically here I want to use the event when bro detects a file in the pcap. working.bro (ran as simply "bro working.bro"): {code:java} @load base/utils/exec redef exit_only_after_terminate=T; event bro_init() { local t= "ls /"; local cmd = Exec::Command($cmd=t); when (local res = Exec::run(cmd)) { print "hello"; print res$stdout; } } {code} notworking.bro (ran as bro -r my.pcap notworking.bro: {code:java} @load base/utils/exec @load base/frameworks/files @load base/frameworks/notice redef exit_only_after_terminate=T; event file_new(f: fa_file) { local t ="ls /"; local cmd = Exec::Command($cmd=t); when (local res = Exec::run(cmd)) { print "hello"; print res$stdout; } } {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 18:24:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Tue, 8 Sep 2015 20:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22008#comment-22008 ] Seth Hall commented on BIT-1363: -------------------------------- Arg! I should have mentioned that I was working with kernel 3.10! Thanks guys. It's nice to have a definitive answer to that. I read all over the place today and couldn't find a coherent answer to that question. Now we're going to have other people randomly searching google for an answer to this question and getting directed to this ticket. :) To reply to Michal's comment about TPACKET_V3, it looks like according to the libpcap changelog that TPACKET_V3 support was added to libpcap 1.5.0 (http://www.tcpdump.org/libpcap-changes.txt) so if you're running a more recent version than that you should already be using that. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 18:29:00 2015 From: jira at bro-tracker.atlassian.net (Matthias Vallentin (JIRA)) Date: Tue, 8 Sep 2015 20:29:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1474) Improve signaling of deprecated code In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22009#comment-22009 ] Matthias Vallentin commented on BIT-1474: ----------------------------------------- Ah, I missed that. That's definitely something we can work with. Let's keep this ticket open for now to track the enhancement with evaluated expressions. > Improve signaling of deprecated code > ------------------------------------ > > Key: BIT-1474 > URL: https://bro-tracker.atlassian.net/browse/BIT-1474 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Matthias Vallentin > Labels: language > > Based on discussion in BIT-1411, we need a better mechanism for deprecating code. In particular, Vern suggested the attribute {{&deprecate=expr}} syntax where {{expr}} would be an expression that evaluates at the point of use of the deprecated construct and would show the user a hint on how to migrate. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 18:29:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Tue, 8 Sep 2015 20:29:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1411) SQL_Injection_Victim is a misleading name In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22010#comment-22010 ] Seth Hall commented on BIT-1411: -------------------------------- I forgot to reply to the other half of Vern's original comment. The intent for this detection being split into two like it is, is to enable some fancier detection and mitigations. By splitting the detection in two we can actually detect a host being attacked even if every single attack is coming from a different IP address and generally knowing who the attacker is in that case is difficult. Eventually the plan is to enable reactions to attacks by denying service quickly to external hosts with a greatly reduced threshold because presumably the host would only begin to be protected once it's under an ongoing attack. > SQL_Injection_Victim is a misleading name > ----------------------------------------- > > Key: BIT-1411 > URL: https://bro-tracker.atlassian.net/browse/BIT-1411 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vern Paxson > > I suggest changing the name of this notice to {{SQL_Injection_Target}}. Having "victim" in the name implies to me that the attack succeeded, which is not what the associated logic is about. > Indeed, I even wonder if this notice is useful. The information should be directly available from {{SQL_Injection_Attacker}} notices (though it doesn't appear to be currently set up to provide this - why not?). -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 18:32:00 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Tue, 8 Sep 2015 20:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1444) Connection logging for ESP In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22011#comment-22011 ] Seth Hall commented on BIT-1444: -------------------------------- Great, thanks! We didn't assign a "fix version" to this ticket because we don't know when someone will be able to take it on, but we are interested in improving how we handle unknown traffic. > Connection logging for ESP > -------------------------- > > Key: BIT-1444 > URL: https://bro-tracker.atlassian.net/browse/BIT-1444 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Reporter: Jimmy Jones > Assignee: Vlad Grigorescu > Priority: Low > > I'd like to be able to track ESP (IPSec) connections in conn.log. Although ESP is encrypted, the ability to track volumes and pattern of life etc would be beneficial when doing intrusion analysis. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 21:06:00 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Tue, 8 Sep 2015 23:06:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22012#comment-22012 ] Michal Purzynski commented on BIT-1363: --------------------------------------- I'm trying to understand now how Bro uses the libpcap and I'm reading the libpcap source at the same time. PcapSource::OpenLive() calls pcap_create() and pcap_activate() later, which in turn, inside libpcap calls pcap_activate_linux() that tries hard to use mmap() and TPACKET_V3. Cool :-) A lot of magic happens after but libpcap is really good in autodetection - granted that you use it like designed, and not pick and choose functions. So we are good here. A documentation piece would be nice, that would recommend kernel at least 3.13 and libpcap 1.6 (or even 1.5). Maybe it will work on RHEL 7 stone-age-old 3.10. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Tue Sep 8 21:40:01 2015 From: jira at bro-tracker.atlassian.net (Vern Paxson (JIRA)) Date: Tue, 8 Sep 2015 23:40:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1411) SQL_Injection_Victim is a misleading name In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22013#comment-22013 ] Vern Paxson commented on BIT-1411: ---------------------------------- I fully agree with the rationale behind splitting it - just want the name to not imply that the attack has been successful. So changing Victim to Target should do the trick. (Also, FWIW, our paper on detecting distributed SSH bruteforcing [http://www.icir.org/vern/papers/dist-ssh-det.ccs13.pdf] might be useful fodder for thinking about the general problem of detecting attacks distributed across a bunch of sources.) > SQL_Injection_Victim is a misleading name > ----------------------------------------- > > Key: BIT-1411 > URL: https://bro-tracker.atlassian.net/browse/BIT-1411 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vern Paxson > > I suggest changing the name of this notice to {{SQL_Injection_Target}}. Having "victim" in the name implies to me that the attack succeeded, which is not what the associated logic is about. > Indeed, I even wonder if this notice is useful. The information should be directly available from {{SQL_Injection_Attacker}} notices (though it doesn't appear to be currently set up to provide this - why not?). -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From noreply at bro.org Wed Sep 9 00:00:23 2015 From: noreply at bro.org (Merge Tracker) Date: Wed, 9 Sep 2015 00:00:23 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509090700.t8970NKK017927@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------------- ------------- ---------- ------------- ---------- ------------------------------------ BIT-1460 [1] BinPAC Michal Purzynski Johanna Amann 2015-09-05 - Normal DPD query too large on multicast DNS BIT-1336 [2] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------------- #6 [3] bro-plugins jswaro [4] 2015-08-24 Adding initial conversion of TCPRS to a plugin [5] [1] BIT-1460 https://bro-tracker.atlassian.net/browse/BIT-1460 [2] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [3] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [4] jswaro https://github.com/jswaro [5] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin From jira at bro-tracker.atlassian.net Wed Sep 9 13:07:00 2015 From: jira at bro-tracker.atlassian.net (Jon Schipp (JIRA)) Date: Wed, 9 Sep 2015 15:07:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1012) RIP Analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Schipp reassigned BIT-1012: ------------------------------- Assignee: Jon Schipp > RIP Analyzer > ------------ > > Key: BIT-1012 > URL: https://bro-tracker.atlassian.net/browse/BIT-1012 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: git/master > Reporter: nicolas > Assignee: Jon Schipp > Priority: Low > Fix For: 2.5 > > Attachments: 0001-RIP-analyzer.patch > > > I wrote some code lignes to see how binpac works, it is an RIPv2 Analyzer. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Wed Sep 9 19:37:00 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Wed, 9 Sep 2015 21:37:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22014#comment-22014 ] Michal Purzynski commented on BIT-1363: --------------------------------------- And I have just tested kernel 3.16 with Bro from git and a configuration like this /opt/bro/etc/local-eth0.bro redef Pcap::bufsize = 256; redef Pcap::packet_fanout_enable = T; redef Pcap::packet_fanout_id = 9001; redef Pcap::packet_fanout_defrag = T; [nsm-stage1-manager] type=manager host=localhost [nsm-stage1-proxy1] type=proxy host=localhost [nsm-stage1-proxy2] type=proxy host=localhost [opsecnatprod1-eth0-0] type=worker host=localhost interface=eth0 aux_scripts=/opt/bro/etc/local-eth0.bro [opsecnatprod1-eth0-1] type=worker host=localhost interface=eth0 aux_scripts=/opt/bro/etc/local-eth0.bro [opsecnatprod1-eth0-2] type=worker host=localhost interface=eth0 aux_scripts=/opt/bro/etc/local-eth0.bro [opsecnatprod1-eth0-3] type=worker host=localhost interface=eth0 aux_scripts=/opt/bro/etc/local-eth0.bro And packets from the same connection are sent to different workers. WTH. eth0 is the interface that accepts and sends traffic out - it is a NAT instance in AWS if that matters. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From noreply at bro.org Thu Sep 10 00:00:22 2015 From: noreply at bro.org (Merge Tracker) Date: Thu, 10 Sep 2015 00:00:22 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509100700.t8A70MOs001851@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------------- ------------- ---------- ------------- ---------- ------------------------------------ BIT-1460 [1] BinPAC Michal Purzynski Johanna Amann 2015-09-05 - Normal DPD query too large on multicast DNS BIT-1336 [2] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------------- #6 [3] bro-plugins jswaro [4] 2015-08-24 Adding initial conversion of TCPRS to a plugin [5] [1] BIT-1460 https://bro-tracker.atlassian.net/browse/BIT-1460 [2] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [3] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [4] jswaro https://github.com/jswaro [5] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin From jira at bro-tracker.atlassian.net Thu Sep 10 07:00:00 2015 From: jira at bro-tracker.atlassian.net (Jan Grashoefer (JIRA)) Date: Thu, 10 Sep 2015 09:00:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22015#comment-22015 ] Jan Grashoefer commented on BIT-1363: ------------------------------------- I have never tried this on an active interface. I am using it on an interface in promiscuous mode. How do you determine that packets of a single connection have been sent do different workers? Can you reproduce this for an interface in PROMISC mode? > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Thu Sep 10 10:26:00 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Thu, 10 Sep 2015 12:26:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22016#comment-22016 ] Michal Purzynski commented on BIT-1363: --------------------------------------- I've just put the interface in promisc mode and made sure all offloading options are disabled. Same result. Connections get spread among two different processes, if sniffing on the NAT instance. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Thu Sep 10 10:44:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Thu, 10 Sep 2015 12:44:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22017#comment-22017 ] Johanna Amann commented on BIT-1460: ------------------------------------ Merging this change actually triggers a few changes in our external test suite. Vlad, could you potentially take a short look if those seem to make sense? > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Johanna Amann > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Thu Sep 10 11:54:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Thu, 10 Sep 2015 13:54:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu reassigned BIT-1460: ------------------------------------ Assignee: Vlad Grigorescu (was: Johanna Amann) > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Vlad Grigorescu > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Thu Sep 10 11:54:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Thu, 10 Sep 2015 13:54:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1460: --------------------------------- Status: Open (was: Merge Request) > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Johanna Amann > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Thu Sep 10 11:55:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Thu, 10 Sep 2015 13:55:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22018#comment-22018 ] Vlad Grigorescu commented on BIT-1460: -------------------------------------- Will do. Sorry for not checking that earlier. > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Vlad Grigorescu > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Thu Sep 10 13:00:01 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Thu, 10 Sep 2015 15:00:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22019#comment-22019 ] Vlad Grigorescu commented on BIT-1460: -------------------------------------- Yes, these all seem reasonable. Several symptoms of this particular bug were fixed. > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Vlad Grigorescu > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Thu Sep 10 13:02:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Thu, 10 Sep 2015 15:02:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22019#comment-22019 ] Vlad Grigorescu edited comment on BIT-1460 at 9/10/15 3:01 PM: --------------------------------------------------------------- Yes, these all seem reasonable. Several symptoms of this particular bug were fixed. I updated the appropriate baselines in topic/vladg/bit-1460 in the bro-testing repo. Several tests unrelated to DNS seem to be broken, but I believe that's due to BIT-1467. Also, the private test suite seems to be out of date with master, but I didn't see any DNS-related changes. was (Author: grigorescu): Yes, these all seem reasonable. Several symptoms of this particular bug were fixed. > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Vlad Grigorescu > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Thu Sep 10 13:02:00 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Thu, 10 Sep 2015 15:02:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu updated BIT-1460: --------------------------------- Status: Merge Request (was: Open) Assignee: (was: Vlad Grigorescu) > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From noreply at bro.org Fri Sep 11 00:00:19 2015 From: noreply at bro.org (Merge Tracker) Date: Fri, 11 Sep 2015 00:00:19 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509110700.t8B70Jxb017077@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------------- ---------- ---------- ------------- ---------- ------------------------------------ BIT-1460 [1] BinPAC Michal Purzynski - 2015-09-10 - Normal DPD query too large on multicast DNS BIT-1336 [2] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- c8b7a8e [3] binpac Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 20ac0c5 [4] bro Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 24ecb35 [5] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- --------------------------------------------------------------------------- #44 [6] bro yunzheng [7] 2015-09-10 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [8] #6 [9] bro-plugins jswaro [10] 2015-08-24 Adding initial conversion of TCPRS to a plugin [11] [1] BIT-1460 https://bro-tracker.atlassian.net/browse/BIT-1460 [2] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [3] c8b7a8e https://github.com/bro/binpac/commit/c8b7a8ec3f8333cf4049a6ee995228cd39d973ae [4] 20ac0c5 https://github.com/bro/bro/commit/20ac0c5aeb8be78df37ac6723c3fd59df09dd373 [5] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [6] Pull Request #44 https://github.com/bro/bro/pull/44 [7] yunzheng https://github.com/yunzheng [8] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [9] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [10] jswaro https://github.com/jswaro [11] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin From jira at bro-tracker.atlassian.net Fri Sep 11 11:02:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 11 Sep 2015 13:02:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann reassigned BIT-1460: ---------------------------------- Assignee: Johanna Amann > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Johanna Amann > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Fri Sep 11 12:10:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 11 Sep 2015 14:10:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1460: ------------------------------- Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > DPD query too large on multicast DNS > ------------------------------------ > > Key: BIT-1460 > URL: https://bro-tracker.atlassian.net/browse/BIT-1460 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 2.4 > Reporter: Michal Purzynski > Assignee: Johanna Amann > Labels: analyzer > Attachments: dnsm.pcap > > > Lots of > 1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > 1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 224.0.0.251 5353 udp DNS DNS_Conn_count_too_large > 1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large > for just UDP and port 5353 - multicast DNS > Pcaps attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Fri Sep 11 16:23:01 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 11 Sep 2015 18:23:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1475) Exec::Run does not complete In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22023#comment-22023 ] Johanna Amann commented on BIT-1475: ------------------------------------ Just to check -- which exact version of Bro are you trying this with? And - would it perhaps be possible to upload the test pcap you are trying this with? I just tried to reproduce this with the current master version of Bro, and on a quick glance there it seems to work fine. > Exec::Run does not complete > --------------------------- > > Key: BIT-1475 > URL: https://bro-tracker.atlassian.net/browse/BIT-1475 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Centos 6.6 > Reporter: Aaron > Labels: hang > > I'm having trouble running an external program in the callback function for an event when processing a pcap file. It seems to work in bro_init, however, which confuses me. > The working file will print out the output of the "ls" command, whereas the not-working file will not print out anything no matter how long I wait. > Specifically here I want to use the event when bro detects a file in the pcap. > working.bro (ran as simply "bro working.bro"): > {code:java} > @load base/utils/exec > redef exit_only_after_terminate=T; > event bro_init() > { > local t= "ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} > notworking.bro (ran as bro -r my.pcap notworking.bro: > {code:java} > @load base/utils/exec > @load base/frameworks/files > @load base/frameworks/notice > redef exit_only_after_terminate=T; > event file_new(f: fa_file) > { > local t ="ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Fri Sep 11 16:24:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 11 Sep 2015 18:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1470) Implemented Functions in Notice Framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22024#comment-22024 ] Johanna Amann commented on BIT-1470: ------------------------------------ Do you think that is ready to be merged, or do you want to make more changes? > Implemented Functions in Notice Framework > ----------------------------------------- > > Key: BIT-1470 > URL: https://bro-tracker.atlassian.net/browse/BIT-1470 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.3 > Reporter: Wendy Edwards > Assignee: Daniel Thayer > Attachments: main_mod.bro, notice_main.patch > > > I modified the main.bro file in the notice framework (see https://github.com/bro/bro/blob/master/scripts/base/frameworks/notice/main.bro) to implement the functions "notice_tags" and "execute_with_notice." The patch (notice_main.patch) and the modified file (main_mod.bro) are both attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Fri Sep 11 17:08:00 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Fri, 11 Sep 2015 19:08:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22025#comment-22025 ] Michal Purzynski commented on BIT-1363: --------------------------------------- Building Bro against libpcap 1.7.4 didn't help. Interface is in the promisc mode, offloading functions disabled. The underlying device is a xen net frontend, not that it should matter. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Fri Sep 11 17:29:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 11 Sep 2015 19:29:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1470) Implemented Functions in Notice Framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1470: ------------------------------- Priority: Low (was: Normal) Fix Version/s: 2.5 > Implemented Functions in Notice Framework > ----------------------------------------- > > Key: BIT-1470 > URL: https://bro-tracker.atlassian.net/browse/BIT-1470 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.3 > Reporter: Wendy Edwards > Assignee: Daniel Thayer > Priority: Low > Fix For: 2.5 > > Attachments: main_mod.bro, notice_main.patch > > > I modified the main.bro file in the notice framework (see https://github.com/bro/bro/blob/master/scripts/base/frameworks/notice/main.bro) to implement the functions "notice_tags" and "execute_with_notice." The patch (notice_main.patch) and the modified file (main_mod.bro) are both attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Fri Sep 11 17:30:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 11 Sep 2015 19:30:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1470) Implemented Functions in Notice Framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22026#comment-22026 ] Daniel Thayer commented on BIT-1470: ------------------------------------ I'm not planning to make any more changes. You can merge it if you have time (it's not urgent). > Implemented Functions in Notice Framework > ----------------------------------------- > > Key: BIT-1470 > URL: https://bro-tracker.atlassian.net/browse/BIT-1470 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.3 > Reporter: Wendy Edwards > Assignee: Daniel Thayer > Priority: Low > Fix For: 2.5 > > Attachments: main_mod.bro, notice_main.patch > > > I modified the main.bro file in the notice framework (see https://github.com/bro/bro/blob/master/scripts/base/frameworks/notice/main.bro) to implement the functions "notice_tags" and "execute_with_notice." The patch (notice_main.patch) and the modified file (main_mod.bro) are both attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Fri Sep 11 17:30:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 11 Sep 2015 19:30:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1470) Implemented Functions in Notice Framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1470: ------------------------------- Status: Merge Request (was: Open) Assignee: (was: Daniel Thayer) > Implemented Functions in Notice Framework > ----------------------------------------- > > Key: BIT-1470 > URL: https://bro-tracker.atlassian.net/browse/BIT-1470 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.3 > Reporter: Wendy Edwards > Priority: Low > Fix For: 2.5 > > Attachments: main_mod.bro, notice_main.patch > > > I modified the main.bro file in the notice framework (see https://github.com/bro/bro/blob/master/scripts/base/frameworks/notice/main.bro) to implement the functions "notice_tags" and "execute_with_notice." The patch (notice_main.patch) and the modified file (main_mod.bro) are both attached. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Fri Sep 11 17:41:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Fri, 11 Sep 2015 19:41:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1200) CloneSerializer cannot handle recursive records In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22027#comment-22027 ] Johanna Amann commented on BIT-1200: ------------------------------------ Do we just want to close this because it will not be possible with broker in any case and recursive records are not well supported in Bro generally? > CloneSerializer cannot handle recursive records > ----------------------------------------------- > > Key: BIT-1200 > URL: https://bro-tracker.atlassian.net/browse/BIT-1200 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Vlad Grigorescu > > Running something like this will result in an infinite loop in the serializer: > {code} > type conn_with_ts: record { > c: connection; > ts: time; > }; > redef record connection += { > conn_with_ts: conn_with_ts &optional; > }; > event connection_established(c: connection) { > local oops = copy(c); > } > {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From noreply at bro.org Sat Sep 12 00:00:21 2015 From: noreply at bro.org (Merge Tracker) Date: Sat, 12 Sep 2015 00:00:21 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509120700.t8C70LVJ003965@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ----------------------------------------- BIT-1470 [1] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [2] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [3] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- --------------------------------------------------------------------------- #44 [4] bro yunzheng [5] 2015-09-11 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [6] #6 [7] bro-plugins jswaro [8] 2015-08-24 Adding initial conversion of TCPRS to a plugin [9] #1 [10] broctl J-Gras [11] 2015-09-11 Added support for packet fanout load balancing [12] [1] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [2] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [3] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [4] Pull Request #44 https://github.com/bro/bro/pull/44 [5] yunzheng https://github.com/yunzheng [6] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [7] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [8] jswaro https://github.com/jswaro [9] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [10] Pull Request #1 https://github.com/bro/broctl/pull/1 [11] J-Gras https://github.com/J-Gras [12] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config From noreply at bro.org Sun Sep 13 00:00:17 2015 From: noreply at bro.org (Merge Tracker) Date: Sun, 13 Sep 2015 00:00:17 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509130700.t8D70HPh004302@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ----------------------------------------- BIT-1470 [1] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [2] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [3] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- --------------------------------------------------------------------------- #44 [4] bro yunzheng [5] 2015-09-11 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [6] #6 [7] bro-plugins jswaro [8] 2015-08-24 Adding initial conversion of TCPRS to a plugin [9] #1 [10] broctl J-Gras [11] 2015-09-11 Added support for packet fanout load balancing [12] [1] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [2] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [3] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [4] Pull Request #44 https://github.com/bro/bro/pull/44 [5] yunzheng https://github.com/yunzheng [6] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [7] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [8] jswaro https://github.com/jswaro [9] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [10] Pull Request #1 https://github.com/bro/broctl/pull/1 [11] J-Gras https://github.com/J-Gras [12] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config From jira at bro-tracker.atlassian.net Sun Sep 13 08:52:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Sun, 13 Sep 2015 10:52:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1476) btest-diff can generate too much output when a test fails In-Reply-To: References: Message-ID: Daniel Thayer created BIT-1476: ---------------------------------- Summary: btest-diff can generate too much output when a test fails Key: BIT-1476 URL: https://bro-tracker.atlassian.net/browse/BIT-1476 Project: Bro Issue Tracker Issue Type: Improvement Components: BTest Reporter: Daniel Thayer When btest-diff fails for a test, it shows the file and then the diff of the file vs. the baseline. For small output sizes, this can be very useful, but it doesn't seem useful when one must scroll through hundreds (or thousands) of lines of output just to find where the diff begins. There is a MAX_LINES parameter in btest-diff to truncate the output of huge files, but it cannot be customized and the default value is 5000, which seems really excessive. There is also a TEST_DIFF_BRIEF option to prevent showing any file contents, but this is not desirable to use for tests with small baselines, and having to set it for each test with a large baseline seems like too much of a maintenance burden. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Sun Sep 13 10:27:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Sun, 13 Sep 2015 12:27:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1476) btest-diff can generate too much output when a test fails In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22028#comment-22028 ] Daniel Thayer commented on BIT-1476: ------------------------------------ In branch "topic/dnthayer/max-lines" in the btest git repo, I've changed the value of MAX_LINES to a smaller value, added ability for a user to override this value by setting the TEST_DIFF_FILE_MAX_LINES env. variable, and changed btest-diff to always show the entire file when no baseline exists. > btest-diff can generate too much output when a test fails > --------------------------------------------------------- > > Key: BIT-1476 > URL: https://bro-tracker.atlassian.net/browse/BIT-1476 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BTest > Reporter: Daniel Thayer > > When btest-diff fails for a test, it shows the file and then the diff of > the file vs. the baseline. For small output sizes, this can be very useful, but it > doesn't seem useful when one must scroll through hundreds (or thousands) of > lines of output just to find where the diff begins. There is a MAX_LINES parameter > in btest-diff to truncate the output of huge files, but it cannot be customized and > the default value is 5000, which seems really excessive. There is also a > TEST_DIFF_BRIEF option to prevent showing any file contents, but this is > not desirable to use for tests with small baselines, and having to set it for each > test with a large baseline seems like too much of a maintenance burden. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From jira at bro-tracker.atlassian.net Sun Sep 13 10:28:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Sun, 13 Sep 2015 12:28:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1476) btest-diff can generate too much output when a test fails In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1476: ------------------------------- Status: Merge Request (was: Open) > btest-diff can generate too much output when a test fails > --------------------------------------------------------- > > Key: BIT-1476 > URL: https://bro-tracker.atlassian.net/browse/BIT-1476 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BTest > Reporter: Daniel Thayer > > When btest-diff fails for a test, it shows the file and then the diff of > the file vs. the baseline. For small output sizes, this can be very useful, but it > doesn't seem useful when one must scroll through hundreds (or thousands) of > lines of output just to find where the diff begins. There is a MAX_LINES parameter > in btest-diff to truncate the output of huge files, but it cannot be customized and > the default value is 5000, which seems really excessive. There is also a > TEST_DIFF_BRIEF option to prevent showing any file contents, but this is > not desirable to use for tests with small baselines, and having to set it for each > test with a large baseline seems like too much of a maintenance burden. -- This message was sent by Atlassian JIRA (v7.0.0-OD-04-018#70102) From noreply at bro.org Mon Sep 14 00:00:24 2015 From: noreply at bro.org (Merge Tracker) Date: Mon, 14 Sep 2015 00:00:24 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509140700.t8E70OsD016530@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- --------------------------------------------------------- BIT-1476 [1] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [2] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [3] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [4] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- --------------------------------------------------------------------------- #44 [5] bro yunzheng [6] 2015-09-11 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [7] #6 [8] bro-plugins jswaro [9] 2015-08-24 Adding initial conversion of TCPRS to a plugin [10] #1 [11] broctl J-Gras [12] 2015-09-11 Added support for packet fanout load balancing [13] [1] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [2] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [3] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [4] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [5] Pull Request #44 https://github.com/bro/bro/pull/44 [6] yunzheng https://github.com/yunzheng [7] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [8] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [9] jswaro https://github.com/jswaro [10] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [11] Pull Request #1 https://github.com/bro/broctl/pull/1 [12] J-Gras https://github.com/J-Gras [13] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config From jira at bro-tracker.atlassian.net Mon Sep 14 03:57:00 2015 From: jira at bro-tracker.atlassian.net (Lu Goon (JIRA)) Date: Mon, 14 Sep 2015 05:57:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1477) Compile Bro IDS on Raspberry Pi 2 In-Reply-To: References: Message-ID: Lu Goon created BIT-1477: ---------------------------- Summary: Compile Bro IDS on Raspberry Pi 2 Key: BIT-1477 URL: https://bro-tracker.atlassian.net/browse/BIT-1477 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3, 2.4 Environment: Kali 2.0 for ARM HF and Ubuntu Mate for ARMHF Reporter: Lu Goon Trying to build BRO-IDS on raspberry PI 2 that is running either Kali Linux 2.0 ARM or Ubuntu Mate 15.04 ARM. When I get to the pthread library the CMake errors out looking for the -lpthreads library instead of the -lpthread library. Would like to know where can I edit the CMAKE file to account for pthread instead of pthreads. See information below: *+PTHREAD is installed on RPi2:+* root at kali:3.0.2# /sbin/ldconfig -p | grep pthread libpthread.so.0 (libc6,hard-float, OS ABI: Linux 2.6.32) => /lib/arm-linux-gnueabihf/libpthread.so.0 libevent_pthreads-2.0.so.5 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libevent_pthreads-2.0.so.5 root at kali:3.0.2# *+ERROR MESSAGE FROM CMAKE:+* Run Build Command:"/usr/bin/make" "cmTryCompileExec67693562/fast" /usr/bin/make -f CMakeFiles/cmTryCompileExec67693562.dir/build.make CMakeFiles/cmTryCompileExec67693562.dir/build make[1]: Entering directory '/root/Projects/BRO-IDS/bro-2.3.2/build/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /root/Projects/BRO-IDS/bro-2.3.2/build/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec67693562.dir/CheckFunctionExists.c.o /usr/bin/cc -Wall -Wno-unused -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTryCompileExec67693562.dir/CheckFunctionExists.c.o -c /usr/share/cmake-3.0/Modules/CheckFunctionExists.c Linking C executable cmTryCompileExec67693562 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec67693562.dir/link.txt --verbose=1 /usr/bin/cc -Wall -Wno-unused -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTryCompileExec67693562.dir/CheckFunctionExists.c.o -o cmTryCompileExec67693562 -rdynamic -lpthreads /usr/bin/ld: cannot find -lpthreads collect2: error: ld returned 1 exit status CMakeFiles/cmTryCompileExec67693562.dir/build.make:88: recipe for target 'cmTryCompileExec67693562' failed make[1]: Leaving directory '/root/Projects/BRO-IDS/bro-2.3.2/build/CMakeFiles/CMakeTmp' make[1]: *** [cmTryCompileExec67693562] Error 1 Makefile:118: recipe for target 'cmTryCompileExec67693562/fast' failed make: *** [cmTryCompileExec67693562/fast] Error 2 -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Mon Sep 14 04:04:00 2015 From: jira at bro-tracker.atlassian.net (Lu Goon (JIRA)) Date: Mon, 14 Sep 2015 06:04:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1478) BPF Filter for local.bro per activated log file In-Reply-To: References: Message-ID: Lu Goon created BIT-1478: ---------------------------- Summary: BPF Filter for local.bro per activated log file Key: BIT-1478 URL: https://bro-tracker.atlassian.net/browse/BIT-1478 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3, 2.4 Environment: linux, mac osx, Reporter: Lu Goon when activating the x509.log or bro script in local.bro, can I configure a BPF filter to only affect x509? For example I only want to have events that the dust_host is our DMZ subnet. Can I configure that in the x509.bro file or some other bro configuration file? -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Mon Sep 14 07:03:01 2015 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Mon, 14 Sep 2015 09:03:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22100#comment-22100 ] Seth Hall commented on BIT-1363: -------------------------------- I meant to comment last week that I dug around in Linux about that comment you pointed to that mentioned making the hash symmetric was actually added a long time ago. I have another idea about what may be causing the apparent load balancing trouble that I need to test. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Mon Sep 14 14:37:00 2015 From: jira at bro-tracker.atlassian.net (Aaron (JIRA)) Date: Mon, 14 Sep 2015 16:37:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1475) Exec::Run does not complete In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron updated BIT-1475: ----------------------- Attachment: bro.tar.gz > Exec::Run does not complete > --------------------------- > > Key: BIT-1475 > URL: https://bro-tracker.atlassian.net/browse/BIT-1475 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Centos 6.6 > Reporter: Aaron > Labels: hang > Attachments: bro.tar.gz > > > I'm having trouble running an external program in the callback function for an event when processing a pcap file. It seems to work in bro_init, however, which confuses me. > The working file will print out the output of the "ls" command, whereas the not-working file will not print out anything no matter how long I wait. > Specifically here I want to use the event when bro detects a file in the pcap. > working.bro (ran as simply "bro working.bro"): > {code:java} > @load base/utils/exec > redef exit_only_after_terminate=T; > event bro_init() > { > local t= "ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} > notworking.bro (ran as bro -r my.pcap notworking.bro: > {code:java} > @load base/utils/exec > @load base/frameworks/files > @load base/frameworks/notice > redef exit_only_after_terminate=T; > event file_new(f: fa_file) > { > local t ="ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Mon Sep 14 14:43:00 2015 From: jira at bro-tracker.atlassian.net (Aaron (JIRA)) Date: Mon, 14 Sep 2015 16:43:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1475) Exec::Run does not complete In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22101#comment-22101 ] Aaron commented on BIT-1475: ---------------------------- Hi Johanna, you are right, I double checked my own example and it does work--apparently I had simplified it too much so that the behavior isn't observable anymore. The actual setup is a lot more specific. I'm actually invoking a python script. I've tried to narrow down where in the python things get locked up, but I could find no discernible pattern, in fact after I threw out enough code it went from "never prints the output" to "sometimes prints it and sometimes does not". I'm sending my bro script and the python code-- I apologize for not being able to find an absolute minimal example. [^bro.tar.gz] With this code, if you run "bro t1.bro" I would expect you to see my python output (the name of a file passed to it from bro). If you run "bro -r my.pcap t1.bro" I would expect you to never see any output related to the script. Included is the same pcap I'm using but I don't think the file itself has anything to do with the problem because, in this example, I'm not even looking at it, I'm just putting everything in bro_init. Is there some kind of timeout where if the process takes too long bro just forgets about it? The code is really not doing anything; perhaps all those nested python imports is taking too much time. Bro is version 2.3.1. > Exec::Run does not complete > --------------------------- > > Key: BIT-1475 > URL: https://bro-tracker.atlassian.net/browse/BIT-1475 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Centos 6.6 > Reporter: Aaron > Labels: hang > Attachments: bro.tar.gz > > > I'm having trouble running an external program in the callback function for an event when processing a pcap file. It seems to work in bro_init, however, which confuses me. > The working file will print out the output of the "ls" command, whereas the not-working file will not print out anything no matter how long I wait. > Specifically here I want to use the event when bro detects a file in the pcap. > working.bro (ran as simply "bro working.bro"): > {code:java} > @load base/utils/exec > redef exit_only_after_terminate=T; > event bro_init() > { > local t= "ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} > notworking.bro (ran as bro -r my.pcap notworking.bro: > {code:java} > @load base/utils/exec > @load base/frameworks/files > @load base/frameworks/notice > redef exit_only_after_terminate=T; > event file_new(f: fa_file) > { > local t ="ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Mon Sep 14 14:50:00 2015 From: jira at bro-tracker.atlassian.net (Aaron (JIRA)) Date: Mon, 14 Sep 2015 16:50:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1475) Exec::Run does not complete In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22101#comment-22101 ] Aaron edited comment on BIT-1475 at 9/14/15 4:49 PM: ----------------------------------------------------- Hi Johanna, you are right, I double checked my own example and it does work--apparently I had simplified it too much so that the behavior isn't observable anymore. The actual setup is a lot more specific. I'm actually invoking a python script. I've tried to narrow down where in the python things get locked up, but I could find no discernible pattern, in fact after I threw out enough code it went from "never prints the output" to "sometimes prints it and sometimes does not". I'm sending my bro script and the python code-- I apologize for not being able to find an absolute minimal example. [^bro.tar.gz] With this code, if you run "bro t1.bro" I would expect you to see my python output (the name of a file passed to it from bro). If you run "bro -r my.pcap t1.bro" I would expect you to never see any output related to the script. Included is the same pcap I'm using but I don't think the file itself has anything to do with the problem because, in this example, I'm not even looking at it, I'm just putting everything in bro_init. Is there some kind of timeout where if the process takes too long bro just forgets about it? The code is really not doing anything; perhaps all those nested python imports is taking too much time. Bro is version 2.3.1. Edit: sorry again, you will have to adjust the path to the python script mentioned in t1.bro as it is the full path. Just change the path to the dir in which you extract everything (it wants to run "check-macros.py" which must be in the same dir as all its libraries). was (Author: ajmills): Hi Johanna, you are right, I double checked my own example and it does work--apparently I had simplified it too much so that the behavior isn't observable anymore. The actual setup is a lot more specific. I'm actually invoking a python script. I've tried to narrow down where in the python things get locked up, but I could find no discernible pattern, in fact after I threw out enough code it went from "never prints the output" to "sometimes prints it and sometimes does not". I'm sending my bro script and the python code-- I apologize for not being able to find an absolute minimal example. [^bro.tar.gz] With this code, if you run "bro t1.bro" I would expect you to see my python output (the name of a file passed to it from bro). If you run "bro -r my.pcap t1.bro" I would expect you to never see any output related to the script. Included is the same pcap I'm using but I don't think the file itself has anything to do with the problem because, in this example, I'm not even looking at it, I'm just putting everything in bro_init. Is there some kind of timeout where if the process takes too long bro just forgets about it? The code is really not doing anything; perhaps all those nested python imports is taking too much time. Bro is version 2.3.1. > Exec::Run does not complete > --------------------------- > > Key: BIT-1475 > URL: https://bro-tracker.atlassian.net/browse/BIT-1475 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Environment: Centos 6.6 > Reporter: Aaron > Labels: hang > Attachments: bro.tar.gz > > > I'm having trouble running an external program in the callback function for an event when processing a pcap file. It seems to work in bro_init, however, which confuses me. > The working file will print out the output of the "ls" command, whereas the not-working file will not print out anything no matter how long I wait. > Specifically here I want to use the event when bro detects a file in the pcap. > working.bro (ran as simply "bro working.bro"): > {code:java} > @load base/utils/exec > redef exit_only_after_terminate=T; > event bro_init() > { > local t= "ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} > notworking.bro (ran as bro -r my.pcap notworking.bro: > {code:java} > @load base/utils/exec > @load base/frameworks/files > @load base/frameworks/notice > redef exit_only_after_terminate=T; > event file_new(f: fa_file) > { > local t ="ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Mon Sep 14 15:15:02 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Mon, 14 Sep 2015 17:15:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1400) topic/jsiwek/mime-multipart-boundary-leniency In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1400: ------------------------------- Resolution: Fixed Status: Closed (was: Open) This was merged in 46fc3db8ccb6432729ecff0a38d9b40fabd2e983 but for some reason never closed. > topic/jsiwek/mime-multipart-boundary-leniency > --------------------------------------------- > > Key: BIT-1400 > URL: https://bro-tracker.atlassian.net/browse/BIT-1400 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Jon Siwek > Assignee: Seth Hall > Fix For: 2.5 > > > Seth had a private pcap showing HTTP multipart content using boundary strings containing the '<' and '>' characters which causes HTTP/MIME content parsing to fail. This branch changes it so those characters are allowed (even though not explicitly permitted by the RFC). It feels a bit hacky to me (but so do most changes I've done to HTTP/MIME analyzers), so please review and check if the analysis looks "more correct" now. > I scheduled this for 2.4 because I think Seth mentioned it might be something to try to get fixed in the final release, but it might be better to put it as part of 2.5 -- it's not really a severe bug but more of an oddity from a particular HTTP implementation and Bro's behavior with respect to it hasn't changed anytime recently (i.e. it's not a regression). -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From noreply at bro.org Tue Sep 15 00:00:21 2015 From: noreply at bro.org (Merge Tracker) Date: Tue, 15 Sep 2015 00:00:21 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509150700.t8F70L7K022330@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- --------------------------------------------------------- BIT-1476 [1] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [2] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [3] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [4] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- --------------------------------------------------------------------------- #44 [5] bro yunzheng [6] 2015-09-11 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [7] #6 [8] bro-plugins jswaro [9] 2015-08-24 Adding initial conversion of TCPRS to a plugin [10] #1 [11] broctl J-Gras [12] 2015-09-11 Added support for packet fanout load balancing [13] [1] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [2] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [3] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [4] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [5] Pull Request #44 https://github.com/bro/bro/pull/44 [6] yunzheng https://github.com/yunzheng [7] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [8] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [9] jswaro https://github.com/jswaro [10] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [11] Pull Request #1 https://github.com/bro/broctl/pull/1 [12] J-Gras https://github.com/J-Gras [13] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config From noreply at bro.org Wed Sep 16 00:00:23 2015 From: noreply at bro.org (Merge Tracker) Date: Wed, 16 Sep 2015 00:00:23 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509160700.t8G70Nx9004619@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- --------------------------------------------------------- BIT-1476 [1] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [2] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [3] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [4] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- --------------------------------------------------------------------------- #44 [5] bro yunzheng [6] 2015-09-11 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [7] #6 [8] bro-plugins jswaro [9] 2015-08-24 Adding initial conversion of TCPRS to a plugin [10] #1 [11] broctl J-Gras [12] 2015-09-11 Added support for packet fanout load balancing [13] [1] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [2] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [3] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [4] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [5] Pull Request #44 https://github.com/bro/bro/pull/44 [6] yunzheng https://github.com/yunzheng [7] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [8] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [9] jswaro https://github.com/jswaro [10] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [11] Pull Request #1 https://github.com/bro/broctl/pull/1 [12] J-Gras https://github.com/J-Gras [13] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config From jira at bro-tracker.atlassian.net Wed Sep 16 14:33:00 2015 From: jira at bro-tracker.atlassian.net (scampbell (JIRA)) Date: Wed, 16 Sep 2015 16:33:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1479) seek functionality in RAW reader does not go to end of file In-Reply-To: References: Message-ID: scampbell created BIT-1479: ------------------------------ Summary: seek functionality in RAW reader does not go to end of file Key: BIT-1479 URL: https://bro-tracker.atlassian.net/browse/BIT-1479 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.4 Environment: running bin/bro version 2.4-87-debug on linux Reporter: scampbell When using the seek functionality for RAW input as described in https://github.com/bro/bro/commit/cbba73ab12b3a9935162f008fe7d05ab61c5be6a The code on line 397-398 will push the suggested value of -1 to 0 which will disable the SEEK_END. The fix would be to make the test if offset < -1, or to remove it in its entirety. many thanks! scott -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Wed Sep 16 14:46:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Wed, 16 Sep 2015 16:46:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1479) seek functionality in RAW reader does not go to end of file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann reassigned BIT-1479: ---------------------------------- Assignee: Johanna Amann > seek functionality in RAW reader does not go to end of file > ----------------------------------------------------------- > > Key: BIT-1479 > URL: https://bro-tracker.atlassian.net/browse/BIT-1479 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Environment: running bin/bro version 2.4-87-debug on linux > Reporter: scampbell > Assignee: Johanna Amann > Labels: input-framework > > When using the seek functionality for RAW input as described in > https://github.com/bro/bro/commit/cbba73ab12b3a9935162f008fe7d05ab61c5be6a > The code on line 397-398 will push the suggested value of -1 to 0 which will disable the SEEK_END. > The fix would be to make the test if offset < -1, or to remove it in its entirety. > many thanks! > scott -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Wed Sep 16 15:19:00 2015 From: jira at bro-tracker.atlassian.net (Lloyd Brown (JIRA)) Date: Wed, 16 Sep 2015 17:19:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1479) seek functionality in RAW reader does not go to end of file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22103#comment-22103 ] Lloyd Brown commented on BIT-1479: ---------------------------------- Alternatively, you could simply choose between SEEK_SET and SEEK_END, before you optionally increment offset. > seek functionality in RAW reader does not go to end of file > ----------------------------------------------------------- > > Key: BIT-1479 > URL: https://bro-tracker.atlassian.net/browse/BIT-1479 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Environment: running bin/bro version 2.4-87-debug on linux > Reporter: scampbell > Assignee: Johanna Amann > Labels: input-framework > > When using the seek functionality for RAW input as described in > https://github.com/bro/bro/commit/cbba73ab12b3a9935162f008fe7d05ab61c5be6a > The code on line 397-398 will push the suggested value of -1 to 0 which will disable the SEEK_END. > The fix would be to make the test if offset < -1, or to remove it in its entirety. > many thanks! > scott -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Wed Sep 16 15:19:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Wed, 16 Sep 2015 17:19:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1479) seek functionality in RAW reader does not go to end of file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1479: ------------------------------- Status: Merge Request (was: Open) Assignee: (was: Johanna Amann) > seek functionality in RAW reader does not go to end of file > ----------------------------------------------------------- > > Key: BIT-1479 > URL: https://bro-tracker.atlassian.net/browse/BIT-1479 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Environment: running bin/bro version 2.4-87-debug on linux > Reporter: scampbell > Labels: input-framework > > When using the seek functionality for RAW input as described in > https://github.com/bro/bro/commit/cbba73ab12b3a9935162f008fe7d05ab61c5be6a > The code on line 397-398 will push the suggested value of -1 to 0 which will disable the SEEK_END. > The fix would be to make the test if offset < -1, or to remove it in its entirety. > many thanks! > scott -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Wed Sep 16 15:19:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Wed, 16 Sep 2015 17:19:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1479) seek functionality in RAW reader does not go to end of file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22104#comment-22104 ] Johanna Amann commented on BIT-1479: ------------------------------------ This is fixed in topic/johanna/bit-1479 > seek functionality in RAW reader does not go to end of file > ----------------------------------------------------------- > > Key: BIT-1479 > URL: https://bro-tracker.atlassian.net/browse/BIT-1479 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Environment: running bin/bro version 2.4-87-debug on linux > Reporter: scampbell > Assignee: Johanna Amann > Labels: input-framework > > When using the seek functionality for RAW input as described in > https://github.com/bro/bro/commit/cbba73ab12b3a9935162f008fe7d05ab61c5be6a > The code on line 397-398 will push the suggested value of -1 to 0 which will disable the SEEK_END. > The fix would be to make the test if offset < -1, or to remove it in its entirety. > many thanks! > scott -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Wed Sep 16 15:25:00 2015 From: jira at bro-tracker.atlassian.net (Lloyd Brown (JIRA)) Date: Wed, 16 Sep 2015 17:25:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1479) seek functionality in RAW reader does not go to end of file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22103#comment-22103 ] Lloyd Brown edited comment on BIT-1479 at 9/16/15 5:24 PM: ----------------------------------------------------------- Alternatively, you could simply choose between SEEK_SET and SEEK_END, before you optionally increment offset. Edit: Never mind. You were posting the fix about the same time as I was posting my comment. was (Author: somewhere_or_other): Alternatively, you could simply choose between SEEK_SET and SEEK_END, before you optionally increment offset. > seek functionality in RAW reader does not go to end of file > ----------------------------------------------------------- > > Key: BIT-1479 > URL: https://bro-tracker.atlassian.net/browse/BIT-1479 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Environment: running bin/bro version 2.4-87-debug on linux > Reporter: scampbell > Labels: input-framework > > When using the seek functionality for RAW input as described in > https://github.com/bro/bro/commit/cbba73ab12b3a9935162f008fe7d05ab61c5be6a > The code on line 397-398 will push the suggested value of -1 to 0 which will disable the SEEK_END. > The fix would be to make the test if offset < -1, or to remove it in its entirety. > many thanks! > scott -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Wed Sep 16 18:13:00 2015 From: jira at bro-tracker.atlassian.net (Lu Goon (JIRA)) Date: Wed, 16 Sep 2015 20:13:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1477) Compile Bro IDS on Raspberry Pi 2 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22105#comment-22105 ] Lu Goon commented on BIT-1477: ------------------------------ it actually looks like this is not a problem with pthreads at all, but with the following check that tries to set BROPATH. Just from looking at the Cmakelist source, I actually do nit really get what the problem could be - however... since this has to do with building the docs, could you edit the root CMakeLists.txt in the bro 2.4.1 folder, and remove the line add_subdirectory(doc) and try to build again and see if it works? > Compile Bro IDS on Raspberry Pi 2 > --------------------------------- > > Key: BIT-1477 > URL: https://bro-tracker.atlassian.net/browse/BIT-1477 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3, 2.4 > Environment: Kali 2.0 for ARM HF and Ubuntu Mate for ARMHF > Reporter: Lu Goon > Labels: compile, pi, raspberry > > Trying to build BRO-IDS on raspberry PI 2 that is running either Kali Linux 2.0 ARM or Ubuntu Mate 15.04 ARM. When I get to the pthread library the CMake errors out looking for the -lpthreads library instead of the -lpthread library. Would like to know where can I edit the CMAKE file to account for pthread instead of pthreads. See information below: > *+PTHREAD is installed on RPi2:+* > root at kali:3.0.2# /sbin/ldconfig -p | grep pthread > libpthread.so.0 (libc6,hard-float, OS ABI: Linux 2.6.32) => /lib/arm-linux-gnueabihf/libpthread.so.0 > libevent_pthreads-2.0.so.5 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libevent_pthreads-2.0.so.5 > root at kali:3.0.2# > *+ERROR MESSAGE FROM CMAKE:+* > Run Build Command:"/usr/bin/make" "cmTryCompileExec67693562/fast" > /usr/bin/make -f CMakeFiles/cmTryCompileExec67693562.dir/build.make CMakeFiles/cmTryCompileExec67693562.dir/build > make[1]: Entering directory '/root/Projects/BRO-IDS/bro-2.3.2/build/CMakeFiles/CMakeTmp' > /usr/bin/cmake -E cmake_progress_report /root/Projects/BRO-IDS/bro-2.3.2/build/CMakeFiles/CMakeTmp/CMakeFiles 1 > Building C object CMakeFiles/cmTryCompileExec67693562.dir/CheckFunctionExists.c.o > /usr/bin/cc -Wall -Wno-unused -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTryCompileExec67693562.dir/CheckFunctionExists.c.o -c /usr/share/cmake-3.0/Modules/CheckFunctionExists.c > Linking C executable cmTryCompileExec67693562 > /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec67693562.dir/link.txt --verbose=1 > /usr/bin/cc -Wall -Wno-unused -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTryCompileExec67693562.dir/CheckFunctionExists.c.o -o cmTryCompileExec67693562 -rdynamic -lpthreads > /usr/bin/ld: cannot find -lpthreads > collect2: error: ld returned 1 exit status > CMakeFiles/cmTryCompileExec67693562.dir/build.make:88: recipe for target 'cmTryCompileExec67693562' failed > make[1]: Leaving directory '/root/Projects/BRO-IDS/bro-2.3.2/build/CMakeFiles/CMakeTmp' > make[1]: *** [cmTryCompileExec67693562] Error 1 > Makefile:118: recipe for target 'cmTryCompileExec67693562/fast' failed > make: *** [cmTryCompileExec67693562/fast] Error 2 -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Wed Sep 16 18:14:00 2015 From: jira at bro-tracker.atlassian.net (Lu Goon (JIRA)) Date: Wed, 16 Sep 2015 20:14:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1477) Compile Bro IDS on Raspberry Pi 2 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lu Goon updated BIT-1477: ------------------------- Resolution: Fixed Status: Closed (was: Open) it actually looks like this is not a problem with pthreads at all, but with the following check that tries to set BROPATH. Just from looking at the Cmakelist source, I actually do nit really get what the problem could be - however... since this has to do with building the docs, could you edit the root CMakeLists.txt in the bro 2.4.1 folder, and remove the line add_subdirectory(doc) and try to build again and see if it works? > Compile Bro IDS on Raspberry Pi 2 > --------------------------------- > > Key: BIT-1477 > URL: https://bro-tracker.atlassian.net/browse/BIT-1477 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3, 2.4 > Environment: Kali 2.0 for ARM HF and Ubuntu Mate for ARMHF > Reporter: Lu Goon > Labels: compile, pi, raspberry > > Trying to build BRO-IDS on raspberry PI 2 that is running either Kali Linux 2.0 ARM or Ubuntu Mate 15.04 ARM. When I get to the pthread library the CMake errors out looking for the -lpthreads library instead of the -lpthread library. Would like to know where can I edit the CMAKE file to account for pthread instead of pthreads. See information below: > *+PTHREAD is installed on RPi2:+* > root at kali:3.0.2# /sbin/ldconfig -p | grep pthread > libpthread.so.0 (libc6,hard-float, OS ABI: Linux 2.6.32) => /lib/arm-linux-gnueabihf/libpthread.so.0 > libevent_pthreads-2.0.so.5 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libevent_pthreads-2.0.so.5 > root at kali:3.0.2# > *+ERROR MESSAGE FROM CMAKE:+* > Run Build Command:"/usr/bin/make" "cmTryCompileExec67693562/fast" > /usr/bin/make -f CMakeFiles/cmTryCompileExec67693562.dir/build.make CMakeFiles/cmTryCompileExec67693562.dir/build > make[1]: Entering directory '/root/Projects/BRO-IDS/bro-2.3.2/build/CMakeFiles/CMakeTmp' > /usr/bin/cmake -E cmake_progress_report /root/Projects/BRO-IDS/bro-2.3.2/build/CMakeFiles/CMakeTmp/CMakeFiles 1 > Building C object CMakeFiles/cmTryCompileExec67693562.dir/CheckFunctionExists.c.o > /usr/bin/cc -Wall -Wno-unused -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTryCompileExec67693562.dir/CheckFunctionExists.c.o -c /usr/share/cmake-3.0/Modules/CheckFunctionExists.c > Linking C executable cmTryCompileExec67693562 > /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec67693562.dir/link.txt --verbose=1 > /usr/bin/cc -Wall -Wno-unused -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTryCompileExec67693562.dir/CheckFunctionExists.c.o -o cmTryCompileExec67693562 -rdynamic -lpthreads > /usr/bin/ld: cannot find -lpthreads > collect2: error: ld returned 1 exit status > CMakeFiles/cmTryCompileExec67693562.dir/build.make:88: recipe for target 'cmTryCompileExec67693562' failed > make[1]: Leaving directory '/root/Projects/BRO-IDS/bro-2.3.2/build/CMakeFiles/CMakeTmp' > make[1]: *** [cmTryCompileExec67693562] Error 1 > Makefile:118: recipe for target 'cmTryCompileExec67693562/fast' failed > make: *** [cmTryCompileExec67693562/fast] Error 2 -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From noreply at bro.org Thu Sep 17 00:00:20 2015 From: noreply at bro.org (Merge Tracker) Date: Thu, 17 Sep 2015 00:00:20 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509170700.t8H70KFG024558@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ----------------------------------------------------------- BIT-1479 [1] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [2] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [3] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [4] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [5] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- --------------------------------------------------------------------------- #44 [6] bro yunzheng [7] 2015-09-11 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [8] #6 [9] bro-plugins jswaro [10] 2015-08-24 Adding initial conversion of TCPRS to a plugin [11] #1 [12] broctl J-Gras [13] 2015-09-11 Added support for packet fanout load balancing [14] [1] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [2] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [3] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [4] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [5] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [6] Pull Request #44 https://github.com/bro/bro/pull/44 [7] yunzheng https://github.com/yunzheng [8] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [9] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [10] jswaro https://github.com/jswaro [11] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [12] Pull Request #1 https://github.com/bro/broctl/pull/1 [13] J-Gras https://github.com/J-Gras [14] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config From jira at bro-tracker.atlassian.net Thu Sep 17 15:26:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Thu, 17 Sep 2015 17:26:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1478) BPF Filter for local.bro per activated log file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22107#comment-22107 ] Johanna Amann commented on BIT-1478: ------------------------------------ Since this is not really a bug, but a question, the mailing list or irc are probably better suited for this question. That being said, you can add bpf filters with the syntax described in https://www.bro.org/sphinx/scripts/base/frameworks/packet-filter/main.bro.html . The thread at http://comments.gmane.org/gmane.comp.security.detection.bro/4759 also has a few examples. There is no easy way to tell Bro to just allow traffic containing x509 certificates - you have to build the filter yourself, only allowing the hosts and services that have traffic containing x509 certificates. If using broctl, typically you would add the filter commands to local.bro or to a script that you load from local.bro -- it is discouraged to edit any scripts in base/ or policy/ yourself. I will close this bug - like I said, if you have more questions the mailing list / irc chat will probably give you more replies. > BPF Filter for local.bro per activated log file > ----------------------------------------------- > > Key: BIT-1478 > URL: https://bro-tracker.atlassian.net/browse/BIT-1478 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3, 2.4 > Environment: linux, mac osx, > Reporter: Lu Goon > Labels: analyzer,, ssl,, x509 > > when activating the x509.log or bro script in local.bro, can I configure a BPF filter to only affect x509? For example I only want to have events that the dust_host is our DMZ subnet. Can I configure that in the x509.bro file or some other bro configuration file? -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Thu Sep 17 15:26:00 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Thu, 17 Sep 2015 17:26:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1478) BPF Filter for local.bro per activated log file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1478: ------------------------------- Resolution: Invalid Status: Closed (was: Open) > BPF Filter for local.bro per activated log file > ----------------------------------------------- > > Key: BIT-1478 > URL: https://bro-tracker.atlassian.net/browse/BIT-1478 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3, 2.4 > Environment: linux, mac osx, > Reporter: Lu Goon > Labels: analyzer,, ssl,, x509 > > when activating the x509.log or bro script in local.bro, can I configure a BPF filter to only affect x509? For example I only want to have events that the dust_host is our DMZ subnet. Can I configure that in the x509.bro file or some other bro configuration file? -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Thu Sep 17 15:48:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 17 Sep 2015 17:48:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1446) Remove the dummy Broker framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22108#comment-22108 ] Daniel Thayer commented on BIT-1446: ------------------------------------ This change will be included in the branch topic/mfischer/broker-integration. > Remove the dummy Broker framework > --------------------------------- > > Key: BIT-1446 > URL: https://bro-tracker.atlassian.net/browse/BIT-1446 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Environment: For unit testing with Broker disabled, there's currently a dummy script-level framework to fill in. > Unfortunately that dummy framework is the one that ends up getting documented, overriding the the actual one. > Now that Broker is mandatory, we should just remove the dummy. > Reporter: Robin Sommer > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Thu Sep 17 16:20:02 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Thu, 17 Sep 2015 18:20:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1475) Exec::Run does not complete In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22109#comment-22109 ] Johanna Amann commented on BIT-1475: ------------------------------------ Could you test if running bro with {code} bro t1.bro -r my.pcap --pseudo-realtime {code} or similar fixes your problem? That will start Bro in pseudo realtime mode and read in the trace as fast as it happened on the wire, inserting sleeps where necessary. The problem seems to be that once processing of the tracefile stopped, no heartbeats are sent to the input threads anymore -- those are necessary to get the output of the command after it has been run. I am not quite sure why that happens - but I think I remember that these are triggered by input traffic (i.e. when there is no further traffic, there are no further heartbeats). The reason that heartbeats happen when no trace is processed is the communication framework - and I think that is special-cased then. In any case - we should probably fix this. > Exec::Run does not complete > --------------------------- > > Key: BIT-1475 > URL: https://bro-tracker.atlassian.net/browse/BIT-1475 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.3 > Environment: Centos 6.6 > Reporter: Aaron > Labels: hang > Fix For: 2.5 > > Attachments: bro.tar.gz > > > I'm having trouble running an external program in the callback function for an event when processing a pcap file. It seems to work in bro_init, however, which confuses me. > The working file will print out the output of the "ls" command, whereas the not-working file will not print out anything no matter how long I wait. > Specifically here I want to use the event when bro detects a file in the pcap. > working.bro (ran as simply "bro working.bro"): > {code:java} > @load base/utils/exec > redef exit_only_after_terminate=T; > event bro_init() > { > local t= "ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} > notworking.bro (ran as bro -r my.pcap notworking.bro: > {code:java} > @load base/utils/exec > @load base/frameworks/files > @load base/frameworks/notice > redef exit_only_after_terminate=T; > event file_new(f: fa_file) > { > local t ="ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Thu Sep 17 16:20:02 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Thu, 17 Sep 2015 18:20:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1475) Exec::Run does not complete In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1475: ------------------------------- Fix Version/s: 2.5 > Exec::Run does not complete > --------------------------- > > Key: BIT-1475 > URL: https://bro-tracker.atlassian.net/browse/BIT-1475 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.3 > Environment: Centos 6.6 > Reporter: Aaron > Labels: hang > Fix For: 2.5 > > Attachments: bro.tar.gz > > > I'm having trouble running an external program in the callback function for an event when processing a pcap file. It seems to work in bro_init, however, which confuses me. > The working file will print out the output of the "ls" command, whereas the not-working file will not print out anything no matter how long I wait. > Specifically here I want to use the event when bro detects a file in the pcap. > working.bro (ran as simply "bro working.bro"): > {code:java} > @load base/utils/exec > redef exit_only_after_terminate=T; > event bro_init() > { > local t= "ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} > notworking.bro (ran as bro -r my.pcap notworking.bro: > {code:java} > @load base/utils/exec > @load base/frameworks/files > @load base/frameworks/notice > redef exit_only_after_terminate=T; > event file_new(f: fa_file) > { > local t ="ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Thu Sep 17 16:20:02 2015 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Thu, 17 Sep 2015 18:20:02 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1475) Exec::Run does not complete In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann updated BIT-1475: ------------------------------- Affects Version/s: git/master > Exec::Run does not complete > --------------------------- > > Key: BIT-1475 > URL: https://bro-tracker.atlassian.net/browse/BIT-1475 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.3 > Environment: Centos 6.6 > Reporter: Aaron > Labels: hang > Fix For: 2.5 > > Attachments: bro.tar.gz > > > I'm having trouble running an external program in the callback function for an event when processing a pcap file. It seems to work in bro_init, however, which confuses me. > The working file will print out the output of the "ls" command, whereas the not-working file will not print out anything no matter how long I wait. > Specifically here I want to use the event when bro detects a file in the pcap. > working.bro (ran as simply "bro working.bro"): > {code:java} > @load base/utils/exec > redef exit_only_after_terminate=T; > event bro_init() > { > local t= "ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} > notworking.bro (ran as bro -r my.pcap notworking.bro: > {code:java} > @load base/utils/exec > @load base/frameworks/files > @load base/frameworks/notice > redef exit_only_after_terminate=T; > event file_new(f: fa_file) > { > local t ="ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From noreply at bro.org Fri Sep 18 00:00:24 2015 From: noreply at bro.org (Merge Tracker) Date: Fri, 18 Sep 2015 00:00:24 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509180700.t8I70OLA022562@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ----------------------------------------------------------- BIT-1479 [1] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [2] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [3] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [4] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [5] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- --------------------------------------------------------------------------- #44 [6] bro yunzheng [7] 2015-09-11 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [8] #6 [9] bro-plugins jswaro [10] 2015-08-24 Adding initial conversion of TCPRS to a plugin [11] #1 [12] broctl J-Gras [13] 2015-09-11 Added support for packet fanout load balancing [14] [1] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [2] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [3] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [4] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [5] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [6] Pull Request #44 https://github.com/bro/bro/pull/44 [7] yunzheng https://github.com/yunzheng [8] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [9] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [10] jswaro https://github.com/jswaro [11] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [12] Pull Request #1 https://github.com/bro/broctl/pull/1 [13] J-Gras https://github.com/J-Gras [14] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config From jira at bro-tracker.atlassian.net Fri Sep 18 04:49:00 2015 From: jira at bro-tracker.atlassian.net (Matthew Domko (JIRA)) Date: Fri, 18 Sep 2015 06:49:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1480) ERSPAN Supprt In-Reply-To: References: Message-ID: Matthew Domko created BIT-1480: ---------------------------------- Summary: ERSPAN Supprt Key: BIT-1480 URL: https://bro-tracker.atlassian.net/browse/BIT-1480 Project: Bro Issue Tracker Issue Type: New Feature Components: Bro Affects Versions: 2.3 Environment: Using vCenter virtual switch, frames from monitored VMs are encapsulated using GRE and forwarded to my sensor on a different broadcast domain. Reporter: Matthew Domko Attachments: erspan PCAP attached... Basically, bro recieves the erspan packet and doesn't recognize that it is just GRE with a slightly different format. All the packets get logged in bro with the ERSPAN source/dest addresses instead of the actual source/dest addresses. It seems like everything else is working. There was a discussion about this on a mailing list in the past, but no one provided PCAP. http://mailman.icsi.berkeley.edu/pipermail/bro/2015-April/008347.html And someone else released a tool to do the decapsulation on the side: http://staff.washington.edu/corey/gulp/ -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Fri Sep 18 10:19:01 2015 From: jira at bro-tracker.atlassian.net (Vlad Grigorescu (JIRA)) Date: Fri, 18 Sep 2015 12:19:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1480) ERSPAN Supprt In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Grigorescu reassigned BIT-1480: ------------------------------------ Assignee: Vlad Grigorescu > ERSPAN Supprt > ------------- > > Key: BIT-1480 > URL: https://bro-tracker.atlassian.net/browse/BIT-1480 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.3 > Environment: Using vCenter virtual switch, frames from monitored VMs are encapsulated using GRE and forwarded to my sensor on a different broadcast domain. > Reporter: Matthew Domko > Assignee: Vlad Grigorescu > Labels: ERSPAN > Attachments: erspan > > > PCAP attached... Basically, bro recieves the erspan packet and doesn't recognize that it is just GRE with a slightly different format. All the packets get logged in bro with the ERSPAN source/dest addresses instead of the actual source/dest addresses. It seems like everything else is working. > There was a discussion about this on a mailing list in the past, but no one provided PCAP. > http://mailman.icsi.berkeley.edu/pipermail/bro/2015-April/008347.html > And someone else released a tool to do the decapsulation on the side: > http://staff.washington.edu/corey/gulp/ -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Fri Sep 18 12:34:00 2015 From: jira at bro-tracker.atlassian.net (Aaron (JIRA)) Date: Fri, 18 Sep 2015 14:34:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1475) Exec::Run does not complete In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22110#comment-22110 ] Aaron commented on BIT-1475: ---------------------------- The extra flag appears to help when the script is as short as my example.... But when I try to use my real script, which would take longer than the example, I again do not see any output (I guess the script runtime was longer than the pcap duration). > Exec::Run does not complete > --------------------------- > > Key: BIT-1475 > URL: https://bro-tracker.atlassian.net/browse/BIT-1475 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.3 > Environment: Centos 6.6 > Reporter: Aaron > Labels: hang > Fix For: 2.5 > > Attachments: bro.tar.gz > > > I'm having trouble running an external program in the callback function for an event when processing a pcap file. It seems to work in bro_init, however, which confuses me. > The working file will print out the output of the "ls" command, whereas the not-working file will not print out anything no matter how long I wait. > Specifically here I want to use the event when bro detects a file in the pcap. > working.bro (ran as simply "bro working.bro"): > {code:java} > @load base/utils/exec > redef exit_only_after_terminate=T; > event bro_init() > { > local t= "ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} > notworking.bro (ran as bro -r my.pcap notworking.bro: > {code:java} > @load base/utils/exec > @load base/frameworks/files > @load base/frameworks/notice > redef exit_only_after_terminate=T; > event file_new(f: fa_file) > { > local t ="ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Fri Sep 18 12:37:01 2015 From: jira at bro-tracker.atlassian.net (Aaron (JIRA)) Date: Fri, 18 Sep 2015 14:37:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1475) Exec::Run does not complete In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22110#comment-22110 ] Aaron edited comment on BIT-1475 at 9/18/15 2:36 PM: ----------------------------------------------------- The extra flag appears to help when the script is as short as my example.... But when I try to use my real script, which would take longer than the example, I again do not see any output (I guess the script runtime was longer than the pcap duration). Edit: Based on your description of the cause, it sounds like shouldn't be a problem if bro is consuming packets live? But it makes it very hard to test scripts in offline/batch mode... was (Author: ajmills): The extra flag appears to help when the script is as short as my example.... But when I try to use my real script, which would take longer than the example, I again do not see any output (I guess the script runtime was longer than the pcap duration). > Exec::Run does not complete > --------------------------- > > Key: BIT-1475 > URL: https://bro-tracker.atlassian.net/browse/BIT-1475 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.3 > Environment: Centos 6.6 > Reporter: Aaron > Labels: hang > Fix For: 2.5 > > Attachments: bro.tar.gz > > > I'm having trouble running an external program in the callback function for an event when processing a pcap file. It seems to work in bro_init, however, which confuses me. > The working file will print out the output of the "ls" command, whereas the not-working file will not print out anything no matter how long I wait. > Specifically here I want to use the event when bro detects a file in the pcap. > working.bro (ran as simply "bro working.bro"): > {code:java} > @load base/utils/exec > redef exit_only_after_terminate=T; > event bro_init() > { > local t= "ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} > notworking.bro (ran as bro -r my.pcap notworking.bro: > {code:java} > @load base/utils/exec > @load base/frameworks/files > @load base/frameworks/notice > redef exit_only_after_terminate=T; > event file_new(f: fa_file) > { > local t ="ls /"; > local cmd = Exec::Command($cmd=t); > when (local res = Exec::run(cmd)) > { > print "hello"; > print res$stdout; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Fri Sep 18 13:55:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 18 Sep 2015 15:55:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1481) some test canonifiers don't always read from stdin In-Reply-To: References: Message-ID: Daniel Thayer created BIT-1481: ---------------------------------- Summary: some test canonifiers don't always read from stdin Key: BIT-1481 URL: https://bro-tracker.atlassian.net/browse/BIT-1481 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Daniel Thayer Some of the test canonifier scripts being used in the Bro test suite cannot reliably be combined with other canonifiers in a pipeline. For example, this works: TEST_DIFF_CANONIFIER="diff-remove-x509-names | diff-remove-timestamps" but switching the order of these canonifiers does not work: TEST_DIFF_CANONIFIER="diff-remove-timestamps | diff-remove-x509-names" -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Fri Sep 18 13:55:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 18 Sep 2015 15:55:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1481) some test canonifiers don't always read from stdin In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer reassigned BIT-1481: ---------------------------------- Assignee: Daniel Thayer > some test canonifiers don't always read from stdin > -------------------------------------------------- > > Key: BIT-1481 > URL: https://bro-tracker.atlassian.net/browse/BIT-1481 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > Assignee: Daniel Thayer > > Some of the test canonifier scripts being used in the Bro test suite > cannot reliably be combined with other canonifiers in a pipeline. > For example, this works: > TEST_DIFF_CANONIFIER="diff-remove-x509-names | diff-remove-timestamps" > but switching the order of these canonifiers does not work: > TEST_DIFF_CANONIFIER="diff-remove-timestamps | diff-remove-x509-names" -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From noreply at bro.org Sat Sep 19 00:00:19 2015 From: noreply at bro.org (Merge Tracker) Date: Sat, 19 Sep 2015 00:00:19 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509190700.t8J70J3T022216@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ----------------------------------------------------------- BIT-1479 [1] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [2] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [3] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [4] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [5] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- --------------------------------------------------------------------------- #44 [6] bro yunzheng [7] 2015-09-18 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [8] #6 [9] bro-plugins jswaro [10] 2015-08-24 Adding initial conversion of TCPRS to a plugin [11] #1 [12] broctl J-Gras [13] 2015-09-11 Added support for packet fanout load balancing [14] [1] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [2] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [3] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [4] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [5] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [6] Pull Request #44 https://github.com/bro/bro/pull/44 [7] yunzheng https://github.com/yunzheng [8] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [9] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [10] jswaro https://github.com/jswaro [11] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [12] Pull Request #1 https://github.com/bro/broctl/pull/1 [13] J-Gras https://github.com/J-Gras [14] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config From jira at bro-tracker.atlassian.net Sat Sep 19 06:33:00 2015 From: jira at bro-tracker.atlassian.net (Matthew Domko (JIRA)) Date: Sat, 19 Sep 2015 08:33:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1480) ERSPAN Supprt In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Domko updated BIT-1480: ------------------------------- Attachment: ERSPAN-info.xps > ERSPAN Supprt > ------------- > > Key: BIT-1480 > URL: https://bro-tracker.atlassian.net/browse/BIT-1480 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.3 > Environment: Using vCenter virtual switch, frames from monitored VMs are encapsulated using GRE and forwarded to my sensor on a different broadcast domain. > Reporter: Matthew Domko > Assignee: Vlad Grigorescu > Labels: ERSPAN > Attachments: erspan, ERSPAN-info.xps > > > PCAP attached... Basically, bro recieves the erspan packet and doesn't recognize that it is just GRE with a slightly different format. All the packets get logged in bro with the ERSPAN source/dest addresses instead of the actual source/dest addresses. It seems like everything else is working. > There was a discussion about this on a mailing list in the past, but no one provided PCAP. > http://mailman.icsi.berkeley.edu/pipermail/bro/2015-April/008347.html > And someone else released a tool to do the decapsulation on the side: > http://staff.washington.edu/corey/gulp/ -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Sat Sep 19 06:34:00 2015 From: jira at bro-tracker.atlassian.net (Matthew Domko (JIRA)) Date: Sat, 19 Sep 2015 08:34:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1480) ERSPAN Supprt In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22111#comment-22111 ] Matthew Domko commented on BIT-1480: ------------------------------------ More research, just trying to save the devs some time... Will keep adding as I find it. If it's not helpful, just let me know. Ciscos implementation uses GRE protocol type 0x88BE . Relevant pages from link attached.Includes a generic packet format graphic www.cisco.com/web/strategy/docs/gov/DATM_CoPP_ERSPAN_NetFlow.pdf > ERSPAN Supprt > ------------- > > Key: BIT-1480 > URL: https://bro-tracker.atlassian.net/browse/BIT-1480 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.3 > Environment: Using vCenter virtual switch, frames from monitored VMs are encapsulated using GRE and forwarded to my sensor on a different broadcast domain. > Reporter: Matthew Domko > Assignee: Vlad Grigorescu > Labels: ERSPAN > Attachments: erspan, ERSPAN-info.xps > > > PCAP attached... Basically, bro recieves the erspan packet and doesn't recognize that it is just GRE with a slightly different format. All the packets get logged in bro with the ERSPAN source/dest addresses instead of the actual source/dest addresses. It seems like everything else is working. > There was a discussion about this on a mailing list in the past, but no one provided PCAP. > http://mailman.icsi.berkeley.edu/pipermail/bro/2015-April/008347.html > And someone else released a tool to do the decapsulation on the side: > http://staff.washington.edu/corey/gulp/ -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Sat Sep 19 22:48:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Sun, 20 Sep 2015 00:48:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1481) some test canonifiers don't always read from stdin In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22112#comment-22112 ] Daniel Thayer commented on BIT-1481: ------------------------------------ In branch "topic/dnthayer/ticket1481" in the bro git repo, I've changed a few canonifier scripts so that they no longer read their input from a filename command-line argument. I also removed two canonifier scripts rather than convert them, because it appears they are no longer being used. In addition, I also fixed a few minor unrelated issues in a few canonifiers, such as an off-by-one error in some "for" loops. > some test canonifiers don't always read from stdin > -------------------------------------------------- > > Key: BIT-1481 > URL: https://bro-tracker.atlassian.net/browse/BIT-1481 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > Assignee: Daniel Thayer > > Some of the test canonifier scripts being used in the Bro test suite > cannot reliably be combined with other canonifiers in a pipeline. > For example, this works: > TEST_DIFF_CANONIFIER="diff-remove-x509-names | diff-remove-timestamps" > but switching the order of these canonifiers does not work: > TEST_DIFF_CANONIFIER="diff-remove-timestamps | diff-remove-x509-names" -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Sat Sep 19 22:49:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Sun, 20 Sep 2015 00:49:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1481) some test canonifiers don't always read from stdin In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1481: ------------------------------- Status: Merge Request (was: Open) Assignee: (was: Daniel Thayer) > some test canonifiers don't always read from stdin > -------------------------------------------------- > > Key: BIT-1481 > URL: https://bro-tracker.atlassian.net/browse/BIT-1481 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > > Some of the test canonifier scripts being used in the Bro test suite > cannot reliably be combined with other canonifiers in a pipeline. > For example, this works: > TEST_DIFF_CANONIFIER="diff-remove-x509-names | diff-remove-timestamps" > but switching the order of these canonifiers does not work: > TEST_DIFF_CANONIFIER="diff-remove-timestamps | diff-remove-x509-names" -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From jira at bro-tracker.atlassian.net Sat Sep 19 22:53:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Sun, 20 Sep 2015 00:53:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1481) some test canonifiers don't always read from stdin In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22113#comment-22113 ] Daniel Thayer commented on BIT-1481: ------------------------------------ Also, I checked all the canonifiers in all of the other Bro git repos that use btest, and didn't find this problem anywhere except in the "bro" git repo. > some test canonifiers don't always read from stdin > -------------------------------------------------- > > Key: BIT-1481 > URL: https://bro-tracker.atlassian.net/browse/BIT-1481 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > > Some of the test canonifier scripts being used in the Bro test suite > cannot reliably be combined with other canonifiers in a pipeline. > For example, this works: > TEST_DIFF_CANONIFIER="diff-remove-x509-names | diff-remove-timestamps" > but switching the order of these canonifiers does not work: > TEST_DIFF_CANONIFIER="diff-remove-timestamps | diff-remove-x509-names" -- This message was sent by Atlassian JIRA (v7.0.0-OD-05-005#70102) From noreply at bro.org Sun Sep 20 00:00:19 2015 From: noreply at bro.org (Merge Tracker) Date: Sun, 20 Sep 2015 00:00:19 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509200700.t8K70JNA014361@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ----------------------------------------------------------- BIT-1481 [1] Bro Daniel Thayer - 2015-09-20 - Normal some test canonifiers don't always read from stdin BIT-1479 [2] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [3] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [4] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [5] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [6] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- --------------------------------------------------------------------------- #44 [7] bro yunzheng [8] 2015-09-18 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [9] #6 [10] bro-plugins jswaro [11] 2015-08-24 Adding initial conversion of TCPRS to a plugin [12] #1 [13] broctl J-Gras [14] 2015-09-11 Added support for packet fanout load balancing [15] [1] BIT-1481 https://bro-tracker.atlassian.net/browse/BIT-1481 [2] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [3] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [4] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [5] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [6] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [7] Pull Request #44 https://github.com/bro/bro/pull/44 [8] yunzheng https://github.com/yunzheng [9] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [10] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [11] jswaro https://github.com/jswaro [12] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [13] Pull Request #1 https://github.com/bro/broctl/pull/1 [14] J-Gras https://github.com/J-Gras [15] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config From noreply at bro.org Mon Sep 21 00:00:22 2015 From: noreply at bro.org (Merge Tracker) Date: Mon, 21 Sep 2015 00:00:22 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509210700.t8L70MTY004825@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ----------------------------------------------------------- BIT-1481 [1] Bro Daniel Thayer - 2015-09-20 - Normal some test canonifiers don't always read from stdin BIT-1479 [2] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [3] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [4] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [5] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [6] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- --------------------------------------------------------------------------- #44 [7] bro yunzheng [8] 2015-09-18 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [9] #6 [10] bro-plugins jswaro [11] 2015-08-24 Adding initial conversion of TCPRS to a plugin [12] #1 [13] broctl J-Gras [14] 2015-09-11 Added support for packet fanout load balancing [15] [1] BIT-1481 https://bro-tracker.atlassian.net/browse/BIT-1481 [2] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [3] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [4] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [5] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [6] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [7] Pull Request #44 https://github.com/bro/bro/pull/44 [8] yunzheng https://github.com/yunzheng [9] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [10] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [11] jswaro https://github.com/jswaro [12] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [13] Pull Request #1 https://github.com/bro/broctl/pull/1 [14] J-Gras https://github.com/J-Gras [15] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config From jira at bro-tracker.atlassian.net Mon Sep 21 07:28:00 2015 From: jira at bro-tracker.atlassian.net (Aaron Eppert (JIRA)) Date: Mon, 21 Sep 2015 09:28:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1482) Crash from: "tcmalloc: large alloc" In-Reply-To: References: Message-ID: Aaron Eppert created BIT-1482: --------------------------------- Summary: Crash from: "tcmalloc: large alloc" Key: BIT-1482 URL: https://bro-tracker.atlassian.net/browse/BIT-1482 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Aaron Eppert core.91861 [New Thread 91861] [New Thread 91871] [New Thread 91872] [New Thread 91873] [Thread debugging using libthread_db enabled] Core was generated by `/usr/local/bro/bin/bro -i eth1 -U .status -p broctl -p broctl-live -p local -p'. Program terminated with signal 11, Segmentation fault. #0 0x000000000081816b in Serializer::Write (this=0x7ffde1aa2d00, v=35329, tag=0xb752df "stype") at /mnt/hgfs/src/psdev/bro/src/Serializer.h:57 in /mnt/hgfs/src/psdev/bro/src/Serializer.h Thread 4 (Thread 0x7fb7ce219700 (LWP 91873)): #0 0x0000003b8f00ba0e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000086f551 in threading::Queue::Get (this=0x3e10c38) at /mnt/hgfs/src/psdev/bro/src/threading/Queue.h:173 #2 0x000000000086dcfb in threading::MsgThread::RetrieveIn (this=0x3e10c00) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:349 #3 0x000000000086de02 in threading::MsgThread::Run (this=0x3e10c00) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:366 #4 0x000000000086a2c6 in threading::BasicThread::launcher (arg=0x3e10c00) at /mnt/hgfs/src/psdev/bro/src/threading/BasicThread.cc:201 #5 0x0000003b8f007a51 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003b8ece89ad in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7fb7cec1a700 (LWP 91872)): #0 0x0000003b8f00ba0e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000086f551 in threading::Queue::Get (this=0x3e11838) at /mnt/hgfs/src/psdev/bro/src/threading/Queue.h:173 #2 0x000000000086dcfb in threading::MsgThread::RetrieveIn (this=0x3e11800) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:349 #3 0x000000000086de02 in threading::MsgThread::Run (this=0x3e11800) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:366 #4 0x000000000086a2c6 in threading::BasicThread::launcher (arg=0x3e11800) at /mnt/hgfs/src/psdev/bro/src/threading/BasicThread.cc:201 #5 0x0000003b8f007a51 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003b8ece89ad in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fb7cf61b700 (LWP 91871)): #0 0x0000003b8f00ba0e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000086f551 in threading::Queue::Get (this=0x3e12438) at /mnt/hgfs/src/psdev/bro/src/threading/Queue.h:173 #2 0x000000000086dcfb in threading::MsgThread::RetrieveIn (this=0x3e12400) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:349 #3 0x000000000086de02 in threading::MsgThread::Run (this=0x3e12400) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:366 #4 0x000000000086a2c6 in threading::BasicThread::launcher (arg=0x3e12400) at /mnt/hgfs/src/psdev/bro/src/threading/BasicThread.cc:201 #5 0x0000003b8f007a51 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003b8ece89ad in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fb84fc06800 (LWP 91861)): #0 0x000000000081816b in Serializer::Write (this=0x7ffde1aa2d00, v=35329, tag=0xb752df "stype") at /mnt/hgfs/src/psdev/bro/src/Serializer.h:57 #1 0x0000000000817fb4 in SerialObj::DoSerialize (this=0x2c2a400, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:268 #2 0x00000000007e1be2 in BroObj::DoSerialize (this=0x2c2a400, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Obj.cc:226 #3 0x00000000008459b4 in BroType::DoSerialize (this=0x2c2a400, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:283 #4 0x000000000081788a in SerialObj::Serialize (this=0x2c2a400, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 #5 0x0000000000845670 in BroType::Serialize (this=0x2c2a400, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:212 #6 0x0000000000742c72 in Attributes::DoSerialize (this=0x2c2afc0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:516 #7 0x000000000081788a in SerialObj::Serialize (this=0x2c2afc0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 #8 0x0000000000742b1b in Attributes::Serialize (this=0x2c2afc0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:500 #9 0x0000000000848ab5 in TypeDecl::Serialize (this=0x2c05ec0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:929 #10 0x000000000084a01a in RecordType::DoSerialize (this=0x2aea340, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:1250 #11 0x000000000081788a in SerialObj::Serialize (this=0x2aea340, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 ... (pattern repeats .... ) ... #116924 0x0000000000845670 in BroType::Serialize (this=0x4740480, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:212 #116925 0x0000000000742c72 in Attributes::DoSerialize (this=0x4808e00, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:516 #116926 0x000000000081788a in SerialObj::Serialize (this=0x4808e00, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 #116927 0x0000000000742b1b in Attributes::Serialize (this=0x4808e00, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:500 #116928 0x0000000000848ab5 in TypeDecl::Serialize (this=0x47eae00, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:929 #116929 0x000000000084a01a in RecordType::DoSerialize (this=0x4847e60, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:1250 #116930 0x000000000081788a in SerialObj::Serialize (this=0x4847e60, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 #116931 0x0000000000845670 in BroType::Serialize (this=0x4847e60, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:212 #116932 0x0000000000742c72 in Attributes::DoSerialize (this=0x48081c0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:516 #116933 0x000000000081788a in SerialObj::Serialize (this=0x48081c0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 #116934 0x0000000000742b1b in Attributes::Serialize (this=0x48081c0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:500 #116935 0x0000000000848ab5 in TypeDecl::Serialize (this=0x47e81c0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:929 #116936 0x000000000084a01a in RecordType::DoSerialize (this=0x2aec4a0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:1250 #116937 0x000000000081788a in SerialObj::Serialize (this=0x2aec4a0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 #116938 0x0000000000845670 in BroType::Serialize (this=0x2aec4a0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:212 #116939 0x0000000000854a9e in Val::DoSerialize (this=0x6b92760, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Val.cc:188 #116940 0x00000000008562bc in MutableVal::DoSerialize (this=0x6b92760, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Val.cc:656 #116941 0x000000000085efb2 in RecordVal::DoSerialize (this=0x6b92760, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Val.cc:2813 #116942 0x000000000081788a in SerialObj::Serialize (this=0x6b92760, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 #116943 0x0000000000854643 in Val::Serialize (this=0x6b92760, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Val.cc:100 #116944 0x0000000000854511 in Val::Clone (this=0x6b92760) at /mnt/hgfs/src/psdev/bro/src/Val.cc:83 #116945 0x00000000007a4d91 in Frame::Clone (this=0x8b612d0) at /mnt/hgfs/src/psdev/bro/src/Frame.cc:78 #116946 0x0000000000841676 in Trigger::Trigger (this=0x2b79dc0, arg_cond=0x4ae81c0, arg_body=0x4af3600, arg_timeout_stmts=0x0, arg_timeout=0x0, arg_frame=0x8b612d0, arg_is_return=false, arg_location=0x4b4d280) at /mnt/hgfs/src/psdev/bro/src/Trigger.cc:108 #116947 0x000000000083db0e in WhenStmt::Exec (this=0x4b3eba0, f=0x8b612d0, flow=@0x7ffde1aa3064) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:2166 #116948 0x000000000083c17b in StmtList::Exec (this=0x4af4260, f=0x8b612d0, flow=@0x7ffde1aa3064) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:1764 #116949 0x000000000083c17b in StmtList::Exec (this=0x4b56540, f=0x8b612d0, flow=@0x7ffde1aa3064) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:1764 #116950 0x00000000007a649b in BroFunc::Call (this=0x3099030, args=0x82c33e0, parent=0x0) at /mnt/hgfs/src/psdev/bro/src/Func.cc:386 #116951 0x000000000077f12e in EventHandler::Call (this=0x3084600, vl=0x82c33e0, no_remote=false) at /mnt/hgfs/src/psdev/bro/src/EventHandler.cc:80 #116952 0x0000000000732965 in Event::Dispatch (this=0xb5004e0, no_remote=false) at /mnt/hgfs/src/psdev/bro/src/Event.h:50 #116953 0x000000000077e85d in EventMgr::Dispatch (this=0xf66ee0) at /mnt/hgfs/src/psdev/bro/src/Event.cc:111 #116954 0x000000000077e968 in EventMgr::Drain (this=0xf66ee0) at /mnt/hgfs/src/psdev/bro/src/Event.cc:128 #116955 0x00000000007ddd66 in net_packet_dispatch (t=1442838074.400739, hdr=0x4d73140, pkt=0x7fb7db8622fc
, hdr_size=14, src_ps=0x4d73000) at /mnt/hgfs/src/psdev/bro/src/Net.cc:278 #116956 0x0000000000af1ed6 in iosource::PktSrc::Process (this=0x4d73000) at /mnt/hgfs/src/psdev/bro/src/iosource/PktSrc.cc:411 #116957 0x00000000007ddf6f in net_run () at /mnt/hgfs/src/psdev/bro/src/Net.cc:320 #116958 0x00000000007319aa in main (argc=18, argv=0x7ffde1aa3af8) at /mnt/hgfs/src/psdev/bro/src/main.cc:1200 ==== No reporter.log ==== stderr.log internal warning in /usr/local/bro/share/bro/base/frameworks/control/./main.bro, line 1: Discarded extraneous Broxygen comment: MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the internal warning in /usr/local/bro/share/bro/base/frameworks/control/./main.bro, line 1: Discarded extraneous Broxygen comment: GNU General Public License for more details. internal warning in /usr/local/bro/share/bro/base/frameworks/control/./main.bro, line 1: Discarded extraneous Broxygen comment: You should have received a copy of the GNU General Public License internal warning in /usr/local/bro/share/bro/base/frameworks/control/./main.bro, line 1: Discarded extraneous Broxygen comment: along with tcplog. If not, see . listening on eth1, capture length 65535 bytes processing suspended processing continued tcmalloc: large alloc 1562509312 bytes == 0x498f0000 @ 0x7fb85004b4ac 0x7fb85006b22c 0x73b0e5 0x815270 0x81627e 0x7437f8 0x742ddd 0x81788a 0x742b1b 0x848ab5 0x84a01a 0x81788a 0x845670 0x848b3b 0x84a01a 0x81788a 0x845670 0x846db0 0x84759e 0x81788a 0x845670 0x742c72 0x81788a 0x742b1b 0x848ab5 0x84a01a 0x81788a 0x845670 0x742c72 0x81788a 0x742b1b /usr/local/bro/share/broctl/scripts/run-bro: line 85: 91861 Segmentation fault (core dumped) nohup ${pin_command} $pin_cpu $mybro "$@" ---- (gdb) frame 0 #0 0x000000000081816b in Serializer::Write (this=0x7ffde1aa2d00, v=35329, tag=0xb752df "stype") at /mnt/hgfs/src/psdev/bro/src/Serializer.h:57 57 DECLARE_IO(uint16) (gdb) print *this $8 = {_vptr.Serializer = 0xb7dc50, static MAGIC = 1112691540, static DATA_FORMAT_VERSION = 25, io = 0x0, format = 0x89def00, current_cache = 0x0, error_descr = 0x0} (gdb) print *this $10 = {_vptr.Serializer = 0xb7dc50, static MAGIC = 1112691540, static DATA_FORMAT_VERSION = 25, io = 0x0, format = 0x89def00, current_cache = 0x0, error_descr = 0x0} (gdb) print *this->format $11 = {_vptr.SerializationFormat = 0xb74dd0, static INITIAL_SIZE = 65536, static GROWTH_FACTOR = 2.5, output = 0x498f0000 "\001", output_size = 1562499968, output_pos = 852829181, input = 0x0, input_len = 0, input_pos = 0, bytes_written = 852829181, bytes_read = 0} The stack trace and the problem seems to be similar to: http://mailman.icsi.berkeley.edu/pipermail/bro/2015-March/008241.html -- This message was sent by Atlassian JIRA (v7.0.0-OD-06-002#70102) From robin at icir.org Mon Sep 21 07:35:09 2015 From: robin at icir.org (Robin Sommer) Date: Mon, 21 Sep 2015 07:35:09 -0700 Subject: [Bro-Dev] [JIRA] (BIT-1482) Crash from: "tcmalloc: large alloc" In-Reply-To: References: Message-ID: <20150921143509.GI95299@icir.org> Which version is this? From jira at bro-tracker.atlassian.net Mon Sep 21 07:37:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 21 Sep 2015 09:37:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1482) Crash from: "tcmalloc: large alloc" In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22200#comment-22200 ] Robin Sommer commented on BIT-1482: ----------------------------------- Which version is this? > Crash from: "tcmalloc: large alloc" > ----------------------------------- > > Key: BIT-1482 > URL: https://bro-tracker.atlassian.net/browse/BIT-1482 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Aaron Eppert > > core.91861 > [New Thread 91861] > [New Thread 91871] > [New Thread 91872] > [New Thread 91873] > [Thread debugging using libthread_db enabled] > Core was generated by `/usr/local/bro/bin/bro -i eth1 -U .status -p broctl -p broctl-live -p local -p'. > Program terminated with signal 11, Segmentation fault. > #0 0x000000000081816b in Serializer::Write (this=0x7ffde1aa2d00, v=35329, tag=0xb752df "stype") at /mnt/hgfs/src/psdev/bro/src/Serializer.h:57 > in /mnt/hgfs/src/psdev/bro/src/Serializer.h > Thread 4 (Thread 0x7fb7ce219700 (LWP 91873)): > #0 0x0000003b8f00ba0e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000086f551 in threading::Queue::Get (this=0x3e10c38) at /mnt/hgfs/src/psdev/bro/src/threading/Queue.h:173 > #2 0x000000000086dcfb in threading::MsgThread::RetrieveIn (this=0x3e10c00) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:349 > #3 0x000000000086de02 in threading::MsgThread::Run (this=0x3e10c00) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:366 > #4 0x000000000086a2c6 in threading::BasicThread::launcher (arg=0x3e10c00) at /mnt/hgfs/src/psdev/bro/src/threading/BasicThread.cc:201 > #5 0x0000003b8f007a51 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003b8ece89ad in clone () from /lib64/libc.so.6 > Thread 3 (Thread 0x7fb7cec1a700 (LWP 91872)): > #0 0x0000003b8f00ba0e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000086f551 in threading::Queue::Get (this=0x3e11838) at /mnt/hgfs/src/psdev/bro/src/threading/Queue.h:173 > #2 0x000000000086dcfb in threading::MsgThread::RetrieveIn (this=0x3e11800) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:349 > #3 0x000000000086de02 in threading::MsgThread::Run (this=0x3e11800) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:366 > #4 0x000000000086a2c6 in threading::BasicThread::launcher (arg=0x3e11800) at /mnt/hgfs/src/psdev/bro/src/threading/BasicThread.cc:201 > #5 0x0000003b8f007a51 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003b8ece89ad in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fb7cf61b700 (LWP 91871)): > #0 0x0000003b8f00ba0e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x000000000086f551 in threading::Queue::Get (this=0x3e12438) at /mnt/hgfs/src/psdev/bro/src/threading/Queue.h:173 > #2 0x000000000086dcfb in threading::MsgThread::RetrieveIn (this=0x3e12400) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:349 > #3 0x000000000086de02 in threading::MsgThread::Run (this=0x3e12400) at /mnt/hgfs/src/psdev/bro/src/threading/MsgThread.cc:366 > #4 0x000000000086a2c6 in threading::BasicThread::launcher (arg=0x3e12400) at /mnt/hgfs/src/psdev/bro/src/threading/BasicThread.cc:201 > #5 0x0000003b8f007a51 in start_thread () from /lib64/libpthread.so.0 > #6 0x0000003b8ece89ad in clone () from /lib64/libc.so.6 > Thread 1 (Thread 0x7fb84fc06800 (LWP 91861)): > #0 0x000000000081816b in Serializer::Write (this=0x7ffde1aa2d00, v=35329, tag=0xb752df "stype") at /mnt/hgfs/src/psdev/bro/src/Serializer.h:57 > #1 0x0000000000817fb4 in SerialObj::DoSerialize (this=0x2c2a400, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:268 > #2 0x00000000007e1be2 in BroObj::DoSerialize (this=0x2c2a400, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Obj.cc:226 > #3 0x00000000008459b4 in BroType::DoSerialize (this=0x2c2a400, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:283 > #4 0x000000000081788a in SerialObj::Serialize (this=0x2c2a400, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 > #5 0x0000000000845670 in BroType::Serialize (this=0x2c2a400, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:212 > #6 0x0000000000742c72 in Attributes::DoSerialize (this=0x2c2afc0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:516 > #7 0x000000000081788a in SerialObj::Serialize (this=0x2c2afc0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 > #8 0x0000000000742b1b in Attributes::Serialize (this=0x2c2afc0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:500 > #9 0x0000000000848ab5 in TypeDecl::Serialize (this=0x2c05ec0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:929 > #10 0x000000000084a01a in RecordType::DoSerialize (this=0x2aea340, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:1250 > #11 0x000000000081788a in SerialObj::Serialize (this=0x2aea340, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 > ... (pattern repeats .... ) > ... > #116924 0x0000000000845670 in BroType::Serialize (this=0x4740480, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:212 > #116925 0x0000000000742c72 in Attributes::DoSerialize (this=0x4808e00, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:516 > #116926 0x000000000081788a in SerialObj::Serialize (this=0x4808e00, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 > #116927 0x0000000000742b1b in Attributes::Serialize (this=0x4808e00, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:500 > #116928 0x0000000000848ab5 in TypeDecl::Serialize (this=0x47eae00, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:929 > #116929 0x000000000084a01a in RecordType::DoSerialize (this=0x4847e60, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:1250 > #116930 0x000000000081788a in SerialObj::Serialize (this=0x4847e60, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 > #116931 0x0000000000845670 in BroType::Serialize (this=0x4847e60, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:212 > #116932 0x0000000000742c72 in Attributes::DoSerialize (this=0x48081c0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:516 > #116933 0x000000000081788a in SerialObj::Serialize (this=0x48081c0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 > #116934 0x0000000000742b1b in Attributes::Serialize (this=0x48081c0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Attr.cc:500 > #116935 0x0000000000848ab5 in TypeDecl::Serialize (this=0x47e81c0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:929 > #116936 0x000000000084a01a in RecordType::DoSerialize (this=0x2aec4a0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:1250 > #116937 0x000000000081788a in SerialObj::Serialize (this=0x2aec4a0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 > #116938 0x0000000000845670 in BroType::Serialize (this=0x2aec4a0, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Type.cc:212 > #116939 0x0000000000854a9e in Val::DoSerialize (this=0x6b92760, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Val.cc:188 > #116940 0x00000000008562bc in MutableVal::DoSerialize (this=0x6b92760, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Val.cc:656 > #116941 0x000000000085efb2 in RecordVal::DoSerialize (this=0x6b92760, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Val.cc:2813 > #116942 0x000000000081788a in SerialObj::Serialize (this=0x6b92760, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/SerialObj.cc:121 > #116943 0x0000000000854643 in Val::Serialize (this=0x6b92760, info=0x7ffde1aa2d60) at /mnt/hgfs/src/psdev/bro/src/Val.cc:100 > #116944 0x0000000000854511 in Val::Clone (this=0x6b92760) at /mnt/hgfs/src/psdev/bro/src/Val.cc:83 > #116945 0x00000000007a4d91 in Frame::Clone (this=0x8b612d0) at /mnt/hgfs/src/psdev/bro/src/Frame.cc:78 > #116946 0x0000000000841676 in Trigger::Trigger (this=0x2b79dc0, arg_cond=0x4ae81c0, arg_body=0x4af3600, arg_timeout_stmts=0x0, arg_timeout=0x0, arg_frame=0x8b612d0, arg_is_return=false, arg_location=0x4b4d280) at /mnt/hgfs/src/psdev/bro/src/Trigger.cc:108 > #116947 0x000000000083db0e in WhenStmt::Exec (this=0x4b3eba0, f=0x8b612d0, flow=@0x7ffde1aa3064) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:2166 > #116948 0x000000000083c17b in StmtList::Exec (this=0x4af4260, f=0x8b612d0, flow=@0x7ffde1aa3064) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:1764 > #116949 0x000000000083c17b in StmtList::Exec (this=0x4b56540, f=0x8b612d0, flow=@0x7ffde1aa3064) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:1764 > #116950 0x00000000007a649b in BroFunc::Call (this=0x3099030, args=0x82c33e0, parent=0x0) at /mnt/hgfs/src/psdev/bro/src/Func.cc:386 > #116951 0x000000000077f12e in EventHandler::Call (this=0x3084600, vl=0x82c33e0, no_remote=false) at /mnt/hgfs/src/psdev/bro/src/EventHandler.cc:80 > #116952 0x0000000000732965 in Event::Dispatch (this=0xb5004e0, no_remote=false) at /mnt/hgfs/src/psdev/bro/src/Event.h:50 > #116953 0x000000000077e85d in EventMgr::Dispatch (this=0xf66ee0) at /mnt/hgfs/src/psdev/bro/src/Event.cc:111 > #116954 0x000000000077e968 in EventMgr::Drain (this=0xf66ee0) at /mnt/hgfs/src/psdev/bro/src/Event.cc:128 > #116955 0x00000000007ddd66 in net_packet_dispatch (t=1442838074.400739, hdr=0x4d73140, pkt=0x7fb7db8622fc
, hdr_size=14, src_ps=0x4d73000) at /mnt/hgfs/src/psdev/bro/src/Net.cc:278 > #116956 0x0000000000af1ed6 in iosource::PktSrc::Process (this=0x4d73000) at /mnt/hgfs/src/psdev/bro/src/iosource/PktSrc.cc:411 > #116957 0x00000000007ddf6f in net_run () at /mnt/hgfs/src/psdev/bro/src/Net.cc:320 > #116958 0x00000000007319aa in main (argc=18, argv=0x7ffde1aa3af8) at /mnt/hgfs/src/psdev/bro/src/main.cc:1200 > ==== No reporter.log > ==== stderr.log > internal warning in /usr/local/bro/share/bro/base/frameworks/control/./main.bro, line 1: Discarded extraneous Broxygen comment: MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > internal warning in /usr/local/bro/share/bro/base/frameworks/control/./main.bro, line 1: Discarded extraneous Broxygen comment: GNU General Public License for more details. > internal warning in /usr/local/bro/share/bro/base/frameworks/control/./main.bro, line 1: Discarded extraneous Broxygen comment: You should have received a copy of the GNU General Public License > internal warning in /usr/local/bro/share/bro/base/frameworks/control/./main.bro, line 1: Discarded extraneous Broxygen comment: along with tcplog. If not, see . > listening on eth1, capture length 65535 bytes > processing suspended > processing continued > tcmalloc: large alloc 1562509312 bytes == 0x498f0000 @ 0x7fb85004b4ac 0x7fb85006b22c 0x73b0e5 0x815270 0x81627e 0x7437f8 0x742ddd 0x81788a 0x742b1b 0x848ab5 0x84a01a 0x81788a 0x845670 0x848b3b 0x84a01a 0x81788a 0x845670 0x846db0 0x84759e 0x81788a 0x845670 0x742c72 0x81788a 0x742b1b 0x848ab5 0x84a01a 0x81788a 0x845670 0x742c72 0x81788a 0x742b1b > /usr/local/bro/share/broctl/scripts/run-bro: line 85: 91861 Segmentation fault (core dumped) nohup ${pin_command} $pin_cpu $mybro "$@" > ---- > (gdb) frame 0 > #0 0x000000000081816b in Serializer::Write (this=0x7ffde1aa2d00, v=35329, tag=0xb752df "stype") > at /mnt/hgfs/src/psdev/bro/src/Serializer.h:57 > 57 DECLARE_IO(uint16) > (gdb) print *this > $8 = {_vptr.Serializer = 0xb7dc50, static MAGIC = 1112691540, static DATA_FORMAT_VERSION = 25, io = 0x0, format = 0x89def00, > current_cache = 0x0, error_descr = 0x0} > (gdb) print *this > $10 = {_vptr.Serializer = 0xb7dc50, static MAGIC = 1112691540, static DATA_FORMAT_VERSION = 25, io = 0x0, > format = 0x89def00, current_cache = 0x0, error_descr = 0x0} > (gdb) print *this->format > $11 = {_vptr.SerializationFormat = 0xb74dd0, static INITIAL_SIZE = 65536, static GROWTH_FACTOR = 2.5, > output = 0x498f0000 "\001", output_size = 1562499968, output_pos = 852829181, input = 0x0, input_len = 0, input_pos = 0, > bytes_written = 852829181, bytes_read = 0} > The stack trace and the problem seems to be similar to: > http://mailman.icsi.berkeley.edu/pipermail/bro/2015-March/008241.html -- This message was sent by Atlassian JIRA (v7.0.0-OD-06-002#70102) From robin at icir.org Mon Sep 21 08:26:45 2015 From: robin at icir.org (Robin Sommer) Date: Mon, 21 Sep 2015 08:26:45 -0700 Subject: [Bro-Dev] Asynchronous function calls Message-ID: <20150921152645.GP95299@icir.org> With Broker, we have the problem that a number of function calls operate asynchronously so that one needs to wrap them into "when" statements, which gets cumbersome quickly. One idea we had discussed in the past is adding synchronous versions with slightly different semantics (see [1] for a summary). However, the other day I came across a new feature in Python 3.5, and I'm now wondering if that could be a better route for Bro, too. In a nutshell, Python has added language support for co-routines. From [2]: "Inside of a coroutine body, the 'await' keyword can be used to make an expression suspend the execution of the coroutine and wait for some processing to complete." Example: data = await db.fetch('SELECT ...') See [2] for more. I think in Bro we could implement somehting like this through the same infrastructure that "when" uses (with some tweaks, maybe); but for user code it would be much nicer. Indeed, existing async BiFs, like for DNS lookups, could then use this as well. One challenge here is error handling: what to do if the function doesn't return / fails / times out? Another question would be performance: what if we have 1000s of these pending? (I don't think we know the answer for "when"-stmts either though ...) Robin [1] https://www.bro.org/development/projects/broker-extensions.html [2] http://www.infoq.com/news/2015/05/python-async-await -- Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin From vlad at grigorescu.org Mon Sep 21 08:56:42 2015 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Mon, 21 Sep 2015 10:56:42 -0500 Subject: [Bro-Dev] Advice on the PE Analyzer Message-ID: For Bro 2.5, I'd like to add some more functionality to the Windows Portable Executable analyzer. I think there's a lot of valuable data that could be extracted, but the format is rather challenging to work with. Some protocol pseudocode would be: > 0000: import_address_table is at 0010 > 0010: entry #1 is at 0030 > 0020: entry #2 is at 0050 > 0030: entry #1 address is at 0100 > 0040: entry #1 name is at 0110 > 0050: entry #2 address is at 0140 > 0060: entry #2 name is at 0120 Much of the data is simply pointers to offsets in the file where the actual data resides. My thought for parsing this is to write two helper functions in C++: > jump_to_next_interesting_offset() > // Skips to the offset of the next thing I would like to parse > get_data_context_at_current_offset() > // Get contextual information for how to parse the current data > // (e.g. this is the the address of entry #1 in the import address table). Does anyone have suggestions for what data structures I should use to store the necessary data? Storing the offsets shouldn't be very difficult, but each offset will need context associated with it in order to know how to parse it once the analyzer gets there, and how to associate the data residing there with data that's already been parsed. Thanks, --Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20150921/84c7e339/attachment.html From vlad at grigorescu.org Mon Sep 21 09:20:29 2015 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Mon, 21 Sep 2015 11:20:29 -0500 Subject: [Bro-Dev] [EXTERNAL] Re: [Bro] Logging VLAN IDs In-Reply-To: References: <20150417155524.GO55440@icir.org> <20150429235907.GH10338@icir.org> Message-ID: Apologies for resurrecting an old thread. I'm wondering if anyone has given any further thought to or done any work on this. While looking at BIT-1480 (adding ERSPAN decapsulation support), I was reminded of what a mess Sessions.cc currently is. I think moving towards passing a Packet structure around would help to simplify things a lot - possibly by breaking up the code into per-protocol classes. Curious to hear any thoughts. Thanks, --Vlad On Thu, May 7, 2015 at 4:17 PM, Thomas, Eric D wrote: > That sounds good! Both ideas seem to add an interesting level of > additional flexibility and analytic potential. > -- > Eric Thomas > edthoma at sandia.gov > > > > > On 4/29/15, 4:59 PM, "Robin Sommer" wrote: > > >What if we did a combination of what I suggested and your thoughts > >here? We carry link-level features through to script-land inside the > >connection record, and in addition allowed to transfer a custom subset > >over to the connection ID for hashing? The latter could be done later > >as a second step. > > > >Robin > > > >On Tue, Apr 28, 2015 at 18:32 +0000, you wrote: > > > >> Hi Robin, > >> > >> I thought more about your generalized idea and would like to follow up. > >>To > >> start, adding link-level features to the connection ID hash, while > >>perhaps > >> useful in some contexts, does not provide us the functionality we > >>desire. > >> I have an incoming feed of VLAN-tagged traffic (both VLAN and 802.1ah) > >> with perhaps dozens of different VLANs, and I would like to handle the > >> connections differently in scripts but also mainly in offline log > >>analysis > >> depending upon which VLANs the traffic is associated with. > >> > >> Initially I had proposed simply adding the VLAN Ids to the conn.log > >>file, > >> but that is certainly too specific of a solution. What are your thoughts > >> on exposing link-level features at the script layer for connections? For > >> example, if all observed VLAN tags for a connection were in a set > >>variable > >> of the script-level Connection record, I could then label my data by > >> matching VLAN Ids, then process them differently accordingly. Thoughts? > >> > > > > > >-- > >Robin Sommer * Broala, LLC * robin at broala.com * www.broala.com > > > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20150921/c39da385/attachment.html From jira at bro-tracker.atlassian.net Mon Sep 21 12:00:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Mon, 21 Sep 2015 14:00:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1483) broxygen ignores doc comments In-Reply-To: References: Message-ID: Daniel Thayer created BIT-1483: ---------------------------------- Summary: broxygen ignores doc comments Key: BIT-1483 URL: https://bro-tracker.atlassian.net/browse/BIT-1483 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Daniel Thayer Priority: Low Tried adding a documentation comment to an enum type, but broxygen ignores it. It seems the problem is the name "Event" (if I rename the type name, then the documentation comment is no longer ignored). Example from frameworks/input/main.bro: export { ## This line is ignored. type Event: enum { ## New data has been imported. EVENT_NEW = 0, ## Existing data has been changed. EVENT_CHANGED = 1, ## Previously existing data has been removed. EVENT_REMOVED = 2, }; -- This message was sent by Atlassian JIRA (v7.0.0-OD-06-002#70102) From jira at bro-tracker.atlassian.net Mon Sep 21 12:01:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Mon, 21 Sep 2015 14:01:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1483) broxygen ignores doc comments In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1483: ------------------------------- Description: Tried adding a documentation comment to an enum type, but broxygen ignores it. It seems the problem is the name "Event" (if I rename the type name, then the documentation comment is no longer ignored). Example from frameworks/input/main.bro: export { ## This line is ignored. type Event: enum { EVENT_NEW = 0, EVENT_CHANGED = 1, EVENT_REMOVED = 2, }; was: Tried adding a documentation comment to an enum type, but broxygen ignores it. It seems the problem is the name "Event" (if I rename the type name, then the documentation comment is no longer ignored). Example from frameworks/input/main.bro: export { ## This line is ignored. type Event: enum { ## New data has been imported. EVENT_NEW = 0, ## Existing data has been changed. EVENT_CHANGED = 1, ## Previously existing data has been removed. EVENT_REMOVED = 2, }; > broxygen ignores doc comments > ----------------------------- > > Key: BIT-1483 > URL: https://bro-tracker.atlassian.net/browse/BIT-1483 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > Priority: Low > > Tried adding a documentation comment to an enum type, but broxygen ignores it. > It seems the problem is the name "Event" (if I rename the type name, then > the documentation comment is no longer ignored). > Example from frameworks/input/main.bro: > export { > ## This line is ignored. > type Event: enum { > EVENT_NEW = 0, > EVENT_CHANGED = 1, > EVENT_REMOVED = 2, > }; -- This message was sent by Atlassian JIRA (v7.0.0-OD-06-002#70102) From robin at icir.org Mon Sep 21 15:50:47 2015 From: robin at icir.org (Robin Sommer) Date: Mon, 21 Sep 2015 15:50:47 -0700 Subject: [Bro-Dev] [EXTERNAL] Re: [Bro] Logging VLAN IDs In-Reply-To: References: <20150417155524.GO55440@icir.org> <20150429235907.GH10338@icir.org> Message-ID: <20150921225047.GD70576@icir.org> On Mon, Sep 21, 2015 at 11:20 -0500, you wrote: > I'm wondering if anyone has given any further thought to or done any work > on this. Yep, it's in place. :) See fb848f795de8ef22987ba01980ff65be1231b312. > was reminded of what a mess Sessions.cc currently is. I think moving > towards passing a Packet structure around would help to simplify > things a lot And that too: fe3579f1b4c82db3cd9cd6f372c1a5387bac24ac and c72d191ab5c960be94c9f516aa94ec214f54b0c7 Does that do what you're looking for? Robin -- Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin From vlad at grigorescu.org Mon Sep 21 20:48:22 2015 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Mon, 21 Sep 2015 22:48:22 -0500 Subject: [Bro-Dev] [EXTERNAL] Re: [Bro] Logging VLAN IDs In-Reply-To: <20150921225047.GD70576@icir.org> References: <20150417155524.GO55440@icir.org> <20150429235907.GH10338@icir.org> <20150921225047.GD70576@icir.org> Message-ID: Oooh, yes, thank you. I'm not sure how I missed that, but that looks nice. On Mon, Sep 21, 2015 at 5:50 PM, Robin Sommer wrote: > On Mon, Sep 21, 2015 at 11:20 -0500, you wrote: > > > I'm wondering if anyone has given any further thought to or done any work > > on this. > > Yep, it's in place. :) See fb848f795de8ef22987ba01980ff65be1231b312. > > > was reminded of what a mess Sessions.cc currently is. I think moving > > towards passing a Packet structure around would help to simplify > > things a lot > > And that too: fe3579f1b4c82db3cd9cd6f372c1a5387bac24ac and > c72d191ab5c960be94c9f516aa94ec214f54b0c7 > > Does that do what you're looking for? > > Robin > > -- > Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20150921/696927ef/attachment.html From noreply at bro.org Tue Sep 22 00:00:26 2015 From: noreply at bro.org (Merge Tracker) Date: Tue, 22 Sep 2015 00:00:26 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509220700.t8M70QZi032058@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ----------------------------------------------------------- BIT-1481 [1] Bro Daniel Thayer - 2015-09-20 - Normal some test canonifiers don't always read from stdin BIT-1479 [2] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [3] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [4] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [5] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [6] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ------------- ------------- ---------- --------------------------------------------------------------------------- #44 [7] bro yunzheng [8] 2015-09-18 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [9] #6 [10] bro-plugins jswaro [11] 2015-08-24 Adding initial conversion of TCPRS to a plugin [12] #1 [13] broctl J-Gras [14] 2015-09-11 Added support for packet fanout load balancing [15] #3 [16] packet-bricks shirkdog [17] 2015-09-21 Add a check for FreeBSD in lua_interface.c [18] [1] BIT-1481 https://bro-tracker.atlassian.net/browse/BIT-1481 [2] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [3] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [4] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [5] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [6] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [7] Pull Request #44 https://github.com/bro/bro/pull/44 [8] yunzheng https://github.com/yunzheng [9] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [10] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [11] jswaro https://github.com/jswaro [12] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [13] Pull Request #1 https://github.com/bro/broctl/pull/1 [14] J-Gras https://github.com/J-Gras [15] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config [16] Pull Request #3 https://github.com/bro/packet-bricks/pull/3 [17] shirkdog https://github.com/shirkdog [18] Merge Pull Request #3 with git pull --no-ff --no-commit https://github.com/shirkdog/packet-bricks.git master From johanna at icir.org Tue Sep 22 13:25:04 2015 From: johanna at icir.org (Johanna Amann) Date: Tue, 22 Sep 2015 13:25:04 -0700 Subject: [Bro-Dev] Advice on the PE Analyzer In-Reply-To: References: Message-ID: <20150922202504.GA77223@wifi79.sys.ICSI.Berkeley.EDU> On Mon, Sep 21, 2015 at 10:56:42AM -0500, Vlad Grigorescu wrote: > For Bro 2.5, I'd like to add some more functionality to the Windows > Portable Executable analyzer. I think there's a lot of valuable data that > could be extracted, but the format is rather challenging to work with. Some > protocol pseudocode would be: > > > 0000: import_address_table is at 0010 > > 0010: entry #1 is at 0030 > > 0020: entry #2 is at 0050 > > 0030: entry #1 address is at 0100 > > 0040: entry #1 name is at 0110 > > 0050: entry #2 address is at 0140 > > 0060: entry #2 name is at 0120 > > Much of the data is simply pointers to offsets in the file where the actual > data resides. My thought for parsing this is to write two helper functions > in C++: > > > jump_to_next_interesting_offset() > > // Skips to the offset of the next thing I would like to parse > > > get_data_context_at_current_offset() > > // Get contextual information for how to parse the current data > > // (e.g. this is the the address of entry #1 in the import address table). I think this generally sounds like a sound approach. One thing that might help with this, if you are not already aware of this - it is a tad tricky to get binpac to use your file analyzer subclass of PE, instead of the base BroFileAnalyzer class - the SSL analyzer shows and example on how to get binpac to do this. > Does anyone have suggestions for what data structures I should use to store > the necessary data? Storing the offsets shouldn't be very difficult, but > each offset will need context associated with it in order to know how to > parse it once the analyzer gets there, and how to associate the data > residing there with data that's already been parsed. This might be a tad naive - but would a std::priorityqueue containing a class, that has the offset (which is used for sorting) as well as all the contextual information that you have to store make sense? Generally - I think it would be really cool to have this feature in Bro :) Johanna From noreply at bro.org Wed Sep 23 00:00:33 2015 From: noreply at bro.org (Merge Tracker) Date: Wed, 23 Sep 2015 00:00:33 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509230700.t8N70XCG032667@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ----------------------------------------------------------- BIT-1481 [1] Bro Daniel Thayer - 2015-09-20 - Normal some test canonifiers don't always read from stdin BIT-1479 [2] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [3] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [4] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [5] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [6] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ------------- ------------- ---------- --------------------------------------------------------------------------- #44 [7] bro yunzheng [8] 2015-09-22 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [9] #6 [10] bro-plugins jswaro [11] 2015-08-24 Adding initial conversion of TCPRS to a plugin [12] #1 [13] broctl J-Gras [14] 2015-09-11 Added support for packet fanout load balancing [15] #3 [16] packet-bricks shirkdog [17] 2015-09-21 Add a check for FreeBSD in lua_interface.c [18] [1] BIT-1481 https://bro-tracker.atlassian.net/browse/BIT-1481 [2] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [3] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [4] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [5] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [6] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [7] Pull Request #44 https://github.com/bro/bro/pull/44 [8] yunzheng https://github.com/yunzheng [9] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [10] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [11] jswaro https://github.com/jswaro [12] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [13] Pull Request #1 https://github.com/bro/broctl/pull/1 [14] J-Gras https://github.com/J-Gras [15] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config [16] Pull Request #3 https://github.com/bro/packet-bricks/pull/3 [17] shirkdog https://github.com/shirkdog [18] Merge Pull Request #3 with git pull --no-ff --no-commit https://github.com/shirkdog/packet-bricks.git master From jira at bro-tracker.atlassian.net Wed Sep 23 11:32:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Wed, 23 Sep 2015 13:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1484) topic/dnthayer/doc-fixes In-Reply-To: References: Message-ID: Daniel Thayer created BIT-1484: ---------------------------------- Summary: topic/dnthayer/doc-fixes Key: BIT-1484 URL: https://bro-tracker.atlassian.net/browse/BIT-1484 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Daniel Thayer The branch "topic/dnthayer/doc-fixes" in the bro repo contains various doc fixes and improvements that I've collected over the past two months. These are mostly just small fixes or clarifications based on user questions on the mailing list. The most significant changes are to the input framework and the GeoIP documentation. -- This message was sent by Atlassian JIRA (v7.0.0-OD-06-002#70102) From jira at bro-tracker.atlassian.net Wed Sep 23 11:32:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Wed, 23 Sep 2015 13:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1484) topic/dnthayer/doc-fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1484: ------------------------------- Status: Merge Request (was: Open) > topic/dnthayer/doc-fixes > ------------------------ > > Key: BIT-1484 > URL: https://bro-tracker.atlassian.net/browse/BIT-1484 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > > The branch "topic/dnthayer/doc-fixes" in the bro repo contains various > doc fixes and improvements that I've collected over the past two months. > These are mostly just small fixes or clarifications based on user questions on > the mailing list. The most significant changes are to the input framework > and the GeoIP documentation. -- This message was sent by Atlassian JIRA (v7.0.0-OD-06-002#70102) From noreply at bro.org Thu Sep 24 00:00:26 2015 From: noreply at bro.org (Merge Tracker) Date: Thu, 24 Sep 2015 00:00:26 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509240700.t8O70Q6h016749@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ----------------------------------------------------------- BIT-1484 [1] Bro Daniel Thayer - 2015-09-23 - Normal topic/dnthayer/doc-fixes [2] BIT-1481 [3] Bro Daniel Thayer - 2015-09-20 - Normal some test canonifiers don't always read from stdin BIT-1479 [4] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [5] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [6] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [7] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [8] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ------------- ------------- ---------- ---------------------------------------------------------------------------- #44 [9] bro yunzheng [10] 2015-09-23 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [11] #6 [12] bro-plugins jswaro [13] 2015-08-24 Adding initial conversion of TCPRS to a plugin [14] #1 [15] broctl J-Gras [16] 2015-09-11 Added support for packet fanout load balancing [17] #3 [18] packet-bricks shirkdog [19] 2015-09-21 Add a check for FreeBSD in lua_interface.c [20] [1] BIT-1484 https://bro-tracker.atlassian.net/browse/BIT-1484 [2] doc-fixes https://github.com/bro/bro/tree/topic/dnthayer/doc-fixes [3] BIT-1481 https://bro-tracker.atlassian.net/browse/BIT-1481 [4] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [5] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [6] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [7] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [8] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [9] Pull Request #44 https://github.com/bro/bro/pull/44 [10] yunzheng https://github.com/yunzheng [11] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [12] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [13] jswaro https://github.com/jswaro [14] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [15] Pull Request #1 https://github.com/bro/broctl/pull/1 [16] J-Gras https://github.com/J-Gras [17] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config [18] Pull Request #3 https://github.com/bro/packet-bricks/pull/3 [19] shirkdog https://github.com/shirkdog [20] Merge Pull Request #3 with git pull --no-ff --no-commit https://github.com/shirkdog/packet-bricks.git master From noreply at bro.org Fri Sep 25 00:00:33 2015 From: noreply at bro.org (Merge Tracker) Date: Fri, 25 Sep 2015 00:00:33 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509250700.t8P70Xwt023303@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- ----------------------------------------------------------- BIT-1484 [1] Bro Daniel Thayer - 2015-09-23 - Normal topic/dnthayer/doc-fixes [2] BIT-1481 [3] Bro Daniel Thayer - 2015-09-20 - Normal some test canonifiers don't always read from stdin BIT-1479 [4] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [5] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [6] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [7] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [8] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ------------- ------------- ---------- ---------------------------------------------------------------------------- #44 [9] bro yunzheng [10] 2015-09-23 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [11] #6 [12] bro-plugins jswaro [13] 2015-08-24 Adding initial conversion of TCPRS to a plugin [14] #1 [15] broctl J-Gras [16] 2015-09-11 Added support for packet fanout load balancing [17] #3 [18] packet-bricks shirkdog [19] 2015-09-21 Add a check for FreeBSD in lua_interface.c [20] [1] BIT-1484 https://bro-tracker.atlassian.net/browse/BIT-1484 [2] doc-fixes https://github.com/bro/bro/tree/topic/dnthayer/doc-fixes [3] BIT-1481 https://bro-tracker.atlassian.net/browse/BIT-1481 [4] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [5] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [6] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [7] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [8] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [9] Pull Request #44 https://github.com/bro/bro/pull/44 [10] yunzheng https://github.com/yunzheng [11] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [12] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [13] jswaro https://github.com/jswaro [14] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [15] Pull Request #1 https://github.com/bro/broctl/pull/1 [16] J-Gras https://github.com/J-Gras [17] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config [18] Pull Request #3 https://github.com/bro/packet-bricks/pull/3 [19] shirkdog https://github.com/shirkdog [20] Merge Pull Request #3 with git pull --no-ff --no-commit https://github.com/shirkdog/packet-bricks.git master From jira at bro-tracker.atlassian.net Fri Sep 25 13:20:01 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 25 Sep 2015 15:20:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1485) add configure option to prevent building broker python bindings In-Reply-To: References: Message-ID: Daniel Thayer created BIT-1485: ---------------------------------- Summary: add configure option to prevent building broker python bindings Key: BIT-1485 URL: https://bro-tracker.atlassian.net/browse/BIT-1485 Project: Bro Issue Tracker Issue Type: Problem Components: Bro, Broker Reporter: Daniel Thayer There should be a configure option to prevent building the broker python bindings. Also, the summary output of configure should more clearly show whether or not pybroker will be built (for example, if you have an older version of swig, it's not easy to see the warning message about not being able to build python bindings). -- This message was sent by Atlassian JIRA (v7.0.0-OD-06-002#70102) From jira at bro-tracker.atlassian.net Fri Sep 25 13:21:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 25 Sep 2015 15:21:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1485) add configure option to prevent building broker python bindings In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22201#comment-22201 ] Daniel Thayer commented on BIT-1485: ------------------------------------ Branch "topic/dnthayer/configure" in the bro and broker repos addresses these issues. > add configure option to prevent building broker python bindings > --------------------------------------------------------------- > > Key: BIT-1485 > URL: https://bro-tracker.atlassian.net/browse/BIT-1485 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro, Broker > Reporter: Daniel Thayer > > There should be a configure option to prevent building the broker python bindings. > Also, the summary output of configure should more clearly show whether or not > pybroker will be built (for example, if you have an older version of swig, it's not easy > to see the warning message about not being able to build python bindings). -- This message was sent by Atlassian JIRA (v7.0.0-OD-06-002#70102) From jira at bro-tracker.atlassian.net Fri Sep 25 13:22:00 2015 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 25 Sep 2015 15:22:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1485) add configure option to prevent building broker python bindings In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1485: ------------------------------- Status: Merge Request (was: Open) > add configure option to prevent building broker python bindings > --------------------------------------------------------------- > > Key: BIT-1485 > URL: https://bro-tracker.atlassian.net/browse/BIT-1485 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro, Broker > Reporter: Daniel Thayer > > There should be a configure option to prevent building the broker python bindings. > Also, the summary output of configure should more clearly show whether or not > pybroker will be built (for example, if you have an older version of swig, it's not easy > to see the warning message about not being able to build python bindings). -- This message was sent by Atlassian JIRA (v7.0.0-OD-06-002#70102) From noreply at bro.org Sat Sep 26 00:00:23 2015 From: noreply at bro.org (Merge Tracker) Date: Sat, 26 Sep 2015 00:00:23 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509260700.t8Q70NLv021094@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- --------------------------------------------------------------- BIT-1485 [1] Bro,Broker Daniel Thayer - 2015-09-25 - Normal add configure option to prevent building broker python bindings BIT-1484 [2] Bro Daniel Thayer - 2015-09-23 - Normal topic/dnthayer/doc-fixes [3] BIT-1481 [4] Bro Daniel Thayer - 2015-09-20 - Normal some test canonifiers don't always read from stdin BIT-1479 [5] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [6] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [7] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [8] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [9] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title -------- ------------- ------------- ---------- ---------------------------------------------------------------------------- #44 [10] bro yunzheng [11] 2015-09-23 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [12] #6 [13] bro-plugins jswaro [14] 2015-08-24 Adding initial conversion of TCPRS to a plugin [15] #1 [16] broctl J-Gras [17] 2015-09-11 Added support for packet fanout load balancing [18] #3 [19] packet-bricks shirkdog [20] 2015-09-21 Add a check for FreeBSD in lua_interface.c [21] [1] BIT-1485 https://bro-tracker.atlassian.net/browse/BIT-1485 [2] BIT-1484 https://bro-tracker.atlassian.net/browse/BIT-1484 [3] doc-fixes https://github.com/bro/bro/tree/topic/dnthayer/doc-fixes [4] BIT-1481 https://bro-tracker.atlassian.net/browse/BIT-1481 [5] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [6] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [7] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [8] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [9] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [10] Pull Request #44 https://github.com/bro/bro/pull/44 [11] yunzheng https://github.com/yunzheng [12] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [13] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [14] jswaro https://github.com/jswaro [15] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [16] Pull Request #1 https://github.com/bro/broctl/pull/1 [17] J-Gras https://github.com/J-Gras [18] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config [19] Pull Request #3 https://github.com/bro/packet-bricks/pull/3 [20] shirkdog https://github.com/shirkdog [21] Merge Pull Request #3 with git pull --no-ff --no-commit https://github.com/shirkdog/packet-bricks.git master From noreply at bro.org Sun Sep 27 00:00:27 2015 From: noreply at bro.org (Merge Tracker) Date: Sun, 27 Sep 2015 00:00:27 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509270700.t8R70Rt7004208@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- --------------------------------------------------------------- BIT-1485 [1] Bro,Broker Daniel Thayer - 2015-09-25 - Normal add configure option to prevent building broker python bindings BIT-1484 [2] Bro Daniel Thayer - 2015-09-23 - Normal topic/dnthayer/doc-fixes [3] BIT-1481 [4] Bro Daniel Thayer - 2015-09-20 - Normal some test canonifiers don't always read from stdin BIT-1479 [5] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [6] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [7] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [8] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [9] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title -------- ------------- ------------- ---------- ---------------------------------------------------------------------------- #44 [10] bro yunzheng [11] 2015-09-23 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [12] #6 [13] bro-plugins jswaro [14] 2015-08-24 Adding initial conversion of TCPRS to a plugin [15] #1 [16] broctl J-Gras [17] 2015-09-11 Added support for packet fanout load balancing [18] #3 [19] packet-bricks shirkdog [20] 2015-09-21 Add a check for FreeBSD in lua_interface.c [21] [1] BIT-1485 https://bro-tracker.atlassian.net/browse/BIT-1485 [2] BIT-1484 https://bro-tracker.atlassian.net/browse/BIT-1484 [3] doc-fixes https://github.com/bro/bro/tree/topic/dnthayer/doc-fixes [4] BIT-1481 https://bro-tracker.atlassian.net/browse/BIT-1481 [5] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [6] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [7] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [8] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [9] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [10] Pull Request #44 https://github.com/bro/bro/pull/44 [11] yunzheng https://github.com/yunzheng [12] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [13] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [14] jswaro https://github.com/jswaro [15] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [16] Pull Request #1 https://github.com/bro/broctl/pull/1 [17] J-Gras https://github.com/J-Gras [18] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config [19] Pull Request #3 https://github.com/bro/packet-bricks/pull/3 [20] shirkdog https://github.com/shirkdog [21] Merge Pull Request #3 with git pull --no-ff --no-commit https://github.com/shirkdog/packet-bricks.git master From ayenadedg at gmail.com Sun Sep 27 02:31:38 2015 From: ayenadedg at gmail.com (Edgar D. AYENA) Date: Sun, 27 Sep 2015 10:31:38 +0100 Subject: [Bro-Dev] Bro-Admin_HELP Message-ID: Bonjour la communaut?, Je voudrais un script bro qui me permettra de d?tecter les domaines dans les mails. Merci d'avance. -- Cordialement, ------ Edgar D. AYENA, ayenadedg at gmail.com From jira at bro-tracker.atlassian.net Sun Sep 27 12:34:01 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Sun, 27 Sep 2015 14:34:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22300#comment-22300 ] Michal Purzynski commented on BIT-1363: --------------------------------------- After talking with some people who implemented both libpcap based and raw af_packet functionality recently and testing it myself, I've learned one cannot simply add fanout options to a socket services by libpcap and expect it to work. If we want fanout we have to use af_packet directly. Libpcap when opened by multiple processes will deliver the same packets to each of them. Adding fanout changes nothing. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-06-002#70102) From noreply at bro.org Mon Sep 28 00:00:29 2015 From: noreply at bro.org (Merge Tracker) Date: Mon, 28 Sep 2015 00:00:29 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509280700.t8S70TSw003002@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- --------------------------------------------------------------- BIT-1485 [1] Bro,Broker Daniel Thayer - 2015-09-25 - Normal add configure option to prevent building broker python bindings BIT-1484 [2] Bro Daniel Thayer - 2015-09-23 - Normal topic/dnthayer/doc-fixes [3] BIT-1481 [4] Bro Daniel Thayer - 2015-09-20 - Normal some test canonifiers don't always read from stdin BIT-1479 [5] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [6] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [7] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [8] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [9] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title -------- ------------- ------------- ---------- ---------------------------------------------------------------------------- #44 [10] bro yunzheng [11] 2015-09-23 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [12] #6 [13] bro-plugins jswaro [14] 2015-08-24 Adding initial conversion of TCPRS to a plugin [15] #1 [16] broctl J-Gras [17] 2015-09-11 Added support for packet fanout load balancing [18] #3 [19] packet-bricks shirkdog [20] 2015-09-21 Add a check for FreeBSD in lua_interface.c [21] [1] BIT-1485 https://bro-tracker.atlassian.net/browse/BIT-1485 [2] BIT-1484 https://bro-tracker.atlassian.net/browse/BIT-1484 [3] doc-fixes https://github.com/bro/bro/tree/topic/dnthayer/doc-fixes [4] BIT-1481 https://bro-tracker.atlassian.net/browse/BIT-1481 [5] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [6] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [7] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [8] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [9] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [10] Pull Request #44 https://github.com/bro/bro/pull/44 [11] yunzheng https://github.com/yunzheng [12] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [13] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [14] jswaro https://github.com/jswaro [15] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [16] Pull Request #1 https://github.com/bro/broctl/pull/1 [17] J-Gras https://github.com/J-Gras [18] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config [19] Pull Request #3 https://github.com/bro/packet-bricks/pull/3 [20] shirkdog https://github.com/shirkdog [21] Merge Pull Request #3 with git pull --no-ff --no-commit https://github.com/shirkdog/packet-bricks.git master From jira at bro-tracker.atlassian.net Mon Sep 28 02:08:01 2015 From: jira at bro-tracker.atlassian.net (Frank Meier (JIRA)) Date: Mon, 28 Sep 2015 04:08:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-528) Python 3 compatibility In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Meier updated BIT-528: ---------------------------- Attachment: pybroker.diff > Python 3 compatibility > ---------------------- > > Key: BIT-528 > URL: https://bro-tracker.atlassian.net/browse/BIT-528 > Project: Bro Issue Tracker > Issue Type: Task > Components: BroControl > Reporter: Robin Sommer > Fix For: 2.4 > > Attachments: pybroker.diff > > > We should make sure that BroControl (and other Pytjon pieces we ship > run fine with Python 3.x). -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 02:08:01 2015 From: jira at bro-tracker.atlassian.net (Frank Meier (JIRA)) Date: Mon, 28 Sep 2015 04:08:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-528) Python 3 compatibility In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22400#comment-22400 ] Frank Meier commented on BIT-528: --------------------------------- When trying to compile current version from git with python 3 I get this error: [ 9%] Building CXX object aux/broker/bindings/python/CMakeFiles/_pybroker.dir/pybrokerPYTHON_wrap.cxx.o bro/build/aux/broker/bindings/python/pybrokerPYTHON_wrap.cxx: In function ?PyObject* _wrap_frontend_request__SWIG_1(PyObject*, PyObject*)?: bro/build/aux/broker/bindings/python/pybrokerPYTHON_wrap.cxx:39324:40: error: ?PyInt_AsSsize_t? was not declared in this scope To solve this one could use the following define in pybroker.i : #if PY_MAJOR_VERSION >= 3 #define PyInt_AsSsize_t PyLong_AsSsize_t #endif There are still a lot of warnings about uninitialized argv[0], but it seems to work. Perhaps this could better be solved using Swig, but I didn't find out how (-py3 does not help). > Python 3 compatibility > ---------------------- > > Key: BIT-528 > URL: https://bro-tracker.atlassian.net/browse/BIT-528 > Project: Bro Issue Tracker > Issue Type: Task > Components: BroControl > Reporter: Robin Sommer > Fix For: 2.4 > > Attachments: pybroker.diff > > > We should make sure that BroControl (and other Pytjon pieces we ship > run fine with Python 3.x). -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 04:02:00 2015 From: jira at bro-tracker.atlassian.net (Kris Nielander (JIRA)) Date: Mon, 28 Sep 2015 06:02:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22401#comment-22401 ] Kris Nielander commented on BIT-1363: ------------------------------------- I am keen to find the origin of the issue. I have been patching fanout into Bro for some time and I never came across these issues (other than not specifying the ID correctly). Did you try running the fanout example code from hxxps://www.kernel.org/doc/Documentation/networking/packet_mmap.txt ? I can imagine that options set by libpcap don't do well with fanout, but essentially the patch operates on the (lower) socket layer. Perhaps some additional code checks need to be done, prior to moving to a separate AF_PACKET source implementation. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 04:21:01 2015 From: jira at bro-tracker.atlassian.net (Jan Grashoefer (JIRA)) Date: Mon, 28 Sep 2015 06:21:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Grashoefer updated BIT-1363: -------------------------------- Attachment: pcap.c > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > Attachments: pcap.c > > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 04:24:00 2015 From: jira at bro-tracker.atlassian.net (Jan Grashoefer (JIRA)) Date: Mon, 28 Sep 2015 06:24:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22402#comment-22402 ] Jan Grashoefer commented on BIT-1363: ------------------------------------- Hi, I experienced the same issues and wrote a minimal example using libpcap and setsockopt, as I suspected it to interfere. Based on [http://www.binarytides.com/packet-sniffer-code-c-libpcap-linux-sockets/] and [https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt] I came to the attached result: [^pcap.c] With this example I was able to reproduce the behavior: It forks 4 processes and for each creates a log (.log) with source/destination address (ordered) and port if available. All in all I came to the same conclusion as Michal. Therefore I am trying to write a small POC of an AF_Packet plugin for Bro. If you think you can fix the issue using libpcap I would be very curious about. Maybe you can keep us up to date on your research. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > Attachments: pcap.c > > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 04:25:01 2015 From: jira at bro-tracker.atlassian.net (Jan Grashoefer (JIRA)) Date: Mon, 28 Sep 2015 06:25:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22402#comment-22402 ] Jan Grashoefer edited comment on BIT-1363 at 9/28/15 6:24 AM: -------------------------------------------------------------- Hi, I experienced the same issues and wrote a minimal example using libpcap and setsockopt, as I suspected it to interfere. Based on [http://www.binarytides.com/packet-sniffer-code-c-libpcap-linux-sockets/] and [https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt] I came to the attached result: [^pcap.c] With this example I was able to reproduce the behavior: It forks 4 processes and for each creates a log (.log) with source/destination address (ordered) and port if available. All in all I came to the same conclusion as Michal. Therefore I am trying to write a small POC of an AF_Packet plugin for Bro. If you think you can fix the issue using libpcap I would be very curious about. Maybe you can keep us up to date about your research. was (Author: jgras): Hi, I experienced the same issues and wrote a minimal example using libpcap and setsockopt, as I suspected it to interfere. Based on [http://www.binarytides.com/packet-sniffer-code-c-libpcap-linux-sockets/] and [https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt] I came to the attached result: [^pcap.c] With this example I was able to reproduce the behavior: It forks 4 processes and for each creates a log (.log) with source/destination address (ordered) and port if available. All in all I came to the same conclusion as Michal. Therefore I am trying to write a small POC of an AF_Packet plugin for Bro. If you think you can fix the issue using libpcap I would be very curious about. Maybe you can keep us up to date on your research. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > Attachments: pcap.c > > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 04:32:00 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Mon, 28 Sep 2015 06:32:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22403#comment-22403 ] Michal Purzynski commented on BIT-1363: --------------------------------------- To be honest, we will spend more time trying to force libpcap to do something than writing a Bro AF_PACKET plugin. The later seems to be very clean, too. https://github.com/bro/bro-plugins/tree/master/netmap https://github.com/bro/bro-plugins/tree/master/pf_ring > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > Attachments: pcap.c > > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 08:31:00 2015 From: jira at bro-tracker.atlassian.net (Gabriel Dinkins (JIRA)) Date: Mon, 28 Sep 2015 10:31:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1486) Bro crashes when trying to Start In-Reply-To: References: Message-ID: Gabriel Dinkins created BIT-1486: ------------------------------------ Summary: Bro crashes when trying to Start Key: BIT-1486 URL: https://bro-tracker.atlassian.net/browse/BIT-1486 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.4 Environment: It's on a Centos 6 OS version and we are in the process of transitioning for an onboard NIC to a Myricom 10G fiber interface card. Reporter: Gabriel Dinkins Priority: Critical Upon trying to start the Bro IDS software it continually crashes. Upon checking the "diag" it states: ==== stderr.log fatal error: problem with interface p3p1 (p3p1: no IPv4 address assigned) -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 08:56:01 2015 From: jira at bro-tracker.atlassian.net (Kris Nielander (JIRA)) Date: Mon, 28 Sep 2015 10:56:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22404#comment-22404 ] Kris Nielander edited comment on BIT-1363 at 9/28/15 10:55 AM: --------------------------------------------------------------- I wouldn't mind putting some more effort into this to bring it to a separate, cleaner module. was (Author: krisnielander): I wouldn't mind putting some more effort into this to bring it to separate, cleaner module. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > Attachments: pcap.c > > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 08:56:01 2015 From: jira at bro-tracker.atlassian.net (Kris Nielander (JIRA)) Date: Mon, 28 Sep 2015 10:56:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22404#comment-22404 ] Kris Nielander commented on BIT-1363: ------------------------------------- I wouldn't mind putting some more effort into this to bring it to separate, cleaner module. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > Attachments: pcap.c > > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 09:03:00 2015 From: jira at bro-tracker.atlassian.net (Jan Grashoefer (JIRA)) Date: Mon, 28 Sep 2015 11:03:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22405#comment-22405 ] Jan Grashoefer commented on BIT-1363: ------------------------------------- I have already started writing a POC for a plugin. In case it works as expected I am going to add TPACKET_V3 support. As I am not used to write C/C++ code I would be glad if you can help review/test my code. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > Attachments: pcap.c > > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 09:26:00 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Mon, 28 Sep 2015 11:26:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22406#comment-22406 ] Michal Purzynski commented on BIT-1363: --------------------------------------- I'm happy to review the code and test it. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > Attachments: pcap.c > > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Mon Sep 28 16:14:01 2015 From: jira at bro-tracker.atlassian.net (Michal Purzynski (JIRA)) Date: Mon, 28 Sep 2015 18:14:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1363) Clustered AF_PACKET support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22407#comment-22407 ] Michal Purzynski commented on BIT-1363: --------------------------------------- Kris, I've modified the example from the kernel documentation to support FANOUT and it works like it should. So it's definitely libpcap being the issue here. > Clustered AF_PACKET support > --------------------------- > > Key: BIT-1363 > URL: https://bro-tracker.atlassian.net/browse/BIT-1363 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Michal Purzynski > Attachments: pcap.c > > > Let's have a support for packet capture with the AF_PACKET sockets in multi worker configuration. > Bro can use a single worker with af_packet, I have tested and it works, but having a direct support for multi-worker load balancing would allow to avoid the pf_ring for many deployments with the traffic level where DNA / ZC / Myricom / DAG is not required. -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From noreply at bro.org Tue Sep 29 00:00:23 2015 From: noreply at bro.org (Merge Tracker) Date: Tue, 29 Sep 2015 00:00:23 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509290700.t8T70NYC017689@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ---------- ---------- ------------- ---------- --------------------------------------------------------------- BIT-1485 [1] Bro,Broker Daniel Thayer - 2015-09-25 - Normal add configure option to prevent building broker python bindings BIT-1484 [2] Bro Daniel Thayer - 2015-09-23 - Normal topic/dnthayer/doc-fixes [3] BIT-1481 [4] Bro Daniel Thayer - 2015-09-20 - Normal some test canonifiers don't always read from stdin BIT-1479 [5] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [6] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [7] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [8] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [9] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title -------- ------------- ------------- ---------- ---------------------------------------------------------------------------- #44 [10] bro yunzheng [11] 2015-09-23 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [12] #6 [13] bro-plugins jswaro [14] 2015-08-24 Adding initial conversion of TCPRS to a plugin [15] #1 [16] broctl J-Gras [17] 2015-09-11 Added support for packet fanout load balancing [18] #3 [19] packet-bricks shirkdog [20] 2015-09-21 Add a check for FreeBSD in lua_interface.c [21] [1] BIT-1485 https://bro-tracker.atlassian.net/browse/BIT-1485 [2] BIT-1484 https://bro-tracker.atlassian.net/browse/BIT-1484 [3] doc-fixes https://github.com/bro/bro/tree/topic/dnthayer/doc-fixes [4] BIT-1481 https://bro-tracker.atlassian.net/browse/BIT-1481 [5] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [6] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [7] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [8] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [9] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [10] Pull Request #44 https://github.com/bro/bro/pull/44 [11] yunzheng https://github.com/yunzheng [12] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [13] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [14] jswaro https://github.com/jswaro [15] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [16] Pull Request #1 https://github.com/bro/broctl/pull/1 [17] J-Gras https://github.com/J-Gras [18] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config [19] Pull Request #3 https://github.com/bro/packet-bricks/pull/3 [20] shirkdog https://github.com/shirkdog [21] Merge Pull Request #3 with git pull --no-ff --no-commit https://github.com/shirkdog/packet-bricks.git master From jira at bro-tracker.atlassian.net Tue Sep 29 09:30:01 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 29 Sep 2015 11:30:01 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1485) add configure option to prevent building broker python bindings In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1485: --------------------------------- Assignee: Robin Sommer > add configure option to prevent building broker python bindings > --------------------------------------------------------------- > > Key: BIT-1485 > URL: https://bro-tracker.atlassian.net/browse/BIT-1485 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro, Broker > Reporter: Daniel Thayer > Assignee: Robin Sommer > > There should be a configure option to prevent building the broker python bindings. > Also, the summary output of configure should more clearly show whether or not > pybroker will be built (for example, if you have an older version of swig, it's not easy > to see the warning message about not being able to build python bindings). -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Tue Sep 29 09:48:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 29 Sep 2015 11:48:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1484) topic/dnthayer/doc-fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1484: --------------------------------- Assignee: Robin Sommer > topic/dnthayer/doc-fixes > ------------------------ > > Key: BIT-1484 > URL: https://bro-tracker.atlassian.net/browse/BIT-1484 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > Assignee: Robin Sommer > > The branch "topic/dnthayer/doc-fixes" in the bro repo contains various > doc fixes and improvements that I've collected over the past two months. > These are mostly just small fixes or clarifications based on user questions on > the mailing list. The most significant changes are to the input framework > and the GeoIP documentation. -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From jira at bro-tracker.atlassian.net Tue Sep 29 09:53:00 2015 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 29 Sep 2015 11:53:00 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1481) some test canonifiers don't always read from stdin In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1481: --------------------------------- Assignee: Robin Sommer > some test canonifiers don't always read from stdin > -------------------------------------------------- > > Key: BIT-1481 > URL: https://bro-tracker.atlassian.net/browse/BIT-1481 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > Assignee: Robin Sommer > > Some of the test canonifier scripts being used in the Bro test suite > cannot reliably be combined with other canonifiers in a pipeline. > For example, this works: > TEST_DIFF_CANONIFIER="diff-remove-x509-names | diff-remove-timestamps" > but switching the order of these canonifiers does not work: > TEST_DIFF_CANONIFIER="diff-remove-timestamps | diff-remove-x509-names" -- This message was sent by Atlassian JIRA (v7.0.0-OD-07-011#70107) From noreply at bro.org Wed Sep 30 00:00:23 2015 From: noreply at bro.org (Merge Tracker) Date: Wed, 30 Sep 2015 00:00:23 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201509300700.t8U70NDp000525@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ------------ ---------- ------------- ---------- --------------------------------------------------------------- BIT-1485 [1] Bro,Broker Daniel Thayer Robin Sommer 2015-09-29 - Normal add configure option to prevent building broker python bindings BIT-1484 [2] Bro Daniel Thayer Robin Sommer 2015-09-29 - Normal topic/dnthayer/doc-fixes [3] BIT-1481 [4] Bro Daniel Thayer Robin Sommer 2015-09-29 - Normal some test canonifiers don't always read from stdin BIT-1479 [5] Bro scampbell - 2015-09-16 - Normal seek functionality in RAW reader does not go to end of file BIT-1476 [6] BTest Daniel Thayer - 2015-09-13 - Normal btest-diff can generate too much output when a test fails BIT-1470 [7] Bro Wendy Edwards - 2015-09-11 2.5 Low Implemented Functions in Notice Framework BIT-1336 [8] Bro Vlad Grigorescu - 2015-09-04 2.5 Trivial ElasticSearch indices in UTC Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ---------------------------------------------------- 24ecb35 [9] bro-testing Vlad Grigorescu 2015-09-10 Add README.rst -> README symlink. Addresses BIT-1413 Open GitHub Pull Requests ========================= Issue Component User Updated Title -------- ------------- ------------- ---------- ---------------------------------------------------------------------------- #44 [10] bro yunzheng [11] 2015-09-23 Fixed parsing of V_ASN1_GENERALIZEDTIME timestamps in x509 certificates [12] #6 [13] bro-plugins jswaro [14] 2015-08-24 Adding initial conversion of TCPRS to a plugin [15] #1 [16] broctl J-Gras [17] 2015-09-11 Added support for packet fanout load balancing [18] #3 [19] packet-bricks shirkdog [20] 2015-09-21 Add a check for FreeBSD in lua_interface.c [21] [1] BIT-1485 https://bro-tracker.atlassian.net/browse/BIT-1485 [2] BIT-1484 https://bro-tracker.atlassian.net/browse/BIT-1484 [3] doc-fixes https://github.com/bro/bro/tree/topic/dnthayer/doc-fixes [4] BIT-1481 https://bro-tracker.atlassian.net/browse/BIT-1481 [5] BIT-1479 https://bro-tracker.atlassian.net/browse/BIT-1479 [6] BIT-1476 https://bro-tracker.atlassian.net/browse/BIT-1476 [7] BIT-1470 https://bro-tracker.atlassian.net/browse/BIT-1470 [8] BIT-1336 https://bro-tracker.atlassian.net/browse/BIT-1336 [9] 24ecb35 https://github.com/bro/bro-testing/commit/24ecb35f121e473bf7ff8e66b2e0c2ac68b4e6c0 [10] Pull Request #44 https://github.com/bro/bro/pull/44 [11] yunzheng https://github.com/yunzheng [12] Merge Pull Request #44 with git pull --no-ff --no-commit https://github.com/yunzheng/bro.git topic/x509-generalizedtime [13] Pull Request #6 https://github.com/bro/bro-plugins/pull/6 [14] jswaro https://github.com/jswaro [15] Merge Pull Request #6 with git pull --no-ff --no-commit https://github.com/jswaro/bro-plugins.git topic/jswaro/feature/initial-tcprs-plugin [16] Pull Request #1 https://github.com/bro/broctl/pull/1 [17] J-Gras https://github.com/J-Gras [18] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config [19] Pull Request #3 https://github.com/bro/packet-bricks/pull/3 [20] shirkdog https://github.com/shirkdog [21] Merge Pull Request #3 with git pull --no-ff --no-commit https://github.com/shirkdog/packet-bricks.git master