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