Как защититься от DDoS-атак. Что такое DDoS-атака на сервер? Что такое DDoS

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

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

Правильные ингредиенты

Суровая правда такова, что многие сайты может положить любой желающий, воспользовавшись атакой Slowloris, наглухо убивающей Apache, или устроив так называемый SYN-флуд с помощью фермы виртуальных серверов, поднятых за минуту в облаке Amazon EC2. Все наши дальнейшие советы по защите от DDoS своими силами основываются на следующих важных условиях.

1. Отказаться от Windows Server

Практика подсказывает, что сайт, который работает на винде (2003 или 2008 - неважно), в случае DDoS обречен. Причина неудачи кроется в виндовом сетевом стеке: когда соединений становится очень много, то сервер непременно начинает плохо отвечать. Мы не знаем, почему Windows Server в таких ситуациях работает настолько отвратно, но сталкивались с этим не раз и не два. По этой причине речь в данной статье будет идти о средствах защиты от DDoS-атак в случае, когда сервер крутится на Linux. Если вы счастливый обладатель относительно современного ядра (начиная с 2.6), то в качестве первичного инструментария будут выступать утилиты iptables и ipset (для быстрого добавления IP-адресов), с помощью которых можно оперативно забанить ботов. Еще один ключ к успеху - правильно приготовленный сетевой стек, о чем мы также будем говорить далее.

2. Расстаться с Apache

Второе важное условие - отказ от Apache. Если у вас, не ровен час, стоит Apache, то как минимум поставьте перед ним кеширующий прокси - nginx или lighttpd. Apache’у крайне тяжело отдавать файлы, и, что еще хуже, он на фундаментальном уровне (то есть неисправимо) уязвим для опаснейшей атаки Slowloris, позволяющей завалить сервер чуть ли не с мобильного телефона. Для борьбы с различными видами Slowloris пользователи Apache придумали сначала патч Anti-slowloris.diff, потом mod_noloris, затем mod_antiloris, mod_limitipconn, mod_reqtimeout… Но если вы хотите спокойно спать по ночам, проще взять HTTP-сервер, неуязвимый для Slowloris на уровне архитектуры кода. Поэтому все наши дальнейшие рецепты основываются на предположении, что на фронтенде используется nginx.

Отбиваемся от DDoS

Что делать, если пришел DDoS? Традиционная техника самообороны - почитать лог-файл HTTP-сервера, написать паттерн для grep (отлавливающий запросы ботов) и забанить всех, кто под него подпадет. Эта методика сработает… если повезет. Ботнеты бывают двух типов, оба опасны, но по-разному. Один целиком приходит на сайт моментально, другой - постепенно. Первый убивает все и сразу, зато в логах появляется весь полностью, и если вы их проgrepаете и забаните все IP-адреса, то вы - победитель. Второй ботнет укладывает сайт нежно и осторожно, но банить вам его придется, возможно, на протяжении суток. Любому администратору важно понимать: если планируется бороться grep’ом, то надо быть готовым посвятить борьбе с атакой пару дней. Ниже следуют советы о том, куда можно заранее подложить соломки, чтобы не так больно было падать.

3. Использовать модуль testcookie

Пожалуй, самый главный, действенный и оперативный рецепт этой статьи. Если на ваш сайт приходит DDoS, то максимально действенным способом дать отпор может стать модуль testcookie-nginx , разработанный хабрапользователем @kyprizel. Идея простая. Чаще всего боты, реализующие HTTP-флуд, довольно тупые и не имеют механизмов HTTP cookie и редиректа. Иногда попадаются более продвинутые - такие могут использовать cookies и обрабатывать редиректы, но почти никогда DoS-бот не несет в себе полноценного JavaScript-движка (хотя это встречается все чаще и чаще). Testcookie-nginx работает как быстрый фильтр между ботами и бэкендом во время L7 DDoS-атаки, позволяющий отсеивать мусорные запросы. Что входит в эти проверки? Умеет ли клиент выполнять HTTP Redirect, поддерживает ли JavaScript, тот ли он браузер, за который себя выдает (поскольку JavaScript везде разный и если клиент говорит, что он, скажем, Firefox, то мы можем это проверить). Проверка реализована с помощью кукисов с использованием разных методов:

• «Set-Cookie» + редирект с помощью 301 HTTP Location;
• «Set-Cookie» + редирект с помощью HTML meta refresh;
• произвольным шаблоном, причем можно использовать JavaScript.

Чтобы избежать автоматического парсинга, проверяющая кукиса может быть зашифрована с помощью AES-128 и позже расшифрована на клиентской стороне JavaScript. В новой версии модуля появилась возможность устанавливать кукису через Flash, что также позволяет эффективно отсеять ботов (которые Flash, как правило, не поддерживают), но, правда, и блокирует доступ для многих легитимных пользователей (фактически всех мобильных устройств). Примечательно, что начать использовать testcookie-nginx крайне просто. Разработчик, в частности, приводит несколько понятных примеров использования (на разные случаи атаки) с семплами конфигов для nginx.

Помимо достоинств, у testcookie есть и недостатки:

• режет всех ботов, в том числе Googlebot. Если вы планируете оставить testcookie на постоянной основе, убедитесь, что вы при этом не пропадете из поисковой выдачи;
• создает проблемы пользователям с браузерами Links, w3m и им подобными;
• не спасает от ботов, оснащенных полноценным браузерным движком с JavaScript.

