Как СОПСА борется с DDOS?

Бесперебойная работа хостинга напрямую связана с отражением DDOS трафика, так как атаки затрагивают не только жертву, но и влияют на всю инфраструктуру дата центра. Для защиты от паразитного трафика, компания НТКОМ, предоставляющая услуги хостинга, аренды серверов и облачных сервисов, разработала собственное решение СОПСА (Система Обнаружения и Предотвращения Сетевых Атак), которая является полностью российской разработкой с возможностью реализации на процессорах Intel или Эльбрус. СОПСА позволяет производить мониторинг сервисов на основе Netflow протокола, используя связь с роутером через BGP, выявлять DOS\DDOS аномалии, а также производить фильтрацию вредоносного трафика.

В данной статье будет рассмотрен пример фильтрации реальной DDOS атаки с объяснением логики действий по ее выявлению.

 

Почему не использовать зарубежные аналоги?

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

 

С чего все началось?

Началось все с многочисленных уведомлений о резком возрастании объема трафика и сильной загрузки каналов на роутерах. Первоначальной задачей нужно понять, что происходит: сгорел роутер, ошибка конфигурирования, уборщица выдернула интерфейс, началась DOS\DDOS атака или что-то иное. Система СОПСА использует взаимодействие Netflow+BGP+SNMP, что позволяет производить мониторинг оборудования, интерфейсов, аудит трафика, выявление аномалий в трафике и нестабильностей маршрутизации.

С оборудованием оказалось все в порядке, но сильно возросло количество трафика, началась DDOS атака. Используя механизм задания объектов, были заданы правила на детектирование доминующих IP адресов получателей трафика, а также IP клиентов, с которых передается максимальный объем данных.

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

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

Для решения проблемы забивки канала были использованы возможности BGP Flow Spec протокола по заданию статических правил на роутере для фильтрации трафика, идущего с DNS серверов. Это позволило существенно понизить нагрузку на каналы, но сервер по-прежнему оставался недоступен.

Следующим шагом был захват трафика на основе BGP протокола для более глубокого анализа. Система производит BGP анонс, анонсируя информацию об атакуемом IP адресе, и указывая другой nexthop, соответствующий IP адресу системы СОПСЫ. Роутер отправляет трафик на систему фильтрации, она производит фильтрацию и возвращает трафик на атакуемый сервер. В данной схеме захватывается лишь часть, интересующего нас трафика, трафик на не атакуемые сервера не попадает на систему фильтрации и проходит по стандартному маршруту. Трафик, отправляемый с атакуемого сервера, проходит по стандартному маршруту, минуя систему фильтрации.

Захват трафика сразу позволил выделить особенность атаки, она представляла собой смесь syn-флуда с подставных IP адресов, icmp пинги, простаивающие TCP соединения, медленные HTTP запросы, HTTPS запросы и прочее не понятное, вплоть до некорректного использования HTTP протокола.

Первым шагом фильтрации, средствами системы СОПСА, был фаервол со статическими правилами, сначала надо заблокировать лишний трафик на неиспользуемые сервисы или протоколы. ICMP протокол не является обязательным для работы TCP\IP и часто используется как средство диагностики или доступности оборудования. Похоже, что многие BotNet сети участвующие в DDOS атаке, периодически пингуют сервер, чтобы определить стабильность его работы, если он недоступен сила атаки немного понижается.

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

Столь сильный разброс трафика по странам, может свидетельствовать или о масштабе BotNet сети, или о том, что в DDOS атаке используются подставные или случайные IP адреса.

Следующий шаг, отделить реальные IP адреса от подставных. Для этого может использоваться метод syn cookie авторизации. В данном методе система производит авторизацию IP адресов клиентов с целью выявления реальных IP. Алгоритм работы широко известен и распространен.

