Проверяем свой проект на уязвимость к Ddos

gallery/0_z_fgcgbymmyu_gui

 

DDOS-атака (с англ. Distributed Denial of Service — «отказ от обслуживания») — это атака на сайт, основной целью которой является выведение его из строя путём подачи большого количества ложных запросов. В результате такой атаки сервера, обслуживающие сайт, вынуждены обрабатывать чрезмерный объём ложных запросов, и сайт становится недоступным для простого пользователя.

 

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

 

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

 

Кто может сделать такие атаки?

Ранее, в былых 90-x можно было сайты ложить с помощью отвертки)))

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

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

 

Методы DDOS атак

По крайней мере существует три различных метода организации ддос атак.

 

1) По полосе пропускания — данный вид атаки предполагает что на веб сайт направляется большое количество запросов по протоколам TCP, UDP и ICMP и таким образом полностью заполняют его пропускную способность. Вызывая при этом отказ в обслуживании.

 

2) На основе протокола сервера — данный вид атаки направлен на конкретные сервисы сервера. И может выполнятся с помощью TCP, UDP и ICMP. Часто такие атаки называют SYN-флуд, смысл которых в отсылке на веб сервер большого количества SYN запросов на которые сервер должен ответить запросом ASK. Из-за большого наводнения таких запросов, сервер часто не справляется с нагрузкой и падает.

 

3) На основе ошибок конкретного веб сайта — этот вид атаки является самым сложным в плане исполнения и применяется как правило высоко-проффесиональными хакерами. Суть его состоит в том что на сайте-жертве находятся уязвимости, используя которые создается высокая нагрузка на сервер и он получает отказ в обслуживании.

 

Инструменты

 

1) Linux

gallery/0_yes3jejwkl5yks5n
gallery/1_xfcy-523ac4_o3vr7bxphq
gallery/1_vg3h--l1s7uovzmqbndr0q
gallery/1_oomkdsp2csnajpbfm1cria
gallery/1_-gndeqoonday5_uvycciqg
gallery/1_dgbkryyukc-h-xwp7zex0q
gallery/1_dahcbsxdlcxnmn4l99xxgg
gallery/1_4h1x3kpovpxdcaioe-0eva
gallery/0_qynv_klsrz4mktqm
gallery/1_7sdl8xb1ag4_yxncmmhiig
gallery/1_cvy0fteos4pdgumcrkic5w
Вернуться назад

И помните все показанное выше, сделано в целях обучения!!!

Можно применять только на своих проектах, после разрешения.

-https://iphostinfo.com/

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/

Если сайт уязвим к ddos, то он перестанет открываться

 

Как защитится?

Потом берем любой сайт и указываем его в терменале с упоминанием порта 80 и запускаем

Теперь компилируем это из формата “.c” в “.exe” командой gcc xerxes.c

Загрузиться файл расширения .с! Лежать он будет по этому пути: Home>xerxes

Заходим в эту директорию

Как проверить новичку свой проект на DDOS

Пример будет сделан на ОС linux, поэтому для начала установим себе его.

Затем открываем терминал и пишем в нем легкую команду для закачки себе этого приложения

- HOIC

HOIC был разработан в ходе операции Payback by Praetox той же командой что создала LOIC. Ключевое отличие в том, что HOIC использует HTTP протокол и с его помощью посылает поток рандомизированных HTTP GET и POST запросов. Он способен одновременно вести атаку на 256 доменов. Вы можете скачать его с SourceForge.

Это все возможные инструменты для проверки на уязвимость проекта к ddos

 

Так же существует множество программ в Exploit Database

 

2) Windows

 

- LOIC

The Low Orbit Ion Cannon (LOIC) Низко орбитальная ионная пушка. Возможно самая популярная DDOS программа. Она может рассылать массовые запросы по протоколам ICMP, UDP тем самым забивая канал к серверу жертвы. Самая известная атака с помощью LOIC была совершена группой Anonymous в 2009 году и направлена против PayPal, Visa, MasterCard в отместку за отключение WikiLeaks от системы сбора пожертвований. Скачать можно здесь.

- Качаем фреймворк metasploit-framework

 

- Смотрим содержание директории:

root@slogin:~ cd metasploit-framework/embedded/framework/modules/auxiliary/dos