Ця стаття є третьою у циклі статей "Як взяти мережеву інфраструктуру під свій контроль". Зміст усіх статей циклу та посилання можна знайти тут.

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

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

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

Наше завдання зараз – виявити ризики, пов'язані із захищеністю на рівні мережі та знизити їх до розумної величини.

Аудит мережної безпеки

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

Я виділив би кілька можливих аудитів безпеки мережі:

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

Аудит конфігурації обладнання (hardening)

Здається, що в більшості випадків це найкраща стартова точка для аудиту та покращення безпеки вашої мережі. ІМХО, це хороша демонстрація закону Парето (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 ці вимоги можуть виглядати так.

Таким чином, можуть бути створені файли конфігурації для різних типів активного обладнання вашої мережної інфраструктури. Далі, вручну або із застосуванням автоматизації, ви можете "залити" ці конфігураційні файли. Як автоматизувати цей процес буде детально розглянуто в іншій серії статей, присвячених оркестрації та автоматизації.

Аудит security дизайну

Зазвичай у мережі підприємства (enterprise network) у тому чи іншому вигляді присутні такі сегменти:

• DC (Public services DMZ and Intranet data center)
• Доступ в інтернет
• VPN віддаленого доступу
• WAN edge
• Філія
• Campus (Office)
• Core

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

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

Розглянемо кожен з них окремо щодо проблем, з якими ви можете зіткнутися з точки зору security дизайну. Звичайно, знову повторюся, що жодною мірою дана стаття не претендує на повноту, досягти якої в цій дійсно глибокій і багатогранній темі непросто (якщо взагалі можливо), але відображає мій особистий досвід.

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

Центр обробки даних

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

Потрібен чи ні фаєрвол?

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

Приклад 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 для Cisco ACI/Juniper SRX/F5 LTM близько 3-х років тому, але на той момент це рішення здалося нам «сирим»

рівень захисту

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

• stateful firewalling (за замовчуванням)
• application firewalling
• threat prevention (antivirus, anti-spyware, and vulnerability)
• Фільтрація URL-адрес
• 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 обмінюються всіма специфічними роутами один з одним і мають forwarding table з приблизно однаковими наборами маршрутів (але різними NH). Т.к. кожен VSYS має по 2 BGP сесії (з однаковими налаштуваннями), кожен маршрут, отриманий через MPLS має 2 NH і, відповідно, 2 FIB записи в Forwarding Table. Якщо припустити, що це єдиний фаєрвол у дата-центрі і він повинен знати про всі маршрути, то це означатиме, що загальна кількість маршрутів у нашому дата-центрі не може бути більшою ніж 32K/(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 для доступів — аудит доступів, видалення застарілих записів, що перетинаються, а також, можливо, перегляд процедури відкриття доступів (буде детально розглянуто в розділі, присвяченому аудиту доступів).

Висока доступність

Питання, чи використовувати HA для фаєрволів або поставити «паралельно» дві незалежні коробки і у разі падіння однієї з них маршрутизувати трафік через другу?

Здавалося б, відповідь очевидна – використовувати HA. Причина, чому це питання все ж таки виникає полягає в тому, що, на жаль, теоретичні та рекламні 99 і кілька дев'яток після коми відсотків доступності на практиці виявляються далеко не такими райдужними. HA — логічно досить складна штука, і на різному устаткуванні, і з різними вендорами (винятків не було) ми відловлювали проблеми та баги та зупинку сервісу.

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

Якщо ви не використовуєте HA, то з точки зору подвійної поломки ваші ризики значно нижчі (т.к. ви маєте 2 незалежні фаєрволи), але т.к. сесії не синхронізовані, то щоразу, коли відбуватиметься перемикання між цими фаєрволами ви втрачатимете трафік. Можна, звичайно, використовувати stateless firewalling, але тоді сенс використання фаєрвола багато в чому втрачається.

Тому, якщо в результаті аудиту ви виявили фаєрволи, що самотньо стоять, і ви замислюєтеся про збільшення надійності вашої мережі, то HA, звичайно, є одним з рекомендованих рішень, але ви повинні врахувати і мінуси, пов'язані з цим підходом і, можливо, саме для вашої мережі більш відповідним буде інше рішення.

Зручність в управлінні (managability)

У принципі HA - це навіть про керованість. Замість конфігурування 2-х коробок окремо і вирішення проблеми синхронізації конфігурацій, ви керуєте ними багато в чому так, ніби у вас один пристрій.

Але, можливо, у вас багато дата-центрів та багато фаєрволів, тоді це питання постає на новому рівні. І питання не лише про конфігурування, а й про

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

І це можуть вирішити централізовані системи менеджменту.

Так, наприклад, якщо ви використовуєте Palo Alto фаєрволи, то Дивитися є таким рішенням.

Далі буде.

Джерело: habr.com