denyhost is one of my favorite apps. http://denyhosts.sourceforge.net/ James Hess wrote:
When you really want to be safe -- even one illicit access attempt may be enough to gain access. fail2ban or ssh rate limiting do not stop distributed brute force attacks.
The best action depends on a tradeoff between OPSEC network operations security considerations VS any legitimate need for quick remote access/admin convenience also Versus simplicity / difficulty to implement : If feasible, BCP38 + use of a destination port 22 ACL on the first/last hop router to discard unexpected SSH traffic to your protected LAN(s) from outside your IP prefixes, and therefore all local NIX servers.
For ISPs, ssh blocking ACL should apply to your own device and router subnets, but not downstream end-users.
+ In case access is desired from unknown remote IPs: dynamic ACL and creative use of a facility such as "access-enable" on router: or port knocking protection [on the ssh server itself].
If security is more important and readily available/quick remote access from offsite is not important: then a secure VPN router + remote access VPN, is a difficult target for an attacker (but susceptible to failure either on client side or hardware failure on remote side).
For port knocking http://www.portknocking.org/view/implementations E.g. fwknop / knockd / BSD Doorman / knockdaemon / PortknockO
This is in ADDITION to (not a replacement for) additional security measures on individual hosts, such as the below.
--------- Forwarded message ---------- From: James Hess <mysidia@gmail.com> Date: Sat, Jan 30, 2010 at 12:23 AM Subject: Re: SSH brute force China and Linux: best practices To: Bobby Mac <bobbyjim@gmail.com>
For home? Turn off the SSH daemon and keep it off, unless you really need it. Or use iptables and /etc/hosts.deny + /etc/hosts.allow to limit access to local IPs.
The considerations for a NIX workstation are really no different than with any network device, port 22 is under constant attack, you might want to filter upstream somewhere. Keep network software up-to-date with patches.
Set strong passwords. Disable remote login to the admin/root user. Use ssh only: telnet is unsafe. Configure an unofficial alternative port number for ssh (one numbered below 1024 but not port 22).
Ban password-based auth in favor of public key, SSL Certificate, or Kerberos/GSSAPI-based authentication (with Kerberos, configure it so a SSH client can only authenticate by first holding a Kerberos ticket, instead of the default of allowing client to enter a password and server to obtain a ticket on client's behalf).
It's really hard to guess a valid 2048-bit DSA key by brute force (a lot harder than guessing the average 8-character password).