Bug#314645: ssh password mappings result
On Tue, Jun 21, 2005 at 09:10:20AM -0700, Greg Webster wrote:
> Completely agreed....I don't want to know the passwords. What I'd like
> to see is, over the long term, are these scans making more attempts at
> non-system, first-name valid accounts that do exist than random chance
> should allow, and a clear indication that more attempts at valid
> accounts are made than for non-valid accounts. Once that's sorted out,
> we can decide if we really have a problem.
>
> Perhaps a small script as part of the prerotate section of logrotate of
> auth.log would do it...something like:
>
> prerotate
> grep 'Failed password' auth.log|awk '{print $9}' >> /tmp/sshscan.log
> endscript
This may or may not be more suitable; it excepts "invalid user" lines:
grep -v 'Failed password for invalid user' auth.log |grep 'Failed password' |awk '{print $9}'
and logs should probably go to /var/log/, lest the machine get
rebooted.
> (with no rotation of /tmp/sshscan.log happening) ($9 may be different on
> some machines)
>
> Leaving that in place for a few weeks on an oft-scanned system should
> give us a list of accounts that have been attempted...then all that
> needs to happen is a 'uniq -c' of /tmp/sshscan.log and then determining
> whether the non-system accounts most often hit are valid or not.
|sort |uniq -c |sort -n, as before, yes. Is there any reason this
can't be done by zgrep /var/log/auth.log*?
And, how do you intend to determine the threshold which defines how
often an account "should" be scanned? Are you going to watch if a
given host "refines" its user list, or are you allowing for the scan
to switch to another host (or become distributed)?
Isn't is sufficient to watch for a massive number of attempts for a
given valid account over a small time period? (For a sufficiently
sensitive definition of "massive", and possibly iterated over all
valid accounts).
> > > > Justin
> On Tue, 2005-06-21 at 11:58 -0400, Justin Pryzby wrote:
> > Sure, but what do you plan to do with the data? Rather, how do you
> > plan to analyze it? It seems to me that this could be done without
> > knowing what passwords are tried.
> >
> > The data lined up pretty well last night, when I discovered the first
> > ssh scan; I had to remove some blank lines from /etc/ssh-log (probably
> > from my own testing), remove my own password from the bottom (I was
> > scp'ing files from the machine), and remove some other cruft I had
> > left behind (from testing that password authentication is forced).
> >
> > But it will probably not line up nearly as well once, for example,
> > auth.log gets rotated, or I log in from an uncommon machine which
> > doesn't have RSA access, and I mistype my password.
> >
> > On Mon, Jun 20, 2005 at 10:15:18PM -0700, Greg Webster wrote:
> > > Hi Justin,
> > >
> > > Part of what I'd like to (dis)prove is that they are making a 'second
> > > run' from this or another machine to hit that accounts that it believes
> > > are valid...any chance you could keep your testing up for a while?
> > >
> > > On Mon, 2005-20-06 at 23:15 -0400, Justin Pryzby wrote:
> > > > Included is a list of usernames and corresponding passwords used in an
> > > > ssh scan I observed. It indicates to me that it is trying
> > > > statistically common (aka dumb) passwords on common usernames; I see
> > > > no evidence of an attempt to measure timings to discover valid
> > > > accounts.
> > > >
> > > > Starred accounts are invalid users.
Reply to: