Ask HN: Attack resilience beyond tweaking Cloudflare?
Here are a few concepts and lessons from today:
- Caching: stopping attacks by just making your setup more scalable. In my case this involved leveraging Cloudflare's network by ensuring I served everything I could without using my servers. I am aware this comes with troubles not related to security but will skip that to focus the discussion on attack mitigation.
- Rate limiting: the frequency with which regular users hit endpoints is likely to be far (1-3 orders of magnitude?) from what a full blown attack would throw at your server. This helps setting aggressive rules on how often someone (as defined by IP, etc/metadata) can hit your server.
- Simple/dumb short-term fixes that wont work even medium-term should be tried: in my case there was one specific url being hit, and I hesitated to set such an easy to bypass rule because my attacker 'would obviously change it once it started failing'. It ended up stopping the attack... I understand this may not be so clear cut always (hindsight bias, easy fix that could be validated immediately).
- Involving more layers of your stack increases you capacity to handle attacks: this sounds obvious but keeping requests from getting to your application becomes easier if you can tweak Cloudflare, tweak your ngnix/heroku, and also being able to catch stuff at the application level. Each layer has to deal with an order of magnitude less requests than the one before it, so the attack has to be bigger and bigger the more layers contribute in this dynamic.
- Paging is important: as a small company, we hadn't put as much thought as would have been good to have today.
Got an immersive glimpse of a part of level 0 today and would love to see what paths the HN crowd has taken to learn more about attacks and web security.