Any guidelines for hardening the Nagios Core VM?

[ssax]

It looks like a fairly basic hardening guide, the problem is it entirely depends on how you have your environment set up and interact with your Nagios Core VM and what checks you are performing on the Nagios Core VM. We don't know that information so it's something that you will have to determine based on your needs and as with any hardening of a system, have documentation that states what could not be performed from the hardening standard that you've selected and why (business needs, requirements, etc) when your configuration differs from the standard.

It looks like you shouldn't really have any problems (again, this depends on any customization that you've done), other than disabling the HTTP server, more likely you will want to force HTTPS so that you can still access the web interface.

My recommendation is to take VM snapshots/backups before implementing the changes just in case you run into any issues.

[byau]

Alright, many things are covered in this doc. It looks good on face, but many of these suggestions are environment and configuration dependent.
Has your security or ops teams looked this?
Do you have any questions about specific items from the doc?

Unfortunately not a question on a specific item, it would pretty much be all items.

As an example, there is another vendor app we have installed which is based on CentOS. The vendor support team went through each section and if one particularly stood out as something we should not touch due to how their application works, he would mention it. If it seemed like something that would not affect his application, he would say so in terms of "To my knowledge, this does not affect our application and can be changed. Please realize we are not running any QA on this so it is up to you to fully QA this change" which is fine, because the answer is coming from someone who knows the internals of the application better than I do

So in this case, if someone from nagios can go through briefly with the same type of inspection: if to your knowledge you do not think it will affect nagios functionality, then let me know and the caveat on all recommendations is that it is not being run through any QA and it is still at my risk to implement the change and that I should make sure to take precautions such as snapshotting the VM or having rollback procedures in place.

Does that help?

As far as the security and ops team looking at it, that's me and the reason I'm sending this to you guys is I would prefer someone with better knowledge about nagios to take a look at the recommendations.

I very much appreciate your response! Sorry for the late response on my part!

[byau]

It looks like a fairly basic hardening guide, the problem is it entirely depends on how you have your environment set up and interact with your Nagios Core VM and what checks you are performing on the Nagios Core VM.

Yes my impression is that it is a fairly standard hardening doc. I unfortunately don't know if Nagios specifically requires certain hardening of some environment configurations to not be done. As far as how the environment is set up to interact with Nagios, that is a different department setting that up - I do not think they do anything extraordinary.

We don't know that information so it's something that you will have to determine based on your needs and as with any hardening of a system, have documentation that states what could not be performed from the hardening standard that you've selected and why (business needs, requirements, etc) when your configuration differs from the standard.

Yes, I see. That is where I would like to get recommendations from nagios. From what you know, this specifically should not be changed due to how Nagios operates. And from what you know, this is okay to change, but it is at our risk to QA the change and have a rollback plan.

It looks like you shouldn't really have any problems (again, this depends on any customization that you've done), other than disabling the HTTP server, more likely you will want to force HTTPS so that you can still access the web interface.

From what I know, little to no customization - very basic rollout.

Regarding forcing https: I did see that in the two links provided earlier in this thread:

http://nagios.sourceforge.net/docs/nagi ... urity.html
http://nagios.sourceforge.net/docs/nagi ... urity.html

I used the above as the "vendor's recommended hardening" in my document. That was very helpful. Now it's a matter of going through their hardening doc and letting them know which ones I will do and which ones I will not do based on our vendor (Nagios) responses.

My recommendation is to take VM snapshots/backups before implementing the changes just in case you run into any issues.

Yes for sure, again any recommendations on what cannot be done I can list as vendor recommends this because it may interfere with nagios functioning. And any recommendation that you believe it can be done because it likely does not interfere with nagios functioning will be done so at our own risk and our own QA

So with that in mind, would someone be able to go through the docs and give me those recommendations?

Thanks again!

[tmcdonald]

At this point I need to mention that while we are glad to help with specific questions, reviewing a 29-page document and doing a line-item response for each section is well out of scope for this forum, and is tiptoeing on consultation work.

[byau]

At this point I need to mention that while we are glad to help with specific questions, reviewing a 29-page document and doing a line-item response for each section is well out of scope for this forum, and is tiptoeing on consultation work.

Okay thank you for that answer. Any idea how much it would cost and how long it would take for consultation?

