Secure / harden CentOS 7

iodisciple

New Member
Joined
Sep 8, 2017
Messages
23
Reaction score
12
Credits
0
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.
 
Last edited:


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.

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!
 
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.
 
Well, it's an ongoing project.

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!
 
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
 
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?
 
@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?

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.
 
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.
 
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
 
Hey guys, great feedback! :D

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

Firewalld uses iptables and iptables is what I prefer and use.

@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?

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

Members online


Top