Защита от ddos атак своими руками

Снова меня DDOS-ят. В этот раз атака не сильная и заметил я ее случайно во время очередного этапа самообразования с целью заполнения пробелов в знаниях в области безопасности.

Если кто-то открыл эту статью просто так, то рекомендую все же ее прочитать. Я все писал «понятным»языком для лучшего восприятия.

DoS—атака (Denial of Service) — закидывание неугодных ресурсов различным флудом, приводящее их к нокдауну. А DDoS—атака — это такая DoS—атака, которую осуществляет не один энтузиаст, а разгневанная толпа, желающая Страшный Суд, Ад и Погибель неправославному ресурсу. Весь профит этого метода заключается в том, что грамотно спланированную атаку невозможно отразить вообще. В результате сервер начинает как минимум безбожно тормозить при ответах на нормальные запросы, а то и вовсе ложится, не вынеся такого издевательства.

Проще говоря, что такое DoS? Это, к примеру, когда ведёшь разговор с кем-то, но тут подходит алкаш, и начинает громко нести бред. Говорить либо невозможно, либо очень сложно. Решение: зовёшь охрану, она скручивает синяка и уводит.

DDoS же отличается тем, что алкашей вбегает толпа многотысячная, и даже если позвать охрану, она банально не сумеет всех скрутить и увести.

Наиболее же эффективная атака такого плана выполняется не тысячами набежавших алкашей (ибо набор добровольцев, организация, синхронизация и прочее), а превращением в зомби уже имеющихся вокруг мирных юзеров. Они уже есть, уже ходят вокруг, уже оборудованы ртом — осталось только заставить их начать орать пациенту в ухо. Всем сразу и независимо от их желания, по команде, с исполнительностью и настойчивостью компьютера. В компьютерном мире такой захват душ обычно выполняется с помощью трояна.

Для начала нужно посмотреть сколько запросов идет с IP адресов клиентов. Для этого в консоли выполним команду:

netstat -ntu | awk ‘‘| cut -d: -f1 | sort | uniq -c | sort -nr | more

Видно, что с IP 192.230.77.217 поступило 129 обращений. «Алкаш» (смотреть выше) один, значит не DDOS, а просто DOS—атака. Заголовок статьи менять уже не буду — позже поймете почему.

Ради интереса, можно посмотреть на какие порты идут обращения с этого IP адреса выполнив команду:

Ага. 443 порт пользуется популярностью. Я думал как обычно на 80-й будет, но в принципе не важно.

Блокирую по всем портам исходящие и входящие соединения с этого IP адреса командами:

iptables -A INPUT -s 192.230.77.217 -j DROP

iptables -A INPUT -d 192.230.77.217 -j DROP

Исходящие блокирую «на всякий случай». Вдруг меня взломают и начнут атаковать с моего сервера. Неприятностей потом будет куча, поэтому лучше подстраховаться.

Все порты блокирую на случай, если будет идти подбор паролей к FTP или еще к чему-то.

Проверяем заново текущую ситуацию после применения блокировки командой:

netstat -ntu | awk ‘‘| cut -d: -f1 | sort | uniq -c | sort -nr | more

Все чисто. Враг не пройдет!

Автоматизация защиты при DDoS атаке

Понятно, что все вышеописанное ручками выполнять лениво и не практично. Давайте этот процесс автоматизируем для нашего удобства и оперативности реагирования на атаки.

На основе одного примера, найденного в Интернете, я написал свой скрипт для защиты от DoS и DDoS атак. Он получился простой, но очень эффективный. Скрипт блокирует IP адреса, количество подключений с которых превысило 50. Это значение можно изменять — скрипт хорошо прокомментирован.

# создаем DROP правила (не выдавать ответа сервера на запросы забаненых) для IP с количеством подключений более 50 и добавляем их в файл
awk ‘ 50) >’ /usr/local/ddos/ddos.iplist >> /usr/local/ddos/iptables_ban.sh

# запускаем скрипт бана IP атакующих
bash /usr/local/ddos/iptables_ban.sh

# Очищаем скрипт, который производит бан
cat /dev/null > /usr/local/ddos/iptables_ban.sh

Давайте его установим.

Для начала, необходимо создать рабочую папку для нашего скрипта. Вводим в консоли команду:

Теперь перейдем в эту папку командой:

Загружаем скрипт в эту папку командой:

Выставляем права 755 на файл скрипта командой:

Запускаем скрипт для теста командой:

В папке со скриптом появятся два файла:

ddos.iplist — в него скидываются все подключения

iptables_ban.sh — сформированный скрипт для блокировки IP адресов

Теперь открываем файл /etc/crontab и добавляем в него следующие строки

*/5 * * * * root /bin/sh /usr/local/ddos/ddos.sh
@monthly root iptables -F

Первая строка — запускает наш скрипт каждые 5 минут.
Вторая — производит раз в месяц очистку всех блокировок (амнистия).

За неделю работы скрипта ситуация с банами IP сложилась следующая (команда iptables -L).

На этом все. Возникнут вопросы — пишите в комментариях.

Источник

Защита от DDOS атаки подручными средствами. Получение доступа к своему серверу

За последнее время, наш сайт часто подвергается достаточно мощным DDOS атакам, к слову последняя атака была самой крупной за последнее время, размер ботнета по нашим оценкам — около 10 тысяч машин, мощность — 100 Mbits/s.

Атаку заметила даже Лаборатория Касперского, и предложила свою помощь в отражении, за что им спасибо. Правда к тому времени мы самостоятельно нашли решение, которое блокирует атаку. Собственно про это решение и пойдет речь.

Все началось в прошлую пятницу в пять часов вечера, и продолжалось до обеда в понедельник. Выходные прошли, за увлекательным занятием по отстрелу ботов. Пришлось немного попотеть, пока нашлось рабочее решение для противодействия атаке.

Атака была типа HTTP Flood. Система на которой у нас работает сайт — Apache под Linux. Мы написали несколько скриптов, которые будут приведены в тексте статьи. В принципе аналогичный подход можно применять и для Windows/IIS.

Попытаюсь рассказать, какие основные шаги мы сделали для отражения атаки, и какие проблемы возникали по ходу:

Получение доступа к своему серверу

Из за высокой нагрузки, вызванной атакой, подключение к серверу становится невозможным. Выход — перезагрузка, плюс хорошая реакция, чтобы попытаться подключится к перезагруженной машине, и отключить сервис, на который производится атака, и провести анализ атаки. Но при мощной атаке, даже после перезагрузки, подключение очень проблематично. Иногда приходилось перезагружать сервер по нескольку раз, пока удавалось залогинится в систему.

После того как получилось зайти в систему, и выключить апач (service httpd stop) нужно убрать запуск апача при старте системы. Это даст возможность получить доступ к машине с помощью перезагрузки, если что-либо пойдет не так. Делается это с помощью команды:

# chkconfig httpd off

Решение не идеальное, но для начала пойдет.

Автоматическая блокировка атакуемого сервиса при высокой загрузке системы

Перезагружать сервер, при каждой новой волне атаки, довольно плохое решение, т.к. это все время, которое играет против нас.

После некоторых раздумий был найден выход. При возрастании загрузки выше, некоторого критического уровня, блокировать файрволом атакуемый сервис (в нашем случае 80-й порт).

Собственно был написан универсальный скрипт который делает задуманное. Вызов скрипта следующий:

# blockOnHighLoad.sh turnOn80Port 5 turnOff80Port

Скрипту передаются две команды, и максимальный уровень загрузки системы при котором нам нужно что-либо предпринять. В данном случае при достижении load average значения 5, запускается команда, которая перекрывает файрволом 80-й порт. При возвращении загрузки на нормальный уровень, порт снова открывается.

Собственно говоря, для простых случаев, можно действия описывать прямо при вызове, например, предыдущая команда без использования внешних скриптов:

blockOnHighLoad.sh «/sbin/iptables -D INPUT -p tcp -m tcp —dport 80 -j DROP» 5 «/sbin/iptables -A INPUT -p tcp -m tcp —dport 80 -j DROP»

Т.е. мы напрямую блокируем/разблокируем порт с помощью iptables.

В более сложных случаях, например, когда атака идет на несколько сервисов сразу, или нужно выполнить сразу несколько шагов, можно использовать внешние команды.

Так наряду с блокировкой единственного порта, полезно бывает полностью «закрыть» машину, оставив только порт для подключения по SSH. Такое действие целесообразно проводить при «уходе» загрузки в «космос». Вот вторая полезная команда:

blockOnHighLoad.sh «» 50 «blockAllExcept.sh 22»

Тут по достижении значения load average в 50 единиц, мы закрываем все что можно, за исключением SSH (22-й порт). Открытие порта производится в данном случае в ручном режиме.

Теперь осталось это все хозяйство вставить в автозагрузку системы. Плюс нужно запустить выключенный httpd. Для этого мы дописали следующие команды в скрипт инициализации /etc/rc.local:

Почему не оставить нормальный запуск httpd через системный старт сервисов? Потому что он запустится перед автоблокировщиком, и при «хорошей» атаке сразу положит систему и скрипт инициализации может не выполнится.

Отмечу, что скрипт печатает небольшой диагностический лог. Выводятся сообщения, когда происходит переключение «режима» работы и печатается текущая загрузка и режим. В
примере выше, этот лог сохраняется в файл /var/log/blockOnHighLoad-5-80.logs. Так что можно посмотреть историю.

Что дальше?

После того как мы получили доступ к машине, мы провели анализ атаки, написали скрипт который автоматически банит ботов. Тут стоит отметить, что при количестве блокируемых IP более нескольких сотен, вариант с iptables, не проходит. Потому как iptables крайне не эффективно работает с большими списками. iptables нужно использовать в связке с ipset, который как раз заточен на хранение и поддержку больших списков IP для iptables. Почитать про детали можно в этой статье.

Надеемся что наш опыт поможет в борьбе с атаками.

Источник

Защита 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

Для защиты от простейшей атаки мы будем использовать firewall — iptables, модуль ядра ipset для хранения больших списков ip и самописные скрипты. По фаерволу смотрите мою статью — настройка 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. Можно использовать уже существующий список и добавленное правило из предыдущего примера, но я рекомендую все разделять. Так удобнее для последующего анализа.

Во время ddos атаки добавляете это правило в cron и выполняете каждую минуту. После завершения атаки скрипт можно отключить. В принципе, можно и на постоянку оставлять, но тут нужно хорошенько подумать и прикинуть, как оно должно выглядеть. Главный принцип — не навредить.

Баним ботов с неправильным referer

Есть категория простых ботов, которые подставляют в referrer либо мусор, либо кривые урлы без http или https в начале. Например вот такие:

Корректное поле referer должно содержать либо http, либо https, либо быть пустым. Все, что иначе, можно смело блокировать или возвращать статус ошибки. Добавляем примерно такую конструкцию в конфигурацию виртуального хоста, в раздел server <>.

После этого проверьте конфигурацию nginx и перечитайте ее.

Если вас достает какой-то бот с конкретным referer, можно забанить именно его. Для этого можно дополнить условие, или изменить. Например, вот так:

В дополнение, можно всех этих ботов с помощью простого скрипта банить на iptables, как в примерах выше. К слову сказать, их можно банить сразу, разбирая http запросы еще до того, как они будут попадать к nginx, например, с помощью ngrep, но это более сложная задача. Не все это умеют делать, там есть нюансы, а с nginx знакомы все. Не составит большого труда реализовать данный метод.

Защита от ддос с помощью модулей nginx — limit_conn и limit_req

Поделюсь еще одним простым способом снизить нагрузку на сервер и частично защититься от ддос с помощью модулей nginx — limit_conn и limit_req. Настроить их не сложно, частично результат работы первого модуля будет пересекаться с первыми двумя способами ddos защиты, описанными в начале. Он более простой для настройки, так что если не справились с теми способами, можно попробовать этот.

Смысл данных модулей в том, что один может ограничить одновременное количество разрешенных соединений с сайтом, а другой количество соединений в единицу времени.

Я ограничу в своем примере количество одновременных подключений к сайту с одного ip числом 50, а количество одновременных запросов к динамическому контенту не более 2-х в секунду. При этом будет разрешен всплеск (burst) запросов до 5-ти. Объясню, как понимать этот всплеск, так как сам не сразу понял, что конкретно он означает.

Если у нас идет превышение количества установленных запросов в секунду, то их выполнение задерживается, и они выстраиваются в очередь на исполнение с указанной скоростью. Размер этой очереди и равен значению всплеска. Все запросы, которым не хватит места в очереди, будут завершены с ошибкой. То есть, если запросов будет 4 в секунду, то 2 выполнятся сразу и еще 2 встанут в очередь. А если будет 10, то 2 выполнятся сразу, 5 встанут в очередь на выполнение по 2 штуки в секунду, а остальные будут завершены с ошибкой.

Исходя из этих условий, ограничение на подключения нужно установить в контексте server, а на доступ к динамическому контенту в соответствующем location. При этом описание зон, которые будут использовать директивы, нужно расположить в http.

Вот пример конфига nginx для реализации установленных ограничений с целью защиты от ддос атак.

После этого перезапустите nginx и проверьте как работают лимиты. Ограничение на количество выполняемых динамических запросов можно увидеть, просто нажимая очень быстро F5 в браузере. Если будете достаточно ловки, то скоро увидите картинку

и запись в логе с ошибками:

Лимит на количество подключений можете проверить той же утилитой ab, о которой я рассказал во введении.

Только не забывайте, что тест нужно запускать не на конкретную страницу, тогда вы попадете на ограничение выполнения динамического контента, а на что-то другое. Например, как в моем примере, на картинку.

Заключение

Я рассмотрел наиболее простые способы для защиты web сервера от не менее простых ddos атак, которые больше похожи на баловство. Серьезная атака, которая просто зальет весь входящий канал сервера, даже не заметит наших защит. Но тем не менее, мне приходилось убеждаться в эффективности этих способов в отражении некоторых атак.

Существует до сих пор огромное количество веб серверов, которые вообще никак не защищены даже от утилиты ab 🙂 Я знаю о чем говорю, так как мне попадаются в работу такие серверы. И есть так же много всяких ботов и простых программ, которые можно найти на просторах интернета и побаловаться, заваливая сайты, которые не готовы к нагрузкам вообще.

Есть еще один способ, такой же простой, как я описал, и эффективный от ботов, которые не понимают редиректов и кукисов. Не стал его описывать, так как не на чем проверить, да и просто устал писать статью, она получилась очень большая. Писал и редактировал ее долго, собирая скрипты и настройки по разным серверам и вспоминая, что я когда-то делал. Потом проверял все это отдельно.

Суть защиты в том, что с помощью nginx выдаем пользователю определенную cookies, а потом редиректим на запрашиваемую страницу. Если бот не понимает кукисов или редиректов, то он отваливается. Нормальные пользователи ничего не замечают. Возможно позже я отдельно расскажу про этот способ и дополню статью. А пока все. Буду рад замечаниям по существу в статьях.

Источник

Защита от ddos атак своими руками