ModSecurity blocks the signal to the AppMon monitor (403 error)

A restrictive configuration of the web server ModSecurity plugin can block signals to the AppMon Monitor. This can result in Access forbidden (403) error codes for some web content. To prevent this issue, paste the following snippet into the Apache configuration file after the inclusion of the ModSecurity-config files.

If SELinux status is enabled and Current mode is enforcing, SELinux might block essential operations required to start the Apache Agent.

To check whether SELinux actually denies something important, take a look at the audit log. It is usually located in the /var/log/audit.log file. Denied operations are logged as type=AVC.

Right after an attempt to start the HTTPd + Agent, execute the ausearch -m avc --start recent command to look for recent audit log entries. If there are denied operations, ausearch command returns something like this:

The first entry at 10:09:13 shows that the process with the id pid=2590, and the executable HTTPd exe="/usr/sbin/httpd", which is running in the unconfined_u:system_r:httpd_t:s0 domain, is denied write access to dynaTraceWebServerSharedMemory.

The second entry at 10:09:18 shows that the same HTTPd exe="/usr/sbin/httpd is denied connection to the destination TCP port 9998 tclass=tcp_socket, dest=9998.

There are several ways to resolve this:

Disable SELinux.

Create a policy module with audit2allow.

Create a policy module manually.

Disabling SELinux

To disable SELinux, edit the /etc/selinux/config file and set the SELINUX property to disabled.

SELINUX=disabled

Reboot your system for the changes to take effect.

Creating a policy module with audit2allow

If you don't want to completely disable SELinux, you can use audit2allow to create a policy module to grant required permissions. The tool can build a policy module based on specific contents of the audit.log file. The procedure is the following:

Switch to permissive mode, by executing the following command:

setenforce 0

Executing of the getenforce or sestatus command should now indicate that SELinux is running in the permissive mode:

> getenforce
Permissive

In permissive mode, SELinux doesn't deny any access, but logs actions are denied in enforcing mode.

Disable dontaudit rules.

In certain situations, AVC denials may not be logged. A policy can silence AVC denials by using dontaudit rules. To ensure we see all denials in the audit.log file, disable the dontaudit rules with the following command:

> semodule -DB

These are enabled later.

Start httpd + Agent.
Start dtwsagent and httpd.

> ./dtwsagent
> service httpd start

Since SELinux is in permissive mode, everything should start now, but new SELinux denials are written to the audit.log file.

Create a policy module with audit2allow.

The new entries to the audit.log file can be used as input to audit2allow to create the module with the desired permissions:

> grep /usr/sbin/httpd | audit2allow -M apacheagent

Install the module:

> semodule -i apacheagent

Switch back to enforcing mode and restart HTTPd and Dynatrace Web Server Agent.

> setenforce 1

Restart HTTPd and Dynatrace Web Server Agent and everything should come up. Recheck audit log and verify that there are not any related denials.

The dontaudit rules can then be enabled again:

> semodule -B

Creating a policy module manually

You can also create a policy module manually, but is not recommended. The recommended approach is one of the two previously described: either disable SELinux completely or create a policy module with audit2allow.

Anyway, if you need to create a policy manually, the following example might help you. But it's just a demo with the purpose to show the general procedure of manual module creation.

Note

The following instructions below are verified on CentOS/RHEL 6 and with Apache HTTPd Agent only and might not be applicable to your system.

The strategy of this demo is the following:

Recursively tag all files in the installation folder with a custom type dynatrace_agent_t.

Permit full access to all files tagged dynatrace_agent_t for processes running in the httpd_t domain. This ensures that the agent can access all files in the installation folder and below, including the dynaTraceWebServerSharedMemory file.

Permit processes, running in the httpd_t domain, to connect to TCP ports.

To create a policy module, create the two following files in an empty directory:

dynatrace_agent.fc: for the security contexts that should be applied to certain files/directories.