SSH brute force China and Linux: best practices
James Hess
mysidia at gmail.com
Sat Jan 30 19:06:17 UTC 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