Is it possible for someone to establish an SSH session but the bro log not to show “auth_success” as true.
Thanks
Tim
Yes. A good example of this is if SSH compression is enabled.
I would hope that auth_success is set to "-" and not set to the
incorrect T or F state, but it's possible that there's some
server/client combination out there that's throwing off the detection.
If you are seeing such cases, please send a PCAP and I can look at
improving the detection.
--Vlad
Tim Desrochers <tgdesrochers@gmail.com> writes:
What I am seeing is “-“ but on successful connects from internal host to internal host I am seeing “success”
I am in the process of examining pcap and auth logs on the server at this moment to determine success or failure
Similarly I’ve seen SSH sessions not identified when SSH is multiplexed with other protocols on the same port; e.g. SSH and HTTP on port 80. Wish I had more time to help with detecting cases like this.
I've been working on that as part of https://bro-tracker.atlassian.net/browse/BIT-1521
There's a bug in the current known services policy that causes multiple protocols on the same port to not be logged to known_services.log, but they should still show up in conn.log as the proper service.
There is a slightly different but related issue in that if you send an http request to an ssh server or an ssh client banner to an http server, bro won't attach both analyzers to the connection. So, you'll get either an http log or an ssh log, but not both.
Nice, thanks for the explanation. I sometimes see this when working cases in ELSA as I always look for BRO_SSH entries. It’s the second case that I believe I'm seeing and I think Seth explained it to me a couple months back as well. Suricata picks them up, so it hasn't been a high priority for me to delve into the Bro analyzers. That and I haven't done any real C++ programming in a very long time though I wish I could.