Hi everyone!

My Web Application Firewall, through the WordFence security plugin, has just alerted me about over 150 attacks in the past ten minutes.

The logs show that the attacker is attempting to access the wp-config.php file. How is this possible? Only the owner and the owner's group have read access, and web server access is also restricted:

<files wp-config.php>
order allow,deny

deny from all

</files>
Every client gets a response that says - You are not authorized to view this file on this server. Also, the WAF is active.

Thanks in advance for any help!

It's great that your Web Application Firewall (WAF) like Wordfence is detecting and blocking these attacks, but let's dig a bit deeper into why this is happeneing and how we can ensure everything is locked down even more tight.

Why are they targeting wp-config.php?: This file is like the crown jewels for a WordPress site. It contains your database connection details and other sensitive information. Attackers often try to access this file to see if they can exploit any misconfigurations and gain entry into your website. However, the fact that they're trying doesn't mean they're succeding.

Access Control Mechanism: The directive <files wp-config.php> with order allow,deny and deny from all should indeed prevent access to wp-config.php from the web. What this does is instruct Apache to deny all HTTP requests to the wp-config.php file. It sounds like it's correctly setup since every client gets the "You are not authorized to view this file on this server" message.

Wordfence Alerts: Wordfence is probably flagging these attempts based on patterns of behavior rather than actual successfull access. Attackers may still be making the requests, but because of your .htaccess rules, they're getting denied. Wordfence logs these attempts because it's a good way to keep track of who's trying what.

Could there be other ways in?: Even if direct access to wp-config.php is blocked, attackers might still try to exploit other vulnerabilities to read this file indirectly. For example, if there is another vulnerability in a plugin, theme, or even the WordPress core itself, an attacker could potentially use that to read files on the server.

Check File Permissions: While you mentioned only the owner and owner's group have read access, it's worth double-checking the permissions. For wp-config.php, the permission should ideally be 640 or 600, meaning only the owner can read/write, and the group (if set to 640) can read, but everyone else has no access at all.

Securing the Server Environment: Ensure that your server is patched and up-to-date. Any outdated software, whether it's the web server itself or other services running on the server, can be exploited.

Consider Server-Level Protection: Besides the .htaccess file, think about using server-level configurations, such as those available in Nginx or Apache configs outside of the .htaccess. These are harder for attackers to tamper with if they somehow get limited access to the server.

Backup Regularly: It's always good to have regular backups of your wp-config.php and other critical files. If something does go wrong, you can restore your site to a secure state.

Analyze the Logs: If you're seeing a high volume of requests to wp-config.php, analyze your server access logs to see if there is a pattern, like a specific IP address or user-agent. You could use fail2ban or another IP blocking mechanism to temporarily ban these IPs after a certain number of requests.

Reinforce WordPress Security: Beyond wp-config.php, make sure all other files and directories are secure. Use a security plugin to scan for any vulnerable plugins/themes and keep your WordPress and all components updated.

WAF Configuration: Ensure that Wordfence or any other WAF you're using is configured correctly and is up to date with the latest rulesets. Sometimes, misconfigurations can lead to bypasses or insufficient protection.

It's a cat and mouse game with security, so staying ahead and maintaining a robust, multi-layered security approach is key.

Ther is this wp-config.php thats not cald. The skript dont show wich file is cald at al. Its a poyntles chek. Its laik, why bother? You kan just ignore it and go on with the rest of the kod.

I meen, I've seen this befor. Wen you arnt a programmmer, its hrd to undorstand whats goin on. You just see a bunch of kod and you dont no whats hapning. But thats ok. You kan stil lern. You kan stil figger it out.

Check through the logs to figure out which address they are trying to access and if there's actually a script located there. Also, ensure the script permissions are correctly set, cause sometimes it might be a permissions issue.