<p>So what I do is I just redirect anything requesting a WordPress-ish thing to WordPress.com (that's what they are looking for, after all...). You can see how to do that here if you're using Nginx:</p>

<p><a href="https://github.com/nystudio107/nginx-craft/blob/master/sites-available/somedomain.com.conf#L67" rel="nofollow noreferrer">https://github.com/nystudio107/nginx-craft/blob/master/sites-available/somedomain.com.conf#L67</a></p>

CC BY-SA 4.0
2018-07-07T16:51:40.593Z
2018-07-07T16:51:40.593Z
andrew.welch
<p>We've done the redirect route in <a href="https://craftcms.stackexchange.com/a/26834/1016">Andrew's answer</a> before and while it keeps some script kiddies out, it can also cause less "savvy" ones to think you actually have a valid WP installation and continue to hit you as well, which doesn't really solve the issue.</p>

<p>nginx is so efficient that we were using a few MBps in our outgoing bandwidth just to redirect a couple offenders before I realized what was hitting our server so hard.</p>

<p>The best option is to:</p>

<ol>
<li>Detect the attempt / 404 it</li>
<li>Block it at the firewall level after they don't get the hint.</li>
</ol>

<p>While we use nginx, you can also do some of this on apache. Use:</p>

<ul>
<li><a href="https://www.nginx.com/blog/rate-limiting-nginx/" rel="nofollow noreferrer">Rate limiting</a>. Excessive bots will get detected pretty quickly here.</li>
<li>Use <a href="https://easyengine.io/tutorials/nginx/fail2ban/" rel="nofollow noreferrer">fail2ban</a> to subsequently block those repeated attempts. </li>
<li>When you create a <code>location</code> block in nginx, just tell it to <a href="https://docs.nginx.com/nginx/admin-guide/monitoring/logging/" rel="nofollow noreferrer">log</a> this sort of junk in another file. Then point fail2ban at that log file. This approach works great especially if you have multiple virtual hosts.</li>
</ul>

<p>Going down the rabbit hole even more, <a href="https://www.modsecurity.org/about.html" rel="nofollow noreferrer">ModSecurity</a> is a super complex beast and not for the faint of heart, but it's common among the big hosting providers to help keep the "riff raff" out.</p>

<p><a href="https://guides.wp-bullet.com/block-wp-login-brute-force-attacks-with-cloudflare-page-rule/" rel="nofollow noreferrer">CloudFlare</a>, <a href="https://www.stackpath.com" rel="nofollow noreferrer">StackPath</a> and <a href="https://www.incapsula.com/pricing-and-plans.html" rel="nofollow noreferrer">Inscapsula</a> can also help in this aspect with their web application firewalls if you're willing to let them handle your DNS. These services handle the request before it even gets to your server.</p>

CC BY-SA 4.0
2018-07-09T04:25:34.777Z
Yeah for sure, if there is massive traffic, blackhole'ing them is a good idea. For one client, we blackhole'd all of Russia (they had zero customers from there, and tons of bots/spammers)
andrew.welch
CC BY-SA 4.0
2018-07-08T21:18:29.100Z
2018-07-08T21:42:27.307Z
2018-07-08T21:42:27.307Z
RitterKnight
<p>Hi has anyone come across this before. It seems like a hack attempt on the site from a bot trying to access it as a wordpress site. This is obviously causing loads of errors in the log files bloating them and making it hard to find any real logs. Is there anything we can do in craft or on the server to block these attempts?</p>

CC BY-SA 4.0
2018-07-07T09:38:15.423Z
Note: this is no long term solution but for a quick fix: create the file, so those requests are not routed over Craft. Some people let the visitor download large files so the requests will end sooner or later but I would suggest to just `die()` it out.
Robin Schambach
CC BY-SA 4.0
2018-07-07T09:55:54.077Z
Cheers Robin good tip.
Lettie
CC BY-SA 4.0
2018-07-07T09:56:14.263Z
I like to set up a redirect in that file that sends them to wordpress.org/wp-login
foamcow
<logs><logging>
wp-login.php bloating log files every 20-30 seconds
# wp-login.php bloating log files every 20-30 seconds

(Asked by: username_0 on 2018-07-07)

Hi has anyone come across this before. It seems like a hack attempt on the site from a bot trying to access it as a wordpress site. This is obviously causing loads of errors in the log files bloating them and making it hard to find any real logs. Is there anything we can do in craft or on the server to block these attempts?

**Tags:** logs, logging
> **Comments:**
> **username_1**: Note: this is no long term solution but for a quick fix: create the file, so those requests are not routed over Craft. Some people let the visitor download large files so the requests will end sooner or later but I would suggest to just `die()` it out.  
> **username_0**: Cheers Robin good tip.  
> **username_2**: I like to set up a redirect in that file that sends them to wordpress.org/wp-login  

---

## 2 answers

### Answer by username_3 on 2018-07-07. Score: 3

So what I do is I just redirect anything requesting a WordPress-ish thing to WordPress.com (that's what they are looking for, after all...). You can see how to do that here if you're using Nginx:

<https://github.com/nystudio107/nginx-craft/blob/master/sites-available/somedomain.com.conf#L67>


---

### Answer by username_4 on 2018-07-08. Score: 1

We've done the redirect route in [Andrew's answer](https://craftcms.stackexchange.com/a/26834/1016) before and while it keeps some script kiddies out, it can also cause less "savvy" ones to think you actually have a valid WP installation and continue to hit you as well, which doesn't really solve the issue.

nginx is so efficient that we were using a few MBps in our outgoing bandwidth just to redirect a couple offenders before I realized what was hitting our server so hard.

The best option is to:

1. Detect the attempt / 404 it
2. Block it at the firewall level after they don't get the hint.

While we use nginx, you can also do some of this on apache. Use:

* [Rate limiting](https://www.nginx.com/blog/rate-limiting-nginx/). Excessive bots will get detected pretty quickly here.
* Use [fail2ban](https://easyengine.io/tutorials/nginx/fail2ban/) to subsequently block those repeated attempts.
* When you create a `location` block in nginx, just tell it to [log](https://docs.nginx.com/nginx/admin-guide/monitoring/logging/) this sort of junk in another file. Then point fail2ban at that log file. This approach works great especially if you have multiple virtual hosts.

Going down the rabbit hole even more, [ModSecurity](https://www.modsecurity.org/about.html) is a super complex beast and not for the faint of heart, but it's common among the big hosting providers to help keep the "riff raff" out.

[CloudFlare](https://guides.wp-bullet.com/block-wp-login-brute-force-attacks-with-cloudflare-page-rule/), [StackPath](https://www.stackpath.com) and [Inscapsula](https://www.incapsula.com/pricing-and-plans.html) can also help in this aspect with their web application firewalls if you're willing to let them handle your DNS. These services handle the request before it even gets to your server.

> **Comments:**
> **username_3**: Yeah for sure, if there is massive traffic, blackhole'ing them is a good idea. For one client, we blackhole'd all of Russia (they had zero customers from there, and tons of bots/spammers)  

---

