SSH brute force China and Linux: best practices
Bret Clark
bclark at spectraaccess.com
Sat Jan 30 19:52:48 UTC 2010
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 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