Wednesday, November 13, 2019

What is ‘Weird’ in Zeek?

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.

Most of these logs correspond to common network protocols, but there are a few interesting exceptions. The most intriguing exception may be the Zeek log called ‘weird’. The weird.log records unusual or exceptional activity that might indicate malformed connections, traffic that doesn’t conform to a particular protocol, malfunctioning or misconfigured hardware, or even an attacker attempting to avoid/confuse a sensor.

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:

1. DNS_RR_unknown_type:

Defined: The condition that causes this weird type to get triggered and logged is defined in src/analyzer/protocol/dns/

Cause: If you look into the 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/

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.

3. inappropriate_FIN

Defined: The condition that causes this weird type to get triggered and logged is defined in src/analyzer/protocol/tcp/

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:
bad_ICMP_checksum – defined in src/analyzer/protocol/icmp/
TCP_Christmas – defined in src/analyzer/protocol/tcp/

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!

Tuesday, November 12, 2019

ZeekWeek 2019 - Summary and Slides

The global community of Zeek developers and users gathered together in Seattle last month, October 8-11, for the annual ZeekWeek (formerly BroCon) event. 

171 network security professionals representing 84 organizations travelled from all over the world to share ideas and knowledge of Zeek.

This year’s event consisted of 2 Zeek training sessions, 17 presentations, lightning talks, a community Q&A panel discussion, and more.

In case you missed this year’s event, here is a list of all the talks as well as all the slides that were made available to organizers. The full agenda and talk descriptions can be found on the website. (Please note: There will be a message that states this event has already happened; just hit the escape key and it will go away. Also, videos coming soon!)


8 October 2019 - Pre-conference Training

(Training slides available for attendees only)
  • Intro to Zeek, Keith Lehigh, Indiana University
  • Making Sense of Encrypted Traffic, Matt Bromely and Aaron Soto

9 October 2019 - ZeekWeek Day 1 - Sessions

  • Opening Remarks, Keith Lehigh, Indiana University (Slides)
  • Keynote: The Threats are Changing, So are We as Defenders, Freddy Dezure, Founder and former Head CERT-EU (Slides)
  • eZeeKonfigurator: Web Frontend for the Config Framework, Vlad Grigorescu, ESnet (Slides)
  • BZAR – Bro/Zeek ATT&CK-based Analytics and Reporting, Mark Fernandez, Lead Cybersecurity Engineer The MITRE Corporation (Slides)
  • Run, Zeek, Run!, Jim Mellander, Cybersecurity Engineer, ESnet (Slides)
  • DNSSEC Protocol Parser - A Case Study, Fatema Bannat Wala, Security Engineer, University of Delaware (Slides)
  • Profiling in Production, Justin Azoff, Corelight (Slides)
  • Identifying Small Heavy-Hitter Flows Using Zeek to Optimize Network Performance, Jordi Ros-Giralt, Managing Engineer, Reservoir Labs (Slides)

10 October 2019 - ZeekWeek Day 2 - Sessions

  • 7 Years with Zeek on Commodity Hardware, Michal Purzynski. Engineer, Mozilla Corporation (Slides)
  • Zeek 3.0.0 and beyond, Robin Sommer, Corelight, CTO and Co-Founder (Slides)
  • Baseline the Network with Zeek, Adam Pumphrey, Consultant, Nimbus LLC (Slides)
  • Without U There is No CommUnity, Amber Graner, Zeek Community Director, Corelight (Slides)
  • Zeek - Incident Response and Beyond, Aashish Sharma, Lawrence Berkeley National Lab
  • Encrypted Things: Network Detection and Response in an Encrypted World, TJ Biehle, Sr. Technical Account Manager, Insight (Slides)
  • Lightning Talks (Various presenters)
    • Zeek Based IPS (Slides)
    • Challenge: Zeek on a large amount of low power sensors, Alex Bortok (Slides)
    • Using BRO [Zeek] to tattle on other tools, Patrick Cain, The Cooper-Cain Group. Inc. (Slides)
    • Contributing to Zeek (How to do a Pull Request), Tim Wojtulewicz, Corelight (Slides)
    • Dynamite-NSM, Open-source project for network traffic analysis with Zeek, Suricata, Flow Data and ELK, Oleg Sinitsin, Dynamite.AI (Slides)
    • eZeeKonfigurator - notice config, Michael Dopheide, ESnet (Slides)
    • How I became a Zeeker & Why I Zeek, Jeff Atkinson (Slides)
  • Using Zeek for SSL Research, Johanna Amann, Senior Researcher, ICSI / Corelight / LBL (Slides)

11 October 2019 - ZeekWeek Day 3 - Sessions

  • New Implementation of Zeek Dictionary to use Less Memory, Jason Lu, Senior Staff Software Engineer, Gigamon (Slides)
  • Introduction to Zeek Script Writing, Seth Hall, Corelight, Chief Evangelist and Co-Founder (No slides were used for this talk; live scripting)
  • Visualizing, Analyzing and Filtering Zeek Events using a Graphical Frontend and OpenGL, Nick Skelsey, Security Engineer, Secure Network (Slides) (Demo Vids)

Thoughts on the event

"ZeekWeek 2019 was another great opportunity to catch up with colleagues across both R&E and industry. It's always inspiring to see what people have been doing with Zeek over the last year." ~ Michael Dopheide, ESnet
“Great experience sharing knowledge and collaborating with the community in this year's ZeekWeek, so much useful content and great place to “zeek out” with fellow Zeekers!” ~ Fatema Bannat Wala, Security Engineer, University of Delaware
“ZeekWeek2019 provided a great opportunity to share knowledge in pursuit of defending networks. Without the people, Zeek is just a tool.” ~Keith Lehigh, Indiana University and Chair, Zeek Leadership Team
“We use Zeek, you should too!” ~ Aashish Sharma, Lawrence Berkeley National Lab and Zeek Leadership Team Member
"It's amazing to see everything this community is doing with Zeek." ~ Robin Sommer, Corelight, CTO and Co-Founder; Zeek Leadership Team Member

Many Thanks and Much Appreciation

Zeek events, such as this year’s ZeekWeek, are only possible through the generous support of the Zeek community, its sponsors and hosts. A huge shoutout and “THANK YOU” to all out sponsors and speakers!!

Helpful Links and information:

Getting Involved: If you would like to be part of the Open Source Zeek Community and contribute to the success of the project please sign up for our mailing lists, join our IRC Channel, come to our events, follow the blog and/or Twitter feed. If you’re writing scripts or plugins for Zeek we would love to hear from you! Can’t figure out what your next step should be, just reach out. Together we can find a place for you to actively contribute and be a part of this growing community.

About Zeek (formerly Bro): Zeek is the world’s leading platform for network security monitoring. Flexible, open source, and powered by defenders.