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

Т.к. эта глава получается довольно объемной, то я решил публиковать ее по частям.
Сетевая безопасность. Часть первая.

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

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

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

Наша задача сейчас — выявить риски, связанные с защищенностью на уровне сети и снизить их до разумной величины.

Если в вашей организации внедрены процессы ISO 27k, то аудит безопасности и изменения сети должны быть органично вписаны в общие процессы в рамках этого подхода. Но эти стандарты все же не о конкретных решениях, не о конфигурации, не о дизайне… Нет однозначных советов, нет стандартов детально диктующих какой должна быть ваша сеть, в этом сложность и красота этой задачи.

Я бы выделил несколько возможных аудитов безопасности сети:

• аудит конфигурации оборудования (hardening)
• аудит security дизайна
• аудит доступов
• аудит процессов

Кажется, что в большинстве случаев это лучшая стартовая точка для аудита и улучшения безопасности вашей сети. ИМХО, это хорошая демонстраций закона Парето (20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата).

Суть в том, что обычно у нас есть рекомендации от вендоров относительно «best practices» по безопасности при конфигурировании оборудования. Это называется «hardening».

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

Несколько примеров для некоторых операционных систем Cisco.

Cisco IOS Configuration Hardening
Cisco IOS-XR Configuration Hardening
Cisco NX-OS Configuration Hardening
Cisco Baseline Security Check List

На основе этих документов может быть создан список требований к конфигурации для каждого типа оборудования. Например, для Cisco N7K VDC эти требования могут выглядеть так.

Таким образом, могут быть созданы конфигурационные файлы для разных типов активного оборудования вашей сетевой инфраструктуры. Далее, вручную или с применением автоматизации, вы можете «залить» эти конфигурационные файлы. Как автоматизировать этот процесс будет подробно рассмотрено в другой серии статей, посвященных оркестрации и автоматизации.
Обычно в сети предприятия (enterprise network) в том или ином виде присутствуют следующие сегменты:

• DC (Public services DMZ and Intranet data center)
• Internet access
• Remote access VPN
• WAN edge
• Branch
• Campus (Office)
• Core

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

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

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

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

Data Center

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

Нужен или нет фаервол?

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

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

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

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

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

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

Фаерволы, особенно современные NGFW (Next-Generation FW) — сложные устройства. Они значительно сложнее чем L3/L2 коммутаторы. Они предоставляют большое количество сервисов и возможностей конфигурирования, поэтому неудивительно, что их надежность значительно ниже. Если непрерывность сервиса является критичной для сети, то, возможно, вам придется выбирать, что приведет к лучшей availability — защищенность с помощью фаервола или простота сети, построенной на коммутаторах (или различного рода фабриках) с использованием обычных ACL.

В случае вышеперечисленных примеров вам скорее всего (как обычно) придется находить компромисс. Посмотрите в сторону следующих решений:

• если вы решили не использовать фаерволы внутри дата-центра, то вам нужно продумать как максимально ограничить доступы по периметру. Например, вы можете открыть только необходимые порты из Интернета (для клиентского трафика) и административные доступы в дата-центр только с джамп хостов. На джамп хостах производить всю необходимую проверку (аутентификацию/авторизацию, антивирус, логирование, …)
• вы можете использовать логическое разбиение сети дата-центра на сегменты, наподобие схемы, описанной в PSEFABRIC пример p002. При этом маршрутизация должна быть настроена таким образом, чтобы трафик, чувствительный к задержкам или высокоинтенсивный трафик ходил «внутри» одного сегмента (в случае p002, VRF-а) и не шел бы через фаервол. Трафик же между разными сегментами будет по-прежнему идти через фаервол. Также можно использовать route leaking между VRF-ами, чтобы избежать перенаправление трафика через фаервол
• также можно использовать фаервол в transparent mode и только для тех VLAN-ов где эти факторы (задержка/производительность) не существенны. Но нужно внимательно изучить ограничения, связанные с использованием этой моды, для каждого вендора
• вы можете подумать о применении service chain архитектуры. Это позволит направлять через фаервол только необходимый трафик. Теоретически выглядит красиво, но я никогда не видел этого решения в продакшене. Мы тестировали service chain для Cisco ACI/Juniper SRX/F5 LTM около 3-х лет назад, но на тот момент это решение показалось нам «сырым»

Уровень защиты

Теперь нужно ответить на вопрос, какие инструменты вы хотите применить для фильтрации трафика. Вот некоторые из возможностей, которые обычно присутствуют в NGFW (например, тут):

• stateful firewalling (по умолчанию)
• application firewalling
• threat prevention (antivirus, anti-spyware, and vulnerability)
• URL filtering
• data filtering (content filtering)
• file blocking (file types blocking)
• dos protection

