a GOOD idea to harden OpenSSH!

[nagygabor88]

I'm writing here, because the ssh dev list says:

Mail Delivery Status Notification (Delay)
[Status: Error, Address: <openssh-unix-***@mindrot.org>, ResponseCode 451, Temporary failure, please try again later.]

So:

What is you're opinion about the next idea? Please write down ++/-- thoughts:

it's against brute-force attacks on sshd:

if a user wants to connect to an ssh server then he have to wait a couple of seconds, then he can write his passphare.
the "couple of seconds" is defined in the sshd config, e.g.: 2 seconds
the method musn't show that the user have to wait 2 seconds to write his passphare.

important: the user could type in his password before the 2 seconds, but the sshd will only process the chars that has been typed after 2 second!

effect:

in this way, if a brute force "robot" comes, and tries to log in with a generated password it will likely input that in a matter of miliseconds, ok.
BUT: the sshd will only give back that, that the password is bad. - because it only processes the password that has been typed 2 seconds after the "type you're password" appear on client side.

if this idea would spread, then the attackers would "adapt", and wait e.g.: 5 seconds before their robot gives the generated password to sshd. - BUT: this will take them too much resources, and the brute-force will be far less effective.

so can this be a feature in sshd? :O

What do you think?

Thank you!

[Christian Grunfeld]

hi,

a couple of years ago I submit an idea like yours !
My idea was that ssh server waits up to ...say 2^N seconds between
failed logins to show again the login prompt, being N the Nth try !

So the first login cames instantly. After a failed login I have to
wait 2 seconds, after a second failed login I have to wait
4s......8s.......16s........32s........2^N seconds !

This will not disturb a normal human login with a couple failures but
makes a robot to wait with a potential law.

I dont know why but mi idea didnt like anybody

Cheers !

Post by nagygabor88
Mail Delivery Status Notification (Delay)
if a user wants to connect to an ssh server then he have to wait a couple of seconds, then he can write his passphare.
the "couple of seconds" is defined in the sshd config, e.g.: 2 seconds
the method musn't show that the user have to wait 2 seconds to write his passphare.
important: the user could type in his password before the 2 seconds, but the sshd will only process the chars that has been typed after 2 second!
in this way, if a brute force "robot" comes, and tries to log in with a generated password it will likely input that in a matter of miliseconds, ok.
BUT: the sshd will only give back that, that the password is bad. - because it only processes the password that has been typed 2 seconds after the "type you're password" appear on client side.
if this idea would spread, then the attackers would "adapt", and wait e.g.: 5 seconds before their robot gives the generated password to sshd. - BUT: this will take them too much resources, and the brute-force will be far less effective.
so can this be a feature in sshd? :O
What do you think?
Thank you!

[Joseph Spenner]

Subject: a GOOD idea to harden OpenSSH!
Date: Wednesday, March 30, 2011, 12:19 PM
if a user wants to connect to an ssh server then he have to
wait a couple of seconds, then he can write his passphare.
the "couple of seconds" is defined in the sshd config,
e.g.: 2 seconds
the method musn't show that the user have to wait 2 seconds
to write his passphare.

This can already be similarly done using iptables, with entries such as:
$IPTABLES -N SSH_CHECK
$IPTABLES -I INPUT -p tcp --dport 22 -m state --state NEW -j SSH_CHECK
$IPTABLES -A SSH_CHECK -m recent --set --name SSH
$IPTABLES -A SSH_CHECK -m recent --update --seconds 180 --hitcount 5 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
$IPTABLES -A SSH_CHECK -m recent --update --seconds 180 --hitcount 5 --rttl --name SSH -j DROP

What this does: If I get more than 5 hits within 180 seconds, block them for 180 seconds.

[Aaron Toponce]

Post by Christian Grunfeld
This will not disturb a normal human login with a couple failures but
makes a robot to wait with a potential law.

That really isn't the job of OpenSSH, but more for PAM or some other
authentication module. Further, there is already software to prevent robots
from getting into your server, such as Netfilter, TCPWrappers and
Denyhosts.

Interesting idea, but something like delaying logins really belongs
elsewhere in the system.

--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o