Во время установки TCP соединения, на приходящие пакеты с флагом SYN, система фильтрации отправляет SYN+ACK флаг, устанавливая волшебные SEQ значения, которые IP адрес клиент, в случае если он реальный, должен подтвердить пакетом ACK флагом, что будет служить авторизацией IP адреса и подтверждения его желания установить TCP соединение. Недостатком, данного метода, является существенный объем отправляемого трафика. Поэтому, у системы фильтрации СОПСА предварительно доступен другой метод “фильтрации первого пакета”, суть которого, блокировать первый TCP.SYN пакет, запоминать его, и в случае повторно его прихода такого же пакета, пропускать его до метода syn cookie.

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

По ранее проделанным оценкам, мы пришли к выводу, что для нормального доступа к сайту, нормальному пользователю, более чем достаточно от 50 до 100 активных TCP\UDP потоков (зависит от сайта и количества содержимого на нем). Тем самым, суть следующего включаемого фильтра, позволит ограничить количество активных потоков для каждого IP адреса клиента. В случае превышения количества одновременных активных потоков, система будет считать IP адрес клиент атакуемым.

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

Проверив доступность сервера, мы увидели, что он медленно, но начинает работу. Все используемые методы ранее были направленные на фильтрацию данных на уровне TCP\IP стека операционной системы, то есть, являющимися универсальными для любого сервиса. Но на уровне известного протокола, по которому работает сервис, также возможны аутентификации, использующие особенности протокола, что также позволяет выявлять участников BotNet сети. Для http протокола, возможны: JavaScript аутентификация, Http-редирект аутентификация и капча (тест Тьюринга). Суть данных методов заключается в том, что при подключении к сайту по HTTP протоколу, система фильтрации убеждается, что подключение осуществляется с полноценного браузера или “полноценного” пользователя. Если выбран JavaScript аутентификация, на приходящий запрос страницы, система возвращает HTML код страницы содержащим JavaScript код, который автоматически запускается браузером и заставляет браузер произвести определенный запрос (каждому пользователю свой). Если система фильтрации увидит данный запрос, тогда IP адрес клиента авторизируется и ему будет предоставлен последующий доступ к защищаемому сайту. Аутентификация на основе http редиректа работает аналогичным образом (используя временный редирект). Данные методы абсолютно невидимы для пользователя, то есть ему не придется нажимать в браузере F5, или делать обновление страницы, визуально внешний вид сайта никак не портится, а время на авторизацию занимает доли секунды. В случае капчи, система пропустит клиента, если он введет соответствующий номер\код, с картинки – данный метод может потенциально использоваться для умных BotNet сетей, которые полноценно эмулируют работу браузера (встраиваются в сам браузер или используют его движок).

Также аутентификация в HTTP протоколе, позволяет делать анализ IP адресов, ранее прошедших http авторизацию. Это проверка на соответствие RFC для http протокола, ограничение слишком частого запроса одной и той же URL (к примеру, зажатие на F5 в браузере, что, кстати, может положить половину сайтов в интернете), а также детектирование слишком медленных HTTP запросов. Про последние надо написать более подробно. Чтобы поддерживать большое количество активных TCP потоков на веб сервере, злоумышленник устанавливает множество TCP соединений и медленно (путем искусственной TCP фрагментации по 1-50 байт) отправляет часть запроса на атакуемый сервер. Простаивающие TCP потоки нельзя закрыть по таймауту, так как фрагментация в TCP протоколе является нормальной и распространенной ситуацией. Но данные медленные запросы сильно отличаются от нормального поведения пользователя, поэтому, их можно детектировать даже если IP адрес ранее прошел http авторизацию.

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

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

На всякий случай, были введены ограничения на лимит доступа к серверу для каждого клиента, прошедшего все вышеперечисленные методы фильтрации. Мы ограничили объем передаваемых данных, количество запросов, TCP\UDP потоков, и т.д и т.п., хоть это и было излишним, так как клиенты не выходили за заданные рамки.

Данный сценарий фильтрации DDOS атак является наиболее распространенным. Система СОПСА содержит еще множество других фильтров на уровне стека операционной системы и аутентификаций в других протоколах (DNS,SIP,итд), но в данном случае было достаточно вышеперечисленного перечня.

