How to Check if a Client Hosting & IP is Blocked in Mod_security2 Logs on AlmaLinux 8 VPS with DirectAdmin Print

  • 0

Mod_security is an essential security module for Apache, Nginx, and IIS web servers that helps protect your website from various attacks. If you're experiencing issues with a particular client's hosting or IP address, it's possible that they have been blocked by mod_security2. In this article, we will guide you through the process of checking if a client hosting and IP is blocked in the mod_security2 logs on an AlmaLinux 8 VPS with DirectAdmin installed.

Step 1: Access your AlmaLinux VPS via SSH
To begin, you'll need to access your AlmaLinux VPS using an SSH client, such as PuTTY or your terminal. Use your server's IP address, SSH port, and your login credentials (username and password or an SSH key) to connect to the server.

Step 2: Locate the mod_security2 log file

Navigate to the Apache logs directory: The default location for Apache logs on AlmaLinux 8 is /var/log/httpd/. Use the cd command to navigate to this directory
cd /var/log/httpd/

Check the mod_security logs: The mod_security logs are usually named modsec_audit.log or modsec_debug.log. You can use the ls command to list all the files in the current directory and locate the log files:

The default location for the mod_security2 log file is `/var/log/httpd/modsec_audit.log` for Apache or `/var/log/nginx/modsec_audit.log` for Nginx. However, this location may vary depending on your server's configuration. You can also check the DirectAdmin configuration file at `/usr/local/directadmin/custombuild/custom/mod_security.conf` to confirm the log file's location.

Step 3: Search the log file for the client's IP address/Client Domain

View the contents of the log files: You can use commands like cat, less, or tail to view the contents of the log files. For example, if you want to view the last 50 lines of the modsec_audit.log file, use the following command:

tail -n 50 modsec_audit.log
If you want to search the log file for specific keywords (e.g., your domain name), you can use the grep command:

grep '' modsec_audit.log

To search for higher severity levels in the log file with grep, you can use the -E option which allows for extended regular expressions. In your case, you might want to search for "ERROR" and "CRITICAL" severity levels. Here is an example:

grep -E 'ERROR|CRITICAL' modsec_audit.log | grep ''

To check if a particular client's IP address is blocked in the mod_security2 logs, use the `grep` command to search for the IP address in the log file. Replace "client_ip" with the actual IP address you're investigating:

grep "client_ip" /var/log/httpd/modsec_audit.log

If the IP address is found in the log file, it means that the client's hosting and IP may have been blocked by mod_security2.

Step 4: Analyze the log entries
Examine the log entries related to the client's IP address to understand why it was blocked. Look for any mod_security2 rule IDs and messages that indicate the reason for the block. You may see entries like the following:

Message: Access denied with code 403 (phase 2). Pattern match "^(?:application\\\\/x-www-form-urlencoded(?:;(?:\\\\s*charset\\\\s*=\\\\s*\\\\S+?)?)??|multipart/form-data;\\\\s*boundary=(?:'[^']{0,200}'|\"[^\"]{0,200}\"|[A-Za-z0-9'()+_,./:=? -]{0,200}))$" at REQUEST_HEADERS:Content-Type. [file "/usr/local/directadmin/custombuild/custom/mod_security.conf"] [line "18"] [id "960010"] [msg "Request content type is not allowed by policy"] [severity "WARNING"]

In this example, the client was blocked due to a rule with ID "960010" and a message stating "Request content type is not allowed by policy."

Step 5: Modify mod_security2 rules (optional)
If you determine that the client's IP was blocked due to a false positive or overly aggressive rule, you may consider modifying the rule's settings or disabling it entirely. You can find the specific rule in the DirectAdmin configuration file at `/usr/local/directadmin/custombuild/custom/mod_security.conf`. Edit the file, make the necessary changes, and save your modifications.

Step 6: Restart the web server
After making any changes to the mod_security2 rules, restart your web server (Apache or Nginx) for the changes to take effect:

For Apache:

systemctl restart http

Note: If you are unable to locate the mod_security logs in the /var/log/httpd/ directory, check your Apache or DirectAdmin configuration files to determine the custom log location. The configuration files can be found at /etc/httpd/conf/ or /etc/httpd/conf.d/.

Was this answer helpful?

« Back