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] or [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 passwords. 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 probes. 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 Javier [1] http://www.k-otik.com/exploits/08202004.brutessh2.c.php or http://cgi.nessus.org/plugins/dump.php3?family=Default%20Unix%20Accounts [2] http://lists.sans.org/pipermail/list/2004-July/048718.html or http://www.securityfocus.com/archive/75/362662/2004-05-03/2004-05-09/0
Attachment:
signature.asc
Description: Digital signature