Данная DDOS атака длилась несколько суток, при этом количество BotNet-ов, атакующих в пиках, достигало до 70 тыс. В результате фильтрации, система предоставляет отчет, содержащий: выделенную вся атакуемую BotNet сеть (IP адреса, методы детектирования, объем трафика, время активности и т.д.), количество трафика, приходящего на DDOS атаку, AS операторов, IP адреса которых участвовали в атаке, логирование всех действий администратора системы и эффективность по каждому методу фильтрации. Данной информации достаточно для будущих расследований инцидента, предоставления претензий провайдерам, с AS которых производилась атака и т.д.

 

Что необходимо сделать злоумышленнику, чтобы обойти защиту? По сути:

  • Атака на забивку канала не эффективна и очень заметна (фильтруется статистическими правилами BGP Flow Spec на уровне каналов провайдера, а также несколькими системами фильтрации).
  • Подмена исходящего IP адреса и SynFlood детектируются и фильтруется на ура, злоумышленнику необходима реальная BotNet сеть с реальными IP адресами.
  • Все вышеперечисленные методы сводились к тому, что возможно РАЗДЕЛИТЬ клиентов от ботов, за счет неполноценной поддержки протоколов, по которым осуществляется атака или выявление чрезмерной активности.

При правильной настройке и использовании, единственный вариант обойти систему фильтрации СОПСА и произвести успешную DDOS атаку, это иметь размер BotNet сети достаточного размера (300 тыс и более) и полноценно поддерживать HTTP\HTTPS\DNS протоколы, при этом эмулировать нормальную активность обычных пользователей (то есть ничем не выделяться), что практически равносильно нагрузочному тестированию на сервер (что решается, путем разнесению сайта на несколько серверов). И даже в этом случае, успех DDOS атаки не гарантирован. К примеру, в HTTP протоколе, для авторизации есть метод капча, то есть, атакующему нужна еще и армия “индусов”, для ввода символов с картинки (хоть при этом при первом заходе испортится внешний вид сайта). И это повышает вероятность, но не гарантирует успешность атаки, к примеру, банальное ограничение доступа к сайту (после всех авторизаций, IP адрес клиента получает доступ на 15-30 минут) позволит заблокировать IP адреса, постоянно подключаемых к сайту, то есть, атакующему BotNet сети. Это значит, что размер BotNet сети должен быть еще существенно больше и атаковать они должны еще более “человечно”. У злоумышленника размер BotNet сети ограничен физически, поэтому боты, как правило, ведут себя агрессивно, чтобы создать большую нагрузку, тем самым, выделяются среди обычных пользователей.

 

К чему приводит отсутствие системы фильтрации от DDOS атак?

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

  • Всего дата-центра, где располагается жертва.
  • Операторов связи, так как возникает дополнительная нагрузка на каналы
  • Спецслужб в расследованиях, и оборудования производящим мониторинг трафика

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

Большинство средних\мелких операторов связи арендуют каналы по определенной таксе, превышение которой приводит к крупным материальным издержкам. Чтобы избежать лишних юридических разбирательств и счетов за объемы трафика, операторы связи также заинтересованы в фильтрации DDOS атак, идущие как из их сети, так и в их сеть.

Для спецслужб защита от DDOS атак также важна для систем анализа сетевого трафика (в том числе СОРМ). В соответствии с Постановлением Правительства РФ от 27 августа 2005 г. №538, а также от 6 июля 2016 г. №374-ФЗ, операторы связи обязаны в течение 3х лет хранить информацию о взаимодействиях пользователей и 6 месяцев хранить содержимое передаваемых данных. При наличии DDOS атаки, количество пользовательских потоков (взаимодействий) могут возрасти в десятки тысяч раз, что не положительно скажется на работе системе любой системы СОРМ, времени хранения данных и соответственно стоимости его внедрения. Использование СОПСЫ позволяет минимизировать риски и удешевить внедрение СОРМ.

© 2010-2018 NT-COM LLC

Click Me