Ddos-атаки: нападение и защита

Подключаемся к чужому девайсу

Как мы уже знаем, примитивные колонки и гарнитуры почти никогда не фильтруют пакеты, которые мы им отправляем. Но что будет, если отослать такому девайсу не просто пакет с данными для проверки связи (ping), а пакет с запросом на подключение к устройству? И не один.

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

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

Перед запуском скрипта нам нужно узнать MAC-адрес устройства. Для этого используем уже знакомую команду , а полученный адрес вставляем в скрипт вместо . Теперь сохраняем скрипт и запускаем его:

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

Если наш сценарий успешно выполнен, мы можем устроить свою дискотеку или вырубить устройство. Мои личные эксперименты с колонкой JBL Xtreme привели к ее отключению, а вот JBL Flip 2 когда-то удавалось и перехватывать (сейчас ее под рукой нет).

Схема программного фильтра от DDoS атак на сайт

Фильтр основан на том, что боты участвующие в DDoS атаках не способны выполнить JavaScript код, соответственно боты не пройдут дальше стоп-страницы фильтра, чем существенно разгрузят фронтенд/бекэнд и базу данных сайта. Т.к. на обработку каждого GET/POST запроса DDoS атаки потребуется выполнить не более 20 строк кода в бэкенде сайта и выдать страницу-заглушку объемом менее 2Кб данных.

1. Фильтр вызываем первой строкой веб-приложения, до вызова всего остального кода приложения. Так можно максимально разгрузить “железо” сервера и уменьшить объем отдаваемого трафика в сторону ботов.
2. Если посетитель попадает под условия фильтра, то выдаем посетителю специальную страницу-заглушку. На странице,
   • Сообщаем о причинах выдачи специальной страницы вместо запрошенной
   • Устанавливаем специальную куку в броузере пользователя посредством JavaScript.
   • Выполняем JavaScript код перенаправления на исходную страницу.
3. Если у посетителя установлена специальная кука, то фильтр прозрачно пропускает посетителя на запрошенную страницу сайта.
4. Если IP адрес посетителя принадлежит автономной системе из списка исключений, то трафик так же прозрачно пропускаем. Это условие необходимо для исключения фильтрации ботов поисковых систем.

Проект фильтра на github.com.

Защита от ddos с помощью iptables

Для защиты от простейшей атаки мы будем использовать firewall — iptables, модуль ядра ipset для хранения больших списков ip и самописные скрипты. По фаерволу смотрите мою статью — настройка iptables. Здесь я не буду на этом останавливаться.

Вопрос настройки ipset я подробно рассматривал в своей статье по блокировке ботов по странам. Советую посмотреть материал, так как он напрямую связан с этой статьей и дополняет ее.

Итак, приступим к созданию нашей простой защиты от dos атаки с большим количеством подключений с одного ip адреса. Для начала проверим команду, которая покажет нам количество подключений с каждого ip адреса:

# netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^*//'

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

Вот он, нарушитель нашего спокойствия, пытающийся организовать дос атаку на наш сервер. Теперь нарисуем скрипт, который будет блокировать всех кто устанавливает более 50-ти одновременных соединений с сайтом.

#!/bin/sh

netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^*//' | awk '{if ($1 > 50 ) print$2}' > /root/ddos/much_conn.txt

sleep 3

list=$(cat /root/ddos/much_conn.txt)
for ipnet in $list
    do
	ipset -A much_conn $ipnet
    done

В принципе, комментировать тут особо нечего. Берем список подключений, который только что вывели, в нем сравниваем первую колонку, если она больше 50, то результат второй колонки, где записан ip адрес, передаем в файл.

Далее читаем этот файл и добавляем все ip адреса из него в ipset список под названием much_conn. Предварительно его надо создать. Подробно об этом я рассказывал в статье, на которую привел ссылку выше, но повторю еще раз здесь:

# ipset -N much_conn iphash

Посмотреть содержимое списка можно командой:

# ipset -L much_conn

Теперь нужно добавить в iptables правило, по которому будут блокироваться все подключения из указанного списка ipset.

# iptables -A INPUT -m set --match-set much_conn src -j DROP

На всякий случай предупреждаю, чтобы вы проверили свой доступ к консоли сервера, прежде чем настраивать правила iptables. Всякое бывает, можно просто ошибиться, скопировать и вставить не то, что нужно.

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

Единственный момент, о котором хочу сказать. Сам я не проверял, сколько подключений открывают поисковые боты, когда приходят на сайт. Я подозреваю, что явно не 50 и даже не 30, но наверняка я не проверял. В общем, будьте аккуратны, когда используете это средство.

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

