zeek and tcpdump packet mismatch

Zeek
1

Hi,
I am facing an issue while running zeek on an interface and writing it to a file. The almost same issue I am getting in case of tcpdump as well. tcpdump is showing 10000 packets received but when I am trying to write in pcap file it is showing only 10-12 packets and zeek is showing 2-4 packets. I checked that many of thsese packets I am receiving in the interface are having invalid checksums, I have tried after disabling it both NIC ( ethtool -K eth0 rx/tx off), and also tried to pass -C argument in zeek and --dont-verify-checksums in tcpdump, but the issue persists.

Anything I am missing here?

##################################################################################
TCPDUMP without writing to file

[root@root]# tcpdump -i eth0 --dont-verify-checksums -n
14:31:04.993181 IP 10.10.0.33.57626 > 10.20.0.51.ssh: Flags [.], ack 248560, win 12922, options [nop,nop,TS val 1405576758 ecr 231651561], length 0
14:31:04.993183 IP 10.10.0.33.57626 > 10.20.0.51.ssh: Flags [.], ack 248656, win 12922, options [nop,nop,TS val 1405576758 ecr 231651561], length 0
14:31:04.993185 IP 10.10.0.33.57626 > 10.20.0.51.ssh: Flags [.], ack 248736, win 12922, options [nop,nop,TS val 1405576758 ecr 231651561], length 0
14:31:04.993187 IP 10.10.0.33.57626 > 10.20.0.51.ssh: Flags [.], ack 248832, win 12922, options [nop,nop,TS val 1405576758 ecr 231651561], length 0
14:31:04.993190 IP 10.10.0.33.57626 > 10.20.0.51.ssh: Flags [.], ack 248896, win 12922, options [nop,nop,TS val 1405576758 ecr 231651561], length 0
14:31:05.682176 IP 10.10.0.33.57626 > 10.20.0.51.ssh: Flags [P.], seq 1:49, ack 248896, win 12922, options [nop,nop,TS val 1405577447 ecr 231651561], length 48
^C
5984 packets captured
6024 packets received by filter
40 packets dropped by kernel

################################################################################
TCPDUMP with writing to file
[root@root]# tcpdump -i eth0 --dont-verify-checksums -w test.pcap
dropped privs to tcpdump
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C8 packets captured
10 packets received by filter
0 packets dropped by kernel

##########################################################################
RUNNING ZEEK and dumping to a file (same behavior with -w option as well)

[root@root]# /mnt/DPI/zeek/broker/bin/zeek -Ci eth0 -w Test.pcap
listening on eth0

^C1697639492.006355 received termination signal
1697639492.006355
4 packets received on interface eth0, 0 (0.00%) dropped, 0 (0.00%) not processed

Thanks.
Biswa

2

Sorry this got overlooked for a couple of months :frowning:. What’s happening is that you’re capturing your own SSH session. When you display the output in the first example, the mere act of printing it to the terminal results in more SSH traffic, which in turn gets captured, resulting in more SSH traffic, etc. When you instead write it to a file or have Zeek process it, there’s no terminal output and thus no cycle of increasing SSH traffic.

3

Hi @Vern, Thanks, you pointed it correctly, there were ssh packets visible in the terminal. But, I was trying to highlight that tcpdump is writing 10 packets but zeek was able to write only 4 packets at the same time in the pcap file. However, I want to understand that. does zeek write all protocol packets it sees even if the protocol is not enabled inside zeek? and is it recommended to use zeek pcap writing for all packets while few protocols are actually loaded.
The idea is to store all packets coming to the wire using zeek ids for forensics/analysis to pcap file and log anomalies from protocols/scripts enabled inside zeek ids.
Thanks
Biswa

4

There are at least two considerations. The most basic is that unless you were running tcpdump and zeek on exactly the same traffic feed, it could be the case that there simply were different numbers of packets seen on the wire between the two runs. If it was an identical feed, then it wouldn’t surprise me if there are certain types of packets that zeek ignores (because they’re not using an L3 protocol it knows about) but tcpdump still records, which leads to the question of just what’s in the tcpdump pcap that zeek missed.

1 Like
5

Thanks @Vern , it was same traffic feed. Maybe they all were not L3 packets thats why zeek didn’t write them. But is it recommended to use this pcap writing in zeek, while processing for enabled protocols? Will it impact in the zeek packet processing performance?
Secondly, will zeek write all L3 packets which it knows even if that protocol is not loaded or enabled in zeek?
Thanks
Biswa

6

I unfortunately haven’t touched that code in a long time, so I’m not sure I’m up to date. Back when it was first added, at least, the point was to record every packet that Zeek analyzed. You’ll need to experiment to see just what that means. Given you have a twin traffic feed, that should be straightforward enough to do with a parallel tcpdump. Regarding processing performance, yes it will affect performance, as writing the pcap file is I/O intensive.