As you can see, at 11:27, Bro thinks 100 hosts were
5060/udp. But the conn.log and flowscan data only show one host being
scanned. Any ideas why this alert thinks 100 hosts are being hit when
it is one host with a single SYN?
It might be the ConnectionCompressor, but I'm not 100% sure what the conn.log
semantics are when the ConnectionCompressor is used. Robin, will know this.
FYI, from ConnCompressor.cc:
// The basic model of the compressor is to wait for an answer before
// instantiating full connection state. Until we see a reply, only a minimal
// amount of state is stored. This has some consequences:
// - We try to mimic TCP.cc as close as possible, but this works only to a
// certain degree; e.g., we don't consider any of the wait-a-bit-after-
// the-connection-has-been-closed timers. That means we will get differences
// in connection semantics if the compressor is turned on. On the other
// hand, these differences will occur only for not well-established
// sessions, and experience shows that for these kinds of connections
// semantics are ill-defined in any case.
// - If an originator sends multiple different packets before we see a reply,
// we lose the information about additional packets (more precisely, we
// merge the packet headers into one). In particular, we lose any payload.
// This is a major problem if we see only one direction of a connection.
// When analyzing only SYN/FIN/RSTs this leads to differences if we miss
// the SYN/ACK.
// To avoid losing payload, there is the option cc_instantiate_on_data:
// if enabled and the originator sends a non-control packet after the
// initial packet, we instantiate full connection state.
// - We lose some of the information contained in initial packets (e.g., most
// IP/TCP options and any payload). If you depend on them, you don't
// want to use the compressor.
// Optionally, the compressor can take care only of initial SYNs and
// instantiate full connection state for all other connection setups.
// To enable, set cc_handle_only_syns to true.
// - The compressor may handle refused connections (i.e., initial packets
// followed by RST from responder) itself. Again, this leads to differences
// from default TCP processing and is therefore turned off by default.
// To enable, set cc_handle_resets to true.
// - We don't match signatures on connections which are completely handled
// by the compressor. Matching would require significant additional state
// w/o being very helpful.
// - Trace rewriting doesn't work if the compressor is turned on (this is
// not a conceptual problem, but simply not implemented).
Gregor Maier gregor(a)icir.org
Int. Computer Science Institute (ICSI) gregor(a)icsi.berkeley.edu
1947 Center St., Ste. 600 http://www.icir.org/gregor/
Berkeley, CA 94704