Было бы неплохо как-то автоматически очищать список забаненных, удаляя оттуда тех, кто уже сутки к вам не подключается, но это сильно усложняет задачу. Нужно как минимум вести лог по блокирующему списку, сохранять время последнего обращения. Обрабатывать все это, высчитывать. В общем, задача хоть и не сильно сложная, но уже не тривиальная. Мне не захотелось этим заниматься.

Есть хоть и не очень изящное, но простое решение этой проблемы. Создать список ipset с заданным временем жизни записи с помощью timeout. Например вот так:

ipset -N much_conn iphash timeout 3600

В данном случае запись с забаненным ip в списке ipset будет храниться в течении 3600 секунд или 60 минут.

Нужно понимать, что в данном примере с 1 ip адресом использовать ipset нет никакого смысла, можно сразу банить средствами самого iptables. Ipset нужен только тогда, когда этот список хотя бы в сотни строк. Если там несколько десяткой адресов, хватит и одного iptables.

Как защититься от DDoS-атак?

Безопасность программного кода

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

Разработайте план действий при обновлении программного обеспечения. Всегда должна быть возможность «отката» в том случае, если что-то пойдет не так.
Своевременно обновляйте ПО. Если накатить апдейты удалось, но при этом появились проблемы, см. п.2.
Не забывайте про ограничение доступа. Аккаунты admin и/или должны быть защищены сильными и регулярно сменяемыми паролями. Необходим также периодический аудит прав доступа, своевременное удаление аккаунтов уволившихся сотрудников.
Интерфейс админа должен быть доступен только из внутренней сети или через VPN. Своевременно закрывайте VPN-доступ для уволившихся и тем более уволенных сотрудников.
Включите устранение последствий DDoS-атак в план аварийного восстановления. План должен предусматривать способы выявления факта такой атаки, контакты для связи с интернет- или хостинг-провайдером, дерево «эскалации проблемы» для каждого департамента.
Сканирование на наличие уязвимостей поможет выявить проблемы в вашей инфраструктуре и программном обеспечении, снизить риски. Простой тест OWASP Top 10 Vulnerability выявит наиболее критичные проблемы. Полезными также будут тесты на проникновение – они помогут найти слабые места.
Аппаратные средства защиты от DDoS-атак могут быть недешевы. Если ваш бюджет такого не предусматривает, то есть хорошая альтернатива – защита от DDoS «по требованию». Такую услугу можно включать простым изменением схемы маршрутизации трафика в экстренной ситуации, либо находится под защитой постоянно.
Используйте CDN-партнера. Сети доставки контента (Content Delivery Network) позволяют доставлять контент сайта посредством распределенной сети. Трафик распределяется по множеству серверов, уменьшается задержка при доступе пользователей, в том числе географически удаленных. Таким образом, хотя основное преимущество CDN – это скорость, она служит также барьером между основным сервером и пользователями.
Используйте Web Application Firewall – файрвол для веб-приложений. Он мониторит трафик между сайтом или приложением и браузером, проверяя легитимность запросов. Работая на уровне приложений, WAF может выявлять атаки по хранимым шаблонам и выявлять необычное поведение. Атаки на уровне приложений нередки в электронной коммерции. Как и в случае CDN, можно воспользоваться сервисами WAF в облаке. Однако конфигурирование правил требует некоторого опыта. В идеале защитой WAF должны быть обеспечены все основные приложения.

Второй способ: Websploit

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

Набираем в консоли команду

Она продемонстрирует нам все модули, которые работают с этой утилитой. Там есть множество компонентов, работающих с Wi-Fi, но нас интересует конкретно модуль bluetooth/bluetooth_pod:

Теперь нужно настроить все параметры и указать сведения об атакуемом устройстве:

Чтобы точно и наверняка угробить Bluetooth, мы изменим размер отсылаемого пакета:

Все подготовительные действия завершены, можем запускать нашу «машину для убийств»:

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

Эти два способа будут работать практически с любыми блютусными колонками, гарнитурами и прочими похожими устройствами. Просто потому, что производители не выпускают для них новые прошивки, способные фильтровать входящие пакеты. Так что, если у тебя есть ноутбук с «Линуксом» на борту, ты точно можешь назвать себя грозой портативных колонок.

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

Защита DNS

1. Мониторинг DNS-серверов на предмет подозрительной деятельности является первым шагом в деле защиты инфраструктуры DNS. Коммерческие решения DNS и продукты с открытым исходным кодом, такие как BIND, предоставляют статистику в реальном времени, которую можно использоваться для обнаружения атак DDoS. Мониторинг DDoS-атак может быть ресурсоемкой задачей. Лучше всего создать базовый профиль инфраструктуры при нормальных условиях функционирования и затем обновлять его время от времени по мере развития инфраструктуры и изменения шаблонов трафика.
2. Дополнительные ресурсы DNS-сервера помогут справиться с мелкомасштабными атаками за счет избыточности инфраструктуры DNS. Ресурсов сервера и сетевых ресурсов должно хватать не обработку большего объема запросов. Конечно, избыточность стоит денег. Вы платите за серверные и сетевые ресурсы, которые обычно не используются в нормальных условиях. И при значительном «запасе» мощности этот подход вряд ли будет эффективным.
3. Включение DNS Response Rate Limiting (RRL) снизит вероятность того, что сервер будет задействован в атаке DDoS Reflection – уменьшится скорость его реакции на повторные запросы. RRL поддерживают многие реализации DNS.
4. Используйте конфигурации высокой доступности. Можно защититься от DDoS-атак путем развертывания службы DNS на сервере высокой доступности (HA). Если в результате атаки «упадет» один физический сервер, DNS-служба может быть восстановлена на резервном сервере.

Methods

И так… У нас тут есть:

NTP

Усиление NTP — это тип атаки распределенного отказа в обслуживании (DDoS), при котором злоумышленник использует общедоступные серверы протокола сетевого времени (NTP), чтобы подавить целевой трафик протокола пользовательских дейтаграмм (UDP).

SYN

Что такое SYN-атака? TCP SYN-флуд (a.k.a. SYN-флуд) — это тип атаки распределенного отказа в обслуживании (DDoS), который использует часть обычного трехстороннего рукопожатия TCP, чтобы потреблять ресурсы на целевом сервере и делать его не отвечающим.

UDP

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

POD (Ping of Death)

Это тип атаки типа «отказ в обслуживании» (DoS), при которой злоумышленник пытается завершить работу, дестабилизировать или заблокировать целевой компьютер или службу, отправляя искаженные или негабаритные пакеты с помощью простой команды ping.

Memcached

Распределенная атака типа «отказ в обслуживании» с использованием memcached — это тип кибератаки, при которой злоумышленник пытается перегружать целевую жертву интернет-трафиком. Злоумышленник подделывает запросы к уязвимому UDP-серверу memcached *, который затем заполняет целевую жертву интернет-трафиком, потенциально перегружая ресурсы жертвы. Несмотря на то, что интернет-инфраструктура цели перегружена, новые запросы не могут быть обработаны, а обычный трафик не может получить доступ к интернет-ресурсу, что приводит к отказу в обслуживании.

453 просмотров

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

Применение фильтра на практике, история спасения сайта от одной небольшой DDoS атаки

Периодически мы сталкиваемся с DDoS атаками на наш собственный, корпоративный сайт https://cleantalk.org. Собственно во время крайней из атак мы и применили фильтр от DDoS на уровне веб-приложений сайта.

Начало атаки

Атака началась в 18:10 UTC+5 18 Января 2018 года, атаковали GET запросами на URL https://cleantalk.org/blacklists. На сетевых интерфейсах Front-end серверов появились дополнительные 1000-1200 кбит/секунду входящего трафика, т.е. получили нагрузку 150/секунду GET запросов к каждому серверу, что выше штатной нагрузки в 5 раз. Как следствие резко вырос Load average серверов Front-end и серверов баз данных. В результате сайт начал выдавать ошибку 502 по причине отсутствия свободных процессов php-fpm.

Анализ атаки

Потратив некоторое время на изучение логов, стало понятно что это именно DDoS атака, т.к.,

• 5/6 запросов приходились на один и тот же URL.
• Отсутствовала ярко выраженная группа IP адресов создающая нагрузку на URL из пункта 1.
• CPU фронтенд серверов был загружен на порядок выше, чем всплеск нагрузки на сетевых интерфейсах.

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

Включение фильтра

Потратив еще некоторое время на подготовку фильтра, в 19:15-19:20 он был включен.

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

Заключение

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

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

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

Заключение

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

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

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

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

Онлайн курс «Сетевой инженер»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные сети, рекомендую познакомиться с онлайн-курсом «Сетевой инженер» в OTUS. Это авторская программа в сочетании с удалённой практикой на реальном оборудовании и академическим сертификатом Cisco! Студенты получают практические навыки работы на оборудовании при помощи удалённой онлайн-лаборатории, работающей на базе партнёра по обучению — РТУ МИРЭА: маршрутизаторы Cisco 1921, Cisco 2801, Cisco 2811; коммутаторы Cisco 2950, Cisco 2960.

Особенности курса:

• Курс содержит две проектные работы.;
• Студенты зачисляются в официальную академию Cisco (OTUS, Cisco Academy, ID 400051208) и получают доступ ко всем частям курса «CCNA Routing and Switching»;
• Студенты могут сдать экзамен и получить вместе с сертификатом OTUS ещё сертификат курса «CCNA Routing and Switching: Scaling Networks»;

Проверьте себя на вступительном тесте и смотрите программу детальнее по .