Rate Limit Unauthenticated connections ?

[Darryl L. Miles]

I am seeing a recent increase in SSH harvesting attempts and brute 
forcing in the log of my system.


I'm interested in opening up some discussion around what OpenSSH can do 
itself to counter measure against:

* DoS attack where too many unauthenticated connections are open.  I'm 
not interested in stopping the professional saboteur but the casual 
script kiddie (to use IRC terms) from downloading the latest SSH 
harvesting program and running it from their limited internet connection.

* The reason why OpenSSH should actively have internal support (or call 
on the assistance where possible of other installed apps like tcpd) is 
that the SSH protocol is universally installed in thats it is simply not 
possible to put all my SSH servers behind a firewall or intrusion 
detection system since I also wish to provide the same protection of SSH 
service to my firewall too (which is also a Unix box running SSH).

* Any proposal in counter measures must administer themselves.



A simple algorithm:

* Restriction of maximum unauthenticated connections in the process of 
authenticating from the same IP address, like a scoreboard file ?  This 
is fast and simple to implement.  The action is to drop the connection 
(maybe with a last blert message before shutdown if the protocol allows 
that).  The whole scoreboard is reset to zero at SSH startup.

* Once the connection has successfully authenticated its score is taken 
off the score board.

* Ability to set the maximum connection level in the sshd_config.

* Ability to provide inclusion or exclusion IPv4/IPv6 prefixes subject 
to scoreboard in the sshd_config.  Enterprise users can disable the 
mechanism for their internal/trusted network.



A more complex algorithm:

* Temporary (time based) locking restrictions, this is based on actual 
login failure information, where each failed attempt racks up counter.  
Then over a set level counter measures are enabled.

* Counter decay cycle based on last failed attempt time and the counter 
value.

* The same configuration options possible here too as simple algorithm, 
IP address inclusion/exclusion.

* Possible counter measure can be configured in sshd_config.

* Counter measure 1: close the connection

* Counter measure 2 (where I'm trying to go with it all): if we have a 
history of too many failed logins then throw the dice.  If the dice say 
no, then let the IP try to login but even if he gives us a real and 
correct password we still dont let him in.  The probability of the die 
saying no increases with the failed login count.  This situation MUST be 
logged clearly.  If this was not found to cause any hardship to 
legitimate users and was considered safe enough to become the default 
SSH configuration then it would have the  far more important social 
effect of just stopping the script kiddies from even bothering to brute 
force SSH.  I do not know what the parameter levels should be set to so 
am really asking the community if as a whole its possible to achieve a 
social deterrent by technical means to this problem.  Which is a far 
better counter measure in itself.


Does what I propose simply move the problem somewhere else ?

Your feedback and slating are both welcome.

-- 
Darryl L. Miles