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

On Sat, 30 Jan 2010, Bazy wrote:

On Sat, Jan 30, 2010 at 6:47 AM, Bobby Mac <bobbyjim@gmail.com> wrote:

...

So after many years of a hiatus from Linux,  I recently dropped XP in favour of Fedora.  Now that my happy windows blinders are off, I see alarming things.  Ugly ssh brute force, DNS server IP spoofing with scans and typical script kiddie tactics.

Take a look at http://www.fail2ban.org and http://denyhosts.sourceforge.net. I'm not Chinese but I'm sure that brute-force attacks come from all over the world. Here's a little from my logwatch.

For securing ssh, better than either of those is sshguard. fail2ban is a Python script, as is denyhosts. Script-based services are fine, but native compiled code is better, lower memory, less overhead. sshguard is better because it's written in C, can read multiple log formats, can block for many popular services (dovecot, ftp daemons, even an imap daemon) and it works with many popular existing firewalls: pf, netfilter, iptables, ipfw, ipfilter, tcpd, even IBM's AIX firewall. http://www.sshguard.net/ I've run it for 3 years now, solid as a rock. Questions are quickly answered in the mailing lists by the lead developer Mij. Additionally, you may want to consider using SSH Key Authorization only, and disable password authentication. This guarantees that brute force attacks will fail, because they only use username + Password (AFAICT), not random private keys. Here is a good article on how to enable Key-based auth (may already be enabled), as well as how to turn Password Auth off in ssh to protect/eliminate ssh brute force successes. http://www.debuntu.org/ssh-key-based-authentication Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

...

also enforce either strong passwords or require no passwords (e.g. keys only) and everything should be cool.

what is 'password'?

"password" is that thing that you use when you don't want one compromised "passphrase for your DSA key" to give access to every resource under the sun that you have access to. Keys are fantastic when used to access a resource with relatively permissive (or no) IP-based access lists, automated applications, etc. However, where I have a resource that's already heavily restricted for SSH by ACL, I sometimes prefer an actual password that has to be dredged out of memory. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.