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

Internet access

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

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

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

Дизайн

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

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

Замечание

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

Стандартным набором оборудования в этом сегменте для сети предприятия (enterprise network) являются

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

Замечание 1

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

Замечание 2

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно!

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

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

Пример

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

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

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

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

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

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

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

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

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

Настройка BGP

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

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

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

Пример 1

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

Пример 2

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

Пример 3

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

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

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

ripe.net
bgp.he.net

Пример

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

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

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

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

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

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

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

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

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

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

DOS/DDOS защита

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

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

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

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

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

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

• volumetric attacks
• protocol attacks
• application attacks

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

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

Пример

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

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

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

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

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

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

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

Пример 1

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

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

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

Пример 2

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

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

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

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