Способы защиты от ddos атак. Kaspersky DDoS Protection Непрерывная работа вашего бизнеса

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

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

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

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

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

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

Пожалуй, самый главный, действенный и оперативный рецепт этой статьи. Если на ваш сайт приходит 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#, он помогает. Таким образом вы отсекаете часть угрозы.

Целью 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 на регулярное выражение.

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

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

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

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

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

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

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

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

Проанализируйте объем трафика, время ответа сервера, количество ошибок. Для этого смотрите логи. В 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-формат с добавленными полями тайминга.

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

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

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

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

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

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

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

• reset_timedout_connection on; Помогает бороться с сокетами, зависшими в фазе FIN-WAIT.
• client_header_timeout Задает тайм-аут при чтении заголовка запроса клиента.
• client_body_timeout Задает тайм-аут при чтении тела запроса клиента.
• keepalive_timeout Задает тайм-аут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера. Многие боятся задавать здесь крупные значения, но мы не уверены, что этот страх оправдан. Опционально можно выставить значение тайм-аута в HTTP-заголовке Keep-Alive, но Internet Explorer знаменит тем, что игнорирует это значение
• send_timeout Задает тайм-аут при передаче ответа клиенту. Если по истечении этого времени клиент ничего не примет, соединение будет закрыто.

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

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

В 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» могут скоропостижно закончиться.

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

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

• 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

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

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

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

Аббревиатура DDoS означает Distributed Denial of Service - распределённая атака на отказ в обслуживании. DDoS-атакой называется нарушение функционирования атакуемой машины путём отправки на неё запросов с многочисленных хостов.

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

Некоторые виды атак могут осуществляться и без ботнета (например, UDP-флуд).

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

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

Для предотвращения DDoS-атак обычно используются аппаратные методы защиты периметра сети - файервол в сочетании с системой обнаружения вторжений (Intrusion Detection Systems, IDS). Однако защиты в строгом смысле этого слова они не обеспечивают.

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

Кроме того, и файерволы, и IDS зачастую являются устройствами с контролем сессий, поэтому сами могут стать объектом атаки.

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

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

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

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

В последние годы широкое распространение получили комплексные программно-аппаратные решения для защиты от DDoS. Их преимущество заключается в том, что они могут не пропускать вредоносный трафик, не создавая при этом проблем с доступностью атакуемого сервиса для легитимных пользователей. На рынке представлены программно-аппаратные комплексы для защиты от DDoS от компаний Cisco, Arbor Networks, F5, Juniper и других.

На базе специализированного программно-аппаратного комплекса реализована и наша услуга защиты от DDoS. Она оказывается совместно с нашими партнёрами - компанией Servicepipe .

Используемая система защиты от DDoS включает не один, а несколько программно-аппаратных комплексов, в том числе Arbor Pravail и F5. Очистка и анализ трафика осуществляются непосредственно в сети при помощи специализированных программных инструментов.

Эта система обеспечивает защиту от следующих видов атак:

• TCP-флуд;
• SYN-флуд;
• нелигитимные комбинации TCP-флагов;
• атаки на TCP-сессии типа TCP Idle, Slow TCP и другие;
• атаки на HTTP-сессии (Slowloris, Pyloris и т.п.);
• HTTP-флуд;
• DNS-флуд;
• DNS Cache Poisoning;
• UDP-флуд;
• ICMP-флуд;
• атаки IP-, TCP и UDP-фрагментами;
• атаки на VoIP и SIP.

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

• Invalid packet List - фильтрация пакетов, не соответствующих RFC;
• создание чёрных и белых список IPv4- и IPv6-адресов;
• GeoIP Filter Lists - фильтрация трафика по странам (блокирует трафик из стран, откуда приходит наибольшее число DDoS-атак).
  GeoIP Policing - полисинг трафика по странам (мониторинг входящего трафика и ограничение трафика из стран, откуда приходит наибольшее количество DDoS-атак);
