Good evening,
My Google-fu is failing me right now, so I wanted to reach out to the list to see if anyone has ever attempted to use Zeek to detect packets with no TCP flags set?
In Snort land, a signature would look something like this:
alert tcp $HOME_NET any → $EXTERNAL_NET 443 (msg:“LOCAL Port 443 and no TCP flags set”; flags:0; classtype:misc-activity; sid:7;)
Before anyone asks, I’ll just ahead and state that “yes Virginia, these packets do really exist in the real world…” (though rare).
Thanks in advance,
-E
I tried feeding Zeek two pcap files.
The first was a single TCP SYN packet with the flags nulled out. Zeek complained that the pcap only contained TCP control packets. The single entry in the conn.log file had a conn_state of OTH.
The second was a single TLS connection over TCP. I nulled out the TCP flags of a single encrypted data packet (after the TCP and TLS handshakes had completed) and ran it through Zeek. Zeek processed the stream normally, with correct files, conn, x509, and ssl log entries, as if the packet I changed had the appropriate flags.
Could you say more about the null-flag packets you are referring to? Do you know what they are generated from?
-AK
Zeek is mainly connection oriented, rather than packet oriented. However, you could write a policy that allows for detection of these packets using the raw_packet, new_packet, or tcp packet events, bearing in mind the caveats in the documentation, particularly the expense of triggering events at the packet level.
If there is a particular concern about these packets (covert communication channel, perhaps?), it would be of interest.
Hope this helps,
Jim
This seems like a job for Bro’s signature engine: https://docs.zeek.org/en/stable/frameworks/signatures.html
Here’s an example: http://try.bro.org/#/trybro/saved/303957
The signature I used is visible in the tcp.sig tab, copying it here for posterity:
signature tcp-syn-no-flag {
ip-proto == tcp
header tcp[12:2] & 4095 == 2
event “Flag-less SYN”
}
Someone should double-check my logic there.
–Vlad
I agree with Vlad. His response made me realize I only sent my response to Erin. Sending to the list for everyone’s benefit.
Try looking for conn.log lines with a conn$state of “OTH” and a conn$history value containing a ‘D’ or a ‘d’, indicating the connection carried data.
-AK