add conn entries for all tunnels and differentiate from non-tunnel conns #3916
Comments
For this we would need to keep load-balancing in mind: While the inner connections will be local to a single worker, the encapsulating tunnel might be seen and thus logged on multiple workers. |
You implied this, but there's a difference between Zeek monitoring/observing a Geneve/VXLAN tunnel being used between two hosts (in which case you might not want to collapse src ports - it might not be a mirroring use-case) or Zeek receiving all monitored packets over VXLAN/Geneve and src ports being flow keys. @rsmmr mentioned a config option for the latter a few times, maybe if we determine the destination IPs of the "Zeek system", observe tunneled traffic towards it and some option is enabled, only then collapse tunnel connections. This is somewhat off-topic, but for mirroring only setups, I'm wondering if a packet source that just listens directly on a UDP port (recvmmsg() and SO_REUSEPORT for loadbalancing 🤞) could be an interesting experiment. |
I like the idea. A UDP socket could even allow zeek to start without special privileges. Are you thinking that plus SO_ATTACH_REUSEPORT_EBPF or something to handle load balancing different half-flows to the same worker? What about mirroring protocols that don't use UDP (erspan uses GRE, for example)? |
|
@ckreibich mentioned that it would be useful to have pcaps for testing, a good place to start is the existing tunnel pcaps under A quick categorization for reference (I may have missed some):
|
Currently, many tunnel types do not create conn entries. I believe the root of this issue is #3915 and if that behavior is resolved, this issue would be mostly resolved. Currently, VXLAN and GENEVE tunnels get entries in the conn log (since they are UDP-based), but GRE and IP-in-IP do not. This can be especially confusing since the tunnel_parents for connections in these non-UDP tunnels have a uid, but no associated conn entry. I also am not seeing a simple way to differentiate conn entries that belong to tunnels from connections that have not been identified as tunnels (it may be useful to exclude tunnels from some calculations to avoid double-counting the traffic, for example).
I am proposing that we add a field to the conn log to allow filtering out sessions that contain other connections (maybe a boolean named
is_tunnelor something similar?). I am also proposing that we track these sessions as a 3-tuple in #3915. I think this issue is a superset of #3378.There are also some special cases that we might want to consider for tunnels:
For UDP based tunnels like VXLAN or GENEVE, I think it would be best to ignore the src/dst ports for session matching, as it is not actually part of the tunnel session but rather used like a flow-specific key to allow ECMP on flows within the tunnel. So, a GENEVE session could actually consist of
host-a:*->host-b:6081andhost-b:*->host-a:6801, however I'm unsure of the best way to handle this in zeek. It won't make a difference in cases where these tunnels are used for mirroring purposes, but if bidirectional traffic exists there will be a separate tunnel for each direction (this may or may not be an issue, though - edit: could there be more bugs like #1991?).GRE has a concept of a tunnel key to differentiate different sessions between two endpoints, however since zeek isn't really exposing the key I think it would be reasonable to ignore that special case for now (there would be no loss of functionality), although I suppose the 4-byte key could also be encoded into orig_p/resp_p somehow.
The text was updated successfully, but these errors were encountered: