Securing SSH Wiki Article Outdated

Home » CentOS » Securing SSH Wiki Article Outdated
CentOS 13 Comments

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.

13 thoughts on - Securing SSH Wiki Article Outdated

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

  • Once upon a time, James Hogarth said:

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

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

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

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

  • 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
    ++++++++++++++++++++++++++++++++++++++++

  • Always Learning 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. mark

  • “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:

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

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

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

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