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,
I found that BRO 2.3.4 Intel do not work with email's indicators. I have
played on my infrastructure to get BRO intel work and found that email
indicator won't work.
I also tested it on try.bro.org/ the same results . However BRO 2.2
version works well with Intel email's indicators .
Please let me know if more details needed to troubleshoot
Using 2.4
I'm having a problem in a connection_finished event. I've extended the
connection record with an extra field.
But..processing a 512MB capture file I have I get a number of connection
events that don't have a c$conn record in them.
I get the same behavior using connection_EOF.
This script demonstrates the problem. I've attached a sample of the
conn.log records that show a mix of good/bad where you can see the TEST1 and
N/A default on the non-conn records.
1426100429.761609 expression error in ./test.bro, line 11: field value
missing [c$conn]
It seems that if there is no "string" value or if it's an ssl, dns, for
example, then there is no $conn field.
Is there an extendable record in a connection record that is ALWAYS there?
@load base/utils/site
@load base/protocols/conn
redef record Conn::Info += {
testfield: string &default="N/A" &log;
};
event connection_finished(c: connection)
{
if (!c?$conn) {
c$conn$testfield = "TEST2";
}
else {
print("TEST1");
c$conn$testfield = "TEST1";
}
}
Hello all,
I have been working with Kerberos in bro for a bit, and a problem I am
consistently having is that for some reason with Kerberos packets, Bro
cannot correctly identify the correct originator IP address in
kerberos.log. It appears that the response packets are having their orig_h
and resp_h values (and corresponding ports) swapped, so all connections
made in the transfer are incorrectly identified as having the same
originating IP address.
Is this a known issue? Am I doing something wrong? Looking at the packets
in wireshark correctly identifies them.
Thanks,
Peter
The connection record includes the IP/port pair. Is there a way to include MAC addresses?
Best Regards,
Earl Eiland,
Sr. Cyber Security Engineer,
Emerging Technologies, root9B,
San Antonio, Texas
I recently saw something online about reading a table from an external file in a bro script. Now that I'm ready to do that, I can't find any references or code examples. Can anyone provide some links?
Best Regards,
Earl Eiland,
Sr. Cyber Security Engineer,
Emerging Technologies, root9B,
San Antonio, Texas
It seems that while it's possible to add to the intel list in memory while
Bro is running, it's not possible to remove.
That is, if I remove something from the intel file because it's generating
too many false positives, I have to restart Bro in order for it to take
effect.
Is there anything I can do to fix this? I'd rather not restart Bro and lose
connection states.
Does anyone have something they like to use to help create/edit Intel files
in bulk? Im trying to find a way to quickly add a lot of domains to one of
my Intel files and I really don't want to have to added them individually.
Thanks,
Mike
--
Sent from my Android device