I checked the log files, and found these hits:

In short, it’s mod_security telling me that the text /etc/ triggered rule 950005, which should be protecting our server against malicious attempts to access local files – like the ones in the /etc directory. The access file only showed a POST to /wp/wp-admin/post.php so I had no idea where the /etc/ string was coming from. Maybe some weird hidden Javascript? Maybe something else?

This post narrowed acknowledged it to be related to mod_security and suggested to disable it permanently or just turn it temporarily off while posting. I aim to do better.

The previous post has a wonderful nugget of enlightenment about prioritizing services on Linux, and suggested a couple of changes to the Linux configuration files – most of which are located in.. the /etc/ folder. In short, I triggered mod_security rule 950005 by posting data containing /etc/.

If you ever plan to cover issues related to deployment and administration of operating system in the Unix family, this rule absolutely has got to go. Obviously it’s written with the best of intentions, but as it is doesn’t work and should be disabled.

Avoid messing with /etc/httpd/modsecurity.d/modsecurity_crs_40_generic_attacks.conf and just disable the specific rules in /etc/httpd/conf.d/mod_security.conf by adding this:

To do this, I’ve decided to use the Apache suexec option for all my scripts. I won’t go into specific details about the setup here, but present a pretty solution to an annoying problem that arises when using suexec and applying software updates for the Apache server.

If your web files are located in /var/www, you won’t need this. For security reasons, suexec is compiled with various configuration options that can’t be changed runtime – the “safe” location of scripts is one of them. If you – like me – have your web files located somewhere else, you’ll need to recompile suexec and re-install it every time you upgrade Apache. If you decide to get the entire source code tree for Apache, just for this, you’ll find yourself in a mess that could easily be avoided.

Here is my solution: Since the suexec source files themselves rarely change, I picked out exactly the files needed to compile the suexec binary and simplified the Makefile. This way, I’ve got a very small directory with the files required to build my suexec with my own configuration options, without messing with the rest of the Apache source code. As long as I remember to run make install after updating Apache, it’s all good.

First of all, you need to set up a directory for the suexec files:

Now make the changes you need to suexec.h and write a suitable Makefile:

You’ll need the apr-devel and httpd-devel packages for this to work. Remember that you need to indent with tabs in makefiles. Run make install to install:

If you’re running php-cgi and getting http error 500, your suexec probably needs to be re-installed. Remember to check the suexec logfile.

Basically he suggests to go to about:config and change the setting browser.cache.disk_cache_ssl to true. There have been issues prior to Firefox 2, but these should be fixed in Firefox 3.

If you’re running a webserver, adding the header value Cache-Control: Public will allow most browsers to automatically cache server files. If you’re paranoid, you should only add this header to scripts, images and stylesheets. Here is an example for Apache that allows browsers to cache a selected fileset for up to one week: