Selective SSH dictionary attack deterrent

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?

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/


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

The iptables stuff takes an IP address (and will get one from the
supplied host name if required). This mapping is done at the time the
iptables command is run. I suppose it is possible to create a daemon to
monitor the host name and update iptables when it changes ....

Paul

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

>> 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?
>
> The iptables stuff takes an IP address (and will get one from the supplied
> host name if required). This mapping is done at the time the iptables
> command is run. I suppose it is possible to create a daemon to monitor the
> host name and update iptables when it changes ....
>
> Paul

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

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.

Paul

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?
>
This a somewhat peripheral approach to solving your problem.

If the set of users which are allowed to connect via ssh is a very
limited set, then, why not disallow passwords entirely. You should
require using ssh certificates instead. In my case, I have decided it
is not acceptable to have a door which can be pried open any time that
password guessing is in the picture. ssh setup for using certificates is
well documented.

Under this method you would still keep a firewall rule to rate limit
login attempts. I don't have immediate access to the firewall rules I am
using, but this type of rate limit rules are also well documented. I am
not familiar with "-m recent" that you are using.

That way, you can still accept any connection from any internet address,
but it will fail unless it is the authorized user with the certificate.
This is a workable solution for mobile users with laptops which may
connect from unknown locations (starbucks, airports, hotels, etc.)

--
Douglas Mayne

Smythe de Winter wrote:

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

You could use a port knocking solution to add your wife's IP to another list
where IPs on that list are never subjected to the 'recent' check. But this
will require (1) putting the port knocking mechanism into place and (2)
better organizing your iptables rules (ie. use subrules instead of putting
everything into INPUT).

The other direction would involve a program which receives/processes data
from syslog. This is easy enough, in that syslog can be told to write
certain log entries to a pipe; your program would be a daemon reading from
that pipe.

The program would watch for failed SSH logins. It would block those IPs. A
second program, run via cron, would clean then up after a while.

Thus, you're not blocking on connect attempts (which could be valid); just
login failures.

- Andrew

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. 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.
>
> 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); 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), and
its potential to fill /etc/hosts.deny with entries that are no longer
relevant, and therefore result in wasted cycles devoted to them. I am
aware that things can be configured so that such entries are removed, but
that requires recurrent user intervention, which is, again, inelegant.

The three IPTables lines that I posted accomplish the same thing much
more succinctly. Most of the other stuff that DenyHosts does can be easily
done by checking one's logs.

On Wed, 22 Feb 2006 09:49:31 -0700, Douglas Mayne wrote:

> 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?
>>
> This a somewhat peripheral approach to solving your problem.
>
> If the set of users which are allowed to connect via ssh is a very limited
> set, then, why not disallow passwords entirely. You should require using
> ssh certificates instead.

That is a valid suggestions. My ssh daemon already authenticates me and
my wife based on our public keys; I guess I could reconfigure it so that
it does not accept password authentication.

On Wed, 22 Feb 2006 18:58:33 GMT, Smythe de Winter <(E-Mail Removed)> wrote:

> That is a valid suggestions. My ssh daemon already authenticates me and
>my wife based on our public keys; I guess I could reconfigure it so that
>it does not accept password authentication.

Probably best way to handle Internet facing ssh connections,
perhaps with a (second) sshd on non-standard port -- even
harder to 'crack' from outside.

Grant.

--
.... The computer scientist, who had listened to all of this said,
"Yes, but where do you think the chaos came from?"

On Wed, 22 Feb 2006 16:08:37 +0000, Smythe de Winter wrote:

> Thanks for your suggestion. It is not clear to me that this will solve my
> problem. 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.

I had the same problem as you are seeing, and the only thing I did to
prevent it was disable password login completely. This way, when someone
connects and can't show a valid certificate he is not allowed access.
Works like a charm.

Jan Hugo