Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Secure-Shell
[Top] [All Lists]

RE: Deliberately create slow SSH response?

Subject: RE: Deliberately create slow SSH response?
Date: Thu, 10 Jul 2008 14:40:12 -0500
I think you misunderstood how my suggesting differs from Kevin's.  I
wish I had more time and I would just write the patch myself... here's
the idea...

sample sshd.conf

# enable bad IP penalty box
penalty_box = yes

# 3 bad attempts within 60 seconds places the offending IP address
# in a penalty box
penalty_attempts = 3
penalty_window = 60

# login delay for IP address in penalty box (in seconds)
penalty_delay = 30

# how long an IP address stays in the penalty box (in minutes)
# the timer would be reset every time there is an invalid attempt.
# a value of 0 means the IP address stays in the penalty box permanently
# until a valid login is supplied.  valid logins would always remove an
# IP address from the penalty box
penalty_timeout = 5

# add an extra 5 seconds to the penalty_delay for each subsequent
# invalid login
penalty_delay_perturb = 5


I've never looked at the source, but I can't imagine this being much
more difficult that a simple structure and a linked-list.

Bryan


On Thu, 2008-07-10 at 19:16 +0000, Sergio Castro wrote:
I'm sorry Bryan, this thread is getting confusing.
What do I mean about what?

-----Mensaje original-----
De: Bryan Christ [mailto:bryan.christ@hp.com]
Enviado el: Jueves, 10 de Julio de 2008 02:17 p.m.
Para: Sergio Castro
Asunto: RE: Deliberately create slow SSH response?

What do you mean?

On Thu, 2008-07-10 at 19:12 +0000, Sergio Castro wrote:
So there you go, then IP filtering is not an option.

-----Mensaje original-----
De: Bryan Christ [mailto:bryan.christ@hp.com] Enviado el: Jueves, 10
de Julio de 2008 02:10 p.m.
Para: Sergio Castro
CC: 'Zembower, Kevin'; secureshell@securityfocus.com
Asunto: RE: Deliberately create slow SSH response?

Unfortunately, I never know exactly where I'll be logging in from and
maintaining a blacklist/whitelist is tiresome.  As for moving the port
(another suggestion I saw) that's not really a possibility for me
either because some of the remote locations I shell in from don't
allow traffic out non-standard ports.

On Thu, 2008-07-10 at 18:54 +0000, Sergio Castro wrote:
Indeed, I agree.
The point I'm trying to convey is that if the objective is to reduce
the chance of an attack getting through, and given the fact that the
service is SSH, then a better solution may be to limit access to
trusted
IPs.
That's all I'm saying :)

-----Mensaje original-----
De: Bryan Christ [mailto:bryan.christ@hp.com] Enviado el: Jueves, 10
de Julio de 2008 01:51 p.m.
Para: Sergio Castro
CC: 'Zembower, Kevin'; secureshell@securityfocus.com
Asunto: RE: Deliberately create slow SSH response?

Sergio,

I think Kevin and I realize that dictionary attacks are automated,
but a 30-60 second delay would significantly slow them down to the
point where it could hardly be called a brute force attack.

On Wed, 2008-07-09 at 17:14 +0000, Sergio Castro wrote:
The brute force attacks are most likely automated, so if your
objective is to bore a human to death with 30 second delays, it wont'
work.

Have you thought about limiting access to the service to only
certain
IPs?

- Sergio

-----Mensaje original-----
De: listbounce@securityfocus.com
[mailto:listbounce@securityfocus.com]
En nombre de Zembower, Kevin Enviado el: MiÃrcoles, 09 de Julio de
2008 11:56 a.m.
Para: secureshell@securityfocus.com
Asunto: Deliberately create slow SSH response?

This might seem like a strange question to ask, but is there a way
to deliberately create a slow response to an SSH request? I'm
annoyed at the large number of distributed SSH brute-force attacks
on a server I administer, trying to guess the password for 'root'
and
other accounts.
I think that my server is pretty secure; doesn't allow root to log
in through SSH, only a restricted number of accounts are allowed
SSH access, with I think pretty good passwords. But still, the
attempts annoy
me.

I wouldn't mind if SSH took say 30 seconds to ask me for my password.
This would slow the attempts. Is there any way to configure
OpenSSH to do this? I searched the archives of this group with
'slow' and
'delay'
but didn't come up with anything on this topic. Please point it
out to me if I overlooked anything. In addition, I can limit the
number of SSH connections to 3-5 and still operate okay.

Ultimately, I need this solution for hosts running OpenSSH_3.9p1
under RHEL ES 4 and OpenSSH_4.3p2 under Debian 'etch' 4.0 and
Fedora
Core 6.

Thanks in advance for your advice and suggestions.

-Kevin

Kevin Zembower
Internet Services Group manager
Center for Communication Programs
Bloomberg School of Public Health
Johns Hopkins University
111 Market Place, Suite 310
Baltimore, Maryland  21202
410-659-6139


__________ NOD32 3255 (20080709) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com




__________ NOD32 3257 (20080710) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com




__________ NOD32 3257 (20080710) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com




__________ NOD32 3257 (20080710) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com



<Prev in Thread] Current Thread [Next in Thread>