Once upon a time, James Hogarth james.hogarth@gmail.com said:

If you really want to SSH to a port other than 22 for a little obscurity use an iptables dnat to map the high port to local host 22 and block 22 from external connections.

Yeah, the old "move stuff to alternate ports" thing is largely a waste of time and just makes it more difficult for legitimate use. With large bot networks and tools like zmap, finding services on alternate ports is not that hard for the "bad guys".

On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote:

On 02/13/2015 09:15 AM, Chris Adams wrote:

...

Yeah, the old "move stuff to alternate ports" thing is largely a waste of time and just makes it more difficult for legitimate use. With large bot networks and tools like zmap, finding services on alternate ports is not that hard for the "bad guys".

Having SSH on 22 is lower-hanging fruit than having SSH on a different port. Sure, an NBA all-star will be able to reach the apples at the top of the tree easily, but most people are not NBA all-stars. Most port-scanners do not scan all possible ports.

And I am fully aware that people in the 'it's a waste of time' camp are unmoved by that. It's not worth arguing about; those who move to non-standard ports are going to want to do it anyway.

Lamar's comments are very sensible.

I always change the SSH port to something conspicuously different. Every server has a different and difficult to guess SSH port number with access restricted to a few IP addresses.

Waste of time = all the time and energy required to clean-up after a hacker's breech when a few seconds work selecting a different port could make a beneficial improvement to security.

On Feb 13, 2015, at 9:03 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:

...changing port numbers...does not really add security. Security through obscurity is only considered to be efficient by Windows folks.

“Security through obscurity” is an overused mantra of derision.

Originally, it was a cry against systems where obscurity was the *only* security measure taken. You could legitimately use it today against software that uses a Caesar cipher instead of AES, or against an admin who moves a publicly-visible file to a nonstandard location to hide it instead of changing its permissions away from world-readable.

Obscurity as an addition to other forms of strength has been a useful tactic since before the Roman Empire was founded.

“…that general…is successful in defense whose opponent does not know what to attack.”

— Sun Tzu, approx 500 BCE

Moving the sshd listening port greatly cuts down on the amount of log spam you get from bots. Yes, the script kiddies can still find your server. But before you dismiss this tactic, try the experiment. Move your sshd to a different port and see what happens to your log spam.

Another legitimate reason to move the SSH port is to cope with overly-restrictive outbound firewalls on other people’s networks. We have one SSH server that listens on port 110 because the site that logs into it has unconditionally blocked port 22 outbound, and we can’t get the local admin to open that port up for us.

If you want to talk about naive security associated with Windows admins, let’s talk about admins who block SSH, which is almost never a *successful* attack vector, while still allowing outbound POP3 connections in a world where email is probably the #1 vector. :facepalm:

Always Learning wrote:

On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote:

...

On 02/13/2015 09:15 AM, Chris Adams wrote:

...

Yeah, the old "move stuff to alternate ports" thing is largely a waste of time and just makes it more difficult for legitimate use. With large bot networks and tools like zmap, finding services on alternate ports is not that hard for the "bad guys".

...

Having SSH on 22 is lower-hanging fruit than having SSH on a different port. Sure, an NBA all-star will be able to reach the apples at the top of the tree easily, but most people are not NBA all-stars. Most port-scanners do not scan all possible ports.

And I am fully aware that people in the 'it's a waste of time' camp are unmoved by that. It's not worth arguing about; those who move to non-standard ports are going to want to do it anyway.

Lamar's comments are very sensible.

I always change the SSH port to something conspicuously different. Every server has a different and difficult to guess SSH port number with access restricted to a few IP addresses.

<snip> I disagree - I am in the "waste of time" camp. The reality is that only script kiddies start out by trying 22 (and I *do* mean script kiddies - I've seen attempts to ssh in that were obviously from warez, man, where they were too stupid to fill in ___ with a username, or salt. All the others, I figure they don't need to be major league, just someone with a clue, who'll run a scan; in fact, I'd expect them to run a scan just to see what IPs were visible, and I know that if I was writing a scan, I don't assume that I'm *so* brilliant that I'm the only one to think of scanning ports < 1k while looking for systems that I might hit.

mark

On 02/13/2015 05:41 AM, James Hogarth wrote:

This is horrible advice anyway. It's not a good idea to run SSH on a port greater than 1024 since if a crash exploit is used to kill the process a non-root trojan process faking SSH to gather credentials could then bind on that port trivially totally compromising the system.

This is where an SELinux policy on your server can come to your aid. You could set up your SELinux policy to allow binding to the desired SSH port by sshd alone, which would prevent the trojan process from rebinding it. But I think the '2345' is just there as an example. Perhaps a line in the HOWTO mentioning that it is preferred to have it listen to a port below 1024 would be appropriate.

That way SSH is still binding to a low port restricted to the root user and you can still get a little of that security through obscurity being desired.

I hate to break it to you, but all security is security through obscurity in some form or fashion. Some forms of obscurity (such as RSA private keys) are just more obscure than other forms of obscurity (like which of a mere 65,535 ports SSH is listening to today, or what knock code you need for the port knocker to access port 22, or whatever). Brute-forcing is just a way of breaking the obscurity of a password, etc. Even layered security is only as secure as the obscurity of how the layers interact.

One of my day job's responsibilities is as site locksmith (and reverse engineering rotating constant master key systems using the Edwards matrix system is one of my current areas of study, since the site's previous occupants didn't leave complete records of the dozen or so RCM key systems here); it is tacit knowledge in locksmithing circles that all security is security through obscurity (even in safes with included hardplate, the security is only as good as the obscurity of the locations of the hardplate's inclusions). But it doesn't matter how randomly you pick the progressions, or whether you use TPP or limited progression or RCM or even spherical methods, it's still all about obscurity, as laid open by Matt Blaze's classic paper "Rights Amplification in Master-Keyed Mechanical Locks" (which caused a bit of a firestorm in certain locksmithing circles when it was published, even though it was a bit of an open secret anyway). Locksmiths have know for decades that security is not ever absolute; this is why safes are rated by how long they can resist knowledgeable attack (and I'm impressed that any safe can resist a thermic lance for longer than 30 minutes, but some can); this is also why lock hardware you buy is rated on a system (and higher rated locks do actually cost more to make).

This is also why the Orange Book and its Rainbow kin exist (Orange Book = 5200.28-STD, aka DoD Trusted Computer System Evaluation Criteria).

On Fri, 2015-02-13 at 18:27 -0800, PatrickD Garvey wrote:

On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen lowen@pari.edu wrote:

...

On 02/13/2015 05:41 AM, James Hogarth wrote:

This is also why the Orange Book and its Rainbow kin exist (Orange Book = 5200.28-STD, aka DoD Trusted Computer System Evaluation Criteria).

Should anyone care to learn from the Rainbow Books, they are available from the United States of America (USA) National Institute of Standards and Technology (NIST) Computer Security Resource Center (CSRC) Selected Historical Computer Security Papers, http://csrc.nist.gov/publications/secpubs/ There is a caveat however, "The Rainbow Series of Department of Defense standards is outdated, out of print, and provided here for historical purposes ONLY." I imagine the CSRC believes some of their other readily available publications are not outdated. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Staying on the original post, there are valuable information from this thread about how to secure ssh, now which one of us are willing to update the wiki.

We can include the use of two factor authentication, public key authentication, challenge response authentication, modifying the /etc/hosts.allow (I have noticed that libwarp no longer contain ssh etc...

I will read up on how to contribute to the CentOS wiki and get involved with the documentation.