zeek August 2015

zeek@lists.zeek.org

49 participants
58 discussions

by j2om1350＠unibw.de

Hi all, My goal is to integrate a new protocol analyzer in Bro. This protocol (PROFINET dyscovery and Basic Configuration Protocol) is working on layer 2. My question is, are there special considerations to get at the data of the layer 2? My colleague has tried creating an analyzer by following your instructions for coding an analyzer by binpac. Before he went on vacation, he told me, he could access data with binpac of layer 3 but not of layer 2? Is that correct? If so does it work with the new binpac ++? Any pieces of advice or suggestions how to get started would be greatly appreciated. Kind regards Marcel Odenwald

6 years, 3 months

[Bro] exercising binpac++/spicy parsers

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

6 years, 7 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)

6 years, 9 months

[Bro] Broadcast detection

by Vito Logrillo

Hi all, i want to flag if a given ip is an ip broadcast/multicast or not: there are some built-in functions able to recognize an ip broadcast in Bro? Thanks, Vito

6 years, 9 months

[Bro] using bro for file extraction

by Earl Eiland

I want to use bro to extract files for external analysis. Bro::FileDataEvent appears to be the proper approach. However, I’m not finding the event to write a script for, nor do I know how to write to anything other than a log file. Please advise! Best Regards, Earl Eiland, Sr. Cyber Security Engineer, Emerging Technologies, root9B, San Antonio, Texas

6 years, 10 months

[Bro] Email Notice Suppression

by Scotty Brown

Hi All, I'm running bro 2.4 and have just added a bunch of critical stack intel feeds. All is working well. One of the feeds I have is a list of TOR ips, and once I set notices to true for the critical stack intel I start getting emails (I've set up email alerting for notices). What I would like to do is suppress email alerts for a particular notice from a particular src host. ie (intel.log): 1441063489.889373 CEyDP6zbg6ngOFFa 10.10.10.10 45969 213.163.70.234 443 - - - 213.163.70.234 Intel::ADDR Conn::IN_RESP sensor-eth1-1 from https://www.dan.me.uk/torlist/ via intel.criticalstack.com So any notice that fires from src 10.10.10.10 for the torlist intel - I'd still like to see the notice in the intel file - but not get the email alert. Any pointers? Cheers, Scotty

6 years, 10 months

[Bro] DHCP Analyzer question/issue

by Tim Brennan

I am running Bro 2.4 as part of a recent security-onion installation. I am seeing very few entries in the dhcp.log files. In weird.log, I see tons of entries similar to the below: binpac exception: out_of_bound: DHCP_Message:file: 236 > 187 binpac exception: out_of_bound: DHCP_Message:giaddr: 28 > 14 binpac exception: out_of_bound: DHCP_Message:chaddr: 44 > 32 binpac exception: out_of_bound: DHCP_Message:sname: 108 > 73 Do I have an configuration issue? Any ideas on what is going on or how to troubleshoot? Thanks, Tim

6 years, 10 months

Re: [Bro] [Bro-Dev] Aide broDev

by Johanna Amann

