A permanent ban may not be worth it; botnets come and go and your table will just grow without bound.

What I (and a number of others) do is a temporary ban based on too many connection attempts; 5 connection attempts in 60 seconds will cause the remote end to be temporarily blocked.

IPT=/sbin/iptables

# SSH firewall rules - deny access to servers that make more than 5 connections
# in 60 seconds

# Set this to "DROP" to drop packets, or REJECT to reject packets
DROP=REJECT

# Only log slowly so we don't fill up logs and overload the linode
$IPT -N ssh-drop
$IPT -A ssh-drop -m limit --limit 2/minute -j LOG --log-prefix "FIREWALL:SSH-DROPPED "
$IPT -A ssh-drop -j $DROP

# Set this to "ssh-drop" for logging, or $DROP to silently lock them out
DEST=ssh-drop

$IPT -A INPUT -p TCP --dport 22 --syn -m recent --name ssh --update --seconds 60 --hitcount 5 -j $DEST

$IPT -A INPUT -p TCP --dport 22 --syn -m recent --name ssh --set

# End of SSH firewalling

I _think_ that works!

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

I use DenyHosts for this.. it allows setting of individual thresholds for attempted logins as root (you could just disable this in the ssdh_config anyway), failed logins of usernames that *do* exist, as well as of usernames that don't exist.

After the threshold has been reached, the IP of the attacker is added to /etc/hosts.deny.

You can set whether to periodically purge these IPs or not, which may address the point raised by sweh above. You can get e-mail notifications of bans and so on. All in one config file, easy peasy.

fail2ban may do a similar thing, I've never used it but have heard good things.

It's generally a good idea to whitelist your IP in /etc/hosts.allow in case you make too many failed attempts to ssh in and end up locking yourself out! A testament to Denyhost's efficiency, it's punished me in the past for being too drunk and trying to log in and fiddle around

Denyhosts and fail2ban fulfill the same purpose; they just do it in different ways.

As noted, denyhosts uses the hosts.deny file to lock out IP addresses. In order for this to work, your sshd must use tcpwrappers. This is accomplished by either being called from xinetd (uncommon), or by the tcpwrapper libraries being compiled into sshd. You can check for the former by (most likely) looking for a relevant file in /etc/xinetd.d/, or for the latter this way:

$ ldd /usr/sbin/sshd | grep wrap
        libwrap.so.0 => /lib/libwrap.so.0 (0xb7ee2000)

If you don't get any output from this command, then sshd hasn't been built against the tcpwrapper libraries and denyhosts will only benefit you if sshd is called from xinetd.

In contrast, fail2ban inserts rules directly into the firewall. This is good in that ssh won't even see connection attempts from hosts that trip the rules. If you already use a system to manage firewall rules (like firestarter, guarddog, or Ubuntu's ufw) then fail2ban's default monkeying with the raw firewall rules may cause problems. It can be customized to use your preferred firewall system instead, but you may find it easier to simply use denyhosts in such a case.

I don't have a strong preference for one or the other - they each have their strengths in different environments. I would very much recommend setting "PermitRootLogin no" or "PermitRootLogin without-password" in your sshd_config.

Edit: you can always use Linode's web console if you end up locking yourself out like condate...

Good point, I learnt this lesson long before I was using Linode

Thanks for the interesting info about fail2ban.

I honestly don't see the advantage of introducing the complexity of extra tools, databases, blacklists, etc, when the iptables "limit" match support as sweh outlined is available. If you don't care about the logging you can make his example even simpler.

But to each his own I guess.

What denyhosts and fail2ban do for you that an iptables-only approach can't is check to see whether or not the connection attempts are actually successful before locking out the remote host.

If you're using Konqueror, gFTP, or a similar tool to transfer lots of files, you can easily create dozens of connection attempts to the server per minute. Heck, does scp itself even re-use an established connection, or does it create a new one each time?

One system I use has a rate-limiting approach like sweh's - if I have to transfer a number of files there, I generally create a zip or tar archive so I'm only copying one file and don't accidentally trip the rules.

There are probably as many ways to secure your sshd as there are sysadmins. It all comes down to what is the best approach for your situation.

And I wasn't picking on condate, I've managed to lock myself out and didn't even have the excuse of being drunk...

If you have a sufficiently new enough version of ssh, then look into the shared connection configuration

eg in my .ssh/config file I have

Host *
  ControlMaster auto
  ControlPath ~sweh/.ssh/Control_Path_%r@%h:%p

Now if you login and stay logged in to a machine then second login attempts reuse the existing connection. There are some gotcha's (it doesn't authenticate, so if you try to access via an key with a forced command on the secondary connection that doesn't work; the primary connection doesn't exit until all secondaries have) but otherwise works good.



This would also solve that problem. In my case I rsync trees when making updates, so I never run into the problem you mentioned

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

I now see I am not alone with these kinds of attacks. I plan on locking down my sshd more.
By the way does anyone know how to get vsftpd to run under a non root user I tried just changing the setting non_priv_user=nobody
on a test unit at home but it failed to work.
ps -ef showed it was still owned by root
Any ideas how to truly get it to run under non privileged account??

_________________
Q.E.D

Rob

That's what a whitelist is for. Those other solutions also rely on polling the log file.

a non privileged user like nobody or justthisguyyaknow

I do not think that reply was relevant to my reply

_________________
Q.E.D



Rob

It needs to start as root to bind to port 21; additionally, it needs to maintain root to switch to other uids after login. You might be able to start it as a non-root user, but it will be unable to bind to port 21 and will only be usable for anonymous FTP. -rt

Not surprising, since it didn't even quote you.