[nycbug-talk] Analyzing malicious SSH login attempts
lists at genoverly.net
Tue Sep 12 09:53:51 EDT 2006
Analyzing malicious SSH login attempts
Christian Seifert 2006-09-11
Malicious SSH login attempts have been appearing in some
administrators' logs for several years. This article revisits
the use of honeypots to analyze malicious SSH login attempts
and see what can be learned about this activity. The article
then offers recommendations on how to secure one's system
against these attacks.
* Use the /etc/hosts.allow and /etc/hosts.deny files...
* Install a firewall to restrict access to the SSH server...
* Restrict the SSH server to only authenticate...
* Move the listening port of the SSH server from 22...
* Use an alternate authentication method...
* disable remote access to root...
I've read Hosts.[allow|deny] can be spoofed and besides, I can not
predict where I'll be when I want to logon. Granted, I could leave a
box open somewhere to logon to, and then hop to the target with that
box as allowed.. but, what's the point? I still have a 'weak link'
according to their logic.
I am not a fan of port knocking, port shuffling, or any other port
dance moves. It would only delay an attacker a few seconds but would
wreak havoc on my muscle memory and any scripts that use scp, rsync,
forwarding, or tunnelling.
For years I used PermitRootLogin=No, but I am being swayed recently
that that is false security. I also have found it to be really
Recently, I have been moving toward keys vs. passwords (it makes logons
fast and fun). But I still have lingering anxiety that once you have
my desktop, you have my local network AND my datacenter network AND
anywhere else I've dropped a key.
Maybe I should, more seriously, consider the shear hassle of skeys.
I'm curious, do NYCBUG talk subscribers consider this a "best
practices" article? Is anything misleading, wrong, missing.. or right?
I am also curious.. where do we draw the line and just *trust* our OS?
More information about the talk