From noreply at bro.org Tue Oct 1 00:00:11 2013 From: noreply at bro.org (Merge Tracker) Date: Tue, 1 Oct 2013 00:00:11 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310010700.r9170Bxd019900@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ------------------------------------------------ ---------- ------------ ---------- ------------- ---------- ------------------------- BIT-1085 [1] BinPAC,Bro,Broccoli,broccoli-python,pysubnettree Jon Siwek Robin Sommer 2013-09-27 2.2 Normal topic/jsiwek/coverity [2] [1] BIT-1085 https://bro-tracker.atlassian.net/browse/BIT-1085 [2] coverity https://github.com/bro/binpac,bro,broccoli,broccoli-python,pysubnettree/tree/topic/jsiwek/coverity From jira at bro-tracker.atlassian.net Tue Oct 1 16:06:28 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Tue, 1 Oct 2013 18:06:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1086) merge topic/bernhard/new-ciphers In-Reply-To: References: Message-ID: Bernhard Amann created BIT-1086: ----------------------------------- Summary: merge topic/bernhard/new-ciphers Key: BIT-1086 URL: https://bro-tracker.atlassian.net/browse/BIT-1086 Project: Bro Issue Tracker Issue Type: Improvement Components: Bro Affects Versions: git/master, 2.2 Reporter: Bernhard Amann Fix For: 2.2 topic/bernhard/new-ciphers adds new ssl ciphers to the constants lists and also adds a few ciphers to the lookup table that were apparently forgotten in the past. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Tue Oct 1 16:06:28 2013 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Tue, 1 Oct 2013 18:06:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1086) merge topic/bernhard/new-ciphers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann updated BIT-1086: -------------------------------- Status: Merge Request (was: Open) > merge topic/bernhard/new-ciphers > -------------------------------- > > Key: BIT-1086 > URL: https://bro-tracker.atlassian.net/browse/BIT-1086 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master, 2.2 > Reporter: Bernhard Amann > Fix For: 2.2 > > > topic/bernhard/new-ciphers adds new ssl ciphers to the constants lists and also adds a few ciphers to the lookup table that were apparently forgotten in the past. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From noreply at bro.org Wed Oct 2 00:00:15 2013 From: noreply at bro.org (Merge Tracker) Date: Wed, 2 Oct 2013 00:00:15 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310020700.r9270FXO017536@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ------------------------------------------------ -------------- ------------ ---------- ------------- ---------- -------------------------------- BIT-1086 [1] Bro Bernhard Amann - 2013-10-01 2.2 Normal merge topic/bernhard/new-ciphers BIT-1085 [2] BinPAC,Bro,Broccoli,broccoli-python,pysubnettree Jon Siwek Robin Sommer 2013-09-27 2.2 Normal topic/jsiwek/coverity [3] [1] BIT-1086 https://bro-tracker.atlassian.net/browse/BIT-1086 [2] BIT-1085 https://bro-tracker.atlassian.net/browse/BIT-1085 [3] coverity https://github.com/bro/binpac,bro,broccoli,broccoli-python,pysubnettree/tree/topic/jsiwek/coverity From scampbell at lbl.gov Wed Oct 2 08:03:54 2013 From: scampbell at lbl.gov (Scott Campbell) Date: Wed, 02 Oct 2013 11:03:54 -0400 Subject: [Bro-Dev] virustotal script? Message-ID: <524C35DA.9070802@lbl.gov> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am wondering if anyone has an example policy which will auto test MD5 hashes against Virustotal? thanks! scott -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJMNdoACgkQK2Plq8B7ZByDzgCgwIOIgirHnBp0UsGkLjl2+nLx iowAn1pZOCP18mKe98z4XKWEXRqxPNEu =zRVz -----END PGP SIGNATURE----- From noreply at bro.org Thu Oct 3 00:00:12 2013 From: noreply at bro.org (Merge Tracker) Date: Thu, 3 Oct 2013 00:00:12 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310030700.r9370CJ9016774@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ------------------------------------------------ -------------- ------------ ---------- ------------- ---------- -------------------------------- BIT-1086 [1] Bro Bernhard Amann - 2013-10-01 2.2 Normal merge topic/bernhard/new-ciphers BIT-1085 [2] BinPAC,Bro,Broccoli,broccoli-python,pysubnettree Jon Siwek Robin Sommer 2013-09-27 2.2 Normal topic/jsiwek/coverity [3] [1] BIT-1086 https://bro-tracker.atlassian.net/browse/BIT-1086 [2] BIT-1085 https://bro-tracker.atlassian.net/browse/BIT-1085 [3] coverity https://github.com/bro/binpac,bro,broccoli,broccoli-python,pysubnettree/tree/topic/jsiwek/coverity From jira at bro-tracker.atlassian.net Thu Oct 3 10:51:29 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 3 Oct 2013 12:51:29 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1086) merge topic/bernhard/new-ciphers In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1086: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > merge topic/bernhard/new-ciphers > -------------------------------- > > Key: BIT-1086 > URL: https://bro-tracker.atlassian.net/browse/BIT-1086 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master, 2.2 > Reporter: Bernhard Amann > Fix For: 2.2 > > > topic/bernhard/new-ciphers adds new ssl ciphers to the constants lists and also adds a few ciphers to the lookup table that were apparently forgotten in the past. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Thu Oct 3 10:51:29 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 3 Oct 2013 12:51:29 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1085) topic/jsiwek/coverity In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1085: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > topic/jsiwek/coverity > --------------------- > > Key: BIT-1085 > URL: https://bro-tracker.atlassian.net/browse/BIT-1085 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BinPAC, Bro, Broccoli, broccoli-python, pysubnettree > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Fix For: 2.2 > > > This branch is in bro, pysubnettree, broccoli, broccoli-python, and binpac repos and fixes various defects reported by Coverity. > I can't remember any of great significance. There were mostly two categories: > * issues that are unlikely to be exercised, but could cause a modest problem (though there's often bigger issues if those code paths were ever taken...) > * issues that are likely to be exercised, but haven't posed much of a problem (logically or empirically) > I'd say just merge it in before the 2.2 release, but cherry-picking or postponing altogether also seem ok. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From noreply at bro.org Sat Oct 5 00:00:13 2013 From: noreply at bro.org (Merge Tracker) Date: Sat, 5 Oct 2013 00:00:13 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310050700.r9570Dc8006104@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ----------------------- ca8504d [1] capstats Daniel Thayer 2013-10-04 Fix getopt_long() usage [1] ca8504d https://github.com/bro/capstats/commit/ca8504dd8e03fc717089719352f260722697ab0b From noreply at bro.org Sun Oct 6 00:00:12 2013 From: noreply at bro.org (Merge Tracker) Date: Sun, 6 Oct 2013 00:00:12 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310060700.r9670CBQ016328@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ----------------------- ca8504d [1] capstats Daniel Thayer 2013-10-04 Fix getopt_long() usage [1] ca8504d https://github.com/bro/capstats/commit/ca8504dd8e03fc717089719352f260722697ab0b From noreply at bro.org Mon Oct 7 00:00:13 2013 From: noreply at bro.org (Merge Tracker) Date: Mon, 7 Oct 2013 00:00:13 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310070700.r9770Dxg021875@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ----------------------- ca8504d [1] capstats Daniel Thayer 2013-10-04 Fix getopt_long() usage [1] ca8504d https://github.com/bro/capstats/commit/ca8504dd8e03fc717089719352f260722697ab0b From jira at bro-tracker.atlassian.net Mon Oct 7 13:00:28 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 7 Oct 2013 15:00:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1009) topic/seth/sumstats-updates In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1009: ------------------------------ Resolution: Fixed Status: Closed (was: Open) This seems done. > topic/seth/sumstats-updates > --------------------------- > > Key: BIT-1009 > URL: https://bro-tracker.atlassian.net/browse/BIT-1009 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Assignee: Robin Sommer > Fix For: 2.2 > > > Lots of smallish updates in this one. I think I've addressed all of the nits that Robin pointed out in sumstats too. The external test suites didn't require any updates so no merged in those repositories. Some commit notes follow: > \\- On-demand access to sumstats results through "return from" > functions named SumStats::request and Sumstats::request_key. > Both functions are tested in standalone and clustered modes. > \\- $name field has returned to SumStats which simplifies cluster > code and makes the on-demand access stuff possible. > \\- Clustered results can only be collected for 1 minute from their > time of creation now instead of time of last read. > \\- Thresholds use doubles instead of counts everywhere now. > \\- Calculation dependency resolution occurs at start up time now > instead of doing it at observation time which provide a minor > cpu performance improvement. A new plugin registration mechanism > was created to support this change. > \\- AppStats now has a minimal doc string and is broken into hook-based > plugins. > \\- AppStats and traceroute detection added to local.bro -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Tue Oct 8 12:40:28 2013 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Tue, 8 Oct 2013 14:40:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1087) topic/dnthayer/broctl-fixes In-Reply-To: References: Message-ID: Daniel Thayer created BIT-1087: ---------------------------------- Summary: topic/dnthayer/broctl-fixes Key: BIT-1087 URL: https://bro-tracker.atlassian.net/browse/BIT-1087 Project: Bro Issue Tracker Issue Type: Problem Components: BroControl Reporter: Daniel Thayer Fix For: 2.2 This branch fixes several bugs in broctl: 1) on Linux, the "top" command output sometimes shows wrong values for memory statistics, 2) there is a race condition when the "sendmail" option is an empty string, 3) there is a deadlock when broctl runs a local command that produces a sufficiently large amount of output, 4) the shell scripts used by broctl are not as portable as they could be (specifically, some commands, such as sed, do not support the same options on all implementations) -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Tue Oct 8 12:40:28 2013 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Tue, 8 Oct 2013 14:40:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1087) topic/dnthayer/broctl-fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1087: ------------------------------- Description: This branch fixes several bugs in broctl: 1) on Linux, the broctl "top" command output sometimes shows wrong values for memory statistics, 2) there is a race condition when the "sendmail" option is an empty string, 3) there is a deadlock when broctl runs a local command that produces a sufficiently large amount of output, 4) the shell scripts used by broctl are not as portable as they could be (specifically, some commands, such as sed, do not support the same options on all implementations) was: This branch fixes several bugs in broctl: 1) on Linux, the "top" command output sometimes shows wrong values for memory statistics, 2) there is a race condition when the "sendmail" option is an empty string, 3) there is a deadlock when broctl runs a local command that produces a sufficiently large amount of output, 4) the shell scripts used by broctl are not as portable as they could be (specifically, some commands, such as sed, do not support the same options on all implementations) > topic/dnthayer/broctl-fixes > --------------------------- > > Key: BIT-1087 > URL: https://bro-tracker.atlassian.net/browse/BIT-1087 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Fix For: 2.2 > > > This branch fixes several bugs in broctl: > 1) on Linux, the broctl "top" command output sometimes shows wrong values for memory statistics, > 2) there is a race condition when the "sendmail" option is an empty string, > 3) there is a deadlock when broctl runs a local command that produces a sufficiently large amount of output, > 4) the shell scripts used by broctl are not as portable as they could be (specifically, some commands, such as sed, do not support the same options on all implementations) -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Tue Oct 8 12:42:28 2013 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Tue, 8 Oct 2013 14:42:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1087) topic/dnthayer/broctl-fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1087: ------------------------------- Status: Merge Request (was: Open) > topic/dnthayer/broctl-fixes > --------------------------- > > Key: BIT-1087 > URL: https://bro-tracker.atlassian.net/browse/BIT-1087 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Fix For: 2.2 > > > This branch fixes several bugs in broctl: > 1) on Linux, the broctl "top" command output sometimes shows wrong values for memory statistics, > 2) there is a race condition when the "sendmail" option is an empty string, > 3) there is a deadlock when broctl runs a local command that produces a sufficiently large amount of output, > 4) the shell scripts used by broctl are not as portable as they could be (specifically, some commands, such as sed, do not support the same options on all implementations) -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From noreply at bro.org Wed Oct 9 00:00:12 2013 From: noreply at bro.org (Merge Tracker) Date: Wed, 9 Oct 2013 00:00:12 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310090700.r9970C0n007086@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ---------- ---------- ------------- ---------- ------------------------------- BIT-1087 [1] BroControl Daniel Thayer - 2013-10-08 2.2 Normal topic/dnthayer/broctl-fixes [2] Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- -------------- ---------- --------------------------------------------------- 00b622f [3] bro Bernhard Amann 2013-10-08 IANA assigned a couple of new tls extension numbers 737b15a [4] bro Bernhard Amann 2013-10-08 add 3 more really new ciphers. [1] BIT-1087 https://bro-tracker.atlassian.net/browse/BIT-1087 [2] broctl-fixes https://github.com/bro/brocontrol/tree/topic/dnthayer/broctl-fixes [3] 00b622f https://github.com/bro/bro/commit/00b622f54d4fbe0fbf750933c8da559a21f2c2a7 [4] 737b15a https://github.com/bro/bro/commit/737b15aef9f36b3860d4890087980b27de6baab1 From jira at bro-tracker.atlassian.net Wed Oct 9 13:20:29 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 9 Oct 2013 15:20:29 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1087) topic/dnthayer/broctl-fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201#comment-14201 ] Robin Sommer commented on BIT-1087: ----------------------------------- This all makes sense, however some of the fixes make me wary to apply between beta and release as I can't really tell by just looking at them if they'll work correctly everywhere. I suppose you have you tested these all on the major platforms? Does our test suite cover them so that we'd catch if something breaks on one of the tested platforms? If/where not, can you add tests that exercise the changed code paths (probably not easily possible everywhere, but for some). > topic/dnthayer/broctl-fixes > --------------------------- > > Key: BIT-1087 > URL: https://bro-tracker.atlassian.net/browse/BIT-1087 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Fix For: 2.2 > > > This branch fixes several bugs in broctl: > 1) on Linux, the broctl "top" command output sometimes shows wrong values for memory statistics, > 2) there is a race condition when the "sendmail" option is an empty string, > 3) there is a deadlock when broctl runs a local command that produces a sufficiently large amount of output, > 4) the shell scripts used by broctl are not as portable as they could be (specifically, some commands, such as sed, do not support the same options on all implementations) -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Wed Oct 9 14:11:28 2013 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Wed, 9 Oct 2013 16:11:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1087) topic/dnthayer/broctl-fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14202#comment-14202 ] Daniel Thayer commented on BIT-1087: ------------------------------------ I found all of these bugs by installing and testing on platforms that we don't do our automated testing (although the first three do affect all platforms, these are not new bugs, and so I would be OK with postponing this until after 2.2). I also tested this branch on all of the platforms where we do our automated testing to make sure I didn't break anything. > topic/dnthayer/broctl-fixes > --------------------------- > > Key: BIT-1087 > URL: https://bro-tracker.atlassian.net/browse/BIT-1087 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Fix For: 2.2 > > > This branch fixes several bugs in broctl: > 1) on Linux, the broctl "top" command output sometimes shows wrong values for memory statistics, > 2) there is a race condition when the "sendmail" option is an empty string, > 3) there is a deadlock when broctl runs a local command that produces a sufficiently large amount of output, > 4) the shell scripts used by broctl are not as portable as they could be (specifically, some commands, such as sed, do not support the same options on all implementations) -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From noreply at bro.org Thu Oct 10 00:00:17 2013 From: noreply at bro.org (Merge Tracker) Date: Thu, 10 Oct 2013 00:00:17 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310100700.r9A70HOJ002851@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ---------- ---------- ------------- ---------- ------------------------------- BIT-1087 [1] BroControl Daniel Thayer - 2013-10-09 2.2 Normal topic/dnthayer/broctl-fixes [2] Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- -------------- ---------- --------------------------------------------------- 00b622f [3] bro Bernhard Amann 2013-10-08 IANA assigned a couple of new tls extension numbers 737b15a [4] bro Bernhard Amann 2013-10-08 add 3 more really new ciphers. [1] BIT-1087 https://bro-tracker.atlassian.net/browse/BIT-1087 [2] broctl-fixes https://github.com/bro/brocontrol/tree/topic/dnthayer/broctl-fixes [3] 00b622f https://github.com/bro/bro/commit/00b622f54d4fbe0fbf750933c8da559a21f2c2a7 [4] 737b15a https://github.com/bro/bro/commit/737b15aef9f36b3860d4890087980b27de6baab1 From jira at bro-tracker.atlassian.net Thu Oct 10 08:40:29 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 10 Oct 2013 10:40:29 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1087) topic/dnthayer/broctl-fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14203#comment-14203 ] Robin Sommer commented on BIT-1087: ----------------------------------- Ok, that sounds good. So are these covered by existing tests? Would they catch if anything broke? > topic/dnthayer/broctl-fixes > --------------------------- > > Key: BIT-1087 > URL: https://bro-tracker.atlassian.net/browse/BIT-1087 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Fix For: 2.2 > > > This branch fixes several bugs in broctl: > 1) on Linux, the broctl "top" command output sometimes shows wrong values for memory statistics, > 2) there is a race condition when the "sendmail" option is an empty string, > 3) there is a deadlock when broctl runs a local command that produces a sufficiently large amount of output, > 4) the shell scripts used by broctl are not as portable as they could be (specifically, some commands, such as sed, do not support the same options on all implementations) -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Thu Oct 10 08:51:28 2013 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 10 Oct 2013 10:51:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1087) topic/dnthayer/broctl-fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204#comment-14204 ] Daniel Thayer commented on BIT-1087: ------------------------------------ We already have test coverage for items #2 and #4 (in fact, there was a Jenkins automated test failure recently that caught #2, but item #4 is only relevant on platforms where we don't do automated testing). The tests exercise the code paths for #1 and #3, but they do not catch these specific cases currently. > topic/dnthayer/broctl-fixes > --------------------------- > > Key: BIT-1087 > URL: https://bro-tracker.atlassian.net/browse/BIT-1087 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Fix For: 2.2 > > > This branch fixes several bugs in broctl: > 1) on Linux, the broctl "top" command output sometimes shows wrong values for memory statistics, > 2) there is a race condition when the "sendmail" option is an empty string, > 3) there is a deadlock when broctl runs a local command that produces a sufficiently large amount of output, > 4) the shell scripts used by broctl are not as portable as they could be (specifically, some commands, such as sed, do not support the same options on all implementations) -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Thu Oct 10 13:39:29 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 10 Oct 2013 15:39:29 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1045) Review usage of InternalError when parsing network traffic In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1045: --------------------------- Assignee: Robin Sommer > Review usage of InternalError when parsing network traffic > ---------------------------------------------------------- > > Key: BIT-1045 > URL: https://bro-tracker.atlassian.net/browse/BIT-1045 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master, 2.1 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > > Creating issue for tracking purposes. > Reporter->InternalError denotes a fatal error, and will cause Bro to stop. Calling this function when parsing network traffic creates the possibility for an attacker using a "packet of death," which could stop Bro. > I suspect that in most cases, a weird should be generated instead, and Bro should just move on to the next packet. A quick grep shows some likely candidates for incorrect use of InternalError: > src/Sessions.cc: reporter->InternalError("Bad IP protocol version in DoNextInnerPacket"); > src/Sessions.cc: reporter->InternalError("fragment block not in dictionary"); > src/Sessions.cc: reporter->InternalError("fragment block missing"); > src/Sessions.cc: reporter->InternalError("unknown transport protocol"); > src/Frag.cc: reporter->InternalError("bad IP version in fragment reassembly"); > src/IP.cc: reporter->InternalError("IPv6_HdrChain::Init with truncated IP header"); > src/IP.cc: reporter->InternalError("IPv6_Hdr_Chain bad header %d", type); > src/IP.h: reporter->InternalError("bad IP version in IP_Hdr ctor"); > src/RSH.cc: reporter->InternalError("multiple rsh client names"); > src/RSH.cc: reporter->InternalError("multiple rsh initial client names"); > src/POP3.cc: reporter->InternalError("command not known"); > src/Rlogin.cc: reporter->InternalError("multiple rlogin client names"); > src/ICMP.cc: reporter->InternalError("unexpected IP proto in ICMP analyzer: %d", > src/ICMP.cc: reporter->InternalError("unexpected next protocol in ICMP::DeliverPacket()"); > src/SMB.cc: reporter->InternalError("command mismatch for ParseTransaction"); > src/HTTP.cc: reporter->InternalError("unrecognized HTTP message event"); > src/HTTP.cc: reporter->InternalError("HTTP ParseRequest failed"); > src/DPM.cc: reporter->InternalError("unknown protocol"); > src/RPC.cc: reporter->InternalError("RPC underflow"); > src/RPC.cc: reporter->InternalError("RPC resync: skipping over data failed"); > src/RPC.cc: reporter->InternalError("inconsistent RPC record marker extraction"); -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Thu Oct 10 13:39:29 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 10 Oct 2013 15:39:29 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1045) Review usage of InternalError when parsing network traffic In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1045: --------------------------- Status: Merge Request (was: Open) > Review usage of InternalError when parsing network traffic > ---------------------------------------------------------- > > Key: BIT-1045 > URL: https://bro-tracker.atlassian.net/browse/BIT-1045 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master, 2.1 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > > Creating issue for tracking purposes. > Reporter->InternalError denotes a fatal error, and will cause Bro to stop. Calling this function when parsing network traffic creates the possibility for an attacker using a "packet of death," which could stop Bro. > I suspect that in most cases, a weird should be generated instead, and Bro should just move on to the next packet. A quick grep shows some likely candidates for incorrect use of InternalError: > src/Sessions.cc: reporter->InternalError("Bad IP protocol version in DoNextInnerPacket"); > src/Sessions.cc: reporter->InternalError("fragment block not in dictionary"); > src/Sessions.cc: reporter->InternalError("fragment block missing"); > src/Sessions.cc: reporter->InternalError("unknown transport protocol"); > src/Frag.cc: reporter->InternalError("bad IP version in fragment reassembly"); > src/IP.cc: reporter->InternalError("IPv6_HdrChain::Init with truncated IP header"); > src/IP.cc: reporter->InternalError("IPv6_Hdr_Chain bad header %d", type); > src/IP.h: reporter->InternalError("bad IP version in IP_Hdr ctor"); > src/RSH.cc: reporter->InternalError("multiple rsh client names"); > src/RSH.cc: reporter->InternalError("multiple rsh initial client names"); > src/POP3.cc: reporter->InternalError("command not known"); > src/Rlogin.cc: reporter->InternalError("multiple rlogin client names"); > src/ICMP.cc: reporter->InternalError("unexpected IP proto in ICMP analyzer: %d", > src/ICMP.cc: reporter->InternalError("unexpected next protocol in ICMP::DeliverPacket()"); > src/SMB.cc: reporter->InternalError("command mismatch for ParseTransaction"); > src/HTTP.cc: reporter->InternalError("unrecognized HTTP message event"); > src/HTTP.cc: reporter->InternalError("HTTP ParseRequest failed"); > src/DPM.cc: reporter->InternalError("unknown protocol"); > src/RPC.cc: reporter->InternalError("RPC underflow"); > src/RPC.cc: reporter->InternalError("RPC resync: skipping over data failed"); > src/RPC.cc: reporter->InternalError("inconsistent RPC record marker extraction"); -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Thu Oct 10 13:39:29 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 10 Oct 2013 15:39:29 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1045) Review usage of InternalError when parsing network traffic In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205#comment-14205 ] Jon Siwek commented on BIT-1045: -------------------------------- I did a pass over InternalError usage in topic/jsiwek/internal-errors. I marked a couple changes with "TODO" that I wasn't particularly confident in, but the others I'm relatively sure are somewhat of an improvement over InternalError (if we were to have a call stack available in the output) or at least probably won't cause more problems by allowing execution to continue. > Review usage of InternalError when parsing network traffic > ---------------------------------------------------------- > > Key: BIT-1045 > URL: https://bro-tracker.atlassian.net/browse/BIT-1045 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master, 2.1 > Reporter: Vlad Grigorescu > > Creating issue for tracking purposes. > Reporter->InternalError denotes a fatal error, and will cause Bro to stop. Calling this function when parsing network traffic creates the possibility for an attacker using a "packet of death," which could stop Bro. > I suspect that in most cases, a weird should be generated instead, and Bro should just move on to the next packet. A quick grep shows some likely candidates for incorrect use of InternalError: > src/Sessions.cc: reporter->InternalError("Bad IP protocol version in DoNextInnerPacket"); > src/Sessions.cc: reporter->InternalError("fragment block not in dictionary"); > src/Sessions.cc: reporter->InternalError("fragment block missing"); > src/Sessions.cc: reporter->InternalError("unknown transport protocol"); > src/Frag.cc: reporter->InternalError("bad IP version in fragment reassembly"); > src/IP.cc: reporter->InternalError("IPv6_HdrChain::Init with truncated IP header"); > src/IP.cc: reporter->InternalError("IPv6_Hdr_Chain bad header %d", type); > src/IP.h: reporter->InternalError("bad IP version in IP_Hdr ctor"); > src/RSH.cc: reporter->InternalError("multiple rsh client names"); > src/RSH.cc: reporter->InternalError("multiple rsh initial client names"); > src/POP3.cc: reporter->InternalError("command not known"); > src/Rlogin.cc: reporter->InternalError("multiple rlogin client names"); > src/ICMP.cc: reporter->InternalError("unexpected IP proto in ICMP analyzer: %d", > src/ICMP.cc: reporter->InternalError("unexpected next protocol in ICMP::DeliverPacket()"); > src/SMB.cc: reporter->InternalError("command mismatch for ParseTransaction"); > src/HTTP.cc: reporter->InternalError("unrecognized HTTP message event"); > src/HTTP.cc: reporter->InternalError("HTTP ParseRequest failed"); > src/DPM.cc: reporter->InternalError("unknown protocol"); > src/RPC.cc: reporter->InternalError("RPC underflow"); > src/RPC.cc: reporter->InternalError("RPC resync: skipping over data failed"); > src/RPC.cc: reporter->InternalError("inconsistent RPC record marker extraction"); -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Thu Oct 10 14:27:28 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 10 Oct 2013 16:27:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1087) topic/dnthayer/broctl-fixes In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1087: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) . > topic/dnthayer/broctl-fixes > --------------------------- > > Key: BIT-1087 > URL: https://bro-tracker.atlassian.net/browse/BIT-1087 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > Fix For: 2.2 > > > This branch fixes several bugs in broctl: > 1) on Linux, the broctl "top" command output sometimes shows wrong values for memory statistics, > 2) there is a race condition when the "sendmail" option is an empty string, > 3) there is a deadlock when broctl runs a local command that produces a sufficiently large amount of output, > 4) the shell scripts used by broctl are not as portable as they could be (specifically, some commands, such as sed, do not support the same options on all implementations) -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Thu Oct 10 14:41:28 2013 From: jira at bro-tracker.atlassian.net (Henry Stern (JIRA)) Date: Thu, 10 Oct 2013 16:41:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1088) pysubnettree-0.20 setup.py has wrong version In-Reply-To: References: Message-ID: Henry Stern created BIT-1088: -------------------------------- Summary: pysubnettree-0.20 setup.py has wrong version Key: BIT-1088 URL: https://bro-tracker.atlassian.net/browse/BIT-1088 Project: Bro Issue Tracker Issue Type: Problem Components: pysubnettree Affects Versions: 2.1 Reporter: Henry Stern The 0.20 release of pysubnettree has incorrect data in setup.py. setup(name="pysubnettree", version="0.19", # Filled in automatically. This should read version="0.20" obviously. It breaks packaging systems like py2dsc. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Thu Oct 10 16:45:29 2013 From: jira at bro-tracker.atlassian.net (leres (JIRA)) Date: Thu, 10 Oct 2013 18:45:29 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: leres created BIT-1089: -------------------------- Summary: Please install sample/example broctl .cfg files Key: BIT-1089 URL: https://bro-tracker.atlassian.net/browse/BIT-1089 Project: Bro Issue Tracker Issue Type: Improvement Components: BroControl Reporter: leres Priority: Low -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Thu Oct 10 16:48:28 2013 From: jira at bro-tracker.atlassian.net (leres (JIRA)) Date: Thu, 10 Oct 2013 18:48:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207#comment-14207 ] leres commented on BIT-1089: ---------------------------- [What a wacky interface, it created the issue before I was done filling out the form!] Could we please have sample or example versions of broctl.cfg, networks.cfg and node.cfg installed by default (or via a cmake option)? I need this for the FreeBSD security/bro port so that if bro is installed via a package, the user has something to start from. > Please install sample/example broctl .cfg files > ----------------------------------------------- > > Key: BIT-1089 > URL: https://bro-tracker.atlassian.net/browse/BIT-1089 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BroControl > Reporter: leres > Priority: Low > -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From noreply at bro.org Fri Oct 11 00:00:12 2013 From: noreply at bro.org (Merge Tracker) Date: Fri, 11 Oct 2013 00:00:12 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310110700.r9B70CWD005573@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ------------ ---------- ------------- ---------- ---------------------------------------------------------- BIT-1045 [1] Bro Vlad Grigorescu Robin Sommer 2013-10-10 - Normal Review usage of InternalError when parsing network traffic [1] BIT-1045 https://bro-tracker.atlassian.net/browse/BIT-1045 From robin at icir.org Fri Oct 11 07:55:58 2013 From: robin at icir.org (Robin Sommer) Date: Fri, 11 Oct 2013 07:55:58 -0700 Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Add README files for most Bro frameworks (60b2c5f) In-Reply-To: <201310110529.r9B5TLjx000482@bro-ids.icir.org> References: <201310110529.r9B5TLjx000482@bro-ids.icir.org> Message-ID: <20131011145558.GH76444@icir.org> On Thu, Oct 10, 2013 at 22:29 -0700, Daniel Thayer wrote: > Add README files for most Bro frameworks I'm forgetting if it works to put these as comments into the __load__.bro files? If so, that would be an alternative as it avoids having a new file in each directory (the README's are easier to find though when looking at the scripts directly, so I'm a bit torn). 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 Oct 11 08:23:28 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 11 Oct 2013 10:23:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1088) pysubnettree-0.20 setup.py has wrong version In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208#comment-14208 ] Robin Sommer commented on BIT-1088: ----------------------------------- I'll prepare a new release that fixes that glitch. > pysubnettree-0.20 setup.py has wrong version > -------------------------------------------- > > Key: BIT-1088 > URL: https://bro-tracker.atlassian.net/browse/BIT-1088 > Project: Bro Issue Tracker > Issue Type: Problem > Components: pysubnettree > Affects Versions: 2.1 > Reporter: Henry Stern > Labels: setup.py, version > > The 0.20 release of pysubnettree has incorrect data in setup.py. > setup(name="pysubnettree", > version="0.19", # Filled in automatically. > This should read version="0.20" obviously. It breaks packaging systems like py2dsc. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From dnthayer at illinois.edu Fri Oct 11 08:17:27 2013 From: dnthayer at illinois.edu (Daniel Thayer) Date: Fri, 11 Oct 2013 10:17:27 -0500 Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Add README files for most Bro frameworks (60b2c5f) In-Reply-To: <20131011145558.GH76444@icir.org> References: <201310110529.r9B5TLjx000482@bro-ids.icir.org> <20131011145558.GH76444@icir.org> Message-ID: <52581687.5030809@illinois.edu> On 10/11/2013 09:55 AM, Robin Sommer wrote: > > > On Thu, Oct 10, 2013 at 22:29 -0700, Daniel Thayer wrote: > >> Add README files for most Bro frameworks > > I'm forgetting if it works to put these as comments into the > __load__.bro files? If so, that would be an alternative as it avoids > having a new file in each directory (the README's are easier to find > though when looking at the scripts directly, so I'm a bit torn). > > Robin > I'm not aware of a way to do that from the __load__.bro file. From seth at icir.org Fri Oct 11 08:53:11 2013 From: seth at icir.org (Seth Hall) Date: Fri, 11 Oct 2013 11:53:11 -0400 Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Add README files for most Bro frameworks (60b2c5f) In-Reply-To: <20131011145558.GH76444@icir.org> References: <201310110529.r9B5TLjx000482@bro-ids.icir.org> <20131011145558.GH76444@icir.org> Message-ID: <3A0EDD1F-6C0F-4332-8BE8-F917C4AF2EDD@icir.org> On Oct 11, 2013, at 10:55 AM, Robin Sommer wrote: > I'm forgetting if it works to put these as comments into the > __load__.bro files? I'm inclined to say having README files would be better since ultimately all of this is just leading toward creating a more formalized "module" style and having READMEs in the directory would probably be good form in general. .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/20131011/d5c66b38/attachment.bin From robin at icir.org Fri Oct 11 09:09:46 2013 From: robin at icir.org (Robin Sommer) Date: Fri, 11 Oct 2013 09:09:46 -0700 Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Add README files for most Bro frameworks (60b2c5f) In-Reply-To: <3A0EDD1F-6C0F-4332-8BE8-F917C4AF2EDD@icir.org> References: <201310110529.r9B5TLjx000482@bro-ids.icir.org> <20131011145558.GH76444@icir.org> <3A0EDD1F-6C0F-4332-8BE8-F917C4AF2EDD@icir.org> Message-ID: <20131011160946.GN76444@icir.org> On Fri, Oct 11, 2013 at 11:53 -0400, you wrote: > ultimately all of this is just leading toward creating a more > formalized "module" style and having READMEs in the directory would > probably be good form in general. Ah, good point. 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 Oct 11 11:26:29 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Fri, 11 Oct 2013 13:26:29 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209#comment-14209 ] Jon Siwek commented on BIT-1089: -------------------------------- Is it ok to always install a sample plus the real version (if it doesn't already exist) that's meant to be used/modified? Or do you need a mode where just the sample config file is the only thing that Bro can ever install? > Please install sample/example broctl .cfg files > ----------------------------------------------- > > Key: BIT-1089 > URL: https://bro-tracker.atlassian.net/browse/BIT-1089 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BroControl > Reporter: leres > Priority: Low > -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Fri Oct 11 11:37:28 2013 From: jira at bro-tracker.atlassian.net (leres (JIRA)) Date: Fri, 11 Oct 2013 13:37:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14210#comment-14210 ] leres commented on BIT-1089: ---------------------------- The current behavior where it only installs a .cfg if none exist is totally fine. What I'm asking for is that either by default or by turning on a cmake argument it would install sample configs. > Please install sample/example broctl .cfg files > ----------------------------------------------- > > Key: BIT-1089 > URL: https://bro-tracker.atlassian.net/browse/BIT-1089 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BroControl > Reporter: leres > Priority: Low > -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Fri Oct 11 11:43:28 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 11 Oct 2013 13:43:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1045) Review usage of InternalError when parsing network traffic In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14211#comment-14211 ] Robin Sommer commented on BIT-1045: ----------------------------------- Going through, I see number of places where I'd argue it's actually a programming/logic error that's not something that can be directly/just triggered by crafted network traffic. Examples are the RefCnt() checks in ~ConnectionTimer() and the indent_level check in ODesc. I'm inclined to leave them as they were, with the argument being that those kinds of error actually *are* best to trigger an abort. E.g, if the reference counting goes awry, pretty much all bets are off anyways, and I'd rather have Bro terminate than trying to continue. So I think the guideline should be avoiding internal errors that happen *directly* because of broken network input; not because of (for lack of a better term) "infrastructure problems" in other parts of Bro. (Although I'm sure as I go further, I'll find more cases where that definition is ambiguous as well.) What's your opinion on cases like the above? What I could do is go through your diffs and adapt with the above in mind, and then we can do another iteration and see if/where we agree. > Review usage of InternalError when parsing network traffic > ---------------------------------------------------------- > > Key: BIT-1045 > URL: https://bro-tracker.atlassian.net/browse/BIT-1045 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master, 2.1 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > > Creating issue for tracking purposes. > Reporter->InternalError denotes a fatal error, and will cause Bro to stop. Calling this function when parsing network traffic creates the possibility for an attacker using a "packet of death," which could stop Bro. > I suspect that in most cases, a weird should be generated instead, and Bro should just move on to the next packet. A quick grep shows some likely candidates for incorrect use of InternalError: > src/Sessions.cc: reporter->InternalError("Bad IP protocol version in DoNextInnerPacket"); > src/Sessions.cc: reporter->InternalError("fragment block not in dictionary"); > src/Sessions.cc: reporter->InternalError("fragment block missing"); > src/Sessions.cc: reporter->InternalError("unknown transport protocol"); > src/Frag.cc: reporter->InternalError("bad IP version in fragment reassembly"); > src/IP.cc: reporter->InternalError("IPv6_HdrChain::Init with truncated IP header"); > src/IP.cc: reporter->InternalError("IPv6_Hdr_Chain bad header %d", type); > src/IP.h: reporter->InternalError("bad IP version in IP_Hdr ctor"); > src/RSH.cc: reporter->InternalError("multiple rsh client names"); > src/RSH.cc: reporter->InternalError("multiple rsh initial client names"); > src/POP3.cc: reporter->InternalError("command not known"); > src/Rlogin.cc: reporter->InternalError("multiple rlogin client names"); > src/ICMP.cc: reporter->InternalError("unexpected IP proto in ICMP analyzer: %d", > src/ICMP.cc: reporter->InternalError("unexpected next protocol in ICMP::DeliverPacket()"); > src/SMB.cc: reporter->InternalError("command mismatch for ParseTransaction"); > src/HTTP.cc: reporter->InternalError("unrecognized HTTP message event"); > src/HTTP.cc: reporter->InternalError("HTTP ParseRequest failed"); > src/DPM.cc: reporter->InternalError("unknown protocol"); > src/RPC.cc: reporter->InternalError("RPC underflow"); > src/RPC.cc: reporter->InternalError("RPC resync: skipping over data failed"); > src/RPC.cc: reporter->InternalError("inconsistent RPC record marker extraction"); -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From robin at icir.org Fri Oct 11 11:47:14 2013 From: robin at icir.org (Robin Sommer) Date: Fri, 11 Oct 2013 11:47:14 -0700 Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: <20131011184713.GR76444@icir.org> On Fri, Oct 11, 2013 at 13:37 -0500, you wrote: > The current behavior where it only installs a .cfg if none exist is > totally fine. What I'm asking for is that either by default or by > turning on a cmake argument it would install sample configs. I'm still not sure I'm really getting the issue but I have an idea: would a separate make target "install-sample-configs" work that unconditionally puts the samples in place? That's something we could still add to 2.2 even at this point as it doesn't interfere with anything else. Robin From jira at bro-tracker.atlassian.net Fri Oct 11 11:49:28 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 11 Oct 2013 13:49:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212#comment-14212 ] Robin Sommer commented on BIT-1089: ----------------------------------- I'm still not sure I'm really getting the issue but I have an idea: would a separate make target "install-sample-configs" work that unconditionally puts the samples in place? That's something we could still add to 2.2 even at this point as it doesn't interfere with anything else. Robin > Please install sample/example broctl .cfg files > ----------------------------------------------- > > Key: BIT-1089 > URL: https://bro-tracker.atlassian.net/browse/BIT-1089 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BroControl > Reporter: leres > Priority: Low > -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Fri Oct 11 15:16:29 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 11 Oct 2013 17:16:29 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1045) Review usage of InternalError when parsing network traffic In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213#comment-14213 ] Robin Sommer commented on BIT-1045: ----------------------------------- Ok, good job on this. I went through and put a few small tweaks into topic/robin/internal-errors-merge. If you could double-check I'd appreciate (and it remains all fuzzy, I actually changed my mind a few times back and forth in some cases ?) Also, one remaining (or new) concern is that now methods which previously aborted, may now return a value that's not usable upstream (null pointers in particular). I saw that you adapted a few locations, but it's hard to tell if there are more. I'm wondering though if Coverity might help us here and flag, e.g., potential null pointer usages. > Review usage of InternalError when parsing network traffic > ---------------------------------------------------------- > > Key: BIT-1045 > URL: https://bro-tracker.atlassian.net/browse/BIT-1045 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master, 2.1 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > > Creating issue for tracking purposes. > Reporter->InternalError denotes a fatal error, and will cause Bro to stop. Calling this function when parsing network traffic creates the possibility for an attacker using a "packet of death," which could stop Bro. > I suspect that in most cases, a weird should be generated instead, and Bro should just move on to the next packet. A quick grep shows some likely candidates for incorrect use of InternalError: > src/Sessions.cc: reporter->InternalError("Bad IP protocol version in DoNextInnerPacket"); > src/Sessions.cc: reporter->InternalError("fragment block not in dictionary"); > src/Sessions.cc: reporter->InternalError("fragment block missing"); > src/Sessions.cc: reporter->InternalError("unknown transport protocol"); > src/Frag.cc: reporter->InternalError("bad IP version in fragment reassembly"); > src/IP.cc: reporter->InternalError("IPv6_HdrChain::Init with truncated IP header"); > src/IP.cc: reporter->InternalError("IPv6_Hdr_Chain bad header %d", type); > src/IP.h: reporter->InternalError("bad IP version in IP_Hdr ctor"); > src/RSH.cc: reporter->InternalError("multiple rsh client names"); > src/RSH.cc: reporter->InternalError("multiple rsh initial client names"); > src/POP3.cc: reporter->InternalError("command not known"); > src/Rlogin.cc: reporter->InternalError("multiple rlogin client names"); > src/ICMP.cc: reporter->InternalError("unexpected IP proto in ICMP analyzer: %d", > src/ICMP.cc: reporter->InternalError("unexpected next protocol in ICMP::DeliverPacket()"); > src/SMB.cc: reporter->InternalError("command mismatch for ParseTransaction"); > src/HTTP.cc: reporter->InternalError("unrecognized HTTP message event"); > src/HTTP.cc: reporter->InternalError("HTTP ParseRequest failed"); > src/DPM.cc: reporter->InternalError("unknown protocol"); > src/RPC.cc: reporter->InternalError("RPC underflow"); > src/RPC.cc: reporter->InternalError("RPC resync: skipping over data failed"); > src/RPC.cc: reporter->InternalError("inconsistent RPC record marker extraction"); -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From noreply at bro.org Sat Oct 12 00:00:15 2013 From: noreply at bro.org (Merge Tracker) Date: Sat, 12 Oct 2013 00:00:15 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310120700.r9C70F3G013117@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ------------ ---------- ------------- ---------- ---------------------------------------------------------- BIT-1045 [1] Bro Vlad Grigorescu Robin Sommer 2013-10-11 - Normal Review usage of InternalError when parsing network traffic [1] BIT-1045 https://bro-tracker.atlassian.net/browse/BIT-1045 From jira at bro-tracker.atlassian.net Sat Oct 12 00:47:28 2013 From: jira at bro-tracker.atlassian.net (tyler.schoenke (JIRA)) Date: Sat, 12 Oct 2013 02:47:28 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1090) fatal error Val::CONVERTER In-Reply-To: References: Message-ID: tyler.schoenke created BIT-1090: ----------------------------------- Summary: 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.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Sat Oct 12 09:52:29 2013 From: jira at bro-tracker.atlassian.net (AK (JIRA)) Date: Sat, 12 Oct 2013 11:52:29 -0500 (CDT) 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=14214#comment-14214 ] AK commented on BIT-1090: ------------------------- Running your scripts against Bro version 2.1-1150 I get this error in ./my-detect-bruteforcing.bro, line 5: can't open base/frameworks/metrics Try upgrading to the latest version of Bro, modifying the detect-bruteforcing.bro script it installs and loading it with your sigsup-ssh-pass2.bro script. > 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.1-OD-09-WN#6144) From noreply at bro.org Sun Oct 13 00:00:24 2013 From: noreply at bro.org (Merge Tracker) Date: Sun, 13 Oct 2013 00:00:24 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310130700.r9D70O0S028314@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ------------ ---------- ------------- ---------- ---------------------------------------------------------- BIT-1045 [1] Bro Vlad Grigorescu Robin Sommer 2013-10-11 - Normal Review usage of InternalError when parsing network traffic [1] BIT-1045 https://bro-tracker.atlassian.net/browse/BIT-1045 From noreply at bro.org Mon Oct 14 00:00:35 2013 From: noreply at bro.org (Merge Tracker) Date: Mon, 14 Oct 2013 00:00:35 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310140700.r9E70Zlo010597@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- --------------- ------------ ---------- ------------- ---------- ---------------------------------------------------------- BIT-1045 [1] Bro Vlad Grigorescu Robin Sommer 2013-10-11 - Normal Review usage of InternalError when parsing network traffic Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ---------------------------------------------- fdb6d19 [2] bro Daniel Thayer 2013-10-13 Add check for curl command to active-http.test [1] BIT-1045 https://bro-tracker.atlassian.net/browse/BIT-1045 [2] fdb6d19 https://github.com/bro/bro/commit/fdb6d190b8f20cb442e64d18a406af670ce842f1 From jira at bro-tracker.atlassian.net Mon Oct 14 08:22:51 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 14 Oct 2013 10:22:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14300#comment-14300 ] Jon Siwek commented on BIT-1089: -------------------------------- The topic/jsiwek/example-configs branch in the cmake repo adds the "install-example-configs" make target to force installation of example config files. It seemed like it would be useful in contexts other than just FreeBSD ports, but let us know if it doesn't actually work for your situation, Craig. > Please install sample/example broctl .cfg files > ----------------------------------------------- > > Key: BIT-1089 > URL: https://bro-tracker.atlassian.net/browse/BIT-1089 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BroControl > Reporter: leres > Priority: Low > -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Mon Oct 14 08:24:51 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 14 Oct 2013 10:24:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1089: --------------------------- Status: Merge Request (was: Open) > Please install sample/example broctl .cfg files > ----------------------------------------------- > > Key: BIT-1089 > URL: https://bro-tracker.atlassian.net/browse/BIT-1089 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BroControl > Reporter: leres > Priority: Low > -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From anthony.kasza at gmail.com Mon Oct 14 09:43:54 2013 From: anthony.kasza at gmail.com (anthony kasza) Date: Mon, 14 Oct 2013 09:43:54 -0700 Subject: [Bro-Dev] CBrAN Bro Control Plugin Message-ID: I have a basic broctl plugin that I'm hoping will be a first step towards the CBrAN outlined here . Currently, most of the functionality is stubbed in as screen output. My initial thought was for the Bro project to maintain and distribute a SQLite database of rebros (git repos of Bro scripts). As Python2.5+ has native support for SQLite this would not require users to install additional Python modules. A community developer would be able to register his/her rebro for inclusion in the SQLite file distributed with broctl. The SQLite file would represent the universe referred to on the project page. Before getting too far into the weeds, I'm hoping to get some feedback around design decisions (what issues distributing/maintaining a SQLite file introduces) and to see if anyone is interested in collaborating. -AK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20131014/b1f0429e/attachment.html From jira at bro-tracker.atlassian.net Mon Oct 14 10:50:51 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 14 Oct 2013 12:50:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1089: ------------------------------ Status: In Progress (was: Open) > Please install sample/example broctl .cfg files > ----------------------------------------------- > > Key: BIT-1089 > URL: https://bro-tracker.atlassian.net/browse/BIT-1089 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BroControl > Reporter: leres > Priority: Low > -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Mon Oct 14 10:50:51 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 14 Oct 2013 12:50:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1089: ------------------------------ Status: Open (was: Merge Request) > Please install sample/example broctl .cfg files > ----------------------------------------------- > > Key: BIT-1089 > URL: https://bro-tracker.atlassian.net/browse/BIT-1089 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BroControl > Reporter: leres > Priority: Low > -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Mon Oct 14 10:50:51 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 14 Oct 2013 12:50:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301#comment-14301 ] Robin Sommer commented on BIT-1089: ----------------------------------- This is now merged into master. Craig, does that solve your problem? > Please install sample/example broctl .cfg files > ----------------------------------------------- > > Key: BIT-1089 > URL: https://bro-tracker.atlassian.net/browse/BIT-1089 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BroControl > Reporter: leres > Priority: Low > -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Mon Oct 14 10:52:51 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 14 Oct 2013 12:52:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1045) Review usage of InternalError when parsing network traffic In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1045: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Review usage of InternalError when parsing network traffic > ---------------------------------------------------------- > > Key: BIT-1045 > URL: https://bro-tracker.atlassian.net/browse/BIT-1045 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: git/master, 2.1 > Reporter: Vlad Grigorescu > Assignee: Robin Sommer > > Creating issue for tracking purposes. > Reporter->InternalError denotes a fatal error, and will cause Bro to stop. Calling this function when parsing network traffic creates the possibility for an attacker using a "packet of death," which could stop Bro. > I suspect that in most cases, a weird should be generated instead, and Bro should just move on to the next packet. A quick grep shows some likely candidates for incorrect use of InternalError: > src/Sessions.cc: reporter->InternalError("Bad IP protocol version in DoNextInnerPacket"); > src/Sessions.cc: reporter->InternalError("fragment block not in dictionary"); > src/Sessions.cc: reporter->InternalError("fragment block missing"); > src/Sessions.cc: reporter->InternalError("unknown transport protocol"); > src/Frag.cc: reporter->InternalError("bad IP version in fragment reassembly"); > src/IP.cc: reporter->InternalError("IPv6_HdrChain::Init with truncated IP header"); > src/IP.cc: reporter->InternalError("IPv6_Hdr_Chain bad header %d", type); > src/IP.h: reporter->InternalError("bad IP version in IP_Hdr ctor"); > src/RSH.cc: reporter->InternalError("multiple rsh client names"); > src/RSH.cc: reporter->InternalError("multiple rsh initial client names"); > src/POP3.cc: reporter->InternalError("command not known"); > src/Rlogin.cc: reporter->InternalError("multiple rlogin client names"); > src/ICMP.cc: reporter->InternalError("unexpected IP proto in ICMP analyzer: %d", > src/ICMP.cc: reporter->InternalError("unexpected next protocol in ICMP::DeliverPacket()"); > src/SMB.cc: reporter->InternalError("command mismatch for ParseTransaction"); > src/HTTP.cc: reporter->InternalError("unrecognized HTTP message event"); > src/HTTP.cc: reporter->InternalError("HTTP ParseRequest failed"); > src/DPM.cc: reporter->InternalError("unknown protocol"); > src/RPC.cc: reporter->InternalError("RPC underflow"); > src/RPC.cc: reporter->InternalError("RPC resync: skipping over data failed"); > src/RPC.cc: reporter->InternalError("inconsistent RPC record marker extraction"); -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Mon Oct 14 10:52:51 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 14 Oct 2013 12:52:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1088) pysubnettree-0.20 setup.py has wrong version In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14302#comment-14302 ] Robin Sommer commented on BIT-1088: ----------------------------------- 0.21 is now online on the download page. > pysubnettree-0.20 setup.py has wrong version > -------------------------------------------- > > Key: BIT-1088 > URL: https://bro-tracker.atlassian.net/browse/BIT-1088 > Project: Bro Issue Tracker > Issue Type: Problem > Components: pysubnettree > Affects Versions: 2.1 > Reporter: Henry Stern > Labels: setup.py, version > > The 0.20 release of pysubnettree has incorrect data in setup.py. > setup(name="pysubnettree", > version="0.19", # Filled in automatically. > This should read version="0.20" obviously. It breaks packaging systems like py2dsc. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Mon Oct 14 10:52:51 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 14 Oct 2013 12:52:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1088) pysubnettree-0.20 setup.py has wrong version In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1088: ------------------------------ Resolution: Fixed Status: Closed (was: Open) > pysubnettree-0.20 setup.py has wrong version > -------------------------------------------- > > Key: BIT-1088 > URL: https://bro-tracker.atlassian.net/browse/BIT-1088 > Project: Bro Issue Tracker > Issue Type: Problem > Components: pysubnettree > Affects Versions: 2.1 > Reporter: Henry Stern > Labels: setup.py, version > > The 0.20 release of pysubnettree has incorrect data in setup.py. > setup(name="pysubnettree", > version="0.19", # Filled in automatically. > This should read version="0.20" obviously. It breaks packaging systems like py2dsc. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Mon Oct 14 13:56:51 2013 From: jira at bro-tracker.atlassian.net (leres (JIRA)) Date: Mon, 14 Oct 2013 15:56:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303#comment-14303 ] leres commented on BIT-1089: ---------------------------- I think so. Thanks! > Please install sample/example broctl .cfg files > ----------------------------------------------- > > Key: BIT-1089 > URL: https://bro-tracker.atlassian.net/browse/BIT-1089 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BroControl > Reporter: leres > Priority: Low > -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Mon Oct 14 14:14:51 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 14 Oct 2013 16:14:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1089) Please install sample/example broctl .cfg files In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1089: ------------------------------ Resolution: Fixed Status: Closed (was: In Progress) > Please install sample/example broctl .cfg files > ----------------------------------------------- > > Key: BIT-1089 > URL: https://bro-tracker.atlassian.net/browse/BIT-1089 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: BroControl > Reporter: leres > Priority: Low > -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jsiwek at illinois.edu Mon Oct 14 15:20:30 2013 From: jsiwek at illinois.edu (Siwek, Jonathan Luke) Date: Mon, 14 Oct 2013 22:20:30 +0000 Subject: [Bro-Dev] CBrAN Bro Control Plugin In-Reply-To: References: Message-ID: On Oct 14, 2013, at 11:43 AM, anthony kasza wrote: > My initial thought was for the Bro project to maintain and distribute a SQLite database of rebros (git repos of Bro scripts). A terminology nitpick: a "rebro" (according to the proposal doc) isn't a git repo, but a git repo may contain rebros (directories containing a __load__.bro script). I'm only pointing it out to suggest the first step is that we come to a consensus on what terms to use to describe things else later discussion might get confusing. Here's things I think need naming: 1) A git repository that may contain bro scripts. I actually don't think these need a special name, just call it a "repo" or "repository" as usual since there's not really any unique requirements. 2) A directory containing __load__.bro. These just let Bro "@load ". "rebro" is confusing for this, since it's not a git repo itself. I've always called this a "package" for lack of anything better. 3) CBrAN Don't think this was actually decided? Works for me, except the case switch in the middle is a bother. > As Python2.5+ has native support for SQLite this would not require users to install additional Python modules. A community developer would be able to register his/her rebro for inclusion in the SQLite file distributed with broctl. The SQLite file would represent the universe referred to on the project page. If the registration process were to be something simple like a person doing a pull request on GitHub where they've added their repo to the "universe" database, a flat file rather than SQLite might be better for that database file since it should be easier to change and audit (by just looking at the git commit) ? Though if BroControl parses that file and generates some internal representation that may use SQLite, that might be one way to do it. Were you mostly thinking of storing metadata/dependency stuff there? - Jon From anthony.kasza at gmail.com Mon Oct 14 17:24:36 2013 From: anthony.kasza at gmail.com (anthony kasza) Date: Mon, 14 Oct 2013 17:24:36 -0700 Subject: [Bro-Dev] CBrAN Bro Control Plugin In-Reply-To: References: Message-ID: Having a name for a directory resembling "repo" when the directory is not a repository is confusing, I agree. I'll refer to it as a package moving forward. The project page refers to the package manager as CBAN, let's go with that. Having a flat file representation of the universe would make managing the universe through GitHub much simpler. It would also save people from having to write a bunch of SQL code. My thought was for the universe database to contain the following pieces of information (taken from the project page): name, URL, author, tags, package version, Bro version, dependencies, license, description. If a plain text flat file is used would would it be useful for the file to be readable by the input framework? -AK On Mon, Oct 14, 2013 at 3:20 PM, Siwek, Jonathan Luke wrote: > > On Oct 14, 2013, at 11:43 AM, anthony kasza > wrote: > >> My initial thought was for the Bro project to maintain and distribute a SQLite database of rebros (git repos of Bro scripts). > > A terminology nitpick: a "rebro" (according to the proposal doc) isn't a git repo, but a git repo may contain rebros (directories containing a __load__.bro script). > > I'm only pointing it out to suggest the first step is that we come to a consensus on what terms to use to describe things else later discussion might get confusing. > > Here's things I think need naming: > > 1) A git repository that may contain bro scripts. > > I actually don't think these need a special name, just call it a "repo" or "repository" as usual since there's not really any unique requirements. > > 2) A directory containing __load__.bro. > > These just let Bro "@load ". "rebro" is confusing for this, since it's not a git repo itself. I've always called this a "package" for lack of anything better. > > 3) CBrAN > > Don't think this was actually decided? Works for me, except the case switch in the middle is a bother. > >> As Python2.5+ has native support for SQLite this would not require users to install additional Python modules. A community developer would be able to register his/her rebro for inclusion in the SQLite file distributed with broctl. The SQLite file would represent the universe referred to on the project page. > > If the registration process were to be something simple like a person doing a pull request on GitHub where they've added their repo to the "universe" database, a flat file rather than SQLite might be better for that database file since it should be easier to change and audit (by just looking at the git commit) ? > > Though if BroControl parses that file and generates some internal representation that may use SQLite, that might be one way to do it. Were you mostly thinking of storing metadata/dependency stuff there? > > - Jon From robin at icir.org Mon Oct 14 20:11:53 2013 From: robin at icir.org (Robin Sommer) Date: Mon, 14 Oct 2013 20:11:53 -0700 Subject: [Bro-Dev] CBrAN Bro Control Plugin In-Reply-To: References: Message-ID: <20131015031153.GC7664@icir.org> Great to see you're up for tackling this, it's one of the major missing pieces in the Bro world (universe? :). I like Jon's terminology, and I agree that a flat file will probably work better than an SQL lite database for storing that meta information. I don't think the input framework needs to parse it, I picture all of this being handled outside of Bro itself (i.e., by BroControl). I actually need to go back to the project page to remind myself of the specifics there; it's been a while since that went up and we might want to update a few things. I'd be happy to chat sometime to flesh this out further. Robin On Mon, Oct 14, 2013 at 17:24 -0700, you wrote: > Having a name for a directory resembling "repo" when the directory is > not a repository is confusing, I agree. I'll refer to it as a package > moving forward. > > The project page refers to the package manager as CBAN, let's go with that. > > Having a flat file representation of the universe would make managing > the universe through GitHub much simpler. It would also save people > from having to write a bunch of SQL code. > My thought was for the universe database to contain the following > pieces of information (taken from the project page): name, URL, > author, tags, package version, Bro version, dependencies, license, > description. If a plain text flat file is used would would it be > useful for the file to be readable by the input framework? > > -AK > > On Mon, Oct 14, 2013 at 3:20 PM, Siwek, Jonathan Luke > wrote: > > > > On Oct 14, 2013, at 11:43 AM, anthony kasza > > wrote: > > > >> My initial thought was for the Bro project to maintain and distribute a SQLite database of rebros (git repos of Bro scripts). > > > > A terminology nitpick: a "rebro" (according to the proposal doc) isn't a git repo, but a git repo may contain rebros (directories containing a __load__.bro script). > > > > I'm only pointing it out to suggest the first step is that we come to a consensus on what terms to use to describe things else later discussion might get confusing. > > > > Here's things I think need naming: > > > > 1) A git repository that may contain bro scripts. > > > > I actually don't think these need a special name, just call it a "repo" or "repository" as usual since there's not really any unique requirements. > > > > 2) A directory containing __load__.bro. > > > > These just let Bro "@load ". "rebro" is confusing for this, since it's not a git repo itself. I've always called this a "package" for lack of anything better. > > > > 3) CBrAN > > > > Don't think this was actually decided? Works for me, except the case switch in the middle is a bother. > > > >> As Python2.5+ has native support for SQLite this would not require users to install additional Python modules. A community developer would be able to register his/her rebro for inclusion in the SQLite file distributed with broctl. The SQLite file would represent the universe referred to on the project page. > > > > If the registration process were to be something simple like a person doing a pull request on GitHub where they've added their repo to the "universe" database, a flat file rather than SQLite might be better for that database file since it should be easier to change and audit (by just looking at the git commit) ? > > > > Though if BroControl parses that file and generates some internal representation that may use SQLite, that might be one way to do it. Were you mostly thinking of storing metadata/dependency stuff there? > > > > - Jon > > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From seth at icir.org Mon Oct 14 21:37:36 2013 From: seth at icir.org (Seth Hall) Date: Tue, 15 Oct 2013 00:37:36 -0400 Subject: [Bro-Dev] CBrAN Bro Control Plugin In-Reply-To: <20131015031153.GC7664@icir.org> References: <20131015031153.GC7664@icir.org> Message-ID: <4DF0C026-8375-4451-A3F0-793FB6331CE5@icir.org> On Oct 14, 2013, at 11:11 PM, Robin Sommer wrote: > I actually need to go back to the project page to remind myself of the > specifics there; it's been a while since that went up and we might > want to update a few things. I'd be happy to chat sometime to flesh > this out further. Me too! I'm pretty excited about this. .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/20131015/6cb653ef/attachment.bin From jsiwek at illinois.edu Tue Oct 15 09:46:39 2013 From: jsiwek at illinois.edu (Siwek, Jonathan Luke) Date: Tue, 15 Oct 2013 16:46:39 +0000 Subject: [Bro-Dev] CBrAN Bro Control Plugin In-Reply-To: References: Message-ID: <16855CFB-8D94-48F9-8FB1-796E74346748@illinois.edu> On Oct 14, 2013, at 7:24 PM, anthony kasza wrote: > My thought was for the universe database to contain the following > pieces of information (taken from the project page): name, URL, > author, tags, package version, Bro version, dependencies, license, > description. I think that sounds ok, though details of how package versioning will work may need some fleshing out up front. Maybe one question to answer first: what level of stability and trustworthiness is expected from the universe? I'd say a git commit hash for versioning could give some of both. Stability in that external repos can progress as fast as they want, but the universe metadata should still point to a valid version. Trustworthiness in that it's known a universe maintainer reviewed the code associated with the hash. Problem is that a git commit hash is per-repository, but per-package versioning might be needed (i.e. limit of one package per repo w/ this scheme). - Jon From anthony.kasza at gmail.com Tue Oct 15 19:09:40 2013 From: anthony.kasza at gmail.com (anthony kasza) Date: Tue, 15 Oct 2013 19:09:40 -0700 Subject: [Bro-Dev] CBrAN Bro Control Plugin In-Reply-To: <16855CFB-8D94-48F9-8FB1-796E74346748@illinois.edu> References: <16855CFB-8D94-48F9-8FB1-796E74346748@illinois.edu> Message-ID: I like the idea of associating a commit hash to a version of a package. I didn't consider that and it's clever. That would make development of package much more fluid and assure a 'point in time' version of any package. My thoughts were to offer zero guarantee around package stability or trustworthiness to users (other than the package will install, uninstall, etc with broctl) unless the package is included in the Bro project. This would prevent the Bro team from having to manage too much. Package versioning, stability, and questions/support would be left up to package authors and package trustworthiness would be up to public reputation. This is generally how community apps are handled for Splunk. No matter how versioning is done, an announcement to all package authors should go out when new version of Bro are cut so to ensure interoperability. -AK On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke wrote: > > On Oct 14, 2013, at 7:24 PM, anthony kasza wrote: > >> My thought was for the universe database to contain the following >> pieces of information (taken from the project page): name, URL, >> author, tags, package version, Bro version, dependencies, license, >> description. > > I think that sounds ok, though details of how package versioning will work may need some fleshing out up front. Maybe one question to answer first: what level of stability and trustworthiness is expected from the universe? > > I'd say a git commit hash for versioning could give some of both. Stability in that external repos can progress as fast as they want, but the universe metadata should still point to a valid version. Trustworthiness in that it's known a universe maintainer reviewed the code associated with the hash. Problem is that a git commit hash is per-repository, but per-package versioning might be needed (i.e. limit of one package per repo w/ this scheme). > > - Jon On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke wrote: > > On Oct 14, 2013, at 7:24 PM, anthony kasza wrote: > >> My thought was for the universe database to contain the following >> pieces of information (taken from the project page): name, URL, >> author, tags, package version, Bro version, dependencies, license, >> description. > > I think that sounds ok, though details of how package versioning will work may need some fleshing out up front. Maybe one question to answer first: what level of stability and trustworthiness is expected from the universe? > > I'd say a git commit hash for versioning could give some of both. Stability in that external repos can progress as fast as they want, but the universe metadata should still point to a valid version. Trustworthiness in that it's known a universe maintainer reviewed the code associated with the hash. Problem is that a git commit hash is per-repository, but per-package versioning might be needed (i.e. limit of one package per repo w/ this scheme). > > - Jon On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke wrote: > > On Oct 14, 2013, at 7:24 PM, anthony kasza wrote: > >> My thought was for the universe database to contain the following >> pieces of information (taken from the project page): name, URL, >> author, tags, package version, Bro version, dependencies, license, >> description. > > I think that sounds ok, though details of how package versioning will work may need some fleshing out up front. Maybe one question to answer first: what level of stability and trustworthiness is expected from the universe? > > I'd say a git commit hash for versioning could give some of both. Stability in that external repos can progress as fast as they want, but the universe metadata should still point to a valid version. Trustworthiness in that it's known a universe maintainer reviewed the code associated with the hash. Problem is that a git commit hash is per-repository, but per-package versioning might be needed (i.e. limit of one package per repo w/ this scheme). > > - Jon From robin at icir.org Wed Oct 16 09:33:01 2013 From: robin at icir.org (Robin Sommer) Date: Wed, 16 Oct 2013 09:33:01 -0700 Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Update FreeBSD install instructions (72129ae) In-Reply-To: <201310142228.r9EMSpY0005112@bro-ids.icir.org> References: <201310142228.r9EMSpY0005112@bro-ids.icir.org> Message-ID: <20131016163301.GP20191@icir.org> On Mon, Oct 14, 2013 at 15:28 -0700, you wrote: > Added perl to list of packages to install (it's not installed by default). What do we require Perl for? 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 Wed Oct 16 09:59:28 2013 From: dnthayer at illinois.edu (Daniel Thayer) Date: Wed, 16 Oct 2013 11:59:28 -0500 Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Update FreeBSD install instructions (72129ae) In-Reply-To: <20131016163301.GP20191@icir.org> References: <201310142228.r9EMSpY0005112@bro-ids.icir.org> <20131016163301.GP20191@icir.org> Message-ID: <525EC5F0.3050008@illinois.edu> On 10/16/2013 11:33 AM, Robin Sommer wrote: > > On Mon, Oct 14, 2013 at 15:28 -0700, you wrote: > >> Added perl to list of packages to install (it's not installed by default). > > What do we require Perl for? > > Robin > As a test, after doing "./configure" I removed /usr/bin/perl, and here's how the build failed: [ 66%] [BISON][Parser] Building parser with bison 2.5 [ 66%] [BISON][RuleParser] Building parser with bison 2.5 [ 66%] [sed] replacing stuff in /home/repo/bro/build/src/rup.cc [ 66%] [sed] replacing stuff in /home/repo/bro/build/src/rup.h [ 66%] [BISON][REParser] Building parser with bison 2.5 [ 66%] [sed] replacing stuff in /home/repo/bro/build/src/rep.cc [ 66%] [sed] replacing stuff in /home/repo/bro/build/src/p.cc [ 66%] [FLEX][RuleScanner] Building scanner with flex 2.5.35 [ 66%] [FLEX][REScanner] Building scanner with flex 2.5.35 [ 67%] [FLEX][Scanner] Building scanner with flex 2.5.35 [ 67%] [Perl] Processing debug commands /bin/sh: 1: /usr/bin/perl: not found make[3]: *** [src/DebugCmdConstants.h] Error 127 make[3]: Leaving directory `/home/repo/bro/build' make[2]: *** [src/CMakeFiles/bro.dir/all] Error 2 make[2]: Leaving directory `/home/repo/bro/build' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/repo/bro/build' make: *** [all] Error 2 From robin at icir.org Wed Oct 16 10:34:28 2013 From: robin at icir.org (Robin Sommer) Date: Wed, 16 Oct 2013 10:34:28 -0700 Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Update FreeBSD install instructions (72129ae) In-Reply-To: <525EC5F0.3050008@illinois.edu> References: <201310142228.r9EMSpY0005112@bro-ids.icir.org> <20131016163301.GP20191@icir.org> <525EC5F0.3050008@illinois.edu> Message-ID: <20131016173428.GA86135@icir.org> On Wed, Oct 16, 2013 at 11:59 -0500, you wrote: > [ 67%] [Perl] Processing debug commands > /bin/sh: 1: /usr/bin/perl: not found Doh! That's unfortunate that a little script like that makes us depend on Perl. Todo item for 2.3: replace with a Python or awk script. 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 Wed Oct 16 10:17:30 2013 From: dnthayer at illinois.edu (Daniel Thayer) Date: Wed, 16 Oct 2013 12:17:30 -0500 Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Update FreeBSD install instructions (72129ae) In-Reply-To: <525EC5F0.3050008@illinois.edu> References: <201310142228.r9EMSpY0005112@bro-ids.icir.org> <20131016163301.GP20191@icir.org> <525EC5F0.3050008@illinois.edu> Message-ID: <525ECA2A.6020103@illinois.edu> On 10/16/2013 11:59 AM, Daniel Thayer wrote: > On 10/16/2013 11:33 AM, Robin Sommer wrote: >> >> On Mon, Oct 14, 2013 at 15:28 -0700, you wrote: >> >>> Added perl to list of packages to install (it's not installed by >>> default). >> >> What do we require Perl for? >> >> Robin >> > > As a test, after doing "./configure" I removed /usr/bin/perl, > and here's how the build failed: > > [ 66%] [BISON][Parser] Building parser with bison 2.5 > [ 66%] [BISON][RuleParser] Building parser with bison 2.5 > [ 66%] [sed] replacing stuff in /home/repo/bro/build/src/rup.cc > [ 66%] [sed] replacing stuff in /home/repo/bro/build/src/rup.h > [ 66%] [BISON][REParser] Building parser with bison 2.5 > [ 66%] [sed] replacing stuff in /home/repo/bro/build/src/rep.cc > [ 66%] [sed] replacing stuff in /home/repo/bro/build/src/p.cc > [ 66%] [FLEX][RuleScanner] Building scanner with flex 2.5.35 > [ 66%] [FLEX][REScanner] Building scanner with flex 2.5.35 > [ 67%] [FLEX][Scanner] Building scanner with flex 2.5.35 > [ 67%] [Perl] Processing debug commands > /bin/sh: 1: /usr/bin/perl: not found > make[3]: *** [src/DebugCmdConstants.h] Error 127 > make[3]: Leaving directory `/home/repo/bro/build' > make[2]: *** [src/CMakeFiles/bro.dir/all] Error 2 > make[2]: Leaving directory `/home/repo/bro/build' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/home/repo/bro/build' > make: *** [all] Error 2 > > Looks like the culprit is bro/src/make_dbg_constants.pl From jsiwek at illinois.edu Wed Oct 16 10:49:22 2013 From: jsiwek at illinois.edu (Siwek, Jonathan Luke) Date: Wed, 16 Oct 2013 17:49:22 +0000 Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/dnthayer/doc-changes-for-2.2: Update FreeBSD install instructions (72129ae) In-Reply-To: <20131016173428.GA86135@icir.org> References: <201310142228.r9EMSpY0005112@bro-ids.icir.org> <20131016163301.GP20191@icir.org> <525EC5F0.3050008@illinois.edu> <20131016173428.GA86135@icir.org> Message-ID: <11351850-C6B6-4E86-9BA9-788C91659BE9@illinois.edu> > Doh! That's unfortunate that a little script like that makes us depend > on Perl. Todo item for 2.3: replace with a Python or awk script. MIght be a way to do it in pure CMake scripting, but haven't looked closely. - Jon From jira at bro-tracker.atlassian.net Wed Oct 16 11:29:51 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 16 Oct 2013 13:29:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1047) Delete old scripts before installing new ones In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304#comment-14304 ] Jon Siwek commented on BIT-1047: -------------------------------- {quote}We should simply remove the old scripts/base and scripts/policy before installing anything new.{quote} I have topic/jsiwek/remove-old-installed-scripts do this, but it doesn't get rid of the confusing error when upgrading a 2.1 install to 2.2: {noformat} fatal error in /usr/local/bro/share/bro/policy/frameworks/software/vulnerable.bro, line 41: BroType::AsRecordType (table/record) (set[record { min:record { major:count; minor:count; minor2:count; minor3:count; addl:string; }; max:record { major:count; minor:count; minor2:count; minor3:count; addl:string; }; }]) {noformat} So the options there seem like either just document it in a how-to-upgrade doc or investigate a change in Bro to emit a more helpful error message. Or both. But I guess a lesson learned is to never have code directly in the distribution's version of local.bro, only {{@load}}'s. The change in topic/jsiwek/remove-old-installed-scripts might still be helpful in other cases, but if you want it in before 2.2 final, having a couple other people test it would be nice to make sure it doesn't accidentally hose installs in some way. > Delete old scripts before installing new ones > --------------------------------------------- > > Key: BIT-1047 > URL: https://bro-tracker.atlassian.net/browse/BIT-1047 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Fix For: 2.2 > > > People keep having problems when they install a new Bro version > over the installation of an old one because scripts that have disappeared in the new version will keep sticking around from the previous installation. > We should simply remove the old scripts/base and scripts/policy before installing anything new. People aren't supposed to edit in there so that should be safe. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Thu Oct 17 09:32:51 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 17 Oct 2013 11:32:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1047) Delete old scripts before installing new ones In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305#comment-14305 ] Robin Sommer commented on BIT-1047: ----------------------------------- I prefer to defer merging topic/jsiwek/remove-old-installed-scripts for the next development cycle. For 2.2, let's just put a note into NEWS pointing out what to change. A nicer error message would be nice obviously, but that's also something for later at this time. > Delete old scripts before installing new ones > --------------------------------------------- > > Key: BIT-1047 > URL: https://bro-tracker.atlassian.net/browse/BIT-1047 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Fix For: 2.2 > > > People keep having problems when they install a new Bro version > over the installation of an old one because scripts that have disappeared in the new version will keep sticking around from the previous installation. > We should simply remove the old scripts/base and scripts/policy before installing anything new. People aren't supposed to edit in there so that should be safe. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From robin at icir.org Thu Oct 17 11:14:10 2013 From: robin at icir.org (Robin Sommer) Date: Thu, 17 Oct 2013 11:14:10 -0700 Subject: [Bro-Dev] Draft API for new communication library Message-ID: <20131017181410.GI52382@icir.org> I have been mulling over how an API for a new communication library could look like. In short, the idea is to (1) overhaul Bro's current communication model to make it more flexible and easier to control; and (2) provide the new functionality in the form of a C library that replaces Broccoli yet will also be used by Bro itself (i.e., we;ll no longer have two independent implementations of the same protocol to maintain). Draft is here: http://www.bro.org/development/projects/comm-ng-v2.html Feedback welcome. 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 Thu Oct 17 14:45:51 2013 From: jira at bro-tracker.atlassian.net (Bob (JIRA)) Date: Thu, 17 Oct 2013 16:45:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1091) Broctl config.py handling of [manager] header is brittle In-Reply-To: References: Message-ID: Bob created BIT-1091: ------------------------ Summary: Broctl config.py handling of [manager] header is brittle Key: BIT-1091 URL: https://bro-tracker.atlassian.net/browse/BIT-1091 Project: Bro Issue Tracker Issue Type: Problem Components: BroControl Affects Versions: 2.2 Environment: RHEL6 Reporter: Bob $prefix/lib/broctl/BroControl/config.py (line 159, in nodes()) special cases the manager node of the etc/node.cfg config and checks it by the attribute n.name, as opposed to all of the other types that are handled earlier in the function, which get checked by the attribute n.type. This means that anyone who might try to set a more descriptive manager name, like [broproductionmanager] or [brotestmanager], will break broctl to disastrous effect: [root at bro-testmgr bro-2.2-beta]# /opt/bro/bin/broctl install removing old policies in /var/bro/spool/installed-scripts-do-not-touch/site ... done. removing old policies in /var/bro/spool/installed-scripts-do-not-touch/auto ... done. creating policy directories ... done. installing site policies ... done. generating local-networks.bro ... done. Traceback (most recent call last): File "/opt/bro/bin/broctl", line 980, in loop.onecmd(line) File "/usr/lib64/python2.6/cmd.py", line 219, in onecmd return func(arg) File "/opt/bro/bin/broctl", line 202, in do_install result = install.install(local) File "/opt/bro/lib/broctl/BroControl/install.py", line 112, in install util.force_symlink(manager.cwd(), current) AttributeError: 'NoneType' object has no attribute 'cwd' abnormal termination, saving state ... This should be cleaned up to make this field user-modifiable as the others are, or at the very least we should implement a warning to users that they should not change the name of the field. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jsiwek at illinois.edu Thu Oct 17 14:54:51 2013 From: jsiwek at illinois.edu (Siwek, Jonathan Luke) Date: Thu, 17 Oct 2013 21:54:51 +0000 Subject: [Bro-Dev] Draft API for new communication library In-Reply-To: <20131017181410.GI52382@icir.org> References: <20131017181410.GI52382@icir.org> Message-ID: <9C749243-F5C7-46CC-90FC-656F492B6E0A@illinois.edu> > http://www.bro.org/development/projects/comm-ng-v2.html > > Feedback welcome. Would something like Cap'n Proto or Protocol Buffers help in defining/maintaining a serialization format? Never used either, just had a good impression from skimming their docs. - Jon http://kentonv.github.io/capnproto/ https://code.google.com/p/protobuf/ https://code.google.com/p/protobuf-c/ From robin at icir.org Thu Oct 17 15:03:43 2013 From: robin at icir.org (Robin Sommer) Date: Thu, 17 Oct 2013 15:03:43 -0700 Subject: [Bro-Dev] Draft API for new communication library In-Reply-To: <9C749243-F5C7-46CC-90FC-656F492B6E0A@illinois.edu> References: <20131017181410.GI52382@icir.org> <9C749243-F5C7-46CC-90FC-656F492B6E0A@illinois.edu> Message-ID: <20131017220343.GP52382@icir.org> On Thu, Oct 17, 2013 at 21:54 +0000, you wrote: > Would something like Cap'n Proto or Protocol Buffers help in > defining/maintaining a serialization format? I didn't know Cap?n Proto so far but I have been wondering about using Protocol Buffers already as well. We'd have to add another dependency but it would make this stuff quite a bit less cumbersome. Do you know if their C version is well maintained? It looks rather old compared to the standard protobuf distribution. Does Cap'n Proto have a C API? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From gc355804 at ohio.edu Thu Oct 17 18:30:28 2013 From: gc355804 at ohio.edu (Clark, Gilbert) Date: Thu, 17 Oct 2013 21:30:28 -0400 Subject: [Bro-Dev] Draft API for new communication library In-Reply-To: <20131017220343.GP52382@icir.org> References: <20131017181410.GI52382@icir.org> <9C749243-F5C7-46CC-90FC-656F492B6E0A@illinois.edu>, <20131017220343.GP52382@icir.org> Message-ID: <1D657054C5E2994C98FE68E14DD10A2B3846DFBB22@EXMAIL1.ohio.edu> FWIW, nanopb is a lightweight (read: targeted at embedded devices) C library that is compatible with protobuf. http://koti.kapsi.fi/~jpa/nanopb/ --Gilbert ________________________________________ From: bro-dev-bounces at bro.org [bro-dev-bounces at bro.org] On Behalf Of Robin Sommer [robin at icir.org] Sent: Thursday, October 17, 2013 6:03 PM To: Siwek, Jonathan Luke Cc: Subject: Re: [Bro-Dev] Draft API for new communication library On Thu, Oct 17, 2013 at 21:54 +0000, you wrote: > Would something like Cap'n Proto or Protocol Buffers help in > defining/maintaining a serialization format? I didn't know Cap?n Proto so far but I have been wondering about using Protocol Buffers already as well. We'd have to add another dependency but it would make this stuff quite a bit less cumbersome. Do you know if their C version is well maintained? It looks rather old compared to the standard protobuf distribution. Does Cap'n Proto have a C API? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev at bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev From jira at bro-tracker.atlassian.net Fri Oct 18 00:24:51 2013 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 18 Oct 2013 02:24:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1091) Broctl config.py handling of [manager] header is brittle In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306#comment-14306 ] Daniel Thayer commented on BIT-1091: ------------------------------------ I'm not aware of any reason why the manager node must be named "manager". Not sure why the code in broctl was written that way. I've fixed this issue in branch topic/dnthayer/ticket1091. > Broctl config.py handling of [manager] header is brittle > -------------------------------------------------------- > > Key: BIT-1091 > URL: https://bro-tracker.atlassian.net/browse/BIT-1091 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: 2.2 > Environment: RHEL6 > Reporter: Bob > Labels: beta, broctl > > $prefix/lib/broctl/BroControl/config.py (line 159, in nodes()) special cases the manager node of the etc/node.cfg config and checks it by the attribute n.name, as opposed to all of the other types that are handled earlier in the function, which get checked by the attribute n.type. This means that anyone who might try to set a more descriptive manager name, like [broproductionmanager] or [brotestmanager], will break broctl to disastrous effect: > [root at bro-testmgr bro-2.2-beta]# /opt/bro/bin/broctl install > removing old policies in /var/bro/spool/installed-scripts-do-not-touch/site ... done. > removing old policies in /var/bro/spool/installed-scripts-do-not-touch/auto ... done. > creating policy directories ... done. > installing site policies ... done. > generating local-networks.bro ... done. > Traceback (most recent call last): > File "/opt/bro/bin/broctl", line 980, in > loop.onecmd(line) > File "/usr/lib64/python2.6/cmd.py", line 219, in onecmd > return func(arg) > File "/opt/bro/bin/broctl", line 202, in do_install > result = install.install(local) > File "/opt/bro/lib/broctl/BroControl/install.py", line 112, in install > util.force_symlink(manager.cwd(), current) > AttributeError: 'NoneType' object has no attribute 'cwd' > abnormal termination, saving state ... > This should be cleaned up to make this field user-modifiable as the others are, or at the very least we should implement a warning to users that they should not change the name of the field. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Fri Oct 18 00:26:51 2013 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 18 Oct 2013 02:26:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1091) Broctl config.py handling of [manager] header is brittle In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1091: ------------------------------- Fix Version/s: 2.2 Affects Version/s: (was: 2.2) > Broctl config.py handling of [manager] header is brittle > -------------------------------------------------------- > > Key: BIT-1091 > URL: https://bro-tracker.atlassian.net/browse/BIT-1091 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Environment: RHEL6 > Reporter: Bob > Labels: beta, broctl > Fix For: 2.2 > > > $prefix/lib/broctl/BroControl/config.py (line 159, in nodes()) special cases the manager node of the etc/node.cfg config and checks it by the attribute n.name, as opposed to all of the other types that are handled earlier in the function, which get checked by the attribute n.type. This means that anyone who might try to set a more descriptive manager name, like [broproductionmanager] or [brotestmanager], will break broctl to disastrous effect: > [root at bro-testmgr bro-2.2-beta]# /opt/bro/bin/broctl install > removing old policies in /var/bro/spool/installed-scripts-do-not-touch/site ... done. > removing old policies in /var/bro/spool/installed-scripts-do-not-touch/auto ... done. > creating policy directories ... done. > installing site policies ... done. > generating local-networks.bro ... done. > Traceback (most recent call last): > File "/opt/bro/bin/broctl", line 980, in > loop.onecmd(line) > File "/usr/lib64/python2.6/cmd.py", line 219, in onecmd > return func(arg) > File "/opt/bro/bin/broctl", line 202, in do_install > result = install.install(local) > File "/opt/bro/lib/broctl/BroControl/install.py", line 112, in install > util.force_symlink(manager.cwd(), current) > AttributeError: 'NoneType' object has no attribute 'cwd' > abnormal termination, saving state ... > This should be cleaned up to make this field user-modifiable as the others are, or at the very least we should implement a warning to users that they should not change the name of the field. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From jira at bro-tracker.atlassian.net Fri Oct 18 00:26:51 2013 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 18 Oct 2013 02:26:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1091) Broctl config.py handling of [manager] header is brittle In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1091: ------------------------------- Status: Merge Request (was: Open) > Broctl config.py handling of [manager] header is brittle > -------------------------------------------------------- > > Key: BIT-1091 > URL: https://bro-tracker.atlassian.net/browse/BIT-1091 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Environment: RHEL6 > Reporter: Bob > Labels: beta, broctl > Fix For: 2.2 > > > $prefix/lib/broctl/BroControl/config.py (line 159, in nodes()) special cases the manager node of the etc/node.cfg config and checks it by the attribute n.name, as opposed to all of the other types that are handled earlier in the function, which get checked by the attribute n.type. This means that anyone who might try to set a more descriptive manager name, like [broproductionmanager] or [brotestmanager], will break broctl to disastrous effect: > [root at bro-testmgr bro-2.2-beta]# /opt/bro/bin/broctl install > removing old policies in /var/bro/spool/installed-scripts-do-not-touch/site ... done. > removing old policies in /var/bro/spool/installed-scripts-do-not-touch/auto ... done. > creating policy directories ... done. > installing site policies ... done. > generating local-networks.bro ... done. > Traceback (most recent call last): > File "/opt/bro/bin/broctl", line 980, in > loop.onecmd(line) > File "/usr/lib64/python2.6/cmd.py", line 219, in onecmd > return func(arg) > File "/opt/bro/bin/broctl", line 202, in do_install > result = install.install(local) > File "/opt/bro/lib/broctl/BroControl/install.py", line 112, in install > util.force_symlink(manager.cwd(), current) > AttributeError: 'NoneType' object has no attribute 'cwd' > abnormal termination, saving state ... > This should be cleaned up to make this field user-modifiable as the others are, or at the very least we should implement a warning to users that they should not change the name of the field. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From robin at icir.org Fri Oct 18 08:31:10 2013 From: robin at icir.org (Robin Sommer) Date: Fri, 18 Oct 2013 08:31:10 -0700 Subject: [Bro-Dev] Draft API for new communication library In-Reply-To: <1D657054C5E2994C98FE68E14DD10A2B3846DFBB22@EXMAIL1.ohio.edu> References: <20131017181410.GI52382@icir.org> <9C749243-F5C7-46CC-90FC-656F492B6E0A@illinois.edu> <20131017220343.GP52382@icir.org> <1D657054C5E2994C98FE68E14DD10A2B3846DFBB22@EXMAIL1.ohio.edu> Message-ID: <20131018153110.GA65589@icir.org> > http://koti.kapsi.fi/~jpa/nanopb/ Nice, that looks like an interesting option. Btw, another advantage of using something like PB is that it would make the serialization more portable. I believe this will be one part where we'll have to keep separate implementastions for Bro and external clients (because in Bro everythingn is already stored in Val, and if we'd use an additional C interface we'd have to convert everything over first; might just as well serialize it directly, but then having a "middle layer" like PB would certainly be helpful). Another alternative would be reusing the code that logging and input framework currently deploy for reading/writing Vals. That was my initial thought, but it limits us to types they support (essentially things which can be easily represented in ASCII); probably not ideal. On the other hand, maybe we could switch logging/input over to using the new implementation we come up with here instead. It would certainly be nice to unify the whole serialization code in one place. 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 Oct 18 13:46:51 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 18 Oct 2013 15:46:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-751) Broxygen Wishlist In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307#comment-14307 ] Robin Sommer commented on BIT-751: ---------------------------------- just another note for the record: we're currently duplicating some text describing packages in both the READ and the main.bro > Broxygen Wishlist > ----------------- > > Key: BIT-751 > URL: https://bro-tracker.atlassian.net/browse/BIT-751 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro > Affects Versions: 2.0 > Reporter: Robin Sommer > Fix For: 2.2 > > > Collecting a number of lower priority items here I noticed: > \\- In a script's summary section, would be nice if the namespace linked > bq. to the corresponding index entry that lists all the scripts > bq. contributing to that namespace. > \\- Thoughts on restructuring the summary section: > * Notices: Should list the new Notices and link them to a part in the Detailed Interface that describes them. Could then become the first entry of the Summary. > * Redefinitions: Currently shows the type being modified and the text associated with the new comment, but not the new value itself. Not totally sure how to change, but perhaps just list the ID being modified here and then also link to Detailed INterface section. > * Redefinitions: That's sometimes hard to understand currently, like in ?scripts/base/frameworks/notice/weird.html: It's not that intuitive that Weird::Log is added to Log::ID; and also not what the comment belongs to. > * Package index: would be nice if it had a brief description of each package, ideally generated automatically somehow (from comments in the +load+.bro perhaps?) > \\- make \-j doesn't work reliably with the doc generation, can give some > bq. odd errors. > \\- With all docs in Sphinx now, it would be helpful not have to rebuild > bq. everything (including Broxygen) each time one runs "make doc". I > bq. remember we discussed using the pickled Sphinx cache before and it > bq. didn't seem worth the trouble. May be worth reconsiderng now to keep > bq. the rebuild times small when doing just doc/* changes. > \\- CSS styling the Broxygen part is a bit tricky because it always > bq. impacts the rest of the Sphinx-generated content. Is there a way to > bq. have a general "broxygen" CSS selector to select only Broxygen > bq. items? -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) From noreply at bro.org Sat Oct 19 00:00:21 2013 From: noreply at bro.org (Merge Tracker) Date: Sat, 19 Oct 2013 00:00:21 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310190700.r9J70Lw8010553@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------- ---------- ---------- ------------- ---------- -------------------------------------------------------- BIT-1091 [1] BroControl Bob - 2013-10-18 2.2 Normal Broctl config.py handling of [manager] header is brittle [1] BIT-1091 https://bro-tracker.atlassian.net/browse/BIT-1091 From jira at bro-tracker.atlassian.net Sat Oct 19 12:59:51 2013 From: jira at bro-tracker.atlassian.net (Fahad Arshad (JIRA)) Date: Sat, 19 Oct 2013 14:59:51 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1092) Handling of variable size 802.11 link-headers In-Reply-To: References: Message-ID: Fahad Arshad created BIT-1092: --------------------------------- Summary: 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.1, 2.0 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.1-OD-09-WN#6144) From noreply at bro.org Sun Oct 20 00:00:11 2013 From: noreply at bro.org (Merge Tracker) Date: Sun, 20 Oct 2013 00:00:11 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310200700.r9K70BXq022909@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------- ---------- ---------- ------------- ---------- -------------------------------------------------------- BIT-1091 [1] BroControl Bob - 2013-10-18 2.2 Normal Broctl config.py handling of [manager] header is brittle [1] BIT-1091 https://bro-tracker.atlassian.net/browse/BIT-1091 From noreply at bro.org Mon Oct 21 00:00:11 2013 From: noreply at bro.org (Merge Tracker) Date: Mon, 21 Oct 2013 00:00:11 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310210700.r9L70BDm007325@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------- ---------- ---------- ------------- ---------- -------------------------------------------------------- BIT-1091 [1] BroControl Bob - 2013-10-18 2.2 Normal Broctl config.py handling of [manager] header is brittle [1] BIT-1091 https://bro-tracker.atlassian.net/browse/BIT-1091 From jira at bro-tracker.atlassian.net Mon Oct 21 07:45:17 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 21 Oct 2013 09:45:17 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1091) Broctl config.py handling of [manager] header is brittle In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1091: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Broctl config.py handling of [manager] header is brittle > -------------------------------------------------------- > > Key: BIT-1091 > URL: https://bro-tracker.atlassian.net/browse/BIT-1091 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Environment: RHEL6 > Reporter: Bob > Labels: beta, broctl > Fix For: 2.2 > > > $prefix/lib/broctl/BroControl/config.py (line 159, in nodes()) special cases the manager node of the etc/node.cfg config and checks it by the attribute n.name, as opposed to all of the other types that are handled earlier in the function, which get checked by the attribute n.type. This means that anyone who might try to set a more descriptive manager name, like [broproductionmanager] or [brotestmanager], will break broctl to disastrous effect: > [root at bro-testmgr bro-2.2-beta]# /opt/bro/bin/broctl install > removing old policies in /var/bro/spool/installed-scripts-do-not-touch/site ... done. > removing old policies in /var/bro/spool/installed-scripts-do-not-touch/auto ... done. > creating policy directories ... done. > installing site policies ... done. > generating local-networks.bro ... done. > Traceback (most recent call last): > File "/opt/bro/bin/broctl", line 980, in > loop.onecmd(line) > File "/usr/lib64/python2.6/cmd.py", line 219, in onecmd > return func(arg) > File "/opt/bro/bin/broctl", line 202, in do_install > result = install.install(local) > File "/opt/bro/lib/broctl/BroControl/install.py", line 112, in install > util.force_symlink(manager.cwd(), current) > AttributeError: 'NoneType' object has no attribute 'cwd' > abnormal termination, saving state ... > This should be cleaned up to make this field user-modifiable as the others are, or at the very least we should implement a warning to users that they should not change the name of the field. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From anthony.kasza at gmail.com Mon Oct 21 22:02:50 2013 From: anthony.kasza at gmail.com (anthony kasza) Date: Mon, 21 Oct 2013 22:02:50 -0700 Subject: [Bro-Dev] CBrAN Bro Control Plugin In-Reply-To: References: <16855CFB-8D94-48F9-8FB1-796E74346748@illinois.edu> Message-ID: Robin, Were you thinking of chatting off list? If so, how and when? -AK On Tue, Oct 15, 2013 at 7:09 PM, anthony kasza wrote: > I like the idea of associating a commit hash to a version of a > package. I didn't consider that and it's clever. That would make > development of package much more fluid and assure a 'point in time' > version of any package. > > My thoughts were to offer zero guarantee around package stability or > trustworthiness to users (other than the package will install, > uninstall, etc with broctl) unless the package is included in the Bro > project. This would prevent the Bro team from having to manage too > much. Package versioning, stability, and questions/support would be > left up to package authors and package trustworthiness would be up to > public reputation. This is generally how community apps are handled > for Splunk. > > No matter how versioning is done, an announcement to all package > authors should go out when new version of Bro are cut so to ensure > interoperability. > > -AK > > On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke > wrote: >> >> On Oct 14, 2013, at 7:24 PM, anthony kasza wrote: >> >>> My thought was for the universe database to contain the following >>> pieces of information (taken from the project page): name, URL, >>> author, tags, package version, Bro version, dependencies, license, >>> description. >> >> I think that sounds ok, though details of how package versioning will work may need some fleshing out up front. Maybe one question to answer first: what level of stability and trustworthiness is expected from the universe? >> >> I'd say a git commit hash for versioning could give some of both. Stability in that external repos can progress as fast as they want, but the universe metadata should still point to a valid version. Trustworthiness in that it's known a universe maintainer reviewed the code associated with the hash. Problem is that a git commit hash is per-repository, but per-package versioning might be needed (i.e. limit of one package per repo w/ this scheme). >> >> - Jon > > > On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke > wrote: >> >> On Oct 14, 2013, at 7:24 PM, anthony kasza wrote: >> >>> My thought was for the universe database to contain the following >>> pieces of information (taken from the project page): name, URL, >>> author, tags, package version, Bro version, dependencies, license, >>> description. >> >> I think that sounds ok, though details of how package versioning will work may need some fleshing out up front. Maybe one question to answer first: what level of stability and trustworthiness is expected from the universe? >> >> I'd say a git commit hash for versioning could give some of both. Stability in that external repos can progress as fast as they want, but the universe metadata should still point to a valid version. Trustworthiness in that it's known a universe maintainer reviewed the code associated with the hash. Problem is that a git commit hash is per-repository, but per-package versioning might be needed (i.e. limit of one package per repo w/ this scheme). >> >> - Jon > > > On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke > wrote: >> >> On Oct 14, 2013, at 7:24 PM, anthony kasza wrote: >> >>> My thought was for the universe database to contain the following >>> pieces of information (taken from the project page): name, URL, >>> author, tags, package version, Bro version, dependencies, license, >>> description. >> >> I think that sounds ok, though details of how package versioning will work may need some fleshing out up front. Maybe one question to answer first: what level of stability and trustworthiness is expected from the universe? >> >> I'd say a git commit hash for versioning could give some of both. Stability in that external repos can progress as fast as they want, but the universe metadata should still point to a valid version. Trustworthiness in that it's known a universe maintainer reviewed the code associated with the hash. Problem is that a git commit hash is per-repository, but per-package versioning might be needed (i.e. limit of one package per repo w/ this scheme). >> >> - Jon From jira at bro-tracker.atlassian.net Tue Oct 22 15:20:17 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 22 Oct 2013 17:20:17 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1047) Delete old scripts before installing new ones In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14400#comment-14400 ] Robin Sommer commented on BIT-1047: ----------------------------------- Can somebody put together a blurb for the NEWS file and what change to make? Also, do we want to point out any changes to the software framework in NEWS? > Delete old scripts before installing new ones > --------------------------------------------- > > Key: BIT-1047 > URL: https://bro-tracker.atlassian.net/browse/BIT-1047 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Fix For: 2.2 > > > People keep having problems when they install a new Bro version > over the installation of an old one because scripts that have disappeared in the new version will keep sticking around from the previous installation. > We should simply remove the old scripts/base and scripts/policy before installing anything new. People aren't supposed to edit in there so that should be safe. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From noreply at bro.org Thu Oct 24 00:00:13 2013 From: noreply at bro.org (Merge Tracker) Date: Thu, 24 Oct 2013 00:00:13 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310240700.r9O70D1j026746@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------- ---------- --------------------------------------------------- eab886f [1] bro Jon Siwek 2013-10-23 Change test of identify_data BIF to ignore charset. [1] eab886f https://github.com/bro/bro/commit/eab886fb84e1a6e531470ec3872361b9791c8033 From gc355804 at ohio.edu Thu Oct 24 21:04:34 2013 From: gc355804 at ohio.edu (Clark, Gilbert) Date: Fri, 25 Oct 2013 00:04:34 -0400 Subject: [Bro-Dev] [Bro-Commits] [git/bro] master: Fix for input readers occasionally dead-locking. (c980d10) In-Reply-To: <201310250128.r9P1SBTY007795@bro-ids.icir.org> References: <201310250128.r9P1SBTY007795@bro-ids.icir.org> Message-ID: <1D657054C5E2994C98FE68E14DD10A2B38486C458F@EXMAIL1.ohio.edu> // Thoughts? /* * Since we know that read_ctr is only incremented after a successful read, and write_ctr is only incremented after a successful write, the two values should be equal iff the queue is empty. I think it could also help if these two items were * declared volatile. */ bool MaybeReady() { return read_ctr != write_ctr; } // Alternatively, replacing random() with a per-instance counter and saying the function returns true every Xth time it is called might mean you weren't having to hit the RNG every time you checked on the status of a queue. // Also, should the call be to random_r() instead of random() ? // --Gilbert ________________________________________ From: bro-commits-bounces at bro.org [bro-commits-bounces at bro.org] On Behalf Of Robin Sommer [robin at icir.org] Sent: Thursday, October 24, 2013 9:28 PM To: bro-commits at bro.org Subject: [Bro-Commits] [git/bro] master: Fix for input readers occasionally dead-locking. (c980d10) Repository : ssh://git at bro-ids.icir.org/bro On branch : master Link : https://github.com/bro/bro/commit/c980d1055e1e17da4867e3fab1ee10f604b242b0 >--------------------------------------------------------------- commit c980d1055e1e17da4867e3fab1ee10f604b242b0 Author: Robin Sommer Date: Thu Oct 24 18:16:49 2013 -0700 Fix for input readers occasionally dead-locking. Bernhard and I tracked it down we believe: the thread queue could deadlock in certain cases. As a fix we tuned the heuristic for telling if a queue might have input to occasionaly err on the safe side by flagging "yes", so that processing will proceed. It's a bit unfortunate to apply this fix last minute before the release as it could potentially impact performance if the heuristic fails to often. We believe the chosen parmaterization should be fine ... >--------------------------------------------------------------- c980d1055e1e17da4867e3fab1ee10f604b242b0 CHANGES | 4 ++++ VERSION | 2 +- src/threading/Queue.h | 10 ++++++---- 3 files changed, 11 insertions(+), 5 deletions(-) diff --git a/CHANGES b/CHANGES index 10bc187..1ae192f 100644 --- a/CHANGES +++ b/CHANGES @@ -1,4 +1,8 @@ +2.2-beta-152 | 2013-10-24 18:16:49 -0700 + + * Fix for input readers occasionally dead-locking. (Robin Sommer) + 2.2-beta-151 | 2013-10-24 16:52:26 -0700 * Updating submodule(s). diff --git a/VERSION b/VERSION index 2b5702f..26d1beb 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -2.2-beta-151 +2.2-beta-152 diff --git a/src/threading/Queue.h b/src/threading/Queue.h index 792fb63..c4f2bfa 100644 --- a/src/threading/Queue.h +++ b/src/threading/Queue.h @@ -61,11 +61,13 @@ public: bool Ready(); /** - * Returns true if the next Get() operation might succeed. - * This function may occasionally return a value not - * indicating the actual state, but won't do so very often. + * Returns true if the next Get() operation might succeed. This + * function may occasionally return a value not indicating the actual + * state, but won't do so very often. Occasionally we also return a + * true unconditionally to avoid a deadlock when both pointers happen + * to be equal even though there's stuff queued. */ - bool MaybeReady() { return ( ( read_ptr - write_ptr) != 0 ); } + bool MaybeReady() { return (read_ptr != write_ptr) || (random() % 10000 == 0); } /** Wake up the reader if it's currently blocked for input. This is primarily to give it a chance to check termination quickly. _______________________________________________ bro-commits mailing list bro-commits at bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-commits From bernhard at ICSI.Berkeley.EDU Thu Oct 24 23:43:21 2013 From: bernhard at ICSI.Berkeley.EDU (Bernhard Amann) Date: Thu, 24 Oct 2013 23:43:21 -0700 Subject: [Bro-Dev] [Bro-Commits] [git/bro] master: Fix for input readers occasionally dead-locking. (c980d10) In-Reply-To: <1D657054C5E2994C98FE68E14DD10A2B38486C458F@EXMAIL1.ohio.edu> References: <201310250128.r9P1SBTY007795@bro-ids.icir.org> <1D657054C5E2994C98FE68E14DD10A2B38486C458F@EXMAIL1.ohio.edu> Message-ID: <82BCCF80-D2EE-4647-A4F3-83CDBFFA4E0B@icsi.berkeley.edu> I just committed an alternative fix to topic/bernhard/alternative-deadlock-fix - this removes the random from Queue again and places another random into the threading manager. However, this one is only called if no communication whatsoever occurs - and only by the main thread, so random() should be fine. Bernhard On Oct 24, 2013, at 9:04 PM, Clark, Gilbert wrote: > // Thoughts? > > /* > * Since we know that read_ctr is only incremented after a successful read, and write_ctr is only incremented after a successful write, the two values should be equal iff the queue is empty. I think it could also help if these two items were > * declared volatile. > */ > bool MaybeReady() { return read_ctr != write_ctr; } > > // Alternatively, replacing random() with a per-instance counter and saying the function returns true every Xth time it is called might mean you weren't having to hit the RNG every time you checked on the status of a queue. > // Also, should the call be to random_r() instead of random() ? > > // --Gilbert > ________________________________________ > From: bro-commits-bounces at bro.org [bro-commits-bounces at bro.org] On Behalf Of Robin Sommer [robin at icir.org] > Sent: Thursday, October 24, 2013 9:28 PM > To: bro-commits at bro.org > Subject: [Bro-Commits] [git/bro] master: Fix for input readers occasionally dead-locking. (c980d10) > > Repository : ssh://git at bro-ids.icir.org/bro > > On branch : master > Link : https://github.com/bro/bro/commit/c980d1055e1e17da4867e3fab1ee10f604b242b0 > >> --------------------------------------------------------------- > > commit c980d1055e1e17da4867e3fab1ee10f604b242b0 > Author: Robin Sommer > Date: Thu Oct 24 18:16:49 2013 -0700 > > Fix for input readers occasionally dead-locking. > > Bernhard and I tracked it down we believe: the thread queue could > deadlock in certain cases. As a fix we tuned the heuristic for telling > if a queue might have input to occasionaly err on the safe side by > flagging "yes", so that processing will proceed. > > It's a bit unfortunate to apply this fix last minute before the > release as it could potentially impact performance if the heuristic > fails to often. We believe the chosen parmaterization should be fine ... > > >> --------------------------------------------------------------- > > c980d1055e1e17da4867e3fab1ee10f604b242b0 > CHANGES | 4 ++++ > VERSION | 2 +- > src/threading/Queue.h | 10 ++++++---- > 3 files changed, 11 insertions(+), 5 deletions(-) > > diff --git a/CHANGES b/CHANGES > index 10bc187..1ae192f 100644 > --- a/CHANGES > +++ b/CHANGES > @@ -1,4 +1,8 @@ > > +2.2-beta-152 | 2013-10-24 18:16:49 -0700 > + > + * Fix for input readers occasionally dead-locking. (Robin Sommer) > + > 2.2-beta-151 | 2013-10-24 16:52:26 -0700 > > * Updating submodule(s). > diff --git a/VERSION b/VERSION > index 2b5702f..26d1beb 100644 > --- a/VERSION > +++ b/VERSION > @@ -1 +1 @@ > -2.2-beta-151 > +2.2-beta-152 > diff --git a/src/threading/Queue.h b/src/threading/Queue.h > index 792fb63..c4f2bfa 100644 > --- a/src/threading/Queue.h > +++ b/src/threading/Queue.h > @@ -61,11 +61,13 @@ public: > bool Ready(); > > /** > - * Returns true if the next Get() operation might succeed. > - * This function may occasionally return a value not > - * indicating the actual state, but won't do so very often. > + * Returns true if the next Get() operation might succeed. This > + * function may occasionally return a value not indicating the actual > + * state, but won't do so very often. Occasionally we also return a > + * true unconditionally to avoid a deadlock when both pointers happen > + * to be equal even though there's stuff queued. > */ > - bool MaybeReady() { return ( ( read_ptr - write_ptr) != 0 ); } > + bool MaybeReady() { return (read_ptr != write_ptr) || (random() % 10000 == 0); } > > /** Wake up the reader if it's currently blocked for input. This is > primarily to give it a chance to check termination quickly. > > _______________________________________________ > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4160 bytes Desc: not available Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20131024/2b56511a/attachment.bin From robin at icir.org Fri Oct 25 11:24:21 2013 From: robin at icir.org (Robin Sommer) Date: Fri, 25 Oct 2013 11:24:21 -0700 Subject: [Bro-Dev] [Bro-Commits] [git/bro] master: Fix for input readers occasionally dead-locking. (c980d10) In-Reply-To: <1D657054C5E2994C98FE68E14DD10A2B38486C458F@EXMAIL1.ohio.edu> References: <201310250128.r9P1SBTY007795@bro-ids.icir.org> <1D657054C5E2994C98FE68E14DD10A2B38486C458F@EXMAIL1.ohio.edu> Message-ID: <20131025182421.GJ42992@icir.org> On Fri, Oct 25, 2013 at 00:04 -0400, you wrote: > * Since we know that read_ctr is only incremented after a successful > read, and write_ctr is only incremented after a successful write, the > two values should be equal iff the queue is empty. That's actually not the case, and that was the problem. There can be elements in the queue even if both pointers align; that happens if the writer is exactly a full round ahead of the reader. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From gc355804 at ohio.edu Fri Oct 25 14:55:52 2013 From: gc355804 at ohio.edu (Gilbert Clark) Date: Fri, 25 Oct 2013 17:55:52 -0400 Subject: [Bro-Dev] [Bro-Commits] [git/bro] master: Fix for input readers occasionally dead-locking. (c980d10) In-Reply-To: <20131025182421.GJ42992@icir.org> References: <201310250128.r9P1SBTY007795@bro-ids.icir.org> <1D657054C5E2994C98FE68E14DD10A2B38486C458F@EXMAIL1.ohio.edu> <20131025182421.GJ42992@icir.org> Message-ID: <526AE8E8.20108@ohio.edu> I meant compare the absolute counters (_ctr), not the pointers (_ptr). Assuming I understand how this works, read_ctr / write_ctr are absolute counts kept in order to keep track of how many times the queue has been read from / written to, are incremented in the same places that the pointers are, and are currently only used to keep statistics for the queue. Since these counts are absolute, there shouldn't be a situation where they're equal unless the queue is empty. Also, keeping both the counters and the pointers around may be redundant. I think it'd be a pretty easy change to start using absolute values only and mod on access, and I'd imagine performance-wise it would end up being pretty comparable. Cheers, Gilbert On 10/25/13 2:24 PM, Robin Sommer wrote: > On Fri, Oct 25, 2013 at 00:04 -0400, you wrote: > >> * Since we know that read_ctr is only incremented after a successful >> read, and write_ctr is only incremented after a successful write, the >> two values should be equal iff the queue is empty. > That's actually not the case, and that was the problem. There can be > elements in the queue even if both pointers align; that happens if the > writer is exactly a full round ahead of the reader. > > Robin > From jira at bro-tracker.atlassian.net Fri Oct 25 20:34:17 2013 From: jira at bro-tracker.atlassian.net (sconzo (JIRA)) Date: Fri, 25 Oct 2013 22:34:17 -0500 (CDT) 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=14401#comment-14401 ] sconzo commented on BIT-1090: ----------------------------- I did something similar in 2.1 the way I was able to add things to the table outside of the script was: ::[key] = set([v1],[v2]); For your example try: SSH::ignore_guessers[172.0.0.0/16] = set( 10.0.0.1/32 ); SSH::ignore_guessers[192.168.1.0/24] = set( 192.168.2.0/24 ); I didn't have a pcap to test your example with, but this worked for me with my def of: "const filter: table[string] of set[addr] = {} &redef;" > 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 noreply at bro.org Sat Oct 26 00:00:12 2013 From: noreply at bro.org (Merge Tracker) Date: Sat, 26 Oct 2013 00:00:12 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310260700.r9Q70CmM007547@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- -------------- ---------- -------------------------------------------------- f90fcdf [1] bro Bernhard Amann 2013-10-25 Revert "Fix the dir module." 4b0ee2e [2] bro Bernhard Amann 2013-10-25 Fix the dir module. c299a71 [3] bro Daniel Thayer 2013-10-25 Add curl to list of optional dependencies 32d7c96 [4] bro Daniel Thayer 2013-10-25 Update test and baseline for a recent doc test fix [1] f90fcdf https://github.com/bro/bro/commit/f90fcdf15207c4a979b9c38e338b5e3a73a86fb5 [2] 4b0ee2e https://github.com/bro/bro/commit/4b0ee2e7ca904d150a687435c2e1b0fdbc241572 [3] c299a71 https://github.com/bro/bro/commit/c299a71b83bfd158bfc16dec36145adfa7f43513 [4] 32d7c96 https://github.com/bro/bro/commit/32d7c96cd426f11190cb971f7fa1250570c6e68d From robin at icir.org Sat Oct 26 19:25:00 2013 From: robin at icir.org (Robin Sommer) Date: Sat, 26 Oct 2013 19:25:00 -0700 Subject: [Bro-Dev] [Bro-Commits] [git/bro] master: Fix for input readers occasionally dead-locking. (c980d10) In-Reply-To: <526AE8E8.20108@ohio.edu> References: <201310250128.r9P1SBTY007795@bro-ids.icir.org> <1D657054C5E2994C98FE68E14DD10A2B38486C458F@EXMAIL1.ohio.edu> <20131025182421.GJ42992@icir.org> <526AE8E8.20108@ohio.edu> Message-ID: <20131027022500.GD89425@icir.org> On Fri, Oct 25, 2013 at 17:55 -0400, you wrote: > I meant compare the absolute counters (_ctr), not the pointers (_ptr). Ah, you mean num_reads/writes. You're right, that should actually work, I forgot that we already track these stats. I'm changing the fix to do this, thanks! > Also, keeping both the counters and the pointers around may be > redundant. I think it'd be a pretty easy change to start using absolute > values only and mod on access, and I'd imagine performance-wise it would > end up being pretty comparable. Yeah, probably. My main performance concern here is the queue locking, everything else probably doesn't matter too much. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From vallentin at icir.org Mon Oct 28 18:09:10 2013 From: vallentin at icir.org (Matthias Vallentin) Date: Mon, 28 Oct 2013 18:09:10 -0700 Subject: [Bro-Dev] Segfault in TM Message-ID: <20131029010910.GW22201@icir.org> (I'm sending this as email because the TM tracker does not work for me: the project has no components, which prevents filing an issue.) Ahir consistently ran into segmentation faults with his workload. We debugged the issue and found the culprit: In FifoDisk.cc, a call std::vector::front() violates the precondition ! std::vector::empty() and thus causes UB. I fixed this here: https://github.com/mavam/time-machine It's a one-line fix and ready to merge. Matthias From noreply at bro.org Tue Oct 29 00:00:18 2013 From: noreply at bro.org (Merge Tracker) Date: Tue, 29 Oct 2013 00:00:18 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310290700.r9T70INv012336@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ------------------------------------------------------------ b255aed [1] bro Jon Siwek 2013-10-28 Fix race condition in unit test. 31c7c1a [2] bro Vlad Grigorescu 2013-10-28 Change percent_lost in capture-loss from a string to a doubl [1] b255aed https://github.com/bro/bro/commit/b255aedc26ec09d0eca7c83b94d2b4c7996676e8 [2] 31c7c1a https://github.com/bro/bro/commit/31c7c1a6737ddf8bc9b6537459f617ea57c0b799 From jsiwek at illinois.edu Tue Oct 29 08:34:52 2013 From: jsiwek at illinois.edu (Siwek, Jonathan Luke) Date: Tue, 29 Oct 2013 15:34:52 +0000 Subject: [Bro-Dev] Segfault in TM In-Reply-To: <20131029010910.GW22201@icir.org> References: <20131029010910.GW22201@icir.org> Message-ID: <64CCC27A-E89A-4631-AA48-ACE99BE7726E@illinois.edu> On Oct 28, 2013, at 8:09 PM, Matthias Vallentin wrote: > (I'm sending this as email because the TM tracker does not work for me: > the project has no components, which prevents filing an issue.) I just made the component field optional for TM tickets which should fix it, let me know if not. - Jon From jira at bro-tracker.atlassian.net Tue Oct 29 11:24:03 2013 From: jira at bro-tracker.atlassian.net (Matthias Vallentin (JIRA)) Date: Tue, 29 Oct 2013 13:24:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (TM-15) Segfault in FifoDisk.cc In-Reply-To: References: Message-ID: Matthias Vallentin created TM-15: ------------------------------------ Summary: Segfault in FifoDisk.cc Key: TM-15 URL: https://bro-tracker.atlassian.net/browse/TM-15 Project: Time Machine Issue Type: Patch Affects Versions: git/master Environment: Confirmed on 32 and 64-bit Linux. Reporter: Matthias Vallentin Fix For: git/master Ahir consistently ran into segmentation faults with his workload. We debugged the issue and found the culprit: In FifoDisk.cc, a call to {{std::vector::front()}} violates its precondition {{! std::vector::empty()}} and thus causes UB. I fixed this here: https://github.com/mavam/time-machine It's a one-line fix and ready to merge. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Tue Oct 29 13:38:03 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 29 Oct 2013 15:38:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination In-Reply-To: References: Message-ID: Jon Siwek created BIT-1093: ------------------------------ Summary: topic/jsiwek/thread-termination Key: BIT-1093 URL: https://bro-tracker.atlassian.net/browse/BIT-1093 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: git/master Reporter: Jon Siwek Assignee: Robin Sommer Fix For: 2.2 The change in this branch should fix the case where the last remaining done/killed thread never got processed (main thread never received pending messages from it or joined/deleted it) until Bro terminates. Which was problematic if the termination condition depended on processing messages from the last remaining thread. The new code's logic is contrary to what it used to be, but I can't figure out what the old was trying to accomplish and think it could only have caused problems. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Tue Oct 29 13:38:03 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 29 Oct 2013 15:38:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1093: --------------------------- Status: Merge Request (was: Open) > topic/jsiwek/thread-termination > ------------------------------- > > Key: BIT-1093 > URL: https://bro-tracker.atlassian.net/browse/BIT-1093 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Fix For: 2.2 > > > The change in this branch should fix the case where the last remaining done/killed thread never got processed (main thread never received pending messages from it or joined/deleted it) until Bro terminates. Which was problematic if the termination condition depended on processing messages from the last remaining thread. > The new code's logic is contrary to what it used to be, but I can't figure out what the old was trying to accomplish and think it could only have caused problems. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From noreply at bro.org Wed Oct 30 00:00:12 2013 From: noreply at bro.org (Merge Tracker) Date: Wed, 30 Oct 2013 00:00:12 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310300700.r9U70CMR026263@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------- ------------ ---------- ------------- ---------- ----------------------------------- BIT-1093 [1] Bro Jon Siwek Robin Sommer 2013-10-29 2.2 Normal topic/jsiwek/thread-termination [2] Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------------- ---------- ------------------------------------------------------------ 7c7967c [3] bro Jon Siwek 2013-10-29 Don't build broccoli ruby bindings by default, use --enable- b2d6ccf [4] bro Jon Siwek 2013-10-29 Revert "Fix race condition in unit test." b255aed [5] bro Jon Siwek 2013-10-28 Fix race condition in unit test. 31c7c1a [6] bro Vlad Grigorescu 2013-10-28 Change percent_lost in capture-loss from a string to a doubl bffe5a6 [7] broccoli Jon Siwek 2013-10-29 Don't build ruby bindings by default, use --enable-ruby to d [1] BIT-1093 https://bro-tracker.atlassian.net/browse/BIT-1093 [2] thread-termination https://github.com/bro/bro/tree/topic/jsiwek/thread-termination [3] 7c7967c https://github.com/bro/bro/commit/7c7967c1ab6379369575c60825437f701dece5e2 [4] b2d6ccf https://github.com/bro/bro/commit/b2d6ccfb195c0a7f9f92ab2b3a1d693483fa08de [5] b255aed https://github.com/bro/bro/commit/b255aedc26ec09d0eca7c83b94d2b4c7996676e8 [6] 31c7c1a https://github.com/bro/bro/commit/31c7c1a6737ddf8bc9b6537459f617ea57c0b799 [7] bffe5a6 https://github.com/bro/broccoli/commit/bffe5a6d06d3da29e4c17f8d5b1e919848b0c848 From jira at bro-tracker.atlassian.net Wed Oct 30 05:06:03 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 30 Oct 2013 07:06:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14500#comment-14500 ] Robin Sommer commented on BIT-1093: ----------------------------------- I looked up when the original "{{&& ! Killed()}}" code got introduced, that was in 743fc1680dc9d4c04f38ca80c7ef4e5b88e8f4cb and the commit message points to BIT-858. Can you take a look and double-check that the problem described there is still addressed with the new version to be sure we don't introduce a regression? (Not immediately sure if we have a test that covers that). > topic/jsiwek/thread-termination > ------------------------------- > > Key: BIT-1093 > URL: https://bro-tracker.atlassian.net/browse/BIT-1093 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Fix For: 2.2 > > > The change in this branch should fix the case where the last remaining done/killed thread never got processed (main thread never received pending messages from it or joined/deleted it) until Bro terminates. Which was problematic if the termination condition depended on processing messages from the last remaining thread. > The new code's logic is contrary to what it used to be, but I can't figure out what the old was trying to accomplish and think it could only have caused problems. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Wed Oct 30 06:32:03 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 30 Oct 2013 08:32:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1093: ------------------------------ Status: Reopened (was: Closed) > topic/jsiwek/thread-termination > ------------------------------- > > Key: BIT-1093 > URL: https://bro-tracker.atlassian.net/browse/BIT-1093 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Fix For: 2.2 > > > The change in this branch should fix the case where the last remaining done/killed thread never got processed (main thread never received pending messages from it or joined/deleted it) until Bro terminates. Which was problematic if the termination condition depended on processing messages from the last remaining thread. > The new code's logic is contrary to what it used to be, but I can't figure out what the old was trying to accomplish and think it could only have caused problems. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Wed Oct 30 06:32:03 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 30 Oct 2013 08:32:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1093: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > topic/jsiwek/thread-termination > ------------------------------- > > Key: BIT-1093 > URL: https://bro-tracker.atlassian.net/browse/BIT-1093 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Fix For: 2.2 > > > The change in this branch should fix the case where the last remaining done/killed thread never got processed (main thread never received pending messages from it or joined/deleted it) until Bro terminates. Which was problematic if the termination condition depended on processing messages from the last remaining thread. > The new code's logic is contrary to what it used to be, but I can't figure out what the old was trying to accomplish and think it could only have caused problems. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Wed Oct 30 06:32:03 2013 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 30 Oct 2013 08:32:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14501#comment-14501 ] Robin Sommer commented on BIT-1093: ----------------------------------- I've merged it but reopening for the double-check. > topic/jsiwek/thread-termination > ------------------------------- > > Key: BIT-1093 > URL: https://bro-tracker.atlassian.net/browse/BIT-1093 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Fix For: 2.2 > > > The change in this branch should fix the case where the last remaining done/killed thread never got processed (main thread never received pending messages from it or joined/deleted it) until Bro terminates. Which was problematic if the termination condition depended on processing messages from the last remaining thread. > The new code's logic is contrary to what it used to be, but I can't figure out what the old was trying to accomplish and think it could only have caused problems. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Wed Oct 30 07:49:03 2013 From: jira at bro-tracker.atlassian.net (tyler.schoenke (JIRA)) Date: Wed, 30 Oct 2013 09:49:03 -0500 (CDT) 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=14502#comment-14502 ] tyler.schoenke commented on BIT-1090: ------------------------------------- I set up the file without the redef, and formatted it as you specified. $ cat sigsup-ssh-pass3.bro SSH::ignore_guessers[172.0.0.0/16] = set( 10.0.0.1/32 ); SSH::ignore_guessers[192.168.1.0/16] = set( 192.168.2.0/32 ); That got rid of the fatal error, but it looks like the array is empty. Maybe the -I option is showing the value of the array before it gets populated by the bro script? $ bro my-detect-bruteforcing.bro sigsup-ssh-pass3.bro -I SSH::ignore_guessers; SSH::ignore_guessers : table[subnet] of set[subnet] = { } &redef Tyler > 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 Wed Oct 30 08:58:03 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 30 Oct 2013 10:58:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14503#comment-14503 ] Jon Siwek commented on BIT-1093: -------------------------------- {{testing/btst/scripts/base/frameworks/input/missing-file.bro}} seems to at least be checking part of the problem mentioned in BIT-858. And I don't think that this conflicts with what was addressed there. Here's an abbreviated history of "thread termination": 743fc1680dc9d4c04f38ca80c7ef4e5b88e8f4cb - threading::Manager::Process() and threading::Manager::NextTimestamp() both check for "{{&& ! t->Killed()}}" - The assumption is that you're not allowed to read from a "dead" thread's queue and threads are only cleaned up in threading::Manager::Terminate() 38e1dc9ca47d97508276a2f7192c5353bb8e6837 - threading::Manager::Process() can now also clean up dead threads b947394990720032ac7f374f7c9d1902ed4485b9 - Reading from a dead thread's queue is now supported - "{{&& ! t->Killed()}}" check is removed from threading::Manager::Process() to allow flushing out a dead thread's queue before cleaning it up, but the check still remains in threading::Manager::NextTimestamp() To me, looks like the NextTimestamp code just didn't evolve w/ the rest. > topic/jsiwek/thread-termination > ------------------------------- > > Key: BIT-1093 > URL: https://bro-tracker.atlassian.net/browse/BIT-1093 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Fix For: 2.2 > > > The change in this branch should fix the case where the last remaining done/killed thread never got processed (main thread never received pending messages from it or joined/deleted it) until Bro terminates. Which was problematic if the termination condition depended on processing messages from the last remaining thread. > The new code's logic is contrary to what it used to be, but I can't figure out what the old was trying to accomplish and think it could only have caused problems. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From jira at bro-tracker.atlassian.net Wed Oct 30 09:02:03 2013 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 30 Oct 2013 11:02:03 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1093: --------------------------- Status: Closed (was: Reopened) > topic/jsiwek/thread-termination > ------------------------------- > > Key: BIT-1093 > URL: https://bro-tracker.atlassian.net/browse/BIT-1093 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Assignee: Robin Sommer > Fix For: 2.2 > > > The change in this branch should fix the case where the last remaining done/killed thread never got processed (main thread never received pending messages from it or joined/deleted it) until Bro terminates. Which was problematic if the termination condition depended on processing messages from the last remaining thread. > The new code's logic is contrary to what it used to be, but I can't figure out what the old was trying to accomplish and think it could only have caused problems. -- This message was sent by Atlassian JIRA (v6.2-OD-01#6204) From noreply at bro.org Thu Oct 31 00:00:14 2013 From: noreply at bro.org (Merge Tracker) Date: Thu, 31 Oct 2013 00:00:14 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201310310700.r9V70ET8031197@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ------------------------------------------------------------ bffe5a6 [1] broccoli Jon Siwek 2013-10-29 Don't build ruby bindings by default, use --enable-ruby to d e321733 [2] broctl Daniel Thayer 2013-10-30 Do not check if the local host is "alive" [1] bffe5a6 https://github.com/bro/broccoli/commit/bffe5a6d06d3da29e4c17f8d5b1e919848b0c848 [2] e321733 https://github.com/bro/broctl/commit/e321733868c6d31fdb586a2c41bbdcdbecbd8a9f From jira at bro-tracker.atlassian.net Thu Oct 31 06:09:03 2013 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 31 Oct 2013 08:09:03 -0500 (CDT) 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=14504#comment-14504 ] Seth Hall commented on BIT-1090: -------------------------------- That syntax is wrong, use... redef SSH::ignore_guessers += { [172.0.0.0/16] = 10.0.0.1/32, [192.168.1.0/16] = 192.168.2.0/32 }; Also, the yield value for that table is just a subnet. Not a set of subnets. > 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 Thu Oct 31 08:06:03 2013 From: jira at bro-tracker.atlassian.net (tyler.schoenke (JIRA)) Date: Thu, 31 Oct 2013 10:06:03 -0500 (CDT) 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=14505#comment-14505 ] tyler.schoenke commented on BIT-1090: ------------------------------------- Hi Seth, I think you missed the part below where I said I modified the data structure to be a set of subnets. Devices connecting to gihub has been firing the alert. Since github has multiple IP ranges, I needed a set of subnets in order to effectively whitelist. Once this is working, I think this change would be a good enhancement request for the existing detect-bruteforcing script. Tyler > 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)