# \[JIRA\] (BIT-1236) topic/jsiwek/flip-on-syn-ack
**URL:** https://community.zeek.org/t/jira-bit-1236-topic-jsiwek-flip-on-syn-ack/3239
**Category:** Development
**Tags:** development
**Created:** [August 25, 2014, 9:40pm UTC](https://community.zeek.org/t/jira-bit-1236-topic-jsiwek-flip-on-syn-ack/3239 "2014-08-25T21:40:11Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Vlad\_Grigorescu1](https://community.zeek.org/u/Vlad_Grigorescu1)
#### Post date: [August 25, 2014, 9:40pm UTC](https://community.zeek.org/t/jira-bit-1236-topic-jsiwek-flip-on-syn-ack/3239/1 "2014-08-25T21:40:11Z")
This ties into something I had noticed recently. Certain scanning tools like to use the same source port per destination IP (I imagine to cache portions of the TCP header). During these scans, multiple TCP connections occur. Bro saw traffic that had:
- A connection that was setup and torn down as expected (conn\_state == “SF”)
- A few minutes pass
- A second connection that was setup and torn down as expected, _except_ that the first SYN was missed - either by Bro or upstream loss.
Bro considered these the same connection.
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.
–Vlad
---
### Author:  [@Siwek\_Jon](https://community.zeek.org/u/Siwek_Jon)
#### Post date: [August 25, 2014, 10:04pm UTC](https://community.zeek.org/t/jira-bit-1236-topic-jsiwek-flip-on-syn-ack/3239/2 "2014-08-25T22:04:00Z")
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
---
### Author:  [@Jim\_Mellander](https://community.zeek.org/u/Jim_Mellander)
#### Post date: [August 25, 2014, 11:45pm UTC](https://community.zeek.org/t/jira-bit-1236-topic-jsiwek-flip-on-syn-ack/3239/3 "2014-08-25T23:45:28Z")
It would be nice to have an optional hook to the script-level, which could signal Bro as to which side is the originator, if the 3-way handshake was missed. There are a number of cases where we could use local site knowledge to definitively identify originator & responder.
---
### Author:  [@Vlad\_Grigorescu1](https://community.zeek.org/u/Vlad_Grigorescu1)
#### Post date: [August 26, 2014, 10:02pm UTC](https://community.zeek.org/t/jira-bit-1236-topic-jsiwek-flip-on-syn-ack/3239/4 "2014-08-26T22:02:26Z")
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
[bug\_ssh\_8\_1\_14\_anon.pcap](https://community.zeek.org/uploads/short-url/5W3ioi7vFXt2RjyxHA1dCfQYHwH.pcap) (7.16 KB)
---
### Author:  [@Siwek\_Jon](https://community.zeek.org/u/Siwek_Jon)
#### Post date: [August 26, 2014, 10:49pm UTC](https://community.zeek.org/t/jira-bit-1236-topic-jsiwek-flip-on-syn-ack/3239/5 "2014-08-26T22:49:40Z")
> 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.
As a workaround you may be able to filter out such cases by checking whether connection records report missing data and a history string with more than one handshake?
> 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.
Yeah, make a ticket.
- Jon
---
### Author:  [@system](https://community.zeek.org/u/system)
#### Post date: [May 6, 2022, 3:42pm UTC](https://community.zeek.org/t/jira-bit-1236-topic-jsiwek-flip-on-syn-ack/3239/6 "2022-05-06T15:42:00Z")