[Bro-Dev] [JIRA] (BIT-1236) topic/jsiwek/flip-on-syn-ack

[Vlad Grigorescu]

Thanks, Jon.

Here's a PCAP with an example. I've anonymized the IPs, so it can be shared
publicly/used as a test if desired.

It does look like the first connection wasn't torn down in a completely
normal way - if I run just that connection through Bro, conn_state is S3,
and there are some missed bytes.

Unfortunately, this is a pretty common occurrence when we're being scanned
- traffic spikes, causing Bro to miss more bytes, leading to more of these
incorrect connections.

The specific issue is that the jump in seq numbers between the first and
second connection cause Bro to think that a lot of traffic was simply
missed. This leads to false positives with the SSH heuristic, since now the
byte total is over the threshold.

Digging into this, I realize it wasn't as closely related to this ticket as
I thought, so let me know if I should file a new ticket for this.

  --Vlad



On Mon, Aug 25, 2014 at 5:04 PM, Siwek, Jon <jsiwek at illinois.edu> wrote:

>
> On Aug 25, 2014, at 4:40 PM, Vlad Grigorescu <vlad at grigorescu.org> wrote:
>
> > Does it makes sense that following a connection teardown, if a SYN-ACK
> is seen, a new connection begins, instead of using the existing connection?
> I can probably grab a PCAP if necessary.
>
> Actually, I’m thinking it may already work like you expect in many
> “normal” situations.  One special case I can remember (there may be others)
> is that Bro may defer closing out a connection even if it sees the teardown
> control packets when it thinks it may be possible to fill in a content gap
> (i.e. it thinks there’s packets coming in out of order, but maybe in your
> case it’s just never seen at all).  If that doesn’t fit with what you saw
> and you’ve got a pcap you can send me, I can try to make sense of it.
>
> - Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140826/7ab7a99c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_ssh_8_1_14_anon.pcap
Type: application/octet-stream
Size: 7332 bytes
Desc: not available
Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140826/7ab7a99c/attachment.obj