Задача
Обеспечить полный доступ из сетей филиалов (Branch Office) к сети центрального офиса (HQ Office) по шифрованному каналу. Организовать защиту внешнего периметра: запретить все входящие соединения из Интернет в центральный офис, выход в Интернет разрешить только прокси серверу из центрального офиса.
Оборудование центрального офиса – CISCO 38XX
Оборудование филиалов – CISCO 18XX
Шифрованный канал организован с использованием VTI, защита периметра - ZBF.
Zone-Based Firewall (ZBF)
Ссылки:
Начиная с версии IOS 12.4(6)T в маршрутизаторах Cisco появилась функциональность называемая Zone-Based Firewall, именно она призвана заменить собой классический firewall (CBAC).
Основное отличие модели ZBF от CBAC в том, что первый, как очевидно из названия, оперирует на уровне зон, второй на уровне интерфейсов. Однако и тот, и другой можно применять одновременно на одном устройстве, но на разных интерфейсах.
Второе значительное улучшение - возможность применения политики в определенному трафику. Дело в том, что в классическом CBAC невозможно применять различные политики к различным группам трафика в пределах одного интерфейса. К примеру, если за внутренним интерфейсом находиться не одна сеть, а несколько, то в случае CBAC применять для них различные политики инспектирования не представляется возможным. С ZBF же это достаточно тривиальная задача.
Третье – простота чтения конфигурации, один набор политик применяется к одному направлению пары зон.
Основные особенности ZBF:
Основные особенности ZBF:
- Зона может состоять из интерфейса или нескольких интерфейсов, в том числе виртуальных, например, VTI.
- Политика применяется к направлению между зонами. Т.е. INSIDE-ISP и ISP-INSIDE это две разных политики.
- Применение ACL остается возможным. При этом входящие ACL применяются ДО ZBF, а исходящие ПОСЛЕ.
- Для всех зон, кроме зоны self (специальная системная зона, предназначенная для управления трафиком с/на маршрутизатор) политика по умолчанию – DROP ANY. Для зоны self политика по умолчанию – PASS ANY. Причем, именно PASS, а не INSPECT. Т.о. при наличии политики ISP-SELF и отсутствии SELF-ISP, ZBF пропустит пакеты от маршрутизатора и не пропустит к маршрутизатору ответные пакеты, например, протокола NTP или ECHO-REPLY, поскольку трафик от маршрутизатора не подвергался инспектированию, а, следовательно, не были динамически открыты "дыры" для обратного трафика. Правильно задавать явную политику инспекции трафика, исходящего из зоны self.
- Важно помнить - при обращении к зоне self инспектирование возможно только для TCP, UDP, ICMP и H.323. Невозможно проведение инспекций уровня 7, а также применение Inspection Parameter map.
- Трафик в пределах одной зоны не подвергается инспектированию.
- Нельзя указать одну и ту же зону в качестве источника и назначения.
Полная картина взаимодействия зон и политик показана в таблице:
Source интерфейс является членом зоны? | Destination интерфейс является членом зоны? | Определение Zone-pair существует? | C3PL policy существует? | Результат |
НЕТ | НЕТ | N/A | N/A | Не применяется ZBF |
Да (зона 1) | Да (зона 1) | Не применимо | N/A | No policy lookup (pass) |
Да | Нет | N/A | N/A | DROP |
Нет | Да | N/A | N/A | DROP |
Да (зона 1) | Да (зона 2) | Нет | N/A | DROP |
Да (зона 1) | Да (зона 2) | Да | Нет | DROP |
Да (зона 1) | Да (зона 2) | Да | Да | Применение политки C3PL |
self | Да | Нет | - | PASS |
self | Да | Да | Нет | PASS |
self | Да | Да | Да | Применение политки C3PL |
Да | self | Нет | - | PASS |
Да | self | Да | Нет | PASS |
Да | self | Да | Да | Применение политки C3PL |
Порядок конфигурирования ZBF:
1. Определить ZBF
2. Определить потоки трафика между зонами
3. Поместить интерфейсы в соответствующие зоны
4. Описать трафик с помощью class-map
5. Описать действия над трафиком с помощью policy-map
6. Определить однонаправленный поток между зонами и к нему соответствующую применить политику.
Элементы конфигурации:
class-map - служит для выделения конкретного трафика из потока, например с помощью acl или выделение по протоколам. Может быть вложенным, т.е. можно выделить трафик с source 192.168.0.0/24 по протоколу http.
policy-map - описание политики. Существует всего три возможных действия - drop, pass, inspect.
zone-pair – определение направления потока и применяемой к нему политики.
Схема
Конфигурация зон HQ следующая:
Зона | Интерфейс | IP адрес |
INSIDE | GE 0/0 | 100.100.100.1 |
INSIDE | Tunnel 3 | 10.10.10.10 |
ISP | GE 0/1 | 100.100.100.2 |
Задача:
Разрешить свободное хождение трафика между головным офисом и филиалами. Выход в интернет для главного офиса обеспечить только через прокси.
Политики:
Внутренний интерфейс помещаем в одну зону (INSIDE) с виртуальными интерфейсами, формирующими шифрованные каналы с филиалами. Таким образом, весь трафик между главным офисом и филиалами является разрешенным и не инспектируется. Изнутри в интернет разрешаем ходить только прокси-серверу по всем протоколам. Снаружи (зона ISP) во внутренние сети доступ закрыт. Кроме того, закрываем все возможности обратиться на внешний интерфейс маршрутизатора Head, кроме создания IPSec VTI канала и ответа на запросы ECHO-REQUEST. Самому маршрутизатору оставляем возможность инициировать IPSec соединения с группой маршрутизаторов в филиалах обращаться к ним по SSH, синхронизировать время по NTP, отправлять запросы ECHO-REQUEST.
Направление | Источник | Назначение | Действие |
INSIDE-ISP | Proxy | Any dns Any ftp Any ftps Any http Any https Any icmp Any udp Any tcp | INSPECT |
ISP-self | BRANCHES udp 500 BRANCHES esp Any icmp echo | self | INSPECT |
self-ISP | self | BRANCHES udp 500 BRANCHES esp BRANCHES tcp 22 NTP_SERVERS udp 123 Any icmp echo Any icmp traceroute | INSPECT |
// Определим зоны безопасности. В данном случае только две – интернет(ISP) и // интранет (INSIDE). Никакого применения политик пока нет - просто имена. HQ (config)#zone security ISP HQ (config)#zone security INSIDE // Сначала определим потоки трафика. Нам нужно создать 3 потока. //СОЗДАНИЕ ПОТОКА INSIDE -> ISP // Определяем протоколы, по которым Prox’е разрешен доступ в интернет с // помощью class-map, который может быть двух типов - с логикой AND // и с логикой OR. В данном случае OR - любой из следующих протоколов HQ (config)#class-map type inspect match-any PROXY-ISP-PROTOCOLS match protocol dns match protocol echo match protocol ftp match protocol ftps match protocol http match protocol https match protocol icmp match protocol udp match protocol tcp // Далее определим IP, с которых и на которые может обращаться Proxy ip access-list extended PROXY-ISP deny ip any 192.168.0.0 0.0.255.255 deny ip any 172.16.0.0 0.0.31.255 deny ip any 10.0.0.0 0.255.255.255 permit ip host PROXY any deny ip any any // Теперь, чтобы скрестить их между собой применяем class-map с логикой AND. class-map type inspect match-all INSIDE-ISP match class-map PROXY-ISP-PROTOCOLS match access-group name PROXY-ISP //создаем политику policy-map type inspect INSIDE-ISP class type inspect INSIDE-ISP inspect class class-default drop // И, наконец, создадим поток INSIDE -> ISP zone-pair security INSIDE-ISP source INSIDE destination ISP service-policy type inspect INSIDE-ISP //Теперь защитим сам маршрутизатор //СОЗДАНИЕ ПОТОКА ISP -> SELF // Определим группу филиальных маршрутизаторов object-group network BRANCHES host 200.200.200.1 . . . host X.X.X.X //Определим группу NTP серверов object-group network NTP_SERVERS host Y.Y.Y.Y Z.Z.Z.Z 255.255.255.254 //Определяем протоколы для создания VTI туннеля и пингов ip access-list extended ISP-SELF permit udp object-group BRANCHES eq isakmp host 100.100.100.1 eq isakmp permit esp object-group BRANCHES host 100.100.100.1 permit icmp any host 100.100.100.1 echo //Классовую карту class-map type inspect match-all ISP-SELF match access-group name ISP-SELF //Политику policy-map type inspect ISP-SELF class type inspect ISP-SELF inspect class class-default drop log // И, наконец, создадим цепочку ISP -> SELF zone-pair security ISP-SELF source ISP destination self service-policy type inspect ISP-SELF //СОЗДАНИЕ ПОТОКА SELF-ISP //Определяем протоколы для создания VTI туннеля, NTP, SSH и пингов ip access-list extended SELF-ISP permit udp host 100.100.100.1 eq isakmp object-group BRANCHES eq isakmp permit esp host 100.100.100.1 object-group BRANCHES permit udp host 100.100.100.1 eq ntp object-group NTP_SERVERS eq ntp permit icmp host 100.100.100.1 any echo permit icmp host 100.100.100.1 any traceroute permit tcp host 100.100.100.1 object-group BRANCHES eq 22 //Классовую карту class-map type inspect match-all SELF-ISP match access-group name SELF-ISP //Политику. При изменении политики лучше ее удалить и создать заново, т.к. //просто изменения иногда не применяются, хотя и отображаются в конфиге. policy-map type inspect SELF-ISP class type inspect SELF-ISP inspect class class-default drop // И, наконец, создадим цепочку SELF -> ISP zone-pair security SELF-ISP source self destination ISP service-policy type inspect SELF-ISP // Теперь назначим интерфейсы в зоны. Необходимо учитывать, // что сразу после этого шага любой трафик между зонами будет запрещен. // Кроме того, что мы уже разрешили, конечно. // ISP – внешний интерфейс HQ (config)#interface GigabitEthernet0/1 HQ (config-if)#zone-member security ISP //INSIDE, растянутый на два интерфейса HQ (config)#interface GigabitEthernet0/0 HQ (config-subif)#zone-member security INSIDE HQ (config)#interface Tunnel 3 HQ (config-subif)#zone-member security INSIDE |
Журналирование удаленных пакетов с указанием причины удаления:
HQ(config)# ip inspect log drop-pkt |
Проверочные команды:
HQ# show zone security [zone-name] HQ# show ip inspect statistics HQ# debug policy-firewall |
HQ#show policy-map type inspect zone-pair ISP-SELF policy exists on zp ISP-SELF Zone-pair: ISP-SELF Service-policy inspect : ISP-SELF Class-map: ISP-SELF (match-all) Match: access-group name ISP-SELF Inspect Packet inspection statistics [process switch:fast switch] udp packets: [602:573] icmp packets: [88:41] Session creations since subsystem startup or last reset 565 Current session counts (estab/half-open/terminating) [0:0:0] Maxever session counts (estab/half-open/terminating) [0:4:0] Last session created 00:06:22 Last statistic reset never Last session creation rate 0 Maxever session creation rate 4 Last half-open session total 0 Class-map: class-default (match-any) Match: any Drop 1037 packets, 34266 bytes |
HQ#show policy-map type inspect zone-pair sessions policy exists on zp SELF-ISP Zone-pair: SELF-ISP Service-policy inspect : SELF-ISP Class-map: SELF-ISP (match-all) Match: access-group name SELF-ISP Inspect Number of Established Sessions = 1 Established Sessions Session 70870460 (100.100.100.1:123)=>(Z.Z.Z.Z:123) ntp:udp SIS_OPEN Created 00:00:11, Last heard 00:00:11 Bytes sent (initiator:responder) [48:96] Class-map: class-default (match-any) Match: any Drop 17 packets, 688 bytes |
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.