Dear all,
Do I need to do "./configure" with any parameter for installing python binding for Broker? I tried no parameter but the broker module cannot be find in python.
Thanks a lot.
Best,
Wenyu
Wenyu Ren
Ph.D. Candidate
Department of Computer Science
University of Illinois at Urbana-Champaign
I'd like to share an issue that could impact anyone using tool ports on an Arista in a port-channel to a Bro cluster. Upgrading to 4.20.x from 4.19 broke our symmetric hashing (fixable with a config change), creating a lot of half-duplex connections in Bro.
In 4.19, the hashing algorithm for output port selection in a port-channel could use either a layer 2 mode (MAC) or a layer 3 and 4 mode (IP and TCP/UDP). In 4.20, both modes can be used simultaneously, and both are enabled by default. During our upgrade, our layer 3 and 4 load-balancing policy was converted to use both modes. That broke symmetric hashing, and leading to many of the connections having the two sides of their flows sent to different Bro nodes.
I haven't established yet with Arista whether the problem is the MAC hashing or having both enabled simultaneously, but layer 2 mode is fairly useless for us anyway as we tap link between routers. Changing the hashing algorithm back to layer 3/4 only solved the issue for us.
Kay Avila
Senior Security Engineer, Cybersecurity and Networking Division
National Center for Supercomputing Applications (NCSA)
University of Illinois, Urbana-Champaign
P: (217) 300-1754 F: (217) 244-1987
Hi,
I'm researching ja3 and ja3s tls signatures.
With resumed tls connections there is no complete
handshake etc. Does it make sense to calculate a ja3
on resumed tls ?
Regards,
Daniel
Hi
I am using below script for port-knocking i am getting error
https://github.com/initconf/scan-NG/blob/master/scripts/check-port-knock.brohttp://try.bro.org/#/trybro/saved/292398
below part is getting error
if (orig !in Scan::known_scanners)
{
if (|likely_port_scanner[orig,resp]| ==
HIGH_THRESHOLD_LIMIT && high_threshold_flag )
{
result = T ;
}
else if (|likely_port_scanner[orig,resp]| ==
MED_THRESHOLD_LIMIT && medium_threshold_flag )
{
result = T ;
error in ././trybro.bro, line 115: unknown identifier Scan::known_scanners,
at or near "Scan::known_scanners"
Regards
Sunu
Hi
I am currently investigating an issue with http file extraction with file analyzer that very frequently I see missing_bytes in the file log which causes the file to be incomplete and fails extract the file nor generate a hash.
I am running bro in a virtual machine sniffing on a interface in promiscuous mode that's is on a virtual switch.
After examining a bunch of packet captures, I tracked the problem down to that when Bro sees out of order ACKs before actual packet, the problem with missing_bytes is observed.
This seems to me that there is no TCP reassembler Bro's documents indicated that the TCP analyzer for the HTTP analyzer (or file analyzer?), since reassembled TCP payloads are only delivered via a tcp_content event.
Does anyone have any information on how to make this work? Is it a configuration problem or...
Appreciate any tips that you may have thanks!
Hi All,
I'm using the latest zeek on alpine 3.8. In recent instagram tls traffic,
I see tls version unknown-64282. The resumed flag is set to true.
What is tls version unknown-64282.
Regards,
Daniel
There are a couple different entries in the Zeek reporter.log that I'm
not sure how to resolve (my Google-fu has failed me on these):
* {"ts":"2019-01-07T08:21:04.323061Z","level":"Reporter::ERROR","message":"string
with embedded NUL:
\u0022\u005cx00\u005cx00\u005cx00\u005cx00\u005cx00\u005cx00\u005cx00\u005cx00NOTIFY\u0022","location":""}
* {"ts":"2019-01-07T15:42:30.457678Z","level":"Reporter::ERROR","message":"software/Log::WRITER_ASCII:
count value too large for JSON: 10427193035649126500","location":""}
Could someone point me in the right direction on what could be causing
these, and how I can resolve the errors?
Thank you!
--
*Zander Work **|** Security Analyst **| **Office of Information
Security **|** Oregon State** University *
*A008 Kerr Admin Bldg **|** Corvallis, OR 97331 **| **Phone:
541-737-9800 *****
Hi All,
I had a recent case where MODBUS was reported in the known_services.log
file for the scanning attempts on port 502, and no connection being set-up.
I always thought that a known_service is logged when the complete handshake
is seen in the connection:
$ zcat known_services.22:00:00-23:00:00.log.gz | grep "128.175.10.187" |
grep "MODBUS" | more
1544756649.284460 128.175.10.187 502 tcp MODBUS
1544756677.105590 128.175.10.187 502 tcp MODBUS
$ zcat conn.22:00:00-23:00:00.log.gz | grep "modbus" | awk -F'\t' '{if ($5
~ /128.175.10.187/) print;}' | more
1544756649.284460 Coix4i2Hvzy3fHMFH5 118.26.141.219 3901
128.175.10.187 502 tcp modbus - - - S0 F
T 0 S 1 60 0 0 (empty)
worker-2-10
1544756677.105590 C1wLrc4pJoc30fJvL 118.26.141.219 1471
128.175.10.187 502 tcp modbus - - - S0 F
T 0 S 1 60 0 0 (empty) worker-4-5
Usually the number of entries logged in the known_services.log file ranges
between 900-2000 for an hour, but that day for a single hour it was
completely swamped by the MODBUS service logs for the heavy scanning on
port 502.
$ zcat known_services.22:00:00-23:00:00.log.gz | grep "MODBUS" | wc -l
96949
I am looking into the issue, but just wanted to share here if someone
already know about this and can provide any inputs, don't want to re-invent
the wheel :)
Thanks!
Fatema.
