New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
How some bots with chronium for e.g. will be blocked by Javascript challenge without any human interraction?
Even Cloudflare cannot effectively block most bots using Chromium. What matters is that high-scale attacks at L7 are not possible because almost all, if not all, devices enslaved in the DDoS botnet cannot handle Chromium, nor can they solve the proof-of-work task due to their weak hardware.
POW challenges can be set to mine some X coin. This means when you visit such site you will expend some cpu resource. For average user this is not a problem. For bots this is a massive problem due to limited resources each bot have. Nice concept.
Could be an issue for android phones too
Damn boy, avg user has 8 core monsters at their hand.
I like to think that so long as the average human could calculate it without pen and paper, an android probably could too
See:
1. You force bot into doing calculations
2. If that bot is actually a single dedi using thousands of proxies, THEN it is spending precious time for CAPTCHA => losing actual attack power (lowers requests/second ratio)
3. If this is a botnet, you can't use IoT as they are too constrained to run chromium
4. If attacker is trying to just flood your captcha endpoint with random junk, you can confidently ban them on first error
Given the above, attack cost is increased insanely
Yep
You simply make it too expensive to take you down
Thankfully, attack power scale with size, so if you’re a loser with 5 daily visitors, you likely don’t have to spend too much time and resources increasing the cost to take you down
Once you’re Cloudflare, you have to do that, but, you also got the resources to do it
it will be completed and presented in February 2023.
Too late to edit it, but yeah - I've got you point - 2023 != 2024.
Using CAPTCHA/hCAPTCHA will inevitably make users impatient, especially the latter. From my personal experience, there are only two reasons for losing patience - 1. The verification cannot be solved in a short time (for example, CAPTCHA always allows you to select an item in a pile of photos and constantly refreshes the photos) 2. Selection The correct image range (correct in the human sense) was obtained, but the verification code thought this was wrong and required re-verification.
In contrast, Cloudflare's turnsite verification is very good. It handles verification automatically most of the time, and even if it is done manually, it can automatically handle the entire verification process with just one click.
Obviously, the user's patience depends on how the verification is done - manual/automatic, zero-interaction verification obviously wins in this comparison (an additional sentence, as far as I know, currently, whether it is CAPTCHA, hCAPTCHA, Turnsite, There are L7 attacks that can be bypassed, although I don't know how they do it)
So if you asked me: "what kind of puzzle would you like to solve when entering a website for the first time so that it is not very disturbing for you" I would answer: "No need for me to do anything"
In addition, I think @tentor is right, you don’t need to completely stop the bot flood, you just need to make the cost of attack rise to a point that is unacceptable to attackers, while at the same time acceptable to normal users. Proof-of-work is a very good idea. It does not require human participation and at the same time can better increase the attacker's cost.
Based on these, if we look at preventing L7 attacks in a simple way, it is nothing more than three steps: distinguish robots from humans, stop robots, and stop robots that have broken through the first step/increase its attack cost.
There are already very mature solutions on the market for distinguishing robots from humans, such as various CAPTCHAs, Javascript challenges, etc., and just like spears and shields, the emergence of AI image verification makes various graphical verification codes no longer reliable. Another relatively feasible solution might be behavioral verification, such as requiring users to slide a slider to verify (there are many Chinese Internet companies doing this).
There doesn't seem to be much that can be said about stopping bots, and spoofing IP sources seems to be common in attacks, but machine learning may be useful if attack data can be collected and behavioral patterns analyzed.
So I think the focus of the work is how to solve attacks that bypass the distinction.
The first is rate limiting. It is obviously impossible for a normal visitor to continuously request the same URL once per second for more than 30s/minute (even if it is really a human, such requests should be blocked). Rate limiting is equivalent to setting a resource usage limit for each visitor. Requests that exceed the allowed usage limit will not be accepted by the server.
Then there is the behavioral logic. It is impossible for a normal visitor to continuously access a single specific URL, especially a URL that takes up a large amount of resources (such as continuously submitting POST to the registration interface. Generally speaking, attackers like to do this because it will Improve attack efficiency)
Then there is the miniaturized proof-of-work. Generally speaking, performing small mathematical calculations in normal requests will not affect the user's device, but for the attack initiator, these mathematical calculations will accumulate into a tower. Increase the cost of attacks/reduce the effectiveness of attacks. It should be feasible to insert verification for small calculations into some page requests that require large resource consumption (registration, login) (it does not need to be too complicated, because this will affect latency and page loading speed)
Sorry, no. That would drive many potential customers away with certainty, at least here in Europe.
It might not look like much but I think that's tough one. Because you can't ignore privacy, lots of related/data/citizen protection law, (not really) rare bio/medical factors (e.g. colour blindness), plus, and that might be bigger an obstacle than you may think, intelligence and "puzzle capability" (for diverse kinds of puzzles) is by no means evenly distributed.
At the same time AI and cheap labour are very powerful factors.
Nope, @tentor has a strong point there. In cryptography we often use that; "server relieve" is just one example.
Yes, this is a good element. Reason: for a user "loosing" say 100 ms and wasting say a few hundred mio. CPU cycles is a very low entry barrier. For someone doing millions of attempts ("[D]DOS") though it's a price tag that in the vast majority of cases is not worth it.
Everytime someone needs to KYC, a child in africa dies.
The Apps and Web applications to do a KYC are such a piece of shit.
They crash on you, the entire browser crashes, firefox, chrome.
The Apps you use on your phone crash.
The easiest way, these days, is to go physically to a store, bring your ID to do KYC.
If the App does not crash, then you either wait ages until someone picks up the call and does
actually a KYC on you or they complain about the camera quality on your ID or the stream is actually so fucking bad, that you just end the call after waiting ages.
I never did a KYC for a fucking VPS, never will do one, pain in the arse.
I guess nginx lua waf is good enough https://github.com/C0nw0nk/Nginx-Lua-Anti-DDoS
This is one component of my bachelor thesis.
This is what I would like to improve.
Lua is a bad choice for high-load scenarios like DDoS protection. I have personally faced a few segfaults within libluajit-5.1 under heavy attacks when using openresty.
But yeah, generally it will do its' job fairly well.
I think this would surely make the boomer antiviruses block your website
My idea is to do like an animated dice roll using js and css. To pass you must move your pawn the number of times that the dice rolled
Fun for users, cpu consuming to bots due to the animation
Be sure to make your challenge in a such way that it can't be easily bypassed without actually executing your JS
Really? I haven't encountered any issues with Lua before. I've used it in conjunction with UFW to manage high concurrent requests effectively. Following config worked great for me.
Firewall may help only in case when there is high concurrency per single IPv4 address or /64 IPv6 prefix, but not otherwise.
Unfortunately I don't have much details on those segfault cases anymore, but I've never faced them when trying to reproduce myself.
However you wouldn't argue that C module for nginx will have much better performance comparing to Lua one. Furthermore, you can apply strict sanity checks to it to ensure that there is no memory issues.
I strongly agree. C module has unbeatable performance, which is why I favour C/C++/C# as programming languages. However, for personal projects, I've shifted to Caddy due to its Go-based syntax, which bears resemblance to C modules, allowing me to create usable plugins with ease.
Proof of concept:
Hey!
This Anti-Bot protection is LIVE on https://hazi.ro/
What I still have to improve (in my opinion):
If you have other suggestions, they are welcome.
Thank you!
design is hella weird on mobile.
I will be thankful if you can attach a screenshot.
Get rid of this crap if you want any visitors to the website. Let alone orders.
I don't want to do anything, except visit site, see 10USD/year 1c/1g/20gb/1gbps offer and click buy.
I have browser plugins which fills up form automatically, I have plugin which saves my CC and in 1-click pays for invoice.
Minimal effort to consume. Your solution disrupts this and therefore will bancrupt you.
Considering that the puzzle must be solved once every 24 hours, I am convinced that it would never stop you from accessing the content you are really interested in.
Thanks for the feedback anyway!
I have "The connection has timed out"
Never had that on my tests.
May I have a screenshot, please?