Hi all,
Recently I have some problems with Bro and PF_RING in cluster.
On my server, when I have less than 32 worker threads(rings),
everything is okay, but when I use worker threads more than 32, pf_ring
start to receive repeating data packets. For example, rings less than 32, I
send 400000 packets to server and pf_ring info in /proc shows there is
400000 packets in rings, but when rings greater than 32, I can get 800000
packets when 33 rings and 1200000 packets when 34 rings and so on.
I guess if there is some rules that a pf_ring or a bro cluster can only
support less than 32 rings or worker threads on a server or some other
reasons?
Any insight would be helpful.
Hey all,
We have logger and manager running on the same node, and it started to use
complete swap and bro logs in current dir stopped rotating.
We have run in this type of issue before when running Bro2.4, and it turned
out that moving proxies to the worker nodes solved the high load issue on
manager, and things started working normally.
Now, we have all the proxies on the worker nodes (4 in total) and logger is
running on the same node as manager, so my guess would be, that might be
causing the high load on manager.
The bro processes are really big on the manager:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
104772 bro 20 0 24.926g 0.017t 1300 S 45.7 25.0 4542:04 bro
125346 bro 20 0 0.221t 0.027t 3444 S 40.4 39.4 187:28.80 bro
125366 bro 25 5 1510856 275516 728 R 40.1 0.4 222:22.58 bro
104776 bro 25 5 540736 228920 360 S 8.9 0.3 893:42.05 bro
Also, the free -g output looks like this:
$ free -g
total used free shared buff/cache
available
Mem: 70 47 0 0 22
21
Swap: 7 7 0
Next thing I am going to try is to disable some of the protocols from
logging (don't know how much help it would be) and restart Bro.
Any other suggestions/Best practices to follow, to avoid this situation in
future (really not looking forward to the quick and dirty fix of restarting
Bro whenever this happens :) )?
Also, I have proper ethtool settings (tso off gso off gro off rx off tx off
sg off) on the manager as well (as suggested in some of the posts for
better performance).
Thanks,
Fatema.
Hello,
Is it easier to have a NetControl action in each script or to have one file that contains all the NetControl actions. I want to do one that has all the NetControl actions contained in one script, but am unsure of how / if it is possible to import information from one script to another.
And if it is possible to import information to a single NetControl Script would someone be kind enough to provide a template.
Freundliche Grüße / Best regards,
Andrew Dellana
Intern
________________________
Hi All,
I'm fairly new to Bro and I have a question very similar to this one '
http://mailman.icsi.berkeley.edu/pipermail/bro/2017-January/011389.html'.
Basically I want the easiest/best path to get standard Bro events (conn,
http, dns, ssl, weird..etc) into Python.
1) Is broctl / python-broccoli the best path?
- Note: in my testing I had to use broctl> start . in order for my
python Connection() to work
- If this isn't necessary and I can do the same with just running
Bro standalone pls let me know
2) If broctl/python-broccoli IS the best path then how do I 'subscribe' to
the standard events?
- Is there a list of the standard events?
- If so do I just @event with a method that has the same name as the
event?
Sorry if these are naive questions, but so far my googling/trying/testing
has been a bit hit-miss :)
Cheers,
-Brian Wylie
Hi,
I am analysing a large number of "pcap" files using,
bro -r *.pcap my_bro.script
The problem is that for each new pcap file, bro over-writes the previous *.log files if I don't change my working directory. Is there a way of controlling the rotation of log files? I know that "broctl" has this time base rotation, but is there any sort of rotation control when bro is run from command line? I can change the working directory, but I want to have all my results in a single a log file (files) so that it is easy to query them.
Regards
Asad
&log cert_chain attribute (vector of Files::info) in ssl.log file.
I would like to list the server's chain of certificates in ssl.log (log of
handshake data) alongside each handshake.
In ssl.log, the cert_chain attribute (certificate chain of the server) is
not being logged, and is of type *vector of **Files::info*. When I tried to
add "&log" attribute to cert_chain in files.bro, it gave an error that:
".... cert_chain is of type that cannot be logged."
When I tried changing the type from *vector of Files::info* to *vector of
string*, it sprang up some different errors since cert_chain is referenced
as a *vector of Files::info* in other parts of files.bro script.
Please tell me how I can log the cert_chain attribute in ssl.log file.
Does Spicy/BinPAC++ have a BNF?
I couldn't find one, if it exists.
Thanks!
- 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
> On Mar 29, 2017, at 5:38 PM, Robert Harrelson <bobharrelsons(a)gmail.com> wrote:
>
> Dear Justin,
>
> Sorry for that mistake. I may have mixed up the files. I just re-ran bro and have copied below the results of ssl.log and conn.log.
> Thanks again for your help!
>
> --Robert
>
>
>
> conn.log
>
> #separator \x09
> #set_separator ,
> #empty_field (empty)
> #unset_field -
> #path conn
> #open 2017-03-29-17-27-40
> #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_bytes tunnel_parents
> #types time string addr port addr port enum string interval count count string bool bool count string count count count count set[string]
>
> 1490822851.106865 Ckk89B3l4i616mbQx6 10.245.44.33 61486 216.58.219.100 443 tcp - 12.846213 0 4118 SHR - - 0 ^hadf 0 0 9 4594 (empty)
>
Ah yes... the hadf for all of your connection histories shows that Bro is only seeing half of your connections
Are you running bro on 10.245.44.33 itself?
https://www.bro.org/documentation/faq.html#why-isn-t-bro-producing-the-logs…
--
- Justin Azoff