Войтиmode_comment Новости и общениеmode_comment Интернет технологииmode_comment Уголок геймераmode_comment Реклама и торговляmode_comment Клуб журналистов
group Люди
assignment О проектеalternate_email Для связи
Форум
arrow_upward Наверх
keyboard_arrow_right Форум
messageIT и безопасность - Проверяем свой проект на уязвимость к DDoS
18 Ноя в 23:56
DDOS-атака (с англ. Distributed Denial of Service — «отказ от обслуживания») — это атака на сайт, основной целью которой является выведение его из строя путём подачи большого количества ложных запросов. В результате такой атаки сервера, обслуживающие сайт, вынуждены обрабатывать чрезмерный объём ложных запросов, и сайт становится недоступным для простого пользователя. 

В этой статье я напишу названия софта которым можно проверить свой сайт на уязвимость к DDOS
Войдите под своим ником, чтобы писать в темах
Dezzer Работает 18 Ноя в 23:57
Методы DDOS атак 
По крайней мере существует три различных метода организации ддос атак. 
1) По полосе пропускания — данный вид атаки предполагает что на веб сайт направляется большое количество запросов по протоколам TCP, UDP и ICMP и таким образом полностью заполняют его пропускную способность. Вызывая при этом отказ в обслуживании. 
2) На основе протокола сервера — данный вид атаки направлен на конкретные сервисы сервера. И может выполнятся с помощью TCP, UDP и ICMP. Часто такие атаки называют SYN-флуд, смысл которых в отсылке на веб сервер большого количества SYN запросов на которые сервер должен ответить запросом ASK. Из-за большого наводнения таких запросов, сервер часто не справляется с нагрузкой и падает. 
3) На основе ошибок конкретного веб сайта — этот вид атаки является самым сложным в плане исполнения и применяется как правило высоко-проффесиональными хакерами. Суть его состоит в том что на сайте-жертве находятся уязвимости, используя которые создается высокая нагрузка на сервер и он получает отказ в обслуживании
Dezzer Работает 18 Ноя в 23:58
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 от системы сбора пожертвований. Скачать можно sourceforge.net/projects/loic/

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


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

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-формате:
[code]echo $(($(fgrep -c “$(env LC_ALL=C date — date=@$(($(date +%s)-60)) +%d/%b/%Y:%H:%M)” “$ACCESS_LOG”)/60))[/code]
По сравнению с нормальным для этого времени дня уровнем количество запросов в секунду может как падать, так и расти. Растут они в случае, если пришел крупный бот, а падают, если пришедший бот обрушил сайт, сделав его полностью недоступным для легитимных пользователей, и при этом бот статику не запрашивает, а легитимные пользователи запрашивают. Падение количества запросов наблюдается как раз за счет статики. Но, так или иначе, мы ведем речь о серьезных изменениях показателей. Когда это происходит внезапно — пока вы пытаетесь решить проблему своими силами и если не видите ее сразу в логе, лучше быстро проверьте движок и параллельно обратитесь к специалистам. 

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-соединений своими закачками; 
- не хотим, чтобы боты (или залетные краулеры поисковых систем) исчерпали вычислительные ресурсы СУБД множеством поисковых запросов. 
Statok.net