Mailing List Archive

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 !



2011/3/30 nagygabor88 <nagygabor88@zoho.com>:
> I'm writing here, because the ssh dev list says:
>
> Mail Delivery Status Notification (Delay)
> [.Status: Error, Address: <openssh-unix-dev@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!
>
>

--- On Wed, 3/30/11, nagygabor88 <nagygabor88@zoho.com> wrote:

> From: nagygabor88 <nagygabor88@zoho.com>
> Subject: a GOOD idea to harden OpenSSH!
> To: "OpenSSH list" <secureshell@securityfocus.com>
> 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.

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.
Jon_Ward@syntelinc.com




-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On Behalf Of nagygabor88
Sent: Wednesday, March 30, 2011 2:20 PM
To: OpenSSH list
Subject: a GOOD idea to harden OpenSSH!

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

Mail Delivery Status Notification (Delay)
[.Status: Error, Address: <openssh-unix-dev@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!

On Thu, Mar 31, 2011 at 03:20:38PM -0300, Christian Grunfeld wrote:
> 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

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

It solves all my problems.

On Apr 2, 2011, at 2:09 AM, "Ward, Jon" <Jon_Ward@syntelinc.com> wrote:

> 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.
> Jon_Ward@syntelinc.com
>
>
>
>
> -----Original Message-----
> From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On Behalf Of nagygabor88
> Sent: Wednesday, March 30, 2011 2:20 PM
> To: OpenSSH list
> Subject: a GOOD idea to harden OpenSSH!
>
> I'm writing here, because the ssh dev list says:
>
> Mail Delivery Status Notification (Delay)
> [.Status: Error, Address: <openssh-unix-dev@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!
>

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.



On 3/31/11 11:24 AM, Joseph Spenner wrote:
> --- On Wed, 3/30/11, nagygabor88<nagygabor88@zoho.com> wrote:
>
>> From: nagygabor88<nagygabor88@zoho.com>
>> Subject: a GOOD idea to harden OpenSSH!
>> To: "OpenSSH list"<secureshell@securityfocus.com>
>> 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.
>
>

On Sunday, April 03, 2011 12:17:55 pm Lamont Granquist wrote:
> 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/
--
To the systems programmer, users and applications serve only to provide a
test load.