Selective SSH dictionary attack deterrent
Smythe de Winter
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?
Paul Black
> 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
Smythe de Winter
> 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.
Paul Black
> 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
Douglas Mayne
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
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.
Smythe de Winter
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.
Andrew Gideon
> 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
Grant
> 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?"
Jan Hugo Prins
> 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
Menno Duursma
> 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: somes...@machine.dyndns.org
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.linux.slackware/msg/c0d4818503f0ac6f
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.
Menno Duursma
> 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.linux.slackware/msg/85e0326ffefab0a5
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.
Lord...@gmail.com
port scanners don't go beyond 1024.
General Schvantzkoph
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.