• Flexible Zombie Detection - выявление зомби и создание профилей легитимного трафика;
• TCP SYN Authentication - противодействие TCP-флудам посредством аутентификации клиента;
• DNS Authentication - противодействие DNS-флудам посредством аутентификации клиента;
• DNS Scoping - валидация DNS-запросов с помощью регулярных выражений;
• DNS Malformed - проверка DNS-запросов на соответствие RFC;
• DNS Rate Limiting - ограничение количества DNS-запросов с одного IP-адреса (подойдёт лишь для ресурсов с небольшой посещаемостью: в нашей стране провайдерами очень часто используется NAT. Вполне типичным является случай, когда «серая» подсеть /16 выходит в Интернет через один IP, и все DNS-запросы идут с одного адреса);
• DNS NXDomain Rate Limiting - валидация DNS-ответов. Эта противомера предназначена для атак, при которых кэш DNS-серверов переполняется невалидными записями; она направлена на отслеживание запросов с несуществующим DNS-именем;
• DNS Regular Expression - фильтрация DNS-запросов по регулярным выражениям;
• TCP Connection Reset - предотвращение слишком долгих TCP-соединений;
• Payload Regular Expression - фильтрация трафика посредством регулярного выражения применительно к Payload- пакетам;
• HTTP Malformed - блокирование HTTP-трафика, не соответствующего RFC;
• HTTP Rate Limiting - ограничение количества HTTP-запросов с одного IP-адреса;
• HTTP Scoping - валидация HTTP-запросов с помощью регулярных выражений;
• SSL Negotiation - блокирование SSL-трафика, не соответствующего RFC;
• AIF and HTTP/URL Regular Expression - наложение сигнатур AIF на исследуемый трафик;
• SIP Malformed - блокирование SIP-трафика, не соответствующего RFC;
• SIP Request Limiting - ограничение количества SIP-запросов с одного IP-адреса.

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

Маршрут движения очищенного трафика показан на следующей схеме:

В числе преимуществ нашей системы защиты от DDoS нужно в первую очередь выделить следующие:

• быстрое подключение: полная настройка защиты от DDoS занимает 1 - 2 рабочих дня;
• доступные цены и прозрачная схема тарификации: оплате подлежит только входящий очищенный трафик;
• отсутствие необходимости сложной настройки на стороне клиента: достаточно просто прописать защищённый IP-адрес алиасом или на loopback-интерфейс;

Услуга уже доступна для заказа в панели управления (раздел «Услуги сети»).
При заказе вам нужно будет заполнить специальный опросник и указать следующее:

• основную цель использования сервера;
• количество IP-адресов, которые необходимо защитить;
• желаемые меры по защите от DDoS.

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

Для самых популярных вариантов использования сервера (веб-сервер, сервер приложений, DNS-сервер) мы подготовили специальные шаблоны защиты, подходящие для большинства клиентов.

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

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

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

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

Для защиты IIS серверов можно воспользоваться (программным) решением от компании Microsoft, но, зная щедрость этой компании, можно догадаться, что они тоже далеко не бесплатные.

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

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

Если же вас «заказали», или вы не послушались предыдущего совета, будьте начеку - аппаратные ресурсы веб-сервера обязательно должны иметь некоторый резерв производительности, а распределенные и дублирующие системы - построены максимально эффективно. Без понимания принципов работы DDoS, эффективную защиту построить просто невозможно. Для осуществления DDoS-атак используется большое количество компьютеров, зараженных вредоносным кодом. Эти компьютеры объединяются в ботнеты (“bot-net” - сети зомби-машин), которые по приказу злоумышленника осуществляют DDoS-атаки, причем владельцы компьютеров зачастую даже не подозревают об этом.

Мы , как хостинг-компания, сталкиваемся с DDoS-атаками на сайты наших клиентов ежедневно и имеем некоторый опыт в борьбе с ними. Как было сказано выше, универсальных мер защиты попросту нет, но атаку все же можно отразить. Предположим, что на некий сайт (пусть это будет domain.ru) идет DDoS атака. По логам видно, что большое количество GET запросов идет на главную страницу. В большинстве таких случаев, ботов можно обмануть воспользовавшись javascript-редиректом. К примеру:

window.location = "domain.ru/index.php"

Как результат - с каждым разделом, который атакован GET запросом прямо в корень, размер файла получится всего несколько байт, что гораздо лучше, чем когда бот соприкасается c ~50-100кб страницей и при этом подтягивает ~5-10 SQL запросов. Легитимные же пользователи, у которых не отключен javascript в браузере, перенаправляются на index.php.

Но есть одно большое НО – поисковые-боты тоже не оборудованы js-интерпретаторами и точно так же, как и атакующие боты, будут утопать в js редиректе. Можно, воспользовавшись такими UNIX утилитами как tcpdump или netstat, написать небольшой скрипт, который будет считать кол-во коннектов с определенного IP адреса, и банить его.

Определить бота можно, например, проверив его host. Небольшой пример элементарного скрипта по блокировке IP, которые создают много коннектов к серверу (данный вариант проверялся на Centos 5.6):

Запись в crond

*/1 * * * * netstat -an | grep tcp | awk "{print $5}" | cut -d: -f1 | sort -n | uniq -c > /var/log/ip.list

Данная команда создает список с кол-вом подключений и самим IP, пример:

10 209.232.223.117
1 209.85.161.191
2 212.113.39.162
1 212.78.78.78
61 213.142.213.19
5 213.151.240.177
1 210.169.67.225
1 216.179.59.97

Сам скрипт, который можно запустить в screen-е или сделать демоном:

#!/bin/bash
connects=150 /dev/null 2>&1
then
// если в имени хоста есть слово google (у гугло-ботов это слово присутствует)
if echo $hostname | grep "google" > /dev/null 2>&1
then
// то добавляем его в белый список и делаем запись в лог
echo "$ip" >> /etc/white.list
echo `date +%H:%M_%d-%m-%Y` $ip "- ADDED TO WHITE LIST AS $hostname SEARCH BOT IP" >> /var/log/ddos_log
else
// если не гугл - блочим
route add $hostname reject
fi
fi
fi
done < /var/log/ip.list

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

TimeOut – указывайте как можно меньшее значение для данной директивы (веб сервера, который подвержен DDoS атаке).

KeepAliveTimeout директива – также нужно снизить ее значение или полностью выключить.

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

Директивы LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, LimitXMLRequestBody должны быть тщательно настроены на ограничение потребления ресурсов вызванных запросами клиентов.

Убедитесь, что вы используете директиву AcceptFilter (на ОС которые поддерживают ее). По умолчанию она включена в конфигурации Apache httpd, но для своей работы может потребовать пересборку с новыми настройками ядра вашей ОС (*nix, *bsd).

Используйте директиву MaxClients, чтобы указать максимальное количество клиентов, которые смогут быть одновременно подключены к серверу - уменьшив значение директивы вы сможете снизить нагрузку на web-сервер.

Защитится от DDoS можно и на программном уровне. В этом вам поможет бесплатный скрипт – DDoS Deflate. С его помощью можно легко избавится от детского флуда и DDoS. Скрипт использует команду «netstat» для обнаружения DDoS и флуда, после чего блокирует IP адреса вредителей с помощью фаервола iptables или apf. Но не стоит расслабляться и считать, что слабый DDoS не сможет нанести ущерб вашему серверу. Возьмем, к примеру, что атакующих зомби-машин всего 10-50, но все они с толстыми каналами, а Вы, как назло, уехали в командировку, или у вас десятки (а то и сотни) серверов, и Вы не успеваете физически “мониторить” их все. В таком случае, даже небольшое количество машин сможет “зафлудить” канал или заставить выйти из строя вебсервер apache, mysql, etc. Другое дело, когда администратор круглосуточно “мониторит” сервер и с легкостью обнаруживает атаки. Но такое бывает крайне редко, поэтому нужно подключить систему сигнализации, а процесс блокировки атакующих зомби-машин - автоматизировать.

P.S. Статья была прислана мне юзером . Вопросы по статье, рекомендации по следующим статьям и интересующим темам и вопросам просьба присылать ему.

Спасибо за внимание!

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

Защититься от DDoS сложно по следующим трем основным причинам.

