Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread Earl A Ramirez
On Fri, 2015-02-13 at 18:27 -0800, PatrickD Garvey wrote:
> On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen  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.




___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread PatrickD Garvey
On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen  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


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread Always Learning

On Fri, 2015-02-13 at 11:21 -0500, m.r...@5-cent.us wrote:

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

Changing SSH port to a non-standard port is the beginning. Restricting
access to that port to a few IPs is another layer of protection  and
then more things are done to lessen the chances of unauthorised access.


-- 
Regards,

Paul.
England, EU.  Je suis Charlie.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread Always Learning

On Fri, 2015-02-13 at 10:03 -0600, Valeri Galtsev wrote:

> On Fri, February 13, 2015 9:05 am, Always Learning wrote:

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

> Just to mention (even though someone already mentioned that): changing
> port numbers, or, say removing disclosure by the daemon what software,
> version, ... it is does not really add security. Security through
> obscurity is only considered to be efficient by Windows folks. Quite
> wrongfully IMHO.

Changing the SSH port is the *START* of extra security (no Port 22 here)
- not the end of my efforts. SSH ports are 'protected' by restricting
access from and to designated IPs.


-- 
Regards,

Paul.
England, EU.  Je suis Charlie.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread Warren Young
> On Feb 13, 2015, at 9:03 AM, Valeri Galtsev  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:
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread m . roth
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.

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

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread Valeri Galtsev

On Fri, February 13, 2015 9:05 am, 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.
>
> 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.
>

Just to mention (even though someone already mentioned that): changing
port numbers, or, say removing disclosure by the daemon what software,
version, ... it is does not really add security. Security through
obscurity is only considered to be efficient by Windows folks. Quite
wrongfully IMHO.

So, I would suggest to not do these "non-standard" things fooling yourself
in wrongful feeling of better security. But instead, maintain the daemons
updated. Keep passwords reasonably sophisticated. Do not start unnecessary
services. Defend against brute force attacks (I use "--hitcount" option of
iptabels on Linuxes and sshguard on FreeBSD). And speaking of security:
maintain system free of local exploits (update, update, update...), that
is if (when I always consider it for my systems) the bad guys are already
in, they can not successfully elevate privileges. Each of the above is
like big chapter on system security each said in one short phrase.

And most importantly, read good fundamental Unix/Linux system book, and
revisit your system configurations (from security point of view) while
reading.

Just my $0.02

Valeri



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread Lamar Owen

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


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread Always Learning

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.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread Lamar Owen

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.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread Chris Adams
Once upon a time, James Hogarth  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".
-- 
Chris Adams 
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread James Hogarth
> 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.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Securing SSH wiki article outdated

2015-02-13 Thread 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
> 
> 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.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Securing SSH wiki article outdated

2015-02-12 Thread m . roth
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

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


[CentOS] Securing SSH wiki article outdated

2015-02-12 Thread Warren Young
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.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos