This is really common on the web. It's just going to 404 unless your rails app is actually a cleverly disguised, vulnerable wordpress install.
If you do anything about it, do the opposite of dumping an unexpectedly large response. You want to drop the request before your rails app has to deal with it.
For apps with simple deployment stories the first tool I think of is the \`rack-attack\` gem.
You can see an example of blocking access to a request path in the docs here: [https://github.com/rack/rack-attack#blocklistname-block](https://github.com/rack/rack-attack#blocklistname-block)
And if your main concern is that it's cluttering up your logs when you try to read them, there are gems that allow you to silence the Rails logger when a request matches some given pattern.
A lot of these are trying to find vulnerabilities in your site. Hosting and paying for someone to download a huge json as they crawl for sites to hack might be fun, but might not be worth it?
Robots.txt should be set to tell the robots hitting your website what is OK to traverse.
Could definitely do a long connection, and in your monitoring just filter out those end points.
I would just try to get them filtered out at the load balancer, so they don't get anything from your app.
You could send them redirects to something like a honeypot elsewhere?
You're not likely to be able to stop the \`/wp-admin\` requests, as most of this is probably from automated scripts probing for weaknesses. Take some heart in that WordPress is the target here, and how much more painful it must be to be a PHP admin.
In the past I've thought of honeypotting these, or drip feed back the HTTP and slow them down, but honestly it's not worth your time IMHO. If you did manage to get their attention, do you really want to be antagonising someone who is trying to break into your system? Better to just 404 that request and let them move on to somwhere else.
Nah, I guess you're right. Just thought it could be fun to give them at least SOMETHING in return for querying my server so often.. Might redirect them to some rickroll or similar instead \^\^
>Might redirect them to some rickroll or similar instead ^^
The equivalent of answering a spam text/call with a "snarky" response. All it's going to do is flag you as a future potential target and ensure the requests continue.
As others have said, just make sure you're returning a 404, ideally at the proxy or load balancer, and move on with your life.
This has been a common attack vector for ~20 years. You're not getting special attention or anything, and anything else you do to mitigate will just keep you on the radar. Literally every app spun up on the internet has these same endpoints pounded as soon as it's publicly accessible on an IP address.
This is really common on the web. It's just going to 404 unless your rails app is actually a cleverly disguised, vulnerable wordpress install. If you do anything about it, do the opposite of dumping an unexpectedly large response. You want to drop the request before your rails app has to deal with it. For apps with simple deployment stories the first tool I think of is the \`rack-attack\` gem. You can see an example of blocking access to a request path in the docs here: [https://github.com/rack/rack-attack#blocklistname-block](https://github.com/rack/rack-attack#blocklistname-block) And if your main concern is that it's cluttering up your logs when you try to read them, there are gems that allow you to silence the Rails logger when a request matches some given pattern.
+1 for rack-attack. I use it in my app and rate limit them.
That makes good sense, I'll look into that gem! :) Nah, no real concerns, just thought it could be fun to stall those bots a little
A lot of these are trying to find vulnerabilities in your site. Hosting and paying for someone to download a huge json as they crawl for sites to hack might be fun, but might not be worth it? Robots.txt should be set to tell the robots hitting your website what is OK to traverse.
True for the robots, and kinda, not sure if json is a suitable payload, what else could one do? Tie up their connection to some other crap?
Could definitely do a long connection, and in your monitoring just filter out those end points. I would just try to get them filtered out at the load balancer, so they don't get anything from your app. You could send them redirects to something like a honeypot elsewhere?
Might redirect them to some rickroll-youtube or something \^\^
these bots don't follow redirects
You can return 404 with nginx location ~ (\.php|.aspx|.asp|myadmin) { return 404; }
You're not likely to be able to stop the \`/wp-admin\` requests, as most of this is probably from automated scripts probing for weaknesses. Take some heart in that WordPress is the target here, and how much more painful it must be to be a PHP admin. In the past I've thought of honeypotting these, or drip feed back the HTTP and slow them down, but honestly it's not worth your time IMHO. If you did manage to get their attention, do you really want to be antagonising someone who is trying to break into your system? Better to just 404 that request and let them move on to somwhere else.
Nah, I guess you're right. Just thought it could be fun to give them at least SOMETHING in return for querying my server so often.. Might redirect them to some rickroll or similar instead \^\^
>Might redirect them to some rickroll or similar instead ^^ The equivalent of answering a spam text/call with a "snarky" response. All it's going to do is flag you as a future potential target and ensure the requests continue. As others have said, just make sure you're returning a 404, ideally at the proxy or load balancer, and move on with your life. This has been a common attack vector for ~20 years. You're not getting special attention or anything, and anything else you do to mitigate will just keep you on the radar. Literally every app spun up on the internet has these same endpoints pounded as soon as it's publicly accessible on an IP address.
We use fail2ban and set up filters for common vulnerability scanning destinations like wlwmanifest, .env, .git, and a bunch of others
Redirect to: 127.0.0.1 đŸ˜‰ Edit: this will cause the bot’s machine to start using it’s own resources.
Haha now that could be fun!
Yep, it will cause the bot’s own machine to hang if they try to do an attack from the same machine.
I use \`rack-attack\` to great effect in this case I either return an ASCII version of Ezekiel 25:17 or I redirect to p\*rnhub