[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PAM tarpit module for repeated SSH login attempts

On Wed, Oct 20, 2004 at 11:50:07AM +0200, martin f krafft wrote:
> Well, since you implemented it already, why not make it
> configurable. I think per-IP makes more sense. If an IP tries 50
> times to guess my root password, I should not only try to stop it,
> I should also not be naive and let it try the same thing on other
> accounts.

I have only briefly reviewed the current code and I agree with Martin that
it should be configurable, even though, IMHO, blocking per-IP might make
sense (in some, but not all, scenarios) while blocking per user does not
usually make sense.

[ now to the lengthy explanation of that IMHO, BTW I'm not trying to bash
your idea, which might be useful in some scenarios ]

Consider the following (intranet) scenario:

Shell server A         ---> Shell server B
[Student server in          [Post-graduate student server in the same 
a University                 University]
[Company X Shell server    [Shell server for users in group Y of 
for all users]              Company X]

A has user accounts and B has a accounts for a subset of those users (maybe
even sharing password authentication through an LDAP database or other
directories or with different accounts and passwords). If you block by IP,
a single user in A can DoS all legitimate login attempts from A to B just
by connecting to _any_ (legitimate) account and providing wrong passwords.

If you block by user, user Alice in A can block user Bob in B 
(regardless of where he connects from) just by sustaining invalid password 
attempts at B with 'Bob' as his (fake) username. Bob will not be able to 
connect until Alice stops doing that.

If you limit by IP _and_ username. Then user Alice can block user Bob from 
connection to B from A with the scenario above, but the Bob could connect 
from a different host X. However, that doesn't stop Alice to make use of A 
to try to password-guess other users, so usefulness might be limited (think 
Alice = Worm)

Now consider the following (internet) scenario:

Any Host ---> Server B

If you block by user, _any_ host can make fake illegitimate access to B as 
user 'Bob' and Bob would be blocked regardless of where he is trying to 
connect from. This could actually be done in a DDoS way, since the user is 
blocked regardless of what system attempts the username/password.

If you block by IP, a host that is trying to gain access to B as user 'Bob' 
will be blocked. Bob will be able to connect from other hosts (as long as 
it's a different server).

As designed (per-user tarpit), your tarpit becomes a DoS for legitimate 
users, regardless of how you look at it.

If you are trying to block systems that are constantly bugging you with 
scans I would actually try to look at it from a different POV. These 
remote scanning engines come in two ways:

- use common system accounts in shell servers (root, ftp, info, system,
admin, test...)  and try all possible passwords to gain access

- use dictionary based accounts (common names: 'alice', 'bob', 'joe') and
try some passwords (login=password) to gain access

To tarpit remote password/login attempts I think it would be best 
if you just tarpited remote attempts for _invalid_ users which I believe 
you are currently not accounting for. Notice that even if there are known 
user accounts there is a slim chance that your system might have one of 
those (unless you are asking for trouble), so you actually get more 
attempts for invalid users that attempts for valid users with wrong 

Try taking a look at how these password-scanners are programmed, see [1] 
(maybe [2] and similar recent threads can give insight on this issue)

For this scenario, it would make sense (for a system exposed in the
Internet, and _maybe_ for an internal system) to have a tarpit that would
tally based on the IP address of the remote system which is using
semi-random users and attempting passwords to gain access. After all, they
are trying to take advantage of finding a legitimate user between thousands
of illegitimate users through a SSH connection. 

Also, some vulnerabilities in SSH implementations could be use to 
retrieve the valid list of usernames (vs. those tested in a dictionary 
attack) due to timing or different responses for valid and invalid users. 
If you check only for _invalid_ usernames you would tarpit those too.

You _could_ make an exception with the root user (since it will be a valid
user in your system _and_ will be used in those attempts) and add it to the
'invalid' users list (after all you don't allot root logins through SSH and
that is a common default configuration in most systems nowadays). After
all, most scanning engines will try it as well.  But make sure you always
have a legitimate user that can connect and cannot be DoSed with the
scenarios I described above.

Notice that, if you do this, attackers can just as well distribute the 
scanning so your system does not get hit by the same engine more than say, 
10 times, but gets hit (with different systems doing the scan) with 10000 

Actually, you might be better off if you just don't expose your SSH server 
to the Internet and block with a 'default DENY' rule only allowing access 
to known legitimate systems. If you can't do that, then you might be better 
off moving your SSH server to a non-standard port and thus making it more 
difficult for probes to find it out.

Just my 2c


[1] http://www.k-otik.com/exploits/08202004.brutessh2.c.php
[2] http://lists.sans.org/pipermail/list/2004-July/048718.html

Attachment: signature.asc
Description: Digital signature

Reply to: