Проверяем свой проект на уязвимость к Ddos
И так давайте начнем с того, что же такое Ddos:
DDOS-атака (с англ. Distributed Denial of Service — «отказ от обслуживания») — это атака на сайт, основной целью которой является выведение его из строя путём подачи большого количества ложных запросов. В результате такой атаки сервера, обслуживающие сайт, вынуждены обрабатывать чрезмерный объём ложных запросов, и сайт становится недоступным для простого пользователя.
Основной целью для злоумышленников, ddos применяю для устранения конкуренции в той или иной отрасли, путем полного прекращение работы атакуемого сервера за счёт подачи на него большого количества ложных запросов, с которыми не будет справляться ваш сайт.
Популярными жертвами таких атак становятся коммерческие и информационные сайты. Хацкеры в последнее время используют такой вид атак с целью вымогательства, требуя денег за прекращение атаки, или ведут информационную войну.
Кто может сделать такие атаки?
Ранее, в былых 90-x можно было сайты ложить с помощью отвертки)))
Да-да именно отвертки, которой можно было зажать кнопку F5 на клавиатуре. Из-за частого обновления страницы, которая делала частые запросы на сервер. Сервер просто напросто не справлялся с такой нагрузкой из слабости.
Сейчас же атаки организовывают с помощью БОТ-сетей. Это совокупность зараженных вирусом компьютеров которые способны синхронно исполнять команды переданные с управляющего сервера. К примеру, если бот-сети из тысячи компьютеров дать команду открыть сайт, то на целевом сайте резко возрастает нагрузка и сайт получает ДДОС атаку.
Методы DDOS атак
По крайней мере существует три различных метода организации ддос атак.
1) По полосе пропускания – данный вид атаки предполагает что на веб сайт направляется большое количество запросов по протоколам TCP, UDP и ICMP и таким образом полностью заполняют его пропускную способность. Вызывая при этом отказ в обслуживании.
2) На основе протокола сервера – данный вид атаки направлен на конкретные сервисы сервера. И может выполнятся с помощью TCP, UDP и ICMP. Часто такие атаки называют SYN-флуд, смысл которых в отсылке на веб сервер большого количества SYN запросов на которые сервер должен ответить запросом ASK. Из-за большого наводнения таких запросов, сервер часто не справляется с нагрузкой и падает.
3) На основе ошибок конкретного веб сайта – этот вид атаки является самым сложным в плане исполнения и применяется как правило высоко-проффесиональными хакерами. Суть его состоит в том что на сайте-жертве находятся уязвимости, используя которые создается высокая нагрузка на сервер и он получает отказ в обслуживании.
Инструменты
1) Linux
- качаем фреймворк metasploit-framework
- Смотрим содержание директории:
root@slogin:~ cd metasploit-framework/embedded/framework/modules/auxiliary/dos
Это все возможные инструменты для проверки на уязвимость проекта к ddos
Так же существует множество программ в Exploit Database
2) Windows
- LOIC
The Low Orbit Ion Cannon (LOIC) Низко орбитальная ионная пушка. Возможно самая популярная DDOS программа. Она может рассылать массовые запросы по протоколам ICMP, UDP тем самым забивая канал к серверу жертвы. Самая известная атака с помощью LOIC была совершена группой Anonymous в 2009 году и направлена против PayPal, Visa, MasterCard в отместку за отключение WikiLeaks от системы сбора пожертвований. Скачать можно здесь.
- HOIC
HOIC был разработан в ходе операции Payback by Praetox той же командой что создала LOIC. Ключевое отличие в том, что HOIC использует HTTP протокол и с его помощью посылает поток рандомизированных HTTP GET и POST запросов. Он способен одновременно вести атаку на 256 доменов. Вы можете скачать его с SourceForge.
Как проверить новичку свой проект на DDOS
Пример будет сделан на ОС linux, поэтому для начала установим себе его.
Затем открываем терминал и пишем в нем легкую команду для закачки себе этого приложения
Скачается файл расширения .с! Лежать он будет по этому пути: Home>xerxes
Заходим в эту директорию
Теперь компилируем это из формата “.c” в “.exe” командой gcc xerxes.c
Потом берем любой сайт и указываем его в терменале с упоминанием порта 80 и запускаем
Если сайт уязвим к ddos, то он перестанет открываться
Как защитится?
1. Отказаться от Windows Server
Практика подсказывает, что сайт, который работает на винде, в случае DDoS обречен. Причина неудачи кроется в виндовом сетевом стеке: когда соединений становится очень много, то сервер непременно начинает плохо отвечать. Я не знаю, почему Windows Server в таких ситуациях работает настолько отвратно, факт есть фактом.
2. Отказ от Apache
Если у вас, стоит Apache, то как минимум поставьте перед ним кеширующий прокси — nginx или lighttpd. Apache’у крайне тяжело отдавать файлы, и, что еще хуже, он на фундаментальном уровне уязвим для опаснейшей атаки Slowloris, позволяющей завалить сервер чуть ли не с смартфона. Для борьбы с различными видами Slowloris пользователи Apache придумали сначала патч Anti-slowloris.diff, потом mod_noloris, затем mod_antiloris, mod_limitipconn, mod_reqtimeout.
3. Использовать модуль testcookie
Отпором для DDOS, может стать модуль testcookie-nginx. Идея простая. Модуль может защитить только от ботов кокторые достаточно тупые, то-есть не имеют механизмов HTTP cookie и редиректа. Иногда конечно попадаются более продвинутые — такие могут использовать cookies и обрабатывать редиректы. Testcookie-nginx работает как быстрый фильтр между ботами и бэкендом во время DDoS-атаки, позволяющий отсеивать мусорные запросы. Проверка происходит на такие вещи:
- Умеет ли клиент выполнять HTTP Redirect,
- Поддерживает ли JavaScript,
- Тот ли он браузер, за который себя выдает
Проверка реализована с помощью кукисов с использованием разных методов:
- «Set-Cookie» + редирект с помощью 301 HTTP Location;
- «Set-Cookie» + редирект с помощью HTML meta refresh;
- произвольным шаблоном, причем можно использовать JavaScript.
Чтобы избежать автоматического парсинга, проверяющая кукиса может быть зашифрована с помощью AES-128 и позже расшифрована на клиентской стороне JavaScript. Большой минус правда, он блокирует доступ для многих легитимных пользователей (фактически всех мобильных устройств), также к недостаткку относим всех ботов, в том числе Googlebot. Если вы планируете оставить testcookie на постоянной основе, убедитесь, что вы при этом не пропадете из поисковой выдачи; создает проблемы пользователям с браузерами Links, w3m и им подобными; не спасает от ботов, оснащенных полноценным браузерным движком с JavaScript. Словом, testcookie_module не универсален.
4. Нейронная сеть (PoC)
Берем нейронную сеть PyBrain, запихиваем в нее логи и проанализируем запросы, более подробнее здесь. В этом случае весьма полезно иметь access.log до начала DDoS’а, так как он описывает практически 100% легитимных клиентов, а следовательно, отличный dataset для тренировки нейронной сети. Тем более глазами в логе боты видны не всегда.
5. Анализируйте ошибки
Проанализируйте объем трафика, время ответа сервера, количество ошибок. Для этого смотрите логи. В nginx время ответа сервера фиксируется в логе двумя переменными: request_time и upstream_response_time. Первая — это полное время выполнения запроса, включая задержки в сети между пользователем и сервером; вторая сообщает, сколько бэкенд выполнял запрос. Значение upstream_response_time чрезвычайно важно для сайтов с большим количеством динамического контента и активным общением фронтенда с базой данных, им нельзя пренебрегать.
6. Отслеживайте количество запросов в секунду
В случае nginx вы можете примерно оценить эту величину следующей shell-командой. Переменная ACCESS_LOG содержит путь к журналу запросов nginx в combined-формате:
echo $(($(fgrep -c "$(env LC_ALL=C date --date=@$(($(date \ +%s)-60)) +%d/%b/%Y:%H:%M)" "$ACCESS_LOG")/60))
По сравнению с нормальным для этого времени дня уровнем количество запросов в секунду может как падать, так и расти. Растут они в случае, если пришел крупный бот, а падают, если пришедший бот обрушил сайт, сделав его полностью недоступным для легитимных пользователей, и при этом бот статику не запрашивает, а легитимные пользователи запрашивают. Падение количества запросов наблюдается как раз за счет статики. Но, так или иначе, мы ведем речь о серьезных изменениях показателей. Когда это происходит внезапно — пока вы пытаетесь решить проблему своими силами и если не видите ее сразу в логе, лучше быстро проверьте движок и параллельно обратитесь к специалистам.
7. tcpdump
Это средство диагностики. С помощью его был обнаружен баг в ядре Linux, когда оно открывало TCP-соединение при выставленных флагах TCP-сегмента SYN и RST. Первым багрепорт отправил именно системный администратор, чей ресурс был атакован этим методом, — атакующие узнали об уязвимости раньше, чем весь мир. Ему, очевидно, такая диагностика помогла. Другой пример: у nginx есть одно не очень приятное свойство — он пишет в лог только после полной отработки запроса. Бывают ситуации, когда сайт лежит, ничего не работает и в логах ничего нет. Все потому, что все запросы, которые в данный момент загружают сервер, еще не выполнились. Tcpdump поможет и здесь. 8. Размеры буферов в nginx
Не секрет, что каждый ресурс имеет лимит. Прежде всего это касается оперативной памяти. Поэтому размеры заголовков и всех используемых буферов нужно ограничить адекватными значениями на клиента и на сервер целиком. Их обязательно нужно прописать в конфиге nginx.
- client_header_buffer_size__ Задает размер буфера для чтения заголовка запроса клиента. Если строка запроса или поле заголовка запроса не помещаются полностью в этот буфер, то выделяются буферы большего размера, задаваемые директивой large_client_header_buffers.
- large_client_header_buffers Задает максимальное число и размер буферов для чтения большого заголовка запроса клиента.
- client_body_buffer_size Задает размер буфера для чтения тела запроса клиента. Если тело запроса больше заданного буфера, то все тело запроса или только его часть записывается во временный файл.
- client_max_body_size Задает максимально допустимый размер тела запроса клиента, указываемый в поле «Content-Length» заголовка запроса. Если размер больше заданного, то клиенту возвращается ошибка 413 (Request Entity Too Large).
9. Настраиваем тайм-ауты в nginx
Ресурсом является и время. Поэтому следующим важным шагом должна стать установка всех тайм-аутов, которые опять же очень важно аккуратно прописать в настройках nginx.
- reset_timedout_connection on; Помогает бороться с сокетами, зависшими в фазе FIN-WAIT.
- client_header_timeout Задает тайм-аут при чтении заголовка запроса клиента.
- client_body_timeout Задает тайм-аут при чтении тела запроса клиента.
- keepalive_timeout Задает тайм-аут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера. Многие боятся задавать здесь крупные значения, но этот страх не оправдан. Опционально можно выставить значение тайм-аута в HTTP-заголовке Keep-Alive, но Internet Explorer знаменит тем, что игнорирует это значение
- send_timeout Задает тайм-аут при передаче ответа клиенту. Если по истечении этого времени клиент ничего не примет, соединение будет закрыто.
Нужно выставить минимальные значения, при которых сайт остается в работоспособном состоянии, то есть страницы отдаются и запросы обрабатываются. Это определяется только тестированием — как с десктопов, так и с мобильных устройств. Алгоритм поиска значений каждого параметра:
- Выставляем математически минимальное значение параметра.
- Запускаем прогон тестов сайта.
- Если весь функционал сайта работает без проблем — параметр определен. Если нет — увеличиваем значение параметра и переходим к п. 2.
- Если значение параметра превысило даже значение по умолчанию — это повод для обсуждения в команде разработчиков.
В ряде случаев ревизия данных параметров должна приводить к рефакторингу/редизайну сайта. Например, если сайт не работает без трехминутных AJAX long polling запросов, то нужно не тайм-аут повышать, а long polling заменять на что-то другое — бот в 20 тысяч машин, висящий на запросах по три минуты, легко убьет среднестатистический дешевый сервер.
10. Лимитируем соединия в nginx
В nginx также есть возможность лимитировать соединения, запросы и так далее. Если вы не уверены в том, как поведет себя определенная часть вашего сайта, то в идеале вам нужно протестировать ее, понять, сколько запросов она выдержит, и прописать это в конфигурации nginx. Одно дело, когда сайт лежит и вы способны прийти и поднять его. И совсем другое дело — когда он лег до такой степени, что сервер ушел в swap. В этом случае зачастую проще перезагрузиться, чем дождаться его триумфального возвращения. Предположим, что на сайте есть разделы с говорящими названиями /download и /search. При этом мы:
- не хотим, чтобы боты (или люди с чересчур ретивыми рекурсивными download-менеджерами) забили нам таблицу TCP-соединений своими закачками;
- не хотим, чтобы боты (или залетные краулеры поисковых систем) исчерпали вычислительные ресурсы СУБД множеством поисковых запросов.
И на последок Тренды в DDoS
- Непрерывно растет мощность атак сетевого и транспортного уровня. Потенциал среднестатистической атаки типа SYN-флуд достиг.
- Особым спросом в последнее время пользуются атаки на DNS. UDP-флуд валидными DNS-запросами со spoof’ленными IP-адресами источника — это одна из наиболее простых в реализации и сложных в плане противодействия атак. Многие крупные компании (в том числе хостинги) испытывали в последнее время проблемы в результате атак на их DNS-серверы. Чем дальше, тем таких атак будет больше, а их мощность будет расти.
- Судя по внешним признакам, большинство ботнетов управляется не централизованно, а посредством пиринговой сети. Это дает злоумышленникам возможность синхронизировать действия ботнета во времени — если раньше управляющие команды распространялись по ботнету в 5 тысяч машин за десятки минут, то теперь счет идет на секунды, а ваш сайт может неожиданно испытать мгновенный стократный рост числа запросов.
- Доля ботов, оснащенных полноценным браузерным движком с JavaScript, все еще невелика, но непрерывно растет. Такую атаку сложнее отбить встроенными подручными средствами, поэтому Самоделкины должны с опасением следить за этим трендом.
Ресурсы на которых лучше не светить своими адресами - http://viewdns.info/
- https://iphostinfo.com/
И помните все показанное выше, сделано в целях обучения!!!
Можно применять только на своих проектах, после разрешения.