Hello, since my French is a bit bad - English reply first. Most, if not all of the tasks in your list seem to require an active in-path system like an IPS system, not a network monitoring system like Bro. Tasks like requiring a password for users that want to use the Internet or only allowing certain servers to access DNS cannot be easily accomplished with Bro. That being said -- we recently started working on the NetControl framework of Bro that allows you to install rules in certain switches/firewalls to e.g. block traffic that is recognized as being malicious - you could examine if that might fulfil your requirements; installation instructions are available at https://github.com/bro/bro-netcontrol -- Bonjour, beaucoup, sinon tous les taches dans le fichier necessite une machine dans le chemin de reseau. Bro est un logiciel qu'ecoute le resau d'ordinateur passivement; donc Bro ne peut pas influencer le trafic dans le reseau. Taches comme demander un mot de passe pour permettre des connexions sont tres difficile d'accompiler avec Bro. Mais -- recemment nous avons commonce le travail sur un nouveau systeme dans Bro appelle 'NetControl'. Netcontrol permets, par example, de ne pas permettre certain connexions. NetControl pousse des regles aux, par example, pare-feux ou switchs. Les instructions pour l'installations sont disponsibles a https://github.com/bro/bro-netcontrol Johanna On Sat, Aug 29, 2015 at 08:05:09PM +0100, Edgar D. AYENA wrote: > Bonjour chers amis développeurs Bro, > Je suis Edgar, et je suis débutant sur Bro. Mon mémoire de fin de > formation m'a amené à mettre en place des politiques de sécurité avec > l'outil Bro. J'ai énuméré quelques taches à exécuter dans un fichier > que j'ai joint à ce mail. Je ne sais pas si tout est faisable avec bro > mais je voudrais sérieusement de l'aide car la date de ma soutenance > se rapproche et je voudrais pouvoir appliquer tout au moins certaines > lors de ma présentation. > Merci de m'aider SVP. > > -- > Cordialement, > ------ > Edgar D. AYENA, > Tél: (00229) 96 055 506 - 95 805 326 > 03 BP 3172 Cotonou, R. Bénin > ayenadedgar(a)yahoo.fr > ayenadedg(a)gmail.com > _______________________________________________ > bro-dev mailing list > bro-dev(a)bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

6 years, 10 months

[Bro] Bro on CentOS 7

by Drake Aronhalt

Has anyone had any issues running bro on CentOS 7.1? It crashes the entire system every time I run 'broctl start'. I've configured with and without pfring as well as with and without c++11 support. The kernel I'm using is 3.10.0-229.11.1.el7.x86_64 (I've also tried to the previous kernel). The NIC is an intel I350 NIC with the stock driver, although I tried updating the driver to the current intel driver with the same results. I think this is a kernel issue (getting ready to file a bug there) I just wanted to make sure someone in the community didn't have a solution for this already. Thanks. Drake

6 years, 10 months

[Bro] Getting info records when log events happen, but where the logging script has no specific log event type

by Gary Faulkner

In my quest to graph event statistics tied to bro logs I've run across a few scripts that seem to break the idiom of logging being a separate event from the rest of the events in a script. A couple examples are capture-loss and tunnels. Both scripts call the LOG function within some other event that doesn't expose the underlying info record to other scripts as far as I can tell. A lot of my meta-data collection acts on the log events and the data contained within the info records at the time those events are logged. I'm wondering if there is another way to grab that data without modifying the base scripts or if these scripts can be easily made to have a logging event? Here are a couple examples of things I'd like to be able to do. * Increment a counter whenever a new log line is written (useful for troubleshooting upstream log aggregator inputs) * Send raw data such as percent_lost per peer to an external time series database (could be useful for seeing loss over time, or identifying problems with load-balancing and filtering of flows). * Track number of tunnels seen by tunnel type (knowing how often and when traffic is being tunneled could be interesting) I also find tracking event counters can be useful for identifying things that are outside the norm, especially in cases where seeing similar trends in a log management system or SEM involves a very expensive query. For example a sudden spike in TCP connection attempts / SYNs that could indicate DOS participation, spikes in the number of DNS ANY queries (probably an open resolver being abused) etc. Here are a few simplistic examples of some counters I'm already collecting that show how the log event and info record are used (These rely on JA's statsd plugin and some stats may be borrowed/derived): # DNS Events event DNS::log_dns(rec: DNS::Info) { statsd_increment("bro.log.dns", 1); #Track DNS log volume if(rec?$rcode && rec$rcode == 3) {statsd_increment("bro.dns.error.nxdomain", 1);} if(rec?$qtype_name && /query/ !in rec$qtype_name) { local s = fmt("bro.dns.query.type.%s", rec$qtype_name); statsd_increment(s, 1); } } # Notice Events event Notice::log_notice(rec: Notice::Info) { statsd_increment("bro.log.notice", 1); #Track Notice log volume if(rec?$note) { local s = fmt("bro.notice.type.%s", rec$note); local s2 = sub(s, /::/, "_"); #influxdb doesn't like :: so replace it with _ statsd_increment(s2, 1); } }

6 years, 10 months

2022

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 August 2015