Scanner and victim reverse condition in scan.zeek

Zeek
1

Hello,

I frequently see a lot of scans from external hosts and some of them are with only TCP-Ack flag ("H" in history) set packets, but these packets appear to have been alerted as Port_Scan activities originated from internal hosts possibly due to the following code snippet in scan.zeek script. Is there any reason for this default code that reverses the network direction if "H" or "s" flag seen in the TCP flag ?

event connection_attempt(c: connection)
  {
  local is_reverse_scan = F;
  if ( "H" in c$history )
    is_reverse_scan = T;

  add_sumstats(c$id, is_reverse_scan);
  }

Thank you

2

Hi Eiji,

Is there any reason for this default code that reverses the network
direction if "H" or "s" flag seen in the TCP flag ?

This is actually a bit subtle and might be a bug.

"H" means a SYN-ACK from the originator -- not a pure ACK. Zeek considers the sender of the first packet in a new connection the originator, but might revise this later if the protocols involved allow it to understand things better. TCP's header flags usually allow it to do so. That said, Zeek treats a connection start via SYN-ACK specially and doesn't immediately flip endpoints, exactly because it might be a scan. The code you're flagging is in a connection_attempt event, which only occurs when an originator has sent a SYN or a SYN-ACK and the other side never responded. Therefore I think the reverse-scan logic in the snippet you're showing is faulty: Zeek correctly labels the originator the sender of the SYN-ACK -- it must be the scanner, since the other side never speaks.

The code you're referring to for "s" is different. I assume you mean the connection_rejected handler in the same script. "s" means a pure SYN from the responder. In a connection_rejected handler, one end attempted the connection, and the other sent a RST. If for whatever reason Zeek considers the SYN to have come from the responder, that's most likely incorrect and so you'd indeed want to reverse endpoints.

I'm reading the tea leaves a bit here ... I think Seth originally wrote this, so he might know better.

Best,
Christian

3

I looked into this a while ago when I was writing simple-scan.. the
logic in scan.bro around 'reverse scans' is completely wrong.
simple-scan skips all of that stuff, it's not reliable.