Nagios Installation Failed

[rajasegar]

Hi,

We are trying to prep a new instance of NagiosXI 5.2.5 on Centos 6.7 64bit using the latest harderning setting.
However the installation just fails.

Can you please see you can detect what is the problem?
I have included the harderning checklist. If someone can narrow down things to undo it would greatly help me out.
Alternatively I need to disable the harderning one by one and it is going to take ages.

Install and hardern later is not an option.

Attached is the install log which I tried a few times.
So far tried disabling SE Linux still same problem.

install.zip

Red Hat 6 Harderning.docx

[rajasegar]

Looks like E-importnagiosql is failing because there is no files to import in /usr/local/nagios/etc/import

Code: Select all

[root@MYUCBPNAGIAPP01 nagiosxi]# ./E-importnagiosql
httpd: no process killed
Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using 10.17.18.228 for ServerName
                                                           [  OK  ]
Sleeping...
NOTE: If prompted, enter the MySQL root password
NagiosQL database appears OK - continuing...
NDOUtils database appears OK - continuing...
ERROR: No files to import - exiting.  Were Nagios Core and NagiosQL installed?

[root@MYUCBPNAGIAPP01 nagiosxi]# ls -l /usr/local/nagios/etc/import
total 0

[tmcdonald]

This is simply not going to be something we can support.

At 62 pages long I am not going to address every point, however on various pages I see the following that jumped out:

• Set noexec on /tmp
• Remove HTTP server
• Set Sticky Bit on All World-Writable Directories
• Remove xinetd
• Modify cron permissions
• Set password expiration days

Any of the above will/may affect either the installation, running, or later troubleshooting of the system. A good chunk of the doc probably will not affect anything (auditd settings, for example) but most things we just haven't tested (or can't). While I am always happy from a security standpoint to see documents this thorough, from a support standpoint this is well beyond what we can work with.

If you can work through some of the above on your own and at least get XI running, we can *maybe* troubleshoot issues down the road, but this is basically an environment in which no assumptions can be made, so we can make no guarantees as to the stability of the system, or our ability to resolve issues.

[scottwilkerson]

The original install errored with the following

Code: Select all

Unable to open main config file '/usr/local/nagios/etc/nagios.cfg'

Can you show the following permissions

Code: Select all

ls -l /usr/local/nagios/etc/nagios.cfg
ls -la /usr/local/nagios/

[rajasegar]

This is simply not going to be something we can support.

At 62 pages long I am not going to address every point, however on various pages I see the following that jumped out:

• Set noexec on /tmp
• Remove HTTP server
• Set Sticky Bit on All World-Writable Directories
• Remove xinetd
• Modify cron permissions
• Set password expiration days

Any of the above will/may affect either the installation, running, or later troubleshooting of the system. A good chunk of the doc probably will not affect anything (auditd settings, for example) but most things we just haven't tested (or can't). While I am always happy from a security standpoint to see documents this thorough, from a support standpoint this is well beyond what we can work with.

If you can work through some of the above on your own and at least get XI running, we can *maybe* troubleshoot issues down the road, but this is basically an environment in which no assumptions can be made, so we can make no guarantees as to the stability of the system, or our ability to resolve issues.

I understand where you are coming from but Enterprise environments are all like that and it is going to get worse.
Thanks a lot for your pointers, we will look into it first.

It would help if Nagios could have a faq on what we should not harden, like SE Linux being enabled etc.

Thanks

[rajasegar]

The original install errored with the following

Code: Select all

Unable to open main config file '/usr/local/nagios/etc/nagios.cfg'

Can you show the following permissions

Code: Select all

ls -l /usr/local/nagios/etc/nagios.cfg
ls -la /usr/local/nagios/

Code: Select all

[root@MYUCBPNAGIAPP01 nagiosxi]# ls -l /usr/local/nagios/etc/nagios.cfg
-rwxrwxr-x. 1 apache nagios 5670 Mar 23 12:39 /usr/local/nagios/etc/nagios.cfg
[root@MYUCBPNAGIAPP01 nagiosxi]#

The listing below is from the instance that is working fine. Only difference seems to be that missing . at the end of the permissions.

Code: Select all

[nagios@nagiosprodxi2 cfgprep]$ ls -l /usr/local/nagios/etc/nagios.cfg
-rwxrwxr-x 1 apache nagios 5815 Feb 26 08:45 /usr/local/nagios/etc/nagios.cfg
[nagios@nagiosprodxi2 cfgprep]$

Thanks for your assistance Scott.

[lmiltchev]

Can you also show the output of the following commands?

Code: Select all

ls -lad /usr/local/nagios/
ls -la /usr/local/nagios/

[tmcdonald]

The listing below is from the instance that is working fine. Only difference seems to be that missing . at the end of the permissions.

That's SELinux: http://superuser.com/questions/230559/w ... with-chmod

But since you said you disabled that already, it is hard to say why the installer can't read that file. This is what I meant earlier about support and making assumptions, since anything in those 62 pages could, potentially, be the culprit.

It would help if Nagios could have a faq on what we should not harden, like SE Linux being enabled etc.Thanks

I think instead of a blacklist of what cannot be modified, a better approach would be a whitelist of what can be modified, and this has been on my TODO list. A blacklist would be nearly impossible to write, since there are an almost infinite amount of modifications that could be made to a system. However, a whitelist would be only the things we have either tested ourselves, or that we have seen implemented enough times to know it will not cause any issues.

[eloyd]

I'm jumping in here because we get asked this all the time. You can't simply follow someone else's directions for hardening a system without knowing what the results will be for your specific installation. For instance, "Remove HTTP server" will pretty much kill any chance of you being able to use Nagios XI, as it is configured, managed, and used through a web server.

So you need to understand what steps are required for your configuration that would override any generic hardening document. In a nutshell, Nagios is a web application that makes use of databases, filesystem pipes, outbound connections to other machines, and various third-party software for tasks like graphing, reporting, and capacity monitoring. Anything that impedes its ability to use these broad categories of topics should not be done.

Edit: Even if they were written specifically by your company, it still would make no sense to disable a web server for a web app.

[tmcdonald]

Please update us when you have the output that @lmiltchev requested. I do need to stress that the scope of support we can offer is going to be impacted by the steps taken in that document, and there are no guarantees as to the functionality of the software even if it does properly install.