SSH brute force China and Linux: best practices

James Hess mysidia at gmail.com
Sat Jan 30 13:06:17 CST 2010


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




More information about the NANOG mailing list