bugtraq - Re: `tattle` -- automatic reporting of SSH brute-force attacks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20050607090923.GA2284@hanuman.astro.su.se>
Date: Tue, 7 Jun 2005 11:09:24 +0200
From: Sergio Gelato <Sergio.Gelato@...ro.su.se>
To: "C.J. Steele, CISSP" <coreyjsteele@...oo.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: `tattle` -- automatic reporting of SSH brute-force attacks

* C.J. Steele, CISSP [2005-06-04 21:46:07 -0700]:
> Inspired by a post to the SANS Intrusions list, I have written `tattle`
> to automate the reporting of SSH brute-force attacks.  

As if we didn't have enough spammers already...

Your tool has several obvious flaws:

1. A single attempt does not a brute-force attack make. You should be counting
entries from a given source and only trigger when a certain (configurable?)
threshold is exceeded. (If you collect logs for several hosts on the same
subnet, you may also want to count how many hosts are being targeted from the
same source at approximately the same time.)

2. You are relying on untrustworthy information to decide where to send your
report. The source hosts for SSH brute-force attacks have usually been broken
into themselves (which is what makes them worth reporting in the first place),
and if they happen to be DNS servers for their domain or IP address range the
attacker can influence your script's calculation of where to send the report.

3. Your regular expression patterns are too loose (they should be anchored,
could use [0-9]+ instead of [0-9]*, and so forth).

4. The code to get the reporting address will give incorrect results in many
cases. In particular, it risks annoying those people who include in their
record's remarks: a request to send abuse reports only to a certain address.
Also, it may be in violation of some whois servers' AUPs, which tend to ban
bulk automated processes from accessing the database. In any case, the
information in whois records is a lot easier for humans to handle than for
programs to parse reliably. You could do slightly better by using abuse.net's
database (once you've figured out how to compute the domain name from the IP
address), but even then you should have a human inspect the report before it 
is sent.

When I report these attacks, I often send in only a subset of the logs. I'm
more comfortable telling the world "yes, I have an account named root" than
leaking information about the status of other account names. Besides, a single
event often generates thousands of entries in my logs. (The noisiness of
these attacks is my main reason for adding the offending IP ranges to the
hosts.deny list whenever practical.)

In short: please do not fully automate this task. The preparation of the
report can be software-assisted, but a human should review (and, when
appropriate, suppress or amend) every message before it is sent.