Is there an equivalent of event connection_established for UDP? I.e., an
event that is raised once datagrams are seen in both directions for a given
4-tuple.
No, and I wouldn't be sure about the semantics of seeing something in
both direction as that's not required for UDP. What are you trying to
do?
Robin
I'd like to know whenever a new server appears on a network. Ideally,
this would be whenever a host calls listen() on a connection-oriented
socket or bind() on a datagram socket. In practice, it seems to work
well enough to track the responding hosts and ports of established
connections or datagram pseudo-connections where the "server" has
responded. This doesn't work for UDP servers that don't respond using
the same 4-tuple, but it works for DNS and a few other common UDP server
types.
I'd like to know whenever a new server appears on a network. Ideally,
this would be whenever a host calls listen() on a connection-oriented
socket or bind() on a datagram socket. In practice, it seems to work
well enough to track the responding hosts and ports of established
connections or datagram pseudo-connections where the "server" has
responded. This doesn't work for UDP servers that don't respond using
the same 4-tuple, but it works for DNS and a few other common UDP server
types.
If you can wait until the internal state of UDP "connections" in Bro times out due to inactivity (default of "udp_inactivity_timeout" variable is 1 min), would it work to handle the "connection_state_remove" event and check for a non-zero c$resp$size ?
- Jon
That would work ok for a protocol like DNS, but not as well when the
4-tuples are long-lived. It also makes IDS evasion really easy for a
custom protocol running over UDP.
If you can wait until the internal state of UDP "connections" in Bro times out due to inactivity (default of "udp_inactivity_timeout" variable is 1 min), would it work to handle the "connection_state_remove" event and check for a non-zero c$resp$size ?
That would work ok for a protocol like DNS, but not as well when the
4-tuples are long-lived. It also makes IDS evasion really easy for a
custom protocol running over UDP.
How about also handling "new_connection" and polling that connection periodically for a non-zero c$resp$size ? That may be more expensive, though.
The base/protocols/conn/polling.bro script provides a generic way to do polling via events, and an example use of it can be found in base/protocols/ftp/gridftp.bro.
- Jon
It would actually be useful to have a "new_udp_connection" (or so)
event that triggers only for new UDP flows. I don't think I'd tie the
bi-directionality in there, but that along with the polling could
work.
Robin