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. |

| Subject: | Re: OpenSSH -- a way to block recurrent login failures? |
|---|---|
| Date: | Tue, 28 Sep 2004 09:07:11 -0500 |
On Tue, 21 Sep 2004, Victor Danilchenko wrote:
>Hi,
>
>We are looking for a way to temporarily block hosts from which
>we receive a given number of sequential failed login attempts, not
>necessarily within the same SSH session (so MaxAuthTries is not enough).
>The best solution I could come up with so far would be to run OpenSSH
>through TCPWrappers, and set up a log watcher daemon which would edit
>/etc/hosts.deny on the fly based on the tracked number of failed logins
>for each logged host.
>
>Is there a better solution known for the sort of problems we
>have been plagued with lately -- repeated brute-force crack attempts
>from remote hosts? I looked on FreshMeat and I searched the mailing
>lists, only to come up empty-handed.
>
>Thanks in advance,
Thanks to all who replied with the suggestions. Alas, none of
them were quite suitable.
The IPTables manipulation is a fine idea, but we need a solution
that runs in a very heterogeneous environment. At the very least, we are
looking at protecting Redhat Linux, OS/X, and Solaris systems.
Portsentry is IMO a little too complicated to easily deploy on a
wide number of systems -- we need a fire-and-forget solution (ideally a
simple modification to the sshd_config file, but that obviously is not
in the cards).
In the end, I wrote a perl script that did solved the problem
the brute way -- trail the SSHD logs, and modify /etc/hosts.deny on the
fly. Attached in this script, should anyone here find it useful. The
next logical step would be to turn this into a distributed solution
where blacklists could be shared among individual nodes. Would be nice
to have a DNS-based blacklisting solution eventually, similar to how
SPAMming can be handled by MTAs...
Note that the attached script has been stripped of our
information before being posted, so a typo or two may have crept in
somewhere during the cleanup editing. It currently works on OS/X and
Linux, I haven't yed added the code to make it work on Solaris.
--
| Victor Danilchenko | When in danger or in doubt, |
| danilche@cs.umass.edu | run in circles, scream, and shout. |
| CSCF | 5-4231 | Robert Heinlein |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Illegal user ssh probes, Huijsmans, JCM (Jan) |
|---|---|
| Next by Date: | Re: PubkeyAuthentication for Specific User Only, tdotzauer@online.de |
| Previous by Thread: | RE: OpenSSH -- a way to block recurrent login failures?, Warner, Randy |
| Next by Thread: | RE: OpenSSH -- a way to block recurrent login failures?, Baker, Darryl |
| Indexes: | [Date] [Thread] [Top] [All Lists] |