"David Dyer-Bennet" dd-b@dd-b.net wrote:
Yes, but if there are *any* ports exposed, seems like those are equally possible. <<
Sort of. Changing the port used by sshd stops the completely clueless script kiddies, since they don't even bother looking at anything other than port 22. Putting it way up high, among the ephemeral ports, will slow down the slightly more clueful who perform nmap scans, since nmap only scans around 1500 ports by default, and if sshd isn't running on one of those, they won't spot it.
However, it won't deter the intelligent or curious attacker; these guys will scan all ports (slowly, so you may not even notice them) and they will use banner enumeration to identify the services, rather than assuming.
Moving sshd to a non-standard port is one of the worst examples of relying on security by obscurity. Its only advantage is that it cuts out some noise in the logs, but proper precautions do that as well, without lulling you into a false sense of security. Rate limiting, combined with enforcement of really strong passwords, or even better, public/private key authentication, is real security.
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.
Best,
--- Les Bell, RHCE, CISSP [http://www.lesbell.com.au] Tel: +61 2 9451 1144 FreeWorldDialup: 800909
Les Bell wrote:
Sort of. Changing the port used by sshd stops the completely clueless script kiddies, since they don't even bother looking at anything other than port 22.
its not even really script 'kiddies', its virus/worms that are doing the vast majority of that hammering on port 22.
and the worms are even stupider than the script kiddies. ok, I suppose the script kiddies are the ones who wrote/released the worm in the first place, or whatever.
Les Bell wrote:
"David Dyer-Bennet" dd-b@dd-b.net wrote:
Yes, but if there are *any* ports exposed, seems like those are equally possible. <<
Sort of. Changing the port used by sshd stops the completely clueless script kiddies, since they don't even bother looking at anything other than port 22. Putting it way up high, among the ephemeral ports, will slow down the slightly more clueful who perform nmap scans, since nmap only scans around 1500 ports by default, and if sshd isn't running on one of those, they won't spot it.
Indeed. A relatively small botnet (~500 bots) can scan the complete IPv4 address space for a single port (port 22) in 24 hours so in theory any hacker with meagre resources could map every standard SSH installation on the internet in a single day. If you run SSH on port 22 it *will* get discovered and probed.
However, it won't deter the intelligent or curious attacker; these guys will scan all ports (slowly, so you may not even notice them) and they will use banner enumeration to identify the services, rather than assuming.
Yes, moving SSH to a non-standard port will likely prevent the casual hacker looking for vulnerable installations but it won't protect against targeted attacks towards specific servers where a full scan is more likely to be performed.
Moving sshd to a non-standard port is one of the worst examples of relying on security by obscurity. Its only advantage is that it cuts out some noise in the logs, but proper precautions do that as well, without lulling you into a false sense of security. Rate limiting, combined with enforcement of really strong passwords, or even better, public/private key authentication, is real security.
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).
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.
Best,
--- Les Bell, RHCE, CISSP [http://www.lesbell.com.au] Tel: +61 2 9451 1144 FreeWorldDialup: 800909
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.
on 7-22-2008 2:45 PM Les Bell spake the following:
"David Dyer-Bennet" dd-b@dd-b.net wrote:
Yes, but if there are *any* ports exposed, seems like those are equally possible. <<
Sort of. Changing the port used by sshd stops the completely clueless script kiddies, since they don't even bother looking at anything other than port 22. Putting it way up high, among the ephemeral ports, will slow down the slightly more clueful who perform nmap scans, since nmap only scans around 1500 ports by default, and if sshd isn't running on one of those, they won't spot it.
However, it won't deter the intelligent or curious attacker; these guys will scan all ports (slowly, so you may not even notice them) and they will use banner enumeration to identify the services, rather than assuming.
Moving sshd to a non-standard port is one of the worst examples of relying on security by obscurity. Its only advantage is that it cuts out some noise in the logs, but proper precautions do that as well, without lulling you into a false sense of security. Rate limiting, combined with enforcement of really strong passwords, or even better, public/private key authentication, is real security.
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.
Portsentry is still available on sourceforge I believe. But who knows if it will still work or even compile. It was written back in the 2.2 kernel days.
On Tue, July 22, 2008 16:45, Les Bell wrote:
Moving sshd to a non-standard port is one of the worst examples of relying on security by obscurity. Its only advantage is that it cuts out some noise in the logs, but proper precautions do that as well, without lulling you into a false sense of security.
I think you've put your finger on a key point here -- what most people really want here is a reduction in log noise.
I'd suggest the best way to achieve that is to not display SSH logon failures :-). If you instead scan the *successes*, you're much more likely to actually spot any problem that occurs.
-
David Dyer-Bennet -
John R Pierce -
Les Bell -
mouss -
Ned Slider -
Scott Silva