By: Fatema Bannat Wala, Security Engineer, University of Delaware
As you probably know, Zeek transforms network traffic into real-time logs used by threat hunters, incident responders, and network operators.
Not all ‘weird’ traffic is malicious. But when Zeek finds network communication that don’t comply with RFC standards and definitions, that can be a sign of something interesting and worth exploring. And it might or reveal information about activity that is hard to notice in the traffic, otherwise. It is important to keep in mind, though, that most of the logged information won’t be anything unusual; large networks typically exhibit many of the underlying activities triggering Zeek’s ‘weird’ records.
Types of Weird
There are MANY types of weirds defined in Zeek, at least 200 seen triggered in network traffic. Common ones include:
- DNS_RR_unknown_type
- Dns_unmatched_msg
- Dns_unmatched_reply
- fragment_with_DF
- bad_ICMP_checksum
- DNS_Conn_count_too_large
- possible_split_routing
- inappropriate_FIN
- TCP_Christmas
- data_after_reset
- truncated_header
- data_before_established
- SYN_seq_jump
- SYN_with_data
- TCP_ack_underflow_or_misorder
- DNS_truncated_RR_rdlength_lt_len
- line_terminated_with_single_CR
- DNS_RR_length_mismatch
- connection_originator_SYN_ack
To check the weirds triggered in your environment run following command:
2,603,914 DNS_RR_unknown_type
2,160,812 possible_split_routing
2,092,811 inappropriate_FIN
753,398 fragment_with_DF
18,343 bad_ICMP_checksum
The above example is showing the statistics of the most triggered weirds in a university environment over a period of 24 hours.
Where to find Weirds?
Sometimes it’s very helpful to know the cause of ‘weird’ records while analyzing the weird.log file. This knowledge can help analysts categorize a ‘weird’ as benign or malicious. Unfortunately, there’s no comprehensive documentation of all weirds; they are defined at various locations throughout the source code of Zeek. The conditions that trigger the weird notices are mainly defined in the following locations:
- In source code of Zeek IDS (in .cc files)
- In script land, in base/ policy/ folders (in various .zeek scripts)
When triggered by network traffic, weird notices are logged into a separate log file called “weird.log” in Zeek. The logging of different weirds can be controlled by base/frameworks/notice/weird.zeek script, which DOES NOT consist all the weirds that are defined in Zeek. It ONLY has a subset of weirds showing what action to take when they get triggered. Hence any additional weird, which is not already found in weird.bro, can be defined and the action for the weird can be controlled by the script.
Investigating Weirds
Following are a few examples of how to go about investigating the triggered weirds in the network:
Defined: The condition that causes this weird type to get triggered and logged is defined in src/analyzer/protocol/dns/DNS.cc
Cause: If you look into the dns.cc code, the condition that triggers this weird is for the RR types that are currently not parsed in Zeek.
Remediation: If the RR type ID recorded in the weird notices belong to the valid RR types defined for DNS protocol, then those notices can be safely ignored, or the RR types parsing support can be written in Zeek to support the parsing for those RR types.
2. possible_split_routing
Defined: The condition that causes this weird type to get triggered and logged is defined in src/analyzer/protocol/tcp/TCP.cc
Cause: When Zeek doesn’t see the other side of the connection, signifying possible split routing.
Remediation: Look for the possible asymmetric routing or split routing caused by any misconfigurations in the network. It might also indicate traffic not properly getting load balanced (symmetric hashing) between the zeek sensors and the different packets belonging to the same connection stream going to different Zeek workers.
Defined: The condition that causes this weird type to get triggered and logged is defined in src/analyzer/protocol/tcp/TCP.cc
Cause: When Zeek sees a packet with a FIN set during a connection, which does not comply with RFC for TCP/IP standard.
Remediation: Sometimes this weird is tied up with the inappropriate_FIN, which is discussed earlier, and remediating that weird also results in the suppression of this weird. Zeek has many traps to catch the similar weird activity that is related to each other. Hence getting one weird remediated can result in few other related weirds to disappear from the logs.
Here’s some information about a few other weirds that might potentially signify malicious traffic or other problems:
TCP_Christmas – defined in src/analyzer/protocol/tcp/TCP.cc
Reason: bad_ICMP_checksum / TCP_Christmas weird notices are seen to be triggered by the scanners, sweeping the range of IPs on the network.
Remediation: These weird notices don’t appear to be noisy, depending on your network, and blocking the offending IPs might be potential action to protect the network. For bad_ICMP_checksum, one should be careful with the blocking action, as this notice is seen triggered often by the traceroutes or actions taken for network troubleshooting, and blocking the source IPs might cause the adverse results. Generally having a threshold of notices per host for this type of weird is a good idea for taking any action against the offending IPs.
I have a lot more to tell you about weird logs in the future, so stay tuned for future installments in this series!
RSS - Posts