Как Взять Под Контроль Вашу Сетевую Инфраструктуру. В Третьей Главе. Сетевая Безопасность. Часть Вторая

Эта статья является четвертой в серии статей «Как взять под контроль вашу сетевую инфраструктуру».

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

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

Эта часть будет посвящена сегменту «Доступ в Интернет».



Как взять под контроль вашу сетевую инфраструктуру.
</p><p>
 В третьей главе.
</p><p>
 Сетевая безопасность.
</p><p>
 Часть вторая

доступ в Интернет Тема безопасности, несомненно, является одной из самых сложных тем в мире сетей передачи данных.

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

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

дизайн Настройки BGP Защита от DOS/DDOS фильтрация трафика на брандмауэре

Дизайн

В качестве примера проектирования этого сегмента для корпоративной сети я бы рекомендовал управление от Cisco внутри БЕЗОПАСНЫЕ модели .

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

Квадрант Гартнера, 2018 г.

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

Комментарий В SAFE сегмент «Удаленный доступ» является частью сегмента «Доступ в Интернет».

Но в этой серии статей мы рассмотрим это отдельно.

Стандартный набор оборудования в этом сегменте для корпоративной сети составляет пограничные маршрутизаторы межсетевые экраны
Примечание 1 В этой серии статей, когда я говорю о межсетевых экранах, я имею в виду НГФВ .

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

Частично вопросы L1/L2 обсуждались в главе « Очистка и документация ".

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

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

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

Но здесь они уже не столь значительны.

Пример 1. Задерживать Что касается Интернета, то о задержках даже около 1 миллисекунды говорить не приходится.

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

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

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

Пример 3. Надежность Этот фактор еще нужно учитывать, но все же, учитывая ненадежность самого Интернета, его значение для этого сегмента не столь существенно, как для дата-центра.

Итак, предположим, что ваш сервис работает поверх http/https (с короткими сеансами).

В этом случае вы можете использовать два независимых бокса (без HA) и при возникновении проблем с маршрутизацией на одном из них переносить весь трафик на второй.

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

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

Важный! Есть соблазн объединить этот межсетевой экран с межсетевым экраном ЦОД (использовать для этих сегментов один межсетевой экран).

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

То есть, используя одни и те же устройства в этих двух сегментах, вы существенно снизите доступность вашего сегмента ЦОД.

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

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

Пример Если вы являетесь поставщиком контента и имеете сеть CDN (см.

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

Это будет дорого, да и может быть просто ненужно.

Для BGP вам не обязательно иметь выделенные маршрутизаторы, вы можете использовать инструменты с открытым исходным кодом, такие как Квагга .

Так что, возможно, все, что вам нужно, это сервер или несколько серверов, коммутатор и BGP. В этом случае ваш сервер или несколько серверов могут выполнять роль не только CDN-сервера, но и маршрутизатора.

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

У вас может быть несколько дата-центров с полной защитой (брандмауэры, услуги DDOS-защиты, предоставляемые вашими интернет-провайдерами) и десятки или сотни «упрощенных» точек присутствия только с коммутаторами и серверами L2. А как же в этом случае с защитой? Давайте посмотрим, например, на популярный в последнее время DDOS-атака с усилением DNS .

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

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

если вы используете AnyCast, то трафик распределяется между вашими точками присутствия.

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

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

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



Настройка BGP

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

Возможности подключения Настройка BGP Мы уже немного говорили о подключении в часть 1 .

Цель состоит в том, чтобы обеспечить, чтобы трафик к вашим клиентам следовал по оптимальному пути.

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

Для одних компаний это более важно, для других – менее.

Все зависит от предоставляемой вами услуги.

Пример 1 Если вы биржа, и вашим клиентам важны временные интервалы менее миллисекунд, то ни о каком Интернете, конечно, не может быть и речи.

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

Пример 3 Также необходимо понимать, что из-за свойств протокола TCP скорость передачи данных внутри одной TCP-сессии также зависит от RTT (Round Trip Time).

Сети CDN также строятся для решения этой проблемы путем перемещения серверов распространения контента ближе к потребителю этого контента.

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

нет bgp.he.net

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

Предположим, что ваш дата-центр находится в Москве, и аплинк у вас один — Ростелеком (AS12389).

В этом случае (single homeed) BGP вам не нужен, и в качестве публичных адресов вы, скорее всего, используете пул адресов от Ростелекома.

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

В ходе исследования вы выяснили, что IP-адреса некоторых из них находятся в сетке 37.52.0.0/21. Запустив трассировку, вы увидели, что трафик идет через AS1299 (Telia), а запустив пинг, вы получили среднее RTT 70 – 80 миллисекунд. Вы также можете увидеть это на зеркало Ростелеком .

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

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

Но если вы посмотрите список коллег для AS6849 вы увидите, например, AS29226 (Мастертел) и AS31133 (Мегафон).

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

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

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



Защита от DOS/DDOS

Теперь DOS/DDOS-атаки стали повседневной реальностью для многих компаний.

На самом деле, на вас довольно часто нападают в той или иной форме.

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

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

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

Моя любимая карта из Чекпоинта.

Защита от DDOS/DOS обычно является многоуровневой.

Чтобы понять почему, нужно разобраться, какие типы DOS/DDOS-атак существуют (см.

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

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

Если вы еще этого не осознали, то вам пока просто повезло.

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

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

Но это только на время атаки.

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

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

Не обязательно передавать весь трафик.

Если, например, вы видите, что через некоторые аплинки или пиринговые соединения нет атак (или трафик незначителен), вы можете продолжать рекламировать префиксы с конкурентными атрибутами по отношению к этим соседям BGP.

Вы также можете делегировать защиту от «атак на протоколы» и «атак на приложения» своим партнерам.

Здесь Здесь можно почитать хорошее исследование( перевод ).

Правда, статье два года, но она даст вам представление о подходах, как можно защититься от DDOS-атак.

В принципе, этим можно ограничиться, полностью передав свою защиту на аутсорсинг.

У этого решения есть свои преимущества, но есть и очевидный недостаток.

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

И доверять такие вещи третьим лицам.

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

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

Пример 1 Предположим, вы прикрылись зонтиком от DDOS с помощью одного из провайдеров.

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

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

Поэтому в обычных условиях трафик не фильтруется.

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

Минуту или больше вы остаетесь под атакой.

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

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

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

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

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

одновременно.

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

к сожалению, мы столкнулись с такой проблемой.

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

Третий уровень защиты от DDOS/DOS — это настройки брандмауэра.

Здесь вы сможете остановить обе атаки второго и третьего типа.

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

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

И вот почему.

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

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



Фильтрация трафика на брандмауэре

Продолжим разговор о фаерволе.

Вы должны понимать, что DOS/DDOS-атаки — это лишь один из видов кибератак.

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

Продолжение следует Теги: #информационная безопасность #Сетевые технологии #ИТ-инфраструктура #DevOps #процессы в ней #сетевая инфраструктура #сетевая архитектура #сетевая безопасность #управление сетевым отделом

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.