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).
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
