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.
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
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
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*
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
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
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
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
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