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
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
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)
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
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
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
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
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
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
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);
}
}