[nycbug-talk] Analyzing malicious SSH login attempts

[Dru]

On Tue, 12 Sep 2006, michael wrote:

> 	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?


Here is what I do. Curious as to what works for others on the list.

- restrict users with AllowUsers 
- reduce MaxAuthTries to 3
- user overload/flush in pf to keep the logs sane

Dru