Zone based firewall (zbf) на cisco маршрутизаторах - ccienetlab - підготовка до ccna ccnp ccie

Zone Based Firewall (ZFW) - новий напрям на маршрутизаторах під управлінням операційної системи Cisco IOS для конфігурації правил доступу між мережами. До появи цієї технології трафік фільтрувався за допомогою списків доступу ACL і динамічної інспекції трафіку Context-Based Access Control (CBAC). І ACL і правила CBAC'а застосовувалися безпосередньо на фізичні інтерфейси, що в багатьох випадках не сприяє масштабованості і гнучкості рішення. Весь трафік, що проходить через інтерфейс, отримував ту ж саму інспекційну політику. Така модель конфігурації обмежує ступінь деталізації політик брандмауера і викликає плутанину правильного застосування політики міжмережевого екранування, особливо в сценаріях, коли політика брандмауера повинна застосовуватися між декількома інтерфейсами.
Zone Based Firewall змінює конфігурацію брандмауера від старої інтерфейсної моделі на більш гнучку, більш зрозумілу модель, на основі зон безпеки.

Зона безпеки складається з набору різних інтерфейсів, які повинні мати однакову політику мережевої безпеки або, інакше кажучи, однаковий рівень довіри. Після цього всі правила налаштовуються для взаємодій між зонами. Такий підхід полегшує налаштування правил брандмауера. Крім того в Zone-Based Policy Firewall використовується Cisco Policy Language (CPL), яка дозволяє більш гнучко, ніж в попередніх версіях брандмауера, налаштовувати правила фільтрації трафіку.
Зона встановлює межі безпеки вашої мережі. Зона визначає межу, де трафік є предметом обмеження з боку політики, як тільки він іде в іншу область вашої мережі.

На малюнку, ви можете побачити три зони безпеки, призначені на різні інтерфейси маршрутизатора:

Коли ви хочете застосувати політики до трафіку, який проходить між зонами, необхідно пам'ятати одне важливе правило: політики застосовуються до зонової парі (zone pair). При цьому, пара зон це не те ж саме, що. Перша зона в парі називається зоною-джерелом (source zone), друга зоною призначення (destination zone). Коли ви застосовуєте політику міжмережевого екранування до зонової парі, вона застосовується до трафіку який «біжить» від зони-джерела до зони призначення.

Правила для застосування ZBF

Мережеві інтерфейси маршрутизатора які належать зонам є об'єктами ряду правил, які регулюють поведінку інтерфейсу, при русі трафіку між цими інтерфейсами:

• Перш ніж інтерфейси можуть бути призначені зоні безпеки, остання повинна бути налаштована.
  
• Будь-інтерфейс може бути призначений тільки однієї зони безпеки.
  
• Будь-зона може належати один або кілька інтерфейсів
  
• В межах зони за замовчуванням дозволено весь трафік
  
• Між зонами за замовчуванням політика - deny any any
  
• Трафік призначений маршрутизатора або згенерований їм дозволено за умовчанням
  
• Трафік не може протікати між інтерфейсом, який належить зоні і будь-яким інтерфейсом, який не належить ніякої зоні. Інакше кажучи, якщо один з інтерфейсів належить до будь-якої зоні, іншої немає - трафік заборонений
  
• Інтерфейси, які не було призначено в зони функціонують як класичні порти маршрутизатора і, можуть все ще використовувати CBAC.
  

Порядок настройки ZBF

1. створити зони
   
2. Створити пари зон
   
3. Визначити класи (class-map) трафіку, до якого застосовуються політики міжмережевого екранування
   
4. Визначити політику міжмережевого екранування, яка вказує які дії будуть застосовуватися до трафіку
   
5. Застосувати політику міжмережевого екранування до зонової парі
   
6. Додати інтерфейси в зону
   

Створення зон і пар зон

Зони створюються за допомогою команди zone security

Зонні пари створюються за допомогою команди

zone-pair security NAME source FROM-ZONE destination TO-ZONE

Визначення класів трафіку

Наприклад, розглянемо наступну клас-карту

