Рекомендации по защите:
DoS

Общая информация об угрозе

Denial of Service (DoS) или «отказ в обслуживании» — обобщенное наименование группы техник выполнения кибератак, преследующих своей целью сделать недоступным атакуемый узел. Классическими представителями этого типа кибератак являются DoS-атаки типа SYN-Flood, HTTP-Flood, PDoS и др. Обычно злоумышленник подбирает технику атаки индивидуально под жертву.

В общем случае DoS-атаки можно разделить на два вида:

атака непосредственно на хосты;
атака на прикладной уровень (application layer DoS).

DoS-атаки не следует путать с атаками типа Distributed Denial of Service (DDoS — распределённая атака типа «отказ в обслуживании»), осуществляемыми с множества хостов, обычно участников ботнета. Однако, на практике грань между этими двумя типами атак настолько тонка, что отнесение конкретной атаки к тому или иному типу порой весьма спорно. К тому же механизмы противодействия обоим типам атак во многом пересекаются. Поэтому приведенные ниже рекомендации охватывают ту часть действий, которые могут быть предприняты на конечном хосте, подлежащем защите, и во многом помогут противостоять не только DoS-, но и DDoS-атакам.

Рекомендации по защите

Рекомендации для защиты от атак непосредственно на хосты:

1. Как бы это банально ни звучало, изучайте документацию и user-experience к используемым службам, их плюсы и минусы по устойчивости к DoS-атакам. В документации могут встречаться ценные указания по «тюнингу» и тонкой настройке различных параметров, позволяющих снизить успех DoS-атаки на ресурсы. В качестве примера ниже представлена конфигурация nginx с комментариями:


# Увеличение максимального количества используемых файлов
worker_rlimit_nofile 100000;
events {
# Увеличение максимального количества соединений
worker_connections 65536;
# Использование механизма epoll для обработки соединений
use epoll;
}
http {
gzip off;
# Отключение таймаута на закрытие keep-alive соединений
keepalive_timeout 0;
# Скрытие данных о версии nginx в заголовках ответа
server_tokens off;
# Сброс соединения по таймауту
reset_timedout_connection on;
}
# Далее идет настройка для работы nginx в режиме reverse-proxy
server {
listen X.X.X.X default deferred;
server_name example.com www.example.com;
# Ограничение размера загружаемых файлов
client_max_body_size 5m;
………..
}}

Данный перечень не полон и не является универсальным. Конфигурация приведена лишь в качестве примера. Если вам необходима помощь в настройке — обращайтесь, будем рады помочь.

2. Изучайте также документацию и user-experience по «тюнингу» операционной системы. В качестве примера ниже приведены настройки для защиты хоста на базе Linux:


# Защита хоста от IMCP-флуда отключением ответа на ICMP-запросы:
sysctl net.ipv4.icmp_echo_ignore_all=1
# Защита хоста от SYN-флуда:
# уменьшение времени удержания «полуоткрытых» TCP-соединений:
sysctl -w net.ipv4.tcp_synack_retries=1
# увеличение очереди «полуоткрытых» TCP-соединений:
sysctl -w net.ipv4.tcp_max_syn_backlog=1024
# включение механизма TCP syncookies, направленного на защиту от SYN-флуда:
sysctl -w net.ipv4.tcp_syncookies=1
# ограничение количества «полуоткрытых» соединений с одного IP к конкретному порту:
iptables -I INPUT -p tcp --syn --dport 443 -m iplimit --iplimit-above 10 -j DROP
# Защита хоста от UDP-флуда:
# ограничение количества соединений к DNS-сервису:
iptables -I INPUT -p udp—dport 53 -j DROP -m iplimit—iplimit-above 1

3. Обязательно своевременно обновляйте программное обеспечение. Некоторые DoS-атаки направлены на эксплуатацию определенных уязвимостей, вызывающих либо высокую нагрузку, либо даже отказ работы целого сервиса. Примеры: CVE-2017-12240, CVE-2016-9150.

4. Используйте специализированные функции сетевого оборудования, позволяющие снизить воздействие флуда (например, CAR, CBAC в сетевых устройствах Cisco). А с помощью шейпинга можно обеспечить работоспособность узлов сети, не находящихся под атакой.

5. Используйте фильтрующие средства, содержащие функции защиты от DoS-атак.

Для защиты приложений рекомендации следующие:

При разработке приложения используйте профайлер. Смотрите, какие вызовы отнимают наибольшее количество времени, думайте, как можно их оптимизировать или вовсе избежать.
Схожая мера применяется и по отношению к БД. Для mysql, например, можно включить опцию slow-query-log, позволяющую логировать запросы, обработка которых отнимает длительное время. Проанализируйте и подумайте, каким образом можно оптимизировать обработку таких запросов.
Анализируйте журналы. В журналах можно добавить время запроса и время ответа, что позволит определить, какие из запросов обрабатываются дольше других.
Используйте WAF. Он потребует длительной и тщательной настройки, но позволит отфильтровать большую часть нежелательных запросов на прикладном уровне.

Общие рекомендации:

Обязательно используйте мониторинг, включите показания нагрузки CPU, оперативной памяти, количество сессий, свободного места на жестком диске и т.д. Это позволит своевременно обнаружить атаку и сразу же предпринять действия по минимизации ущерба. Для мониторинга можно использовать зарекомендовавшие себя Zabbix или Nagios.
По необходимости проводите аудит (стресс-тесты) с целью поиска потенциально уязвимых точек.
Планируйте архитектуру. Избавляйтесь от «узких горлышек», кластеризуйте оборудование и службы, распределяйте вычисления, не используйте один сервер/виртуальную машину/docker-контейнер для работы сразу всех высококритичных служб.
Опционально рекомендуется настроить инфраструктуру таким образом, чтобы при атаке на ресурс на одном из хостов можно было оперативно поднять этот же ресурс на другом хосте.

Действия в случае инцидента

При выявлении DoS-атаки можно попытаться как снизить её ущерб, так и полностью её остановить.

В первую очередь попытайтесь заблокировать атакующий хост. Рекомендуется также временно заблокировать узлы, например, по геолокации или по репутации, для избегания повторения той же атаки с «соседнего» хоста.
Если такой возможности нет или принятые меры не вернули сервис «к жизни», то отключите сервер от сети. Цели, которые он выполнял — он не выполняет, да и приоритетнее сейчас как можно скорее обнаружить и устранить проблему. Если при этом инфраструктура была построена с возможностью использовать дополнительный инстанс «рухнувшей» службы — самое время этой возможностью воспользоваться.
Попытайтесь локализовать и устранить проблему. Смотрите, что именно и каким образом подвергалось атаке, особенное внимание обращайте на «500-ые» ошибки. Обратите внимание на логи средств защиты информации: установив тип атаки, можно быстрее локализовать проблему. Проанализируйте журналы. В них можно поискать уязвимую форму (например, загрузки файла), после чего её временно отключить для разрешения проблемы. В случае, если просмотр журналов по каким-то причинам невозможен, определить проблему можно и с помощью tcpdump.
Подключайте сервер обратно к сети и следите за состоянием, атакующий наверняка попытается найти новую цель или применить иной метод атаки.
Обязательно инициируйте процедуру расследования инцидента и обеспечьте усиленный мониторинг безопасности: DoS-атака может являться частью или служить прикрытием более масштабной таргетированной атаки.