Welcome to Our Community

While Linux.org has been around for a while, we recently changed management and had to purge most of the content (including users). If you signed up before April 23rd, 2017 please sign up again. Thanks!

  1. Note: we recently updated out site software, please report any unseen issues - we do this often to insure your information is secure.
    Dismiss Notice

Secure / harden CentOS 7

Discussion in 'Linux Security' started by iodisciple, Sep 25, 2017.

  1. iodisciple

    iodisciple New Member

    Joined:
    Sep 8, 2017
    Messages:
    23
    Likes Received:
    12
    Hi!

    I'm hoping you have some pointers about how to secure / harden CentOS 7. I can only find huge articles with hundreds of systems and although I like security a lot, I find it hard to believe you should implement them all ;-)

    Examples:
    https://highon.coffee/blog/security-harden-centos-7/
    https://www.linuxquestions.org/questions/linux-security-4/security-references-45261/



    So the firewalld firewall is active, SELinux is enforcing, SSH is pretty secure I think (no root access, different port, etc.)... how to go from there? I've been looking at these articles, installed and tested Rootkit Hunter, Linux Malware Detect, ClamAV and have been looking at Tripwire, Fail2Ban and others.

    Any input is greatly appreciated.
     
    #1 iodisciple, Sep 25, 2017
    Last edited: Sep 25, 2017
  2. atanere

    atanere Moderator
    Gold Supporter

    Joined:
    Apr 6, 2017
    Messages:
    1,168
    Likes Received:
    1,158
    I'm afraid I am neither a security expert, nor a sysadmin for server systems... just a plain old Linux user (with a lot of opinions). So I am certainly not a voice of authority on this topic. But I did take a look at your links and found both of them to be very educational for the goals you are setting for yourself. As you have found out... there is A LOT of stuff to learn about security, and I agree that you need not learn all of it. But you will need to focus and choose what you do think is important and to separate that from what is not important. That, in itself, depends on the system you are trying to protect.

    I like this quote from the HighOn.Coffee website you provided: "Installing CentOS 7 using a minimal installation reduces the attack surface and ensures you only install software that you require."

    So, while you are installing and evaluating some of the various tools you mention (LMD, ClamAV, Tripwire, etc)... try to be sure that they are being useful to you.... and useful enough to overcome the attack vector that they present just by being present on your system. I'm guessing that some or all of these programs have internet access, which gives them some vulnerability. And all software has bugs... so they all become another vulnerability that you must patch and maintain well. You need only to look at the recent Equifax hack (143 millions records compromised) to see what effect an unpatched application can do!

    Okay, enough of my two cents. I just didn't want your post to sit unanswered too long. Keep it up... you're on a good path, I think. Wishing you success!
     
    iodisciple likes this.
  3. iodisciple

    iodisciple New Member

    Joined:
    Sep 8, 2017
    Messages:
    23
    Likes Received:
    12
    Hi atanere.

    Thank your for your time and answer. Its really useful because it makes me think some more about it and the main point you quote from the highon.coffee website.

    I'm indeed trying all kinds of stuff but the goal is, I think, to uninstall about 95% again and stay with the most useful for me. I'm thinking for days now though, what the most important stuff should be.

    Well, it's an ongoing project. Any more input is greatly appreciated.
     
    atanere likes this.
  4. atanere

    atanere Moderator
    Gold Supporter

    Joined:
    Apr 6, 2017
    Messages:
    1,168
    Likes Received:
    1,158
    Yes, it is indeed an ongoing project... I can't see how a career in computer security can be anything but a lifelong committment. Hardware and software both are constantly changing and evolving, becoming more and more complex, never less. And stronger and stronger protection will be needed to keep up too.

    I often realize how far behind I am getting, especially with hardware. Modern CPU's and GPU's are way beyond me now since I rarely buy new computers, and I no longer work in technology. But I'm also glad now that helping family and friends with computers is just for fun, because I like to do it... and it isn't my job. :D

    Cheers!
     
    wizardfromoz likes this.
  5. iodisciple

    iodisciple New Member

    Joined:
    Sep 8, 2017
    Messages:
    23
    Likes Received:
    12
    Cheers! Have a great day!
     
  6. Lazydog

    Lazydog Member

    Joined:
    Jul 27, 2017
    Messages:
    49
    Likes Received:
    47
    atanere likes this.
  7. Rob

    Rob Administrator
    Staff Member

    Joined:
    Oct 27, 2011
    Messages:
    221
    Likes Received:
    639
    You did mention some good steps. Every server is going to be different depending on which services you're running, which ports are open, etc..

    Instead of fail2ban, i've been a fan of csf/lfd. You can read an article I wrote up here:
    https://www.linux.org/threads/install-csf-lfd-to-help-secure-your-linux-server.4360/

    Also, you may want to take out password authentication via ssh and just use ssh keys.. that way, even if they knew your password they wouldn't be able to get in.

    Good luck! :)

    Rob
     
    atanere likes this.
  8. iodisciple

    iodisciple New Member

    Joined:
    Sep 8, 2017
    Messages:
    23
    Likes Received:
    12
    Hey guys, great feedback! :D

    @Lazydog I'll look at those links for sure. Also, which firewall do you prefer? Why not firewalld?

    @Rob I've now disabled SSH password authentication, only logging in with keys. With keys, is it save to permit root login? I think I need it for rsnapshot and Ansible, to login as root... I will surely have a look at your article. I was considering, instead of Fail2Ban, to giving Suricate a try. Any experiences with that one?
     
  9. Rob

    Rob Administrator
    Staff Member

    Joined:
    Oct 27, 2011
    Messages:
    221
    Likes Received:
    639
    Yep, in /etc/ssh/sshd_config you want to change:
    PermitRootLogin no

    to this:
    PermitRootLogin without-password

    That forces keys for root.

    I haven't tried Suricate.. but have been using csf for a while. Using csf on Linux.org actually.
     
  10. iodisciple

    iodisciple New Member

    Joined:
    Sep 8, 2017
    Messages:
    23
    Likes Received:
    12
    Thanks again Rob. I've immediately reconfigured the PermitRootLogin option. I did the 'prohibit-password' option though instead of 'without-password' because the latter sounded a bit scary (but IS the same and as save as you said). ;)

    I'm going to have a look at Suricata (seems pretty difficult) and csf ASAP.
     
  11. Rob

    Rob Administrator
    Staff Member

    Joined:
    Oct 27, 2011
    Messages:
    221
    Likes Received:
    639
    Ah, prohibit-password is a new thing I believe.. looks like it is the same thing..

    https://www.openssh.com/txt/release-7.0

     
  12. Rob

    Rob Administrator
    Staff Member

    Joined:
    Oct 27, 2011
    Messages:
    221
    Likes Received:
    639
    As an update.. i'd stick with without-password for now unless you're sure it's going to work on your version of openssh.

    On my CentOS 6 lab box, it's running OpenSSH_5.3p1
    On my CentOS 7 lab box, it's running OpenSSH_6.6.1p1

    Neither will take the prohibit-password argument since that comes out in v7. If you restart sshd with the prohibit-password on a version earlier than 7, you'll get something like:

    Code:
    Starting sshd: /etc/ssh/sshd_config line 42: Bad yes/without-password/forced-commands-only/no argument: prohibit-password
     
  13. Lazydog

    Lazydog Member

    Joined:
    Jul 27, 2017
    Messages:
    49
    Likes Received:
    47
    Firewalld uses iptables and iptables is what I prefer and use.

    I would still not allow root login even with keys. People seem to forget that keys can be stolen and once someone has the keys to the kingdom you're out of luck. No one should ever log in as root unless it is absolute necessary. I still have not found a time when this was necessary to date. Use "sudo -s" to get root privileges.
     
  14. nuna

    nuna Member

    Joined:
    Aug 29, 2017
    Messages:
    36
    Likes Received:
    57
    I agree with @Lazydog. You can use an account with less privileges and sudo to root when necessary. SSH private key can be encrypted with a passphrase. SSH can be configured to use a non-standard port.

    The first source of information that comes to mind is Red Hat. They provide great guides but certainly some time and patience is required. Most of the Red Hat information can be applied to CentOS:
     
  15. iodisciple

    iodisciple New Member

    Joined:
    Sep 8, 2017
    Messages:
    23
    Likes Received:
    12
    I completely agree that permitting root login via ssh is more dangerous. Initially I configured the server to not allow it. But now there are a couple of systems, like rsync and rsnapshot, that need root access to sync/backup some core system files. Also Ansible seems to do way better with it than just a regular user. So how would you do this?
     
  16. wizardfromoz

    wizardfromoz Well-Known Member

    Joined:
    Apr 30, 2017
    Messages:
    873
    Likes Received:
    973
    Hi all. While the OP is waiting on a response to that last question …

    I am putting together for publication here soon, a thread on the uses of “elevated privileges”, also myths surrounding same.

    The thread will be covering, but not necessarily limited to, the following, and their application under Linux:

    • sudo -s
    • sudo -i
    • sudo su
    • su
    • su -
    • su -c
    • su -l
    • gksu
    • gksudo and, likely,
    • visudo
    And for those of you whom know I am a mad multi-multi-multi-booter, you would be surprised if I did not tell you that there are “different strokes for different folks” where some of the Linux “families” are concerned – for example in both Puppy and Kali, you are Root by default (and there are more).

    I won’t derail the OP’s interesting thread here, further, but I may link to the new thread from here, so that those interested may see what prompted some of my thoughts, and possibly benefit (or indeed, contradict me, and I can learn).

    Enjoy Linux, folks, and I’ll watch this thread with interest.

    Cheers

    Wizard
     
  17. iodisciple

    iodisciple New Member

    Joined:
    Sep 8, 2017
    Messages:
    23
    Likes Received:
    12
    Awesome, I'll await your thread with interest ;)
     
    wizardfromoz likes this.

Share This Page