I definitely agree bots are underserved, I have a few things I do to keep them entertained, ssh bots are tar-pitted to keep them connected but busy, my hope is that I occupy at least one thread of not the whole process.
For wp-login bots I serve them a nice chunk of random (generated by a fuzzer) html in the hopes that 1. It wastes abit of their bandwidth/memory and 2. it crashes their parser
In reality I guess bots nowadays are sturdy enough to not get stuck or crash but who knows, feels good to do something :-)
Pre "guy views html source gets home raided for haxx0ring" I'd have said "you silly!"
Now... I'd say "there shouldn't be, it's your server, people can chose to access it or not, but if the right kind of fool comes along, there's no knowing where the stupid ends."
I blocked almost all wp-login bots just using bot fight mode in Cloudflare few months ago along with some CF page rules to run an interstatial. It seems to losing effectiveness over time though, and since I do have WP-login, I wonder how I can implement something like your idea.
Maybe rename the legit login and put this in its place, but that would cause issues for redirects from the legit login link...
Change your login path to something like /custom-admin. Then create a page rule to captcha any attempt to access /wp-login. What traffic other than bots is going to go to the old login page? You can change the login link to go to the new page.
Every time I read about ssh tarpits I wish I had a reason to set up one in my VPS. Alas it's much easier to use the VPS provider's network access rules to block all incoming traffic to tcp/22 that isn't from my IP.
Why would that be? It's not even executable code: someone would need to 1.actively request it, 2.actively save it somewhere 3.actively try to extract it.
If the zip bomb explicitly targets bots it becomes not only a zip bomb, but a mitigation tailor-made to prevent abuse of your platform. Phrase it as the latter and it is probably okay.
> I’m half joking, but if we can have HTTP 418 I’m a Teapot then there is enough room in the HTTP standard for the more useful HTTP 419 Never Gonna Give You Up error code.
Actually, there was a proposal to remove the 418 code formally, but in the end it was grandfathered in. Unfortunately, unless you have convinced a lot of people to allow 419, it would be not allowed anymore (even in a April Fools' RFC) according to the established protocol of IANA controlling the allocation of error codes, and IANA no longer allow "joke" allocations unless there was an RFC clarifying why that particular code must exists in a non-joking manner (see 451, in homage to Fahrenheit 451 but is the recommended code for a informed block). Even 418 was technically only reserved in such a way that allows it to be overridden in case that a good demonstration that 418 should be the code for that error.
The thing that really disappoints me is that 418 I'm a Teapot isn’t registered—instead it’s reserved as “(Unused)”: https://www.iana.org/assignments/http-status-codes/http-stat..., https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics.... As it stands, I suspect (as one that’s been involved in a couple and examined more back in 2013–2014) that most even vaguely recent HTTP libraries that have some kind of status code enum or constants defined take their data from the HTTP status codes registry, with a single exception for 418 I'm a Teapot.
As far as a 419 is concerned, I’d argue that 418 is already suitable anyway as a joke alternative to the more serious 429/503: “wp-admin.php? I’m not WordPress, I’m a teapot!” (Similar style to the joke about one cow warning another about the mad cow disease in the area, and the other responding that it’s not not worried because it’s a helicopter.)
418 is defined in HTCPCP, an _extension_ to HTTP. That's why I never understood why people use it in HTTP. So it makes sense that it's only reserved in HTTP.
IANA controls http codes only insofar as no one has told them to knock it off yet. There's no major interop risk from conflicting (200, 400, 500) codes in the way there is for other namespaces because the semantics are essentially contained only in the first digit.
If you're aware that someone is doing penetration tests on your system, but their probing isn't significantly costing you resources, wouldn't you instead just give some generic response to not clue them into you knowing their intention? There's a lot of people who basically do that with scam callers by just leading them on and wasting the scammers time.
I used to do something along this line. If I saw a bot then I would use ACL's in haproxy to serve up some static pages from memory that contained strings their request was looking for. This of course attracted more bots. It didn't cost me anything aside from making my logs a bit more noisy, so I disabled logging for the bots. Then I found a funny side effect of shodan showing my nodes being vulnerable to many things. That was a blemish so I disabled the ACL's. In hind-sight and knowing how bot farms work it wasn't really wasting anyone's time or resources but was a fun little learning exercise.
Maybe sometimes, but you would just be the reason some random person said "Dammit my machine blue screened again." or "Why is my machine using so much ram?" The C2 machines would detect this node offline and use a different one. On the plus side, maybe a percentage of those people would re-image their machines and patch them.
You could but it's extra work to build that into the application while you could use a generic off the shelf WAF / IDS type solution that just blocks them. Won't fully stop a targeted manual attack but it is enough to make bots move on to their next target. And it slows down any manual reconnaissance work.
I like the spirit of the idea, but messing with bots and script kiddies is best kept a highly local thing.
You don't need a standardized error code to signal to a red team, you can say "hi" in a number of different ways, depending on what they're poking at. And if everyone is doing the same thing to script kiddies, well, where's the sport in that?
If the requirement is that client should follow the redirect, one should not use a 4xx status code. I think “319 never gonna give you up” is more adequate
It all seems quite scammy. They claim it's opt-in, but as a Brave user I can't find the option to opt-in or opt-out.
They look the searches you do at Google and other search engines. The search terms and the results you click on gets sent their way, including metadata from the page.
The content itself is downloaded by their bot (more like a fetcher). That bot has the user agent of a regular browser, so you won't see it.
You also can't specifically block their fetcher. It only adheres to disallow *.
For wp-login bots I serve them a nice chunk of random (generated by a fuzzer) html in the hopes that 1. It wastes abit of their bandwidth/memory and 2. it crashes their parser
In reality I guess bots nowadays are sturdy enough to not get stuck or crash but who knows, feels good to do something :-)
Tarpit instructions https://nyman.re/super-simple-ssh-tarpit/
Wp-login page https://twitter.com/gnyman/status/1181652421841436672?s=20
And I remembered another nice trick which someone else came up with, zip bomb the bots :-)
https://blog.haschek.at/2017/how-to-defend-your-website-with...