Как сделать ддос защиту
Как защитить себя от DoS/DDoS-атак
Анатомия DoS-атак
DoS-атаки подразделяются на локальные и удаленные. К локальным относятся различные эксплойты, форк-бомбы и программы, открывающие по миллиону файлов или запускающие некий циклический алгоритм, который сжирает память и процессорные ресурсы. На всем этом мы останавливаться не будем. А вот удаленные DoS-атаки рассмотрим подробнее. Они делятся на два вида:
Методы борьбы
Выхода из этой ситуации фактически нет, однако последствия DDoS-атак и их эффективность можно существенно снизить за счет правильной настройки маршрутизатора, брандмауэра и постоянного анализа аномалий в сетевом трафике. В следующей части статьи мы последовательно рассмотрим:
В самом конце будет дан ответ на вопрос: что делать, когда началась DDoS-атака.
Борьба с 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-шторма на системы, необходимо тщательным образом подготовить их к такой ситуации:
Добавьте в /etc/sysctl.conf следующие строки:
Следует отметить, что все приемы, направлены на снижение эффективности DDoS-атак, ставящих своей целью израсходовать ресурсы машины. От флуда, забивающего канал мусором, защититься практически невозможно, и единственно правильный, но не всегда осуществимый способ борьбы заключается в том, чтобы «лишить атаку смысла». Если ты заимеешь в свое распоряжение действительно широкий канал, который легко пропустит трафик небольшого ботнета, считай, что от 90% атак твой сервер защищен. Есть более изощренный способ защиты. Он основан на организации распределенной вычислительной сети, включающей в себя множество дублирующих серверов, которые подключены к разным магистральным каналам. Когда вычислительные мощности или пропускная способность канала заканчиваются, все новые клиенты перенаправляются на другой сервер (или же постепенно «размазываются» по серверам по принципу round-robin). Это но очень стойкая структура, завалить которую практически нереально.
Другое более-менее эффективное решение заключается в покупке хардварных систем. Работая в связке, они могут подавить начинающуюся атаку, но, как и большинство других решений, основанных на обучении и анализе состояний, дают сбои.
Кажется, началось. Что делать?
Перед непосредственным началом атаки боты «разогреваются», постепенно наращивая поток пакетов на атакуемую машину. Важно поймать момент и начать активные действия. Поможет в этом постоянное наблюдение за маршрутизатором, подключенным к внешней сети (анализ графиков NetFlow). На сервере-жертве определить начало атаки можно подручными средствами.
С HTTP-флудом несколько сложнее. Для начала нужно подсчитать количество процессов Apache и количество коннектов на 80-ый порт (HTTP-флуд):
Значения, в несколько раз превышающие среднестатистические, дают основания задуматься. Далее следует просмотреть список IP-адресов, с которых идут запросы на подключение:
Однозначно идентифицировать DoS-атаку нельзя, можно лишь подтвердить свои догадки о наличии таковой, если один адрес повторяется в списке слишком много раз (да и то, это может говорить о посетителях, сидящих за NAT’ом). Дополнительным подтверждением будет анализ пакетов с помощью tcpdump:
Показателем служит большой поток однообразных (и не содержащих полезной информации) пакетов от разных IP, направленных на один порт/сервис (например, корень web-сервера или определенный cgi-скрипт).
Окончательно определившись, начинаем дропать неугодных по IP-адресам (будет гораздо больше эффекта, если ты сделаешь это на маршрутизаторе):
Или сразу по подсетям:
Во времена своего рассвета DoS-атаки были настоящей катастрофой для серверов и обычных рабочих станций. Web-сайт можно было легко завалить с помощью одного-единственного хоста, реализующего атаку типа Smurf. Рабочие станции с установленной ОС Windows падали, как доминошки, от атак типа Ping of Death, Land, WinNuke. Сегодня всего этого не стоит опасаться.
Методы борьбы с DDoS-атаками
Хотелось бы поговорить с вами на актуальную нынче тему, а именно — про DDoS и методы борьбы с ним. Рядовые администраторы знают, что это такое, а вот для большинства вебмастеров это аббревиатура остается загадкой до того момента пока они на личном опыте не столкнуться с этой неприятностью. Итак, DDoS — это сокращение от Distributed Denial of Service (распределенный отказ в обслуживании), когда тысячи зараженных компьютеров отправляют на сервер множество запросов, с которыми он, в последствии, не может справиться. Целью DDoS атаки является нарушение нормальной работы сервера, а в дальнейшем — «падение» сайта или сервера целиком.
Как же от этого защититься? К сожалению, универсальных мер защиты от DDoS-атак до сих пор не существует. Тут необходим комплексный подход, который будет включать меры аппаратного, программного и даже организационного характера.
Программно-аппаратные системы от сетевого гиганта Cisco являются наиболее эффективными, но за них вам придется порядочно раскошелиться.
Для защиты IIS серверов можно воспользоваться (программным) решением от компании Microsoft, но, зная щедрость этой компании, можно догадаться, что они тоже далеко не бесплатные.
В настоящее время, заказные DDoS-атаки превратились в выгодную и активно развивающуюся нишу сетевой преступности. Поискав в Google, можно найти десятки предложений от «специалистов» по устранению сайта конкурентов.
Какие же основные принципы по защите от DDoS? В первую очередь, не нужно привлекать к себе (своему сайту) лишнее внимание радикально настроенной общественности, публикуя контент, способный задеть расовые, национальные или религиозные чувства каких либо индивидов.
Если же вас «заказали», или вы не послушались предыдущего совета, будьте начеку — аппаратные ресурсы веб-сервера обязательно должны иметь некоторый резерв производительности, а распределенные и дублирующие системы — построены максимально эффективно. Без понимания принципов работы DDoS, эффективную защиту построить просто невозможно. Для осуществления DDoS-атак используется большое количество компьютеров, зараженных вредоносным кодом. Эти компьютеры объединяются в ботнеты (“bot-net” — сети зомби-машин), которые по приказу злоумышленника осуществляют DDoS-атаки, причем владельцы компьютеров зачастую даже не подозревают об этом.
Мы, как хостинг-компания, сталкиваемся с DDoS-атаками на сайты наших клиентов ежедневно и имеем некоторый опыт в борьбе с ними. Как было сказано выше, универсальных мер защиты попросту нет, но атаку все же можно отразить. Предположим, что на некий сайт (пусть это будет domain.ru) идет DDoS атака. По логам видно, что большое количество GET запросов идет на главную страницу. В большинстве таких случаев, ботов можно обмануть воспользовавшись javascript-редиректом. К примеру:
Как результат — с каждым разделом, который атакован GET запросом прямо в корень, размер файла получится всего несколько байт, что гораздо лучше, чем когда бот соприкасается c
50-100кб страницей и при этом подтягивает
5-10 SQL запросов. Легитимные же пользователи, у которых не отключен javascript в браузере, перенаправляются на index.php.
Но есть одно большое НО – поисковые-боты тоже не оборудованы js-интерпретаторами и точно так же, как и атакующие боты, будут утопать в js редиректе. Можно, воспользовавшись такими UNIX утилитами как tcpdump или netstat, написать небольшой скрипт, который будет считать кол-во коннектов с определенного IP адреса, и банить его.
Определить бота можно, например, проверив его host. Небольшой пример элементарного скрипта по блокировке IP, которые создают много коннектов к серверу (данный вариант проверялся на Centos 5.6):
Данная команда создает список с кол-вом подключений и самим IP, пример:
10 209.232.223.117
1 209.85.161.191
2 212.113.39.162
1 212.78.78.78
61 213.142.213.19
5 213.151.240.177
1 210.169.67.225
1 216.179.59.97
Сам скрипт, который можно запустить в screen-е или сделать демоном:
Давайте также посмотрим и на настройки параметров Apache, которые помогут избежать некоторых проблем вызванных DDoS атакой.
TimeOut – указывайте как можно меньшее значение для данной директивы (веб сервера, который подвержен DDoS атаке).
KeepAliveTimeout директива – также нужно снизить ее значение или полностью выключить.
Стоит обязательно проверить значения различных тайм-аут директив представленные другими модулями.
Директивы LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, LimitXMLRequestBody должны быть тщательно настроены на ограничение потребления ресурсов вызванных запросами клиентов.
Убедитесь, что вы используете директиву AcceptFilter (на ОС которые поддерживают ее). По умолчанию она включена в конфигурации Apache httpd, но для своей работы может потребовать пересборку с новыми настройками ядра вашей ОС (*nix, *bsd).
Используйте директиву MaxClients, чтобы указать максимальное количество клиентов, которые смогут быть одновременно подключены к серверу — уменьшив значение директивы вы сможете снизить нагрузку на web-сервер.
Защитится от DDoS можно и на программном уровне. В этом вам поможет бесплатный скрипт – DDoS Deflate. С его помощью можно легко избавится от детского флуда и DDoS. Скрипт использует команду «netstat» для обнаружения DDoS и флуда, после чего блокирует IP адреса вредителей с помощью фаервола iptables или apf. Но не стоит расслабляться и считать, что слабый DDoS не сможет нанести ущерб вашему серверу. Возьмем, к примеру, что атакующих зомби-машин всего 10-50, но все они с толстыми каналами, а Вы, как назло, уехали в командировку, или у вас десятки (а то и сотни) серверов, и Вы не успеваете физически “мониторить” их все. В таком случае, даже небольшое количество машин сможет “зафлудить” канал или заставить выйти из строя вебсервер apache, mysql, etc. Другое дело, когда администратор круглосуточно “мониторит” сервер и с легкостью обнаруживает атаки. Но такое бывает крайне редко, поэтому нужно подключить систему сигнализации, а процесс блокировки атакующих зомби-машин — автоматизировать.
Защита web сервера от программ для ddos атак
Некоторое время назад я написал подробную статью про установку и настройку web сервера на базе nginx и php-fpm последних версий. Там я упомянул, что это первая статья из цикла заметок о веб сервере. Сегодня я расскажу как простыми и подручными средствами защититься от простых ddos атак.
Введение
Сразу сделаю оговорку по поводу слова ddos, которое тут не совсем уместно, но я не придумал, как еще популярно объяснить о чем идет речь. От полноценной ddos атаки вы не сможете защититься в рамках настройки веб сервера. У вас просто будет забит весь канал и сервер перестанет отвечать. Если мощности сервера не достаточно для обработки и фильтрации входящих запросов, то он ляжет, чтобы вы там не делали. Для полноценной защиты от ddos нужны полноценные средства, которые стоят ощутимых финансовых затрат. Более подробно с теорией по защите от ddos читайте в отдельной статье.
Нужно понимать, что защита от ddos должна быть адекватна значимости ресурса. Если у вас персональный блог, который не приносит существенной прибыли, то платить за защиту от ddos бессмысленно. Достаточно просто полежать какое-то время или сделать защиту своими силами. В общем, всегда нужно соизмерять стоимость простоя со стоимостью защиты и на основе этого принимать решение о целесообразности того или иного метода.
Я приведу советы по защите от простых атак ботов или каких-то мелких вредителей и пакостников, которые без должных действий с вашей стороны могут положить ваш сайт или сервер без особых проблем. Вот простой пример. Есть не очень слабый виртуальный сервер от ihor, на борту которого 2 ярда, 8 гигов оперативы и ssd диск.
Сервер настроен по моей предыдущей статье, ссылку на которую привел в начале. На сервере развернут wordpress сайт с некоторым содержимым. И есть у нас вредитель, который на своем сервере запускает простой тест от apache на производительность веб сервера:
Всего лишь 50 параллельных потоков. Что мы видим на своем веб сервере:
Не очень приятная картина. Сервер загружен на 100%. И хотя он нормально обрабатывает запросы и в целом корректно работает. Даже не очень тормозит, но все равно это плохо. А если будет 3 сервера и по 100 потоков на каждом? Нет никаких проблем даже на тест взять у разных хостеров по виртуальной машине и запускать на них подобные штуки, имитируя ддос атаку.
В общем, если вы совсем не сделали никакой защиты на своем сервере, то любой человек сможет вам без особых проблем доставить некоторые неудобства. Защититься от такой «атаки» не сложно. Дальше я расскажу как это сделать.
Защита от ddos с помощью iptables
Вопрос настройки ipset я подробно рассматривал в своей статье по блокировке ботов по странам. Советую посмотреть материал, так как он напрямую связан с этой статьей и дополняет ее.
Итак, приступим к созданию нашей простой защиты от dos атаки с большим количеством подключений с одного ip адреса. Для начала проверим команду, которая покажет нам количество подключений с каждого ip адреса:
У меня получается примерно так. Много единичных подключений. Идет штатная работа веб сервера, никто на него не ломится десятками подключений. Теперь нагрузим наш сервер множественными паразитными запросами и еще раз посмотрим вывод команды.
Вот он, нарушитель нашего спокойствия, пытающийся организовать дос атаку на наш сервер. Теперь нарисуем скрипт, который будет блокировать всех кто устанавливает более 50-ти одновременных соединений с сайтом.
В принципе, комментировать тут особо нечего. Берем список подключений, который только что вывели, в нем сравниваем первую колонку, если она больше 50, то результат второй колонки, где записан ip адрес, передаем в файл.
Далее читаем этот файл и добавляем все ip адреса из него в ipset список под названием much_conn. Предварительно его надо создать. Подробно об этом я рассказывал в статье, на которую привел ссылку выше, но повторю еще раз здесь:
Посмотреть содержимое списка можно командой:
Теперь нужно добавить в iptables правило, по которому будут блокироваться все подключения из указанного списка ipset.
Все, мы заблокировали всех, кто создает массовый спам подключений к серверу. Ограничение в 50 подключений можете исправлять по месту, возможно его нужно будет уменьшить, если кто-то будет открывать меньше подключений с одного ip.
Единственный момент, о котором хочу сказать. Сам я не проверял, сколько подключений открывают поисковые боты, когда приходят на сайт. Я подозреваю, что явно не 50 и даже не 30, но наверняка я не проверял. В общем, будьте аккуратны, когда используете это средство.
Данный скрипт можно засунуть в крон и запускать каждую минуту. Но лично я бы так не стал делать. Я рекомендую мониторить ресурсы сервера и запускать подобные средства, только если сервер работает на пределе своих возможностей и вы вручную зашли и убедились, что вас кто-то спамит подключениями. После этого врубайте на какое-то время данный скрипт по крону. Когда ddos прекратится, отключайте.
Было бы неплохо как-то автоматически очищать список забаненных, удаляя оттуда тех, кто уже сутки к вам не подключается, но это сильно усложняет задачу. Нужно как минимум вести лог по блокирующему списку, сохранять время последнего обращения. Обрабатывать все это, высчитывать. В общем, задача хоть и не сильно сложная, но уже не тривиальная. Мне не захотелось этим заниматься.
Есть хоть и не очень изящное, но простое решение этой проблемы. Создать список ipset с заданным временем жизни записи с помощью timeout. Например вот так:
В данном случае запись с забаненным ip в списке ipset будет храниться в течении 3600 секунд или 60 минут.
Нужно понимать, что в данном примере с 1 ip адресом использовать ipset нет никакого смысла, можно сразу банить средствами самого iptables. Ipset нужен только тогда, когда этот список хотя бы в сотни строк. Если там несколько десяткой адресов, хватит и одного iptables.
Анализ лог файла web сервера для защиты от ddos
Рассмотрим еще один простой, но все же более сложный тип ддос атаки, когда идут типовые запросы с разных IP. То есть простой ботнет, может быть даже собранный руками из нескольких дешевых vds серверов. Одновременных подключений будет не много, но если у вас тяжелый сайт и злоумышленник найдет его слабое место (например поиск), то этого может быть достаточно, чтобы положить сайт.
Банить будем тоже через iptables, а список адресов для бана будем извлекать из логов веб сервера. Для этого у вас должно быть включено логирование запросов к веб серверу. Например, в nginx за это отвечает такая настройка виртуального хоста:
Мы не будем каждый раз анализировать весь лог файл. Эта операция сама по себе будет сильно нагружать веб сервер. Возьмем последние 1000 строк из лог файла и посчитаем количество подключений с одного ip с типовым содержимым, например запрос главной страницы по протоколу http 1.0, «GET / HTTP/1.0». Если вы заметите другой постоянный признак ботнета, который вас атакует, используйте его. Это может быть один и тот же user agent или что-то еще. Допустим, если атакующий будет долбить в уязвимое место, то это будет адрес этой страницы.
Результатом этой команды будет примерно такой список.
В данном случае я использовал немного другое условие и просто вывел список всех тех, кто стучался на главную страницу. Но уже тут видно нарушителя, которого можно забанить.
Рисуем похожий на предыдущий скрипт для автоматической блокировки тех, кто отправляет слишком много запросов на наш сайт и создает проблемы с производительностью. Повторюсь еще раз, если проблем с производительностью нет, я не рекомендую делать лишних движений.
Здесь делаем то же самое, что и раньше. Те, кто сделали более 50-ти одинаковых запросов по нашей маске на последние 1000 строк в лог файле, отправляются в бан.
Не забудьте создать отдельный список в ipset и добавить отдельное правило в ipables. Можно использовать уже существующий список и добавленное правило из предыдущего примера, но я рекомендую все разделять. Так удобнее для последующего анализа.
Баним ботов с неправильным referer
Есть категория простых ботов, которые подставляют в referrer либо мусор, либо кривые урлы без http или https в начале. Например вот такие:
Корректное поле referer должно содержать либо http, либо https, либо быть пустым. Все, что иначе, можно смело блокировать или возвращать статус ошибки. Добавляем примерно такую конструкцию в конфигурацию виртуального хоста, в раздел server <>.
После этого проверьте конфигурацию nginx и перечитайте ее.
Если вас достает какой-то бот с конкретным referer, можно забанить именно его. Для этого можно дополнить условие, или изменить. Например, вот так:
В дополнение, можно всех этих ботов с помощью простого скрипта банить на iptables, как в примерах выше. К слову сказать, их можно банить сразу, разбирая http запросы еще до того, как они будут попадать к nginx, например, с помощью ngrep, но это более сложная задача. Не все это умеют делать, там есть нюансы, а с nginx знакомы все. Не составит большого труда реализовать данный метод.
Смысл данных модулей в том, что один может ограничить одновременное количество разрешенных соединений с сайтом, а другой количество соединений в единицу времени.
Я ограничу в своем примере количество одновременных подключений к сайту с одного ip числом 50, а количество одновременных запросов к динамическому контенту не более 2-х в секунду. При этом будет разрешен всплеск (burst) запросов до 5-ти. Объясню, как понимать этот всплеск, так как сам не сразу понял, что конкретно он означает.
Если у нас идет превышение количества установленных запросов в секунду, то их выполнение задерживается, и они выстраиваются в очередь на исполнение с указанной скоростью. Размер этой очереди и равен значению всплеска. Все запросы, которым не хватит места в очереди, будут завершены с ошибкой. То есть, если запросов будет 4 в секунду, то 2 выполнятся сразу и еще 2 встанут в очередь. А если будет 10, то 2 выполнятся сразу, 5 встанут в очередь на выполнение по 2 штуки в секунду, а остальные будут завершены с ошибкой.
Исходя из этих условий, ограничение на подключения нужно установить в контексте server, а на доступ к динамическому контенту в соответствующем location. При этом описание зон, которые будут использовать директивы, нужно расположить в http.
Вот пример конфига nginx для реализации установленных ограничений с целью защиты от ддос атак.
После этого перезапустите nginx и проверьте как работают лимиты. Ограничение на количество выполняемых динамических запросов можно увидеть, просто нажимая очень быстро F5 в браузере. Если будете достаточно ловки, то скоро увидите картинку
и запись в логе с ошибками:
Лимит на количество подключений можете проверить той же утилитой ab, о которой я рассказал во введении.
Только не забывайте, что тест нужно запускать не на конкретную страницу, тогда вы попадете на ограничение выполнения динамического контента, а на что-то другое. Например, как в моем примере, на картинку.
Заключение
Я рассмотрел наиболее простые способы для защиты web сервера от не менее простых ddos атак, которые больше похожи на баловство. Серьезная атака, которая просто зальет весь входящий канал сервера, даже не заметит наших защит. Но тем не менее, мне приходилось убеждаться в эффективности этих способов в отражении некоторых атак.
Существует до сих пор огромное количество веб серверов, которые вообще никак не защищены даже от утилиты ab 🙂 Я знаю о чем говорю, так как мне попадаются в работу такие серверы. И есть так же много всяких ботов и простых программ, которые можно найти на просторах интернета и побаловаться, заваливая сайты, которые не готовы к нагрузкам вообще.
Есть еще один способ, такой же простой, как я описал, и эффективный от ботов, которые не понимают редиректов и кукисов. Не стал его описывать, так как не на чем проверить, да и просто устал писать статью, она получилась очень большая. Писал и редактировал ее долго, собирая скрипты и настройки по разным серверам и вспоминая, что я когда-то делал. Потом проверял все это отдельно.
Суть защиты в том, что с помощью nginx выдаем пользователю определенную cookies, а потом редиректим на запрашиваемую страницу. Если бот не понимает кукисов или редиректов, то он отваливается. Нормальные пользователи ничего не замечают. Возможно позже я отдельно расскажу про этот способ и дополню статью. А пока все. Буду рад замечаниям по существу в статьях.