For a while now, we were noticing intermittent load spikes on the server powering a high traffic Joomla website of a client of ours. These spikes were troubling, because they were caused by neither the MySQL database nor the PHP instance; they were caused by something else, something that we didn’t know what it was until this morning…
At around 9:15 AM we noticed, by chance, that the cxswatch process was erratically appearing and disappearing in the top -d shell command during the load spikes. The process had huge processor usage, often close to 20%.
For those who don’t know, the cxswatch process is short for the ConfigServer eXploit Scanner, which is, as the name suggests, a Linux application that is used to scan directories for exploits. It is now installed by default on a WHM server, and it is somehow instrumental in finding malicious/hacked files as soon as they are uploaded/modified. Of course, this means that we cannot just disable the application in order to address the load issue, so our best option was to check the logs for “issues”. So, we logged in to WHM, and then clicked on ConfigServer eXploit Scanner in the left menu (in the Plugins section), and then we clicked on the Tail cxs Watch Log button. Here’s what we saw:
Jan 16 09:16:39 pro01 cxswatch[37473]: WARNING: '/home/[cpanel-user]/public_html/cache/com_content' scanned 6 times in the last 30 seconds, you might want to ignore this resource
The above message was there hundreds of times, but with different dates. Apparently, the Joomla cache folder is so dynamic that it is scanned very frequently, leading to unnecessary overhead, so we needed to tell cxswatch to just ignore this folder. Here’s how we did it:
- We ssh’d to the server.
-
We opened the file cxs.ignore (which is located under the /etc/cxs/ folder) using vi:
vi /etc/cxs/cxs.ignore -
We added the following line to it (note that, by default, the cxs.ignore file doesn’t exist; in that case editing it and saving it through vi will just create it):
dir: /home/[cpanel-user]/public_html/cache -
We saved the file and then we restarted ConfigServer eXploit Scanner by going back to its settings in WHM and then clicking on the Restart cxs Watch button.
-
That’s it! Once we did the above, the load was reduced substantially, especially during high activity hours when cache files were constantly being (re-)generated.
But, doesn’t disabling the cxs for the “cache” folder compromise security?
Well, not particularly, and this is because we have an .htaccess file with a deny from all line in that folder. So, even in the unlikely case where a malicious file gets uploaded to that folder, it can’t be executed. Additionally, we do have a midnight scanner that can catch malicious files and that is run on all folders.
But, what if a malicious user uploads a hacked file that is masqueraded as a legitimate cache file?
Well, doing that is not easy. You see, the names of cached files in Joomla follow a certain hash, and it is probably (much) easier to know the root password of the server than to figure out the “cache hash”.
We hope that you found this post interesting and useful. If you need help with the implementation, then we are always there for you. All you need to do is to contact us and we’ll do the work for you swiftly, professionally, and at affordable fees!