HTTP-трафік повинен зустріти спершу match protocol http. щоб бути впевненим, що трафік обробляється HTTP інспекцією. Якщо ж рядки в клас-карті поміняти місцями, то HTTP трафік потрапить під match protocol tcp і такий трафік буде класифікований як TCP трафік і буде інспектуватися у відповідність з можливостями інспекційного TCP движка.

Список підтримуваних протоколів такий же як у технології CBAC. Однак, на противагу класичним класовим картками, коли ви вводите команду match protocol. ви не включаєте процес NBAR - швидше протокол для інспекції буде обраний коли карта політики буде застосована до зонного парі

Визначення політик міжмережевого екранування

Команда policy-map визначає дію, яке буде вироблено з відфільтрованим за допомогою команди class-map трафіком. Існує три основних дії, які можна застосувати до класифікованому трафіку:

• Drop - Трафік обробляється цим дією сліпо відкидається і ніякого повідомлення на віддалених хост не висилати. На противагу класичним листам доступу (ACL), коли висилається ICMP Host Unreachable. На даний момент немає можливості змінювати поведінку дії Drop.
  Крім вище сказаного, кожна карта політик має прихований клас class-default, для якого налаштовано дію "drop" (аналогічно рядку deny any any в будь-якому списку доступу).
  
• Pass - Пропускає трафік не включаючи інспекцію протоколу. Ця дія дозволяє маршрутизатора пересилати трафік з однієї зони в іншу, при цьому він не е відстежує стан з'єднань або сесій. Ця дія дозволяє проходження трафіку тільки в одному напрямку. Щоб зворотний трафік пройти в зворотному напрямку, повинна бути відповідна політика для нього. Ця дія корисно для таких протоколів, як IPSec ESP, IPSec AH, ISAKMP і інших за своєю суттю безпечних протоколів з передбачуваним поведінкою.
  
• Inspect - Включає динамічну інспекцію для трафіку, який проходить від зони джерела до зони приймача і автоматично дозволяє зворотний трафік навіть для складні протоколів, таких як H323. Наприклад, якщо трафік із зони Private в зону Internet, маршрутизатор підтримує інформацію про з'єднання або сеансах для TCP і UDP трафіку. Тому маршрутизатор дозволяє зворотний трафік із зони Internet в зону Private в якості відповідей на запити з'єднань з Private в Internet.
  

ZBF пропонує опцію логування для трафіку, який відкидається або інспектується.

Застосування політик міжмережевого екранування

Застосування створеної політики міжмережевого екранування здійснюється командою service policy. Через неї ми прив'язуємо policy-map до певної парі зон в одному напрямку.

Для двох зон можна застосувати тільки одну service policy в одному напрямку і, відповідно, одну в зворотному напрямку. Якщо дію з трафіком визначено як inspect. то запити будуть контролюватися таким чином, що в зворотну сторону будуть дозволені відповіді на ці запити. Якщо дію визначено як пропускати трафік, то контролюватися нічого не буде і відповіді на цей трафік проходити не будуть (якщо це не дозволено політикою між зонами в зворотну сторону).

Політика Self-зони маршрутизатора

Політики, які можуть бути застосовані щодо self-зони маршрутизатора мають деякі обмеження.
По-перше, динамічна інспекція для трафіку, який згенерований самим маршрутизатором, обмежена протоколами TCP, UDP, ICMP і H323. Інспекція протоколів на рівні додатків (HTTP, TELNET і ін.) Не підтримується.

По-друге, обмеження по кількості сесій і по смузі також не може бути налаштоване. Якщо ви використовуєте, наприклад, протоколи маршрутизації OSPF, EIGRP, то вони повинні бути явно дозволені - тому що інспекція цих протоколів не підтримується.

Додавання інтерфейсів в зону міжмережевого екранування

Інтерфейси додаються в зону командою zone-member security в налаштуваннях інтерфейсу маршрутизатора.
приклад:

Приклад конфігурації ZBF

Тепер перейдемо до найцікавішого, до налаштування. Розглянемо наступну топологію.

У лівій стороні від роутера R2 знаходиться внутрішня мережа з HTTP сервером, в правій частині вихід в Інтернет. У цій простій конфігурації ми будемо використовувати тільки дві зони. Одну для нашої внутрішньої мережі (PRIVATE), а іншу для зовнішньої (PUBLIC). Ми створимо клас для всього TCP і UDP трафіку, який будемо використовувати в політиці для інспектування.

