3 ms·

>For a site focused on transparency and privacy, it's parked behind CloudFlare. I can't view the site past the about page without JS enabled and allowing CloudF

• bArray 7y ago
  > If there exists a solution to either not using cloudflare, > or some option hidden away that allows me to tell clouflare > o fuck off with how it treats traffic, I'd love to know. The method I use to avoid CloudFlare altogether (probably wrong as it's bespoke) is to do the following before "handling" the request: * Store all connecting IPs, last request time and the rate at which requests are being made in a serviced-buffer. If the request rate becomes too high, give them a timeout (return a very small page telling them to come back in a few minutes). * If database hits are high, drop non-important requests first, starting with views, then up/down votes, comments and then user security. Views and votes can fail silently and most people won't be any of the wiser. * If static content requests are high, drop generated content first, followed by large files (all JS, most CSS, images, etc). For the generated content, you can use a recently generic cached view. * Lastly, if all else fails, just return a redirect to some static server hosted somewhere strong (like GitHub pages for example), explaining that demand is high at this current time. This approach has worked for me so far. Under high load, you need to handle requests as soon as possible, even if it means not returning something. Holding onto a connection is what will sink your ship. In general most sites seem to die because they spend too long dealing with individual requests. especially when the database is hit. As soon as you overload a WordPress database for example, it's screwed. And this is just for displaying content to the website!
  • GoblinSlayer 7y ago
    Do you even need to store ips? Just count accepted connections and every, say, 1000th connection check current time, if less than a second elapsed since previous check, close the listening socket. Isn't ddos caused by packet congestion rather than server processing?
    • cc-d 7y ago
      This is exactly it. Some forms of ddos are focused on layer 7, but these are not the problem. The ddos attacks that are actually difficult to deal with are the layer 3, multi-hundred gigabit attacks. Which in our new IoT reality, are not uncommon.
    • bArray 7y ago
      > Just count accepted connections and every, say, 1000th > connection check current time, if less than a second > elapsed since previous check, close the listening socket. Then you risk killing genuine traffic. Above average hit from a handful of locations is more likely to be abuse. > Isn't ddos caused by packet congestion rather than server > processing? From what I understand, a DDoS attack any pat of your system, usually the part that is the slowest. You want to kill attacking traffic as quickly as possible without affecting genuine traffic. As for attacks on the network itself, this is where you rely on your cloud service provider.
• bArray 7y ago
  By the way, sorry for sounding harsh. You've done a good job. For lowering the costs of running, there are tonnes of pretty cheap options out there. I personally quite enjoy running my C1 instance at Scaleway [1], I get dedicated hardware, 4 ARM cores, 2GB RAM, 50GB SSD (with the option of additional storage) and 200Mb/s external network. The benefit of the C1 solution is that I can have it screaming 24/7 (mine instance really is) and the price is fixed. If you buy yourself a Raspberry Pi, you can do testing at home and then deploy your solution to the cloud with relative confidence. [1] https://www.scaleway.com/en/bare-metal-instances/ https://www.scaleway.com/en/bare-metal-instances/