zeek-dev October 2013

zeek-dev@lists.zeek.org

87 discussions

[Bro-Dev] [JIRA] (BIT-1090) fatal error Val::CONVERTER

by tyler.schoenke (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1090?page=com.atlassian.jira.p… ] 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)

8 years, 2 months

[Bro-Dev] [JIRA] (BIT-1090) fatal error Val::CONVERTER

by Seth Hall (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1090?page=com.atlassian.jira.p… ] 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)

8 years, 2 months

[Bro-Dev] [Auto] Merge Status

by Merge Tracker

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/bffe5a6d06d3da29e4c17f8d5b1e919848b0… [2] e321733 https://github.com/bro/broctl/commit/e321733868c6d31fdb586a2c41bbdcdbecbd8a…

8 years, 2 months

[Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination

by Jon Siwek (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.p… ] 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)

8 years, 2 months

[Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination

by Jon Siwek (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.p… ] 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)

8 years, 2 months

[Bro-Dev] [JIRA] (BIT-1090) fatal error Val::CONVERTER

by tyler.schoenke (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1090?page=com.atlassian.jira.p… ] 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)

8 years, 2 months

[Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination

by Robin Sommer (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.p… ] 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)

8 years, 2 months

[Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination

by Robin Sommer (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.p… ] 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)

8 years, 2 months

[Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination

by Robin Sommer (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.p… ] 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)

8 years, 2 months

[Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination

by Robin Sommer (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.p… ] 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)

8 years, 2 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

zeek-dev October 2013