Question on quick start documentation SSH:Login example.

Zeek
1

Hi,

Sorry for directing such a simple question to the mailing list - but
I'm really stuck and would appreciate your help.

I am running 2 separate instances of Bro (on separate hardware):
1. Bro 2.2 on FreeBSD 10
2. Bro 2.3 on FreeBSD 10

I am following the Quick Start documentation found here:
http://www.bro.org/sphinx/quickstart/index.html

I can't get the deployment customization example on "SSH:Login" to work.

I have performed the following:
1. Checked my installation is working.
2. Checked my email (mailto) is working.
3. Checked my networks.cfg includes my test SSH server and excludes my client.
4. Checked for previous posts on the issue.

Here is the code that is to be written into local.bro (only change was
the IP Addresses):
<snip>
const watched_servers: set[addr] = {
     192.168.1.100,
     192.168.1.101,
     192.168.1.102,
} &redef;

hook Notice::policy(n: Notice::Info)
    {
    if ( n$note == SSH::SUCCESSFUL_LOGIN && n$id$resp_h in watched_servers )
         add n$actions[Notice::ACTION_EMAIL];
    }
</snip>

Thank you,
Nithen

2

Looks like the quickstart is a bit off here..

That used to use SSH::Login but was changed to SSH::SUCCESSFUL_LOGIN,
but SSH::SUCCESSFUL_LOGIN is a Intel::Where and not a Notice::Type.

There's no ssh login notice anymore, so I don't think there is an easy
fix here to accomplish the same thing.

3

That documentation is not correct anymore, sorry about that. Will see about getting it fixed, but I put an example at [1] that should work to accomplish the same thing. The “SSH:: heuristic_successful_login” event is somewhat delayed, so just be aware of that if you’re looking for immediate feedback to check whether it’s working. And another gotcha is that the event only triggers after a certain amount of data is transmitted so just logging in/out real quick may not be detected. (I’m realizing this example is no longer that straightforward and probably doesn’t belong in the quick-start guide anymore).

- Jon

[1] https://gist.github.com/jsiwek/2a7692aa9f24e197ca9c

4

Thank you Jon and Justin. I really appreciate your help!

Jon, I could not get your script working - so I took a step back to
check my installation. I wanted to confirm that my default scripts
work.

I setup the following lab:

Kali Linux -> Bro SPAN -> Metasploitable

Using: FreeBSD + Bro 2.3 (compiled from source)

Test: trigger /usr/local/bro/share/bro/policy/protocols/ssh/detect-bruteforcing.bro

Verified: loaded_scripts.log (script is loaded), ssh.log (ssh login
attempts there).

So here is an extract of the ssh.log:
<snip>
1407355776.833081 CNjybf25kbwTIpD9D6 192.168.88.2 58904 192.168.88.101 22 undetermined INBOUND SSH-2.0-MEDUSA_1.0 - - -
1407355784.647680 CGYsSAwShJeTcT2t8 192.168.88.2 58905 192.168.88.101 22 undetermined INBOUND SSH-2.0-MEDUSA_1.0 - - -
</snip>

I checked the threshold in the Bro script:
<snip>
const password_guesses_limit: double = 30
</snip>

I hit the SSH server over 500 incorrect root logins - however no alerts noted.

Any ideas on where I should start investigating? Do you require more
information?

Thank you,
Nithen

5

From the script:

# Generate the notice.
NOTICE([$note=Password_Guessing,
     $msg=fmt("%s appears to be guessing SSH passwords (seen in %d connections).", key$host, r$num),
     $sub=sub_msg,
     $src=key$host,
     $identifier=cat(key$host)]);
}]);

Would that be in the ssh.log or the notice.log?

James

6

Thanks James, I checked both (actually all logs) and mail -> my novice
assessment was notice.log to answer your question - am I correct?

N

7

Thanks James, I checked both (actually all logs) and mail -> my novice
assessment was notice.log to answer your question - am I correct?

N

8

Good call on checking. Per the html:

http://www.bro.org/sphinx/scripts/policy/protocols/ssh/detect-bruteforcing.bro.html

It looks like unless it's redefined, these should show up in notice.log...but I'm a noob, so someone smarter then me on this list should be able to verify that.

James

9

The “undetermined” is saying it doesn’t even have a guess as to whether the ssh log in failed or was successful so either type of analysis you’ve tried so far won’t notice anything interesting happening because they’re only concerned about ssh logins with a status of “success” or “failure". I suggest trying to read scripts/base/protocols/ssh/main.bro and understand the criteria it uses to flip the login status to either “failure” or “success”, then try to look at conn.log to see which criteria aren’t being met.

- Jon

10

This is where I twist Vlad's arm hard to finish his work on his rewritten SSH analyzer so that we can get rid of my crummy success determiner for SSH connections. His new one appears to do a greatly improved job at determining success and failure for logins.

  .Seth