Connection/flow not detected in new_connection but in connection_state_remove

Zeek
,
1

I was trying to print new connection detected from the below pcap file

The connection/flow from src port 20000 to dst port 20000 is not detected in new_connection (total 10 connections detected) but connection_state_remove showing that connection/flow (total 11 connections). Why so?

Regards,
Subhajit

2

Hmmm when I use the following script it prints 11, 11. This is with Zeek 5.0.5.

global new_c = 0;
global remove_c = 0;

event new_connection(c: connection)
	{
	++new_c;
	}

event connection_state_remove(c: connection)
	{
	++remove_c;
	}

event zeek_done()
	{
	print new_c, remove_c;
	}
3

Yes, sorry the question is incomplete . The issue is coming when I published the new_connection data to a python module using broker framework. Locally inside zeek it is printing 11 new conn and 11 in remove conn, but when in the same script I connect to a peer and sending the new_connection data, the first connection information is somehow lost and not received in the python script. I have started the python listener first then starting zeek with the pcap and zeek scripts . I am suspecting that first event is getting fired before peer is connected (peer connect code inside zeek_init()) and event new connection func is also in the same script from where I am publishing that event.
Thanks

4

Hello @biswa ,

I am suspecting that first event is getting fired before peer is connected (peer connect code inside zeek_init()) and event new connection func is also in the same script from where I am publishing that event.

You’re most likely on the right track here. What you can do is to suspend_processing() within zeek_init() and then call continue_processing() within Broker::peer_added when the process reading the pcap observes the Python side showing up as peer.

There’s a glitch with this approach: If you call suspend_processing(), the network_time() will end-up being the current time instead of pcap time. I’ve very recently proposed to change this. If you are confused/surprised by the observed timestamps, this might be why. Feel free to provide details of your use-case or chime in on the PR.

This is fairly advanced Zeek/Python/broker integration use-case, nice! :slight_smile:

5

Another peculiarity that might be relevant here is the fact that Zeek will always process the first packet to initialize network time. Events generated by this packet might be handled before broker is peered.

6

Oh! Thanks for that! This seems a bit random and “peculiarity” seems closer to “issue”. The mentioned PR actually changes this and at least Zeek’s test suite appears unaffected while it makes @biswa’s use-cases rather difficult. Maybe we get let go of that with 6.0.