Interesting observation with ssh on non-ssh port

All,

I resolved to get monitoring of large amounts of outbound data (the exfiltrate and largeTx type scripts) working today. My test setup is two internal machines (192.168.1.). My hope was that I could just test scp'ing a file from a machine running bro. I haven't got any scripts to function, so I looked at the conn.log. Interestingly, the port I run ssh on doesn't show up. I see my connected sessions fine in ssh.log, but there's no trace of it in conn.log. This obviously explains why I couldn't get the large outbound transfer scripts working, but now I'm curious...is there a reason why this TCP session doesn't show up in conn.log? Running bro 2.2...thank you.

James

Did you close down the connection? Bro doesn’t log anything until the connection ends. In scripts though you could use the ConnPolling thing that Jon Siwek mentioned in another thread to monitor the connection in-flight. Typically I don’t recommend relying on the log events except for very simple tasks. Doing any sort of in-progress monitoring of connections is almost intrinsically not a simple task.

  .SEth

Hi Seth,

I absolutely did. I was originally scp'ing a file, then started to test with ssh'ing to the host and exiting out. Is there a way to debug this? I think I even compiled it for debugging :slight_smile:

James

You’re sure that your box was seeing the traffic you think it was? Also, if this is on a real network you want to be careful with building with debugging enabled because it can cause a large performance hit which can then cause it’s own problems.

  .Seth

Bah...the port I was listening on was a spanned port 8-| Actually looping in on itself...shut that off and now I see things just fine...sorry for the waste of bits on the list. Thanks Seth.

James

No immediate idea on why the TCP session isn’t showing in conn.log, but one thing to be aware of is SSH::skip_processing_after_detection. If you’ve redef’d that to true, then any large-transfer detection is bound to fail for SSH sessions. Generally, any connection on which the skip_further_processing() built-in function is called won’t have accurate size/packet counts.

- Jon

Thanks Jon I'll keep that in mind. Short answer was I'm an idiot :slight_smile:

James