CentOS - Feb 2015 - Securing SSH wiki article outdated

Hi, just a quick note to whoever is maintaining this page:

  http://wiki.centos.org/HowTos/Network/SecuringSSH

The procedure is missing the firewall-cmd calls necessary in EL7:

  firewall-cmd --add-port 2345/tcp
  firewall-cmd --add-port 2345/tcp --permanent

Also, it may be worth mentioning that semanage is in the policycoreutils-python
package, which isn?t installed by default in all stock configurations.

Warren Young wrote:
> Hi, just a quick note to whoever is maintaining this page:
>
>   http://wiki.centos.org/HowTos/Network/SecuringSSH
>
> The procedure is missing the firewall-cmd calls necessary in EL7:
>
>   firewall-cmd --add-port 2345/tcp
>   firewall-cmd --add-port 2345/tcp --permanent
>
> Also, it may be worth mentioning that semanage is in the
> policycoreutils-python package, which isn?t installed by default in all
> stock configurations.
Nor is setroubleshoot.

       mark

On 12/02/15 20:03, Warren Young wrote:
> Hi, just a quick note to whoever is maintaining this page:
> 
>   http://wiki.centos.org/HowTos/Network/SecuringSSH
> 
> The procedure is missing the firewall-cmd calls necessary in EL7:
> 
>   firewall-cmd --add-port 2345/tcp
>   firewall-cmd --add-port 2345/tcp --permanent
> 
> Also, it may be worth mentioning that semanage is in the
policycoreutils-python package, which isn?t installed by default in all stock
configurations.

Thank you, and copying to the centos-docs list for reference.

> On 12/02/15 20:03, Warren Young wrote:
> > Hi, just a quick note to whoever is maintaining this page:
> >
> >   http://wiki.centos.org/HowTos/Network/SecuringSSH
> >
> > The procedure is missing the firewall-cmd calls necessary in EL7:
> >
> >   firewall-cmd --add-port 2345/tcp
> >   firewall-cmd --add-port 2345/tcp --permanent
> >
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.

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.

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.

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.

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. 

-- 
Regards,

Paul.
England, EU.      Je suis Charlie.

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).

Hi,

Am 13.02.2015 um 09:48 schrieb Ned Slider:
>
>
> On 12/02/15 20:03, Warren Young wrote:
>> Hi, just a quick note to whoever is maintaining this page:
>>
>>    http://wiki.centos.org/HowTos/Network/SecuringSSH
>>
>> The procedure is missing the firewall-cmd calls necessary in EL7:
>>
>>    firewall-cmd --add-port 2345/tcp
>>    firewall-cmd --add-port 2345/tcp --permanent
added to that page.

cheers
Christoph
-- 
Christoph Galuschka
CentOS-QA-Team member | IRC: tigalch

On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen <lowen at 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.