Artem Zosimchuk: 'Distributed problems: DDoS and a family'

Artem Zosimchuk, Tech Lead at Setapp, shared his experience in dealing with DDoS attacks. The talk is interesting not only to engineers but also to Product Owners and Product Managers.

Transcript

1. Distributed problems: DDOS and a family 1
2. What is it all about? Disclaimer: I`m not a network security engineer. All the information is just to raise awareness on this topic. It’s for you to have smth to think about while designing and developing new decisions. Overview: • What are DoS/DDoS attacks: reasons, types, point of failures • Why scaling is not an option (usually) • Defence approaches • Bonus for developers 2
3. DoS / DDoS 3
4. Motivation for DoS attack - Vulnerabilities detection for a personal profit - Data hijacking (as a result of brute-force) - Reputational losses - Blackmail - Direct financial loss - Personal interest or public protest - Just for fun - You have a leg and gun 4
5. Types of DoS - Network and transport layer OSI level 3,4 5
6. DDoS 6
7. DDoS 7
8. Types of DoS - Application layer OSI level 6 & 7 Examples: - Not valid SSL - HTTP requests - RPC requests 8
9. DDoS 9
10. Points of failure - Transport (network bandwidth, balancing, packets overflow) - Computing power (servers CPU, DBs, queues and so on) Special case: - Protection (fail negative) 10
11. Scale 11
12. Scale C10M Bad design problem 12
13. Scale 13
14. Primary types of protection - Filtering on the network layer/data center/cloud provider (on premise, Azure Firewall, AWS WAF) - Filtering on the controlled servers (Istio, nginx rate limiting, fail2ban, iptables) - Filtering on the application layer (captcha, presigned request) - Move the target (IP or DNS change) - 3d party solution (AWS Shield, Cloudflare, Akamai, etc) - Scale (almost cloud only) 14
15. Basic things to think of - Prevent VS react - Cost protection VS Price of failure - Filter as closer to the source as possible - Move verification to client as much as possible - Ask a professional 15
16. Bonus: how to shoot your leg 100 000 clients update info once in 24 hours: - Normal distribution ~ 70 req/min ($50 server) - from 00:00 till 01:00 ~ 1670 req/min (at least $1200 server) - from 00:00 till 00:01 ~ 100000 req/min (at least $71000 on infrastructure) 16
17. Bonus: how NOT to shoot your leg - Load should be normalized as much as possible - You should avoid using predefined events on specific time (aka “cron”) - You should avoid using boot time or app launch time as “zero” time - Add protection layer on the client app from bugs in client - Remember that users do not always update client apps, you should think of controlled backward compatibility and ability to deprecate old versions. 17
18. https://www.linkedin.com/in/artem-zosimchuk/ Thank you! https://www.facebook.com/artem.zosimchuk 18