While it’s normal for websites to attract all kinds of unwanted traffic, you can improve your website firewall. Unwanted traffic hurts server performance. It may be overkill, but I have several layers of protection. Starting from the outside, I use:
- Cloudflare – By default, Cloudflare has some general protection and security settings to stop the most obvious offenders.
- 7G Firewall by Perishable Press – This is a set of access rules that Perishable Press designed to protect against common attacks seen on WordPress sites.
- Wordfence – In addition to general attacks against WordPress, Wordfence offers more fine-grained protection against the latest exploits.
Hunting The Attackers
One way you can improve your website firewall is with Wordfence. Ultimately, this setup works quite well, but I use logs on the server to look for attack trends to block before that traffic hits the server. Let’s take a look at Wordfence’s “Live Traffic” view for malicious traffic. I only have it log security-related traffic, so that includes logins and blocked requests.
You’ll see some hits for xmlrpc, which is a WordPress remote command system. I don’t use it, so I would add this to my Cloudflare firewall rule. There are also attempts to get user info by scanning author records. Hackers use this to look for high-ranking usernames in order to try to brute-force attack those accounts. The log also reveals a setup-config attempt, which means they are looking for a fresh, unconfigured WordPress site to take over. Some attacks also look for an exposed wp-config file. So I’ll block any requests for a URL that contains “config.php”. It’s possible that an admin might have legitimate need to access such a file, so I’ve whitelisted my home IP address at Cloudflare so the firewall won’t block me.
Each log entry includes the IP address. In looking for trends, I look up the IP address at UltraTools. It may reveal the origin to be a VPS host, and I generally block those in Cloudflare’s Firewall Tools settings, as legitimate traffic should not be coming from a web host. That indicates that a malicious user has set up a server account in order to try to hack websites.
Another way to improve your website firewall is with 7G. My next step is to look at my 7G firewall logs. Since I use RunCloud as part of my hosting setup, these logs are in the webapp user’s “logs” directory, along with the other traffic logs. Again, these logs look very much like the Wordfence log. I’m looking at the URL and IP address and follow the steps from above. One common probe I see is a bot looking for files that begin with a dot. These are often environment files that may contain sensitive information. So I also block any files or paths that begin with a dot.
So now I end up with a Firewall rule that looks like this:
I’m not showing the content fields because I don’t want to show the specific text I use to block attacks on this very site. But with the string of OR statements, it’s looking to match any condition. You’ll notice a Referer statement because I’ve found there are some link exchanges that steer malicious traffic to my site(s).
Blocking Unwanted Crawlers
Another source of unwanted traffic are crawler bots. The good ones first look for a robots.txt file and respect your settings. If your robots.txt file allows that robot, they will crawl your site. Some bots are untrustworthy and either won’t even look at robots.txt, or they will look at it to find out what you don’t want them crawling, then crawl it anyway. So I’ve created another firewall rule to block these bots by User Agent String. Just like the above rule, it is a series of OR conditions for all the User Agent Strings.
I usually discover these bad bots from my server’s firewall or error logs because these bots are looking for stuff they’re not supposed to. My logs would show attempts against hidden files, outdated plugins, or any other large number of 404 errors that show up my server’s error log.