This is related to this ticket: http://tracker.icir.org/bro/ticket/285
I am fairly lost on this, hopefully someone will have insight into the behavior. In the following snippet of code, there's a strange behavior (maybe intentional?) where a packet with SYN/ACK flags set and no other packets related to the connection are seen, the connection_established event will be generated.
if ( peer->state == TCP_ENDPOINT_SYN_SENT )
else if ( peer->state == TCP_ENDPOINT_INACTIVE )
// If we were to ignore SYNs and
// only instantiate state on SYN
// acks, then we'd do:
This only seems to be true when the connection compressor is disabled though. The connection compressor *seems* to prevent this effect. I'll include steps to reproduce the problem here and I'll attach the example tracefile to this email...
===POLICY SCRIPT (test.bro)===
event connection_established(c: connection)
print fmt("gah! there shouldn't be a connection established (%s)", id_string(c$id));
===END POLICY SCRIPT===
Here's the output with a connection established that shouldn't happen:
[seth@Blake build (master)]$ ./src/bro -C -f "ip" -r connection_established-problem.trace test use_connection_compressor=F
1285716061.336160 weird: unsolicited_SYN_response
gah! there shouldn't be a connection established (188.8.131.52/3072 > 184.108.40.206/http)
Here's the (lack of) output with the connection compressor enabled:
[seth@Blake build (master)]$ ./src/bro -C -f "ip" -r connection_established-problem.trace test use_connection_compressor=T
[seth@Blake build (master)]$
I also disabled the checksum validation because the TCP header has an invalid checksum in the packet for some reason.
Sorry for the long email, but any thoughts on the behavior of the sans connection compressor behavior?
connection_established-problem.trace (100 Bytes)