Selective SSH dictionary attack deterrent

On Wed, 22 Feb 2006 15:21:04 +0000, Smythe de Winter wrote:

> I am using the following IPTables rules in order to foil dictionary
> attacks on my SSH server:
>
> iptables -A INPUT -p tcp -i eth0 -s 192.168.0.0/24 --dport 22 -j ACCEPT
> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent
> --update --seconds 15 -j DROP

To be pedatic: i think this brakes RFC793 - maybe better to use like:

-j REJECT --reject-with tcp-reset

> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent
> --set -j ACCEPT
>
> With this, after one failed SSH login attempt from any IP address, with
> the exception of those in my LAN, any further SSH connection attempts from
> the same IP address will be rejected for 15 seconds.
>
> I would like to expand this so that the 15-second rule does not apply to
> connection attempts from my wife's computer, which is outside my LAN. The
> problem is, my wife has an internet connection with a dynamically assigned
> IP address.
>
> There is a DynDNS name associated with my wife's computer, and I have set
> things up so that her DynDNS name always has the right IP address
> associated with it. Would this help?

If you filter on it: sure. Maybe use the libwrap (tcpwrapper) support in
sshd for this. I.e. in hosts.allow something like:

sshd: 192.168., machine.dyndns.org

But you could do a little better still, if the client runs a configureable
ident service (e.g. deamon, IRC application, firewall, etc.)

sshd: (E-Mail Removed)

On Unix-like OSs you could even run a fakeident that rotates some list of
stings periodically or whatever (and you may want to libwrap that too):
http://groups.google.nl/group/alt.os...d4818503f0ac6f

Maybe to /etc/hosts.deny add the following (just to annoy):

sshd : ALL : twist ( sleep 15; /bin/echo "SSH-1.0-FakeSSH-0.1" & )

--
-Menno.

On Wed, 22 Feb 2006 18:50:39 +0000, Smythe de Winter wrote:
> On Wed, 22 Feb 2006 16:35:02 +0000, Paul Black wrote:
>> Smythe de Winter wrote:
>>> On Wed, 22 Feb 2006 15:53:17 +0000, Paul Black wrote:
>>>> Smythe de Winter wrote:

>>>>> I am using the following IPTables rules in order to foil dictionary
>>>>> attacks on my SSH server:
>>>> You might try solving the problem in a slightly different way:
>>>> http://www.denyhosts.net/
>>>
>>> Thanks for your suggestion. It is not clear to me that this will solve
>>> my problem.

Well, actually i would think none off the suggestions i have read sofar
(with the exeption of pubkey auth) would really "solve" dictionary cq
brute-force attacks. Using the S/Key (such as the pam_opie module) would
probably be better still. Rather then SSH into some box directly tough,
something like a OpenVPN gateway could be preferable as frontent as well.

>>> In addition, I find this solution too big, inelegant,
>>> intrusive and significantly less performant than an IPTables one like
>>> the above. Yes, I am not all that impressed by it.

Maybe have a look at the OpenSSH Timelox instead then:
http://wwwx.cs.unc.edu/~hays/dev/timelox_and_TheHand/

>> Why too big? It's a single script that reads a log file and adds
>> entries to /etc/hosts.deny for TCP Wrappers to use.
>>
>> Why inelegant?
>> Why intrusive?
>> Why less performance?
>>
>> Don't see where you get these issues from.
>
> I don't want to start a controversy here, especially bearing in mind
> that your intention was to help, for which I am grateful to you.
>
> I find the DenyHosts solution inelegant because of its requirements:
> Python (big and slow) and SSH with tcp_wrappers support (which I don't
> have);

Why not? It takes next to *no* resorces if hosts.{allow,deny} are empty...

> intrusive, because of its automatic modifications of
> /etc/hosts.deny; less performant, because of its use of tcp_wrappers
> (which, nice as they are, in my experience tend to slow things down),

The _only_ thing they might slowdown is the initial connection stage. And
more often then not, it's either reverse-dns-lookup or an ident-query that
makes one wait.

For the latter, either have clients return what's expected (RST?), or
disable the - default 5sec - delay with like: spawn ( /bin/true & )

For the former: the hosts file + local DNS cache probably does the trick:
http://groups.google.nl/group/alt.os...e0326ffefab0a5

Ofter that stage is done with, firewall-rules (such as the iptables you
posted) will still "slow things down" to some extend - sinse of every
packet atleast the headers are inspected still (however unnoticeable on
modern PC hardware) - not so with libwrap ACLs...

[snip]

--
-Menno.

A simple solution would be to move ssh to a non standard port, most
port scanners don't go beyond 1024.

On Wed, 22 Feb 2006 15:21:04 +0000, Smythe de Winter wrote:

> I am using the following IPTables rules in order to foil dictionary
> attacks on my SSH server:
>
> iptables -A INPUT -p tcp -i eth0 -s 192.168.0.0/24 --dport 22 -j ACCEPT
> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent
> --update --seconds 15 -j DROP
> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent
> --set -j ACCEPT
>
> With this, after one failed SSH login attempt from any IP address, with
> the exception of those in my LAN, any further SSH connection attempts from
> the same IP address will be rejected for 15 seconds.
>
> I would like to expand this so that the 15-second rule does not apply to
> connection attempts from my wife's computer, which is outside my LAN. The
> problem is, my wife has an internet connection with a dynamically assigned
> IP address.
>
> There is a DynDNS name associated with my wife's computer, and I have set
> things up so that her DynDNS name always has the right IP address
> associated with it. Would this help?

There is a simpler solution, move the SSH port to something other than 22.
You should also disable password authentication and require RSA
authentication. I have two systems that have ssh connections, one is on
port 22 the other is on a different port. The one on port 22 has constant
attacks although they are futile because I don't allow password
authentication. The other system is on a higher port number, it's never
had an attack.