Hi,
It seems no matter what I do, I still get these notices
"PacketFilter::DroppedPackets". I created more workers, but I have a
question about creating new workers via using an existing worker to capture
on the same interface using the "lb_procs" method to up the number of
"sub-threads?" for multi-CPU processing. What advantage does a new worker
give me over "lb_procs"?
Thanks!
Hi
Any idea ?
From: Izik Birka
Sent: Tuesday, February 14, 2017 9:15 AM
To: 'Martin, Eric J' <ejmartin2(a)wpi.edu>
Subject: RE: SMB
Hi
I enable them and it's great but I'm looking for SMB bytes statistics , like in conn.log file
For example if someone downloaded 300 MB with SMB protocol (form network share) , is there any file that hold this statistics ?
with http protocol , I can find it in conn.log file
thanks
From: Martin, Eric J [mailto:ejmartin2@wpi.edu]
Sent: Tuesday, February 14, 2017 12:09 AM
To: Izik Birka <Izik.Birka(a)hot.net.il<mailto:Izik.Birka@hot.net.il>>
Subject: Re: SMB
There's smb_files and smb_mappings that need to be enabled. When you say 'stats', what are you looking for?
--
Eric Martin
ejmartin2(a)wpi.edu<mailto:ejmartin2@wpi.edu>
Information Security Analyst
Office: (508) 831-6070
Worcester Polytechnic Institute
www.wpi.edu<http://www.wpi.edu>
PGP: C74F 1EBF 2E80 7984 8CB5 064E BF17 D34C C704 B30F
For security purposes, this message has been double ROT13 encoded
________________________________
From: bro-bounces(a)bro.org<mailto:bro-bounces@bro.org> <bro-bounces(a)bro.org<mailto:bro-bounces@bro.org>> on behalf of Izik Birka <Izik.Birka(a)hot.net.il<mailto:Izik.Birka@hot.net.il>>
Sent: Monday, February 13, 2017 3:34:29 AM
To: bro(a)bro.org<mailto:bro@bro.org>
Subject: [Bro] SMB
Hi
Is there any logs that contains SMB stats ? why conn.log doesn't contains SMB connection ?
I have bro 2.5
Thanks
Izik Birka
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain materials protected by copyright or information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or agreement. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication by error, notify the sender immediately and delete this message immediately. Thank you.
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain materials protected by copyright or information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or agreement.
If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication by error, notify the sender immediately and delete this message immediately.
Thank you.
Hello,
When a bro script detects something, how can you go about resolving the issues that caused it (assuming it wasn't noise that caused it)? Is there something that I change in Bro or is this something that would be covered in the corporate compliance / security?
Following up with that what is the best practice to analyze the packet captures from Bro to determine if there is an actual issue? I am currently looking into Splunk as a log parser.
Best regards,
Andrew Dellana
Intern
________________________
Has anyone experienced segfaults with Bro + Netmap when executing a ‘broctrl stop'?
1487299650.431866 818913 packets received on interface bro}3, 0 dropped
/opt/bro/share/broctl/scripts/run-bro: line 107: 4821 Segmentation fault nohup "$mybro" "$@"
-Dave
Hi,
I'm trying to troubleshoot a Bro IDS that is experiencing capture loss with
dropped packets. The machine I'm using has a 16-core Intel Xeon processor,
96Gb RAM, and an Intel NIC. I have 3 Bro workers with CPU affinity enabled
and I'm using the pf_ring module on CentOS with no custom Bro scripts
running. All of my processors are running at 99% utilization.
According to my operating system, I'm dropping about 8000 packets over the
course of a day on a 300-400Mbps network. According to Bro capstats, I am
dropping about the same number of packets I'm receiving, sometimes more
than I receive. My capture_loss.log shows my workers lose about 30-50%
packets and my manager and proxy, 70-90%. I can provide any configurations
or screenshots if necessary.
I'm trying to troubleshoot where the issue lies. I initially installed Bro
with all the recommended packages (tcmalloc, etc...) and the pf_ring module
and I can see that Bro is using it. At this point, everything I see is
pointing to an application issue and I'm running Bro version 2.5. I had the
same issue with Bro v.2.4 as well.
Short of tweaking OS kernel and NIC card settings, I'm not sure where else
I could try to reduce my packet drop count in Bro. Any recommendations?
Thanks,
Hello,
First of all, I am really grateful for Bro and its easy scripting. I have been using Bro in the context of my master thesis and had lots of fun using it.
I am contacting you today as I have encountered a problem that none of my google researching skills could solve. Let me try and describe it clearly.
What I am trying to acheive:
I am using the pcap file available at https://www.bro.org/static/traces/ssh.pcap to simulate a SSH::Password_Guessing notice using the command `broctl process`. My goal is simply to make Bro send me an email when such a notice is raised.
What is going wrong:
Even though the notice is raised, I do not receive any emails.
Hypothesis to eliminate:
- First of all, my broctl.cfg file is configured correctly and, if I raise a random notice in the `bro_init()` event, I successfully receive the email.
- I am also sure that the notice is being raise properly as a `notice.log` file gets generated with the relevant notice containing the `Notice::ACTION_EMAIL` action. I even hard-coded a print inside the module that raise the notice to make sure that this part of the code was run.
What I have tried:
- redefining Notice::emailed_types
- redefining Notice::alarmed_types
- adding a Notice::policy hook containing `add n$actions[Notice::ACTION_EMAIL];`
I hope that my problem description helps. I am really struggling to understand this behaviour and cannot find similar problems online.
Please do not hesitate to contact me should you need additional information.
Thank you in advance for your support,
Best regards,
Loris
Hi all!
After successfully compiling pf_ring and enable module on a rpi 3 arm
kernel :
pi@raspberrypi:~ $ modinfo pf_ring && cat /proc/net/pf_ring/info
filename: /lib/modules/4.4.34-v7+/kernel/net/pf_ring/pf_ring.ko
alias: net-pf-27
description: Packet capture acceleration and analysis
author: ntop.org
license: GPL
srcversion: 159AD63EACFCF3EFC835D09
depends:
vermagic: 4.4.34-v7 SMP mod_unload modversions ARMv7
parm: min_num_slots:Min number of ring slots (uint)
parm: perfect_rules_hash_size:Perfect rules hash size (uint)
parm: transparent_mode:(deprecated) (uint)
parm: enable_debug:Set to 1 to enable PF_RING debug tracing into
the syslog (uint)
parm: enable_tx_capture:Set to 1 to capture outgoing packets
(uint)
parm: enable_frag_coherence:Set to 1 to handle fragments (flow
coherence) in clusters (uint)
parm: enable_ip_defrag:Set to 1 to enable IP defragmentation(only
rx traffic is defragmentead) (uint)
parm: quick_mode:Set to 1 to run at full speed but with upto one
socket per interface (uint)
PF_RING Version : 6.4.1 (unknown)
Total rings : 2
Standard (non ZC) Options
Ring slots : 32768
Slot version : 16
Capture TX : Yes [RX+TX]
IP Defragment : No
Socket Mode : Standard
Total plugins : 0
Cluster Fragment Queue : 0
Cluster Fragment Discard : 0
I compiled also successfully bro with pf_ring plugin. But there is a
problem...Although rpi interface "sees" network traffic as it is plugged on
a network mirror bridge and pf_ring compiled tcpdump output does full
network packet capture :
pi@raspberrypi:~/bro-test $ ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:eb:68:1a:49
inet addr:10.0.0.31 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::18a4:4736:aeb7:94b7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5912 errors:0 dropped:0 overruns:0 frame:0
TX packets:1317 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:358436 (350.0 KiB) TX bytes:166018 (162.1 KiB)
pi@raspberrypi:~/bro-test $ sudo /opt/pfring/sbin/tcpdump host not 10.0.0.31
[PF_RING] mmap() failed: try with a smaller snaplen
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:00:43.045119 IP 10.0.0.2.37630 > 10.0.0.3.9200: Flags [.], seq
2264223995:2264225443, ack 4236626719, win 1444, options [nop,nop,TS val
3506664 ecr 3496553], length 1448
21:00:43.045498 IP 10.0.0.2.37630 > 10.0.0.3.9200: Flags [.], seq
1448:2896, ack 1, win 1444, options [nop,nop,TS val 3506664 ecr 3496553],
length 1448
21:00:43.045500 IP 10.0.0.2.37630 > 10.0.0.3.9200: Flags [P.], seq
2896:4096, ack 1, win 1444, options [nop,nop,TS val 3506664 ecr 3496553],
length 1200
21:00:43.045502 IP 10.0.0.2.37630 > 10.0.0.3.9200: Flags [.], seq
4096:5544, ack 1, win 1444, options [nop,nop,TS val 3506664 ecr 3496553],
length 1448
21:00:43.046343 IP 10.0.0.2.37630 > 10.0.0.3.9200: Flags [.], seq
5544:6992, ack 1, win 1444, options [nop,nop,TS val 3506664 ecr 3496553],
length 1448
21:00:43.046344 IP 10.0.0.2.37630 > 10.0.0.3.9200: Flags [P.], seq
6992:7028, ack 1, win 1444, options [nop,nop,TS val 3506664 ecr 3496553],
length 36
21:00:43.046346 IP 10.0.0.3.9200 > 10.0.0.2.37630: Flags [.], ack 7028, win
1024, options [nop,nop,TS val 3496778 ecr 3506664], length 0
^C
7 packets captured
10 packets received by filter
3 packets dropped by kernel
When i start bro with pf_ring bro exports logs only for rpi self traffic
that is to say traffic from or to 10.0.0.31 ip:
pi@raspberrypi:~/bro-test $ sudo /opt/bro/bin/bro -i pf_ring::eth0
listening on eth0
1488315827.676782 616 packets received on interface eth0, 0 dropped
pi@raspberrypi:~/bro-test $ cat conn.log
#separator \x09
#set_separator ,
#empty_field (empty)
#unset_field -
#path conn
#open 2017-02-28-21-03-39
#fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p
proto service duration orig_bytes resp_bytes conn_state
local_orig local_resp missed_bytes history orig_pkts
orig_ip_bytes resp_pkts resp_ip_bytestunnel_parents
#types time string addr port addr port enum
string interval count count string bool bool count
stringcount count count count set[string]
1488315814.841388 Cn0COF2Dl2RGFtlsak 10.8.0.2 60414
10.0.0.31 22 tcp - - - - OTH -- 0 ^c 0
0 0 0 (empty)
1488315826.472327 C0a8me4cjwn36bIpZ 10.8.0.2 60414 10.0.0.31
22 tcp - - - - OTH -- 0 ^c 0 0 0
0 (empty)
#close 2017-02-28-21-03-47
There are no errors and no capture_loss or drop packets, although base bro
plugins are enable, bro sees only limited events:
pi@raspberrypi:~/bro-test $ ls -la
total 28
drwxr-xr-x 3 pi pi 4096 Feb 28 21:03 .
drwxr-xr-x 12 pi pi 4096 Feb 28 20:55 ..
-rw-r--r-- 1 root root 699 Feb 28 21:03 conn.log
-rw-r--r-- 1 root root 253 Feb 28 21:03 packet_filter.log
-rw-r--r-- 1 root root 362 Feb 28 21:03 reporter.log
drwx------ 3 root root 4096 Feb 28 21:03 .state
-rw-r--r-- 1 root root 428 Feb 28 21:03 weird.log
On the contrary if on the same machine bro starts with default libpcap i
get full network visibility and real traffic logs:
pi@raspberrypi:/opt/bro/logs/current $ ls
capture_loss.log dce_rpc.log dns.log http.log notice.log
stats.log stdout.log weird.log
conn.log dhcp.log files.log kerberos.log ssl.log
stderr.log syslog.log x509.log
pi@raspberrypi:/opt/bro/logs/current $
pi@raspberrypi:/opt/bro/logs/current $ tail -f conn.log
1488300721.714628 C0ZuNp3n1AAPFqOAP8 fe80::d436:4663:8865:8d25
546 ff02::1:2 547 udp - 62.994834 784 0 S0 F
F 0 D 7 1120 0 0 (empty)
1488300873.355133 C4qmHe463s94Z4dwq1 10.0.0.3 43772 10.0.0.1
53 udp dns 0.000407 30 105 SF T T 0 Dd
1 58 1 133 (empty)
1488300873.353585 CHKByP1XMjBTSqRJ7e 10.0.0.3 55014 10.0.0.1
53 udp dns 0.000434 44 107 SF T T 0 Dd
1 72 1 135 (empty)
1488300882.759725 CnoqlW2FFjY3LX3q2 10.0.0.6 49704 10.0.0.5
445 tcp - 14.935617 3786 1209 RSTO T T 0
ShADdaR 13 4318 9 1581 (empty)
1488300864.039916 CwI2Fng0jsi2ODWl9 10.0.0.31 123
193.93.167.241 123 udp - 0.020522 0 48 SHR T
F 0 Cd 0 0 1 76 (empty)
1488300874.039921 CN6xHJ2fqNoOloNr4e 10.0.0.31 123
194.116.168.41 123 udp - 0.029709 0 48 SHR T
F 0 Cd 0 0 1 76 (empty)
1488300933.675398 Cd7Bql2wn5TNLWBTMg 10.0.0.3 47206 10.0.0.1
53 udp dns 0.000539 30 105 SF T T 0 Dd
1 58 1 133 (empty)
1488300933.674395 CHSnQs2YEeLjiqxOe3 10.0.0.3 55965 10.0.0.1
53 udp dns 0.000245 44 107 SF T T 0 Dd
1 72 1 135 (empty)
1488300889.039915 CALlew1poCyja9ha2l 10.0.0.31 123
91.217.155.60 123 udp - 0.021564 0 48 SHR T F
0 Cd 0 0 1 76 (empty)
So any ideas whats going on ? I couldn't find any reference of something
similar really and i am searching reading and compiling for 2 weeks :)
Bro is a great tool and combined with rpi and pf_ring very flexible and
powerful in cluster mode. So any help would be highly appreciated to help
me with this project. Thanks in advanced
> On Feb 27, 2017, at 5:54 PM, fatema bannatwala <fatema.bannatwala(a)gmail.com> wrote:
>
> When I configured and installed bro from source, I did:
> $./configure --prefix=/usr/local/bro/2.5 --with-pcap=/usr/local/pfring/5.6.2
Yep, you are using the libpcap wrapper here, which is currently the only way to do clustered load balancing with PF_Ring unless you do that tiny change that Mark pointed out a minute ago. To get that more tightly integrated and configurable with broctl would take a bit more work, but as a hack that tiny change would work.
You can tell in your node.cfg if you are using the libpcap wrapper or the plugin by the interface name. If you have use an interface name like: pf_ring::eth1, then you are using the plugin and load balancing won't work. If you are just using an interface name like eth1 and lb_method=pf_ring, then you will be using the libpcap wrapper.
When the pf_ring developers contributed the pf_ring plugin, it seems that they didn't do full integration with the deployment method.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
Hi all,
I am trying to use Bro's PF_RING plugin with broctl, using a simple bro
cluster on a single host.
Here is an extract of my 'node.cfg' file:
[worker]
type=worker
host=localhost
interface=pf_ring::eth0
lb_method=pf_ring
lb_procs=8
pin_cpus=0,1,2,3,4,5,6,7
When I used the deploy command, I got the following error: "fatal error:
type of packet source 'pf_ring' no recognized, or mode not supported"
Here is the output of the deploy command:
[BroControl] > deploy
...
starting ...
starting manager ...
starting proxy ...
starting worker-1
...
starting worker-8
worker-1 terminated immediately after starting; check output with "diag"
...
worker-8 terminated immediately after starting; check output with "diag"
And when running "diag":
[BroControl] > diag
==== stderr.log
fatal error: type of packet source 'pf_ring' no recognized, or mode not
supported
However I do not have any problem running bro as a standalone process
with local commands such as:
$/usr/local/bro/bin/bro -i pf_ring::eth0
listening on eth0
and:
$/usr/local/bro/bin/bro -N | grep PF
Bro::PF_RING - Packet acquisition via PF_RING (dynamic, version 1.0)
This tends to prove Bro plugin has been installed and works.
I think Broctl is launching Bro binary without the right settings for
the plugin to be found/to work correctly. Am I missing something with
configuration files ?
May be the environment variables aren't properly set?
Does anyone use bro's PF_RING plugin with a cluster configuration
without issues?
Thanks,
Rémi
Noticed this today and I believe it's related to a recent cluster crash.
The virtual memory size of the Bro manager continues to grow slowly (56G
right now) while the resident active memory remains around 4G. To my
knowledge this suggests a memory leak. The system is FreeBSD.
We are using a Kafka only based output with local file logging disabled and
a modified number of loggers. I think a single logger works fine for the
most part but I used 4 here for testing after the recent cluster crash.
Regarding the crash, the cluster was running fine and then active memory
spiked sharply until reaching the ceiling and consuming swap. I suspect it
was related to the VSIZE of the manager reaching a maximum of some sort and
triggering the failure.
Name Type Host Pid Proc VSize Rss Cpu Cmd
logger-1 logger 10.1.1.1 85959 parent 176M 67M 6% bro
logger-1 logger 10.1.1.1 86115 child 194M 62M 0% bro
logger-2 logger 10.1.1.1 85962 parent 709M 175M 19% bro
logger-2 logger 10.1.1.1 86017 child 194M 65M 1% bro
logger-3 logger 10.1.1.1 85965 parent 663M 164M 13% bro
logger-3 logger 10.1.1.1 86114 child 202M 71M 0% bro
logger-4 logger 10.1.1.1 85967 parent 663M 157M 17% bro
logger-4 logger 10.1.1.1 86113 child 194M 63M 0% bro
manager manager 10.1.1.1 86204 child 878M 649M 100% bro
manager manager 10.1.1.1 86109 parent 56G 4G 16% bro
last pid: 1482; load averages: 4.73, 4.73,
4.58 up
3+23:25:56 00:12:45
52 processes: 2 running, 50 sleeping
CPU: 3.4% user, 0.3% nice, 3.3% system, 0.0% interrupt, 92.9% idle
Mem: 538M Active, 6674M Inact, 17G Wired, 26M Cache, 101G Free
ARC: 14G Total, 2325M MFU, 11G MRU, 144K Anon, 57M Header, 548M Other
Swap: 12G Total, 17M Used, 12G Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU
COMMAND
86204 bro 1 108 5 878M 649M CPU27 27 26.0H 100.00% bro
85962 bro 172 20 0 709M 175M select 25 22.4H 25.63% bro
86109 bro 7 20 0 57682M 4879M uwait 13 499:16 22.17% bro
85967 bro 162 20 0 663M 157M select 13 19.7H 20.80% bro
85965 bro 162 20 0 663M 164M select 23 18.2H 16.31% bro
85959 bro 21 20 0 176M 69352K select 40 193:32 6.30% bro
86017 bro 1 25 5 194M 66772K select 36 28:18 1.27% bro
86113 bro 1 25 5 194M 65068K select 42 23:28 0.98% bro
86114 bro 1 25 5 202M 73308K select 38 13:43 0.39% bro
