zeek May 2015

zeek@lists.zeek.org

40 participants
51 discussions

by Troy Jordan

Hello, There are some hilti-based parsers in the Bro docker image. When I run the pcaps for BACnet (/opt/hilti/bro/tests/Traces/bacnet/*.pcap) through Bro (eg bro -r NPDU.pcap) , no event logs are produced in /usr/local/bro/logs). How do I integrate these parsers into Bro? - Troy -- Troy Jordan t r o y j @ m a i n e . e d u GIAC GCIH,GCIA ------------------------------------------------------------ Network Systems Security Analyst Information Technology Security Office University of Maine System ------------------------------------------------------------ 233 Science Building | voice: 207.561.3590 Portland, ME 04103 | fax: 509.351.3650 "As you all know, Security Is Mortals chiefest Enemy" William Shakespeare, Macbeth

5 years, 2 months

[Bro] restrict_filters not preventing logging of selected IP addresses

by Richard Johnson

I think I'm specifying restrict_filters correctly to stop some hosts from being logged, but it's not working as I intend/expect. My local.bro redefinition of restrict_filters (below) is being recognized and propagated by broctl install, as confirmed by print restrict_filters after restarting. As further confirmation that the redef is being noticed, if I specify a pcap syntax impossibility in restrict_filters, I get workers quitting with "fatal error in /raid/bro/share/bro/base/frameworks/packet-filter/./main.bro, line 282: Bad pcap filter ..." on a restart. Yet when the restrict_filter is OK and is seemingly recognized, the IP addresses in the restrict_filters still appear in log entries. This logging continues after a broctl install and update, after a broctl install and restart, as well as after a complete cluster reboot. I'm seeing this under Bro 2.3-7 on CentOS 6.5 with pfring. Whether the capture_filters are redef'ed as shown in the details below, or not, doesn't change the restrict_filters failure I'm seeing. Any ideas for where to take this debugging odyssey? What am I missing that's obvious? Richard ------- Details: [manager-host ~]$ grep capture_filters /raid/bro/share/bro/site/local.bro redef capture_filters = { ["all"] = "ip or not ip" }; [manager-host ~]$ grep restrict_filters /raid/bro/share/bro/site/local.bro redef restrict_filters += { ["not-these-hosts"] = "not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88" }; [lines condensed for this message by removing extra pretty printing <cr>s] [BroControl] > print capture_filters manager capture_filters = { [all] = ip or not ip } proxy-1 capture_filters = { [all] = ip or not ip } proxy-2 capture_filters = { [all] = ip or not ip } worker-1-1 capture_filters = { [all] = ip or not ip } worker-1-2 capture_filters = { [all] = ip or not ip } worker-1-3 capture_filters = { [all] = ip or not ip } worker-1-4 capture_filters = { [all] = ip or not ip } worker-2-1 capture_filters = { [all] = ip or not ip } worker-2-2 capture_filters = { [all] = ip or not ip } worker-2-3 capture_filters = { [all] = ip or not ip } worker-2-4 capture_filters = { [all] = ip or not ip } [lines condensed for this message by removing extra pretty printing <cr>s] [BroControl] > print restrict_filters manager restrict_filters = { [not-these-hosts] = not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88 } proxy-1 restrict_filters = { [not-these-hosts] = not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88 } proxy-2 restrict_filters = { [not-these-hosts] = not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88 } worker-1-1 restrict_filters = { [not-these-hosts] = not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88 } worker-1-2 restrict_filters = { [not-these-hosts] = not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88 } worker-1-3 restrict_filters = { [not-these-hosts] = not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88 } worker-1-4 restrict_filters = { [not-these-hosts] = not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88 } worker-2-1 restrict_filters = { [not-these-hosts] = not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88 } worker-2-2 restrict_filters = { [not-these-hosts] = not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88 } worker-2-3 restrict_filters = { [not-these-hosts] = not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88 } worker-2-4 restrict_filters = { [not-these-hosts] = not host 172.16.1.1 and not host 172.16.22.22 and not host 172.16.39.39 and not host 172.16.88.88 } [manager-host current]$ grep 172.16.88.88 conn.log | tail -3 1429461245.805348 CpuepS3Ds2GYzABCtb xx.xx.xx.xx xxxxx 172.16.88.88 443 tcp ssl 4192.655995 14660 16441 S1 F 0ShADda 50 17268 49 19001 (empty) 1429464730.699197 CqVMY53iVvTFSWclAi xx.xx.xx.xx xxxxx 172.16.88.88 443 tcp ssl 1002.988461 5491 4481 SF F 0ShADdaFf 21 6591 17 5377 (empty) 1429464286.982078 CUl3Cl24bUWkgbhAGd xx.xx.xx.xx xxxxx 172.16.88.88 443 tcp ssl 1447.315821 7095 5595 SF F 0ShADdafF 25 8403 21 6699 (empty)

5 years, 4 months

[Bro] delayed bro operation

by Frank Meier

Hi. A policy forces me to run bro in a separate network. So the captured PCAPs are transfered to the bro network for logging purposes. How would I handle delays in feeding bro with the PCAPS? Would connections spanning multiple PCAPs be a problem? My first idea is to crank up all the timeouts like this: redef tcp_inactivity_timeout = 5 days; redef udp_inactivity_timeout = 5 days; redef icmp_inactivity_timeout = 5 days; redef default_file_timeout_interval = 5 days; What performance penalty will I suffer? I guess the RAM usage will grow, because connections, which were not cleanly terminated, would hang around for a long time. Are there any examples for this kind of setup? How would you search for this? Have a nice weekend! Franky

5 years, 6 months

[Bro] binpac++ plugin error

by Troy Jordan

I am working through section 3 of the binpac++ documentation to understand binpac++ analyzers are integrated into Bro. (I'm running the HILTI/Binpac++ docker image, under Centos7.) I am getting an error when confirming the binpac++ plugin is present: root@df5e8fd99740:~# export BRO_PLUGIN_PATH=/opt/hilti/build/bro root@df5e8fd99740:~# bro -NN ssh.evt fatal error in /usr/local/bro/share/bro/base/init-bare.bro, line 1: cannot load plugin library /opt/hilti/build/bro//lib/Bro-Hilti.linux-x86_64.so: /opt/hilti/build/bro//lib/Bro-Hilti.linux-x86_64.so: undefined symbol: _ZN6plugin6Plugin11MetaHookPreENS_8HookTypeERKNSt3__14listINS_12HookArgumentENS2_9allocatorIS4_EEEE Perhaps I have set the BRO_PLUGIN_PATH incorrectly? - Troy -- Troy Jordan t r o y j @ m a i n e . e d u GIAC GCIH,GCIA ------------------------------------------------------------ Network Systems Security Analyst Information Technology Security Office University of Maine System ------------------------------------------------------------ 233 Science Building | voice: 207.561.3590 Portland, ME 04103 | fax: 509.351.3650 "As you all know, Security Is Mortals chiefest Enemy" William Shakespeare, Macbeth

5 years, 7 months

[Bro] tx_hosts and rx_hosts in files.log

by Ali Hadi

Hi, If you use the PCAP below and analyze it using Bro: https://www.bro.org/static/traces/email.pcap Then when checking the files.log, the tx_hosts is supposed to show the host who transmitted the file, and rx_hosts is for the host who received the file based on Bro's documentation: https://www.bro.org/sphinx-git/scripts/base/frameworks/files/main.bro.html If you do the following: cat files.log | bro-cut fuid tx_hosts rx_hosts | grep <ID OF THE LEAKED PDF FILE> You'll get that the TX Host IP (SrcIP) is 192.168.121.176 and not 192.168.121.179 !!! Is there something I'm doing wrong, or has bro switched their positions in the output? Thanks in advance, *Ali*

5 years, 7 months

[Bro] Quick PF_RING question

by James Lay

Hey all, So I'm reading up and wanting to try out PF_RING for bro. Is there a way you use this using command line bro? The documentation only talks about clustering using PF_RING, and that's not what I want to do. End goal is to reduce packet loss. Thank you. James

5 years, 8 months

Re: [Bro] initial buffer length

by Hui Lin (Hugo)

HI Abdelkarim, Probably you should try to use the basic data type such as using int for "type" and "chunk" instead of using the bytestring (even with the length defined). I remember that the bytestring did not work for my case either. I don't remember the reason in details now, but I remember that it is related to how Binpac compiler is implemented. Best, Hui Lin On Thu, May 28, 2015 at 3:44 AM, Abdelkarim benkhadra < a.benkhadra(a)hotmail.com> wrote: > hi hui, > thanks for your answer. > > i tryed the DNP3 way still does not work, > > type myproto_Header = record { > type: bytestring &length=3; > chunk: bytestring &length=1, > msgSize: uint16; > }; > > type myproto_req = record { > hdr: myproto_Header; > data: case (hdr.type) of { > //some records; > }; > }&length = hdr.msgSize; > > the length of records in the "case" is specified for each one. > still get the same error. > > ------------------------------ > From: hlin33(a)illinois.edu > Date: Wed, 27 May 2015 10:02:53 -0500 > Subject: Re: [Bro] initial buffer length > To: a.benkhadra(a)hotmail.com > CC: bro(a)bro.org > > > Hi Abdelkarim, > > In the myproto_Header, do you have some definitions of records before > msgSize (whose length is not explicitly specified)? If that is the case, > BinPac cannot decide the initial length in order to locate msgSize. > > You may refer the DNP3 analyzer that I wrote in a similar way. > > > type Header_Block = record { > start: uint16 &check(start == 0x0564); > len: uint8; > ctrl: uint8; > dest_addr: uint16; > src_addr: uint16; > } &byteorder = littleendian; > > type DNP3_Request = record { > addin_header: Header_Block; ## added by Hui Lin in Bro code > .... > } &byteorder = bigendian > &length= 9 + addin_header.len - 5 - 1; > > > Hope this helps. > > Best, > > Hui Lin > > > > On Wed, May 27, 2015 at 6:52 AM, Abdelkarim benkhadra < > a.benkhadra(a)hotmail.com> wrote: > > Hi, > > in myproto-protocol.pac, i have: > > type myproto_PDU(is_orig: bool) = record { > header: myproto_Header; > //restofdefinition; > } &length=header.msgSize; > > type myproto_Header = record { > //some fields; > msgSize: uint16; > //restoffields; > }; > msgSize represents the length of the PDU. > and when "make"ing bro i get "cannot determine initial buffer length for > type myproto_PDU". > i tryed some random values like &length=60 and it works fine. > i took the modbus analyzer as an exemple to write myproto analyzer but > without success. > any ideas? > > > > > -- > Hui Lin > PhD Candidate, Research Assistant > Electrical and Computer Engineering Department > University of Illinois at Urbana-Champaign > -- Hui Lin PhD Candidate, Research Assistant Electrical and Computer Engineering Department University of Illinois at Urbana-Champaign

5 years, 8 months

[Bro] How to modify http.log

by Vito Logrillo

Hi all, i'm trying to modify http.log using the script written below -----script.bro----- redef record HTTP::Info += { host_ip: set[addr] &optional &log; }; event connection_state_remove(c: connection) &priority=5 { local record_flag: bool = F; if (/^[hH][tT][tT][pP]:/ in c$http$uri) { record_flag = T; when (local h = lookup_hostname(c$http$host)) { record_flag = F; print(h); if (|h|>0 && (0.0.0.0 !in h)) { c$http$host_ip = h; Log::write(HTTP::LOG, c$http); } return; } } if (record_flag == T) { return; } } -----end script.bro---- I've added a new field in http.log (host_ip) in order to see the host ip using the function lookup_hostname. The script works well, but the same record is written twice (with and without the host_ip field). I've tried to use a state flag (record_flag) to avoid this, but the result is the same. How can avoid record duplicantion? Thanks, Vito

5 years, 8 months

Re: [Bro] initial buffer length

by Hui Lin (Hugo)

Hi Abdelkarim, In the myproto_Header, do you have some definitions of records before msgSize (whose length is not explicitly specified)? If that is the case, BinPac cannot decide the initial length in order to locate msgSize. You may refer the DNP3 analyzer that I wrote in a similar way. type Header_Block = record { start: uint16 &check(start == 0x0564); len: uint8; ctrl: uint8; dest_addr: uint16; src_addr: uint16; } &byteorder = littleendian; type DNP3_Request = record { addin_header: Header_Block; ## added by Hui Lin in Bro code .... } &byteorder = bigendian &length= 9 + addin_header.len - 5 - 1; Hope this helps. Best, Hui Lin On Wed, May 27, 2015 at 6:52 AM, Abdelkarim benkhadra < a.benkhadra(a)hotmail.com> wrote: > Hi, > > in myproto-protocol.pac, i have: > > type myproto_PDU(is_orig: bool) = record { > header: myproto_Header; > //restofdefinition; > } &length=header.msgSize; > > type myproto_Header = record { > //some fields; > msgSize: uint16; > //restoffields; > }; > msgSize represents the length of the PDU. > and when "make"ing bro i get "cannot determine initial buffer length for > type myproto_PDU". > i tryed some random values like &length=60 and it works fine. > i took the modbus analyzer as an exemple to write myproto analyzer but > without success. > any ideas? > -- Hui Lin PhD Candidate, Research Assistant Electrical and Computer Engineering Department University of Illinois at Urbana-Champaign

5 years, 8 months

[Bro] BroCon '15: CFP due Friday & other updates

by Dopheide, Jeannette M

Bro Community, BroCon '15 is just around the corner (August 4th -6th). Have you registered yet? https://www.regonline.com/brocon2015 The Call for Presentations is due this Friday, May 29th: https://www.bro.org/community/brocon2015.html#call-forpresentations Not sure if you want to come to BroCon? Check out our working Agenda here: https://www.bro.org/community/brocon2015.html#agenda More updates will be posted to the Agenda once we have approved the submitted proposals. If you're on Twiiter, tag us @Bro_IDS or use #BroCon2015 to connect with other members of the community. Thanks again, and see you in August! The Bro Team ------ Jeannette Dopheide Bro Outreach Coordinator National Center for Supercomputing Applications University of Illinois at Urbana-Champaign

5 years, 8 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

zeek May 2015