Cisco защита от ddos

Есть несколько десятков серверов в двух стойках к которым в сумме подведено около 10 Gbps с возможностью расширения до 40-50 Gbps. Периодически «приходят» атаки в несколько гигабит или более и забиваю канал. Для борьбы с атаками используется внешний сервис, который помогает, но приходится менять IP-адреса. Т.е. при появлении атаки у всех сайтов меняются IP-адреса на специальные защищенные, которые предоставляет компания, у которой покупается данная услуга. А на атакуемые IP-адреса в сетевом оборудование режется трафик на 100%. Но это схема имеет существенный для нас недостаток — нужно время на изменения IP в DNS и время на обновление DNS.

Хотим сделать схему с защитой с помощью сетевого оборудования Cisco (или какого-либо другого) внутри ДЦ, чтобы не пользоваться данным внешним сервисом и не менять IP.

Подскажите, пожалуйста, возможно ли это и, если да, то в какую сторону копать? Где можно найти консультанта по данному вопросу?

Вопрос задан более трёх лет назад
5284 просмотра

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

Есть несколько десятков серверов в двух стойках к которым в сумме подведено около 10 Gbps

Что значит около 10 Гбит/с? Используются 10-гигабитные линки или агрегация из нескольких гигабитных? По некоторым соображениям первый вариант предпочтительнее.

Периодически «приходят» атаки в несколько гигабит или более и забиваю канал.

Интенсивность трафика вам известна откуда? Необходимо понимать, что если мусорный трафик представляет собой UDP или сегменты TCP без установления сессии, то вполне возможна такая ситуация, когда к вашему провайдеру приходит 10-20 гигабит/c адресованного вам трафика, а до вас доходит лишь его часть. Если есть возможность, запросите статистику (данные netflow) хостинг-провайдера.

Хотим сделать схему с защитой с помощью сетевого оборудования Cisco (или какого-либо другого) внутри ДЦ, чтобы не пользоваться данным внешним сервисом и не менять IP.

Касательно оборудования Cisco. Было у Cisco Systems решение Clean Pipes, предназначенное для противодействия DDoS-атакам. Состояло из двух компонент — детектора аномалий (Cisco Traffic Anomaly Detector, использовалось опционально) и собственно фильтрующего устройства (Cisco Anomaly Guard). Оба устройства имеют статус End-of-life. Далее совместно с Arbor Networks была разработана архитектура Clean Pipes 2.0, где, насколько мне известно, основную работу выполняло устройство Arbor Peakflow TMS (threat management solution). О существовании современного устройства под брендом Cisco Systems, разработанного для противодействия DDoS-атакам, мне неизвестно.

Подскажите, пожалуйста, возможно ли это и, если да, то в какую сторону копать?

Во-первых, определитесь, зачем вам это. Если мусорный трафик на клиента приводит к недоступности вашей сети (т.е. к полной утилизации линка), то это одно. В таком случае вам поможет BGP blackhole (RTBH, remotely triggered blackhole filtering), отбрасывая весь трафик до клиента. Эффективно клиентский хост будет недоступен (т.е. DoS-атака удалась, отказ в обслуживании достигнут), но мусорный трафик будет отброшен на оборудовании провайдера, не влияя на работоспособность вашей сети. На мой взгляд, иметь настроенный RTBH необходимо. Для этого можно использовать, например, программный BGP клиент, вроде exabgp или quagga.

