Restrict IP's for ssh with a dynamic list

SanskritFritz · 2011-03-30 09:08:05

Ok, I'm getting tired of checking my log for

Failed password for invalid user chris from 173.236.184.13 port 58106 ssh2

entries in my auth.log.
But I can't just set the hosts.allow, because I often login from different IP addresses. Denyhosts does the job, but a bit too slow. Also my firewall is set to allow no more than 10 tries per second (which is still ridiculously high).
So I thought I could set up a cronjob that checks a IP list somewhere out there, and updates the hosts.allow, so I can login from any IP address. All I have to do is update the list with my current IP, wait a minute for the cronjob to update hosts.allow, and I'm good to go.
But before I go and whip up a script like this, I am pretty sure, that such a solution already exists, or there are better solutions.
Please advice me.

ghen · 2011-03-30 11:49:51

Some alternative suggestions:

- simply run your ssh on another port, and get rid of 99% of these attacks
- allow ssh key logins only (you'll still get those logs but you can now safely ignore/filter them)
- install fail2ban to block clients after X failed attempts
- port knocking

SanskritFritz · 2011-03-30 12:23:06

Thanks ghen, those ideas are really something to consider. But
1. I need port 22, because most of the time I connect from behind restrictive firewalls.
2. I thought about this as well, but then I must carry my key with me somehow. Still, I might choose that, it is far more secure, thats for sure.
3. fail2ban does effectively the same as denyhosts, just on the firewall level. Same (slow) speed though.
4. Again those pesky restrictive firewalls...

steve___ · 2011-03-30 12:56:49

I use this script on slicehost/linode servers

#!/bin/sh

script=${0##*/}

usage() { cat << EOF
usage: $script HOSTNAME1 [HOSTNAME2 HOSTNAME3 .. HOSTNAMEn]

A script to update iptable records for dynamic dns hosts.  Cron this
script to update the IP addresses.
EOF
}

(( $# == 0 )) && { usage; exit 1; }

chain=dyndns          ## The forward chain name.
iptables=/usr/sbin/iptables

mkdir -p /var/run/fw-dyndns

$iptables -L -n -v | grep -q "Chain $chain" ||
    { "$iptables" -N "$chain" && "$iptables" -I INPUT 1 -j "$chain"; }

for host in $* ; do
    ## lookup host name from dns tables
    ip=$(ping -c 1 -W 1 "$host" | awk -F'[()]' 'NR<2 {print $2}')
    hostfile=/var/run/fw-dyndns/$host
    oldip=0

    [[ -e $hostfile ]]  && oldip=$(<"$hostfile")
    [[ $oldip == $ip ]] && continue      ## If the IP hasn't changed, then continue

    if (( $oldip != 0 )); then
        echo $(date) "Removing old iptables rule for $host ($oldip)"
        $("$iptables" -D "$chain" -s "$oldip"/32 -j ACCEPT)
    fi

    if [[ $ip ]]; then
        echo $(date) "Inserting new iptables rule for $host ($ip)"
        $("$iptables" -I "$chain" -s "$ip"/32 -j ACCEPT)
    fi

    ## Store new IP address
    echo "$ip" > "$hostfile"
done

exit 0

I also have a very similar script which I use on openwrt firewalls. If you want to see it, just let me know.

SanskritFritz · 2011-03-30 14:58:07

steve___ thanks, this is something I can start with for sure! I'll have to dissect that script, as there are many things I'm not familiar with yet.

steve___ · 2011-03-30 15:35:01

I will give you a better description. I run this script from cron, like so:

*/5 * * * *     /root/bin/fw-dyndns host1.no-ip.org host2.no-ip.org ... etc

For example, I use community/noip to update my dynanic IP my laptop, home fw etc. For an example of those this works, on my laptop I run this script every five minutes:

#!/bin/bash

oldip=$(< /var/run/host1no-ip.org)
ip=$(curl -Ls http://tnx.nl/ip)

if (( $oldip != $ip )); then
    killall noip2
    /usr/bin/noip2
    echo "$ip" > /var/run/host1.no-ip.org
fi

What the 'fw-dyndns' script does is allow access to all ports for the domain names passed to it. That's this line:

 $("$iptables" -I "$chain" -s "$ip"/32 -j ACCEPT)

You could narrow this down to only port 22 but changing this line.

Let me know if you have any questions. Or if anyone else knows of a better way to do this please let me know.

Last edited by steve___ (2011-03-30 15:36:15)

Leonid.I · 2011-03-30 18:56:48

ghen wrote:

Some alternative suggestions:
- simply run your ssh on another port, and get rid of 99% of these attacks
- allow ssh key logins only (you'll still get those logs but you can now safely ignore/filter them)
- install fail2ban to block clients after X failed attempts
- port knocking

Or, you can use a rate limiter with iptables' recent module. For example, I have a max rate of ~3 connections/minute. If this limit is exceeded, the offending host is blocked for 2 mins. This stops the scripts-kiddies, and there is nonneed to modify iptables rules on the fly.

SanskritFritz · 2011-03-30 19:54:20

Steve, so your script essentially allows access to those domains listed in your noip config? That is not exactly what I want, but close. I login to my home box from different companies that have fix ip addresses mostly.

Leonid, that is actually what this line does in firehol.conf:

protection strong 10/sec 10

Sorry I only know firehol a little bit, no experience with iptables or networking in general.

steve___ · 2011-03-30 20:08:42

SanskritFritz wrote:

Steve, so your script essentially allows access to those domains listed in your noip config? That is not exactly what I want, but close. I login to my home box from different companies that have fix ip addresses mostly.

I used a no-ip.org domain name to illustrate that the script works with dynamic IPs as well as static IPs. Although I have not tested the script with an IP address all these should be valid:

fw-dyndns host1.no-ip.org host1.staticip.com 123.123.123.123

Last edited by steve___ (2011-03-30 20:09:12)

SanskritFritz · 2011-03-30 21:36:24

steve thank you, that will serve me well. Now on to whipping up my script, gonna take some time...

jowilkin · 2011-03-30 22:44:03

SanskritFritz wrote:

Denyhosts does the job, but a bit too slow.

What do you mean by slow? The fact that it scans log files and so failed logins will not be detected until the log is scanned again?

If so, you may want to look at pam_abl (pam auto blacklist) http://hexten.net/wiki/index.php/Pam_abl. It's a pam module that will block users and/or ip addresses after x failed attempts; so there is no delay in blacklisting.

Last edited by jowilkin (2011-03-30 22:44:33)

SanskritFritz · 2011-03-31 07:59:13

jowilkin wrote:

SanskritFritz wrote:
Denyhosts does the job, but a bit too slow.
What do you mean by slow? The fact that it scans log files and so failed logins will not be detected until the log is scanned again?

Exactly.

jowilkin wrote:

you may want to look at pam_abl (pam auto blacklist) http://hexten.net/wiki/index.php/Pam_abl. It's a pam module that will block users and/or ip addresses after x failed attempts; so there is no delay in blacklisting.

Wow, nice, thanks! There is even an AUR package for it. I'll definitely try this later.

Leonid.I · 2011-03-31 14:51:31

SanskritFritz wrote:

Leonid, that is actually what this line does in firehol.conf:
protection strong 10/sec 10
Sorry I only know firehol a little bit, no experience with iptables or networking in general.

Uhm... /me reinventing the wheel, it seems

SanskritFritz · 2011-04-01 08:43:14

Leonid.I wrote:

SanskritFritz wrote:
Leonid, that is actually what this line does in firehol.conf:
protection strong 10/sec 10
Sorry I only know firehol a little bit, no experience with iptables or networking in general.
Uhm... /me reinventing the wheel, it seems

Hmm, I looked up more thoroughly, and I was wrong. So your idea will be implemented for sure, thanks.

Leonid.I · 2011-04-01 16:44:34

Do you need the iptables ruleset?

SanskritFritz · 2011-04-01 19:34:54

Leonid.I wrote:

Do you need the iptables ruleset?

Please, yes, thank you.

Leonid.I · 2011-04-02 17:37:49

OK, here it goes. There are several "layers":
(1) Port knocking. This is no match for a specialized daemon, like AUR/knockd, but much simpler and does the trick of hiding the machine from port scanners. In order to protect against statistical possibility that the firewall gets opened by the usual internet noise, after sufficiently long time, we need to have some time correlation between the knocks (here I have the simplest possible way)

-A IF_KNOCK -p tcp -m tcp --dport XXXXX -m recent --set --name IF_KNK_LIST --rsource -j LOG --log-prefix "seq1: " --log-level 6 --log-ip-options --log-uid
-A IF_KNOCK -p tcp -m tcp --dport YYYYY -m recent --rcheck --seconds TC --name IF_KNK_LIST --rsource -j KNOCK_ACCEPT
-A IF_KNOCK -j DROP
-A KNOCK_ACCEPT -j LOG --log-prefix "kseq2: " --log-level 6 --log-ip-options --log-uid
-A KNOCK_ACCEPT -m recent --set --name ACCPT_KNK_LIST --rsource
-A KNOCK_ACCEPT -m recent --remove --name IF_KNK_LIST --rsource
-A KNOCK_ACCEPT -j DROP
...
-A INPUT -p tcp -m tcp --dport XXXXX -m state --state NEW -j IF_KNOCK
-A INPUT -p tcp -m tcp --dport YYYYY -m state --state NEW -j IF_KNOCK
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --rcheck --seconds TTTTT --name ACCPT_KNK_LIST --rsource -j SSH_ACCEPT

Here XXXXX and YYYYY are some large, but arbitrary ports, TC (time correlation, usually ~ 10 sec) is the max. time between the knocks after which the first knock will be forgotten and second will never succeed, and TTTTT (usually several hours) is the time interval (in sec) to keep the port 22 open.
(2) If the first layer is penetrated, we use the chain SSH_ACCEPT (just mentioned above)

-A SSH_ACCEPT -m recent --set --name NEW_SSH --rsource
-A SSH_ACCEPT -m recent --update --seconds TTT --hitcount N --name NEW_SSH --rsource -j DROP
-A SSH_ACCEPT -j ACCEPT

Now, TTT is a smaller (than TTTTT) time period (usually 1-several minutes) and N is the number of hits, upon reaching which the packets will be dropped (usually N<10).

Of course, if you have a habit of mistyping your password 10 times in a row, or make a lot of calls to scp (e.g. you use svn+ssh), then you'll block yourself out. The solution, which is anyway more elegant, is to use ssh connection sharing, via

ssh -MS /path/to/socket user@host

EDIT: Oh, and forgot to mention, ports can be opened with "ssh -p XXXXX host and CTRL-C".

Last edited by Leonid.I (2011-04-02 17:43:34)

rwd · 2011-04-07 07:54:55

SanskritFritz wrote:

2. I thought about this as well, but then I must carry my key with me somehow. Still, I might choose that, it is far more secure, thats for sure.

problem solved

Last edited by rwd (2011-04-07 07:55:59)

ewaller · 2011-04-07 14:47:39

Moderator Note: Please be careful of the forum rules regarding the posting of pictures. This picture is well over the 250 pixel limit, but the size is 49K which slips in under the 50K limit. I'll let it slide, but be careful.

SanskritFritz · 2011-04-07 19:40:27

The picture might be too big, but thanks, it was funny.

SanskritFritz · 2011-04-08 07:58:45

Leonid.I thanks for that very thorough explanation. Would you mind to look at this:
http://firehol.sourceforge.net/commands.html?#accept
I'm using Firehol, it looks to me that the accept command realizes something similar to your proposal. Is that true?

Leonid.I · 2011-04-09 23:47:05

SanskritFritz wrote:

Leonid.I thanks for that very thorough explanation. Would you mind to look at this:
http://firehol.sourceforge.net/commands.html?#accept
I'm using Firehol, it looks to me that the accept command realizes something similar to your proposal. Is that true?

Yes, you're right: "accept with limit" and "accept with knock" (although the latter will require you to have Judd Vinet's knockd configured and running).

My only problem with firehol/susefirewall2/... is that these tools are too complicated for a workstation. They try to automate basic things, which users should know anyway. For example, strictly speaking none of my machines even need a firewall (indeed, the only open port is 22, which is password protected), so I have it for learning and monitoring purposes only. What is the advantage of just executing "/etc/rc.d/firehol start" without understanding what this script is doing? These tools might be useful primarily for sysadmins dealing with many busy servers...

Last edited by Leonid.I (2011-04-09 23:48:53)

Arch Linux

#1 2011-03-30 09:08:05

Restrict IP's for ssh with a dynamic list

#2 2011-03-30 11:49:51

Re: Restrict IP's for ssh with a dynamic list

#3 2011-03-30 12:23:06

Re: Restrict IP's for ssh with a dynamic list

#4 2011-03-30 12:56:49

Re: Restrict IP's for ssh with a dynamic list

#5 2011-03-30 14:58:07

Re: Restrict IP's for ssh with a dynamic list

#6 2011-03-30 15:35:01

Re: Restrict IP's for ssh with a dynamic list

#7 2011-03-30 18:56:48

Re: Restrict IP's for ssh with a dynamic list

#8 2011-03-30 19:54:20

Re: Restrict IP's for ssh with a dynamic list

#9 2011-03-30 20:08:42

Re: Restrict IP's for ssh with a dynamic list

#10 2011-03-30 21:36:24

Re: Restrict IP's for ssh with a dynamic list

#11 2011-03-30 22:44:03

Re: Restrict IP's for ssh with a dynamic list

#12 2011-03-31 07:59:13

Re: Restrict IP's for ssh with a dynamic list

#13 2011-03-31 14:51:31

Re: Restrict IP's for ssh with a dynamic list

#14 2011-04-01 08:43:14

Re: Restrict IP's for ssh with a dynamic list

#15 2011-04-01 16:44:34

Re: Restrict IP's for ssh with a dynamic list

#16 2011-04-01 19:34:54

Re: Restrict IP's for ssh with a dynamic list

#17 2011-04-02 17:37:49

Re: Restrict IP's for ssh with a dynamic list

#18 2011-04-07 07:54:55

Re: Restrict IP's for ssh with a dynamic list

#19 2011-04-07 14:47:39

Re: Restrict IP's for ssh with a dynamic list

#20 2011-04-07 19:40:27

Re: Restrict IP's for ssh with a dynamic list

#21 2011-04-08 07:58:45

Re: Restrict IP's for ssh with a dynamic list

#22 2011-04-09 23:47:05

Re: Restrict IP's for ssh with a dynamic list

Board footer