largeTx.bro alerts on any outgoing Txs over X bytes. If of sufficient size it sends an email alert.
get.bash uses tshark to extract captured Security Onion FPC packets from /nsm/sensor_data/so-OLN-eth0/dailylogs/2014-01-19.
I received an email alert saying that 1.1.1.1 transmitted over 1GB of information to 2.2.2.2. Therefore I went to the FPC directory above to extract this communication to see what it was. The extracted content was ~3.5MB in size.
I've tested this with several large file uploads and have gotten consistent and accurate results with all tests. Therefore I'm confused as to how this alert was generated.
Is this an intermittent bug possibly or am I not understanding something?
The email alert I received from Bro 2.2 on Security Onion with all the latest patches is included as well. The duration is odd as well. I've received a handful of similar alerts for large transfers and very short durations.
Thank you,
Brian Kellogg
largeTx.bro (1.77 KB)
alert-email.txt (343 Bytes)
get.bash (307 Bytes)
Yes and that is the intention. If you look at the email alert in the email you will see a report size of over 1GB and the Bro script only send emails on any Tx over 50MB.
Thank you,
Brian Kellogg
largeTx.bro alerts on any outgoing Txs over X bytes. If of sufficient size it sends an email alert.
..
I received an email alert saying that 1.1.1.1 transmitted over 1GB of information to 2.2.2.2. Therefore I went to the FPC directory above to extract this communication to see what it was. The extracted content was ~3.5MB in size.
Message: Orig transmitted 1056737769 bytes to resp. Duration 0.092641 sec. Connection UID Cma6473thsxripFj9k.
Can you post the full conn.log entry for this connection? That might help
explain what is going on.
grep Cma6473thsxripFj9k conn.log
should find the exact entry.
1390143300.845103 Cma6473thsxripFj9k 1.1.1.1 3326 2.2.2.2 80 tcp - 0.092641 1056737769 0 RSTOS0 T 0 SaR 2 88 1 40 (empty) - US so-eth0
Thank you,
Brian Kellogg
SaR in the history field is in common for both of the erroneous email alerts I received today.
Thank you,
Brian Kellogg
Here is the conn log entry for the other one:
1390143593.839386 C3miqNnYs6FBw74c5 3.3.3.3 4235 4.4.4.4 80 tcp - 0.086147 1594489093 0 RSTOS0 T 0 SaR 2 88 1 40 (empty) - US so -eth0
Thank you,
Brian Kellogg
Security Analyst; IT Governance, Risk, and Compliance
500 Paul Clark Drive, Olean, NY 14760
T: (716) 375-3186 | F: (716) 375-3557
So, with the field names, that is:
ts 1390143300.845103
uid Cma6473thsxripFj9k
id.orig_h 1.1.1.1
id.orig_p 3326
id.resp_h 2.2.2.2
id.resp_p 80
proto tcp
service -
duration 0.092641
orig_bytes 1056737769
resp_bytes 0
conn_state RSTOS0
local_orig T
missed_bytes 0
history SaR
orig_pkts 2
orig_ip_bytes 88
resp_pkts 1
resp_ip_bytes 40
Which shows that bro calculated that there were 1056737769 bytes based
on sequence numbers, but only actually saw 88 bytes.
I think simply changing $size to $num_bytes_ip will fix your problems.
Ah, thank you for the clarification. I was obvsiously misunderstanding how that field was calculated.
Thank you,
Brian Kellogg
> 1390143300.845103 Cma6473thsxripFj9k 1.1.1.1 3326 2.2.2.2 80 tcp - 0.092641 1056737769 0 RSTOS0 T 0 SaR 2 88 1 40 (empty) - US so-eth0
So, with the field names, that is:
[snip]
duration 0.092641
orig_bytes 1056737769
resp_bytes 0
conn_state RSTOS0
local_orig T
missed_bytes 0
history SaR
[snip]
Which shows that bro calculated that there were 1056737769 bytes based
on sequence numbers, but only actually saw 88 bytes.
I think simply changing $size to $num_bytes_ip will fix your problems.
That's probably a decent workaround.
Another option would be to only trigger on connections that were fully
established - with conn_state of SF (possibly also RST0 and RSTR) - as
those should have the "most reliable" byte counts.
I think the problem in Brian's case comes from this not being a normally
established / torn down connection. conn_state RSTOS0 implies Bro saw
an incomplete connection attempt be torn down by an RST (by the orignal
sender, which is odd, and history SaR means the receiver sent not a
SYNACK, and not nothing, but a bare ACK, which is odder still... but
that is a story for another day*).
It could be argued that Bro should "know" that for certain failed /
incomplete connection types, ACK/SEQ math can be unreliable (maybe it
already does for some), and that SaR is a candidate for that (maybe that
has already been argued; there's probably good cases to be made both
ways).
[ *Snip esoteric ramble about the 4 way handshake, etc. ]
Thanks,
Hank Leininger <hlein@korelogic.com>
D24D 2C2A F3AC B9AE CD03 B506 2D57 32E1 686B 6DB3
This is actually a bug in Bro's handling of odd tcp sessions and it would be great to get a packet capture so we could fix this and work it into our test suite.
.Seth