modsecurity_enabled in 1.690

[sparek]

I upgraded a server from 1.689 to 1.691 and then updated Apache to 2.4.66.

In doing so, mod_security was not enabled after the Apache recompiled. I had to remove some mod_security related directives from some included files to get Apache to restart and then I had to investigate why.

1.690 introduced a new modsecurity_enabled directive in the directadmin.conf file. I suspect that this is where the issue lays.

I especially like the description of this new directive:

This new configuration option controls if the web server templates should include the configuration directives for ModSecurity.

Server administrators do not really need to care about this option. The CustomBuild will automatically set this option to the correct value when ModSecurity is being used.

If there's no intervening required by the server administrator... why is it a configuration option?

At any rate, modsecurity_enabled was set to 1

# /usr/local/directadmin/directadmin config-get modsecurity_enabled
1

But mod_security was still not being enabled.

Looking at another server that is still on 1.689, I found that the file /etc/httpd/conf/extra/httpd-phpmodules.conf was including another file:

Include /etc/httpd/conf/extra/httpd-modsecurity.conf

And this line is missing in the /etc/httpd/conf/extra/httpd-phpmodules.conf file on the 1.691 server. So I added that back.

Then restarting Apache balked because /usr/local/lib/libxml2.so did not exist. And sure enough in /etc/httpd/conf/extra/httpd-modsecurity.conf was a reference to:

LoadFile /usr/local/lib/libxml2.so

I checked this on the 1.689 server and it has the path:

LoadFile /usr/lib64/libxml2.so

So I updated the /etc/httpd/conf/extra/httpd-modsecurity.conf file to load the proper libxml2.so library on the 1.691 server and Apache restarted with mod_security.

I haven't updated any of my other servers to 1.691 (they are all on 1.689 right now). So I don't know if this is just a one off issue with this particular server. Or if something isn't playing nice with the modsecurity_enabled setting. I have some reservations about updating other servers until I can get an explanation as to why mod_security is not being included in the Apache configuration.

Additionally, the /usr/local/directadmin/custombuild/options.conf file also has modsecurity as being enabled, with:

modsecurity=yes

So I don't really know how DirectAdmin is missing that mod_security is enabled.

If nobody else is having this problem, then where is mod_security suppose to be included in Apache? There's a maze of configuration files for Apache, so trying to track down where something is being included can be difficult. All I can go on is based on 1.689 servers that still have mod_security working with Apache.

 

[nsc]

You have custom files in your /usr/local/directadmin/custombuild/custom/ap2/conf/ directory. Please note, as soon as you start customizing the configs - you become responsible tracking the changes.
Recommendation is to review the configs (diff with the current configs in /usr/local/directadmin/custombuild/configure/ap2/conf ) or remove the customizations completely.

Keypoints related to your situation that got changed:

• libxml2.so is not used in apache configs anymore - your custom config likely still does.
• the httpd-modsecurity.conf is now included with the httpd-modsecurity-enable.conf that gets generated dynamically, not with the httpd-phpmodules.conf - so this part is expected to work this way.
• httpd-modsecurity-enable.conf is always included by the httpd.conf - you probably have this file custom as well, that would explain why modsec config was not included on your server.

 

[romans]

To find all your DA customization you can try running such command:

find /usr/local/directadmin/ -name custom | xargs ls -la

and then inspect every "custom" folder and files related to WEB/Apache in it (there should not be files with "custom" name, only if they were created accidentally).
If there are too much data and the command is running for a long time, you can try such one:

find /usr/local/directadmin/ -maxdepth 3 -name custom | xargs ls -la

 

[sparek]

@nsc @romans
Indeed this was the case. I should have thought of this.

I actually do have a custom file monitoring system in place. I wrap the DirectAdmin update (I don't do automatic updates) in a script that captures the parent of customized files before updating and then captures those files after the update and compares them for changes.

But, I didn't have this system set to email me when differences are found. So I assumed nothing changed or I didn't have that trigger to check for changes.

I have updated my wrapper to send an email when differences are found.

Thanks for the heads up on this.