SSH brute force China and Linux: best practices

Bret Clark bclark at
Sat Jan 30 19:52:48 UTC 2010

denyhost is one of my favorite apps.

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
> 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 at>
> Date: Sat, Jan 30, 2010 at 12:23 AM
> Subject: Re: SSH brute force China and Linux: best practices
> To: Bobby Mac <bobbyjim at>
> 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).

More information about the NANOG mailing list