[nycbug-talk] Analyzing malicious SSH login attempts

[michael]

http://www.securityfocus.com/infocus/1876

	Analyzing malicious SSH login attempts
	Christian Seifert 2006-09-11

	Introduction
	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.
	...
	Recommendations		[snips]
	* 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
inconvenient.

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?

-- 

Michael