Re: [CentOS] Securing SSH wiki article outdated
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
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
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
Once upon a time, James Hogarth james.hoga...@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. -- Chris Adams li...@cmadams.net ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
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
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
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 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
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
On Feb 13, 2015, at 9:03 AM, Valeri Galtsev galt...@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: ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
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
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
On Fri, 2015-02-13 at 18:27 -0800, PatrickD Garvey wrote: On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen lo...@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. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen lo...@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
Re: [CentOS] Securing SSH wiki article outdated
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
