From noreply at bro.org Fri Nov 1 00:00:16 2013 From: noreply at bro.org (Merge Tracker) Date: Fri, 1 Nov 2013 00:00:16 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311010700.rA170GRX018083@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ---------------------------------------------------- f0d687b [1] broctl Daniel Thayer 2013-10-31 Add another warning message when a host is not alive [1] f0d687b https://github.com/bro/broctl/commit/f0d687b6d21b36a2bc3b68f6bb7b2cd8aecb4d55 From jsiwek at illinois.edu Tue Nov 5 10:35:39 2013 From: jsiwek at illinois.edu (Siwek, Jonathan Luke) Date: Tue, 5 Nov 2013 18:35:39 +0000 Subject: [Bro-Dev] [Bro-Commits] [git/bro] fastpath: Update VirusTotal URL to work with changes to their website. (0977983) In-Reply-To: <201311051736.rA5Hacta014891@bro-ids.icir.org> References: <201311051736.rA5Hacta014891@bro-ids.icir.org> Message-ID: Maybe it would be helpful if the URL format string is something a user can redef? - Jon On Nov 5, 2013, at 11:36 AM, Vlad Grigorescu wrote: > Repository : ssh://git at bro-ids.icir.org/bro > > On branch : fastpath > Link : https://github.com/bro/bro/commit/09779836cbbea6744114fba67bf0aa277cce4131 > >> --------------------------------------------------------------- > > commit 09779836cbbea6744114fba67bf0aa277cce4131 > Author: Vlad Grigorescu > Date: Tue Nov 5 12:06:33 2013 -0500 > > Update VirusTotal URL to work with changes to their website. > > >> --------------------------------------------------------------- > > 09779836cbbea6744114fba67bf0aa277cce4131 > scripts/policy/frameworks/files/detect-MHR.bro | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/policy/frameworks/files/detect-MHR.bro b/scripts/policy/frameworks/files/detect-MHR.bro > index 5ed8715..753372e 100644 > --- a/scripts/policy/frameworks/files/detect-MHR.bro > +++ b/scripts/policy/frameworks/files/detect-MHR.bro > @@ -48,7 +48,7 @@ event file_hash(f: fa_file, kind: string, hash: string) > if ( mhr_detect_rate >= notice_threshold ) > { > local message = fmt("Malware Hash Registry Detection rate: %d%% Last seen: %s", mhr_detect_rate, readable_first_detected); > - local virustotal_url = fmt("https://www.virustotal.com/en/file/%s/analysis/", hash); > + local virustotal_url = fmt("https://www.virustotal.com/en/search/?query=%s", hash); > NOTICE([$note=Match, $msg=message, $sub=virustotal_url, $f=f]); > } > } > > _______________________________________________ > bro-commits mailing list > bro-commits at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-commits > From vladg at cmu.edu Tue Nov 5 11:13:29 2013 From: vladg at cmu.edu (Vlad Grigorescu) Date: Tue, 5 Nov 2013 19:13:29 +0000 Subject: [Bro-Dev] [Bro-Commits] [git/bro] fastpath: Update VirusTotal URL to work with changes to their website. (0977983) In-Reply-To: <27076_1383676547_rA5IZjsx029456_ADF9D039-B2B5-4F99-A879-4B08CB3F2689@illinois.edu> References: <201311051736.rA5Hacta014891@bro-ids.icir.org> <27076_1383676547_rA5IZjsx029456_ADF9D039-B2B5-4F99-A879-4B08CB3F2689@illinois.edu> Message-ID: <72BE28C0-E24F-4721-9E33-42B1E2D05650@andrew.cmu.edu> Yeah, I was thinking about that. I'll make that change in a bit. --Vlad On Nov 5, 2013, at 1:35 PM, Siwek, Jonathan Luke wrote: > Maybe it would be helpful if the URL format string is something a user can redef? > > - Jon > > > On Nov 5, 2013, at 11:36 AM, Vlad Grigorescu wrote: > >> Repository : ssh://git at bro-ids.icir.org/bro >> >> On branch : fastpath >> Link : https://github.com/bro/bro/commit/09779836cbbea6744114fba67bf0aa277cce4131 >> >>> --------------------------------------------------------------- >> >> commit 09779836cbbea6744114fba67bf0aa277cce4131 >> Author: Vlad Grigorescu >> Date: Tue Nov 5 12:06:33 2013 -0500 >> >> Update VirusTotal URL to work with changes to their website. >> >> >>> --------------------------------------------------------------- >> >> 09779836cbbea6744114fba67bf0aa277cce4131 >> scripts/policy/frameworks/files/detect-MHR.bro | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/scripts/policy/frameworks/files/detect-MHR.bro b/scripts/policy/frameworks/files/detect-MHR.bro >> index 5ed8715..753372e 100644 >> --- a/scripts/policy/frameworks/files/detect-MHR.bro >> +++ b/scripts/policy/frameworks/files/detect-MHR.bro >> @@ -48,7 +48,7 @@ event file_hash(f: fa_file, kind: string, hash: string) >> if ( mhr_detect_rate >= notice_threshold ) >> { >> local message = fmt("Malware Hash Registry Detection rate: %d%% Last seen: %s", mhr_detect_rate, readable_first_detected); >> - local virustotal_url = fmt("https://www.virustotal.com/en/file/%s/analysis/", hash); >> + local virustotal_url = fmt("https://www.virustotal.com/en/search/?query=%s", hash); >> NOTICE([$note=Match, $msg=message, $sub=virustotal_url, $f=f]); >> } >> } >> >> _______________________________________________ >> bro-commits mailing list >> bro-commits at bro.org >> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-commits >> > > > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev From noreply at bro.org Wed Nov 6 00:00:16 2013 From: noreply at bro.org (Merge Tracker) Date: Wed, 6 Nov 2013 00:00:16 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311060800.rA680GQS005690@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- --------------- --------------- ---------- ------------------------------------------------------------ 8ad2ab4 [1] bro Vlad Grigorescu 2013-11-05 Change MHR notice sub message URL to a redef. 0977983 [2] bro Vlad Grigorescu 2013-11-05 Update VirusTotal URL to work with changes to their website. b110b8c [3] broccoli-python Bernhard Amann 2013-11-04 Installation section was missing necessary steps 92d3a29 [4] broctl Daniel Thayer 2013-11-04 Improve the check-pid helper script [1] 8ad2ab4 https://github.com/bro/bro/commit/8ad2ab44e2f077d20bbb5142a97b80fdf0d7a40c [2] 0977983 https://github.com/bro/bro/commit/09779836cbbea6744114fba67bf0aa277cce4131 [3] b110b8c https://github.com/bro/broccoli-python/commit/b110b8c6bbeecb105e719756d6e00d5e9cf5baac [4] 92d3a29 https://github.com/bro/broctl/commit/92d3a29679eddcc3f463d43914af5ac92a71fa54 From seth at icir.org Wed Nov 6 11:02:41 2013 From: seth at icir.org (Seth Hall) Date: Wed, 6 Nov 2013 14:02:41 -0500 Subject: [Bro-Dev] Failing tests? Message-ID: <028E0F4F-ABDA-48CC-B0E8-61B7D9C72C93@icir.org> Are other people seeing these tests fails? [ 34%] doc.sphinx.connection-record-01 ... failed [ 34%] doc.sphinx.connection-record-02 ... failed [ 35%] doc.sphinx.data_struct_table_complex ... failed [ 35%] doc.sphinx.data_struct_record_01 ... failed [ 35%] doc.sphinx.data_struct_record_02 ... failed [ 35%] doc.sphinx.data_struct_set_declaration ... failed [ 35%] doc.sphinx.data_struct_table_declaration ... failed [ 35%] doc.sphinx.data_struct_vector_declaration ... failed [ 36%] doc.sphinx.data_struct_vector_iter ... failed [ 36%] doc.sphinx.data_type_const.bro ... failed [ 36%] doc.sphinx.data_type_pattern ... failed [ 36%] doc.sphinx.data_type_interval ... failed [ 36%] doc.sphinx.data_type_pattern_02 ... failed [ 36%] doc.sphinx.data_type_subnets ... failed [ 37%] doc.sphinx.file-analysis-01 ... failed [ 37%] doc.sphinx.data_type_time ... failed [ 37%] doc.sphinx.file-analysis-02 ... failed [ 37%] doc.sphinx.framework_logging_factorial ... failed [ 38%] doc.sphinx.file-analysis-03 ... failed [ 38%] doc.sphinx.framework_logging_factorial-2 ... failed [ 39%] doc.sphinx.framework_logging_factorial-3 ... failed [ 47%] doc.sphinx.using_bro ? failed  I *think* the problem might just be that the baselines aren't committed for these. .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20131106/1bf702bb/attachment.bin From dnthayer at illinois.edu Wed Nov 6 11:32:52 2013 From: dnthayer at illinois.edu (Daniel Thayer) Date: Wed, 6 Nov 2013 13:32:52 -0600 Subject: [Bro-Dev] Failing tests? In-Reply-To: <028E0F4F-ABDA-48CC-B0E8-61B7D9C72C93@icir.org> References: <028E0F4F-ABDA-48CC-B0E8-61B7D9C72C93@icir.org> Message-ID: <527A9964.5090004@illinois.edu> I just ran the tests, and all of them passed. I would suggest starting over ("make distclean") and see if this problem is reproducible or not. On 11/06/2013 01:02 PM, Seth Hall wrote: > Are other people seeing these tests fails? > > [ 34%] doc.sphinx.connection-record-01 ... failed > [ 34%] doc.sphinx.connection-record-02 ... failed > [ 35%] doc.sphinx.data_struct_table_complex ... failed > [ 35%] doc.sphinx.data_struct_record_01 ... failed > [ 35%] doc.sphinx.data_struct_record_02 ... failed > [ 35%] doc.sphinx.data_struct_set_declaration ... failed > [ 35%] doc.sphinx.data_struct_table_declaration ... failed > [ 35%] doc.sphinx.data_struct_vector_declaration ... failed > [ 36%] doc.sphinx.data_struct_vector_iter ... failed > [ 36%] doc.sphinx.data_type_const.bro ... failed > [ 36%] doc.sphinx.data_type_pattern ... failed > [ 36%] doc.sphinx.data_type_interval ... failed > [ 36%] doc.sphinx.data_type_pattern_02 ... failed > [ 36%] doc.sphinx.data_type_subnets ... failed > [ 37%] doc.sphinx.file-analysis-01 ... failed > [ 37%] doc.sphinx.data_type_time ... failed > [ 37%] doc.sphinx.file-analysis-02 ... failed > [ 37%] doc.sphinx.framework_logging_factorial ... failed > [ 38%] doc.sphinx.file-analysis-03 ... failed > [ 38%] doc.sphinx.framework_logging_factorial-2 ... failed > [ 39%] doc.sphinx.framework_logging_factorial-3 ... failed > [ 47%] doc.sphinx.using_bro ? failed >  > I *think* the problem might just be that the baselines aren't committed for these. > > .Seth > From noreply at bro.org Thu Nov 7 00:00:23 2013 From: noreply at bro.org (Merge Tracker) Date: Thu, 7 Nov 2013 00:00:23 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311070800.rA780N0Q011906@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ----------------------------------------------------------- 410e4ba [1] bro Daniel Thayer 2013-11-06 Fix typos in sumstats doc and update doc test 85d8653 [2] bro Daniel Thayer 2013-11-06 Update docs and tests for a recent change to detect-MHR.bro 9ed5f8b [3] bro Daniel Thayer 2013-11-06 Update tests and baselines for sumstats docs [1] 410e4ba https://github.com/bro/bro/commit/410e4babd045035503696e29639a1b8875e4e04e [2] 85d8653 https://github.com/bro/bro/commit/85d8653bce626f566791b051d73ac8daa5e7bee0 [3] 9ed5f8b https://github.com/bro/bro/commit/9ed5f8bae8d7d86e105d8273366ab5fc99711117 From jira at bro-tracker.atlassian.net Thu Nov 7 07:17:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:17:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1065) packet_filter.log is broken In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1065: --------------------------- Resolution: Fixed Fix Version/s: git/master Status: Closed (was: Open) Fixed > packet_filter.log is broken > --------------------------- > > Key: BIT-1065 > URL: https://bro-tracker.atlassian.net/browse/BIT-1065 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.2 > Reporter: Seth Hall > Fix For: git/master > > > Apparently I broke the packet_filter.log when I overhauled the packet filter framework. I need to make sure and fix that prior to the 2.2 release (I think it's an ok thing to be broken during the beta). -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:23:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:23:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1082) Trash after SNI information In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1082: --------------------------- Resolution: Cannot Reproduce Status: Closed (was: Open) I'm going to close this ticket since there is really nothing to do about it at this time. > Trash after SNI information > --------------------------- > > Key: BIT-1082 > URL: https://bro-tracker.atlassian.net/browse/BIT-1082 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Bernhard Amann > Fix For: 2.3 > > > When using Bro to extract the server name indication of TLS connections, Bro sometimes does not seem to be able to determine the correct end of the server name field -- instead it also returns additional binary data at the end of the server name. > I do not know if this is reproducible, so far I have not managed to get a trace of a case where it happens. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:26:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:26:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1038) Input framework memory usage issue with huge files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1038: --------------------------- Resolution: Fixed Status: Closed (was: Open) I believe this ticket is fixed. > Input framework memory usage issue with huge files > -------------------------------------------------- > > Key: BIT-1038 > URL: https://bro-tracker.atlassian.net/browse/BIT-1038 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Assignee: Bernhard Amann > Fix For: 2.2 > > > When using the input framework to read a data file and convert into an event stream, it seems that none of the objects instantiated for event generation are freed up. For a file of ~ 5.25 M lines, I am seeing > 4 GB memory used. > Version is 2.1-798 > A quick demo script looks like: > event bro_init() > \{ > # input stream setup > Input::add_event([$reader=Input::READER_RAW, $mode=Input::STREAM, $name="issh", $fields=lineVals, $ev=sshLine|$source=data_file,]); > } > event sshLine(description: Input::EventDescription, tpe: Input::Event, LV: lineVals) > \{ > return; > } > thanks\! > scott -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:28:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:28:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1073) Make the MIME analyzer a FAF analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1073: --------------------------- Fix Version/s: 2.3 > Make the MIME analyzer a FAF analyzer > ------------------------------------- > > Key: BIT-1073 > URL: https://bro-tracker.atlassian.net/browse/BIT-1073 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master > Reporter: Matthias Vallentin > Labels: analyzer, file-analysis, mime > Fix For: 2.3 > > > We should convert the MIME analyzer to use FAF, allowing other components to reuse it. Specifically, I noted this in the process of bringing back the POP3 analyzer. Ideally, we can just feed the contents of the download emails via the RETR command into a FAF-based MIME analyzer. Then we wouldn't have to rebuild functionality that's close to the SMTP analyzer. > In summary, we should factor the MIME analysis into a separate analysis unit. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:30:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:30:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1051) smtp-url-extraction.bro misses/truncates urls between data chunks In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1051: --------------------------- Resolution: Won't Fix Status: Closed (was: Open) We aren't going to "fix" the current functionality, but we will be replacing it with a better mechanism. > smtp-url-extraction.bro misses/truncates urls between data chunks > ----------------------------------------------------------------- > > Key: BIT-1051 > URL: https://bro-tracker.atlassian.net/browse/BIT-1051 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Brian Little > Priority: Low > > Files::add_analyzer(f, Files::ANALYZER_DATA_EVENT, [$stream_event=intel_mime_data]); > event intel_mime_data(f: fa_file, data: string) {} > I think the file analysis framework sends the data through to the intel_mime_data event in sections (appears that way from adding print debugging). The cutting point between the data sections can fall in the middle of an url, causing the regex to miss the url, or truncate it. > What would be the recommended way around for this? (and other usage of file analysis framework) -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:30:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:30:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1050) Merge request for DHCP analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1050: --------------------------- Fix Version/s: 2.2 Status: Closed (was: Reopened) Merged. > Merge request for DHCP analyzer > ------------------------------- > > Key: BIT-1050 > URL: https://bro-tracker.atlassian.net/browse/BIT-1050 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: 2.2 > Reporter: Vlad Grigorescu > Assignee: Seth Hall > Labels: analyzer > Fix For: 2.2 > > > topic/vladg/dhcp is ready to go. I've been running it in prod with no problems. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:30:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:30:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1051) smtp-url-extraction.bro misses/truncates urls between data chunks In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14603#comment-14603 ] Seth Hall commented on BIT-1051: -------------------------------- That's a known limitation. The plan at the moment is to create a file analyzer that let's you extract with a regular expression. Internally it would be provided as a stream so the chunking issue will go away. What in place now is a hack unfortunately. > smtp-url-extraction.bro misses/truncates urls between data chunks > ----------------------------------------------------------------- > > Key: BIT-1051 > URL: https://bro-tracker.atlassian.net/browse/BIT-1051 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Brian Little > Priority: Low > > Files::add_analyzer(f, Files::ANALYZER_DATA_EVENT, [$stream_event=intel_mime_data]); > event intel_mime_data(f: fa_file, data: string) {} > I think the file analysis framework sends the data through to the intel_mime_data event in sections (appears that way from adding print debugging). The cutting point between the data sections can fall in the middle of an url, causing the regex to miss the url, or truncate it. > What would be the recommended way around for this? (and other usage of file analysis framework) -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:32:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:32:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-990) Sumstats documentation In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-990: -------------------------- Resolution: Fixed Status: Closed (was: Open) Done > Sumstats documentation > ---------------------- > > Key: BIT-990 > URL: https://bro-tracker.atlassian.net/browse/BIT-990 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > Fix For: 2.2 > > > We should prepare an overview how-to for using the sumstats framework for 2.2 -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:32:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:32:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1025) internal error: over-ran key in CompositeHash::RecoverVals In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1025: --------------------------- Fix Version/s: (was: 2.2) 2.3 > internal error: over-ran key in CompositeHash::RecoverVals > ---------------------------------------------------------- > > Key: BIT-1025 > URL: https://bro-tracker.atlassian.net/browse/BIT-1025 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: dmandelb > Fix For: 2.3 > > Attachments: bbn-correlator.tgz > > > {noformat} > $ bro bbn-correlator > internal error: over-ran key in CompositeHash::RecoverVals > Aborted > {noformat} -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:32:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:32:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-988) Bug in HTTP body extraction In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-988: -------------------------- Resolution: Fixed Status: Closed (was: Open) Functionality removed in favor of FAF > Bug in HTTP body extraction > --------------------------- > > Key: BIT-988 > URL: https://bro-tracker.atlassian.net/browse/BIT-988 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Matthias Vallentin > Assignee: Seth Hall > Labels: file-analysis > Fix For: 2.2 > > > There exists a bug in HTTP body extraction that prevents certain bodies from being dumped, even though having set > {noformat} > redef extract_file_types = /.*/; > {noformat} > This happens presumably because Bro does not figure out the correct MIME type and does not set {{c$http$mime_type}}. It results in this check failing: > {noformat} > if ( c$http?$mime_type && extract_file_types in c$http$mime_type ) > { > c$http$extract_file = T; > } > {noformat} > On a related note, I also find missing responses to HTTP POST requests which I assume come from the same issues. > I have a trace that I could attach, but wanted to make sure it's worth the effort in face of the upcoming file analysis framework, or if we plan on pushing a 2.1 hotfix for this. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:34:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:34:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-948) add bif for URI -> binary decoding In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-948: -------------------------- Fix Version/s: (was: 2.2) 2.3 > add bif for URI -> binary decoding > ---------------------------------- > > Key: BIT-948 > URL: https://bro-tracker.atlassian.net/browse/BIT-948 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Priority: Low > Fix For: 2.3 > > > The current URI_decode() bif returns non-ascii data in a x\nn format which is safe, but not useful in all situations (such as when you need the literal binary data). > thanks\! > scott -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:34:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:34:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-942) Generic log delaying mechanism for logging framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-942: -------------------------- Fix Version/s: (was: 2.2) 2.3 > Generic log delaying mechanism for logging framework > ---------------------------------------------------- > > Key: BIT-942 > URL: https://bro-tracker.atlassian.net/browse/BIT-942 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Assignee: Seth Hall > Priority: Low > Fix For: 2.3 > > > We need to add a mechanism for delaying log writes within the logging framework for the case where some asynchronous lookup needs to happen in a non-base script. There are a few requirements: > \\- The mechanism needs to copy the log record so that future modifications of the record aren't impacted unless deliberately modifying the delayed record. > \\- Three functions in Log:: namespace to register and unregister delays for logs and one to get access to the delayed log by it's delay token. > \\- Additional configuration option in logging framework to configure a default logging delay. It's possible that we should set the default stream delay in the stream configuration record. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:34:30 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:34:30 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-977) retransmit in connection history In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-977: -------------------------- Fix Version/s: (was: 2.2) 2.3 > retransmit in connection history > -------------------------------- > > Key: BIT-977 > URL: https://bro-tracker.atlassian.net/browse/BIT-977 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Priority: Low > Fix For: 2.3 > > > In the connection record's $history field, it would be useful to include another character to indicate retransmits sent during the connection. I think that T and t for first orig and resp retransmit respectively would be appropriate. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:36:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:36:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-903) -b turns off -f In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-903: -------------------------- Fix Version/s: (was: 2.2) 2.3 > -b turns off -f > --------------- > > Key: BIT-903 > URL: https://bro-tracker.atlassian.net/browse/BIT-903 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Vern Paxson > Fix For: 2.3 > > Attachments: single-tcp-conn-est.trace > > > Running with \-b (bare bones) disables processing by \-f. Boy did this take me a long time to figure out :-(. > Reproduce using the appended trace. Invoking with *-e 'event connection_established(c:connection) \{ print "yep"; }*' will print "yep". Invoking with that plus *-f 'not tcp*' won't print anything. But invoking with *-f 'not tcp' \-b* _does_ print "yep". -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:36:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:36:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-924) String BIFs Return 1-indexed string_arrays In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-924: -------------------------- Fix Version/s: (was: 2.2) 2.3 > String BIFs Return 1-indexed string_arrays > ------------------------------------------ > > Key: BIT-924 > URL: https://bro-tracker.atlassian.net/browse/BIT-924 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: grigorescu > Fix For: 2.3 > > > The following BIFs return 1-indexed string_arrays: > * sort_string_array > * split > * split1 > * split_all > * split_n -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:38:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:38:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-896) SCP and SFTP rotators printing In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-896: -------------------------- Resolution: Fixed Status: Closed (was: Open) > SCP and SFTP rotators printing > ------------------------------ > > Key: BIT-896 > URL: https://bro-tracker.atlassian.net/browse/BIT-896 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Fix For: 2.2 > > > The SCP and SFTP log rotators are causing output on stdout and shouldn't be. I think the output is coming from the scp and sftp clients, maybe they just need a quiet flag? -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:38:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:38:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-896) SCP and SFTP rotators printing In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609#comment-14609 ] Seth Hall commented on BIT-896: ------------------------------- I believe this was fixed. > SCP and SFTP rotators printing > ------------------------------ > > Key: BIT-896 > URL: https://bro-tracker.atlassian.net/browse/BIT-896 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Fix For: 2.2 > > > The SCP and SFTP log rotators are causing output on stdout and shouldn't be. I think the output is coming from the scp and sftp clients, maybe they just need a quiet flag? -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:38:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:38:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-903) -b turns off -f In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608#comment-14608 ] Seth Hall commented on BIT-903: ------------------------------- This issue begs a couple of questions. Should Bro scripts have access to command line arguments? If they did, we could have a script that monitors for the flag being given and complaining if the PacketFilter framework isn't loaded. Should we always load the PacketFilter framework? (I don't think we should). > -b turns off -f > --------------- > > Key: BIT-903 > URL: https://bro-tracker.atlassian.net/browse/BIT-903 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Vern Paxson > Fix For: 2.3 > > Attachments: single-tcp-conn-est.trace > > > Running with \-b (bare bones) disables processing by \-f. Boy did this take me a long time to figure out :-(. > Reproduce using the appended trace. Invoking with *-e 'event connection_established(c:connection) \{ print "yep"; }*' will print "yep". Invoking with that plus *-f 'not tcp*' won't print anything. But invoking with *-f 'not tcp' \-b* _does_ print "yep". -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:45:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:45:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-867) GRE support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-867: -------------------------- Fix Version/s: (was: 2.2) 2.3 > GRE support > ----------- > > Key: BIT-867 > URL: https://bro-tracker.atlassian.net/browse/BIT-867 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > Fix For: 2.3 > > > Should be rather easy to add support for GRE tunnels now. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:47:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:47:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-816) Reworked PacketFilter framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-816: -------------------------- Resolution: Fixed Status: Closed (was: Open) Finished > Reworked PacketFilter framework > ------------------------------- > > Key: BIT-816 > URL: https://bro-tracker.atlassian.net/browse/BIT-816 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Assignee: Seth Hall > Fix For: 2.2 > > > This is in the topic/seth/scripts-for-2.1 branch, apologies for the poor naming. One test is failing for me (coverage.test-all-policy) but I'm not sure what to do to fix it. > This branch reworks the packet filter framework to make it easier to accomplish common actions. > \\- Removes the PacketFilter::all_packets variable and instead makes "ip or not ip" the default capture filter. > \\- Adds some convenience methods for restricting the traffic that is monitored and shunting traffic away with BPF. > \\- Adds the beginning of load balancing support that is necessary to tie in with some load balancing methods through broctl. > \\- Change the queue manager to flush the event queue before initializing analyzers through DPD. > \\- New protocols framework that adds some convenience support for defining the analyzer->DPD linkage. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:47:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:47:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-560) Child analyzer Init() problem In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611#comment-14611 ] Seth Hall commented on BIT-560: ------------------------------- Need to bump this again. No one looked into it. > Child analyzer Init() problem > ----------------------------- > > Key: BIT-560 > URL: https://bro-tracker.atlassian.net/browse/BIT-560 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: gregor > Assignee: Robin Sommer > Fix For: 2.3 > > > {noformat} > #!rst > I think there is an inherent problem in the way analyzers and child analyzers are initialized. If analyzers are added by BuildInitialAnalyzerTree() they are not initialized at first but in a batch by calling:: > > root->Init(); > root->InitChildren(); > If an analyzer wants to add a child in its Init(), the parent doesn't know whether it needs to init this child or not. If the parent was added by ``BuildInitialAnalyzerTree()``, it *must not* ``Init()`` the child, because ``BuildInitialAnalyzerTree()`` will do it. OTOH, if the parent was added dynamically, e.g., by DPD signatures, then it *must* ``Init()`` the child. > What was the reason for ``BuildInitialAnalyzerTree()`` to defer initialization of the tree until the end of the function? Initializing when they are added would solve the problem but I guess there was a good reason to do it this way. > {noformat} -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:47:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:47:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-560) Child analyzer Init() problem In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-560: -------------------------- Fix Version/s: (was: 2.2) 2.3 > Child analyzer Init() problem > ----------------------------- > > Key: BIT-560 > URL: https://bro-tracker.atlassian.net/browse/BIT-560 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: gregor > Assignee: Robin Sommer > Fix For: 2.3 > > > {noformat} > #!rst > I think there is an inherent problem in the way analyzers and child analyzers are initialized. If analyzers are added by BuildInitialAnalyzerTree() they are not initialized at first but in a batch by calling:: > > root->Init(); > root->InitChildren(); > If an analyzer wants to add a child in its Init(), the parent doesn't know whether it needs to init this child or not. If the parent was added by ``BuildInitialAnalyzerTree()``, it *must not* ``Init()`` the child, because ``BuildInitialAnalyzerTree()`` will do it. OTOH, if the parent was added dynamically, e.g., by DPD signatures, then it *must* ``Init()`` the child. > What was the reason for ``BuildInitialAnalyzerTree()`` to defer initialization of the tree until the end of the function? Initializing when they are added would solve the problem but I guess there was a good reason to do it this way. > {noformat} -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:52:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:52:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-553) Script variable to set pcap's buffer size In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-553: -------------------------- Resolution: Feedback Missing Status: Closed (was: Open) I don't think we're going to bother with this especially since packet capture might get overhauled a bit soon. > Script variable to set pcap's buffer size > ----------------------------------------- > > Key: BIT-553 > URL: https://bro-tracker.atlassian.net/browse/BIT-553 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: gregor > Fix For: 2.2 > > > Newer pcap versions have a pcap_set_buffer_size(). This call can be used to adjust the kernel level buffer size for captures. (E.g., Linux PF_RING's buffer size, which will be quite important if we start using 64KB snaplen) > It's supported for all platforms we care about (Linux, BPF-based OSes), but we probably want to make sure that it obsoletes the manual tuning through: > http://www.net.t-labs.tu-berlin.de/research/bpcs/ > (It might well be that one still has to manually increase the max buffer sizes) -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:52:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:52:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-579) "Raw" logging writer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-579: -------------------------- Resolution: Fixed Status: Closed (was: Open) I can now recognize that this wasn't a great idea. :) > "Raw" logging writer > -------------------- > > Key: BIT-579 > URL: https://bro-tracker.atlassian.net/browse/BIT-579 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Priority: High > Fix For: 2.2 > > > This was formerly a ticket about creating syslog logging writer, but I think we found a better and more general approach in a "raw" writer. The raw writer would abandon the normal tab separated output from the Ascii writer and instead would be based on a templating format passed through the config filter field. There should also be options for sending the formatted data to files, sockets, and syslog. > This writer would open several doors for us: > * Direct integration from script-land with ELSA. > * Functional replacement for PRADS in script-land with integration into Sguil. > * Direct script-land integration with the metrics framework and Graphite. > Here is a made up example of creating a metrics filter for sending data to Graphite: > {noformat} > Log::add_filter(Metrics::LOG, [$name="graphite", > $writer=Log::WRITER_RAW, > $path="tcp://1.2.3.4:2003/", > $config = table(["fmt"] = "{{metric}} {{value}} {{ts}}")]); > {noformat} -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:59:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:59:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-521) Bro's secondary path does not handle IPv6) (only v4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-521: -------------------------- Fix Version/s: 2.3 > Bro's secondary path does not handle IPv6) (only v4 > --------------------------------------------------- > > Key: BIT-521 > URL: https://bro-tracker.atlassian.net/browse/BIT-521 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: gregor > Labels: IPv6 > Fix For: 2.3 > > > Bro's secondary path only handles IPv4 packets > See NetSessions::NextPacketSecondary -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:59:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:59:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-697) Equivalent of capture-events.bro in 2.x In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-697: -------------------------- Fix Version/s: 2.3 > Equivalent of capture-events.bro in 2.x > --------------------------------------- > > Key: BIT-697 > URL: https://bro-tracker.atlassian.net/browse/BIT-697 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Matthias Vallentin > Fix For: 2.3 > > > How should we handle the functionality provided by the 1.5 script {{capture-events.bro}} in 2.x? It currently does not exist. Since it's implementation only consists of this one-liner > {noformat} > event bro_init() > { > capture_events("events.bst"); > } > {noformat} > I think we make that a redefinable script variable rather than shipping a separate script. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 07:59:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 09:59:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-521) Bro's secondary path does not handle IPv6) (only v4 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14614#comment-14614 ] Seth Hall commented on BIT-521: ------------------------------- Let's say we kill off secondary path in 2.3? > Bro's secondary path does not handle IPv6) (only v4 > --------------------------------------------------- > > Key: BIT-521 > URL: https://bro-tracker.atlassian.net/browse/BIT-521 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: gregor > Labels: IPv6 > Fix For: 2.3 > > > Bro's secondary path only handles IPv4 packets > See NetSessions::NextPacketSecondary -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:01:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:01:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-671) Test Bro core and script layer simultaneously In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-671: -------------------------- Fix Version/s: (was: 2.2) 2.3 > Test Bro core and script layer simultaneously > --------------------------------------------- > > Key: BIT-671 > URL: https://bro-tracker.atlassian.net/browse/BIT-671 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BTest > Affects Versions: git/master > Reporter: Matthias Vallentin > Fix For: 2.3 > > > If we record all events during testing, say by adding {{events.bst}} to each Bro run, we can simultaneously test the core. Moreover, we instantly know whether a bug manifests at script land or at the core. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:01:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:01:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-310) Higher time resolution? In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-310: -------------------------- Resolution: Fixed Status: Closed (was: Open) I'm just going to close this ticket actually. It will come up again if it's important enough. > Higher time resolution? > ----------------------- > > Key: BIT-310 > URL: https://bro-tracker.atlassian.net/browse/BIT-310 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > Fix For: 2.3 > > > Something to discuss: do we need timestamps with higher resolution > (if the NIC provides them, like the DAGs for example). -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:01:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:01:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-310) Higher time resolution? In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-310: -------------------------- Fix Version/s: (was: 2.2) 2.3 > Higher time resolution? > ----------------------- > > Key: BIT-310 > URL: https://bro-tracker.atlassian.net/browse/BIT-310 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > Fix For: 2.3 > > > Something to discuss: do we need timestamps with higher resolution > (if the NIC provides them, like the DAGs for example). -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:03:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:03:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-266) broctl cron hangs with dead hosts In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-266: -------------------------- Resolution: Fixed Status: Closed (was: Open) Without more debugging information or activity on this ticket, I'm just going to close it. > broctl cron hangs with dead hosts > --------------------------------- > > Key: BIT-266 > URL: https://bro-tracker.atlassian.net/browse/BIT-266 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: solomon > Assignee: Daniel Thayer > Fix For: 2.2 > > > If a bro node has become completely inaccessible (dead or otherwise offline), the broctl 'cron' task will hang for far too long while attempting to restart bro on that host. When 'broctl cron' is run from the system crontab, this negatively impacts any other use of broctl and prevents almost all interactive use of broctl, which repeatedly times out with 'cannot get lock' error message. > One is forced to either kill all running python processes on the master (thereby killing the blocking 'broctl cron' task), or to run broctl non-interactively (such as running "broctl top" from the command line) over-and-over again until the process successfully gets the lock. > broctl should timeout more quickly with hosts that are completely offline. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:05:30 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:05:30 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-341) Verify MACs seen In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-341: -------------------------- Resolution: Fixed Status: Closed (was: Open) I think this is too deployment specific and ultimately something that Bro itself should be doing. I'm going to close this ticket since it doesn't have a terribly concrete task item. > Verify MACs seen > ---------------- > > Key: BIT-341 > URL: https://bro-tracker.atlassian.net/browse/BIT-341 > Project: Bro Issue Tracker > Issue Type: Task > Components: BroControl > Affects Versions: git/master > Reporter: Robin Sommer > Assignee: Robin Sommer > > BroControl's "cron" should check the number of MAC addresses seen by > the worker nodes. If it changes, that may be an indicator of a > problem (like the switch flooding packets to all nodes). -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:07:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:07:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-505) Invalid Unref crash In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-505: -------------------------- Resolution: Fixed Status: Closed (was: Open) I'm not seeing crashes. > Invalid Unref crash > ------------------- > > Key: BIT-505 > URL: https://bro-tracker.atlassian.net/browse/BIT-505 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: gclark > Attachments: bro.trace.bz2 > > > Using latest from bro-master: > Last few lines of Bro execution trace: > {noformat} > 1311220077.263882 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:384 Builtin Function called: network_time() > 1311220077.263882 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:384 Function return: 1311220077.26388 > 1311220077.263882 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 function called: id_string(id = '[orig_h=204.152.191.37, orig_p=80/tcp, resp_h=212.110.251.3, resp_p=33595/tcp]') > 1311220077.263882 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Builtin Function called: fmt(va_args = '%s:%d > %s:%d', vararg0 = '204.152.191.37', vararg1 = '80/tcp', vararg2 = '212.110.251.3', vararg3 = '33595/tcp') > 1311220077.263882 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Function return: 204.152.191.37:80 > 212.110.251.3:33595 > 1311220077.263882 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Function return: 204.152.191.37:80 > 212.110.251.3:33595 > 1311220077.263882 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:359 function called: Weird::report_weird_conn(t = '1311220077.26388', name = 'above_hole_data_without_any_acks', id = '204.152.191.37:80 > 212.110.251.3:33595', addl = '', c = '[id=[orig_h=204.152.191.37, orig_p=80/tcp, resp_h=212.110.251.3, resp_p=33595/tcp], orig=[size=7240, state=3, num_pkts=, num_bytes_ip=], resp=[size=0, state=0, num_pkts=, num_bytes_ip=], start_time=1311220077.2637, duration=0.000185012817382812, service={ > }, addl=, hot=0, history=D, uid=vwfIafnipTj, conn=, extract_orig=F, extract_resp=F, dns=, dns_state=, ftp=, http=, http_state=, irc=, mime=, mime_state=, smtp=, smtp_state=, ssh=, ssl=, syslog=]') > 1311220077.263882 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:310 function called: Weird::report_weird(t = '1311220077.26388', name = 'above_hole_data_without_any_acks', id = '204.152.191.37:80 > 212.110.251.3:33595', have_conn = 'T', addl = '', action = 'WEIRD_FILE', no_log = 'F') > 1311220077.263882 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 function called: Log::write(id = 'WEIRD', columns = '[ts=1311220077.26388, uid=vwfIafnipTj, id=[orig_h=204.152.191.37, orig_p=80/tcp, resp_h=212.110.251.3, resp_p=33595/tcp], msg=above_hole_data_without_any_acks, addl=, notice=F]') > 1311220077.263882 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 Builtin Function called: Log::__write(id = 'WEIRD', columns = '[ts=1311220077.26388, uid=vwfIafnipTj, id=[orig_h=204.152.191.37, orig_p=80/tcp, resp_h=212.110.251.3, resp_p=33595/tcp], msg=above_hole_data_without_any_acks, addl=, notice=F]') > 1311220077.263882 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 Function return: T > 1311220077.263882 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 Function return: T > 1311220077.461318 /home/gilbert/Code/bro/build/src/event.bif.bro:104 event called: conn_weird(name = 'spontaneous_RST', c = '[id=[orig_h=212.110.251.3, orig_p=113/tcp, resp_h=161.53.178.240, resp_p=50349/tcp], orig=[size=0, state=6, num_pkts=, num_bytes_ip=], resp=[size=0, state=0, num_pkts=, num_bytes_ip=], start_time=1311220077.46132, duration=0.0, service={ > }, addl=, hot=0, history=R, uid=0Wn1J3f4jD4, conn=, extract_orig=F, extract_resp=F, dns=, dns_state=, ftp=, http=, http_state=, irc=, mime=, mime_state=, smtp=, smtp_state=, ssh=, ssl=, syslog=]', addl = '') > 1311220077.461318 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:384 Builtin Function called: network_time() > 1311220077.461318 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:384 Function return: 1311220077.46132 > 1311220077.461318 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 function called: id_string(id = '[orig_h=212.110.251.3, orig_p=113/tcp, resp_h=161.53.178.240, resp_p=50349/tcp]') > 1311220077.461318 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Builtin Function called: fmt(va_args = '%s:%d > %s:%d', vararg0 = '212.110.251.3', vararg1 = '113/tcp', vararg2 = '161.53.178.240', vararg3 = '50349/tcp') > 1311220077.461318 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Function return: 212.110.251.3:113 > 161.53.178.240:50349 > 1311220077.461318 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Function return: 212.110.251.3:113 > 161.53.178.240:50349 > 1311220077.461318 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:359 function called: Weird::report_weird_conn(t = '1311220077.46132', name = 'spontaneous_RST', id = '212.110.251.3:113 > 161.53.178.240:50349', addl = '', c = '[id=[orig_h=212.110.251.3, orig_p=113/tcp, resp_h=161.53.178.240, resp_p=50349/tcp], orig=[size=0, state=6, num_pkts=, num_bytes_ip=], resp=[size=0, state=0, num_pkts=, num_bytes_ip=], start_time=1311220077.46132, duration=0.0, service={ > }, addl=, hot=0, history=R, uid=0Wn1J3f4jD4, conn=, extract_orig=F, extract_resp=F, dns=, dns_state=, ftp=, http=, http_state=, irc=, mime=, mime_state=, smtp=, smtp_state=, ssh=, ssl=, syslog=]') > 1311220077.461318 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:310 function called: Weird::report_weird(t = '1311220077.46132', name = 'spontaneous_RST', id = '212.110.251.3:113 > 161.53.178.240:50349', have_conn = 'T', addl = '', action = 'WEIRD_IGNORE', no_log = 'F') > 1311220077.461532 /home/gilbert/Code/bro/build/src/event.bif.bro:104 event called: conn_weird(name = 'connection_originator_SYN_ack', c = '[id=[orig_h=161.53.178.240, orig_p=6667/tcp, resp_h=212.110.251.3, resp_p=59665/tcp], orig=[size=0, state=0, num_pkts=, num_bytes_ip=], resp=[size=0, state=0, num_pkts=, num_bytes_ip=], start_time=1311220077.46094, duration=0.0, service={ > }, addl=, hot=0, history=H, uid=hrTdn4R7Yq9, conn=, extract_orig=F, extract_resp=F, dns=, dns_state=, ftp=, http=, http_state=, irc=, mime=, mime_state=, smtp=, smtp_state=, ssh=, ssl=, syslog=]', addl = '') > 1311220077.461532 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:384 Builtin Function called: network_time() > 1311220077.461532 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:384 Function return: 1311220077.46153 > 1311220077.461532 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 function called: id_string(id = '[orig_h=161.53.178.240, orig_p=6667/tcp, resp_h=212.110.251.3, resp_p=59665/tcp]') > 1311220077.461532 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Builtin Function called: fmt(va_args = '%s:%d > %s:%d', vararg0 = '161.53.178.240', vararg1 = '6667/tcp', vararg2 = '212.110.251.3', vararg3 = '59665/tcp') > 1311220077.461532 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Function return: 161.53.178.240:6667 > 212.110.251.3:59665 > 1311220077.461532 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Function return: 161.53.178.240:6667 > 212.110.251.3:59665 > 1311220077.461532 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:359 function called: Weird::report_weird_conn(t = '1311220077.46153', name = 'connection_originator_SYN_ack', id = '161.53.178.240:6667 > 212.110.251.3:59665', addl = '', c = '[id=[orig_h=161.53.178.240, orig_p=6667/tcp, resp_h=212.110.251.3, resp_p=59665/tcp], orig=[size=0, state=0, num_pkts=, num_bytes_ip=], resp=[size=0, state=0, num_pkts=, num_bytes_ip=], start_time=1311220077.46094, duration=0.0, service={ > }, addl=, hot=0, history=H, uid=hrTdn4R7Yq9, conn=, extract_orig=F, extract_resp=F, dns=, dns_state=, ftp=, http=, http_state=, irc=, mime=, mime_state=, smtp=, smtp_state=, ssh=, ssl=, syslog=]') > 1311220077.461532 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:310 function called: Weird::report_weird(t = '1311220077.46153', name = 'connection_originator_SYN_ack', id = '161.53.178.240:6667 > 212.110.251.3:59665', have_conn = 'T', addl = '', action = 'WEIRD_FILE', no_log = 'F') > 1311220077.461532 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 function called: Log::write(id = 'WEIRD', columns = '[ts=1311220077.46153, uid=hrTdn4R7Yq9, id=[orig_h=161.53.178.240, orig_p=6667/tcp, resp_h=212.110.251.3, resp_p=59665/tcp], msg=connection_originator_SYN_ack, addl=, notice=F]') > 1311220077.461532 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 Builtin Function called: Log::__write(id = 'WEIRD', columns = '[ts=1311220077.46153, uid=hrTdn4R7Yq9, id=[orig_h=161.53.178.240, orig_p=6667/tcp, resp_h=212.110.251.3, resp_p=59665/tcp], msg=connection_originator_SYN_ack, addl=, notice=F]') > 1311220077.461532 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 Function return: T > 1311220077.461532 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 Function return: T > 1311220077.462050 /home/gilbert/Code/bro/build/src/event.bif.bro:67 event called: protocol_confirmation(c = '[id=[orig_h=212.110.251.3, orig_p=52895/tcp, resp_h=64.18.128.86, resp_p=6667/tcp], orig=[size=38, state=3, num_pkts=, num_bytes_ip=], resp=[size=0, state=0, num_pkts=, num_bytes_ip=], start_time=1311220077.46205, duration=0.0, service={ > }, addl=, hot=0, history=D, uid=Y6rpTW6Rgeg, conn=, extract_orig=F, extract_resp=F, dns=, dns_state=, ftp=, http=, http_state=, irc=, mime=, mime_state=, smtp=, smtp_state=, ssh=, ssl=, syslog=]', atype = '19', aid = '8963') > 1311220077.462050 /home/gilbert/Code/bro/build/src/event.bif.bro:104 event called: conn_weird(name = 'irc_line_too_short', c = '[id=[orig_h=212.110.251.3, orig_p=52895/tcp, resp_h=64.18.128.86, resp_p=6667/tcp], orig=[size=38, state=3, num_pkts=, num_bytes_ip=], resp=[size=0, state=0, num_pkts=, num_bytes_ip=], start_time=1311220077.46205, duration=0.0, service={ > }, addl=, hot=0, history=D, uid=Y6rpTW6Rgeg, conn=, extract_orig=F, extract_resp=F, dns=, dns_state=, ftp=, http=, http_state=, irc=, mime=, mime_state=, smtp=, smtp_state=, ssh=, ssl=, syslog=]', addl = '') > 1311220077.462050 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:384 Builtin Function called: network_time() > 1311220077.462050 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:384 Function return: 1311220077.46205 > 1311220077.462050 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 function called: id_string(id = '[orig_h=212.110.251.3, orig_p=52895/tcp, resp_h=64.18.128.86, resp_p=6667/tcp]') > 1311220077.462050 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Builtin Function called: fmt(va_args = '%s:%d > %s:%d', vararg0 = '212.110.251.3', vararg1 = '52895/tcp', vararg2 = '64.18.128.86', vararg3 = '6667/tcp') > 1311220077.462050 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Function return: 212.110.251.3:52895 > 64.18.128.86:6667 > 1311220077.462050 /home/gilbert/Code/bro/policy/utils/conn-ids.bro:23 Function return: 212.110.251.3:52895 > 64.18.128.86:6667 > 1311220077.462050 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:359 function called: Weird::report_weird_conn(t = '1311220077.46205', name = 'irc_line_too_short', id = '212.110.251.3:52895 > 64.18.128.86:6667', addl = '', c = '[id=[orig_h=212.110.251.3, orig_p=52895/tcp, resp_h=64.18.128.86, resp_p=6667/tcp], orig=[size=38, state=3, num_pkts=, num_bytes_ip=], resp=[size=0, state=0, num_pkts=, num_bytes_ip=], start_time=1311220077.46205, duration=0.0, service={ > }, addl=, hot=0, history=D, uid=Y6rpTW6Rgeg, conn=, extract_orig=F, extract_resp=F, dns=, dns_state=, ftp=, http=, http_state=, irc=, mime=, mime_state=, smtp=, smtp_state=, ssh=, ssl=, syslog=]') > 1311220077.462050 /home/gilbert/Code/bro/policy/frameworks/notice/weird.bro:310 function called: Weird::report_weird(t = '1311220077.46205', name = 'irc_line_too_short', id = '212.110.251.3:52895 > 64.18.128.86:6667', have_conn = 'T', addl = '', action = 'WEIRD_FILE', no_log = 'F') > 1311220077.462050 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 function called: Log::write(id = 'WEIRD', columns = '[ts=1311220077.46205, uid=Y6rpTW6Rgeg, id=[orig_h=212.110.251.3, orig_p=52895/tcp, resp_h=64.18.128.86, resp_p=6667/tcp], msg=irc_line_too_short, addl=, notice=F]') > 1311220077.462050 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 Builtin Function called: Log::__write(id = 'WEIRD', columns = '[ts=1311220077.46205, uid=Y6rpTW6Rgeg, id=[orig_h=212.110.251.3, orig_p=52895/tcp, resp_h=64.18.128.86, resp_p=6667/tcp], msg=irc_line_too_short, addl=, notice=F]') > 1311220077.462050 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 Function return: T > 1311220077.462050 /home/gilbert/Code/bro/policy/frameworks/logging/base.bro:188 Function return: T > 1311220077.462050 /home/gilbert/Code/bro/build/src/event.bif.bro:611 event called: irc_nick_message(c = '[id=[orig_h=212.110.251.3, orig_p=52895/tcp, resp_h=64.18.128.86, resp_p=6667/tcp], orig=[size=38, state=3, num_pkts=, num_bytes_ip=], resp=[size=0, state=0, num_pkts=, num_bytes_ip=], start_time=1311220077.46205, duration=0.0, service={ > }, addl=, hot=0, history=D, uid=Y6rpTW6Rgeg, conn=, extract_orig=F, extract_resp=F, dns=, dns_state=, ftp=, http=, http_state=, irc=, mime=, mime_state=, smtp=, smtp_state=, ssh=, ssl=, syslog=]', who = 'T', newnick = '', vararg0 = 'Trance') > {noformat} > Also, gdb stack trace: > {noformat} > (gdb) bt > #0 0x081ae57f in Unref (o=0x1b9) at /home/gilbert/Code/bro-baseline/src/Obj.h:215 > BIT-1 0x0827fc24 in Frame::SetElement (this=0xac64360, n=3, v=0xac60da0) at /home/gilbert/Code/bro-baseline/src/Frame.h:25 > BIT-2 0x08288796 in BroFunc::Call (this=0x920b258, args=0xac60ec8, parent=0x0) at /home/gilbert/Code/bro-baseline/src/Func.cc:304 > BIT-3 0x08251d33 in EventHandler::Call (this=0x91363c0, vl=0xac60ec8, no_remote=false) at /home/gilbert/Code/bro-baseline/src/EventHandler.cc:73 > BIT-4 0x081fd6c9 in Event::Dispatch (this=0xac63e08, no_remote=false) at /home/gilbert/Code/bro-baseline/src/Event.h:46 > BIT-5 0x08251594 in EventMgr::Dispatch (this=0x8471da0) at /home/gilbert/Code/bro-baseline/src/Event.cc:107 > BIT-6 0x082515ef in EventMgr::Drain (this=0x8471da0) at /home/gilbert/Code/bro-baseline/src/Event.cc:119 > BIT-7 0x082e16f1 in net_packet_dispatch (t=1311220077.46205, hdr=0x9a15c58, pkt=0x9a16148 "", hdr_size=14, src_ps=0x9a15c20, pkt_elem=0x0) > at /home/gilbert/Code/bro-baseline/src/Net.cc:354 > BIT-8 0x082e1912 in net_packet_arrival (t=1311220077.46205, hdr=0x9a15c58, pkt=0x9a16148 "", hdr_size=14, src_ps=0x9a15c20) > at /home/gilbert/Code/bro-baseline/src/Net.cc:416 > BIT-9 0x082f2433 in PktSrc::Process (this=0x9a15c20) at /home/gilbert/Code/bro-baseline/src/PktSrc.cc:275 > BIT-10 0x082e1a33 in net_run () at /home/gilbert/Code/bro-baseline/src/Net.cc:446 > BIT-11 0x081fcf5e in main (argc=8, argv=0xbf90af14) at /home/gilbert/Code/bro-baseline/src/main.cc:997 > {noformat} > This crash was triggered by replaying a trace through a local TAP device; Bro was listening on the TAP device and processing the replayed packets. > The address passed to Unref() appears to be invalid. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:09:30 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Thu, 7 Nov 2013 10:09:30 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-985) 'tail -f' functionality for file reading in input framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann updated BIT-985: ------------------------------- Fix Version/s: (was: 2.2) 2.3 > 'tail -f' functionality for file reading in input framework > ----------------------------------------------------------- > > Key: BIT-985 > URL: https://bro-tracker.atlassian.net/browse/BIT-985 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Assignee: Bernhard Amann > Priority: Low > Fix For: 2.3 > > Attachments: PATCH > > > With the current input framework, file data \-> event translation requires that the entire data file be read at bro start time. This can be prohibitive when the file sizes become large ( > 1GB ). > It would be great to see a file open option that would start reading at the end of the file. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:11:30 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Thu, 7 Nov 2013 10:11:30 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-985) 'tail -f' functionality for file reading in input framework In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14619#comment-14619 ] Bernhard Amann commented on BIT-985: ------------------------------------ I will add this soon-ish... > 'tail -f' functionality for file reading in input framework > ----------------------------------------------------------- > > Key: BIT-985 > URL: https://bro-tracker.atlassian.net/browse/BIT-985 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: scampbell > Assignee: Bernhard Amann > Priority: Low > Fix For: 2.3 > > Attachments: PATCH > > > With the current input framework, file data \-> event translation requires that the entire data file be read at bro start time. This can be prohibitive when the file sizes become large ( > 1GB ). > It would be great to see a file open option that would start reading at the end of the file. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:13:30 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Thu, 7 Nov 2013 10:13:30 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-865) http://www.bro-ids.org/development/projects/ is inaccessible In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann updated BIT-865: ------------------------------- Resolution: Fixed Status: Closed (was: Open) This was apparently fixed a while ago; /development/projects now shows a page > http://www.bro-ids.org/development/projects/ is inaccessible > ------------------------------------------------------------ > > Key: BIT-865 > URL: https://bro-tracker.atlassian.net/browse/BIT-865 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Affects Versions: git/master > Reporter: Vern Paxson > > This part of the web site, even though it's linked to by other pages (such as the upper right of http://www.bro-ids.org/development/projects/cban.html ), returns a 403 Forbidden when visited. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:15:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:15:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-758) New function split_esc In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621#comment-14621 ] Seth Hall commented on BIT-758: ------------------------------- Couldn't you get the same functionality with one of the split functions using this pattern? /[^\/]#/ > New function split_esc > ---------------------- > > Key: BIT-758 > URL: https://bro-tracker.atlassian.net/browse/BIT-758 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Matthias Vallentin > > In the topic branch {{topic/matthias/split-escaped}}, I added new functionality to split strings that may contain an escaped split expression. E.g., now it would be possible to split strings of the form > {noformat} > a#b\#c#d > {noformat} > into {{[b\#c, d|a,]}}. This would otherwise not be possible, because one cannot perform a lookahead with Bro's regular expressions. > I implemented this function as an utility function at the scripting layer, rather than adding a new BiF. Ideally, we'd enhance {{split_n}} with this ability and then propagate the changes through the respective {{split*}} functions. But before this happens, it makes probably more sense to address BIT-757 first. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:18:31 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Thu, 7 Nov 2013 10:18:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-911) SRV replies don't get processed by DNS analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623#comment-14623 ] Bernhard Amann commented on BIT-911: ------------------------------------ I just took a short look at this and it still does not seem to work (I think we fixed some dns issues for 2.2). > SRV replies don't get processed by DNS analyzer > ----------------------------------------------- > > Key: BIT-911 > URL: https://bro-tracker.atlassian.net/browse/BIT-911 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Vern Paxson > Fix For: 2.3 > > Attachments: tdns-srv.bug.trace > > > The event engine doesn't appear to generate {{dns_SRV_reply}} in some cases, as indicated by running on the attached trace. I've tried this with both the default DNS analysis and my own custom analysis (that uses \-b to not run other stuff) and have confirmed that the reply event isn't getting generated, even though there aren't any checksum issues or such. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:18:31 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Thu, 7 Nov 2013 10:18:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-911) SRV replies don't get processed by DNS analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann updated BIT-911: ------------------------------- Fix Version/s: (was: 2.2) 2.3 > SRV replies don't get processed by DNS analyzer > ----------------------------------------------- > > Key: BIT-911 > URL: https://bro-tracker.atlassian.net/browse/BIT-911 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Vern Paxson > Fix For: 2.3 > > Attachments: tdns-srv.bug.trace > > > The event engine doesn't appear to generate {{dns_SRV_reply}} in some cases, as indicated by running on the attached trace. I've tried this with both the default DNS analysis and my own custom analysis (that uses \-b to not run other stuff) and have confirmed that the reply event isn't getting generated, even though there aren't any checksum issues or such. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:18:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:18:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-758) New function split_esc In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622#comment-14622 ] Seth Hall commented on BIT-758: ------------------------------- Oh no, I'm ridiculous. You can't because that would grab that character. > New function split_esc > ---------------------- > > Key: BIT-758 > URL: https://bro-tracker.atlassian.net/browse/BIT-758 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Matthias Vallentin > > In the topic branch {{topic/matthias/split-escaped}}, I added new functionality to split strings that may contain an escaped split expression. E.g., now it would be possible to split strings of the form > {noformat} > a#b\#c#d > {noformat} > into {{[b\#c, d|a,]}}. This would otherwise not be possible, because one cannot perform a lookahead with Bro's regular expressions. > I implemented this function as an utility function at the scripting layer, rather than adding a new BiF. Ideally, we'd enhance {{split_n}} with this ability and then propagate the changes through the respective {{split*}} functions. But before this happens, it makes probably more sense to address BIT-757 first. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:20:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:20:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-348) Reassembler integer overflow issues. Data not delivered after 2GB In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14624#comment-14624 ] Seth Hall commented on BIT-348: ------------------------------- Sigh, now I guess it's high priority for 2.3. > Reassembler integer overflow issues. Data not delivered after 2GB > ----------------------------------------------------------------- > > Key: BIT-348 > URL: https://bro-tracker.atlassian.net/browse/BIT-348 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: gregor > Priority: High > Labels: inttypes > Fix For: 2.3 > > > {noformat} > #!rst > The TCP Reassembler does not deliver any data to analyzers after the first 2GB due to signed integer overflow (Actually it will deliver again between 4--6GB, etc.) This happens silently, i.e., without content_gap events or Undelivered calls. > This report superseded BIT-315, BIT-137 > The TCP Reassembler (and Reassem) base class use ``int`` to keep track of sequence numbers and ``seq_delta`` to check for differences. If a connection exceeds 2GB, the relative sequence numbers (int) used by the Reassembler become negative. While many parts of the Reassembler still work (because seq_delta still reports the correct difference) some parts do not. In particular ``seq_to_skip`` is broken (and fails silently). There might well be other parts of the Reassembler that fail > silently as well, that I haven't found yet. > See Comments in TCP_Reassembler.cc for more details. > The Reassembler should use int64. However this will require deep changes to the Reassembler and the TCP Analyzer and TCP_Endpoint classes (since we also store sequence numbers there). Also, the analyzer framework will need tweaks as well (e.g., Undelivered uses ``int`` for sequence numbers, also has to go to 64 bit) > As a hotfix that seems to work I disabled the ``seq_to_skip`` features. It wasn't used by any analyzer or policy script (Note, that seq_to_skip is different from skip_deliveries). Hotfix is in > topic/gregor/reassembler-hotfix > {noformat} -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:20:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:20:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-348) Reassembler integer overflow issues. Data not delivered after 2GB In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-348: -------------------------- Fix Version/s: (was: 2.2) 2.3 > Reassembler integer overflow issues. Data not delivered after 2GB > ----------------------------------------------------------------- > > Key: BIT-348 > URL: https://bro-tracker.atlassian.net/browse/BIT-348 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: gregor > Priority: High > Labels: inttypes > Fix For: 2.3 > > > {noformat} > #!rst > The TCP Reassembler does not deliver any data to analyzers after the first 2GB due to signed integer overflow (Actually it will deliver again between 4--6GB, etc.) This happens silently, i.e., without content_gap events or Undelivered calls. > This report superseded BIT-315, BIT-137 > The TCP Reassembler (and Reassem) base class use ``int`` to keep track of sequence numbers and ``seq_delta`` to check for differences. If a connection exceeds 2GB, the relative sequence numbers (int) used by the Reassembler become negative. While many parts of the Reassembler still work (because seq_delta still reports the correct difference) some parts do not. In particular ``seq_to_skip`` is broken (and fails silently). There might well be other parts of the Reassembler that fail > silently as well, that I haven't found yet. > See Comments in TCP_Reassembler.cc for more details. > The Reassembler should use int64. However this will require deep changes to the Reassembler and the TCP Analyzer and TCP_Endpoint classes (since we also store sequence numbers there). Also, the analyzer framework will need tweaks as well (e.g., Undelivered uses ``int`` for sequence numbers, also has to go to 64 bit) > As a hotfix that seems to work I disabled the ``seq_to_skip`` features. It wasn't used by any analyzer or policy script (Note, that seq_to_skip is different from skip_deliveries). Hotfix is in > topic/gregor/reassembler-hotfix > {noformat} -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:27:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:27:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-688) [Fwd] Re: content_gap vs. ack_above_hole In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-688: -------------------------- Fix Version/s: 2.3 > [Fwd] Re: [Bro-Dev] content_gap vs. ack_above_hole > -------------------------------------------------- > > Key: BIT-688 > URL: https://bro-tracker.atlassian.net/browse/BIT-688 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > Labels: cleanup > Fix For: 2.3 > > > From: Vern Paxson > Subject: Re: [Bro-Dev] content_gap vs. ack_above_hole > > Can somebody remind me what exactly the difference between these two > > is (and/or why we have both?). > Yeah, my fault :-P. As best as I can tell (from revisiting the code), > content-gap is a superset of ack-above-hole. Content gaps can also occur > in situations where we're not expecting to see ACKs (for example, due to > split routing, or because we're not processing traffic from the receiver). > I think merging the two into a single content_gap event would make sense. > Vern -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:27:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:27:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-688) [Fwd] Re: content_gap vs. ack_above_hole In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14625#comment-14625 ] Seth Hall commented on BIT-688: ------------------------------- This should be really easy to take care of for 2.3. > [Fwd] Re: [Bro-Dev] content_gap vs. ack_above_hole > -------------------------------------------------- > > Key: BIT-688 > URL: https://bro-tracker.atlassian.net/browse/BIT-688 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > Labels: cleanup > Fix For: 2.3 > > > From: Vern Paxson > Subject: Re: [Bro-Dev] content_gap vs. ack_above_hole > > Can somebody remind me what exactly the difference between these two > > is (and/or why we have both?). > Yeah, my fault :-P. As best as I can tell (from revisiting the code), > content-gap is a superset of ack-above-hole. Content gaps can also occur > in situations where we're not expecting to see ACKs (for example, due to > split routing, or because we're not processing traffic from the receiver). > I think merging the two into a single content_gap event would make sense. > Vern -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:29:31 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Thu, 7 Nov 2013 10:29:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-760) Lift Server Alternative Name (SAN) field to scripting layer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann updated BIT-760: ------------------------------- Fix Version/s: (was: 2.2) 2.3 > Lift Server Alternative Name (SAN) field to scripting layer > ----------------------------------------------------------- > > Key: BIT-760 > URL: https://bro-tracker.atlassian.net/browse/BIT-760 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Matthias Vallentin > Assignee: Seth Hall > Labels: analyzer > Fix For: 2.3 > > > It would be nice to have the *Subject Alternative Name (SAN)* field of an X.509 certificate available at the scripting layer. It contains a list of domains that should be used in addition to the CN field of the subject to verify that a domain matches the certificate. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:29:31 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Thu, 7 Nov 2013 10:29:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-760) Lift Server Alternative Name (SAN) field to scripting layer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann reassigned BIT-760: ---------------------------------- Assignee: Bernhard Amann (was: Seth Hall) > Lift Server Alternative Name (SAN) field to scripting layer > ----------------------------------------------------------- > > Key: BIT-760 > URL: https://bro-tracker.atlassian.net/browse/BIT-760 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Matthias Vallentin > Assignee: Bernhard Amann > Labels: analyzer > Fix For: 2.3 > > > It would be nice to have the *Subject Alternative Name (SAN)* field of an X.509 certificate available at the scripting layer. It contains a list of domains that should be used in addition to the CN field of the subject to verify that a domain matches the certificate. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:29:31 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Thu, 7 Nov 2013 10:29:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-760) Lift Server Alternative Name (SAN) field to scripting layer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14626#comment-14626 ] Bernhard Amann commented on BIT-760: ------------------------------------ I have a branch in which this is nearly working, this should make it into 2.3 > Lift Server Alternative Name (SAN) field to scripting layer > ----------------------------------------------------------- > > Key: BIT-760 > URL: https://bro-tracker.atlassian.net/browse/BIT-760 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: Matthias Vallentin > Assignee: Bernhard Amann > Labels: analyzer > Fix For: 2.3 > > > It would be nice to have the *Subject Alternative Name (SAN)* field of an X.509 certificate available at the scripting layer. It contains a list of domains that should be used in addition to the CN field of the subject to verify that a domain matches the certificate. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:29:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:29:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-699) Reorganizing layout of protocol analyzers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-699: -------------------------- Resolution: Fixed Status: Closed (was: Open) Done. > Reorganizing layout of protocol analyzers > ----------------------------------------- > > Key: BIT-699 > URL: https://bro-tracker.atlassian.net/browse/BIT-699 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > Fix For: 2.2 > > > We should restructure how protocol analyzers are organized inside the > C++ core. Ideally, I'd like to have a single directory per analyzer > with everything in there that relates to that analyzer, with no need > to touch other places (currently, one needs to touch quite many for > adding an analyzer). This includes the analyzers' `{{*.cc}}{{, }}{{*.h}}{{, > }}{{*.bif}}{{, and }}{{*.pac}}{{ files. For the }}{{bif}}{{s, we should also move > the corresponding parts from }}{{event.bif}}{{ and }}{{init-bare.bif}}{{ into > that directory. > This restructuring is also a good opportuntity to reorganize the > Broxygen generation for analyzers: I think it would be nice to have > one page per analyzer that has (1) a general description, (2) all > tuning parameters, (3) all core events, and (4) links to all relevant > }}{{base}}{{ and }}{{policy}}` scripts. > I'm setting this to 2.1 for now. It's not high-priority for that > release and we can bump it further out if necessary. But I think it's > good to keep in mind, and perhaps work on parts of this as time > permits. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:29:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:29:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-699) Reorganizing layout of protocol analyzers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627#comment-14627 ] Seth Hall commented on BIT-699: ------------------------------- I think this ticket was completed by the work Robin did on reorganizing the analyzers for 2.2. > Reorganizing layout of protocol analyzers > ----------------------------------------- > > Key: BIT-699 > URL: https://bro-tracker.atlassian.net/browse/BIT-699 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > Fix For: 2.2 > > > We should restructure how protocol analyzers are organized inside the > C++ core. Ideally, I'd like to have a single directory per analyzer > with everything in there that relates to that analyzer, with no need > to touch other places (currently, one needs to touch quite many for > adding an analyzer). This includes the analyzers' `{{*.cc}}{{, }}{{*.h}}{{, > }}{{*.bif}}{{, and }}{{*.pac}}{{ files. For the }}{{bif}}{{s, we should also move > the corresponding parts from }}{{event.bif}}{{ and }}{{init-bare.bif}}{{ into > that directory. > This restructuring is also a good opportuntity to reorganize the > Broxygen generation for analyzers: I think it would be nice to have > one page per analyzer that has (1) a general description, (2) all > tuning parameters, (3) all core events, and (4) links to all relevant > }}{{base}}{{ and }}{{policy}}` scripts. > I'm setting this to 2.1 for now. It's not high-priority for that > release and we can bump it further out if necessary. But I think it's > good to keep in mind, and perhaps work on parts of this as time > permits. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:31:31 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Thu, 7 Nov 2013 10:31:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1075) Bro Workshop videos In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann updated BIT-1075: -------------------------------- Resolution: Fixed Status: Closed (was: Open) All videos seem to be accessible on youtube now. > Bro Workshop videos > ------------------- > > Key: BIT-1075 > URL: https://bro-tracker.atlassian.net/browse/BIT-1075 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Reporter: Benson Mathews > > Hi, > I was looking to go through the Bro Workshop 2011, but most of the videos doesn't seem to be working. > Could those be made available again. > Thanks, > Benson -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:33:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:33:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-781) Case sensitive (non-normalized) HTTP header names In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-781: -------------------------- Fix Version/s: (was: 2.2) 2.3 > Case sensitive (non-normalized) HTTP header names > ------------------------------------------------- > > Key: BIT-781 > URL: https://bro-tracker.atlassian.net/browse/BIT-781 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: sconzo > Labels: analyzer > Fix For: 2.3 > > > There are a lot of usecases to have access to the normalized HTTP header names, I'm asking for an extension that will allow access to the non-normalized version. This can be used to find non-standard/suspicious HTTP connections. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:33:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:33:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-768) Inline monitoring of modified scripts. In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-768: -------------------------- Fix Version/s: (was: 2.2) 2.3 > Inline monitoring of modified scripts. > -------------------------------------- > > Key: BIT-768 > URL: https://bro-tracker.atlassian.net/browse/BIT-768 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Seth Hall > Assignee: Daniel Thayer > Fix For: 2.3 > > > We need to train users to do check, install, restart through broctl better. I'd like to reduce the barrier to entry a bit more and if broctl can coach new users through the process better and remind existing users of the process it would be great. > Here are my suggestions for what I think needs to be done: > \\- Track hashes for all copied scripts (maybe in broctl.dat?) and watch for changes to notify the user. I think it would be ok to only notify the user when they are in broctl but I can see that people may want that to also check and occasionally email from broctl cron (let's save emailing for later though, inline notification in broctl may be enough). > \\- Track hashes for scripts that have been "checked" because then we can coach people about what step in the process they are at. If someone has already run "check" on the current scripts we can recommend that they need to > \\- Create variables to turn off various suggestions. I think the various suggestions would be "need to check scripts", "need to install scripts", and "ready to restart" or something along those lines. I'm not even sure I like this idea though. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:33:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:33:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-781) Case sensitive (non-normalized) HTTP header names In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630#comment-14630 ] Seth Hall commented on BIT-781: ------------------------------- Well, looks like this didn't happen yet again. We may end up just waiting on this until the HTTP binpac++ analyzer shows up in Bro. > Case sensitive (non-normalized) HTTP header names > ------------------------------------------------- > > Key: BIT-781 > URL: https://bro-tracker.atlassian.net/browse/BIT-781 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: git/master > Reporter: sconzo > Labels: analyzer > Fix For: 2.3 > > > There are a lot of usecases to have access to the normalized HTTP header names, I'm asking for an extension that will allow access to the non-normalized version. This can be used to find non-standard/suspicious HTTP connections. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:35:30 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Thu, 7 Nov 2013 10:35:30 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-66) Bro crashes if &synchronized vars aren't initialized In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann updated BIT-66: ------------------------------ Resolution: Fixed Status: Closed (was: Open) Seems to work now. > Bro crashes if &synchronized vars aren't initialized > ----------------------------------------------------- > > Key: BIT-66 > URL: https://bro-tracker.atlassian.net/browse/BIT-66 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Robin Sommer > > At the workshop, we had this lab exercise of synchronizing a counter: > global c = 0 &synchronized; > If c is not initialized however, Bro crashes: > global c: count &synchronized; -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:37:31 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Thu, 7 Nov 2013 10:37:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-34) Segfault from assigning uninitialized variables to record values In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann updated BIT-34: ------------------------------ Resolution: Fixed Status: Closed (was: Open) Seems to be fixed - does not crash anymore and gives appropriate error messages. > Segfault from assigning uninitialized variables to record values > ---------------------------------------------------------------- > > Key: BIT-34 > URL: https://bro-tracker.atlassian.net/browse/BIT-34 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 1.5.2 > Reporter: Seth Hall > > Contents of the test-crash.bro script: > {noformat} > global asdfasdf; > const blah = [$ports=asdfasdf]; > {noformat} > Running the test-crash script: > {noformat} > (gdb) run test-crash.bro > Starting program: /Users/seth/Desktop/bro/bro.dev/bro.trunk.clean/src/bro test-crash.bro > Reading symbols for shared libraries ++++++++++++. done > ./test-crash.bro, line 1 (asdfasdf): error, no type given > ./test-crash.bro, line 2 ($nothing=asdfasdf): run-time error, uninitialized list value > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00000020 > 0x000430b1 in Val::AsRecordVal (this=0x0) at Val.h:295 > 295 CONVERTER(TYPE_RECORD, RecordVal*, AsRecordVal) > (gdb) bt > #0 0x000430b1 in Val::AsRecordVal (this=0x0) at Val.h:295 > BIT-1 0x0009f0f6 in RecordConstructorExpr::InitVal (this=0xa09190, t=0xa09220, aggr=0xa09290) at Expr.cc:3320 > BIT-2 0x001a96ef in init_val (init=0xa09190, t=0xa09220, aggr=0xa09290) at Var.cc:17 > BIT-3 0x001a9d23 in make_var (id=0xa08e30, t=0xa09220, c=INIT_FULL, init=0xa09190, attr=0x0, dt=VAR_CONST, do_init=1) at Var.cc:152 > BIT-4 0x001a9e08 in add_global (id=0xa08e30, t=0x0, c=INIT_FULL, init=0xa09190, attr=0x0, dt=VAR_CONST) at Var.cc:179 > BIT-5 0x0000f39e in yyparse () at parse.y:803 > BIT-6 0x00003d12 in main (argc=2, argv=0xbffff184) at main.cc:735 > {noformat} -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:51:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:51:31 -0600 (CST) 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=14633#comment-14633 ] Seth Hall commented on BIT-854: ------------------------------- I think the real question with this is what level of support we provide to "dumping" packets in Bro? Right now it's not something we consider much or put much effort into validating that it works correctly. I'm going to remove the milestone from this because it's possible that we address the issue later either by having timemachine actually dump the packets or from further work on protocol analysis through the upcoming binpac++ integration. > 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 (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:51:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:51:31 -0600 (CST) 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: -------------------------- Fix Version/s: (was: 2.2) > 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 (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 08:51:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 10:51:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-856) more documentation for utilities would be cool In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-856: -------------------------- Fix Version/s: 2.3 > more documentation for utilities would be cool > ---------------------------------------------- > > Key: BIT-856 > URL: https://bro-tracker.atlassian.net/browse/BIT-856 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: bro-aux > Affects Versions: git/master > Reporter: Vern Paxson > Fix For: 2.3 > > > Utilities like bro-cut only supply \--help documentation, as far as I can tell. Man pages would be handy. (In particular, I was looking for some sort of statement of exactly to what degree bro-cut can munch on the concatenation of multiple log files that have different column layouts.) -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 11:48:31 2013 From: jira at bro-tracker.atlassian.net (Vern Paxson (JIRA)) Date: Thu, 7 Nov 2013 13:48:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-903) -b turns off -f In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634#comment-14634 ] Vern Paxson commented on BIT-903: --------------------------------- Is it reasonable that -f causes the PacketFilter framework to be loaded? > -b turns off -f > --------------- > > Key: BIT-903 > URL: https://bro-tracker.atlassian.net/browse/BIT-903 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Vern Paxson > Fix For: 2.3 > > Attachments: single-tcp-conn-est.trace > > > Running with \-b (bare bones) disables processing by \-f. Boy did this take me a long time to figure out :-(. > Reproduce using the appended trace. Invoking with *-e 'event connection_established(c:connection) \{ print "yep"; }*' will print "yep". Invoking with that plus *-f 'not tcp*' won't print anything. But invoking with *-f 'not tcp' \-b* _does_ print "yep". -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Thu Nov 7 13:30:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 7 Nov 2013 15:30:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-903) -b turns off -f In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-903: -------------------------- Attachment: signature.asc If we could check command line arguments in Bro scripts we could implement that functionality. ;) > -b turns off -f > --------------- > > Key: BIT-903 > URL: https://bro-tracker.atlassian.net/browse/BIT-903 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Vern Paxson > Fix For: 2.3 > > Attachments: signature.asc, single-tcp-conn-est.trace > > > Running with \-b (bare bones) disables processing by \-f. Boy did this take me a long time to figure out :-(. > Reproduce using the appended trace. Invoking with *-e 'event connection_established(c:connection) \{ print "yep"; }*' will print "yep". Invoking with that plus *-f 'not tcp*' won't print anything. But invoking with *-f 'not tcp' \-b* _does_ print "yep". -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:06:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:06:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-959) Issue with HTTP POST file extraction In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-959: -------------------------- Resolution: Fixed Status: Closed (was: Open) This feature has been replace by the file analysis framework. > Issue with HTTP POST file extraction > ------------------------------------ > > Key: BIT-959 > URL: https://bro-tracker.atlassian.net/browse/BIT-959 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.1 > Reporter: gregoire.moreau > Priority: Low > Fix For: 2.2 > > > I've had a problem with the extraction of HTTP POST file content with bro2.1 stable, there's no problem with incoming content. I use a modified http/file-extract.bro script. > My tests were mainly done with PDF content. > The problem is whenever a 0x0d is found in the content, it is replaced with 0x0d0a. > I've found a little workaround, but I'm not sure about all the borders effects it could have. Also, it may not be the good way to correct the problem... > The workaround is as follow in HTTP.cc : > *************** HTTP_Analyzer::HTTP_Analyzer(Connection* > *** 808,813 **** > \--\- 808,814 \---\- > reply_reason_phrase = 0; > content_line_orig = new ContentLine_Analyzer(conn, true); > + content_line_orig->SetCRLFAsEOL(CR_as_EOL & LF_as_EOL); > AddSupportAnalyzer(content_line_orig); > With the workaround it still add one CRLF at the end of some PDF files. > As I wish to keep the hashes of the files it does matter :) -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:08:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:08:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1022) HTTP bogus events In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1022: --------------------------- Resolution: Fixed Status: Closed (was: Open) Closing since no traffic was ever provided. > HTTP bogus events > ----------------- > > Key: BIT-1022 > URL: https://bro-tracker.atlassian.net/browse/BIT-1022 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.1 > Reporter: thorkill > Priority: High > Labels: http > Fix For: 2.2 > > Attachments: local-http.bro > > > I am using attached script to watch for suspected activity in http-connections. This happens a lot in our network: > > 2013-06-10-16:32:00 HTTP::HTTP_strange_event 87.139.xxx.2xx:3916/tcp \-> xx.xx.xx.xx:80/tcp (uid ngRQOFjBgsg) > bq. unknown_HTTP_method=\{Accept: text/*} (0 missed bytes) > bq. # 87.139.xxx.2xx = p57xxx4xx.dip0.t-ipconnect.de xx.xx.xx.xx = > I can not find out what the problem is. httpd logs tell me that everything was just fine. > In most cases it happens after some POST request but not all the time. > I will provide a pcap if I catch it somehow. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:10:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:10:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1042) Caret in regex pattern doesn't match start of line In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1042: --------------------------- Status: Closed (was: Reopened) Closing this ticket as there is not really any action resulting from it. > Caret in regex pattern doesn't match start of line > -------------------------------------------------- > > Key: BIT-1042 > URL: https://bro-tracker.atlassian.net/browse/BIT-1042 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.1 > Environment: Ubuntu 12.04 and 13.04. Dependencies from apt-get ubuntu repos only. > Reporter: Brian Little > Labels: pattern, regex > Attachments: caret.bro > > > print split_all("some string", /^t/); > I would expect it to not match ^t, but it matches any t in the string. > output: > { > [1] = some s, > [3] = ring, > [2] = t > } > expected: > { > [1] = some string > } > tested on bro 2.1 and github master 2.1-824 -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:10:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:10:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1043) LRU Table implementation In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1043: --------------------------- Affects Version/s: (was: 2.1) git/master > LRU Table implementation > ------------------------ > > Key: BIT-1043 > URL: https://bro-tracker.atlassian.net/browse/BIT-1043 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master > Reporter: Jordi Ros-Giralt > Fix For: 2.3 > > > Attaching below the email description i exchanged with Seth and Robin describing this work. > ------ > Hi Seth and Robin, > We got the repo up, you can get to our branch as follows: > git clone --recursive https://github.com/giralt/bro.git > cd bro/ > git checkout lru-table > We would be happy to contribute this code to the Bro community. This is what it does: > - It implements LRU tables for Bro > - A Bro table can be enhanced with the LRU functionality with the following new table attributes: > &lru_table: enhance the table with LRU functionality > &size_limit=n: if adding an element to the table makes the size of the table larger than n, then drop the LRU element from that table before inserting the new element. n=0 means table size can be infinite (so don't drop elements from it) > &drop_func=callback_func: defines a programmable callback function that gets called automatically every time an element from the LRU table is dropped due to hitting the size_limit. The prototype of this callback must be as follows: > function callback_func(t: table[keytype] of valuetype, key: keytype, val: valuetype): count > - It adds the following bif functions: > function get_lru%(v: any%): any > function get_mru%(v: any%): any > function get_lru_key%(v: any%): any > function get_mru_key%(v: any%): any > - Example: > function freed(t: table[port] of string, key: port, val: string): count { print "Dropped"; } > local port_names: table[port] of string &lru &size_limit=2 &drop_func=freed; > In terms of applications, we are currently using this feature for the chimera-to-bro compiler we are working on: http://www.chimera-query.org/index.html > We thought that we could also use this feature to provide a sort of memory management facility for Bro. I had a talk with Seth some weeks ago about this. Something like the LRU implementation allows programmers to put bounds on the size of tables and prioritize which elements can be dropped first upon memory exhaustion scenarios. Perhaps an idea here would be to develop a garbage collector (could be done using Bro language itself, perhaps as a framework) which would be run upon hitting a certain memory usage watermark and which would mainly run through the set of tables marked as "garbage collectable" dropping LRU elements from them to help reduce/eliminate the risk of running out of memory. > Should this be something interesting, what are the steps we would need to do to open source the LRU code into Bro? -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:10:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:10:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1042) Caret in regex pattern doesn't match start of line In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14638#comment-14638 ] Seth Hall commented on BIT-1042: -------------------------------- Brian, you can refer to the scripts here: https://github.com/sethhall/bro-junk-drawer/tree/master/domain-tld There are some examples of dealing with domain names (and I'm avoiding string creation as much as possible which is good for performance). > Caret in regex pattern doesn't match start of line > -------------------------------------------------- > > Key: BIT-1042 > URL: https://bro-tracker.atlassian.net/browse/BIT-1042 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.1 > Environment: Ubuntu 12.04 and 13.04. Dependencies from apt-get ubuntu repos only. > Reporter: Brian Little > Labels: pattern, regex > Attachments: caret.bro > > > print split_all("some string", /^t/); > I would expect it to not match ^t, but it matches any t in the string. > output: > { > [1] = some s, > [3] = ring, > [2] = t > } > expected: > { > [1] = some string > } > tested on bro 2.1 and github master 2.1-824 -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:12:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:12:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1062) Issues fragmented packets and BRO In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1062: --------------------------- Resolution: Won't Fix Status: Closed (was: Open) We aren't sure these packets are legitimate. > Issues fragmented packets and BRO > --------------------------------- > > Key: BIT-1062 > URL: https://bro-tracker.atlassian.net/browse/BIT-1062 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.1 > Environment: Ubuntu/Debian > Reporter: john blaze > Attachments: fraggy_out_EVILSTUFF, more_frag.pcap > > > I was doing some testing with fragmented attacks trying to bypass IDS sensors and noticed that BRO does not identify/populate the SRC & DST IP's in the weird log and other fields such as the URI in the http.log when doing stuff like: > >>> f=fragment(IP(dst="80.69.77.211")/ICMP()/("X"*50), fragsize=10) > >>> for frag in f: > ... send(frag) > 1377062338.222065 - - - - - excessively_small_fragment - F bro > Also,. I fragmented a GET /EVILSTUFF HTTP request,. and noticed: > 1377056289.770819 - - - - - excessively_small_fragment - F bro > 1377056289.787032 - - - - - fragment_inconsistency - F bro > 1377056290.141267 iL6Ki3ncjV1 192.168.1.5 17384 192.168.1.16 80 unmatched_HTTP_reply - F bro > PCAPS are attached. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:17:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:17:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1090) fatal error Val::CONVERTER In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1090: --------------------------- Resolution: Works for Me Status: Closed (was: Open) > fatal error Val::CONVERTER > -------------------------- > > Key: BIT-1090 > URL: https://bro-tracker.atlassian.net/browse/BIT-1090 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.1 > Environment: Ubuntu 10.04.03 LTS, bro 2.1-179 > Reporter: tyler.schoenke > Attachments: my-detect-bruteforcing.bro, sigsup-ssh-pass2.bro > > > Hi guys, > I get the following message when I modified a data structure in detect-bruteforcing.bro. I didn't get a chance to test against the current version, but did a quick check against the mailing lists and tracker and didn't see this issue mentioned. > $ bro my-detect-bruteforcing.bro sigsup-ssh-pass2.bro > fatal error in ./sigsup-ssh-pass2.bro, line 2: Val::CONVERTER (types/table) (10.0.0.1/32) > Here is the modification to detect-bruteforcing.bro: > const ignore_guessers: table[subnet] of set[subnet] = {} &redef; > I found the need to whitelist from a single host to multiple subnets instead of a single subnet. The following minimal script will produce the error. > cat sigsup-ssh-pass2.bro > redef SSH::ignore_guessers = { > [172.0.0.0/16] = set( 10.0.0.1/32 ) > }; > Any help would be appreciated. > Thanks, > Tyler -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:17:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:17:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1090) fatal error Val::CONVERTER In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14641#comment-14641 ] Seth Hall commented on BIT-1090: -------------------------------- This short test script works for me with 2.2... const foobar: table[subnet] of set[subnet] = table() &redef; redef foobar += { [172.0.0.0/16] = set(10.0.0.1/32) }; > fatal error Val::CONVERTER > -------------------------- > > Key: BIT-1090 > URL: https://bro-tracker.atlassian.net/browse/BIT-1090 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.1 > Environment: Ubuntu 10.04.03 LTS, bro 2.1-179 > Reporter: tyler.schoenke > Attachments: my-detect-bruteforcing.bro, sigsup-ssh-pass2.bro > > > Hi guys, > I get the following message when I modified a data structure in detect-bruteforcing.bro. I didn't get a chance to test against the current version, but did a quick check against the mailing lists and tracker and didn't see this issue mentioned. > $ bro my-detect-bruteforcing.bro sigsup-ssh-pass2.bro > fatal error in ./sigsup-ssh-pass2.bro, line 2: Val::CONVERTER (types/table) (10.0.0.1/32) > Here is the modification to detect-bruteforcing.bro: > const ignore_guessers: table[subnet] of set[subnet] = {} &redef; > I found the need to whitelist from a single host to multiple subnets instead of a single subnet. The following minimal script will produce the error. > cat sigsup-ssh-pass2.bro > redef SSH::ignore_guessers = { > [172.0.0.0/16] = set( 10.0.0.1/32 ) > }; > Any help would be appreciated. > Thanks, > Tyler -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:19:30 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:19:30 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1092) Handling of variable size 802.11 link-headers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1092: --------------------------- Resolution: Rejected Status: Closed (was: Open) No plans to support variable length headers at this time and this ticket doesn't have any concrete tasks in it so I'm closing. > Handling of variable size 802.11 link-headers > ---------------------------------------------- > > Key: BIT-1092 > URL: https://bro-tracker.atlassian.net/browse/BIT-1092 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.0, 2.1 > Reporter: Fahad Arshad > > This issue has been discussed before at this location: > http://comments.gmane.org/gmane.comp.security.detection.bro/3932 > Running Bro on version 2.0 or 2.1 results in the following error > $ bro -r ~/Documents/airportSniff-5000-packets.cap > fatal error: bro: problem with trace file /home/bro/Documents/airportSniff-5000-packets.cap - unknown data link type 0x7f > From my understanding (by looking at get_link_header_size() method in src/PktSrc.cc), currently Bro cannot handle variable size header information. > Is there any future plan to handle variable size header information? -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:24:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:24:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-478) Move BinPAC docs over to new server In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-478: -------------------------- Resolution: Fixed Status: Closed (was: Open) > Move BinPAC docs over to new server > ----------------------------------- > > Key: BIT-478 > URL: https://bro-tracker.atlassian.net/browse/BIT-478 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Reporter: Robin Sommer > Assignee: Daniel Thayer > Fix For: 2.2 > > > There's some BinPAC documentation in the old Wiki that we should move over. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:24:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:24:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-594) Control via git not reliable In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-594: -------------------------- Resolution: Fixed Status: Closed (was: Open) I believe this is about the old tracker. > Control via git not reliable > ---------------------------- > > Key: BIT-594 > URL: https://bro-tracker.atlassian.net/browse/BIT-594 > Project: Bro Issue Tracker > Issue Type: Problem > Components: TicketTracker > Reporter: Robin Sommer > > Adding "Closes #xxx" to commit messages works sometimes, but not > always. See ccad24b68584aabecaf0af69f2202914221be9e4 for a commit > where it didn't. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Fri Nov 8 12:27:31 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 8 Nov 2013 14:27:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-595) Batch edit plugin missing In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-595: -------------------------- Resolution: Fixed Status: Closed (was: Open) About the old tracker. > Batch edit plugin missing > ------------------------- > > Key: BIT-595 > URL: https://bro-tracker.atlassian.net/browse/BIT-595 > Project: Bro Issue Tracker > Issue Type: Problem > Components: TicketTracker > Reporter: Robin Sommer > > The batch edit plugin for Trac has disappaered. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From noreply at bro.org Sat Nov 9 00:00:16 2013 From: noreply at bro.org (Merge Tracker) Date: Sat, 9 Nov 2013 00:00:16 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311090800.rA980GAa025872@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------- ---------- --------------------------------------------------------- 1e43dfc [1] bro Seth Hall 2013-11-08 Fix the irc_reply event for certain server message types. [1] 1e43dfc https://github.com/bro/bro/commit/1e43dfc46aee65a3845cf17bc9207190a20387ac From jira at bro-tracker.atlassian.net Sat Nov 9 18:17:30 2013 From: jira at bro-tracker.atlassian.net (Jon Crussell (JIRA)) Date: Sat, 9 Nov 2013 20:17:30 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1094) Segmentation Fault in SQLite Writer In-Reply-To: References: Message-ID: Jon Crussell created BIT-1094: --------------------------------- Summary: Segmentation Fault in SQLite Writer Key: BIT-1094 URL: https://bro-tracker.atlassian.net/browse/BIT-1094 Project: Bro Issue Tracker Issue Type: Patch Components: Bro Affects Versions: 2.2 Environment: N/A Reporter: Jon Crussell Attachments: 0001-Fixed-Segmentation-fault-in-SQLite-Writer.patch There is a bug in the SQLite Writer that causes a segmentation fault if the field type is TYPE_TABLE or TYPE_VECTOR. The fix is pretty minor, see attached patch. Also available here: https://github.com/jcrussell/bro/tree/topic/jcrussell/sqlite-writer-fix -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From noreply at bro.org Sun Nov 10 00:00:11 2013 From: noreply at bro.org (Merge Tracker) Date: Sun, 10 Nov 2013 00:00:11 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311100800.rAA80BgZ002508@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------- ---------- --------------------------------------------------------- 1e43dfc [1] bro Seth Hall 2013-11-08 Fix the irc_reply event for certain server message types. [1] 1e43dfc https://github.com/bro/bro/commit/1e43dfc46aee65a3845cf17bc9207190a20387ac From jira at bro-tracker.atlassian.net Sun Nov 10 07:40:31 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Sun, 10 Nov 2013 09:40:31 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1094) Segmentation Fault in SQLite Writer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann reassigned BIT-1094: ----------------------------------- Assignee: Bernhard Amann > Segmentation Fault in SQLite Writer > ----------------------------------- > > Key: BIT-1094 > URL: https://bro-tracker.atlassian.net/browse/BIT-1094 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.2 > Environment: N/A > Reporter: Jon Crussell > Assignee: Bernhard Amann > Attachments: 0001-Fixed-Segmentation-fault-in-SQLite-Writer.patch > > > There is a bug in the SQLite Writer that causes a segmentation fault if the field type is TYPE_TABLE or TYPE_VECTOR. The fix is pretty minor, see attached patch. > Also available here: > https://github.com/jcrussell/bro/tree/topic/jcrussell/sqlite-writer-fix -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Sun Nov 10 22:09:03 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Mon, 11 Nov 2013 00:09:03 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1094) Segmentation Fault in SQLite Writer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann updated BIT-1094: -------------------------------- Status: Merge Request (was: Open) > Segmentation Fault in SQLite Writer > ----------------------------------- > > Key: BIT-1094 > URL: https://bro-tracker.atlassian.net/browse/BIT-1094 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.2 > Environment: N/A > Reporter: Jon Crussell > Assignee: Bernhard Amann > Attachments: 0001-Fixed-Segmentation-fault-in-SQLite-Writer.patch > > > There is a bug in the SQLite Writer that causes a segmentation fault if the field type is TYPE_TABLE or TYPE_VECTOR. The fix is pretty minor, see attached patch. > Also available here: > https://github.com/jcrussell/bro/tree/topic/jcrussell/sqlite-writer-fix -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Sun Nov 10 22:09:03 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Mon, 11 Nov 2013 00:09:03 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1094) Segmentation Fault in SQLite Writer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700#comment-14700 ] Bernhard Amann commented on BIT-1094: ------------------------------------- Thank you very much for the fix - it is committed to topic/bernhard/ticket1094 with a minimal testcase. > Segmentation Fault in SQLite Writer > ----------------------------------- > > Key: BIT-1094 > URL: https://bro-tracker.atlassian.net/browse/BIT-1094 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.2 > Environment: N/A > Reporter: Jon Crussell > Assignee: Bernhard Amann > Attachments: 0001-Fixed-Segmentation-fault-in-SQLite-Writer.patch > > > There is a bug in the SQLite Writer that causes a segmentation fault if the field type is TYPE_TABLE or TYPE_VECTOR. The fix is pretty minor, see attached patch. > Also available here: > https://github.com/jcrussell/bro/tree/topic/jcrussell/sqlite-writer-fix -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From noreply at bro.org Mon Nov 11 00:00:14 2013 From: noreply at bro.org (Merge Tracker) Date: Mon, 11 Nov 2013 00:00:14 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311110800.rAB80EXX012289@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------ -------------- ---------- ------------- ---------- ----------------------------------- BIT-1094 [1] Bro Jon Crussell Bernhard Amann 2013-11-11 - Normal Segmentation Fault in SQLite Writer Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------- ---------- --------------------------------------------------------- 1e43dfc [2] bro Seth Hall 2013-11-08 Fix the irc_reply event for certain server message types. [1] BIT-1094 https://bro-tracker.atlassian.net/browse/BIT-1094 [2] 1e43dfc https://github.com/bro/bro/commit/1e43dfc46aee65a3845cf17bc9207190a20387ac From jira at bro-tracker.atlassian.net Mon Nov 11 13:40:02 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 11 Nov 2013 15:40:02 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1095) Meta ticker tracking patches for potential 2.2.1 In-Reply-To: References: Message-ID: Robin Sommer created BIT-1095: --------------------------------- Summary: Meta ticker tracking patches for potential 2.2.1 Key: BIT-1095 URL: https://bro-tracker.atlassian.net/browse/BIT-1095 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.2 Reporter: Robin Sommer I'm creating this ticket to track commit that we would want to back port to 2.2 if ended up doing a bug fix release 2.2.1 -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Mon Nov 11 13:42:02 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 11 Nov 2013 15:42:02 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1095) Meta ticker tracking patches for potential 2.2.1 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1095: ------------------------------ Description: I'm creating this ticket to track commits that we would want to back port to 2.2 if ended up doing a bug fix release 2.2.1 (was: I'm creating this ticket to track commit that we would want to back port to 2.2 if ended up doing a bug fix release 2.2.1) > Meta ticker tracking patches for potential 2.2.1 > ------------------------------------------------ > > Key: BIT-1095 > URL: https://bro-tracker.atlassian.net/browse/BIT-1095 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.2 > Reporter: Robin Sommer > > I'm creating this ticket to track commits that we would want to back port to 2.2 if ended up doing a bug fix release 2.2.1 -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Mon Nov 11 13:58:03 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 11 Nov 2013 15:58:03 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1095) Meta ticker tracking patches for potential 2.2.1 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14701#comment-14701 ] Robin Sommer commented on BIT-1095: ----------------------------------- Add to 2.2.1 > Meta ticker tracking patches for potential 2.2.1 > ------------------------------------------------ > > Key: BIT-1095 > URL: https://bro-tracker.atlassian.net/browse/BIT-1095 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.2 > Reporter: Robin Sommer > > I'm creating this ticket to track commits that we would want to back port to 2.2 if ended up doing a bug fix release 2.2.1 -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Mon Nov 11 13:58:03 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 11 Nov 2013 15:58:03 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1094) Segmentation Fault in SQLite Writer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1094: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Segmentation Fault in SQLite Writer > ----------------------------------- > > Key: BIT-1094 > URL: https://bro-tracker.atlassian.net/browse/BIT-1094 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.2 > Environment: N/A > Reporter: Jon Crussell > Assignee: Bernhard Amann > Attachments: 0001-Fixed-Segmentation-fault-in-SQLite-Writer.patch > > > There is a bug in the SQLite Writer that causes a segmentation fault if the field type is TYPE_TABLE or TYPE_VECTOR. The fix is pretty minor, see attached patch. > Also available here: > https://github.com/jcrussell/bro/tree/topic/jcrussell/sqlite-writer-fix -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From noreply at bro.org Thu Nov 14 00:00:18 2013 From: noreply at bro.org (Merge Tracker) Date: Thu, 14 Nov 2013 00:00:18 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311140800.rAE80I25021099@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------- ---------- -------------------------------------------------- 0d3115c [1] cmake Jon Siwek 2013-11-13 Make "install-example-configs" target use DESTDIR. [1] 0d3115c https://github.com/bro/cmake/commit/0d3115c3597f5f67c15eb27cb37b9ead0db082b9 From jira at bro-tracker.atlassian.net Thu Nov 14 10:14:03 2013 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 14 Nov 2013 12:14:03 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1006) topic/dnthayer/broctl-testing In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1006: ------------------------------- Resolution: Fixed Status: Closed (was: Open) The test failures have been fixed. > topic/dnthayer/broctl-testing > ----------------------------- > > Key: BIT-1006 > URL: https://bro-tracker.atlassian.net/browse/BIT-1006 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Daniel Thayer > Assignee: Daniel Thayer > Fix For: 2.2 > > > This branch contains an automated test suite for broctl. > Included are tests of all broctl commands and plugins, and > tests that broctl can read all three of its config files > correctly. > All tests rely on btest, and Makefile targets > have been added to run all tests. Each test runs > with its own unique Bro install prefix, so a test > case does not have any affect on any others (the only > exception is a small number of test cases that use > broctl commands that rely on broccoli, but these > have been serialized to avoid problems). > There were two changes to broctl itself needed to support the test suite. > First, the ability to specify the location of the broctl install > via an environment variable (if not defined, then the > hard-coded path is used instead) was added. Another change > was to allow the manager in a cluster to be on localhost > (in that case, all other nodes must also be on localhost). -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From noreply at bro.org Fri Nov 15 00:00:12 2013 From: noreply at bro.org (Merge Tracker) Date: Fri, 15 Nov 2013 00:00:12 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311150800.rAF80C5R010368@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------- ---------- -------------------------------------------------- 0d3115c [1] cmake Jon Siwek 2013-11-13 Make "install-example-configs" target use DESTDIR. [1] 0d3115c https://github.com/bro/cmake/commit/0d3115c3597f5f67c15eb27cb37b9ead0db082b9 From noreply at bro.org Sat Nov 16 00:00:12 2013 From: noreply at bro.org (Merge Tracker) Date: Sat, 16 Nov 2013 00:00:12 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311160800.rAG80CDh029182@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ---------------------------- 3effe5d [1] bro Daniel Thayer 2013-11-15 Update local.bro for Bro 2.2 [1] 3effe5d https://github.com/bro/bro/commit/3effe5df084255dbe7f8613862f522007b0b3133 From noreply at bro.org Sun Nov 17 00:00:10 2013 From: noreply at bro.org (Merge Tracker) Date: Sun, 17 Nov 2013 00:00:10 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311170800.rAH80AFh003193@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ---------------------------- 3effe5d [1] bro Daniel Thayer 2013-11-15 Update local.bro for Bro 2.2 [1] 3effe5d https://github.com/bro/bro/commit/3effe5df084255dbe7f8613862f522007b0b3133 From noreply at bro.org Mon Nov 18 00:00:14 2013 From: noreply at bro.org (Merge Tracker) Date: Mon, 18 Nov 2013 00:00:14 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311180800.rAI80EaL013304@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ---------------------------- 3effe5d [1] bro Daniel Thayer 2013-11-15 Update local.bro for Bro 2.2 [1] 3effe5d https://github.com/bro/bro/commit/3effe5df084255dbe7f8613862f522007b0b3133 From robin at icir.org Mon Nov 18 07:52:18 2013 From: robin at icir.org (Robin Sommer) Date: Mon, 18 Nov 2013 07:52:18 -0800 Subject: [Bro-Dev] [Auto] Merge Status In-Reply-To: <201311180800.rAI80EaL013304@bro-ids.icir.org> References: <201311180800.rAI80EaL013304@bro-ids.icir.org> Message-ID: <20131118155218.GD58630@icir.org> On Mon, Nov 18, 2013 at 00:00 -0800, you wrote: > 3effe5d [1] bro Daniel Thayer 2013-11-15 Update local.bro for Bro 2.2 Daniel, rathter than simply removing the piece of code, can we put in a 2.2 version instead to achieve the same effect? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From dnthayer at illinois.edu Mon Nov 18 11:05:44 2013 From: dnthayer at illinois.edu (Daniel Thayer) Date: Mon, 18 Nov 2013 13:05:44 -0600 Subject: [Bro-Dev] [Auto] Merge Status In-Reply-To: <20131118155218.GD58630@icir.org> References: <201311180800.rAI80EaL013304@bro-ids.icir.org> <20131118155218.GD58630@icir.org> Message-ID: <528A6508.3080704@illinois.edu> On 11/18/2013 09:52 AM, Robin Sommer wrote: > > On Mon, Nov 18, 2013 at 00:00 -0800, you wrote: > >> 3effe5d [1] bro Daniel Thayer 2013-11-15 Update local.bro for Bro 2.2 > > Daniel, rathter than simply removing the piece of code, can we put in > a 2.2 version instead to achieve the same effect? > > Robin > I think it's a bad idea to have script code in local.bro (besides "@load") because it will not be updated when a user upgrades to a newer release of Bro. Also, the fact that it's commented-out by default means it's not going to be tested, and most likely nobody will notice (for a while) when something else changes that breaks that code. Perhaps instead we could put something in scripts/policy/misc/ (or somewhere else?), and then @load that from local.bro (the @load would be commented-out by default). From jsiwek at illinois.edu Mon Nov 18 11:28:36 2013 From: jsiwek at illinois.edu (Siwek, Jonathan Luke) Date: Mon, 18 Nov 2013 19:28:36 +0000 Subject: [Bro-Dev] [Auto] Merge Status In-Reply-To: <20131118155218.GD58630@icir.org> References: <201311180800.rAI80EaL013304@bro-ids.icir.org> <20131118155218.GD58630@icir.org> Message-ID: <22FEF537-C5AE-4093-8A86-5FFCA7F7F548@illinois.edu> On Nov 18, 2013, at 9:52 AM, Robin Sommer wrote: > > On Mon, Nov 18, 2013 at 00:00 -0800, you wrote: > >> 3effe5d [1] bro Daniel Thayer 2013-11-15 Update local.bro for Bro 2.2 > > Daniel, rathter than simply removing the piece of code, can we put in > a 2.2 version instead to achieve the same effect? Even though the example would be commented out, that's defying the ?best practice? of the only code in local.bro being @loads ? it generally simplifies the upgrade procedure both for a user that wants to use the new upstream version and for a dev/maintainer that wants to set new defaults for things. Maybe putting the example closer to the Notice::policy documentation (either within the Broxygen comments or the general Notice Framework docs) is better. There, it?s easier to regression test, more likely to be changed if a dev makes incompatible changes to notice scripts, and more accessible to users. - Jon From robin at icir.org Mon Nov 18 14:04:32 2013 From: robin at icir.org (Robin Sommer) Date: Mon, 18 Nov 2013 14:04:32 -0800 Subject: [Bro-Dev] [Auto] Merge Status In-Reply-To: <528A6508.3080704@illinois.edu> References: <201311180800.rAI80EaL013304@bro-ids.icir.org> <20131118155218.GD58630@icir.org> <528A6508.3080704@illinois.edu> Message-ID: <20131118220432.GU58630@icir.org> Ok, makes sense to leave it out of local.bro. Whether to put it elsewhere depends on how many people might actually use it I guess. I'll merge as is for now. Robin On Mon, Nov 18, 2013 at 13:05 -0600, you wrote: > On 11/18/2013 09:52 AM, Robin Sommer wrote: >> >> On Mon, Nov 18, 2013 at 00:00 -0800, you wrote: >> >>> 3effe5d [1] bro Daniel Thayer 2013-11-15 Update local.bro for Bro 2.2 >> >> Daniel, rathter than simply removing the piece of code, can we put in >> a 2.2 version instead to achieve the same effect? >> >> Robin >> > > I think it's a bad idea to have script code in local.bro (besides > "@load") because it will not be updated when a user upgrades to a > newer release of Bro. Also, the fact that it's commented-out by > default means it's not going to be tested, and most likely nobody > will notice (for a while) when something else changes that breaks > that code. > > Perhaps instead we could put something in scripts/policy/misc/ (or > somewhere else?), and then @load that from local.bro (the @load > would be commented-out by default). > > -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From noreply at bro.org Tue Nov 19 00:00:12 2013 From: noreply at bro.org (Merge Tracker) Date: Tue, 19 Nov 2013 00:00:12 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311190800.rAJ80Cgv011762@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ---------------------------- 3effe5d [1] bro Daniel Thayer 2013-11-15 Update local.bro for Bro 2.2 [1] 3effe5d https://github.com/bro/bro/commit/3effe5df084255dbe7f8613862f522007b0b3133 From anthony.kasza at gmail.com Thu Nov 21 19:33:46 2013 From: anthony.kasza at gmail.com (anthony kasza) Date: Thu, 21 Nov 2013 19:33:46 -0800 Subject: [Bro-Dev] Bare Mode Message-ID: Hey All, Looking at the diff between the output of the two commands I was slightly surprised. bro -e 'event bro_script_loaded(script: string, levels: count) { print script; }' bro -be 'event bro_script_loaded(script: string, levels: count) { print script; }' I'm curious if Bro in bare mode is ever used for anything. I'm not surprised to see bare mode include bifs. Is there a design decision why bare mode includes things like the input and logging framework but not the protocol directories that make use of them (e.g. bro/base/protocols/conn) ? -AK From jsiwek at illinois.edu Fri Nov 22 07:38:23 2013 From: jsiwek at illinois.edu (Siwek, Jonathan Luke) Date: Fri, 22 Nov 2013 15:38:23 +0000 Subject: [Bro-Dev] Bare Mode In-Reply-To: References: Message-ID: On Nov 21, 2013, at 9:33 PM, anthony kasza wrote: > I'm curious if Bro in bare mode is ever used for anything. The intention for mode is to allow users more choice in what script-level functionality to load. In practice, I don?t know how often it?s used for that. The other thing I frequently use it for is unit tests, where I want minimal test cases and faster parse time. > I'm not surprised to see bare mode include bifs. Is there a design decision > why bare mode includes things like the input and logging framework but > not the protocol directories that make use of them (e.g. > bro/base/protocols/conn) ? If it?s something that?s tightly coupled with internals and only has parse-time performance cost, then that?s something to expect to be loaded in bare mode. The protocol analysis packages don?t satisfy either condition ? internals don?t depend on them to be loaded and loading them can have run-time performance costs. - Jon From robin at icir.org Fri Nov 22 07:52:06 2013 From: robin at icir.org (Robin Sommer) Date: Fri, 22 Nov 2013 07:52:06 -0800 Subject: [Bro-Dev] Bare Mode In-Reply-To: References: Message-ID: <20131122155206.GB63431@icir.org> On Fri, Nov 22, 2013 at 15:38 +0000, you wrote: > The intention for mode is to allow users more choice in what > script-level functionality to load. In practice, I don?t know how > often it?s used for that. I'll add that bare mode is essentially what used to be the default configuration in Bro <2.0. So it's also a way to get back to the old approach where you would add things as you need them. Bro is more difficult to use that way but it can reduce resource usage quite a bit if one really only needs a couple pieces. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From jira at bro-tracker.atlassian.net Fri Nov 22 12:36:12 2013 From: jira at bro-tracker.atlassian.net (Ryan Schmidt (JIRA)) Date: Fri, 22 Nov 2013 14:36:12 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1096) Should check version of libmagic not version of file In-Reply-To: References: Message-ID: Ryan Schmidt created BIT-1096: --------------------------------- Summary: Should check version of libmagic not version of file Key: BIT-1096 URL: https://bro-tracker.atlassian.net/browse/BIT-1096 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.2 Environment: Mac OS X 10.6.8; libmagic and other dependencies installed using MacPorts Reporter: Ryan Schmidt As far as I can tell, bro requires the libmagic library, but not the file program. However bro's configuration script appears not to be checking the version of the libmagic library, but the version of the file program. This is a problem in distributions like MacPorts where the libmagic library and the file program are in separate packages; installing the libmagic package does not mean you will automatically get the corresponding version of the file program. This causes a build failure on Mac OS X 10.6 Snow Leopard for example which ships with /usr/bin/file version 5.03. Even though libmagic 5.15 is installed from MacPorts, bro fails to configure, thinking it's too old. The MacPorts project's bug report for that is https://trac.macports.org/ticket/41457 Could you change bro's configuration script to check the version of libmagic instead? You can check MAGIC_VERSION in magic.h. -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206) From jira at bro-tracker.atlassian.net Fri Nov 22 14:20:12 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Fri, 22 Nov 2013 16:20:12 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1096) Should check version of libmagic not version of file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14800#comment-14800 ] Jon Siwek commented on BIT-1096: -------------------------------- Looks like MAGIC_VERSION doesn't appear in magic.h until libmagic 5.13, which is probably why it's currently looking in {{file --version}} output for version info. Is it sufficient to use MAGIC_VERSION if available and fallback on {{file --version}} ? Or is there a better way to extract the version from older libmagics? > Should check version of libmagic not version of file > ---------------------------------------------------- > > Key: BIT-1096 > URL: https://bro-tracker.atlassian.net/browse/BIT-1096 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.2 > Environment: Mac OS X 10.6.8; libmagic and other dependencies installed using MacPorts > Reporter: Ryan Schmidt > > As far as I can tell, bro requires the libmagic library, but not the file program. However bro's configuration script appears not to be checking the version of the libmagic library, but the version of the file program. This is a problem in distributions like MacPorts where the libmagic library and the file program are in separate packages; installing the libmagic package does not mean you will automatically get the corresponding version of the file program. > This causes a build failure on Mac OS X 10.6 Snow Leopard for example which ships with /usr/bin/file version 5.03. Even though libmagic 5.15 is installed from MacPorts, bro fails to configure, thinking it's too old. The MacPorts project's bug report for that is https://trac.macports.org/ticket/41457 > Could you change bro's configuration script to check the version of libmagic instead? You can check MAGIC_VERSION in magic.h. -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206) From jira at bro-tracker.atlassian.net Fri Nov 22 14:39:12 2013 From: jira at bro-tracker.atlassian.net (Ryan Schmidt (JIRA)) Date: Fri, 22 Nov 2013 16:39:12 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1096) Should check version of libmagic not version of file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14801#comment-14801 ] Ryan Schmidt commented on BIT-1096: ----------------------------------- bq. Looks like MAGIC_VERSION doesn't appear in magic.h until libmagic 5.13, which is probably why it's currently looking in {{file --version}} output for version info. Oh. Well drat. bq. Is it sufficient to use MAGIC_VERSION if available and fallback on {{file --version}} ? Or is there a better way to extract the version from older libmagics? That would address my immediate concern. There doesn't seem to be a {{libmagic-config}} program or pkg-config .pc file for libmagic so I don't know how else to check its version. > Should check version of libmagic not version of file > ---------------------------------------------------- > > Key: BIT-1096 > URL: https://bro-tracker.atlassian.net/browse/BIT-1096 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.2 > Environment: Mac OS X 10.6.8; libmagic and other dependencies installed using MacPorts > Reporter: Ryan Schmidt > > As far as I can tell, bro requires the libmagic library, but not the file program. However bro's configuration script appears not to be checking the version of the libmagic library, but the version of the file program. This is a problem in distributions like MacPorts where the libmagic library and the file program are in separate packages; installing the libmagic package does not mean you will automatically get the corresponding version of the file program. > This causes a build failure on Mac OS X 10.6 Snow Leopard for example which ships with /usr/bin/file version 5.03. Even though libmagic 5.15 is installed from MacPorts, bro fails to configure, thinking it's too old. The MacPorts project's bug report for that is https://trac.macports.org/ticket/41457 > Could you change bro's configuration script to check the version of libmagic instead? You can check MAGIC_VERSION in magic.h. -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206) From jira at bro-tracker.atlassian.net Fri Nov 22 18:09:13 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 22 Nov 2013 20:09:13 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1096) Should check version of libmagic not version of file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14802#comment-14802 ] Seth Hall commented on BIT-1096: -------------------------------- Unfortunately there probably isn't much we will do about this. We're already had some early discussions about forking and modifying libmagic and building it directly into Bro which would make it problem go away. I'm going to close this ticket because it's unlikely we'll address it before taking some other course of action anyway. > Should check version of libmagic not version of file > ---------------------------------------------------- > > Key: BIT-1096 > URL: https://bro-tracker.atlassian.net/browse/BIT-1096 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.2 > Environment: Mac OS X 10.6.8; libmagic and other dependencies installed using MacPorts > Reporter: Ryan Schmidt > > As far as I can tell, bro requires the libmagic library, but not the file program. However bro's configuration script appears not to be checking the version of the libmagic library, but the version of the file program. This is a problem in distributions like MacPorts where the libmagic library and the file program are in separate packages; installing the libmagic package does not mean you will automatically get the corresponding version of the file program. > This causes a build failure on Mac OS X 10.6 Snow Leopard for example which ships with /usr/bin/file version 5.03. Even though libmagic 5.15 is installed from MacPorts, bro fails to configure, thinking it's too old. The MacPorts project's bug report for that is https://trac.macports.org/ticket/41457 > Could you change bro's configuration script to check the version of libmagic instead? You can check MAGIC_VERSION in magic.h. -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206) From jira at bro-tracker.atlassian.net Fri Nov 22 18:11:12 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Fri, 22 Nov 2013 20:11:12 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1096) Should check version of libmagic not version of file In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1096: --------------------------- Resolution: Won't Fix Status: Closed (was: Open) Unfortunately there isn't a better way to check the version at this time. > Should check version of libmagic not version of file > ---------------------------------------------------- > > Key: BIT-1096 > URL: https://bro-tracker.atlassian.net/browse/BIT-1096 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.2 > Environment: Mac OS X 10.6.8; libmagic and other dependencies installed using MacPorts > Reporter: Ryan Schmidt > > As far as I can tell, bro requires the libmagic library, but not the file program. However bro's configuration script appears not to be checking the version of the libmagic library, but the version of the file program. This is a problem in distributions like MacPorts where the libmagic library and the file program are in separate packages; installing the libmagic package does not mean you will automatically get the corresponding version of the file program. > This causes a build failure on Mac OS X 10.6 Snow Leopard for example which ships with /usr/bin/file version 5.03. Even though libmagic 5.15 is installed from MacPorts, bro fails to configure, thinking it's too old. The MacPorts project's bug report for that is https://trac.macports.org/ticket/41457 > Could you change bro's configuration script to check the version of libmagic instead? You can check MAGIC_VERSION in magic.h. -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206) From vern at icir.org Sat Nov 23 17:08:53 2013 From: vern at icir.org (Vern Paxson) Date: Sat, 23 Nov 2013 17:08:53 -0800 Subject: [Bro-Dev] Bare Mode In-Reply-To: <20131122155206.GB63431@icir.org> (Fri, 22 Nov 2013 07:52:06 PST). Message-ID: <20131124010853.319672C4003@rock.ICSI.Berkeley.EDU> Yeah, I sometimes find when running on ginormous traces with limited disk space available for (what will be massive) logs that -b really helps. Vern From jira at bro-tracker.atlassian.net Mon Nov 25 09:30:40 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 25 Nov 2013 11:30:40 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1097) Unexpected string indexing behavior In-Reply-To: References: Message-ID: Robin Sommer created BIT-1097: --------------------------------- Summary: Unexpected string indexing behavior Key: BIT-1097 URL: https://bro-tracker.atlassian.net/browse/BIT-1097 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.2 Reporter: Robin Sommer Playing with string indexing/slicing, I'm seeing some (I think) non-intuitive behavior: {code} global s = "012345"; print "A"; print s[1:-1]; print s[1:-2]; print s[1:-3]; print s[1:-4]; print s[1:-5]; print s[1:-6]; print s[1:-7]; print s[1:-8]; print s[1:-9]; print ""; print "B"; print s[-1:-1]; print s[-1:-2]; print s[-1:-3]; print s[-1:-4]; {code} This prints: {code} A 12345 1234 123 12 1 12345 12345 12345 B 5 5 5 {code} I would instead have expected: (1) A to print empty lines for all cases with the 2nd index <= -6? (2) B to print empty lines for all cases with the 2nd index <= -2? So, is this intentional? -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206) From jira at bro-tracker.atlassian.net Mon Nov 25 14:38:40 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 25 Nov 2013 16:38:40 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1098) topic/jsiwek/broxygen In-Reply-To: References: Message-ID: Jon Siwek created BIT-1098: ------------------------------ Summary: topic/jsiwek/broxygen Key: BIT-1098 URL: https://bro-tracker.atlassian.net/browse/BIT-1098 Project: Bro Issue Tracker Issue Type: Improvement Components: Bro, Broccoli Affects Versions: git/master Reporter: Jon Siwek Fix For: 2.3 This branch is in the bro and broccoli repos and improves the automated script-reference documentation generation process, broxygen. This should address issues in BIT-701 and BIT-751, let me know if there's anything not covered that's still relevant. Highlights: - Remove {{--doc-scripts}} and {{-Z}} options to toggle documentation mode -- the parser is now always instrumented to gather documentation from comments of the form "##", "##!", or "##<". - Raw comments are available at runtime through several BIF functions: {{get_*_comments}}; - Add {{--broxygen}} and {{-X}} options to toggle generating reST-format documentation output, driven by a config file argument. - Add a "broxygen" Sphinx extension domain, allowing certain pieces of documentation to be generated on-the-fly via invoking a Bro process. Re-organized/cleaned up the Sphinx source tree in {{doc/}} to use this in some places. -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206) From jira at bro-tracker.atlassian.net Mon Nov 25 14:38:40 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 25 Nov 2013 16:38:40 -0600 (CST) Subject: [Bro-Dev] [JIRA] (BIT-1098) topic/jsiwek/broxygen In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1098: --------------------------- Status: Merge Request (was: Open) > topic/jsiwek/broxygen > --------------------- > > Key: BIT-1098 > URL: https://bro-tracker.atlassian.net/browse/BIT-1098 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro, Broccoli > Affects Versions: git/master > Reporter: Jon Siwek > Fix For: 2.3 > > > This branch is in the bro and broccoli repos and improves the automated script-reference documentation generation process, broxygen. > This should address issues in BIT-701 and BIT-751, let me know if there's anything not covered that's still relevant. > Highlights: > - Remove {{--doc-scripts}} and {{-Z}} options to toggle documentation mode -- the parser is now always instrumented to gather documentation from comments of the form "##", "##!", or "##<". > - Raw comments are available at runtime through several BIF functions: {{get_*_comments}}; > - Add {{--broxygen}} and {{-X}} options to toggle generating reST-format documentation output, driven by a config file argument. > - Add a "broxygen" Sphinx extension domain, allowing certain pieces of documentation to be generated on-the-fly via invoking a Bro process. Re-organized/cleaned up the Sphinx source tree in {{doc/}} to use this in some places. -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206) From noreply at bro.org Tue Nov 26 00:00:16 2013 From: noreply at bro.org (Merge Tracker) Date: Tue, 26 Nov 2013 00:00:16 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311260800.rAQ80G5h026120@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ------------ ---------- ---------- ---------- ------------- ---------- ------------------------- BIT-1098 [1] Bro,Broccoli Jon Siwek - 2013-11-25 2.3 Normal topic/jsiwek/broxygen [2] [1] BIT-1098 https://bro-tracker.atlassian.net/browse/BIT-1098 [2] broxygen https://github.com/bro/bro,broccoli/tree/topic/jsiwek/broxygen From noreply at bro.org Wed Nov 27 00:00:16 2013 From: noreply at bro.org (Merge Tracker) Date: Wed, 27 Nov 2013 00:00:16 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311270800.rAR80GQL005314@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ------------ ---------- ---------- ---------- ------------- ---------- ------------------------- BIT-1098 [1] Bro,Broccoli Jon Siwek - 2013-11-25 2.3 Normal topic/jsiwek/broxygen [2] [1] BIT-1098 https://bro-tracker.atlassian.net/browse/BIT-1098 [2] broxygen https://github.com/bro/bro,broccoli/tree/topic/jsiwek/broxygen From noreply at bro.org Thu Nov 28 00:00:12 2013 From: noreply at bro.org (Merge Tracker) Date: Thu, 28 Nov 2013 00:00:12 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311280800.rAS80ChL011997@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ------------ ---------- ---------- ---------- ------------- ---------- ------------------------- BIT-1098 [1] Bro,Broccoli Jon Siwek - 2013-11-25 2.3 Normal topic/jsiwek/broxygen [2] [1] BIT-1098 https://bro-tracker.atlassian.net/browse/BIT-1098 [2] broxygen https://github.com/bro/bro,broccoli/tree/topic/jsiwek/broxygen From noreply at bro.org Fri Nov 29 00:00:24 2013 From: noreply at bro.org (Merge Tracker) Date: Fri, 29 Nov 2013 00:00:24 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311290800.rAT80O96019481@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ------------ ---------- ---------- ---------- ------------- ---------- ------------------------- BIT-1098 [1] Bro,Broccoli Jon Siwek - 2013-11-25 2.3 Normal topic/jsiwek/broxygen [2] [1] BIT-1098 https://bro-tracker.atlassian.net/browse/BIT-1098 [2] broxygen https://github.com/bro/bro,broccoli/tree/topic/jsiwek/broxygen From noreply at bro.org Sat Nov 30 00:00:14 2013 From: noreply at bro.org (Merge Tracker) Date: Sat, 30 Nov 2013 00:00:14 -0800 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201311300800.rAU80Elw024488@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ------------ ---------- ---------- ---------- ------------- ---------- ------------------------- BIT-1098 [1] Bro,Broccoli Jon Siwek - 2013-11-25 2.3 Normal topic/jsiwek/broxygen [2] [1] BIT-1098 https://bro-tracker.atlassian.net/browse/BIT-1098 [2] broxygen https://github.com/bro/bro,broccoli/tree/topic/jsiwek/broxygen From leres at ee.lbl.gov Sat Nov 30 17:51:22 2013 From: leres at ee.lbl.gov (Craig Leres) Date: Sat, 30 Nov 2013 17:51:22 -0800 Subject: [Bro-Dev] Fwd: [REL - 10amd64-default][security/bro] Failed for bro-2.2 in build In-Reply-To: <201311300808.rAU88xFv086973@beefy2.isc.freebsd.org> References: <201311300808.rAU88xFv086973@beefy2.isc.freebsd.org> Message-ID: <529A961A.4090809@ee.lbl.gov> Sounds like FreeBSD has upgraded to a newer version of clang and it doesn't like to build /src/logging/writers/SQLite.cc anymore. It's the last few lines of the attached message that shows the problem, is there an obvious fix? Thanks! Craig -------------- next part -------------- An embedded message was scrubbed... From: pkg-fallout at FreeBSD.org Subject: [REL - 10amd64-default][security/bro] Failed for bro-2.2 in build Date: Sat, 30 Nov 2013 08:08:59 GMT Size: 55003 Url: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20131130/4aaab953/attachment-0001.eml