zeek-dev March 2016

zeek-dev@lists.zeek.org

198 discussions

[Bro-Dev] [JIRA] (BIT-1535) conn.log conn_state field or documentation is wrong

by Johanna Amann (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1535?page=com.atlassian.jira.p… ] Johanna Amann commented on BIT-1535: ------------------------------------ topic/johanna/bit-1535 updates the documentation of RSTR to "Responder sent a RST" > conn.log conn_state field or documentation is wrong > --------------------------------------------------- > > Key: BIT-1535 > URL: https://bro-tracker.atlassian.net/browse/BIT-1535 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Justin Azoff > Assignee: Vern Paxson > > There is an issue where the conn.log conn_state field will contain RSTR, which according to the documentation means "Established, responder aborted." > The problem that I notice is that I see log entries where conn_state is RSTR, but conn_history does not contain an 'h'. Additionally, the resp_h is absolutely not running a service on resp_p and the orig_h is usually in the process of a tcp scan. > Here are the top frequencies of RSTR without an h over about a weeks worth of conn logs: > {code} > 38193 RSTR Fr > 3662 RSTR DFr > 1801 RSTR DFdrR > 1248 RSTR DRr > 432 RSTR DrF > 232 RSTR Far > 128 RSTR DdAFrR > 79 RSTR DFadrR > 64 RSTR DrR > 58 RSTR DdAFarR > {code} > Compared to histories that did contain an h: > {code} > 425398 RSTR ShADadFr > 204149 RSTR ShADadFrR > 156303 RSTR ShADdFar > 141795 RSTR ShADadFRRr > 105704 RSTR ShADadfr > 79697 RSTR ShADadr > 63493 RSTR ShADaFr > 51704 RSTR ShADadFrrrr > 42075 RSTR ShADdar > 37678 RSTR ShADadfRr > {code} > I don't have a pcap for this, but I believe many of the weird connections are related to scans or backscatter. > I'm not sure if the code is wrong or the documentation is wrong, but I don't see how a fin+reset connection could be classified as established. > Also, One thing that would be a nice documentation addition is the answer to this question: > Given a conn.log entry, how do determine if there was a connection established? I thought it would be if the state was in 'SF S1 S2 S3 RSTO RSTR', but RSTR is problematic... -- This message was sent by Atlassian JIRA (v7.2.0-OD-03-010#72000)

5 years, 4 months

[Bro-Dev] [JIRA] (BIT-1535) conn.log conn_state field or documentation is wrong

by Johanna Amann (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1535?page=com.atlassian.jira.p… ] Johanna Amann updated BIT-1535: ------------------------------- Status: Merge Request (was: Open) Assignee: (was: Vern Paxson) > conn.log conn_state field or documentation is wrong > --------------------------------------------------- > > Key: BIT-1535 > URL: https://bro-tracker.atlassian.net/browse/BIT-1535 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Reporter: Justin Azoff > > There is an issue where the conn.log conn_state field will contain RSTR, which according to the documentation means "Established, responder aborted." > The problem that I notice is that I see log entries where conn_state is RSTR, but conn_history does not contain an 'h'. Additionally, the resp_h is absolutely not running a service on resp_p and the orig_h is usually in the process of a tcp scan. > Here are the top frequencies of RSTR without an h over about a weeks worth of conn logs: > {code} > 38193 RSTR Fr > 3662 RSTR DFr > 1801 RSTR DFdrR > 1248 RSTR DRr > 432 RSTR DrF > 232 RSTR Far > 128 RSTR DdAFrR > 79 RSTR DFadrR > 64 RSTR DrR > 58 RSTR DdAFarR > {code} > Compared to histories that did contain an h: > {code} > 425398 RSTR ShADadFr > 204149 RSTR ShADadFrR > 156303 RSTR ShADdFar > 141795 RSTR ShADadFRRr > 105704 RSTR ShADadfr > 79697 RSTR ShADadr > 63493 RSTR ShADaFr > 51704 RSTR ShADadFrrrr > 42075 RSTR ShADdar > 37678 RSTR ShADadfRr > {code} > I don't have a pcap for this, but I believe many of the weird connections are related to scans or backscatter. > I'm not sure if the code is wrong or the documentation is wrong, but I don't see how a fin+reset connection could be classified as established. > Also, One thing that would be a nice documentation addition is the answer to this question: > Given a conn.log entry, how do determine if there was a connection established? I thought it would be if the state was in 'SF S1 S2 S3 RSTO RSTR', but RSTR is problematic... -- This message was sent by Atlassian JIRA (v7.2.0-OD-03-010#72000)

5 years, 4 months

[Bro-Dev] [JIRA] (BIT-1539) Adding intel to intel framework Bro is not loading the file