И тоже не все однозначно. Казалось бы, чем выше уровень защиты, тем лучше. Но вам также нужно учесть, что

• чем больше вышеперечисленных функций фаервола вы используете, тем естественно это будет дороже (лицензии, дополнительные модули)
• использование некоторых алгоритмов может существенно снизить пропускную способность фаервола, а также увеличить задержки, см. например тут
• как и любое сложное решение, использование сложных методов защиты может снизить надежность вашего решения, например, при использовании application firewalling я сталкивался с блокировкой некоторых вполне стандартно работающих приложений (dns, smb)

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

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

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

Сегментирование

Речь идет о логической сегментации сети дата-центра. Например, разбиение на VLAN-ы и подсети — это тоже логическая сегментация, но мы не будем ее рассматривать в силу ее очевидности. Интересна сегментация с учетом таких сущностей как FW security зоны, VRF (и их аналогов применительно к различным вендорам), логических устройств (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Пример такой логической сегментации и востребованного на данный момент дизайна дата-центра приведена в p002 проекта PSEFABRIC.

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

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

Часто сегментация основана только на FW security зонах. Тогда вам нужно ответить на следующие вопросы:

• какие security зоны вам нужны
• какой уровень защиты вы хотите применить к каждой из этих зон
• будет ли разрешен по умолчанию intra-zone трафик
• если нет, то какие политики фильтрации трафика будут применяться внутри каждой из зон
• какие политики фильтрации трафика будут применяться для каждой пары зон (source/destination)

TCAM

Часто встречается проблема недостаточного TCAM (Ternary Content Addressable Memory), как для маршрутизации, так и для доступов. ИМХО, это один из самых важных вопросов при выборе оборудования, поэтому нужно отнестись к этому вопросу с надлежащей степенью аккуратности.

Пример 1. Forwarding Table TCAM.

Давайте рассмотрим Palo Alto 7k фаервол.
Видим, что IPv4 forwarding table size* = 32K
При этом это количество роутов общее для всех VSYS-ов.

Предположим, что в соответствии с вашим дизайном вы решили использовать 4 VSYS-а.
Каждый из этих VSYS-ов по BGP подключен к двум PE MPLS облака, которое вы используете в качестве BB. Таким образом, 4 VSYS-а обмениваются всеми специфическими роутами друг с другом и имеют farwarding table с приблизительно одинаковыми наборами маршрутов (но разными NH). Т.к. каждый VSYS имеет по 2 BGP сессии (с одинаковыми настройками), то каждый маршрут, полученный через MPLS имеет 2 NH и, соответственно, 2 FIB записи в Forwarding Table. Если предположить, что это единственный фаервол в дата-центре и он должен знать про все маршруты, то это будет значить, что общее количество маршрутов в нашем дата-центре не может быть более чем 32000/(4×2) = 4K.

Теперь, если предположить, что у нас 2 дата-центра (с одинаковым дизайном), и мы хотим использовать VLAN-ы, «растянутые» между дата-центрами (например, для vMotion), то, чтобы решить проблему маршрутизации, мы должны использовать хостовые роуты. Но это значит, что на 2 дата-центра у нас будет не больше чем 4096 возможных хостов и, конечно, этого может быть недостаточно.

Пример 2. ACL TCAM.

Если вы планируете фильтровать трафик на L3 коммутаторах (или других решениях, использующих L3 коммутаторы, например, Cisco ACI), то при выборе оборудования вы должны обратить внимание на ACL TCAM.

Предположим вы хотите контролировать доступы на SVI интрефейсах Cisco Catalyst 4500. Тогда, как видно из этой статьи, для контроля исходящего (так же как и входящего) трафика на интерфейсах вы можете использовать лишь 4096 строчек TCAM. Что при использовании TCAM3 даст вам около 4000 тысяч ACE (строк ACL).

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

High Availability

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

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

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

Если вы не используете HA, то с точки зрения двойной поломки ваши риски значительно ниже (т.к. вы имеете 2 независимых фаервола), но т.к. сессии не синхронизированы, то каждый раз, когда будет происходить переключение между этими фаерволами вы будет терять трафик. Можно, конечно, использовать stateless firewalling, но тогда смысл использования фаервола во-многом теряется.

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

Удобство в управлении (managability)

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

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

• бэкапе конфигураций
• апдейтах
• апгрейдах
• мониторинге
• логировании

И все это могут решить централизованные системы менеджмента.

Так, например, если вы используете Palo Alto фаерволы, то Panorama является таким решением.

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

© Habrahabr.ru