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

Slide 1

Slide 1 text

Distributed problems: DDOS and a family 1

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

DoS / DDoS 3

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Types of DoS - Network and transport layer OSI level 3,4 5

Slide 6

Slide 6 text

DDoS 6

Slide 7

Slide 7 text

DDoS 7

Slide 8

Slide 8 text

Types of DoS - Application layer OSI level 6 & 7 Examples: - Not valid SSL - HTTP requests - RPC requests 8

Slide 9

Slide 9 text

DDoS 9

Slide 10

Slide 10 text

Points of failure - Transport (network bandwidth, balancing, packets overflow) - Computing power (servers CPU, DBs, queues and so on) Special case: - Protection (fail negative) 10

Slide 11

Slide 11 text

Scale 11

Slide 12

Slide 12 text

Scale C10M Bad design problem 12

Slide 13

Slide 13 text

Scale 13

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

https://www.linkedin.com/in/artem-zosimchuk/ Thank you! https://www.facebook.com/artem.zosimchuk 18