Словом, testcookie_module не универсален. Но от ряда вещей, таких как, например, примитивные инструментарии на Java и C#, он помогает. Таким образом вы отсекаете часть угрозы.

4. Код 444

Целью DDoS’еров часто становится наиболее ресурсоемкая часть сайта. Типичный пример - поиск, который выполняет сложные запросы к базе. Естественно, этим могут воспользоваться злоумышленники, зарядив сразу несколько десятков тысяч запросов к поисковому движку. Что мы можем сделать? Временно отключить поиск. Пускай клиенты не смогут искать нужную информацию встроенными средствами, но зато весь основной сайт будет оставаться в работоспособном состоянии до тех пор, пока вы не найдете корень всех проблем. Nginx поддерживает нестандартный код 444, который позволяет просто закрыть соединение и ничего не отдавать в ответ:

Location /search { return 444; }

Таким образом можно, например, оперативно реализовать фильтрацию по URL. Если вы уверены, что запросы к location /search приходят только от ботов (например, ваша уверенность основана на том, что на вашем сайте вообще нет раздела /search), вы можете установить на сервер пакет ipset и забанить ботов простым shell-скриптом:

Ipset -N ban iphash tail -f access.log | while read LINE; do echo "$LINE" | \ cut -d""" -f3 | cut -d" " -f2 | grep -q 444 && ipset -A ban "${L%% *}"; done

Если формат лог-файлов нестандартный (не combined) или требуется банить по иным признакам, нежели статус ответа, - может потребоваться заменить cut на регулярное выражение.

5. Баним по геопризнаку

Нестандартный код ответа 444 может пригодиться еще и для оперативного бана клиентов по геопризнаку. Вы можете жестко ограничить отдельные страны, от которых испытываете неудобство. Скажем, вряд ли у интернет-магазина фотоаппаратов из Ростова-на-Дону много пользователей в Египте. Это не очень хороший способ (прямо скажем - отвратительный), поскольку данные GeoIP неточны, а ростовчане иногда летают в Египет на отдых. Но если вам терять нечего, то следуйте инструкциям:

1. Подключите к nginx GeoIP-модуль (wiki.nginx.org/HttpGeoipModule).
2. Выведите информацию о геопривязке в access log.
3. Далее, модифицировав приведенный выше шелл-скрипт, проgrepайте accesslog nginx’а и добавьте отфутболенных по географическому признаку клиентов в бан.

Если, к примеру, боты по большей части были из Китая, то это может помочь.

6. Нейронная сеть (PoC)

Наконец, вы можете повторить опыт хабрапользователя @SaveTheRbtz, который взял нейронную сеть PyBrain, запихал в нее лог и проанализировал запросы (habrahabr.ru/post/136237). Метод рабочий, хотя и не универсальный:). Но если вы действительно знаете внутренности своего сайта - а вы, как системный администратор, должны, - то у вас есть шансы, что в наиболее трагических ситуациях такой инструментарий на основе нейронных сетей, обучения и собранной заранее информации вам поможет. В этом случае весьма полезно иметь access.log до начала DDoS’а, так как он описывает практически 100% легитимных клиентов, а следовательно, отличный dataset для тренировки нейронной сети. Тем более глазами в логе боты видны не всегда.

Диагностика проблемы

Сайт не работает - почему? Его DDoS’ят или это баг движка, не замеченный программистом? Неважно. Не ищите ответа на этот вопрос. Если вы считаете, что ваш сайт могут атаковать, обратитесь к компаниям, предоставляющим защиту от атак, - у ряда анти-DDoS-сервисов первые сутки после подключения бесплатны - и не тратьте больше время на поиск симптомов. Сосредоточьтесь на проблеме. Если сайт работает медленно или не открывается вообще, значит, у него что-то не в порядке с производительностью, и - вне зависимости от того, идет ли DDoS-атака или нет, - вы, как профессионал, обязаны понять, чем это вызвано. Мы неоднократно были свидетелями того, как компания, испытывающая сложности с работой своего сайта из-за DDoS-атаки, вместо поиска слабых мест в движке сайта пыталась направлять заявления в МВД, чтобы найти и наказать злоумышленников. Не допускайте таких ошибок. Поиск киберпреступников - это трудный и длительный процесс, осложненный самой структурой и принципами работы сети Интернет, а проблему с работой сайта нужно решать оперативно. Заставьте технических специалистов найти, в чем кроется причина падения производительности сайта, а заявление смогут написать юристы.

7. Юзайте профайлер и отладчик

Для наиболее распространенной платформы создания веб-сайтов - PHP + MySQL - узкое место можно искать с помощью следующих инструментов:

• профайлер Xdebug покажет, на какие вызовы приложение тратит больше всего времени;
• встроенный отладчик APD и отладочный вывод в лог ошибок помогут выяснить, какой именно код выполняет эти вызовы;
• в большинстве случаев собака зарыта в сложности и тяжеловесности запросов к базе данных. Здесь поможет встроенная в движок базы данных SQL-директива explain.

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

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

8. Анализируйте ошибки

Проанализируйте объем трафика, время ответа сервера, количество ошибок. Для этого смотрите логи. В nginx время ответа сервера фиксируется в логе двумя переменными: request_time и upstream_response_time. Первая - это полное время выполнения запроса, включая задержки в сети между пользователем и сервером; вторая сообщает, сколько бэкенд (Apache, php_fpm, uwsgi…) выполнял запрос. Значение upstream_response_time чрезвычайно важно для сайтов с большим количеством динамического контента и активным общением фронтенда с базой данных, им нельзя пренебрегать. В качестве формата лога можно использовать такой конфиг:

Log_format xakep_log "$remote_addr - $remote_user [$time_local] " ""$request" $status $body_bytes_sent " ""$http_referer" "$http_user_agent" $request_time \ $upstream_response_time";

Это combined-формат с добавленными полями тайминга.

9. Отслеживайте количество запросов в секунду

Также посмотрите на число запросов в секунду. В случае 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))

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

10. Не забывайте про tcpdump

Многие забывают, что tcpdump - это обалденное средство диагностики. Я приведу пару примеров. В декабре 2011-го был обнаружен баг в ядре Linux, когда оно открывало TCP-соединение при выставленных флагах TCP-сегмента SYN и RST. Первым багрепорт отправил именно системный администратор из России, чей ресурс был атакован этим методом, - атакующие узнали об уязвимости раньше, чем весь мир. Ему, очевидно, такая диагностика помогла. Другой пример: у nginx есть одно не очень приятное свойство - он пишет в лог только после полной отработки запроса. Бывают ситуации, когда сайт лежит, ничего не работает и в логах ничего нет. Все потому, что все запросы, которые в данный момент загружают сервер, еще не выполнились. Tcpdump поможет и здесь.

Он настолько хорош, что я советовал людям не использовать бинарные протоколы до того, как они убедятся, что все в порядке, - ведь текстовые протоколы отлаживать tcpdump’ом легко, а бинарные – нет. Однако сниффер хорош как средство диагностики - в качестве средства поддержания production’а он страшен. Он легко может потерять сразу несколько пакетов и испортить вам историю пользователя. Смотреть его вывод удобно, и он пригодится для ручной диагностики и бана, но старайтесь ничего критичного на нем не основывать. Другое любимое многими средство «погрепать запросы» - ngrep - вообще по умолчанию пытается запросить в районе двух гигабайт несвопируемой памяти и только потом начинает уменьшать свои требования.

11. Атака или нет?

Как отличить DDoS-атаку, например, от эффекта рекламной кампании? Этот вопрос может показаться смешным, но эта тема не менее сложная. Бывают довольно курьезные случаи. У одних хороших ребят, когда они напряглись и основательно прикрутили кеширование, сайт слег на пару дней. Выяснилось, что в течение нескольких месяцев этот сайт незаметно датамайнили какие-то немцы и до оптимизации кеширования страницы сайта у этих немцев со всеми картинками грузились довольно долго. Когда страница начала выдаваться из кеша моментально, бот, у которого не было никаких тайм-аутов, тоже начал собирать их моментально. Тяжело пришлось. Случай особенно сложный по той причине, что если вы сами изменили настройку (включили кеширование) и сайт после этого перестал работать, то кто, по вашему и начальственному мнению, виноват? Вот-вот. Если вы наблюдаете резкий рост числа запросов, то посмотрите, например, в Google Analytics, кто приходил на какие страницы.

Тюнинг веб-сервера

Какие еще есть ключевые моменты? Конечно, вы можете поставить «умолчальный» nginx и надеяться, что у вас все будет хорошо. Однако хорошо всегда не бывает. Поэтому администратор любого сервера должен посвятить немало времени тонкой настройке и тюнингу nginx.

12. Лимитируем ресурсы (размеры буферов) в 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).

13. Настраиваем тайм-ауты в 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 Задает тайм-аут при передаче ответа клиенту. Если по истечении этого времени клиент ничего не примет, соединение будет закрыто.

Сразу вопрос: какие параметры буферов и тайм-аутов правильные? Универсального рецепта тут нет, в каждой ситуации они свои. Но есть проверенный подход. Нужно выставить минимальные значения, при которых сайт остается в работоспособном состоянии (в мирное время), то есть страницы отдаются и запросы обрабатываются. Это определяется только тестированием - как с десктопов, так и с мобильных устройств. Алгоритм поиска значений каждого параметра (размера буфера или тайм-аута):

1. Выставляем математически минимальное значение параметра.
2. Запускаем прогон тестов сайта.
3. Если весь функционал сайта работает без проблем - параметр определен. Если нет - увеличиваем значение параметра и переходим к п. 2.
4. Если значение параметра превысило даже значение по умолчанию - это повод для обсуждения в команде разработчиков.

В ряде случаев ревизия данных параметров должна приводить к рефакторингу/редизайну сайта. Например, если сайт не работает без трехминутных AJAX long polling запросов, то нужно не тайм-аут повышать, а long polling заменять на что-то другое - ботнет в 20 тысяч машин, висящий на запросах по три минуты, легко убьет среднестатистический дешевый сервер.

14. Лимитируем соединия в nginx (limit_conn и limit_req)

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

Предположим, что на сайте есть разделы с говорящими названиями /download и /search. При этом мы:

• не хотим, чтобы боты (или люди с чересчур ретивыми рекурсивными download-менеджерами) забили нам таблицу TCP-соединений своими закачками;
• не хотим, чтобы боты (или залетные краулеры поисковых систем) исчерпали вычислительные ресурсы СУБД множеством поисковых запросов.

Для этих целей сгодится конфигурация следующего вида:

Http { limit_conn_zone $binary_remote_addr zone=download_c:10m; limit_req_zone $binary_remote_addr zone=search_r:10m \ rate=1r/s; server { location /download/ { limit_conn download_c 1; # Прочая конфигурация location } location /search/ { limit_req zone=search_r burst=5; # Прочая конфигурация location } } }

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

Обратите внимание на параметр 10m в примере. Он означает, что на расчет данного лимита будет выделен словарь с буфером в 10 мегабайт и ни мегабайтом более. В данной конфигурации это позволит отслеживать 320 000 TCP-сессий. Для оптимизации занимаемой памяти в качестве ключа в словаре используется переменная $binary_remote_addr, которая содержит IP-адрес пользователя в бинарном виде и занимает меньше памяти, чем обычная строковая переменная $remote_addr. Нужно заметить, что вторым параметром к директиве limit_req_zone может быть не только IP, но и любая другая переменная nginx, доступная в данном контексте, - например, в случае, когда вы не хотите обеспечить более щадящий режим для прокси, можно использовать $binary_remote_addr$http_user_agent или $binary_remote_addr$http_cookie_myc00kiez - но использовать такие конструкции нужно с осторожностью, поскольку, в отличие от 32-битного $binary_remote_addr, эти переменные могут быть существенно большей длины и декларированные вами «10m» могут скоропостижно закончиться.

Тренды в DDoS

1. Непрерывно растет мощность атак сетевого и транспортного уровня. Потенциал среднестатистической атаки типа SYN-флуд достиг уже 10 миллионов пакетов в секунду.
2. Особым спросом в последнее время пользуются атаки на DNS. UDP-флуд валидными DNS-запросами со spoof’ленными IP-адресами источника - это одна из наиболее простых в реализации и сложных в плане противодействия атак. Многие крупные российские компании (в том числе хостинги) испытывали в последнее время проблемы в результате атак на их DNS-серверы. Чем дальше, тем таких атак будет больше, а их мощность будет расти.
3. Судя по внешним признакам, большинство ботнетов управляется не централизованно, а посредством пиринговой сети. Это дает злоумышленникам возможность синхронизировать действия ботнета во времени - если раньше управляющие команды распространялись по ботнету в 5 тысяч машин за десятки минут, то теперь счет идет на секунды, а ваш сайт может неожиданно испытать мгновенный стократный рост числа запросов.
4. Доля ботов, оснащенных полноценным браузерным движком с JavaScript, все еще невелика, но непрерывно растет. Такую атаку сложнее отбить встроенными подручными средствами, поэтому Самоделкины должны с опасением следить за этим трендом.

готовим ОС

Помимо тонкой настройки nginx, нужно позаботиться о настройках сетевого стека системы. По меньшей мере - сразу включить net.ipv4.tcp_syncookies в sysctl, чтобы разом защитить себя от атаки SYN-flood небольшого размера.

15. Тюним ядро

Обратите внимание на более продвинутые настройки сетевой части (ядра) опять же по тайм-аутам и памяти. Есть более важные и менее важные. В первую очередь надо обратить внимание на:

• net.ipv4.tcp_fin_timeout Время, которое сокет проведет в TCP-фазе FIN-WAIT-2 (ожидание FIN/ACK-сегмента).
• net.ipv4.tcp_{,r,w}mem Размер приемного буфера сокетов TCP. Три значения: минимум, значение по умолчанию и максимум.
• net.core.{r,w}mem_max То же самое для не TCP буферов.

При канале в 100 Мбит/с значения по умолчанию еще как-то годятся; но если у вас в наличии хотя бы гигабит в cекунду, то лучше использовать что-то вроде:

Sysctl -w net.core.rmem_max=8388608 sysctl -w net.core.wmem_max=8388608 sysctl -w net.ipv4.tcp_rmem="4096 87380 8388608" sysctl -w net.ipv4.tcp_wmem="4096 65536 8388608" sysctl -w net.ipv4.tcp_fin_timeout=10

16. Ревизия /proc/sys/net/**

Идеально изучить все параметры /proc/sys/net/**. Надо посмотреть, насколько они отличаются от дефолтных, и понять, насколько они адекватно выставлены. Linux-разработчик (или системный администратор), разбирающийся в работе подвластного ему интернет-сервиса и желающий его оптимизировать, должен с интересом прочитать документацию всех параметров сетевого стека ядра. Возможно, он найдет там специфические для своего сайта переменные, которые помогут не только защитить сайт от злоумышленников, но и ускорить его работу.

Не бояться!

Успешные DDoS-атаки изо дня в день гасят e-commerce, сотрясают СМИ, c одного удара отправляют в нокаут крупнейшие платежные системы. Миллионы интернет-пользователей теряют доступ к критичной информации. Угроза насущна, поэтому нужно встречать ее во всеоружии. Выполните домашнюю работу, не бойтесь и держите голову холодной. Вы не первый и не последний, кто столкнется с DDoS-атакой на свой сайт, и в ваших силах, руководствуясь своими знаниями и здравым смыслом, свести последствия атаки к минимуму.

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

Почему сайт попал под атаку? Сколько атака может продолжаться?

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

Если ваш ресурс - коммерческий, атака вполне может быть происками конкурентов.

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

Отдельно следует рассматривать проекты, априори подверженные DDOS-атакам: сайты онлайн-игр (Lineage 2), инвест-проекты и так далее. Если ваш проект изначально в зоне повышенного риска, то подумать о защите от атак нужно заранее, еще до запуска.

С какой именно атакой вы столкнулись?

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

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

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

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

Если сайт размещен на VPS, определить уровень атаки можно и самостоятельно, временно отключив веб-сервер и проанализировав его логи, или обратившись за помощью к специалистам по администрированию серверов. Найти таких специалистов можно, к примеру, на фрилансерских биржах в разделе «Системное администрирование» или на веб-мастерских форумах в разделах по хостингу. Аудит сервера будет или бесплатным, или не очень дорогим. Конечно, доверять аудит стоит только специалистам с репутацией.

Зная детали атаки, вам будет проще решить, какие именно меры следует принимать для решения роблемы.

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

Хостер стандартно предлагает переход на VPS или выделенный сервер, где можно настроить фильтрацию проблемных запросов на уровне веб-сервера Nginx, либо блокировать ip-адреса бот-машин фаерволом (iptables, APF, ipfw). Cкрипты анализа логов веб-сервера можно запускать регулярно по cron, что позволяет обеспечить защиту от средних атак в автоматическом режиме.

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

Если хостер не готов помочь с защитой от атаки, или не может дать никаких гарантий того, что справится с атакой текущего уровня, то не спешите с переходом на сервер. Рассмотрите доступные средства внешней защиты. Например, сервис http://www.cloudflare.com , где даже бесплатный тарифный план может помочь отбить флуд и атаки среднего уровня. Настройка сводится всего лишь к регистрации на CloudFlare, и изменению DNS для домена вашего сайта. Аналогичные услуги можно получить в Highloadlab .

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

DoS и DDoS-атака — это агрессивное внешнее воздействие на вычислительные ресурсы сервера или рабочей станции, проводимое с целью доведения последних до отказа. Под отказом мы понимаем не физический выход машины из строя, а недоступность ее ресурсов для добросовестных пользователей — отказ системы в их обслуживании (D enial o f S ervice, из чего и складывается аббревиатура DoS).

Если такая атака проводится с одиночного компьютера, она классифицируется как DoS (ДоС), если с нескольких — DDoS (ДиДоС или ДДоС), что означает «D istributed D enial o f S ervice» — распределенное доведение до отказа в обслуживании. Далее поговорим, для чего злоумышленники проводят подобные воздействия, какими они бывают, какой вред причиняют атакуемым и как последним защищать свои ресурсы.

Кто может пострадать от DoS и DDoS атак

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

Схема, иллюстрирующая суть DDoS-атаки:

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

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

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

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

Как проводятся атаки

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

Так выглядит нормальная работа сервера, визуализированная в программе Logstalgia :

Эффективность одиночных DOS-атак не слишком высока. Кроме того, нападение с личного компьютера подвергает злоумышленника риску быть опознанным и пойманным. Гораздо больший профит дают распределенные атаки (DDoS), проводимые с так называемых зомби-сетей или ботнетов.

Так отображает деятельность ботнета сайт Norse-corp.com :

Зомби-сеть (ботнет) — это группа компьютеров, не имеющих физической связи между собой. Их объединяет то, что все они находятся под контролем злоумышленника. Контроль осуществляется посредством троянской программы, которая до поры до времени может никак себя не проявлять. При проведении атаки хакер дает зараженным компьютерам команду посылать запросы на сайт или сервер жертвы. И тот, не выдержав натиска, перестает отвечать.

Так Logstalgia показывает DDoS-атаку:

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

Способы нападения и защиты

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

Флуд

Флуд, говоря простым языком, это информация, не несущая смысловой нагрузки. В контексте DoS/DDoS-атак флуд представляет собой лавину пустых, бессмысленных запросов того или иного уровня, которые принимающий узел вынужден обрабатывать.

Основная цель использования флуда — полностью забить каналы связи, насытить полосу пропускания до максимума.

Виды флуда:

• MAC-флуд — воздействие на сетевые коммуникаторы (блокировка портов потоками данных).
• ICMP-флуд — заваливание жертвы служебными эхо-запросами с помощью зомби-сети или рассылка запросов «от имени» атакуемого узла, чтобы все члены ботнета одновременно отправили ему эхо-ответ (атака Smurf). Частный случай ICMP-флуда — ping-флуд (отправка на сервер запросов ping).
• SYN-флуд — отправка жертве многочисленных SYN-запросов, переполняя очередь TCP-подключений путем создавая большого количества полуоткрытых (ожидающих подтверждения клиента) соединений.
• UDP-флуд — работает по схеме Smurf-атак, где вместо ICMP-пакетов пересылаются датаграммы UDP.
• HTTP-флуд — заваливание сервера многочисленными HTTP-сообщениями. Более изощренный вариант — HTTPS-флуд, где пересылаемые данные предварительно шифруются, и прежде чем атакуемый узел их обработает, ему предстоит их расшифровать.

Как защититься от флуда

• Настроить на сетевых коммутаторах проверку на валидность и фильтрацию MAC-адресов.
• Ограничить или запретить обработку эхо-запросов ICMP.
• Блокировать пакеты, приходящие с определенного адреса или домена, который дает повод подозревать его в неблагонадежности.
• Установить лимит на количество полуоткрытых соединений с одним адресом, сократить время их удержания, удлинить очередь TCP-подключений.
• Отключить сервисы UDP от приема трафика извне или ограничить количество UDP-соединений.
• Использовать CAPTCHA, задержки и другие приемы защиты от ботов.
• Увеличить максимальное количество HTTP-подключений, настроить кэширование запросов с помощью nginx.
• Расширить пропускную способность сетевого канала.
• По возможности выделить отдельный сервер для обработки криптографии (если используется).
• Создать резервный канал для административного доступа к серверу в аварийных ситуациях.

Перегрузка аппаратных ресурсов

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

• Создание скрипта, который разместит на форуме или сайте, где у пользователей есть возможность оставлять комментарии, огромное количество бессмысленной текстовой информации, пока не заполнится всё дисковое пространство.
• То же самое, только заполнять накопитель будут логи сервера.
• Загрузка сайта, где выполняется какое-либо преобразование введенных данных, непрерывной обработкой этих данных (отправка так называемых «тяжелых» пакетов).
• Загрузка процессора или памяти выполнением кода через интерфейс CGI (поддержка CGI позволяет запускать на сервере какую-либо внешнюю программу).
• Вызов срабатывания системы безопасности, что делает сервер недоступным извне и т. д.

Как защититься от перегрузки аппаратных ресурсов

• Увеличить производительность оборудования и объем дискового пространства. При работе сервера в штатном режиме свободными должны оставаться не менее 25-30% ресурсов.
• Задействовать системы анализа и фильтрации трафика до передачи его на сервер.
• Лимитировать использование аппаратных ресурсов компонентами системы (установить квоты).
• Хранить лог-файлы сервера на отдельном накопителе.
• Рассредоточить ресурсы по нескольким независимым друг от друга серверам. Так, чтобы при отказе одной части другие сохраняли работоспособность.

Уязвимости в операционных системах, программном обеспечении, прошивках устройств

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

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

Эксплуатация уязвимостей не всегда имеет цель вызвать только отказ в обслуживании. Если хакеру повезет, он сможет получить контроль над ресурсом и распорядиться этим «подарком судьбы» по своему усмотрению. Например, использовать для распространения вредоносных программ, украсть и уничтожить информацию и т. д.

Методы противодействия эксплуатации уязвимостей в софте

• Своевременно устанавливать обновления, закрывающие уязвимости операционных систем и приложений.
• Изолировать от стороннего доступа все службы, предназначенные для решения административных задач.
• Использовать средства постоянного мониторинга работы ОС сервера и программ (поведенческий анализ и т. п.).
• Отказаться от потенциально уязвимых программ (бесплатных, самописных, редко обновляемых) в пользу проверенных и хорошо защищенных.
• Использовать готовые средства защиты систем от DoS и DDoS-атак, которые существуют как в виде аппаратных, так и программных комплексов.

Как определить, что ресурс подвергся нападению хакера

Если злоумышленнику удалось достичь цели, не заметить атаку невозможно, но в отдельных случаях администратор не может точно определить, когда она началась. То есть от начала нападения до заметных симптомов иногда проходит несколько часов. Однако во время скрытого воздействия (пока сервер не «лег») тоже присутствуют определенные признаки. Например:

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

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

Мы много расказываем о атаках на сайт, взломе и но тематика DDOS у нас не упоминалась. Сегодня мы исправляем это положение и предлагаем вам полный обзор технологий организации ДДОС атак и известных инструментов для выполнения хакерских атак.

Просмотреть листинг доступных инструментов для DDOS атак в KALI вы можете выполнив команду:

kali > / usr / share / exploitdb / platforms / windows / dos

Данная команда показывает базу данных эксплоитов для атаки Windows систем.

Для просмотра доступных инструментов ДДОС атаки Linux вводим команду:

/ usr / share / exploitdb / platforms / Linux / dos .

2. LOIC

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

Атаки, организованые с помощью LOIC могут утилизироваться с помощью блокировки UDP и ICMP пакетов на сетевом оборудовании интернет провайдеров. Вы можете скачать саму программу LOIC бесплатно на сайте . Этот инструмент на базе Windows и работа с ним очень проста, указываете сайты жертвы и нажимаете всего одну кнопку.

2. HOIC

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

3. XOIC

XOIC еще один очень простой DDOS инструмент. Пользователю необходимо просто установить IP адрес жертвы, выбрать протокол (HTTP, UDP, ICMP, or TCP), и нажать на спусковой крючек! Скачать его можно с

5. HULK

6. UDP Flooder

UDP Flooder соотвествует своему названию - инструмент прендназначен для отсылки множества UDP пакетов к цели. UDP Flooder часто используется при DDOS атаках на игровые сервера, для отключения игроков от сервера. Для скачивания программа доступна на .

7. RUDY

8. ToR’s Hammer

ToR’s Hammer был создан для работы через сеть, с целью достижения большой анонимности атакующего . Проблема же данного инструмена в том, что сеть TOR является достаточно медленной и тем самым снижает эфективность ДДОС атаки. Скачать эту DDOS программу вы можете с сайтов Packet Storm или .

9. Pyloris

Pyloris это еще один ддос инструмен использующий новый подход. Он позволяет атакующему создать свой уникальный HTTP запрос. Затем программа будет пытаться удерживать TCP соединение открытым с помощью таких запросов, тем самым уменьшать количество доступных соединений на сервере. Когда лимит соединений сервера подходит к концу, сервер больше не может обслуживать соединения и сайт становится не доступным. Данный инструмент доступен бесплатно для скачивания с сайта .

10. OWASP Switchblade

Open Web Application Security Project (OWASP) и ProactiveRISK разработали инсрумент Switchblade DoS tool для тестирования WEB приложений на устойчивость к ДДОС атакам.Он имеет три режима работы: 1. SSL Half-Open, 2. HTTP Post, и 3. Slowloris. Скачать для ознакомления можно с сайта OWASP .

11. DAVOSET

12. GoldenEye HTTP DoS Tool

13. THC-SSL-DOS

Эта программа для ДДОС (идет в поставке Kali) и отличается от большинства DDOS инструментов тем, что она не использует пропускную способность интернет канала и может быть использована с одного компьютера. THC-SSL-DOS использует уязвимость SSL протокола и способна «положить» целевой сервер. Если конечно эта уязвимость на нем имеется. Скачать программу можно с сайта THC , либо использовать KALI Linux где этот инструмент уже установлен.

14. DDOSIM — Layer 7 DDoS эмулятор

На этом наш обзор заканчивается, но в будущем мы еще вернемся к теме ДДОС атак на страницах нашего блога.

Last updated by at Январь 27, 2017 .

Многие популярные ресурсы подвергаются DDoS-атакам с той или иной целью.

Если являетесь владельцем популярных или стремительно растущих ресурсов, следует задумать о безопасности своего детища.

Сегодня мы расскажем, что такое DoS и DDoS атаки , каким образом осуществляются последние и какая эффективная защита от них существует.

Cодержание:

Понятие

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

В итоге учитель сдавался, так и не начав новую тему. ДоС мало чем отличается от этой элементарной схемы.

DDoS называют хакерскую атаку на сервер (-ы), которые обрабатывают запросы пользователей (посетителей сайта), с целью создания таких условий, когда тот перестанет справляться с нагрузкой.

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

Чаще всего это делается для нанесения экономического ущерба: простой приводит к расходам, восстановление системы и её защита также требуют финансовых и прочих ресурсов.

Как организовать

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

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

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

Она ждёт своей очереди, и после отправки определённой команды подключает компьютер пользователя к масштабной атаке. Этот ПК называется зомби.

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

Защититься от DDoS на 100% не может никто и нигде, ведь любой имеет свои недостатки, плюс его можно взломать.

Да и человеческий фактор в таком случае играет далеко не второстепенную роль: правильная настройка оборудования и программного обеспечения – залог успешной работы.

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

Второй и менее распространённый алгоритм – приглашение добровольцев для участия в массированной отправке запросов на указанный сервер через специальное программное обеспечение.

Третья разновидность таких кибепреступных действи й – размещение ссылок на целевой ресурс на крупных порталах (новостных). Из-за стремительного наплыва юзеров сервер не выдерживает нагрузки и «падает».

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

Причины

Специалисты в области компьютерной безопасности выделяют несколько факторов, провоцирующих DDoS:

• Самообразование, развлечение – начинающие взломщики могут попытаться навредить небольшому ресурсу с целью попрактиковаться в организации DDoS или проверить свои силы на деле.
• Личные мотивы – может быть местью кому-либо или какой-нибудь организации, например, после облав на группы хакеров веб-узлы американской спецслужбы ФБР и некоторых правительственных ведомств несколько недель не функционировали.

Схожими были и последствия блокировки крупного украинского файлообменника ex.ua.

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

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

• Финансовая выгода – злоумышленник требует определённую пользу от владельца веб-ресурса, как правило, финансовую. Такими поступками известны группы ezBTC и RedDoor.

Разновидности

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

Переполнение интернет-канала или флуд.

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

SYN-флуд – переполнение вычислительных возможностей системы ложными запросами. После установки соединения система под каждый запрос выделяет определённое количество физических ресурсов сервера.

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

Захват аппаратных ресурсов – схож с предыдущим типом, его цель – загрузить центральный процессор жертвы на 100%.

HTTP и ping-флуд применяются для атаки серверов со сравнительно небольшой пропускной способностью, когда скорость интернета хакера меньше жертвы не более, чем на порядок, а то и вовсе больше.

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

Smurf-атака. Самый серьёзный алгоритм ввиду большой вероятности того, что в обслуживании атакованной машины будет отказано.

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

UDP-флуд – Жертве посылаются echo-команды, IP атакующего изменяется на адрес атакованного, который вынужден принимать собственные запросы в большом количестве и так до занятия ложными ответами всей полосы.

Переполнение вычислительных мощностей – посылание запросов, которые для обработки требуют много . Когда ЦП будет загружен на 100%, пользователи доступ к сайту не получат.

Переполнение HDD лог-файлами. Мы говорили о влиянии квалификации системного администратора на возможность осуществления атаки на серверы, которые тот обслуживает. Если неопытный человек не установит определённые лимиты на размер лог-файла или количество записей в нём, займет всё дисковое пространство и выведет сервер из строя.

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

Атаки на кэш – подмена IP DNS-сервера на адрес жертвы. Запрос приводит не на страницу атакованного ресурса, а на сайт злоумышленника. При наличии огромного количества зомби-компьютеров они насыщают запросами, ввиду чего тот не справляется с преобразованием IP в доменные имена.

При правильной конфигурации DNS вероятность успешной атаки опускается до ноля.

Layer 7 – на запрос сервер должен отправить тяжелый пакет, например, архив или .

Существуют платные ресурсы для осуществления киберпреступлений, как vDOS.

Он предоставляет услуги всем, не спрашивая имени пользователя и цели эксплуатации сервиса.

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

Разберёмся, как это делается.

Определяем DDos

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

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

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

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

Такие люди помогут выполнить пару манипуляций в настройках для отражения атаки. Средства их выявления относятся к нескольким категориям:

• статистика – изучение активности пользователей на ресурсе;
• сигнатуры – качественный анализ входящего и исходящего трафика;
• комбинация первой и второй .

Защита: общие понятия

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

Да и то, порой лишь снизят эффективность атаки. Закрытие дыр в программном коде – более эффективная мера борьбы с зомби-компьютерами и сетями ботнетов.

И оставлять её на потом ни в коем случае не нужно.

Разберёмся, какие меры следует предпринимать при запуске сервера, создании сети и настройке ПО, чтобы избежать роли жертвы.

Выигрываем время

В зависимости от типа злодеяния различают разные алгоритмы предотвращения прерывания обслуживания.

• Для предотвращения HTTP-флуда повышаем число одновременных соединений с базой , а если атака развивается, сбрасываем эти соединения.
• ICMP-флуд – отключаем ответы на ICMP ECHO запросы.
• UDP-флуд – также отключаем данный вид запросов или ограничиваем их допустимое количество.
• SYN-флуд – если определили его наличие, уменьшаем очередь полуоткрытых соединений TCP до 1-3-х.

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

• Своевременное обновление ПО на сервере и движка сайта.
• Наличие плана реагирования на появление внештатной ситуации.
• Учёт вероятности DDoS ещё на стадии написания/заказа программного кода, его тщательное тестирование.
• Отсутствие доступа к интерфейсу администрирования с внешней сети.
• Эксплуатация тестов на проникновение и критические проблемы OWASP Top 10 Vulnerability.
• Если аппаратные средства обеспечения безопасности недоступны, предусмотрите услугу программной защиты по требованию путём внесения корректировок в схему маршрутизации.
• Эксплуатация сетей доставки контента CDN. Они позволяют распределить трафик между несколькими серверами для уменьшения таймингов и повышения скорости доступа.
• Установка файрвола Web Application Firewall на веб-приложения , который будет мониторить трафик, приходящий на сайт, и проверять его подлинность, что с большой вероятностью исключит ложные запросы.
• Не используем Apache. При эксплуатации Апачи устанавливайте кэширующий прокси nginx, но и он не спасёт от Slowloris – самого опасного способа DDoS. Лучше остановитесь на защищенном HTTPS-сервере.
• Воздействие на источник проблемы. Если знаете обидчика, посредством законодательства или иных рычагов давления вынудите его прекратить противозаконные действия. Для этого даже специальные фирмы существуют.

Безопасность DNS

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

Хотя в последнее время и они эволюционируют, а потому борорьба с такими программами становится сложнее.

Модуль отслеживает мусорные запросы, ведь тело бота почти никогда (но случаи становятся всё более частыми) не несёт в себе движка JavaScript. Он становится фильтром в случае атаки Layer 7.

Модуль проверяет:

• действительно ли бот является браузером, за который себя выдаёт:
• на самом ли деле он поддерживает JS;
• умеет ли тот переадресовывать.

Способов проверки несколько и для их всех задействуются cookies, которые в последней версии еще и шифруются посредством AES-128 при необходимости. Также может инсталлироваться через , который боты не поддерживают.

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

Инструмент распространяется бесплатно и поставляется с файлами конфигурации для различных случаев.

С недостатков testcookie обладает следующими:

• блокирует всех ботов, в том числе и Googlebot (по крайней мере в нынешнем виде), что делает его постоянное использование невозможным;
• предоставляет неудобства юзерам с редкими интернет-обозревателями, вроде Links;
• не защитит от продвинутых ботов, которые обладают .

Временное отключение функций

Хакеры в основном сосредотачиваются на самых «тяжелых» частях сайта (для больших ресурсов), таких как встроенный поиск. Если используется этот способ нанесения вреда, просто отключите поиск на время.

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

Географическое положение

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

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

Точность определения геометок, бан пользователей, и прочие недостатки – временная плата за работоспособность сайта в дальнейшем.

Отладчик

Использование профайлера Xdebug позволит увидеть самые тяжелые запросы.

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

Блокирование подозрительного трафика

Используем межсетевой экран или ACL списки для блокировки подозрительного трафика.

Такое программное обеспечение способно закрыть доступ к сайту определённым категориям запросов, но отделить реальный трафик от «плохого» не в силах.

Обратная DDoS атака

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

Часто такой процесс позволяет прекратить нападки и даже загрузить сервер атакующего до его вывода из строя.