Определение простыми словами
DoS — это попытка «положить» сервис, отправляя ему больше работы, чем он может обработать. Это может быть миллион SYN-пакетов на 80-й порт, тяжёлые HTTP-запросы к страницам с дорогим SQL, сотни одновременных соединений, удерживающих сокеты. Сервер тратит CPU, RAM или сетевую пропускную способность на бесполезные запросы и перестаёт отвечать настоящим клиентам.
Если запросы идут с одного источника — это классический DoS, его легко отбить блокировкой IP. Когда атака идёт с тысяч заражённых машин (botnet) одновременно — это DDoS, фильтровать сложнее. По модели OSI атаки делят на L3/L4 (объёмные — UDP flood, SYN flood, ICMP flood) и L7 (логические — медленные запросы Slowloris, HTTP-флуд, обращения к дорогим API).
Сравнение
| Тип | Уровень | Что нагружает | Защита |
|---|---|---|---|
| SYN flood | L4 (TCP) | таблица соединений | SYN cookies, conntrack |
| UDP flood | L4 | канал, sockets | rate-limit на firewall |
| ICMP flood | L3 | пропускную способность | iptables -m limit |
| Amplification (DNS, NTP) | L4 | входящий канал | BCP38, провайдер |
| Slowloris | L7 | сокеты веб-сервера | Nginx limit_conn |
| HTTP flood | L7 | CPU приложения | WAF, JS-челлендж |
| Cache busting | L7 | origin-сервер | правила на CDN |
Кейсы использования
- Конкурент во время чёрной пятницы запускает HTTP-флуд по чекауту магазина — корзина перестаёт оформляться.
- Игровой сервер CS получает UDP-флуд на порт 27015 — игроков выкидывает из матчей с пингом 9999.
- Telegram-бот атакован тысячами одинаковых /start — упирается в лимит соединений Webhook.
- Фрилансер заказал DDoS на сайт бывшего работодателя — попадает под уголовную статью УК РФ 273.
- Негативный сценарий: для защиты включили только rate-limit по IP. Атакующий разнёс источники по 50 000 адресов — лимит не сработал. Решение — поведенческий анализ, JS-челлендж и фильтрация на уровне CDN или WAF.
Технические детали
# Лимит частоты HTTP-запросов в Nginx
http {
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;
}
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
limit_conn conn 10;
}
}
# Защита от SYN flood ядром Linux
sudo sysctl -w net.ipv4.tcp_syncookies=1
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sudo sysctl -w net.ipv4.tcp_synack_retries=2
# Блок ICMP-флуда через iptables
sudo iptables -A INPUT -p icmp --icmp-type echo-request
-m limit --limit 10/sec --limit-burst 20 -j ACCEPT
sudo iptables -A INPUT -p icmp -j DROP
# Анализ источников атаки
ss -tn state syn-recv | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
tcpdump -ni eth0 'tcp[tcpflags] & tcp-syn != 0' | head -100
На сетевом уровне работает в связке с iptables и nftables. На L7 эффективнее всего защита от DDoS через CDN.
🔥 Где это применяется
Частые вопросы
Чем DoS отличается от DDoS?
DoS идёт с одного источника — обычно одного IP или сети. DDoS распределён по тысячам захваченных устройств (ботнет), часто из разных стран. По эффекту похожи, по сложности фильтрации DDoS на порядок труднее.
Можно ли отбить DoS только средствами сервера?
Маленькие атаки до 1 Гбит/с — да, через iptables, sysctl и Nginx limit_req. Объёмные DDoS забивают сам канал хостинга, фильтровать на сервере бесполезно — нужна защита на стороне провайдера или CDN.
Как понять, что сайт под DoS-атакой, а не под наплывом трафика?
Резкий рост запросов с подозрительных User-Agent, аномально много обращений к одной странице или API, повышенный процент 5xx-ответов. Помогает анализ access-логов командой awk и графики в Prometheus или Zabbix.