Мы будем жить теперь по новому! (zone-based firewall)
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00808bc994.shtml http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_configuration_example09186a00809492a4.shtml Начиная с версии IOS 12.4(6)T в рутерах Cisco появилась функциональность называемая Zone-Based Firewall, именно она призвана заменить собой классический firewall (CBAC). В чем отличие, какие основные возможности я и попробую ответить в этой заметке. 1. Немного теории Основное отличие модели ZBF от CBAC в том, что первый, как очевидно из названия, оперирует на уровне зон, второй на уровне интерфейсов. Второе значительное улучшение -позможность применения политики в определенному трафику. Дело в то том, что в классическом CBAC невозможно применять к различные политики к различным группам трафика в пределах одного интерфейса. К примеру, если за внутренним интерфейсом находиться не одна сеть, а несколько, то в случае CBAC применять для них различные политики инспектирования не представляется возможным. С ZBF же это достаточно тривиальная задача. Синтаксис конфигурации, называемый Cisco Policy Language (CPL) достаточно похож на MPF в устройствах ASA. Несколько фактов облегчающих понимание "как это работает". - Зона может состоять из интерфейса или нескольких интерфейсов. - Политика применяется к направлению между зонами. Т.е. inside-outside и outside-inside это две разных политики. - Важное изменение, политика по умолчанию - deny any any. - Можно использовать CBAC и ZBF одновременно, но на разных интерфейсах. - Если два интерфейса не принадлежат ни к одной зоне - трафик разрешен. - Если один из интерфейсов принадлежит к какой-либо зоне, другой нет - трафик запрещен. - Если два интерфейса принадлежат к разным зонам - трафик запрещен до явного разрешения. - Трафик в пределах одной зоны не подвергается инспектированию. Элементы конфигурации: class-map - служит для выделения конкретного трафика из потока, например с помощью acl или выделение по протоколам. Может быть вложенным, т.е. можно выделить трафик с source 192.168.0.0/24 по протоколу http. policy-map - применение политики, Существует всего три возможных действия - drop, pass, inspect. Стенд Конфигурация сети следующая: insideA - 10.10.11.1/24 insideB - 10.10.12.1/24 outside - 10.10.10.1/24 dmzA - 10.10.20.1/24 2. Базовая модель Начнем с простейшей конфигурации. Забудем пока о наличии ДМЗ и решим самую типичную задачу - предоставление доступа в интернет с инспектированием трафика. Все, остальные конфигурации по сути своей будут строиться на этой как на базовой. Здесь же удобно рассмотреть основные командыконфигурирования, комментарии по тексту. // определим зоны безопасности, в данном случае только две интернет и интранет // никакого применения политик пока нет - просто имена. R1(config)#zone security outside R1(config-sec-zone)#description Big and Scary internet R1(config)#zone security inside R1(config-sec-zone)# description Shy and modest intranet // назначим интерфейсы в зоны, необходимо учитывать, // что сразу после этого шага любой трафик между зонами будет запрещен // ouside R1(config)#interface FastEthernet0/0 R1(config-if)#zone-member security outside R1(config-if)#description ouside //inside, растянутый на два интерфейса R1(config)#interface FastEthernet0/1.800 R1(config-subif)#description insideB R1(config-subif)#zone-member security inside R1(config)#interface FastEthernet0/1.900 R1(config-subif)#description insideA R1(config-subif)#zone-member security inside Ну вот и отлично, всё что можно запретили - безопасность на уровне. :) Теперь займемся разрешением. // определение протоколов по которым пользователям разрешен в интернет, // например, http, smtp, dns // class-map может быть двух типов - с логикой AND и с логикой OR. В // данном случае OR - любой из трех протоколов R1(config)#class-map type inspect match-any cm_http-dns-smtp R1(config-cmap)#match protocol http R1(config-cmap)#match protocol smtp R1(config-cmap)#match protocol dns // это пример class-map с логикой AND. Данная карта выбирает // фильтрует трафик с source 10.10.12.0/24 и любым из протоколов http, dns, smtp R1(config)#access-list 120 permit ip 10.10.12.0 0.0.0.255 any R1(config)#class-map type inspect match-all cm_insideB_web R1(config-cmap)#match class-map cm_http-dns-smtp R1(config-cmap)#match access-group 120 //создание политики R1(config)#policy-map type inspect in-out R1(config-pmap)#class type inspect cm_insideB_web R1(config-pmap-c)#inspect // Момент истины, создадим цепочку inside -> outside и наделим // интернетом счастливых пользователей insideB R1(config)#zone-pair security inside-outside source inside destination outside R1(config-sec-zone-pair)#service-policy type inspect in-out
Еще раз хочу обратить внимание, при всей этой конфигурации трафик в пределах зоны, т.е. между интерфейсами insideA и insideB разрешен.
3. Усложненная конфигурация. Усложняется она использованием ДМЗ, все остальные параметры остаются теми же. //Определим новую зону и назначим её интерфейсу R1(config)#zone security dmz R1(config-sec-zone)#description Controlled DMZ
R1(config)#int fa0/1.700 R1(config-subif)#zone-member security dmz //выделим сервер или группу подлежащую публикации R1(config)#access-list 199 remark Publishing web server R1(config)#access-list 199 permit ip any host 10.10.20.2 //определим по каким протоколам серверы будет виден снаружи R1(config)#class-map type inspect match-all pub-web R1(config-cmap)#match access-group 199 R1(config-cmap)#match protocol http //создадим политику разрешающую доступ R1(config)#policy-map type inspect www-dmz R1(config-pmap)#class type inspect pub-web R1(config-pmap-c)#inspect //создадим цепочку outside -> dmz R1(config)#zone-pair security out-dmz source outside destination dmz Теперь сервер 10.10.20.2 доступен в интернет по протоколу http, если необходимо добавить еще один сервер достаточно просто изменить acl 199
Защищая себя (zone-based firewall self)
В предыдущей заметке была рассмотрена функциональность под названием Zone-Based firewall, которую компания Cisco позиционирует как замену достаточно широко используемой CBAC. Были показаны основные команды конфигурирования и типичный сценарий применения. К сожалению я совершенно забыл о такой необходимости как защита самого маршрутизатора. Сегодня поговорим об этом. Для управлением трафиком предназначенным непосредственно маршрутизатору или трафику создаваемому им самим, в понимании ZBF предназначена специальная зона - self. Соответственно, да контроля, например, доступа к маршрутизатору из интернета, необходимо создать цепочку (zone-pair) internet -> self и уже в контексте её политики задавать необходимы разрешения.. По умолчанию зона уже создана. Одно из основных отличий от "нормальных" зон - поведение по-умолчанию, трафик к/от self зоны разрешен. Также отмечу, self зона достаточно обрезана в функциональности инспекция возможна только для протоколов tcp, udp, icmp, H.323 Опять таки, простейший пример конфигурации: - из интернета запретить всё кроме icmp; - из интранета, дополнительно к icmp разрешить ssh и https для задач управления. Значительно облегчит задачу существующий по-умолчанию класс - class-default выделяющий весь трафик, наподобие permit any any acl. Логичным было бы создать примерно следующую политику:
R1(config)#class-map type inspect match-all cm_manage R1(config-cmap)#match protocol icmp R1(config-cmap)#match protocol ssh R1(config-cmap)#match protocol https R1(config)#policy-map type inspect in-self R1(config-pmap)#class type inspect cm_manage R1(config-pmap-c)#inspect R1(config-pmap)#class class-default R1(config-pmap-c)#drop R1(config)#zone-pair security in-self source inside destination self R1(config-sec-zone-pair)#service-policy type inspect in-self
Но не выходит. :) Здесь мы сталкиваемся с ограничением на глубину инспекции в self зонах. Как сказано выше, максимальный уровень инспекции в данном случае - L3/L4. При применении получаем сообщение вида:
R1(config-sec-zone-pair)#service-policy type inspect out-self %Protocol https configured in class-map cm_manage cannot be configured for the self zone. Please remove the protocol and retry Inspect service-policy attachment failed
Заставить злобную железяку всё таки разрешать соединения по протоколам ssh и https можно следующим образом: R1(config)#access-list 198 permit tcp any any eq 22 R1(config)#access-list 198 permit tcp any any eq 443 R1(config)#class-map type inspect match-any cm_manage R1(config-cmap)#match protocol icmp R1(config-cmap)#match access-group 198 R1(config)#policy-map type inspect in-self R1(config-pmap)#class type inspect cm_manage R1(config-pmap-c)#inspect R1(config-pmap)#class class-default R1(config-pmap-c)#drop R1(config)#zone-pair security in-self source inside destination self R1(config-sec-zone-pair)#service-policy type inspect in-self
Хочу обратить внимание, что реальной инспекции именно протоколов http и ssh не происходит, пакеты инспектируются до уровня tcp.
Замечу, то что описывается в данной заметке не является официально рекомендуемым способом обеспечивать безопасность самого устройства. Для этого предназначен - Network Foundation Protection, который я надеюсь рассмотреть немного позже. Вот мы и познакомились с общими концепциями построение брандмауэров от Cisco. Хочется заметить, представленный метод конечно достаточно громоздок и если у вас всего два интерфейса между которыми необходимо настроить инспекцию, возможно классический CBAC в этом окажется удобнее, как минимум объем команд меньше. Если же конфигурация усложняется, или же имеет свойство изменяться, Zone-Based Firewall именно то решение которое необходимо. Конфигурация гораздо легче читается и поддерживать, расширять, её проще.
Posted by pablo
at 8:21
PM 2
comments:
Labels: firewalling, ios, security
Cisco Zone-Based Policy Firewall и WCCP + Squid 2.7
Рассмотрим пример конфигурирования CISCO 871 в роли Брандмауэра (Firewall) c помощью новой модели конфигурирования Zone-Based Policy Firewall (ZFW), а также настроим на использование WCCP (Web Cache Control Protocol), в качестве кэша будем использовать прокси- сервер SQUID 2.7 работающий под ОС Linux Ubuntu 8.10. Топология сети представлена ниже.
Что имеем: CISCO 871 – с IOS Advanced IP Service K9, если у вас отличная от этой версия IOS, то вы не сможете использовать больше одно VLAN’а. Конечно, если вы не используете спец. сборку IOS, в которой имеется поддержка VLAN.
FastEthernet 4 (FE4) – Порт подключен к сети провайдера (WAN), присвоены:
-
IP адрес: 79.XXX.XXX.XXX
-
Маска подсети: 255.255.255.252
-
Шлюз: 79.XXX.XXX.XXVLAN 1
VLAN 1
-
IP адрес: 192.168.2.2
-
Маска подсети: 255.255.255.000
VLAN 2
-
IP адрес: 192.168.77.1
-
Маска подсети: 255.255.255.000
WCCP cache – SQUID 2.7 под управлением ОС Ubuntu 8.10 располагается в DMZ зоне, на сервере имеются следующие сетевые интерфейсы:
eth0 – Порт подключен к FastEthernet 2 на Cisco, присвоены:
-
IP адрес: 192.168.77.2
-
Маска подсети: 255.255.255.000
-
Шлюз: 192.168.77.1
Mail server – CGPro под управлением ОС Ubuntu 8.10 располагается в DMZ зоне, на сервере имеются следующие сетевые интерфейсы eth0 – Порт подключен к FastEthernet 2 на Cisco, присвоены:
-
IP адрес: 192.168.77.3
-
Маска подсети: 255.255.255.000
-
Шлюз: 192.168.77.1
Пользовательские ПК, располагающиеся в LAN зоне, подсеть 192.168.2.0/24 с шлюзом 192.168.2.2 Определились с исходными данными – теперь нам стоит определиться с тем, какими ресурсами/сервисам сети интернет и наших серверов пользователи могут использовать, а также какие сервисы будут доступны из сети интернет. Из сети интернет пользователям доступны сервисы, работающие по следующим протоколам: aol, http, https, ftp, dns, icmp, udp, ssh. А также разрешен доступ к почтовым серверам mail.ru по протоколам smtp и pop. Из зоны DMZ для пользователей разрешено все, если вам понадобится разрешить доступ к чему- то конкретному, вы легко сможете сделать это по аналогии. Из зоны LAN для серверов также разрешено все. Для серверов из интернета доступны http, https, ftp, dns, icmp, udp, ssh, smtp, pop. Из сети интернет доступны следующие сервисы из зоны DMZ: smtp и openvpn, работающий на 2000 порту по протоколу TCP. На рисунке ниже схематично изображено использование сервисов зонами.
Приступим непосредственно к конфигурированию брандмауэра. Руководство по конфигурированию ZFW описывает порядок выполнения процедуры по конфигурированию:
-
Определить зоны (zone);
-
Определить пары зон (zone-pair);
-
Определение классов (class-map), описывающих трафик, к которому будет применяться политика на пересечении пары зон;
-
Определение политик (policy-map), применяемых к ранее созданным классам трафика (class-map);
-
Применение политик к паре зон;
-
Связывание интерфейса с зоной.
Определим зоны В нашем случае используется три зоны: LAN – подсеть, в которой находятся пользователи, DMZ – подсеть серверов, WAN – сеть провайдера (интернет).!
zone security lan zone security dmz zone security wan
Определим пары зон Из рисунка 2 можно увидеть, что получается пять пар зон. zone-pair security lan-dmz source lan destination dmz zone-pair security dmz-lan source dmz destination lan zone-pair security dmz-wan source dmz destination wan zone-pair security wan-dmz source wan destination dmz zone-pair security lan-wan source lan destination wan Определим классы трафика Проходящий трафик может классифицироваться по нескольким критериям: Access-group, Protocol, Class-map, Not. Трафик может быть классифицирован при условии полного совпадения всех критериев (match-all) или неполного – от одного и более (match-any).
В нашем примере пользователи в интернете имеют доступ только к почтовым серверам mail.ru, для этого нам следует определить список доступа:
ip access-list extended mail.ru-acl permit ip any host 91.190.232.8 permit ip any 194.67.23.0 0.0.0.255 permit ip any 194.67.57.0 0.0.0.255 permit ip any 194.168.55.0 0.0.0.255 permit ip any 194.186.55.0 0.0.0.255 ! Также в DMZ у нас находится VPN сервер: ip access-list extended openvpn-acl permit tcp any any eq 2000 ! Следующий список доступа будет нам давать полный доступ между зонами DMZ и LAN в обоих направлениях
! ip access-list extended lan-dmz-all-acl permit ip any any ! Определим классы ! class-map type inspect match-any lan-dmz-all-class match access-group name lan-dmz-all-acl class-map type inspect match-any smtp-class match protocol smtp class-map type inspect match-all smtp-mail.ru-acl-class match class-map smtp-class match access-group name mail.ru-acl class-map type inspect match-any internet-traffic-class match protocol http match protocol https match protocol ftp match protocol dns match protocol icmp match protocol udp match protocol aol match protocol ssh class-map type inspect match-any user-allow-traffic-class match class-map internet-traffic-class match class-map smtp-mail.ru-acl-class class-map type inspect match-any dns-smtp-openvpn-class match protocol dns match protocol smtp match access-group name openvpn-acl ! Определим политики! policy-map type inspect wan-dmz-policy class type inspect dns-smtp-openvpn-class pass class class-default drop policy-map type inspect lan-wan-policy class type inspect user-allow-traffic-class inspect class class-default drop policy-map type inspect dmz-wan-policy class type inspect internet-traffic-class inspect class type inspect smtp-class inspect class class-default drop policy-map type inspect lan-dmz-all-policy class type inspect landmz-gre-class pass class class-default drop Применим политики к паре зон! zone-pair security lan-dmz source lan destination dmz service-policy type inspect lan-dmz-all-policy zone-pair security dmz-lan source dmz destination lan service-policy type inspect lan-dmz-all-policy zone-pair security dmz-wan source dmz destination wan service-policy type inspect dmz-wan-policy zone-pair security wan-dmz source wan destination dmz service-policy type inspect wan-dmz-policy zone-pair security lan-wan source lan destination wan service-policy type inspect lan-wan-policy ! Свяжем зоны с интерфейсами! interface FastEthernet4 ip address 79.XXX.XXX.XXX 255.255.255.252 ip nat outside zone-member security wan ! interface Vlan1 ip address 192.168.2.2 255.255.255.0 ip nat inside zone-member security lan ! interface Vlan2 ip address 192.168.77.1 255.255.255.0 ip nat inside zone-member security dmz
Конфигурация NAT’а для доступа к ресурсам DMZ: Для почтового и VPN серверов
ip nat inside source static tcp 192.168.77.3 25 interface FastEthernet4 25 ip nat inside source static tcp 192.168.77.3 2000 interface FastEthernet4 2000 ! С настройками ZFW закончили, перейдем к конфигурированию WCC. Минимальные настройки SQUID http_access allow all http_port 3128 transparent wccp router 192.168.77.1 wccp version 4 Создадим GRE туннель и зададим перенаправление порта с 80 на 3128 /etc/network/wccp.up #!/bin/bash ip tunnel add tnl0 mode gre local 192.168.77.2 remote 192.168.77.1 ttl 255 ip link set tnl0 up ip addr add 192.168.90.75 dev tnl0 iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 3128
Отмечу особенность конфигурирования WCCP на Cisco. При построении GRE туннеля на сервере с установленным прокси-сервером Squid в качестве удаленного хоста следует ввести IP адрес, указанный на маршрутизаторе Cisco как Router Identifier, узнать его можно при помощи команды show ip wccp. Если IP адрес не принадлежит той же зоне, где располагается ваш прокси-сервер, (например, IP адрес принадлежит зоне LAN) то вам следует разрешить GRE трафик между зоной, где располагается прокси-сервер и зоной, которой принадлежит IP адрес, указанный в Router Identifier.
ip access-list extended lan-dmz-all-acl permit ip any any permit gre any any ! Существует правило: в качестве IP адреса в Router Identifier выбирается наибольший по значению IP адрес из присвоенных интерфейсам Сisco.
/etc/network/wccp.down #!/bin/bash iptables -t nat –F ip tunnel del tnl0 В /etc/network/interfaces добавим post-up /etc/network/wccp.up pre-down /etc/network/wccp.down В файле /etc/sysctl.conf сделаем следующие изменения: net.ipv4.conf.all.rp_filter=0 net.ipv4.ip_forward=1 На этом все настройки со стороны сервера закончены, переходим к конфигурированию Cisco. Указываем на каком интерфейсе будем обрабатывать http трафик, в нашем случае VLAN 1! interface Vlan1 ip address 192.168.2.2 255.255.255.0 ip wccp web-cache redirect in ip nat inside zone-member security lan Так как используем первую версию протокола, то обязательно указываем ip wccp version 1, так как по умолчанию используется вторая версия.
! ip wccp version 1 ip wccp web-cache ! На этом конфигурирование wccp завершается.