by Johanna Amann (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1539?page=com.atlassian.jira.p… ] Johanna Amann updated BIT-1539: ------------------------------- Resolution: Solved Status: Closed (was: Open) Since there was no further comment on this, I assumed that solved your problem. Feel free to re-open if you still think there is anything wrong in Bro. > Adding intel to intel framework Bro is not loading the file > ----------------------------------------------------------- > > Key: BIT-1539 > URL: https://bro-tracker.atlassian.net/browse/BIT-1539 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.4 > Environment: CentOS 7.2. 1511 kernel version 3.10 > Reporter: Lu Goon > Labels: Framework, IP, Intel, addresses, data, files, text > > We wanted to get our intel ( bad IPs) in to bro for alerting using the intel framework. I crafted a file of BAD IPs based on the documentation on the site. Also based this on the critical stack implementation as well. > I provided the following fields: indicator, indicator_type, meta.source, meta.desc, meta.do_notice. > thus a sample entry would be > 1.2.3.4 \t Intel::ADDR \t MY INTEL \t My bad IP list \t F > Per the documentation it should write all that into the intel.log file if activated in the local.bro file > either using broctl or bro -i ens33 local.bro. There is no indication in loaded scripts that the files loads. > Also in my local.bro file I include. > @load policy/frameworks/intel/seen > @load policy/frameworks/intel/do_notice > redef Intel::read_files += { "/usr/local/bro/upload/intel.dat"}; > Any help on debugging why this file is not loading or indication of if it is loaded? -- This message was sent by Atlassian JIRA (v7.2.0-OD-03-010#72000)

5 years, 4 months

[Bro-Dev] [JIRA] (BIT-1529) Base SIP scripts missing SUBSCRIBE and NOTIFY

by Johanna Amann (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1529?page=com.atlassian.jira.p… ] Johanna Amann updated BIT-1529: ------------------------------- Status: Merge Request (was: Open) > Base SIP scripts missing SUBSCRIBE and NOTIFY > --------------------------------------------- > > Key: BIT-1529 > URL: https://bro-tracker.atlassian.net/browse/BIT-1529 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Fix For: 2.5 > > > The base/protocols/sip/main.bro script has a set in `sip_methods` which needs to have SUBSCRIBE and NOTIFY added. They're defined in RFC 3265. -- This message was sent by Atlassian JIRA (v7.2.0-OD-03-010#72000)

5 years, 4 months

[Bro-Dev] [JIRA] (BIT-1529) Base SIP scripts missing SUBSCRIBE and NOTIFY

by Johanna Amann (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1529?page=com.atlassian.jira.p… ] Johanna Amann commented on BIT-1529: ------------------------------------ I added subscribe in topic/johanna/bit-1529. Notify was already added in 4a56a17817fc4eed2a3a6c10ecb5140df4f2dfc5 No tests since I don't have traffic (but since this is only used to generate weirds, it should be ok). > Base SIP scripts missing SUBSCRIBE and NOTIFY > --------------------------------------------- > > Key: BIT-1529 > URL: https://bro-tracker.atlassian.net/browse/BIT-1529 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Seth Hall > Fix For: 2.5 > > > The base/protocols/sip/main.bro script has a set in `sip_methods` which needs to have SUBSCRIBE and NOTIFY added. They're defined in RFC 3265. -- This message was sent by Atlassian JIRA (v7.2.0-OD-03-010#72000)

5 years, 4 months

[Bro-Dev] [JIRA] (BIT-1540) Ifconfig is hardcoded in BroControl

by Jon Schipp (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1540?page=com.atlassian.jira.p… ] Jon Schipp reassigned BIT-1540: ------------------------------- Assignee: Jon Schipp > Ifconfig is hardcoded in BroControl > ----------------------------------- > > Key: BIT-1540 > URL: https://bro-tracker.atlassian.net/browse/BIT-1540 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Affects Versions: git/master > Reporter: Johanna Amann > Assignee: Jon Schipp > Fix For: 2.5 > > > From the mailing list: > {quote} > Hi Folks, > On later versions of Linux distros iproute2 replaces ifconfig with ip > Starting at line 601 at > https://github.com/bro/broctl/blob/master/BroControl/config.py > It looks like ifconfig is hard-written into the logic. Probably needs a > patch to check for the ip command. > Cheers, > Harry > {quote} > We should probably check for the presence of the ip utility and use that, if present. -- This message was sent by Atlassian JIRA (v7.2.0-OD-03-010#72000)

5 years, 4 months

[Bro-Dev] [JIRA] (BIT-1541) Crash in SocketComm::Run - RemoteSerializer.cc:3493

by Aaron Eppert (JIRA)

Aaron Eppert created BIT-1541: --------------------------------- Summary: Crash in SocketComm::Run - RemoteSerializer.cc:3493 Key: BIT-1541 URL: https://bro-tracker.atlassian.net/browse/BIT-1541 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.4 Reporter: Aaron Eppert This has been happening on a few sensors, both standalone and not. On each sensor, there is broctl cron running as well as periodic polling being the Python interface to the netstats data. {quote}#0 0x0000000000607d47 in SocketComm::Run (this=0x1) at /mnt/hgfs/src/psdev/bro/src/RemoteSerializer.cc:3493 #1 0x0000000000608021 in RemoteSerializer::Fork (this=0x2590000) at /mnt/hgfs/src/psdev/bro/src/RemoteSerializer.cc:687 #2 0x000000000060813f in RemoteSerializer::Enable (this=0x2590000) at /mnt/hgfs/src/psdev/bro/src/RemoteSerializer.cc:575 #3 0x00000000005d52b3 in BifFunc::bro_enable_communication (frame=<optimized out>, BiF_ARGS=<optimized out>) at bro.bif:4480 #4 0x00000000005d2cdd in BuiltinFunc::Call (this=0x2ae1180, args=0x16255be0, parent=0x4ada990) at /mnt/hgfs/src/psdev/bro/src/Func.cc:586 #5 0x00000000005b7af6 in CallExpr::Eval (this=0x315e900, f=0x4ada990) at /mnt/hgfs/src/psdev/bro/src/Expr.cc:4544 #6 0x000000000062b8d4 in ExprStmt::Exec (this=0x315e8b0, f=0x4ada990, flow=@0x7ffe64462c50: FLOW_NEXT) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:352 #7 0x0000000000629b94 in IfStmt::DoExec (this=0x31533c0, f=0x4ada990, v=<optimized out>, flow=@0x7ffe64462c50: FLOW_NEXT) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:456 #8 0x000000000062b8f1 in ExprStmt::Exec (this=0x31533c0, f=0x4ada990, flow=@0x7ffe64462c50: FLOW_NEXT) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:356 #9 0x0000000000629c31 in StmtList::Exec (this=0x31534e0, f=0x4ada990, flow=@0x7ffe64462c50: FLOW_NEXT) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:1696 #10 0x0000000000629c31 in StmtList::Exec (this=0x3153120, f=0x4ada990, flow=@0x7ffe64462c50: FLOW_NEXT) at /mnt/hgfs/src/psdev/bro/src/Stmt.cc:1696 #11 0x00000000005decfe in BroFunc::Call (this=0x2743b80, args=<optimized out>, parent=0x0) at /mnt/hgfs/src/psdev/bro/src/Func.cc:403 #12 0x000000000059d95a in EventHandler::Call (this=0x2476c80, vl=0x15db0b60, no_remote=no_remote@entry=false) at /mnt/hgfs/src/psdev/bro/src/EventHandler.cc:130 #13 0x000000000059cb65 in Dispatch (no_remote=false, this=0x16193120) at /mnt/hgfs/src/psdev/bro/src/Event.h:50 #14 EventMgr::Dispatch (this=this@entry=0xc07840 <mgr>) at /mnt/hgfs/src/psdev/bro/src/Event.cc:111 #15 0x000000000059cd00 in EventMgr::Drain (this=0xc07840 <mgr>) at /mnt/hgfs/src/psdev/bro/src/Event.cc:128 #16 0x000000000054c659 in main (argc=<optimized out>, argv=<optimized out>) at /mnt/hgfs/src/psdev/bro/src/main.cc:1147 {quote} -- This message was sent by Atlassian JIRA (v7.2.0-OD-03-010#72000)

5 years, 4 months

[Bro-Dev] [Auto] Merge Status

by Merge Tracker

Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- -------------- ---------- ---------- ------------- ---------- ------------------------------------------------------- BIT-1537 [1] Bro Carlos Terrón - 2016-02-29 2.5 Normal bro segfaults after compile in MacOS X 10.11 El Capitan BIT-1507 [2] Bro Jan Grashoefer Seth Hall 2016-01-25 - Low Intel framework does not match mail addresses properly Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ------------ ---------- ------------------------------------- #55 [3] bro wglodek [4] 2016-02-07 http-evasion [5] #52 [6] bro J-Gras [7] 2016-01-18 Fixed matching mail address intel [8] #18 [9] bro-plugins jshlbrd [10] 2016-02-12 SSDP analyzer [11] [1] BIT-1537 https://bro-tracker.atlassian.net/browse/BIT-1537 [2] BIT-1507 https://bro-tracker.atlassian.net/browse/BIT-1507 [3] Pull Request #55 https://github.com/bro/bro/pull/55 [4] wglodek https://github.com/wglodek [5] Merge Pull Request #55 with git pull --no-ff --no-commit https://github.com/0xcc-labs/bro.git topic/http-evasion [6] Pull Request #52 https://github.com/bro/bro/pull/52 [7] J-Gras https://github.com/J-Gras [8] Merge Pull Request #52 with git pull --no-ff --no-commit https://github.com/J-Gras/bro.git topic/jgras/bit-1507 [9] Pull Request #18 https://github.com/bro/bro-plugins/pull/18 [10] jshlbrd https://github.com/jshlbrd [11] Merge Pull Request #18 with git pull --no-ff --no-commit https://github.com/jshlbrd/bro-plugins-1.git topic/jshlbrd/ssdp

5 years, 4 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

zeek-dev March 2016