Хабрахабр

Как взять сетевую инфраструктуру под свой контроль. Часть третья. Сетевая безопасность. Продолжение

Это вторая часть главы «Сетевая безопасность» (которая в свою очередь является третьей частью цикла статей «Как взять сетевую инфраструктуру под свой контроль»). В первой части этой главы мы рассмотрели некоторые аспекты сетевой безопасности сегмента «Data Center». Эта глава будет посвящена «Internet Access» сегменту.

image

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

При аудите этого сегмента обратите внимание на следующие аспекты:

  • дизайн
  • настройки BGP
  • DOS/DDOS защита
  • фильтрация трафика на фаерволе

Дизайн

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

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

Но в данном цикле статей мы будем рассматривать его отдельно. Замечание
В SAFE сегмент «Remote Access» является частью «Internet Access».

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

  • граничные маршрутизаторы (border routers)
  • фаерволы

Замечание 1

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

Замечание 2

Отчасти вопросы L1/L2 были рассмотрены в главе "Чистка и документирование". Я опускаю рассмотрение различного рода L2/L1 или оверлейных L2 over L3 решений необходимых для обеспечения L1/L2 связности и ограничиваюсь только вопросами уровня L3 и выше.

Если вы не обнаружили фаервола в этом сегменте, то не стоит спешить с выводами.

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

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

Задержка Пример 1.

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

Производительность Пример 2.

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

Надежность Пример 3.

Этот фактор по-прежнему нужно принимать во внимание, но все же, с учетом ненадежности самого интернета, его значение для этого сегмента не так значимо, как для дата-центра.

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

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

Поэтому, скорее именно только цена может быть тем фактором, который заставит вас отказаться от применения фаерволов в этом сегменте.

Важно!

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

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

Пример

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

Поэтому, возможно, все, что вам нужно – это сервер или несколько серверов, коммутатор и BGP. Для BGP вам совсем не обязательно иметь выделенные маршрутизаторы, вы можете использовать open-source инструменты, например, Quagga.

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

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

А как же защита в данном случае?

Ее опасность заключается в том, что генерируется большое количество трафика, который просто «забивает» на 100% все ваши аплинки. Давайте рассмотрим, например, популярную в последнее время DNS Amplification DDOS атаку.

Что мы имеем в случае нашего дизайна.

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

И еще небольшое замечание к этому примеру. Если достаточное количество трафика вы отдаете через IX-ы, то это также снижает вашу подверженность подобным атакам

Настройка BGP

Здесь две темы.

  • Связность
  • Настройка BGP

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

Пример 1

Если вы — биржа, и для ваших клиентов важны интервалы времени меньше чем миллисекунды, то, понятно, ни о каком интернете вообще речи идти не может.

Пример 2

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

Пример 3

CDN сети строятся в том числе и для решения этой проблемы, вынося сервера раздачи контента ближе к потребителю этого контента. Так же нужно понимать, что, в силу свойств протокола TCP, скорость передачи данных в рамках одной TCP сессии также зависит от RTT (Round Trip Time).

Исследование связности – это отдельная интересная тема, достойная отдельной статьи или серии статей и требует хорошего понимания, как «устроен» интернет.

Полезные ресурсы:

ripe.net
bgp.he.net

Пример

Приведу лишь один небольшой пример.

В этом случае (single homed) BGP вам не нужен, и в качестве публичных адресов вы, скорее всего, используете адресный пул от Ростелекома. Предположим, что ваш дата-центр находится в Москве, и у вас есть единственный аплинк – Ростелеком (AS12389).

При исследовании вы выяснили, что IP адреса некоторых из них находятся в сетке 37. Предположим, что вы предоставляете некий сервис, и у вас достаточное количество клиентов из Украины, и они жалуются на большие задержки. 0. 52. 0/21.

Вы можете увидеть это также на looking glass Ростелекома. Выполнив traceroute, вы увидели, что трафик идет через AS1299 (Telia), а выполнив ping, вы получили средний RTT 70 — 80 миллисекунд.

52. Утилитой whois (на сайте ripe.net или локальной утилитой) вы легко можете определить, что блок 37. 0/21 принадлежит AS6849 (Ukrtelecom). 0.

Но если вы посмотрите на список пиров для AS6849, то вы увидите, например, AS29226 (Mastertel) и AS31133 (Megafon). Далее, зайдя на bgp.he.net вы видите, что у AS6849 нет отношений с AS12389 (они не являются ни клиентами, ни аплинками друг другу, так же у них нет и пиринга).

Например, для Mastertel RTT будет уже порядка 30 миллисекунд. Найдя looking glass этих провайдеров, вы можете сравнить путь и RTT.

