Syslog

Syslog: SSH Login Analyzer 0.2

Overview

An example of what can be done with the generic client is a tool that extracts (ssh) login information from a centralized syslog server, and correlates it looking for cross-host attacks. There is no need to focus exclusively on SSH as a media, but it tends to be the most commonly used method of accessing hosts remotely.

The general design is as follows:

The basic idea is that a series of hosts using a central syslog server (syslog-ng), which tends to be useful for many other types of large scale analysis as well. A script (in this case written in perl) reads the syslog data and generates appropriately formatted bro pre-events. which look something like:

ssh_login double=1108696916 addr=128.55.128.251 addr=128.55.128.157 string=operator string=publickey

This string is passed to the generic client which process it into a bro event, which is then transmitted over the network to the bro instance. The policy described here is an example of a login analyzer.

Details
There are six separate tests that are done on logins. They are:

Name	Description
LoginFailSrc	The number of logins from a source IP exceeds a given threshold. This is a coarse identifier of problems.
LoginFailPair	The number of failed logins between two IP addresses has exceeded a given threshold. This value is unrelated to LoginFailSrc.
LoginFailAccount	The number of failed individual accounts from a single IP address has exceeded a given threshold.
LoginFailAccountPair	Same as above, except that a pair of IP address' is used.
LoginFailDict	The number of failed tries for a single account between two IP's (ie of the form: IP->account@IP) has exceeded a count. This is used to look for dictionary attacks.
LoginAfterFail	This flags accounts that have a successful login after a series of failures. Tends to be noisy.

One unusual complication for dealing with authentication analysis is the notion of a postponed login. This is a byproduct of PAM authentication and can result in an interesting problem. Using PAM, you can get a series of failed authentication messages before the final successful message:

Feb 11 20:10:14 baz sshd[29121]: Failed publickey for test from 128.55.1.1 port 1774 ssh2
Feb 11 20:10:14 baz sshd[29121]: Failed publickey for test from 128.55.1.1 port 1774 ssh2
Feb 11 20:10:14 baz sshd[29121]: Postponed publickey for test from 128.55.1.1 port 1774 ssh2
Feb 11 20:10:14 baz sshd[29121]: Accepted publickey for test from 128.55.1.1 port 1774 ssh2

If there is no corrective action, a series of successful authentications can result in a false positive for login failures! This problem is corrected via the postponed_ssh_login() event.

In addition to the syslog.bro, the framework for a general user-id checker is being put in place via user-check.bro. It creates three classes of user:

User Type	Description
Informational	An account that is seen often and is worth filtering on to remove it from reports or logs.
Suspicious	Accounts that you should expect to never see such as 'toor' or 'lp'
DeadManWalkin	Accounts assigned to former employees or known hostile entities. The difference between this and 'Suspicious' is arbitrary, but sometimes useful.

The use of user-check rather than login.bro (and it's list of hot users) is done since there are new classes of id's being used such as CN's attached to certificates which may require special handling. Rather than expanding login.bro to functionality that it was not designed to perform, it seemed like a better idea to move user identification functionality into a new module.

Download

syslog.bro 0.3

user-check.bro 0.1