• Врожденные уязвимости сети . Во-первых, в этом случае нет уязвимостей сети, которая используется преступниками. Атака успешна потому, что в природе всех компьютерных платформ существует некий порог доставки. Компьютеры, кластеры или облачные системы - все они имеют физические ограничения по количеству запросов, которые они могут обрабатывать в заданное время. Успешная атака DDoS должно просто генерировать достаточное количество трафика, чтобы превысить это пороговое значение. Большая часть других атак может быть отражена путем использования специальных патчей, конфигурацией систем безопасности или изменение политик. Но ни один из этих подходов не поможет противостоять DDoS. Службы должны быть всегда доступны и, значит, уязвимы для атак.

• Невозможность заблокировать толпу . DDoS очень сложно заблокировать, поскольку существует очень много источников атаки. Очень трудно обеспечить эффективную блокировку длинного списка атакующих IP-адресов. Потенциально тысячи адресов должны быть временно добавлены в черный список для того, чтобы остановить атаку. Если атакующий использует метод, прикрывающий атаку вполне легитимными хостами (spoofing), то в черный список могут попасть и невинные хосты.

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

• Установите приоритеты важности приложений, для того, чтобы сохранить наиболее приоритетные. В условиях интенсивной DDoS-атаки и ограниченных ресурсов необходимо сосредоточиться на приложениях, обеспечивающих основные источники прибыли.

• Защитите удаленных пользователей. Обеспечьте работу вашего бизнеса: занесите в белый список IP-адреса доверенных удаленных пользователей, которым необходим доступ, и сделайте этот список основным. Распространите это список в сети и отправьте его поставщикам услуг доступа.

• Определите класс атаки. C каким типом атаки вы столкнулись: Объемная? Маломощная и медленная? Ваш поставщик услуг сообщит вам, является ли атака исключительно объемной.

• Оцените варианты борьбы с адресами источников атак. В случае сложных атак ваш поставщик услуг не сможет преодолеть/определить количество источников. Заблокируйте небольшие списки атакующих IP-адресов в вашем межсетевом экране. Более крупные атаки можно блокировать на основе данных о геопозиционировании.

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

• Усильте свой периметр защиты. Возможно, вы столкнулись с ассиметричной атакой DDoS 7 уровня. Сосредоточьтесь на защите на уровне приложений: используйте системы логинов, систему распознавания людей или технологию Real Browser Enforcement.

• Ограничьте сетевые ресурсы. Если предыдущие меры не помогли, то необходимо ограничить ресурсы – таким образом будет ограничен «плохой» и «хороший» трафик.

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

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

Дополнительные материалы

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

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

Мощная DDoS-атака может занять всю емкость интернет-канала «жертвы», поэтому на стороне атакуемого проблему не решить: эффективная защита может быть обеспечена только на уровне оператора связи. Internet Umbrella постоянно контролирует уровень превышения интенсивности различных профилей трафика для защищаемой сети и сравнивает его со стандартными значениями трафика. В случае атаки оборудование фильтрует вредоносные пакеты и направляет клиенту только очищенный трафик. Все эти действия производятся в автоматическом режиме 24 часа в сутки, а емкость интернет-каналов оператора достаточна для того, чтобы предотвращать самые мощные атаки. Выделенная смена технических специалистов Orange наблюдает за эффективностью и работоспособностью услуги в режиме 24/7 и оперативно вносит корректировки по мере необходимости.

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

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

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

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

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

Есть два допущения в отношении борьбы с DoS/DDoS-атаками. Во-первых, требуется остановить атаку как можно раньше, прежде чем она проникнет глубоко в сеть. Во-вторых, что является более очевидным, требуется проверять весь трафик. Этого нелегко добиться при атаках, основанных на использовании протокола HTTPS .

Уже к 2012 году команда ERT столкнулась с возросшим количеством просьб о помощи в борьбе с HTTPS- атаками. Удивительно, что такие атаки раньше не так часто использовались, однако в это время ожидался резкий рост их популярности.

Почему HTTPS-атака представляет такую угрозу? Несмотря на то, что в ней используется протокол, аналогичный протоколу HTTP, она представляет угрозу совершенно иного уровня. Причина в следующем: как правило, HTTP-атаки можно обнаружить и ликвидировать с помощью системы защиты от DDoS-атак, которая расположена на клиентском оборудовании (CPE), в облаке или, в идеальном случае, и там, и там. Такие решения могут справиться с HTTP-атаками уровня приложений или атаками на переполнение сети.

