[HN Gopher] Show HN: "HTTP 419 Never Gonna Give You Up" for bots
___________________________________________________________________
Show HN: "HTTP 419 Never Gonna Give You Up" for bots
Author : bradgessler
Score : 49 points
Date : 2021-10-27 05:41 UTC (1 days ago)
(HTM) web link (bradgessler.com)
(TXT) w3m dump (bradgessler.com)
| nunez wrote:
| a part of me is definitely in favor of this, but another part of
| me wants to avoid turning http error codes into a meme
| dane-pgp wrote:
| No, this is turning a meme into an HTTP error code. You're
| thinking of:
|
| https://i.redd.it/wmwqgt9kbop41.jpg
| dmitrijbelikov wrote:
| https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#Unof...
|
| 419 Page Expired (Laravel Framework) Used by the Laravel
| Framework when a CSRF Token is missing or expired.
| [deleted]
| ufmace wrote:
| Probably shouldn't be made an official thing, but it'd be funny
| to do this on all the various minor manually-adminned sites out
| there.
| andrethegiant wrote:
| If it redirects then it should be in the 3xx class
| willcipriano wrote:
| 400's are errors caused by the client, I think that fits
| better.
| willcipriano wrote:
| This collides with Laravel's informal use of the 419 status code
| for "Page Expired"[0]. I think this one is more valuable though.
| What about 445 or 455? I don't see anyone using those.
|
| I humbly propose:
|
| 455 - My kung fu is stronger than yours
|
| [0]https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
| Slade1 wrote:
| 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.
| Waterluvian wrote:
| Redirect to a honeypot as a service that utterly wastes
| someone's time.
| LinuxBender wrote:
| 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.
| verdverm wrote:
| I wonder if zip bomb like responses will still work for the
| majority of bots
|
| https://blog.haschek.at/post/f2fda
| t0mas88 wrote:
| 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.
| saurik wrote:
| Blocking someone is still more generic than returning a
| specific HTTP response code specifically designed to inform
| the other party of your suspicion.
| hyperman1 wrote:
| Send them redirects to a russian governemental site. They'll
| take care of it
| arthurcolle wrote:
| This could be seen as abuse by the .ru and .su folks
| gnyman wrote:
| 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 :-)
|
| 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...
| SCHiM wrote:
| Although I think bots should be free to access the same content
| as humans do, I have a suggestion for your fuzzer anti-bot-
| spray:
|
| It won't work on the more sturdy samples, but maybe try a GZIP
| bomb on https streams:
| https://www.infosecmatter.com/metasploit-module-library/?mm=...
| zinekeller wrote:
| > 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.
| [deleted]
| unanswered wrote:
| 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.
___________________________________________________________________
(page generated 2021-10-28 23:00 UTC)