Так что, если разница между 80 и 30 миллисекундами существенна для вашего сервиса, то, возможно, вам нужно задуматься о связности, получить в RIPE свой номер AS, свой пул адресов и подключить дополнительные аплинки и/или создать точки присутствия на IX-ах.

При использовании BGP вы не только имеете возможность улучшить связность, но также резервируете свое подключение к интернету.

Несмотря на то, что эти рекомендации были выработаны на основе «best practice» провайдеров, все же (если ваши BGP настройки не совсем уж элементарные) они являются несомненно полезными и фактически должны быть частью hardening-а, который мы обсуждали в первой части. Данный документ содержит рекомендации по настройке BGP.

DOS/DDOS защита

Сейчас DOS/DDOS атаки стали повседневной реальностью для многих компаний. В действительности, в том или ином виде, вас атакуют довольно часто. То, что вы пока не замечаете этого, говорит лишь о том, что пока не была организована целенаправленная атака против вас, и что те средства защиты, которыми вы пользуетесь, даже, возможно, не подозревая об этом (различные встроенные защиты операционных систем), достаточны, чтобы деградация предоставляемого сервиса была минимизирована для вас и ваших клиентов.

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

Здесь можно найти ссылки на них.

Моя любимая карта от CheckPoint.

Чтобы понять почему, надо понимать какие типы DOS/DDOS атак существуют (см. Защита от DDOS/DOS обычно является эшелонированной. например, здесь или здесь)

То есть мы имеем три типа атак:

  • volumetric attacks
  • protocol attacks
  • application attacks

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

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

Пример

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

Но На время атаки вам придется в этом случае отчасти пожертвовать связностью.

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

Защиту от «protocol attacks» и «application attacks» вы также можете отдать на откуп партнерам.
Вот здесь вы можете почитать хорошее исследование (перевод). Правда, статья двухгодичной давности, но это даст вам представление о подходах, как вы можете защититься от DDOS атак.

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

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

Итак, вторая линия защиты это фильтрация и ограничители трафика (policers) на входе в вашу сеть.

Пример 1

Предположим, что этот провайдер использует Arbor для фильтрации трафика и фильтры на границе своей сети. Предположим, что вы “закрылись зонтиком” от DDOS с помощью одного из провайдеров.

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

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

Пример 2

Давайте предположим, что вы предоставляете сервис, при котором у вас одновременно может быть порядка 100 тысяч TCP коннекций (в один дата-центр). Аномально большое количество SYN пакетов может быть не только результатом SYN flood атаки.

Если ваше приложение устроено таким образом, что оно, «недолго думая», сразу (или через какой-то одинаковый для всех сессий интервал времени) пытается переустановить соединение, то вы приблизительно одновременно получите как минимум 50 тысяч SYN пакетов. Предположим, что в результате кратковременной проблемы с одним из ваших основных провайдеров у вас “кикнулось” половина сессий.

Казалось бы, балансировщики должны отрабатывать такие событие, но … к сожалению, мы столкнулись в полный рост с такой проблемой. Если же поверх этих сессий у вас, например, должен работать ssl/tls handshake, что предполагает обмен сертификатами, то с точки зрения исчерпания ресурсов для вашего балансировщика нагрузки это будет гораздо более сильный «DDOS» чем простой SYN flood.

И, конечно, policer на граничном маршрутизаторе спасет ваше оборудование и в этом случае.

Третий уровень защиты от DDOS/DOS – это настройки вашего фаервола.

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

Совет

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

Если нет, то, может быть, просто потому, что вы не пробовали? С вами не происходило такого, что случайно, генерируя трафик, чтобы проверить, например, насколько операционная система ваших серверов устойчива к DDOS атакам, вы “убивали” свой фаервол, загружая его на 100 процентов, при этом трафиком с обычной интенсивностью?

Поэтому, на этапе 2 с помощью обычных ACL (на уровне L3/L4) пускайте в вашу сеть только тот трафик, который должен туда входить. В общем, фаервол, как я уже говорил — сложная штука, и он хорошо работает с известными уязвимостями и оттестированными решениями, но если вы пошлете что-то необычное, просто какой-то мусор или пакеты с неправильными заголовками, то вы с некоторой, не такой уж маленькой (исходя из моего опыта) вероятностью можете ввести в ступор и топовое оборудование.

Фильтрация трафика на фаерволе

Продолжаем разговор о фаерволе. Нужно понимать, что DOS/DDOS атаки – это лишь одна из разновидностей кибер-атак.

Кроме DOS/DDOS protection мы можем еще иметь что-то наподобие следующего списка возможностей:

  • application firewalling
  • threat prevention (antivirus, anti-spyware, and vulnerability)
  • URL filtering
  • data filtering (content filtering)
  • file blocking (file types blocking)

Вам решать, что из этого списка вам нужно.

Продолжение следует

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть