The WHM error logs can be pretty confusing, most of all because it’s difficult to locate the right one. There are a huge number of events that take place and we have around a dozen or more locations where they are recorded, making it extremely difficult to hunt down one particular instance. This is most often encountered when a security system encounters a false positive – either you’re unable to login at all, or some script isn’t working. The first step to solving the problem is figuring out what exactly happened. Did you get locked out because of a large number of failed login attempts and therefore your IP address is blacklisted? Did you trigger some mod_security rule? If so, which one?
In this article, I’m going to show you a couple of important log file locations in WHM. In addition, I also show you how to use the SSH command line to filter one of those log files so that it’s easy to search for exactly what you’re looking for.
Let’s start with the basic log file showing us all the login errors that have occurred on our server. This way, you can see exactly which login attempt was unsuccessful, why, and from which IP address. To see this log, access the following file in WHM:
Depending on the type of file Explorer or SSH program you’re using, the output will be formatted differently, but you should expect to see something like this:
In the example above, you can see failed logins for at least two reasons as well as the IP addresses. You can also check whether or not the correct password was entered. This will allow you to get a quick overview of why the logins are failing and enable you to take corrective action.
That was a relatively easy scenario. Let’s move instead to dealing with mod_security violations, and finding out which rule was triggered and by what.
Mod_Security Violations Log
Like the one for login errors, mod_security logs are also located in a very specific place. Here it is:
However, the difference here is that this one is HUGE. It contains all the errors encountered by the Apache server as a whole. Here’s a screenshot of all the different types of log files maintained by Apache along with error_log.
You can see that the one we are interested in has a file size of 14.9 MB – and mine is an extremely inactive server! Other log files are even bigger. This size is a real problem – it makes it difficult or impossible to scroll through finding exactly what you want especially if the mod_security rule was triggered a little while before.
But this is not a new problem, and we have tools to fix it. Enter grep. Grep is a SSH command line utility that allows us to search for specific lines containing certain strings. Moreover, we can pipe the output into yet another utility called “sep” for easy formatting. A quick way to check all mod_security violations is to open up your SSH and type in the following:
grep ModSecurity /usr/local/apache/logs/error_log | sed -e 's#^.*\[id "\([0-9]*\).*hostname "\([a-z0-9\-\_\.]*\)"\].*uri "#\1 \2 #' | cut -d\" -f1 | sort -n | uniq -c | sort –n
This will print out a neat set of lines with the triggered mod_security rules in the second column as shown here:
It also provides you with the specific file or location that caused the problem, making it easy for you to troubleshoot. Last year, I had a problem with a Clientexec script that mod_security kept blocking. To find the relevant rule, I use grep and search for all lines containing the words “modsec”, “clientexec”, and 2014.
grep -i modsec /usr/local/apache/logs/error_log | grep clientexec | grep 2014 | sed "s/$/\\n/"
Each grep command feeds its output into the next one via the “|” symbol. You can chain together any number of commands in this way. For the above line, my output looks like this:
The highlighted portions give me important information as to when the errors occurred, which mod_security rule triggered it, as well as the description of the error. All of this information makes it easy for me to pinpoint the source of the problem and either whitelist a specific directory, or disable a certain mod_security rule.
So that’s how you check log files in WHM – for large ones, it’s best to access them via SSH using commandline utilities instead of downloading several megabytes with the GUI.