Tools · Network tools · 18 / 24
Zeek: notices, weird events, and what you escalate
notice.log is Zeek's judgment. weird.log is a protocol oddity. Both are leads tied to a uid. A defender confirms them in conn.log before paging anyone, and treats a file-wide checksum weirdness as a capture problem.
Notice versus weird
A notice is a named conclusion Zeek's scripts decided to emit: a note and a message, plus the addresses and the uid when they have them. Which notices appear depends on the policy the sensor loaded. A lab VM and a production sensor will not emit the same set. Quote the note name and the Zeek version.
weird.log is lower level. It records things like a checksum failure, a gap, or a sequence that did not make sense, with a name and a uid. One weird name on one uid belongs with that connection's conn.log row. The same weird name on every uid belongs with the capture method.
What earns a person
Escalate a host or a service when a notice and the underlying log agree, and the agreement touches data or access the owner cares about. A conn.log fan-out of S0 plus a notice about that originator is a host to review. A single weird row you cannot tie to a uid yet stays in the case notes.
Do not escalate checksum weirdness that covers the whole file after you have already explained offload. Do not escalate an empty http.log on a TLS service. Do not paste notice messages that include lab secrets. The escalation names the host, the time, the note, and the uid. The logs stay in the case folder.
- Read the uid's conn.log row before you accept the notice wording.
- Policy decides which notices exist. Name the policy host in the ticket.
- File-wide checksum weirdness goes back to -C and the NIC, not to the application owner.
- A notice you cannot reproduce from conn.log, dns.log, or http.log is not ready to page.
A worked defensive case
notice.log on the lab sensor has one row whose message names 10.8.0.20 and a short window. conn.log for that window shows the S0 fan-out you already attributed to the inventory job, plus the single established session to 10.8.0.40:443. weird.log shows bad checksum names on nearly every uid, and the capture came from a NIC with checksum offload.
You escalate nothing about checksums. You send the owner the inventory-job note they already confirmed, with the notice name and the uid list attached. The 443 session stays on the application ticket. Two different severities stay in two different notes so the checksum noise cannot bury the job that needs to be turned off.
Where this is documented
Zeek's notice framework and the weird.log schema are in the script reference. The set of notes on a sensor is the local policy, which is site-specific. Conn::Info remains the check on anything a notice claims about a connection.
Use a host-only lab network, or a capture the owner already handed you. These commands read that file or record a single lab host. They are not a scan of the public internet.
Commands
zeek-cut -m ts uid id.orig_h id.resp_h note msg < /lab/zeek/notice.log
zeek-cut -m ts uid name < /lab/zeek/weird.log
Diagram
A lead that matches the log, and noise that does not
What you page on
Signal. A weird checksum name on every uid, from an offload NIC.
Check. The pattern matches the capture, not one application.
Action. Note -C and move on. Paging the app owner hides the real ticket.
Signal. A notice about 10.8.0.20, plus the S0 fan-out in conn.log.
Check. The uid and the window agree with the log.
Action. Tell the owner which job to disable. Attach the uid list.
Check yourself
1. bad checksum appears on almost every uid, and the NIC offloads checksums. What is the disposition?
2. A notice names 10.8.0.20 during the minute of the S0 fan-out, and conn.log shows that fan-out. What do you escalate?
3. The notice message happens to include a lab token. What goes in the page?