Защищая себя (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 именно то решение которое необходимо. Конфигурация гораздо легче читается и поддерживать, расширять, её проще.