TCP idle timer expiry

Zeek
1

Hi,

If the tcp connection is idle for some time, the connection_state_remove
event handler is getting called.
So the subsequent packets in the same connection doesn't get logged.

How can I increase the tcp idle time out? The increase in the timer is also
not the best solution.
Is there a way where the packets gets logged even after BRO removes the
connection from the table?

Thanks,
Dhanesh.

2

Jaya Dhanesh wrote:

Hi,

If the tcp connection is idle for some time, the connection_state_remove
event handler is getting called.
So the subsequent packets in the same connection doesn't get logged.

How can I increase the tcp idle time out? The increase in the timer is also
not the best solution.

You can reconfigure several timer values such as:

redef tcp_SYN_timeout = X secs;
redef tcp_attempt_delay = X secs;

redef tcp_inactivity_timeout = X mins;
redef udp_inactivity_timeout = X secs;
redef icmp_inactivity_timeout = X secs;

which might help out some. See heavy-analysis.bro for a better list.

Is there a way where the packets gets logged even after BRO removes the
connection from the table?

You will get a *new* connection for post-timed out data if the pcap
expression allows for ACK flagged packets to be seen (such as 80/tcp
with the http analyzer loaded). If not, then the FIN/RST ought to be
picked up as an additional connection.

If your configuration is not seeing much in the way of traffic, then it
is possible to turn the timeout values quite high. They have been tuned
to their current values to prevent state explosion for busy sites.

scott

3

Could someone explain what tcp_attempt_delay is used for? It seems that
it may be relevant to a script problem that I am experiencing, where a
'new_connection' event is occurring 5 seconds after the packet is
received (an unanswered SYN), 5 seconds being also the default value of
tcp_attempt_delay - so I am drawing a (possibly unwarranted) connection
between the value of tcp_attempt_delay and the time delay I am experiencing.

Is there perhaps a different event that I should be looking at, or can
this value be turned to zero without negative effect? - I need to
respond immediately to an incoming packet.

The application is a custom 'catch-and release' blocking script. We
block a host when it scans, then unblock after an interval of
quiescence, to preserve a working set of currently threatening hosts.
When a host that was unblocked as much as sends a single packet, we want
to immediately reblock. This, of course, requires immediate response -
waiting for a 5 second interval is unacceptable.

On an older version of Bro, the new_connection event was triggered
immediately on receipt of the first packet, and the 'catch-and-release'
mechanism worked correctly, now we seem to have this 5 second delay.

Thanks in advance.

4

This might be an (unintentional) artifact of the connection
compressor. I'll look into it.

Robin