[Eric Jaw]

Why not utilize OpenVPN to tunnel to the network and allow only local
connections made to the ssh server?

It solves all my problems.

1.) Great idea.
2.) This could be a massive impediment to legitimate automated connections. Part of a process that would make large numbers of connections per unit of time will be slowed unnecessarily.
3.) There are similar techniques implemented in many of today's authentication mechanisms, but they only slow the retries after the first attempt fails. This effectively remedies the above problem while still accomplishing the goal.
Jon Ward, CEPT, CISA
Vulnerability Testing Technical Lead
Syntel, Inc.
-----Original Message-----
Sent: Wednesday, March 30, 2011 2:20 PM
To: OpenSSH list
Subject: a GOOD idea to harden OpenSSH!
Mail Delivery Status Notification (Delay)
if a user wants to connect to an ssh server then he have to wait a couple of seconds, then he can write his passphare.
the "couple of seconds" is defined in the sshd config, e.g.: 2 seconds
the method musn't show that the user have to wait 2 seconds to write his passphare.
important: the user could type in his password before the 2 seconds, but the sshd will only process the chars that has been typed after 2 second!
in this way, if a brute force "robot" comes, and tries to log in with a generated password it will likely input that in a matter of miliseconds, ok.
BUT: the sshd will only give back that, that the password is bad. - because it only processes the password that has been typed 2 seconds after the "type you're password" appear on client side.
if this idea would spread, then the attackers would "adapt", and wait e.g.: 5 seconds before their robot gives the generated password to sshd. - BUT: this will take them too much resources, and the brute-force will be far less effective.
so can this be a feature in sshd? :O
What do you think?
Thank you!

[Lamont Granquist]

you can already use fail2ban to accomplish this kind of thing.

the original idea i think is somewhat terrible in a multi-user
enterprise-y kind of environment since you'll wind up telling users that
they have to wait 2 seconds before entering their passphrase
constantly. for your home server it might work, but you can always
setup public keys or OTP pretty easily as well, in addition to fail2ban.

you can also use pam_tally to only allow 6 failed passwords in a row
before locking the account. i run the cronjob to unlock all the
accounts every 30 mins or so, which only allows a velocity of 12 guess
per hour on a single account, while not requiring users with locked
accounts to call up a helpdesk.

Post by Joseph Spenner

Subject: a GOOD idea to harden OpenSSH!
Date: Wednesday, March 30, 2011, 12:19 PM
if a user wants to connect to an ssh server then he have to
wait a couple of seconds, then he can write his passphare.
the "couple of seconds" is defined in the sshd config,
e.g.: 2 seconds
the method musn't show that the user have to wait 2 seconds
to write his passphare.

$IPTABLES -N SSH_CHECK
$IPTABLES -I INPUT -p tcp --dport 22 -m state --state NEW -j SSH_CHECK
$IPTABLES -A SSH_CHECK -m recent --set --name SSH
$IPTABLES -A SSH_CHECK -m recent --update --seconds 180 --hitcount 5 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
$IPTABLES -A SSH_CHECK -m recent --update --seconds 180 --hitcount 5 --rttl --name SSH -j DROP
What this does: If I get more than 5 hits within 180 seconds, block them for 180 seconds.

[Mike Ramirez]

Post by Lamont Granquist
you can already use fail2ban to accomplish this kind of thing.
the original idea i think is somewhat terrible in a multi-user
enterprise-y kind of environment since you'll wind up telling users that
they have to wait 2 seconds before entering their passphrase
constantly. for your home server it might work, but you can always
setup public keys or OTP pretty easily as well, in addition to fail2ban.
you can also use pam_tally to only allow 6 failed passwords in a row
before locking the account. i run the cronjob to unlock all the
accounts every 30 mins or so, which only allows a velocity of 12 guess
per hour on a single account, while not requiring users with locked
accounts to call up a helpdesk.

I've had good experiences with bfd[1] which scans logs for invalid login
attempts per user, after X attempts, the ip is banned. The length of the ban
is variable (30 minutes was good enough to stop repeated attacks).

Bonus, it kept the logs clean.

Mike

http://www.rfxn.com/projects/brute-force-detection/