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
Hi!
I am relatively new to bro so please excuse me, if I missed the obvious solution.
I want to extract files downloaded via http from a pcap-file, but the files I download are never extracted completely.
They seem to be truncated at ~1 mb. My bro-script is quite simple:
event file_new(f: fa_file)
{
Files::add_analyzer(f, Files::ANALYZER_EXTRACT);
}
Are there any other events I have to catch to get the complete file?
When I download a test file from [1] with size 3521964 bytes, only 960204 bytes are extracted. I checked with
wireshark and tcpflow, that the download was completely captured in the pcap,
I tested with Bro 2.3.2 and the current dev version from git.
have a nice weekend!
Franky
[1] http://ipv4.download.thinkbroadband.com/5MB.zip
We have a new Bro installation, built from source on Debian wheezy, that keeps core dumping. It looks like it's choking on some code related to ssh. Here is the diag for the latest crash. It is identical to the other one I have:
[BroControl] > diag
[bro]
Bro 2.3-633
Linux 3.2.0-4-686-pae
No gdb installed.
==== No reporter.log
==== stderr.log
listening on eth1, capture length 8192 bytes
bro: /root/bro/build/src/analyzer/protocol/ssh/ssh_pac.cc:1382: int binpac::SSH::SSH2_KEXINIT::Parse(binpac::const_byteptr, binpac::const_byteptr, binpac::SSH::ContextSSH*, int): Assertion `t_dataptr_after_cookie <= t_end_of_data' failed.
/usr/local/bro/share/broctl/scripts/run-bro: line 100: 10307 Aborted (core dumped) nohup "$mybro" "$@"
==== stdout.log
max memory size (kbytes, -m) unlimited
data seg size (kbytes, -d) unlimited
virtual memory (kbytes, -v) unlimited
core file size (blocks, -c) unlimited
==== .cmdline
-i eth1 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto
==== .env_vars
PATH=/usr/local/bro/bin:/usr/local/bro/share/broctl/scripts:/usr/local/bro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
BROPATH=/usr/local/bro/spool/installed-scripts-do-not-touch/site::/usr/local/bro/spool/installed-scripts-do-not-touch/auto:/usr/local/bro/share/bro:/usr/local/bro/share/bro/policy:/usr/local/bro/share/bro/site
CLUSTER_NODE=
==== .status
RUNNING [net_run]
==== No prof.log
==== No packet_filter.log
==== No loaded_scripts.log
[BroControl] >
This is just running the default setup, with the local subnets configured, as we are just starting with Bro. This is a really low end server, but the capture interface is only running at 100 meg so there are really no resource issues. (Yes, this is a 32-bit box. It's pretty old. That's why I built from source.)
The first crash occurred after a few minutes. Then it ran for nearly 24 hours before this crash. Is there something I can tweak to prevent this?
Thanks,
Ted Llewellyn
Greetings all,
I am new to Bro, and I hope you can help me.
I read the following documentation:
https://www.bro.org/sphinx-git/frameworks/notice.html
Exactly, this part of the code:
...
hook Notice::policy(n: Notice::Info)
{
if
( n$note == SSH::Password_Guessing && n$id$resp_h == 10.0.0.1
)
add n$actions[Notice::ACTION_EMAIL];
}
...
And write it in the file ../local.bro
But, when I generate an attack to IP (10.0.0.1), and I got an error: "*field
value missing [n$id]*" .
I use *bro -i eth0 local *to debug logs in live
I did many changes, also I use "$id?$resp_h" to check errors, and i got the
same error. I am sorry but I am new with Bro and I would like to know How
can I fix that?.
Thank you
Javier
--
Saludos Cordiales
Javier
Hi all,
I'm working on an application based on Bro and we need to use SMB and
Netbios analyzers at the moment.
If I try to use the NetBIOS SSN analyzer found in the master git, I receive
an error when I try to enable the analyzer.
Analyzer::enable_analyzer(Analyzer::ANALYZER_NETBIOSSSN);
Analyzer::register_for_ports(Analyzer::ANALYZER_NETBIOSSSN, ports);
This is the received error:
Internal error: unknown analyzer name NETBIOS; mismatch with tag
analyzer::Component?
So I have seen the NetbiosSSN.cc file and I have found the line that should
be fixed.
At line 458 you can see that
NetbiosSSN_Analyzer::NetbiosSSN_Analyzer(Connection* conn)
:tcp::TCP_ApplicationAnalyzer("NETBIOS", conn)
I've changed "NETBIOS" string to "NETBIOSSN", then re-built it and Bro
worked.
Can you let me know that this fix is correct?
Thank you.
Best regards,
Danilo
Hi all,
I am trying to use packet-bricks in a FreeBSD 10.1 host with netmap
enabled. Following README, I have executed the following commands:
[ pmain(): line 463] Executing (null)
[print_version(): line 345] BRICKS Version 0.1-alpha
bricks> BRICKS.help()
BRICKS Commands:
help()
print_status()
show_stats()
shutdown()
Available subsystems within BRICKS have their own help() methods:
PktEngine
bricks> utilObj:enable_nmpipes()
[ report(): line 222] stdin:1: attempt to index global 'utilObj'
(a nil value)
stack traceback:
stdin:1: in main chunk
[C]: ?bricks> pe = PktEngine.new("e0")
bricks> print_status()
[ report(): line 222] stdin:1: attempt to call global
'print_status' (a nil value)
stack traceback:
stdin:1: in main chunk
[C]: ?bricks> pe = PktEngine.new("e0", 1024, 1)
[pktengine_new(): line 178] Engine with name: e0 already exists
bricks> lb = Brick.new("LoadBalancer", 2)
bricks> lb:connect_input("vtnet2")
bricks> lb:connect_output("vtnet2{0", "vtnet2{1", "em0")
bricks> pe:link(lb)
546.982488 nm_open [444] overriding ARG3 0
546.982547 nm_open [457] overriding ifname vtnet2 ringid 0x0 flags 0x1
[netmap_link_iface(): line 175] Wait for 2 secs for phy reset
[brick_link(): line 101] Linking e0 with link vtnet2 with batch size:
512 and qid: -1
549.055808 nm_open [444] overriding ARG3 0
[netmap_create_channel(): line 761] zerocopy for vtnet2 --> vtnet2{0
(index: 0) enabled
[netmap_create_channel(): line 766] Created netmap:vtnet2{0 interface
549.101244 nm_open [444] overriding ARG3 0
[netmap_create_channel(): line 761] zerocopy for vtnet2 --> vtnet2{1
(index: 1) enabled
[netmap_create_channel(): line 766] Created netmap:vtnet2{1 interface
549.142483 nm_open [444] overriding ARG3 0
[netmap_create_channel(): line 761] zerocopy for vtnet2 --> em0
(index: 2) enabled
[netmap_create_channel(): line 766] Created netmap:em0 interface
bricks> pe:start()
bricks> [initiate_backend(): line 346] Engine e0 is listening on port 1239
pe.show_stats()
[ report(): line 222] stdin:1: bad argument #1 to 'show_stats'
(userdata expected, got no value)
stack traceback:
[C]: in function 'show_stats'
stdin:1: in main chunk
[C]: ?bricks> show.stats()
[ report(): line 222] stdin:1: attempt to index global 'show' (a nil value)
stack traceback:
stdin:1: in main chunk
[C]: ?bricks>
dmesg shows me the following:
544.880658 [ 407] vtnet_netmap_config vtnet config txq=1,
txd=512 rxq=1, rxd=512
544.946020 [ 676] netmap_update_config configuration changed (but fine)
544.981566 [1219] netmap_mem_global_config reconfiguring
545.014116 [ 818] netmap_config_obj_allocator XXX aligning object by 1 bytes
546.288980 [ 407] vtnet_netmap_config vtnet config txq=1,
txd=512 rxq=1, rxd=512
546.353092 [ 79] vtnet_netmap_free_bufs freed 256 mbufs, 0 netmap
bufs on 1 queues
546.982572 [ 407] vtnet_netmap_config vtnet config txq=1,
txd=512 rxq=1, rxd=512
547.011973 [ 407] vtnet_netmap_config vtnet config txq=1,
txd=512 rxq=1, rxd=512
549.055837 [ 325] netmap_pipe_krings_create 0xfffff80110f9ac00: case
1, create everything
549.101272 [ 325] netmap_pipe_krings_create 0xfffff801105e0800: case
1, create everything
em0: link state changed to DOWN
em0: link state changed to UP
As you can see, stats failed. When I try to use tcpdump:
root@nsm02:/dev # tcpdump -i 'netmap:vtnet2{0'
tcpdump: netmap:vtnet2{0: No such device exists
(BIOCSETIF failed: Device not configured)
Please, any help??
Hello again!
I'm trying to run installation with client-to-server only traffic
visible to Bro. This seems not to break Bro however the following
messages fill weird.log:
1427302895.156616 C50xd821xHdTYgVRWj 172.x.x.x
33468 87.252.227.138 41223 data_before_established
- F bro
1427302895.228297 CqeQYQ1Q4MgbwupuR8 172.x.x.x
45107 62.84.63.46 13871 possible_split_routing
- F bro
1427302895.228985 CqeQYQ1Q4MgbwupuR8 172.x.x.x
45107 62.84.63.46 13871
data_before_established - F bro
1427302895.782191 CiSuNR2tWAfGBpuSxe 172.x.x.x
55007 80.249.82.211 11898 possible_split_routing
- F bro
1427302895.783376 CiSuNR2tWAfGBpuSxe 172.x.x.x
55007 80.249.82.211 11898 data_before_established
Does anyone know how to switch Bro into asymmetric mode? At least can I
disable notices that need 2-way session?
Thanks!
Pavel
From: Rovnov Pavel
Sent: Wednesday, March 25, 2015 3:11 PM
To: 'bro(a)bro.org'
Subject: One-way TCP session to handle HTTP requests only
Hello!
I'm looking for a monitoring solution that will give me an instrument to
log all HTTP requests (including HTTPS). I see that Bro does this really
well by default. But as soon as I will have huge amount of web traffic
(like 10Gb/s+) I would like to process HTTP requests only by mirroring
only one-way of TCP sessions. That will save a lot of processing power
since HTTP request << HTTP response.
I found only one reference to my idea that say that handling one-way TCP
at best will slow down Bro
(http://mailman.icsi.berkeley.edu/pipermail/bro/2006-October/001853.html
). So the questions are:
1) Can anyone confirm that using Bro to handle one-way TCP session
is a bad idea?
2) Does anyone have any experience of tuning Bro to handle one-way
TCP sessions? We might turn off unnecessary processing (e. g. policies
that need 2-way session) to solve the task...
Thanks!
Pavel
Please try to keep the Bro list CC-ed on this, as it might be useful to
others.
That error location makes sense - it's where I would expect to see problems
if there's an issue with DNS. What I'm confused about is that SMB and SSH
should be completely unrelated.
How exactly are you disabling the SMB plugin when you don't see any errors?
You might just want to comment out the following lines in your local.bro:
@load protocols/ssh/interesting-hostnames
@load frameworks/files/detect-MHR
Of course, the "better" solution would be to fix the system so that it can
do reverse DNS lookups (and TXT queries for detect-MHR) :-)
--Vlad
On Fri, Mar 20, 2015 at 1:55 PM, Danilo Nicolò <dani.nicolo(a)gmail.com>
wrote:
> Hi Vlad,
>
> Thanks for your reply.
> Yes, I did the git merge and I didn't have any conflicts.
>
> About the stacktrace, that error is raised up when Bro logs SSH packets
> with SMB plugin active. In particular, the SIGBUS error is catched when the
> script
> /usr/local/bro/share/bro/policy/protocols/ssh/interesting-hostnames.bro is
> launched.
> I've debugged the stacktrace and I found the row when the SIGBUS is raised
> up on the script:
>
> 'when ( local hostname = lookup_addr(host) )'
>
> This is the gdb analysis:
>
> Reading symbols from ./bro...done.
> (gdb) r
> Starting program: /usr/local/bro/bin/bro -i eth0 -U .status -p broctl -p
> broctl-live -p standalon
> /usr/local/bro/share/bro/policy/protocols/ssh/interesting-hostnames.bro
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> listening on eth0, capture length 8192 bytes
>
> [New Thread 0x7ffff588e700 (LWP 5824)]
> [New Thread 0x7ffff508d700 (LWP 5825)]
> tcmalloc: large alloc 1562501120 bytes == 0x42420000 @ 0x7ffff70f1d9c
> 0x7ffff7111845 0x5e5846 0x5e5a5b 0x600f0c 0x603958 0x5e620d 0x60352c
> 0x5e620d 0x6038c2 0x603a25 0x5e620d 0x60317e 0x603209 0x5e620d 0x547d31
> 0x5e620d 0x6038a4 0x603a25 0x5e620d 0x547d31 0x5e620d 0x6038a4 0x603a25
> 0x5e620d 0x547d31 0x5e620d 0x6038a4 0x603a25 0x5e620d 0x547d31
>
> Program received signal SIGBUS, Bus error.
> 0x00000000005e58c7 in BinarySerializationFormat::Write (this=0x427a090,
> v=<optimised out>, tag=<optimised out>) at
> /home/danko/bro_stable/bro/src/SerializationFormat.cc:311
> 311 return WriteData(&v, sizeof(v));
> (gdb)
>
>
> If I try to disable smb plugin I don't receive any errors.
>
>
> Best regards,
>
> Danilo
>
>
>
> 2015-03-20 18:46 GMT+01:00 Vlad Grigorescu <vlad(a)grigorescu.org>:
>
>> Hi Danilo,
>>
>> One of the bottlenecks of SMB development has been a lack of real-world
>> testing, so I'd definitely appreciate any bugs or feedback you run into.
>>
>> On Thu, Mar 19, 2015 at 10:48 AM, Danilo Nicolò <dani.nicolo(a)gmail.com>
>> wrote:
>>
>> I've substituted src/analyzer/protocol/smb,
>>> src/analyzer/protocol/netbios, init-bare.bro and init-default.bro from SMB2
>>> version to master version.
>>>
>>
>> I don't quite understand this - can you elaborate on what specifically
>> you did here? If you did the git merge topic/vladg/smb, that should replace
>> everything for you. Were you seeing merge conflicts? I can get those
>> cleaned up, if so.
>>
>>
>>> Thread 1 (Thread 0x7f3337201780 (LWP 22674)):
>>> #0 0x0000000000816193 in Serializer::Write (this=0x7fffc052fd00,
>>> v=35329, tag=0xb7a68f "stype") at /home/danko/bro/src/Serializer.h:57
>>> #1 0x0000000000815fdc in SerialObj::DoSerialize (this=0x2b2bf00,
>>> info=0x7fffc052fd60) at /home/danko/bro/src/SerialObj.cc:268
>>> #2 0x00000000007df8f6 in BroObj::DoSerialize (this=0x2b2bf00,
>>> info=0x7fffc052fd60) at /home/danko/bro/src/Obj.cc:226
>>> #3 0x0000000000843002 in BroType::DoSerialize (this=0x2b2bf00,
>>> info=0x7fffc052fd60) at /home/danko/bro/src/Type.cc:283
>>> #4 0x000000000081585b in SerialObj::Serialize (this=0x2b2bf00,
>>> info=0x7fffc052fd60) at /home/danko/bro/src/SerialObj.cc:121
>>> #5 0x0000000000842cce in BroType::Serialize (this=0x2b2bf00,
>>> info=0x7fffc052fd60) at /home/danko/bro/src/Type.cc:212
>>> #6 0x00000000008438ec in TypeList::DoSerialize (this=0x2b402e0,
>>> info=0x7fffc052fd60) at /home/danko/bro/src/Type.cc:392
>>> #7 0x000000000081585b in SerialObj::Serialize (this=0x2b402e0,
>>> info=0x7fffc052fd60) at /home/danko/bro/src/SerialObj.cc:121
>>> ...
>>> #81382 0x0000000000837f2a in ForStmt::DoExec (this=0x4c90610,
>>> f=0x6e5d9c0, v=0x740a610, flow=@0x7fffc0530080: FLOW_NEXT) at
>>> /home/danko/bro/src/Stmt.cc:1358
>>> #81383 0x0000000000833db1 in ExprStmt::Exec (this=0x4c90610,
>>> f=0x6e5d9c0, flow=@0x7fffc0530080: FLOW_NEXT) at
>>> /home/danko/bro/src/Stmt.cc:373
>>> #81384 0x0000000000839969 in StmtList::Exec (this=0x4c8f850,
>>> f=0x6e5d9c0, flow=@0x7fffc0530080: FLOW_NEXT) at
>>> /home/danko/bro/src/Stmt.cc:1764
>>> #81385 0x0000000000839969 in StmtList::Exec (this=0x4c93a60,
>>> f=0x6e5d9c0, flow=@0x7fffc0530080: FLOW_NEXT) at
>>> /home/danko/bro/src/Stmt.cc:1764
>>> #81386 0x00000000007a4828 in BroFunc::Call (this=0x4974a80,
>>> args=0x5acc3c0, parent=0x0) at /home/danko/bro/src/Func.cc:403
>>> #81387 0x000000000077d5a4 in EventHandler::Call (this=0x49ae420,
>>> vl=0x5acc3c0, no_remote=false) at /home/danko/bro/src/EventHandler.cc:130
>>> #81388 0x0000000000731ff1 in Event::Dispatch (this=0x70daec0,
>>> no_remote=false) at /home/danko/bro/src/Event.h:50
>>> #81389 0x000000000077ccdd in EventMgr::Dispatch (this=0xf65e60 <mgr>) at
>>> /home/danko/bro/src/Event.cc:111
>>> #81390 0x000000000077cde8 in EventMgr::Drain (this=0xf65e60 <mgr>) at
>>> /home/danko/bro/src/Event.cc:128
>>> #81391 0x00000000007dbfa7 in net_run () at /home/danko/bro/src/Net.cc:374
>>> #81392 0x000000000073105c in main (argc=19, argv=0x7fffc05309b8) at
>>> /home/danko/bro/src/main.cc:1212
>>>
>>
>> I've seen errors similar to this before, but I'm not sure it's related
>> to SMB. Usually the cause of this is that Bro can't do DNS queries (there
>> are a few scripts that do reverse lookups). Do you see the same behavior if
>> you run git/master on this system (with no SMB changes)?
>>
>> Thanks,
>>
>> --Vlad
>>
>
>