In the meantime: I'll try to pare the questions down: so I'll post a list once I have it and how about if a question can answered quickly off the top of your heads then I would appreciate an answer, if it cannot be then just state it as such. Would that be fair? I do not want to take advantage of anyone's time so hopefully that sounds fair. I'll see if I can do that.

[byau]

Tried to pare it down as much as possible. Here goes, any responses appreciated


1) Is it okay to disable the user accounts uucp, psotfix, ftp, mail, lp?

2) Any issues with locking down user accounts with password restrictions (e.g. password shall be a min of 6 chars)

3) In the /etc/ssh/sshd_config file, any problems with setting these

IgnoreUserKnownHosts yes
AllowTcpForwarding no

4) Document recommends turning these services off. Which of these can actually be turned off?

netfs
httpd (assume it has to stay on?)
mysqld (assume it has to stay on?)
postfix (assume it has to stay on?)

5) hardening doc asks to remove suid/sgid except from the below files.

/usr/bin/passwd
/usr/bin/ssh
/usr/bin/sudo
/bin/ping
/usr/bin/crontab
/bin/su
/usr/bin/agent_ctrl
/usr/bin/wall
/usr/bin/rcp

So there are a number of other SUID files and SGID dirs in place - any that you can think of off the top of your head that need to maintain the bit?
For example, I am assuming anything with "nagios" in the file name or directory name should have its SUID/SGID preserved (e.g. /usr/local/nagios/etc)

6) Any problems with the following sysctl settings being changed:

net.ipv4.conf.all.accept_redirects = 1 (doc recommends: 0)
net.ipv4.conf.lo.accept_redirects = 1 (doc recommends: 0)
net.ipv4.conf.eth0.accept_redirects = 1 (doc recommends: 0)
net.ipv4.conf.default.accept_redirects = 1 (doc recommends: 0)
net.ipv4.icmp_echo_ignore_all = 0 (doc recommends: 1)
net.ipv4.conf.all.send_redirects = 1 (doc recommends: 0)
net.ipv4.conf.default.send_redirects = 1 (doc recommends: 0)
net.ipv4.conf.all.secure_redirects = 1 (doc recommends: 0)
net.ipv4.conf.default.secure_redirects = 1 (doc recommends: 0)

Thank you

Ben

[tmcdonald]

With the understanding that these are not quality-assured, tested statements and should not be taken as such, and that *emphasis* is used:

----------
1.) uucp and lp can *probably* be disabled. Nagios may use the other three in some configurations.

2.) Password restrictions should not be a problem, just be sure that if you do change a password to meet the criteria that the appropriate changes be made in any configs/commands that use that password.

3.) These settings *should not* have an effect on the functioning of the Nagios server.

4.) netfs can *probably* be disabled. httpd is needed if you wish to view the web interface, and I *believe* Core can run without it but it is *recommended* that it be kept enabled. mysqld is needed for the ndo database and it is *recommended* that it be kept enabled. postfix may be used depending on your notification methods, and it is *recommended* that it be kept enabled.

5. & 6.) I can't off the top of my head say, one way or another, what effects might take place should anything be changed. It is *recommended* that these be kept default.
----------

Any idea how much it would cost and how long it would take for consultation?

For that you would need to speak to sales@nagios.com

[byau]

With the understanding that these are not quality-assured, tested statements and should not be taken as such, and that *emphasis* is used:

Thank you for your input. Yes I will make sure to repeat the above statement again so there is no doubt.

The understanding is any statements you (and other nagios staff) make here is to the best of your better knowledge of nagios than mine, and should NOT be constituted as nagios official word as any of the changes I am asking about are not officially QA'd by nagios. It is at my risk to implement the changes and at my own resource to QA these changes and also have a rollback plan in place.

That being said, I most definitely appreciate your input. If any other nagios folks want to give some input, I would appreciate theirs too, again under the same understanding above.

Any idea how much it would cost and how long it would take for consultation?

For that you would need to speak to sales@nagios.com

Thank you again!

[tmcdonald]

We will leave this open for a bit for further comment. Since any new replies will show up as "needs to be replied to" on our support dashboard, please refrain from comment unless it is directly adding to the conversation.

Thanks!

[byau]

Appreciate it. There hasn't been any new replies from your side. For me this is enough for me to construct the doc for our customer. You can close this thread if you like. Thank you again!