Борьба с flood-атаками
Итак, существует два типа DoS/DDoS-атак, и наиболее распространенная из них основана на идее флуда, то есть заваливания жертвы огромным количеством пакетов. Флуд бывает разным: ICMP-флуд, SYN-флуд, UDP-флуд и HTTP-флуд. Современные DoS-боты могут использовать все эти виды атак одновременно, поэтому следует заранее позаботиться об адекватной защите от каждой из них. Пример как защититься от самого распространенного типа атак.
HTTP-флуд.
Один из самых распространенных на сегодняшний день способов флуда. Основан на бесконечной посылке HTTP-сообщений GET на 80-ый порт с целью загрузить web-сервер настолько, чтобы он оказался не в состоянии обрабатывать все остальные запросы. Часто целью флуда становится не корень web-сервера, а один из скриптов, выполняющих ресурсоемкие задачи или работающий с базой данных. В любом случае, индикатором начавшейся атаки будет служить аномально быстрый рост логов web-сервера.
Методы борьбы с HTTP-флудом включают в себя тюнинг web-сервера и базы данных с целью снизить эффект от атаки, а также отсеивание DoS-ботов с помощью различных приемов. Во-первых, следует увеличить максимальное число коннектов к базе данных одновременно. Во-вторых, установить перед web-сервером Apache легкий и производительный nginx – он будет кэшировать запросы и отдавать статику. Это решение из списка "must have", которое не только снизит эффект DoS-атак, но и позволит серверу выдержать огромные нагрузки.
В случае необходимости можно задействовать nginx-модуль ngx_http_limit_req_module, ограничивающий количество одновременных подключений с одного адреса. Ресурсоемкие скрипты можно защитить от ботов с помощью задержек, кнопок "Нажми меня", выставления кукисов и других приемов, направленных на проверку "человечности"
Универсальные советы
Чтобы не попасть в безвыходное положение во время обрушения DDoS-шторма на системы, необходимо тщательным образом подготовить их к такой ситуации:
Все сервера, имеющие прямой доступ во внешнюю сеть, должны быть подготовлены к простому и быстрому удаленному ребуту. Большим плюсом будет наличие второго, административного, сетевого интерфейса, через который можно получить доступ к серверу в случае забитости основного канала.
ПО, используемое на сервере, всегда должно находиться в актуальном состоянии. Все дырки - пропатчены, обновления установлены (простой, как сапог, совет, которому многие не следуют). Это оградит тебя от DoS-атак, эксплуатирующих баги в сервисах.
Все слушающие сетевые сервисы, предназначенные для административного использования, должны быть спрятаны брандмауэром ото всех, кто не должен иметь к ним доступ. Тогда атакующий не сможет использовать их для проведения DoS-атаки или брутфорса.
На подходах к серверу (ближайшем маршрутизаторе) должна быть установлена система анализа трафика, которая позволит своевременно узнать о начинающейся атаке и вовремя принять меры по ее предотвращению.
Добавьте в /etc/sysctl.conf следующие строки:
Код:
# vi /etc/sysctl.conf
# Защита от спуфинга
net.ipv4.conf.default.rp_filter = 1
# Проверять TCP-соединение каждую минуту. Если на другой стороне - легальная машина, она сразу ответит. Дефолтовое значение - 2 часа.
net.ipv4.tcp_keepalive_time = 60
# Повторить пробу через десять секунд
net.ipv4.tcp_keepalive_intvl = 10
# Количество проверок перед закрытием соединения
net.ipv4.tcp_keepalive_probes = 5
Следует отметить, что все приемы, направлены на снижение эффективности DDoS-атак, ставящих своей целью израсходовать ресурсы машины. От флуда, забивающего канал мусором, защититься практически невозможно, и единственно правильный, но не всегда осуществимый способ борьбы заключается в том, чтобы "лишить атаку смысла". Если ты заимеешь в свое распоряжение действительно широкий канал, который легко пропустит трафик небольшого ботнета, считай, что от 90% атак твой сервер защищен. Есть более изощренный способ защиты. Он основан на организации распределенной вычислительной сети, включающей в себя множество дублирующих серверов, которые подключены к разным магистральным каналам. Когда вычислительные мощности или пропускная способность канала заканчиваются, все новые клиенты перенаправляются на другой сервер (или же постепенно "размазываются" по серверам по принципу round-robin). Это но очень стойкая структура, завалить которую практически нереально.
Другое более-менее эффективное решение заключается в покупке хардварных систем. Работая в связке, они могут подавить начинающуюся атаку, но, как и большинство других решений, основанных на обучении и анализе состояний, дают сбои.
Кажется, началось. Что делать?
Перед непосредственным началом атаки боты "разогреваются", постепенно наращивая поток пакетов на атакуемую машину. Важно поймать момент и начать активные действия. Поможет в этом постоянное наблюдение за маршрутизатором, подключенным к внешней сети (анализ графиков NetFlow). На сервере-жертве определить начало атаки можно подручными средствами.
Наличие SYN-флуда устанавливается легко - через подсчет числа "полуоткрытых" TCP-соединений:
Код:
# netstat -na | grep ":80 " | grep SYN_RCVD
В обычной ситуации их не должно быть совсем (или очень небольшое количество: максимум 1-3). Если это не так - ты атакован, срочно переходи к дропанью атакующих.
С HTTP-флудом несколько сложнее. Для начала нужно подсчитать количество процессов Apache и количество коннектов на 80-ый порт (HTTP-флуд):
Код:
# ps aux | grep httpd | wc -l
# netstat -na | grep ":80 " | wc -l
Значения, в несколько раз превышающие среднестатистические, дают основания задуматься. Далее следует просмотреть список IP-адресов, с которых идут запросы на подключение:
Код:
# netstat -na | grep ":80 " | sort | uniq -c | sort -nr | less
Однозначно идентифицировать DoS-атаку нельзя, можно лишь подтвердить свои догадки о наличии таковой, если один адрес повторяется в списке слишком много раз (да и то, это может говорить о посетителях, сидящих за NAT'ом). Дополнительным подтверждением будет анализ пакетов с помощью tcpdump:
Код:
# tcpdump -n -i eth0 -s 0 -w output.txt dst port 80 and host IP-сервера
Показателем служит большой поток однообразных (и не содержащих полезной информации) пакетов от разных IP, направленных на один порт/сервис (например, корень web-сервера или определенный cgi-скрипт).
Окончательно определившись, начинаем дропать неугодных по IP-адресам (будет гораздо больше эффекта, если ты сделаешь это на маршрутизаторе):
Код:
# iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port http -j DROP
Или сразу по подсетям:
Код:
# iptables -A INPUT -s xxx.xxx.0.0/16 -p tcp --destination-port http -j DROP
Это даст тебе некоторую фору (совсем маленькую; зачастую IP-адрес источника спуфится), которую ты должен использовать для того, чтобы обратиться к провайдеру/хостеру (с приложенными к сообщению логами web-сервера, ядра, брандмауэра и списком выявленных тобой IP-адресов). Большинство из них, конечно, проигнорируют это сообщение (а хостинги с оплатой трафика еще и порадуются - DoS-атака принесет им прибыль) или просто отключат твой сервер. Но в любом случае это следует сделать обязательно, – эффективная защита от DDoS возможна только на магистральных каналах. В одиночку ты справишься с мелкими нападками, направленными на истощение ресурсов сервера, но окажешься беззащитным перед более-менее серьезным DDoS'ом.
Во времена своего рассвета DoS-атаки были настоящей катастрофой для серверов и обычных рабочих станций. Web-сайт можно было легко завалить с помощью одного-единственного хоста, реализующего атаку типа Smurf. Рабочие станции с установленной ОС Windows падали, как доминошки, от атак типа Ping of Death, Land, WinNuke. Сегодня всего этого не стоит опасаться.
Итак, существует два типа DoS/DDoS-атак, и наиболее распространенная из них основана на идее флуда, то есть заваливания жертвы огромным количеством пакетов. Флуд бывает разным: ICMP-флуд, SYN-флуд, UDP-флуд и HTTP-флуд. Современные DoS-боты могут использовать все эти виды атак одновременно, поэтому следует заранее позаботиться об адекватной защите от каждой из них. Пример как защититься от самого распространенного типа атак.
HTTP-флуд.
Один из самых распространенных на сегодняшний день способов флуда. Основан на бесконечной посылке HTTP-сообщений GET на 80-ый порт с целью загрузить web-сервер настолько, чтобы он оказался не в состоянии обрабатывать все остальные запросы. Часто целью флуда становится не корень web-сервера, а один из скриптов, выполняющих ресурсоемкие задачи или работающий с базой данных. В любом случае, индикатором начавшейся атаки будет служить аномально быстрый рост логов web-сервера.
Методы борьбы с HTTP-флудом включают в себя тюнинг web-сервера и базы данных с целью снизить эффект от атаки, а также отсеивание DoS-ботов с помощью различных приемов. Во-первых, следует увеличить максимальное число коннектов к базе данных одновременно. Во-вторых, установить перед web-сервером Apache легкий и производительный nginx – он будет кэшировать запросы и отдавать статику. Это решение из списка "must have", которое не только снизит эффект DoS-атак, но и позволит серверу выдержать огромные нагрузки.
В случае необходимости можно задействовать nginx-модуль ngx_http_limit_req_module, ограничивающий количество одновременных подключений с одного адреса. Ресурсоемкие скрипты можно защитить от ботов с помощью задержек, кнопок "Нажми меня", выставления кукисов и других приемов, направленных на проверку "человечности"
Универсальные советы
Чтобы не попасть в безвыходное положение во время обрушения DDoS-шторма на системы, необходимо тщательным образом подготовить их к такой ситуации:
Все сервера, имеющие прямой доступ во внешнюю сеть, должны быть подготовлены к простому и быстрому удаленному ребуту. Большим плюсом будет наличие второго, административного, сетевого интерфейса, через который можно получить доступ к серверу в случае забитости основного канала.
ПО, используемое на сервере, всегда должно находиться в актуальном состоянии. Все дырки - пропатчены, обновления установлены (простой, как сапог, совет, которому многие не следуют). Это оградит тебя от DoS-атак, эксплуатирующих баги в сервисах.
Все слушающие сетевые сервисы, предназначенные для административного использования, должны быть спрятаны брандмауэром ото всех, кто не должен иметь к ним доступ. Тогда атакующий не сможет использовать их для проведения DoS-атаки или брутфорса.
На подходах к серверу (ближайшем маршрутизаторе) должна быть установлена система анализа трафика, которая позволит своевременно узнать о начинающейся атаке и вовремя принять меры по ее предотвращению.
Добавьте в /etc/sysctl.conf следующие строки:
Код:
# vi /etc/sysctl.conf
# Защита от спуфинга
net.ipv4.conf.default.rp_filter = 1
# Проверять TCP-соединение каждую минуту. Если на другой стороне - легальная машина, она сразу ответит. Дефолтовое значение - 2 часа.
net.ipv4.tcp_keepalive_time = 60
# Повторить пробу через десять секунд
net.ipv4.tcp_keepalive_intvl = 10
# Количество проверок перед закрытием соединения
net.ipv4.tcp_keepalive_probes = 5
Следует отметить, что все приемы, направлены на снижение эффективности DDoS-атак, ставящих своей целью израсходовать ресурсы машины. От флуда, забивающего канал мусором, защититься практически невозможно, и единственно правильный, но не всегда осуществимый способ борьбы заключается в том, чтобы "лишить атаку смысла". Если ты заимеешь в свое распоряжение действительно широкий канал, который легко пропустит трафик небольшого ботнета, считай, что от 90% атак твой сервер защищен. Есть более изощренный способ защиты. Он основан на организации распределенной вычислительной сети, включающей в себя множество дублирующих серверов, которые подключены к разным магистральным каналам. Когда вычислительные мощности или пропускная способность канала заканчиваются, все новые клиенты перенаправляются на другой сервер (или же постепенно "размазываются" по серверам по принципу round-robin). Это но очень стойкая структура, завалить которую практически нереально.
Другое более-менее эффективное решение заключается в покупке хардварных систем. Работая в связке, они могут подавить начинающуюся атаку, но, как и большинство других решений, основанных на обучении и анализе состояний, дают сбои.
Кажется, началось. Что делать?
Перед непосредственным началом атаки боты "разогреваются", постепенно наращивая поток пакетов на атакуемую машину. Важно поймать момент и начать активные действия. Поможет в этом постоянное наблюдение за маршрутизатором, подключенным к внешней сети (анализ графиков NetFlow). На сервере-жертве определить начало атаки можно подручными средствами.
Наличие SYN-флуда устанавливается легко - через подсчет числа "полуоткрытых" TCP-соединений:
Код:
# netstat -na | grep ":80 " | grep SYN_RCVD
В обычной ситуации их не должно быть совсем (или очень небольшое количество: максимум 1-3). Если это не так - ты атакован, срочно переходи к дропанью атакующих.
С HTTP-флудом несколько сложнее. Для начала нужно подсчитать количество процессов Apache и количество коннектов на 80-ый порт (HTTP-флуд):
Код:
# ps aux | grep httpd | wc -l
# netstat -na | grep ":80 " | wc -l
Значения, в несколько раз превышающие среднестатистические, дают основания задуматься. Далее следует просмотреть список IP-адресов, с которых идут запросы на подключение:
Код:
# netstat -na | grep ":80 " | sort | uniq -c | sort -nr | less
Однозначно идентифицировать DoS-атаку нельзя, можно лишь подтвердить свои догадки о наличии таковой, если один адрес повторяется в списке слишком много раз (да и то, это может говорить о посетителях, сидящих за NAT'ом). Дополнительным подтверждением будет анализ пакетов с помощью tcpdump:
Код:
# tcpdump -n -i eth0 -s 0 -w output.txt dst port 80 and host IP-сервера
Показателем служит большой поток однообразных (и не содержащих полезной информации) пакетов от разных IP, направленных на один порт/сервис (например, корень web-сервера или определенный cgi-скрипт).
Окончательно определившись, начинаем дропать неугодных по IP-адресам (будет гораздо больше эффекта, если ты сделаешь это на маршрутизаторе):
Код:
# iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port http -j DROP
Или сразу по подсетям:
Код:
# iptables -A INPUT -s xxx.xxx.0.0/16 -p tcp --destination-port http -j DROP
Это даст тебе некоторую фору (совсем маленькую; зачастую IP-адрес источника спуфится), которую ты должен использовать для того, чтобы обратиться к провайдеру/хостеру (с приложенными к сообщению логами web-сервера, ядра, брандмауэра и списком выявленных тобой IP-адресов). Большинство из них, конечно, проигнорируют это сообщение (а хостинги с оплатой трафика еще и порадуются - DoS-атака принесет им прибыль) или просто отключат твой сервер. Но в любом случае это следует сделать обязательно, – эффективная защита от DDoS возможна только на магистральных каналах. В одиночку ты справишься с мелкими нападками, направленными на истощение ресурсов сервера, но окажешься беззащитным перед более-менее серьезным DDoS'ом.
Во времена своего рассвета DoS-атаки были настоящей катастрофой для серверов и обычных рабочих станций. Web-сайт можно было легко завалить с помощью одного-единственного хоста, реализующего атаку типа Smurf. Рабочие станции с установленной ОС Windows падали, как доминошки, от атак типа Ping of Death, Land, WinNuke. Сегодня всего этого не стоит опасаться.