(untitled)

how does someone protect themselves from DDOS especially if they're running a website without cloudflare? How does lainchan do it?

>>16194 I want to run an imageboard but I don't want cloudflare to man in the middle all of my connections

>>16194 >>16195 Bump for non CF solution, I'm also curious.

>>16194 >How does someone protect themselves from DDOS You just make it as expensive as you can and then wait for them to stop.

>>16194 Why bother? For private pages just go offline for a while. Saving traffic costs beats anything you could do paying for their nonsense. Outside of that for simple spammers you can make connection establishment computationally intense. If they dont kill you with start package spam or reflection attacks(request big package from someone else and sign it with your adress) you can get them stuck processing a valid code for requesting your sites content. Lastly a dumb approach that works is if big traffic comes in just randomly kick - statistically you will hit an attacker most likely. Note this is all basic itsec 101 top of my head, i haven't used any of this as i found it never necessary.

L4 you'd buy something like an OVH but L7 protection without a CDN is difficult. It's unlikely you'll even get attacked often enough for it to matter though.

>>16194 The best way I know of is to implement a Load Balancer that handles requests asynchronously, typically with a ticketing system (asynchronous semaphore). It's not a solution, but it can mitigate the problem. Old web servers used to create one thread per incoming request. This is terrible idea, since a thread is a heavy structure in memory and context switching times are pricey. Too many incoming requests would very quickly implode your memory with many Thread objects, aborting the program, causing DDOS. Normal services will usually create a number of threads to attend requests. When a request arrives at the server's port, it is handled by an available thread. A thread will only be available once it fully completes its requests. If your server is bombarded with requests, legitimate requests will hang in there waiting until for a long time in queue. Too many requests received and your request queue might exceed memory bounds and, again, abort your program, causing DDOS. Asynchronously handling requests, though, will allow you to handle concurrently many requests before any even finish. Asynchronous tasks are objects which leave much smaller memory footprint than threads, and don't have heavy context switching times (1 thread will process many tasks). You can also implement a rate limit per IP address, and discard their requests, though this might be achieved with your firewall. I don't really think there is a simple solution to this. Nginx may provide this already? I'm not sure. But it does claim to be a proxy, which I assume is implemented this way, but I'd have to read more.

>>16210 >This is *a terrible idea >If your server is bombarded with requests, legitimate requests will hang in there waiting for a long time in queue. >memory footprint than threads *and don't have > though this can be achieved with your firewall. What the f*ck is wrong with me, today?

>>16210 Aren't the connection queues usually something along the lines of ring-buffers?

Probably a dumb idea but is it possible to have a honeypot setup to redurect an attacker to so they can waste their time?

>>16194 >How does lainchan do it? The provider it uses provides some DDoS protection. https://clientarea.ramnode.com/knowledgebase/85/Do-you-provide-DDoS-protection-How-does-it-work.html like most hosters do. But DDoS isn't really a problem if your site isn't that controversial or attracts gaymer kids. I can't provide any first hand insights as i never was the target of a DDoS. >>16210 >Nginx may provide this already? https://nginx.org/en/docs/http/ngx_http_limit_req_module.html >>17549 Depends on the attack but it's a cat and mouse game and most likely more work on your side than on the attackers.

>>16194 Purchase anti-DDOS hardware plus subscribe. Or else, just traffic flow level analysis.

>>17623 Well assuming it's a relatively large site with the resources to do make a honey pot and relatively often gets DDoSed is it actually a good option or would it be too resource intensive and inconvenient to users?

have multiple mirrors at different data centers. As soon as they target one mirror, change the DNS settings so the website is served from another mirror. Repeat until they get bored and give up.

>>17883 Say an attacker has capacity to sustain attack on N+1 points where N is number of your dormant data center mirrors, but this number will always be less than what you could afford with cheaper or free (as in beer) subscription to DDoS shielding company like Cloudflare. No matter how many times you switch, each location gets exhausted, the more times you switch, the more locations attacker learns about, and since their capacity is higher than yours, eventually you lose. The point of DDoS-ing a service is to deter it's audience from retrieving or contributing information to it. In a prolonged scenario you lose a significant portion of retrieval audience, hence losing influence over your pie slice of infosphere, or even main source of income if you provide services over Internet; prolonged denial for contributing audience (be it forum posters or article writers unable to submit articles) makes them lose collective infosphere influence manifested through your service to disseminating their collective writing, essentially either diverting their contribution effort to other services, or stopping further attempts in contribution to their areas of interest in absence of stable platform. Simply put, both forum admin and posters lose when forum is inaccessible, both editors and writers lose when newspaper site is inaccessible. An independent writer or small ad-hoc community loses the most.

- load balancer + easy horizontal scaling of backends - rate limiting requests by IP (exempt tor exits from this) with these two simple tricks you can make a ddos prohibitively expensive without cloudflare

>>17886 >load balancer You ready to shell off $100+ each month for 10Gbit connection alone? >rate limiting requests by IP RIP same ISP users >exempt tor exits from this Someone would saturate your connection through multiple connections from Tor exists out of spite inconveniencing all Tor users in the process. There have already been ddos attempts with Tor exits.

>>17887 >You ready to shell of $100+ each month It depends on the website, usually it is much cheaper than this and scaling up can be done temporarily in response to attacks. Nobody is saying you have to run 50 10gbit servers 24/7 lol > same ISP users I don't follow, you rate limit by the full IP address so only one user is affected. The goal is to have sane rates that don't affect normal users, you can have a very high ceiling for rate limits that will snag the abusive traffic without affecting anyone else, including people sharing their IP with someone else > There have already been ddos attempts with Tor exits Like when? They're way too slow for this and already busy serving the traffic of tons of other people, they are a terrible choice for DDoS. Listen, this is just what worked for me hosting a production search engine with all kinds of abusive traffic, you have to tailor your strategy based on your attacker

>>17885 you'll get fuarrrked no matter what if your attacker has more resources than you, that's kinda how DDOSes work. Cloudflare could get overwhelmed too -- they just have a *lot* of resources so only the biggest botnets could challenge them.

>>17888 most darknet markets/forums get periodically DDOSed through the tor network. Usually they're small fries compared to the huge things that you'd find on the clearnet though.

>>17891 That's different than getting DDoS'd by exit nodes, which does not happen. Onion service attacks are a different animal

>>17888 There are around 2000 exits and according to this site it corresponds to 130 Gbit of traffic right now. Divide it by two to get a rough one-way number. An attacker would inconvenience all Tor users essentially booting them off all exits and freeing bandwidth for the DoS attack enough to shut down a small forum or a medium collective blog site. http://d6amkx45augz4kskvjryv3bmmwyf7vw4k3uwxsh5egnibw2igl5aozqd.onion/flag/exit/ >>17890 It reminds of the no government - big government argument. A big government can protect you from a big outer force in case there is one, when you're on your own and there is no big governemnt to protect you, you either don't inconvenience anyone big, or you're dead.

>>17887 Tor is soykaf for DDoS because it decreases the power of an attack. Attackers want to amplify their attacks using Saudi or Chinese censorship infrastructure, not to dampen the power of their attacks with Tor.

>>17895 Tor cannot be used for DDoS, you fuhking morons. Unless your website is on a toaster. Cloudflare has literally never blocked Tor at the TCP level ONCE. This is because they never had to and never will. BTW this should also also should give you a hint about why your little "no cloudflare = ddos" meme is invalid.

>>17894 >hurr durr statism tripe or you could literally just use 90's tech instead of 60's tech, like freenet or IP*S and your content cannot be ddosed