<story><title>Ask HN: How do you handle DDoS attacks?</title><text>For owners of small websites running on DigitalOcean, GCP or AWS, how do you handle DDoS and DoS attacks?&lt;p&gt;For context, while exploring the load testing tool Siege running on a VPS, I was able to bring down multiple sites running on shared hosting, and some running on small VPS by setting a high enough concurrent number of users. This is not a DDoS, but it goes to show how easy it is to cause damage. Note: I only brought down sites that I own, or those of friends with their permission.&lt;p&gt;What tools are useful in fighting DDoS attacks and script kiddies? Mention free and paid options.&lt;p&gt;What are the options to limit damage in case of an attack? How do you limit bandwidth usage charges?&lt;p&gt;There was a previous discussion on this topic 6 years ago https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=1986728</text></story><parent_chain><item><author>Kenji</author><text>Uh, stupid question but how do you cache a website like for example this comment thread on hackernews? Suppose a DDoSer calls this comment thread a lot of times. The request has to go through to the server because when I hit F5 or post a comment myself, I see the comments in realtime. How do you handle that exactly? Does caching for a few seconds help already, or does the backbone push updated sites to the CDN server? I have no experience in DDos mitigation.</text></item><item><author>buro9</author><text>I&amp;#x27;ve faced DoS attacks for years as I run internet forums.&lt;p&gt;The simple advice for layer 7 (application) attacks:&lt;p&gt;1. Design your web app to be incredibly cacheable&lt;p&gt;2. Use your CDN to cache everything&lt;p&gt;3. When under attack seek to identify the site (if you host more than one) and page that is being attacked. Force cache it via your CDN of choice.&lt;p&gt;4. If you cannot cache the page then move it.&lt;p&gt;5. If you cannot cache or move it, then have your CDN&amp;#x2F;security layer of choice issue a captcha challenge or similar.&lt;p&gt;The simple advice for layer 3 (network) attacks:&lt;p&gt;1. Rely on the security layer of choice, if it&amp;#x27;s not working change vendor.&lt;p&gt;On the L3 stuff, when it comes to DNS I&amp;#x27;ve had some bad experiences (Linode, oh they suffered) some pretty good experiences (DNS Made Easy) and some great experiences (CloudFlare).&lt;p&gt;On L7 stuff, there&amp;#x27;s a few things no-one tells you about... like if you have your application back onto AWS S3 and serve static files, that the attack can be on your purse as the bandwidth costs can really add up.&lt;p&gt;It&amp;#x27;s definitely worth thinking of how to push all costs outside of your little realm. A Varnish cache or Nginx reverse proxy with file system cache can make all the difference by saving your bandwidth costs and app servers.&lt;p&gt;I personally put CloudFlare in front of my service, but even then I use Varnish as a reverse proxy cache within my little setup to ensure that the application underneath it is really well cached. I only have about 90GB of static files in S3, and about 60GB of that is in my Varnish cache, which means when some of the more interesting attacks are based on resource exhaustion (and the resource is my pocket), they fail because they&amp;#x27;re probably just filling caches and not actually hurting.&lt;p&gt;The places you should be ready to add captchas as they really are uncacheable:&lt;p&gt;* Login pages&lt;p&gt;* Shopping Cart Checkout pages&lt;p&gt;* Search result pages&lt;p&gt;Ah, there&amp;#x27;s so much one can do, but generally... designing to be highly cacheable and then using a provider who routinely handles big attacks is the way to go.</text></item></parent_chain><comment><author>buro9</author><text>Cache everything a guest accesses for 5 minutes or more. Vary on the specific cookie that represents a signed-in user.&lt;p&gt;None of my guests have noticed this, and it has increased most of my analytics numbers as my pages are faster too.&lt;p&gt;The signed-in users, they get the dynamic pages.&lt;p&gt;But now the cookie that identifies the user is what you use to correlate any attack traffic, the attacker is forced to (somewhat) identify themselves and you can then revoke their authentication status or ban the account.&lt;p&gt;Finally you captcha and&amp;#x2F;or rate-limit the login page.&lt;p&gt;This is effectively what I do on my sites, the pages themselves and the underlying API all cache if the cookie or access token is absent.&lt;p&gt;This is trivial to do within the code, but can be harder to do with the CDN&amp;#x2F;security layer (who need to support a &amp;quot;vary on cookie&amp;quot; or &amp;quot;bypass cache on cookie&amp;quot; or equivalent).</text></comment>
<story><title>Ask HN: How do you handle DDoS attacks?</title><text>For owners of small websites running on DigitalOcean, GCP or AWS, how do you handle DDoS and DoS attacks?&lt;p&gt;For context, while exploring the load testing tool Siege running on a VPS, I was able to bring down multiple sites running on shared hosting, and some running on small VPS by setting a high enough concurrent number of users. This is not a DDoS, but it goes to show how easy it is to cause damage. Note: I only brought down sites that I own, or those of friends with their permission.&lt;p&gt;What tools are useful in fighting DDoS attacks and script kiddies? Mention free and paid options.&lt;p&gt;What are the options to limit damage in case of an attack? How do you limit bandwidth usage charges?&lt;p&gt;There was a previous discussion on this topic 6 years ago https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=1986728</text></story><parent_chain><item><author>Kenji</author><text>Uh, stupid question but how do you cache a website like for example this comment thread on hackernews? Suppose a DDoSer calls this comment thread a lot of times. The request has to go through to the server because when I hit F5 or post a comment myself, I see the comments in realtime. How do you handle that exactly? Does caching for a few seconds help already, or does the backbone push updated sites to the CDN server? I have no experience in DDos mitigation.</text></item><item><author>buro9</author><text>I&amp;#x27;ve faced DoS attacks for years as I run internet forums.&lt;p&gt;The simple advice for layer 7 (application) attacks:&lt;p&gt;1. Design your web app to be incredibly cacheable&lt;p&gt;2. Use your CDN to cache everything&lt;p&gt;3. When under attack seek to identify the site (if you host more than one) and page that is being attacked. Force cache it via your CDN of choice.&lt;p&gt;4. If you cannot cache the page then move it.&lt;p&gt;5. If you cannot cache or move it, then have your CDN&amp;#x2F;security layer of choice issue a captcha challenge or similar.&lt;p&gt;The simple advice for layer 3 (network) attacks:&lt;p&gt;1. Rely on the security layer of choice, if it&amp;#x27;s not working change vendor.&lt;p&gt;On the L3 stuff, when it comes to DNS I&amp;#x27;ve had some bad experiences (Linode, oh they suffered) some pretty good experiences (DNS Made Easy) and some great experiences (CloudFlare).&lt;p&gt;On L7 stuff, there&amp;#x27;s a few things no-one tells you about... like if you have your application back onto AWS S3 and serve static files, that the attack can be on your purse as the bandwidth costs can really add up.&lt;p&gt;It&amp;#x27;s definitely worth thinking of how to push all costs outside of your little realm. A Varnish cache or Nginx reverse proxy with file system cache can make all the difference by saving your bandwidth costs and app servers.&lt;p&gt;I personally put CloudFlare in front of my service, but even then I use Varnish as a reverse proxy cache within my little setup to ensure that the application underneath it is really well cached. I only have about 90GB of static files in S3, and about 60GB of that is in my Varnish cache, which means when some of the more interesting attacks are based on resource exhaustion (and the resource is my pocket), they fail because they&amp;#x27;re probably just filling caches and not actually hurting.&lt;p&gt;The places you should be ready to add captchas as they really are uncacheable:&lt;p&gt;* Login pages&lt;p&gt;* Shopping Cart Checkout pages&lt;p&gt;* Search result pages&lt;p&gt;Ah, there&amp;#x27;s so much one can do, but generally... designing to be highly cacheable and then using a provider who routinely handles big attacks is the way to go.</text></item></parent_chain><comment><author>voltagex_</author><text>What you can do with a site like HN will be different than if you&amp;#x27;re a shopping getting DDoSed on Black Friday by a competitor.&lt;p&gt;You can put the whole of HN into read only mode if needed and it&amp;#x27;ll have no real impact; disallowing purchases on MyAmazonCompetitor.com would be catastrophic.</text></comment>