Інтерфейси Ethernet0 / 0 і Ethernet0 / 1 помістимо в зону PRIVATE, а інтерфейс Serial1 / 0.1 в зону PUBLIC. Між зонами PRIVATE і PUBCLIC здійснюється інспекція всього TCP і UDP трафіку. Інспекція ICMP трафіку не провадиться. Конфігурація динамічної маршрутизації опущена, так само як і конфігурація інших маршрутизаторів, так як для цього прикладу вона не суттєва.

Перевіримо роботу ZBF на R2 і виконаємо telnet і ping на маршрутизатор R5 з маршрутизатора R1

Бачимо, що ми без проблем створюємо TCP з'єднання через маршрутизатор R2, але трафік ICMP не проходить. Команда show policy-map type inspect zone-pair показує статистику роботи ZBF в реальному часі.

Так само можна подивитися поточні сесії встановлені через маршрутизатор. Наприклад в наведеному вище висновку бачимо встановлене TCP TELNET з'єднання з R1 в строну R5. Так як ICMP трафік у нас не класифікується. він потрапляє за замовчуванням потрапляє в class class-default і відкидається.
Виконаємо для ICMP Трафіку інспектування, але обмежимо його рух між зонами PRIVATE і PUBLIC зі швидкістю 8K.

Спробуємо виконати команду ping на роутері R1 в строну R5

Ми бачимо, що при надсиланні 100 пакетів, 9 з них були відпрошуся на R2 - це пакети які що не влізли в зазначену смугу. Виконаємо ще раз команду show policy-map type inspect zone-pair PRIVATE_PUBLIC sessions на R2:

Тут ми бачимо як працював наш обмежувач для ICMP трафіку. В поле conformed вказано що 192 пакета потрапили в 8Kbit-смугу. Але ми посилали 100 пакетів. а звідки взялася цифра 192?

Все просто. Ми посилали 100 ICMP Echo Request пакетів в строну R5, на кожен ICMP Request, маршрутизатор R5 відповідав ICMP Echo Reply. Якби ICMP трафік не був обмежений 8Kbit смугою, то R2 порахував би 200 пакетів, які пройшли через нього - 100 ICMP запитів і 100 ICMP відповідей. Але так як є обмеження для цього трафіку, то 9 пакетів були вбиті - exceeded 9, і до R2 дійшли тільки 91 запит, що дало 91 відповідь. Разом 182. Але перед тим як робити 100-пакетний тест, ми зробили стандартний 5-пакетний ICMP тест, який повністю потрапив в смугу.

Ми можемо включити журнал, щоб бачити створення і завершення сесії для трафіку, що проходить через маршрутизатор. Це робиться за допомогою команди parameter-map

Безпосередньо в parameter-map вказуються параметри які впливають на поведінку ZBF, таке як захист від DoS атак, таймери для TCP і UDP сесій, логирование і т.д. Далі указное параметри застосовуються в політиках для L3 / L4 і L7 - класів трафіку. Нижче наведемо простий приклад включення логування сесій.

В даному прикладі, поведінка інспектування TCP і UDP трафіку було змінено застосуванням параметра, такого як логирование (audit-trail on). Тепер коли створюються і завершуються сесії, R2 буде Залогуватися ці події і видавати повідомлення:

Jun 21 09: 47: 48.052:% FW-6-SESS_AUDIT_TRAIL_START: (target: class) - (PRIVATE_PUBLIC: TCP_UDP): Start tcp session: initiator (24.234.12.1:54529) - responder (5.5.5.5:23)
Jun 21 09: 47: 57.170:% FW-6-SESS_AUDIT_TRAIL: (target: class) - (PRIVATE_PUBLIC: TCP_UDP): Stop tcp session: initiator (24.234.12.1:54529) sent 49 bytes - responder (5.5.5.5: 23) sent 98 bytes

У першому повідомленні вказується що відбулося створення TCP сесії від R1 в строну R5 на порт 23. При цьому вказується зонная пара PRIVATE_PUBLIC і клас трафіку (TCP_UDP) під який потрапило дане з'єднання.

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

Інші новини по темі: