Final or last event generation for a connection analyser

Zeek
1

Hi All,
Is there any way or generate the “The last event “ for a packet or connection I.e this event will be invoked after all related events are fired. The requirement is to store all parsed protocol attributes collected from different events and in this final event one can dump or send (using broker) all collected connection related info.

Thanks
Biswa

2

That would be connection_state_remove.

3

Thanks @Vern ! but will connection state remove be called per packet ? For eg if a request packet and response packet both seen then connection is established and it will removed after certain timeout for that protocol. But I think what we get in zeek script is also view of the half connection as well I.e. when zeek sees request for that connection it will generate an event and I think it will not wait for response packet and when zeek sees the response, it will generate response event. Is my understanding correct ?
Thanks
Biswa

4

Zeek is connection-oriented, not packet-oriented. It generates events reflecting the stream of packets seen for a connection - or for just one side of a connection, if that’s all that’s seen and analyzers for the protocol can make some sense of it. In either case, the very last event generated will be connection_state_remove, which appears to correspond to the “final event” that you asked about. If you don’t think it’ll work for your use case, then you’ll have to provide more particulars about just what you’re trying to do.

1 Like
5

Thanks @Vern ! I thought the events are fired when zeek sees any side traffic and not wait for the other side packet to come, like in case of dns request and response , communication happens on the same connection and there will be two events, one for request and another for response, now connection state remove will be invoked when the connection is expired , that may take time in case of tcp, right? But events are fired instantly when request or response side of traffic is seen, so I am not sure if waiting for state remove event would be good idea or not ?
Please clarify!

Thanks

6

Events are generated when enough information has been seen to allow the internals to conclude that the event has occurred. For DNS request/response, this is usually per-packet (but in fact might not be even for DNS, if the transaction occurs via DNS-over-TCP). connection_state_remove occurs when the event engine is about to forget entirely about a given connection, so it’s a last-chance-to-act event. Whether waiting for it is a “good idea or not” depends on what you’re trying to achieve - I’d need more specifics about your goals to be able to advise on that further.

7

Thanks @Vern ! Got your point , I thought that way only. My use case is very simple … I have to respond as soon as I get enough information for a connection to react upon it. So you can assume there is python daemon running which has subscribed to zeek events and do some additional logic on the parsed attributes we get from aggregating the events. Now there are two options here …
Eg. protocol X has 5 events support .
A packet or connection is seen from client to server

  1. Call Publish to the events generated one by one as they are fired from zeek. So let’s assume event1,3,5 generated for packet 1, and we call publish to X/event1, X/event3, X/event5 topic one by one , then aggregate these in python daemon and run a logic to generate a new log (attack or anomaly) based on the informations from these 3 events using some logic in zeek script or python broker.
  2. If there is a final event just like connection state remove then aggregation can be done in zeek script itself for all 3 events and then send one event from the zeek to python on X/final topic . Benefit is less number of message passing between zeek and python for a packet. However if this event generation is delayed then the response to any attack or vulnerability will get delayed as well.

So my question is how to make the zeek python communication efficient and instant for such usecases ehere multiple events generated for a packet or connection coming from a direction

Thanks
Biswa

8

Well, connection_state_remove is the final event that’s available. You can use other end-of-activity events like connection_finished for TCP connections and udp_reply for UDP transactions. Those will occur sooner if they occur, but they won’t occur in circumstances when a TCP connection lacks a terminating handshake, or a UDP packet is sent but no reply occurs. Whether that’s appropriate for your setup will depend on just what analysis the Python code performs.

9

@Vern true, for half connections we will not get connection finished or udp reply I think. So python code will fail to detect any dos type of activity from one side if we subscribe to such tcp udp events. Most probably connection state removed will be helpful for my case and in worst case I will need to send all events generated for a packet !

Thanks
Biswa