Ned Slider wrote:
[snip]
I don't think anyone is suggesting running SSH on a non-standard port as
a sole means of defence, but rather as part of a layered approach where
it is very effective in what it is designed to do - namely to vastly
reduce the number of random brute-forcing attempts and concomitant noise
in log files not to mention reducing the overall load on other
mechanisms of defence such as firewall scripts etc.
Moreover, rate limiting is not as effective as it used to be as there is
now evidence that attackers are using distributed methods of attack
utilizing multiple random IP addresses that circumnavigate defences that
rely on attacks originating from a single IP address. Studies suggest
attackers will try a handful of common account names/passwords and then
move on as that's what yields the highest returns for them.
We should also remember that public/private key authentication is only
secure as the host the private key is stored on when keys without
passphrases are employed (all too common where users don't want to trade
using a password for a passphrase). If a user account gets hacked then
the keys to the kingdom are there for the taking and the hacker has
instant access to any SSH servers which employ public/private key
authentication (without passphrases).
Indeed. and with keyloggers or social eng, passphrases get stolen too.
(and trojans can also connect from the same client if an agent is
running). so don't trust users too much...
A useful additional layer of defence, if you want it, is a daemon that
will
watch for port scans on the simple services ports and immediately
insert a
firewall rule to block that source - such as the old PortSentry, if
you can
find it, or some more modern equivalent. Of course, this won't do much to
defend against some types of stealthy scans, such as idle time scans.
one problem here is that you may block innocent clients in the case of
IP spoofing. better have a daemon that establishes tcp sessions before
blocking.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