Если вы планируете фильтровать клиентский трафик (т.е. отбрасывать мусорный и пропускать "полезный", что бы это ни значило), то RTBH не подойдет. Возможные варианты (с которыми я работал либо работу которых наблюдал) аппаратных решений — грамотно настроенный сервер под Linux/*BSD с картами Intel (дешево, гибко, множество нюансов), Juniper SRX подходящей мощности (дорого, от некоторых атак вполне защищает, но, на мой взгляд, специализированное решение предпочтительнее), Arbor Peakflow TMS (дорого, красивый интерфейс, в целом понравилась работа с ним), Периметр от МФИ-Софт (работает, но не без нюансов).

Кроме самого устройства или внешнего сервиса, как я уже упоминал, следует, на мой взгляд, удостовериться, что:
1) сеть находится под всесторонним мониторингом
2) имеется либо отдельная (management) сеть для управления, либо настройки QoS на линках, резервирующие полосу для трафика систем управления.
3) настроена защита CPU сетевых устройств (Control plane protection policy в cisco-мире)
4) отсутствуют другие узкие места (например, ECMP в том или ином виде, агрегация двух линков в 1 гигабит/c не во всех случаях дает пропускную способность в 2 гигабита/с)

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

Аналитика, обзоры, исследования из мира Информационной Безопасности | (с) Иван Пискунов

МОИ ПРОЕКТЫ

воскресенье, 17 июля 2016 г.

Защита от DDoS: от маршрутизатора до провайдера

на уровне провайдера
на уровне сетевого оборудования распределения и доступа
на уровне конфигурирования системного и прикладного ПО

Насыщение полосы пропускания Это самый распространенный тип атаки, цель которого — вывести информационную систему из строя из-за исчерпания системных ресурсов (процесса, памяти, канала связи). Данный тип атак разделяется на несколько подтипов, но все они так или иначе связаны с так называемым флудом — большим количеством запросов. Во-первых, это ping-флуд (множество ping-запросов), HTTP-флуд (множество небольших по размеру HTTP-запросов, вызывающих во много раз более объемные ответы). Во-вторых, это ICMP-флуд и UDP-флуд, которые усиливаются с помощью замены IP-адреса злоумышленника на IP-адрес жертвы. В-третьих, это SYN-флуд, когда атака основана на том, что атакуемой системе посылается много запросов на подключение от фактически несуществующих узлов, а атакуемая система продолжает пытаться эту связь наладить, пока не отключается по тайм-ауту

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

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

Атаки на DNS-серверыТакие атаки можно разделить на два типа: атаки на уязвимость в программном обеспечении DNS-серверов и DDoS-атаки на DNS-серверы. Распределенные атаки на DNS-серверы подразумевают большое количество компьютеров для насыщения полосы пропускания либо захвата системных ресурсов. Ранее для подобных атак применялись многочисленные бот-сети. Но сейчас они неэффективны ввиду того, что провайдеры научились отсеивать подобный «мусорный» трафик. Также злоумышленники используют тот факт, что многие (десятки тысяч) DNS-серверов, работающих в интернете, настроены неправильно, что позволяет использовать их при организации DDoS-атак.

Существует также другая классификация DDoS-атак, по объекту атаки, выделяют следующие виды:

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

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

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

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

Smurf — злоумышленником отправляются широковещательные echo-пакеты (протокол ICMP), в заголовках которых в качестве источника указывается адрес жертвы. В результате, все системы, получившие ping-запрос, «заваливают» жертву echo-ответами.
ICMP-flood — похожа на Smurf, но отправляет ICMP-запросы напрямую на узел-жертву без использования широковещательного адреса.
UDP-flood— отправка на узел-мишень огромного количества UDP-пакетов, что приводит к «связыванию» сетевых ресурсов.
TCP-flood— аналогична предыдущей, но используются TCP-пакеты.
TCP SYN-flood — злоумышленник отправляет на открытый порт много SYN-пакетов с недостижимым адресом источника. Атакуемый маршрутизатор должен ответить пакетом , но узел, указанный в качестве источника, недоступен, и поэтому трехступенчатая схема установления TCP-соединения не завершается. А поскольку таких SYN-пакетов очень много, лимит на количество открытых соединений быстро превышается и жертва отказывается принимать запросы на установление соединения от обычных пользователей сети.

Обнаружение DoS-атаки

Огромное количество ARP-запросов;
Огромное количество записей в NAT/PAT-таблице;
Повышенное использование памяти маршрутизатора;
Повышенное использование процессорного времени маршрутизатора.

применяются уже непосредственно на маршрутизирующем оборудовании перед тем, как трафик достигает процессора маршрутизации, обеспечивая "персональную" защиту оборудования;

применяются уже после того, как трафик прошел обычные списки контроля доступа – являются последним уровнем защиты на пути к процессору маршрутизации;

применяются ко всему трафику (и внутреннему, и внешнему, и транзитному по отношению к сети оператора связи).

3. Infrastructure ACL

обычно устанавливаются на границе сети оператора связи ("на входе в сеть");

имеют целью предотвратить доступ внешних хостов к адресам инфраструктуры оператора;

обеспечивают беспрепятственный транзит трафика через границу операторской сети;

обеспечивают базовые механизмы защиты от несанкционированной сетевой активности, описанные в RFC 1918, RFC 3330, в частности, защиту от спуфинга (spoofing, использование поддельных IP адресов источника с целью маскировки при запуске атаки).

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

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

class-map type?
access-control access-control specific class-map
control Configure a control policy class-map
inspect Configure CBAC Class Map
logging Class map for control-plane packet logging
port-filter Class map for port filter
queue-threshold Class map for queue threshold
stack class-map for protocol header stack specification
Создать специальную политику (Policy-map type )
policy-map type?
access-control access-control specific policy-map
control Configure a control policy policy-map
inspect Configure CBAC Policy Map
logging Control-plane packet logging
port-filter Control-plane tcp/udp port filtering
queue-threshold Control-plane protocol queue limiting
И применить её в этом режиме:
control-plane host
service-policy type?
logging Control-plane packet logging
port-filter Control-plane tcp/udp port filtering
queue-threshold Control-plane protocol queue limiting
Ограничение же нагрузки на мозг служебными пакетами организуется похоже, только для этого достаточно описать обычный класс трафика, обычную политику, где в качестве действия указать ограничение словом police
police rate [units] pps

Сервера, размещенные в сети администрируемой мной AS, часто подвергаются различным DDOS атакам. Целью атакующих могут быть, как отдельные ресурсы размещенные на серверах, сами сервера и вся площадка в целом. С каждым месяцем количество, сложность и мощность атак возрастает. Атаки в 300-400Мб/с выросли до 70-80Гб/с. В этой ситуации не все атаки могут быть отражены тюнингом серверов, а крупные атаки могут помешать работе и всей площадки в целом. Бороться с такими атаками необходимо силами всей команды хостинга. Сетевые администраторы также должны иметь средства борьбы с такими атаками на сетевом уровне. О таких средствах и пойдет речь под катом.

В статье будет рассматриваться основной метод защиты от DDOS атак средствами динамической маршрутизации: — метод Blackhole («черной дыры»).
Этот метод позволяет полностью прекратить поток трафика на атакуемый сервер и снять нагрузку с каналов AS и провайдера. В условиях предоставления услуг виртуального хостинга высокой доступности этот метод является крайней мерой, но остается эффективным средством для борьбы с крупными DDOS атаками, когда другими средствами справиться не удается.

Поясним несколько терминов, которые будут встречаться в статье:
BGP (Border Gateway Protocol) — основной протокол динамической маршрутизации в глобальной сети интернет. Позволяет маршрутизаторам обмениваться таблицами маршрутизации. Предоставляет гибкие средства для управления трафиком.
BGP community — атрибут протокола динамической маршрутизации BGP, позволяющий устанавливать определенные метки на передаваемые маршруты. Атрибут позволяет создавать и устанавливать пользовательские значения (установлен только рекомендуемый формат community) и на их основании гибко настраивать фильтры маршрутизатора.
peering — установленная сессия BGP для обмена маршрутами.
Анонсирование сети — в терминологии протоколов динамической маршрутизации, отправка маршрутов из локальной таблицы маршрутизации соседнему маршрутизатору.
AS (Autonomous System) — набор IP-сетей, управляемых одним оператором по установленным правилам глобальной сети Интернет.
eBGP (External Border Gateway Protocol) — тип обмена маршрутами по протоколу BGP между маршрутизаторами разных AS.
iBGP (Internal Border Gateway Protocol) — тип обмена маршрутами по протоколу BGP между маршрутизаторами внутри AS.
policy-statement — в рамках конфигурации маршрутизаторов Juniper представляет собой набор правил, определяющих условия фильтрации маршрутов, получаемых или передаваемых по протоколам динамической маршрутизации.
DDOS (Distributed Denial of Service) — распределённая атака типа «отказ в обслуживании». Атака, для которой используется сеть компьютеров по всему миру зараженных вредоносным программным обеспечением (ботнет), осуществляющих генерацию трафика или атаку на жертву.
UDP Amplification — разновидность DDOS атаки, для реализации которой используются сторонние сервера с открытыми UDP портами и службами SNMP, NTP, DNS. Как правило этот вид атаки направлен на пропускную способность канала жертвы.
ISP (Internet Service Provider) — организация, предоставляющая услуги доступа к сети Интернет, попросту — провайдер.

BGP blackhole

Blackhole позволяет управлять трафиком на уровне провайдера, до попадания в нашу AS. Он эффективен для борьбы с крупными атаками на пропускную способность канала (чаще всего DNS Amplification). В классической схеме метод предполагает выставление next-hop для анонсируемого маршрута на ip адрес из приватной сети. Так как у магистральных провайдеров маршруты до приватных сетей, по большей части, должны быть направлены в Null0 (Cisco терминология, в Juniper — discard) пакеты с адресом назначения из этой сети буду автоматически отбрасываться — попадать в «черную дыру» еще в сети провайдера. К сожалению, в реальных сетях магистральных провайдеров не всегда установлены маршруты приватных сетей в Null0, так как сами провайдеры используют эти адреса для маршрутизации или попросту не следуют рекомендациям RFC. Для установки blackhole, чаще всего, используются расширенные возможности управления маршрутами BGP — BGP community. Метод реализуется путем создания специальной группы (community) для маршрутов, трафик которых необходимо направить в «черную дыру». В момент начала атаки у сетевого администратора атакуемой AS будет возможность передать маршрут с длинной маски /32 подкрепив его этим community, тем самым сообщив маршрутизаторам ISP о том, что пакеты до этого ip адреса должны отбрасываться. Фильтрация пакетов на стороне ISP может осуществляться как с помощью ACL так и с помощью Null интерфейса, но наиболее правильных подход предполагает рекурсивный blackhole. Схематически метод рекурсивного blackhole показан ниже:

Атакующие из AS3 и AS4 производят атаку на веб-сервер с ip адресом 1.1.1.1 который находится в AS2. Сетевой администратор AS2 устанавливает в blackhole адрес сервера передавая маршрут к его ip адресу с community 666. Маршрутизатор ISP получая маршрут /32 с установленным blackhole community начинает отбрасывать все пакеты направленные на адрес ip 1.1.1.1. Кроме того, чтобы снять нагрузку с собственных каналов, ISP (AS1) передает этот маршрут далее своим провайдерам устанавливая на него blackhole community предоставленные ими (на схеме это community 3:666 и 4:666). Такой метод защиты гораздо эффективнее простой фильтрации пакетов на маршрутизаторе AS2, так как снимает нагрузку с каналов между AS1 и AS2, а также eBGP каналов провайдера AS1. Отбрасывание пакетов направленных на ip адрес 1.1.1.1 происходит на маршрутизаторах провайдеров к которым непосредственно подключены атакующие. Если атакующий подключен к другой AS (не принадлежит AS провайдера), то каждый из провайдеров AS3 и AS4 может анонсировать маршрут с blackhole community дальше своим провайдерам, а те в свою очередь своим и т.д. Таким образом все сети магистральных провайдеров будут разгружены от DDOS трафика.

практика BGP blackhole

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

Настройка провайдерской стороны

Сначала необходимо создать определенный community для обозначения префиксов установленных в blackhole:

где 1 — это номер AS провайдера (позволяет community оставаться уникальным даже при передаче по сетям других ISP), 666 — уникальный номер community (может быть любым, но рекомендуется использовать 666). Далее создаем Policy для импорта префиксов от нашего пира, выбираем из них префиксы с community blackhole и заворачиваем их в Null (в Juniper это discard):

Назначаем этот policy-statement на eBGP сессию для импортируемых (получаемых) префиксов от клиентов.

Настройка клиентской стороны

Аналогичным образом, сначала, создается community для обозначения префиксов установленных в blackhole:

Значения те же самые как и на стороне провайдера, с той лишь разницей, что номер AS должен соответствовать AS провайдера, то есть, кто выдает community тот и устанавливает его обозначение. Далее создаем policy-statement для добавления community к префиксам которые надо передавать маршрутизатору ISP.

Префиксы выбираются из static маршрутов. Так как маршрутизатор изначально знает только о сетях больше /32, специфичный префикс нужно создавать отдельно. Как видно из правила from, этот policy-statement будет выбирать все статические маршруты с тегом 666 (номер тега может быть любым). Назначаем этот policy-statement в качестве фильтра export на eBGP сессию к нашему провайдеру. Теперь, если есть необходимость поставить адрес сервера в blackhole создаем статический маршрут /32 на нашем маршрутизаторе.
Например, для установки в blackhole адреса указанного на схеме надо выполнить команду:

где 1.1.1.1 — это ip адрес устанавливаемый в blackhole.