Однако когда те же самые атаки выполняются посредством протокола HTTPS, дела обстоят по-другому. Сетевые флуды могут быть остановлены; данные пока не шифруются, и SYN-флуд, к примеру, по HTTPS выглядит точно также, как и по HTTP. Однако атаки на приложения достаточно сложно обнаружить.

Как показано на рисунке, зашифрованный HTTPS-трафик обычно дешифруется только на веб-сервере, балансировщике нагрузки или выделенном устройстве для SSL-терминации. Данные объекты обычно лежат дальше в сети после того уровня, где трафик проверяется системами защиты от DoS-атак (в облаке или CPE):

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

Помимо HTTPS-атак, существуют атаки, присущие именно уровню SSL , которые нацелены непосредственно на механизм обмена данными по SSL. SSL-атаки, которые выполняются с помощью инструмента THC-SSL-DOS, подробно обсуждались в отчете за 2011 год, однако мы вкратце изложим этот вопрос.

Обычно SSL-подтверждение выполняется только единожды с целью установки безопасного соединения. Для атаки используется опция протокола на «повторное согласование» для установки нового секретного ключа. Отправляя многократные запросы на повторное SSL-согласование, злоумышленник значительно повышает нагрузку на процессор целевого сервера до того момента, когда тот уже не может дальше работать.

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

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

Необходимо рассматривать качество на трёх уровнях:

• качество восприятия услуги пользователем здесь и сейчас;
• ожидания пользователя относительно качества услуги во время определённого периода времени (час, неделя, месяц);
• гарантия качества, построенная на уверенности пользователя, что предоставляемый сервис не окажет скрытого негативного влияния на него (компьютер не взломают, не заразят вирусом и т.д.).

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

Защита от DDoS-атак с использованием SSL-шифрования чем-то напоминает работу службы безопасности в аэропортах на Ближнем Востоке: всегда есть множество женщин с прикрытыми лицами, которых нужно не просто деликатно досматривать, но и анализировать поведение. Иначе рано или поздно одна из них взорвет самолёт. Технически в защите от таких атак используются специфические подходы, но при адекватных настройках расшифровка HTTPS-сообщений потребует не так много ресурсов. Проблема в другом: далеко не каждый клиент готов дать полный доступ к своим зашифрованным каналам. Можно ли эффективно анализировать трафик без ключей?

«Сегодня с помощью HTTPS-сообщений атакуют множество защищенных ресурсов, а SSL используют в том числе для того, чтобы обойти средства безопасности, – поясняет суть проблемы руководитель Qrator Labs Александр Лямин. – В отличие от прямых DDoS-атак на механизмы шифрования, которые происходят на уровнях L5 и L6, атаки с использованием SSL относятся к уровню L7. Поэтому они очень похожи на действия легитимных пользователей».

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

Например, ботнет может имитировать зашифрованное соединение и выполнить SSL-атаку. Шифрование каждого канала связи способно какое-то время скрывать от систем безопасности и администраторов сайта наличие вредоносной активности. В итоге это может привести к утечке конфиденциальных данных или нарушению работы сайта.
«Атаки L7 в любом случае попадают в корпоративную сеть, – комментирует Александр Лямин. – Так как первые пакеты HTTPS-запроса от атакующего – сугубо служебные, то они всегда выглядят легитимно. Понять на этом этапе намерения удалённого клиента принципиально невозможно».

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

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

С ключом

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

Без ключа

Как показывает практика, многие клиенты из сферы розничной торговли и СМИ предпочитают раскрыть ключи шифрования поставщику средств защиты. Это считается допустимым риском, поскольку SSL-шифрование используется у них только для изоляции клиентов друг от друга и предотвращения перехвата данных из слабо защищённых сегментов сети – например, через Wi-Fi. Финансовые организации, напротив, предпочитают настраивать сервера таким образом, чтобы поставщику была доступна только косвенная информация.

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

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