вторник, 23 ноября 2010 г.

Применение Cisco IOS EEM CLI Applet для отслеживания состояния каналов.



   Задача


Необходимо отслеживать состояние IPSec каналов до филиалов. В случае изменения состояния отсылать сообщение на почту администраторов.
Оборудование центрального офиса – CISCO 38хх
Оборудование филиалов – CISCO 18хх
Шифрованный канал организован с использованием VTI.

Cisco IOS Embedded Event Manager (EEM)
Ссылки:

Cisco IOS Embedded Event Manager (EEM) позволяет запрограммировать реакцию устройства Cisco на различные события в реальном времени. EEM является частью операционной системы Cisco IOS. Решение EEM состоит из детекторов событий (Event Detectors), менеджера событий (Event Manager), а также механизма политик менеджера событий (Event Manager Policy Engine). Механизм политик управляет двумя типами политик, настраиваемых пользователями – Applet policies и Tcl policies.  

 Клиенты могут настроить политики для выполнения определенных действий в случае, если программное обеспечение Cisco IOS через встроенные детекторы событий  (show event manager detector all) распознает определенные события. Результатом является чрезвычайно мощный и гибкий набор инструментов, позволяющий автоматизировать многие задачи сетевого управления и контролировать работу Cisco IOS с целью повышения доступности, сбора информации и оповещения внешних систем или персонала о критических событиях.

Вариантов решения задачи несколько, остановимся на использовании CLI Applets. Поскольку у нас используются VTI для организации IPSec канала, то ситуация упрощается – будем отслеживать изменение состояния по сообщениям LINEPROTO-5-UPDOWN в syslog’е. Это позволит использовать один апплет для всех каналов.

//Инициализируем переменные, необходимые для отправки писем
event manager environment _email_server 192.168.1.10
event manager environment _email_to noc@headoffice.ru;admin@headoffice.ru
event manager environment _email_from cisco@headoffice.ru

// Создаем апплет
event manager applet VPNTunnelTrack

// Указываем интересующее нас событие из syslog’а
 event syslog occurs 1 pattern "LINEPROTO-5-UPDOWN"

// Вытаскиваем время события, описание интерфейса, статус интерфейса с помощью // regexp
 action 100 regexp "(..:..:..).*(Tunnel[0-9]+), changed state to (.*)" "$_syslog_msg" var time interface_name interface_state

// Проверяем, получилось ли вытащить
 action 200 if $_regexp_result eq 1

// Вытаскиваем строку с описанием интерфейса, изменившего статус
 action 300  cli command "show interface $interface_name | include Description"

// На всякий случай инициализируем переменную, в которую будем вытаскивать
// описание интерфейса
 action 400  set desc "The state of interface $interface_name has changed. Tunnel Description is not set. Please login to Cisco and describe interface $interface_name."

// Вытаскиваем описание интерфейса
 action 500  regexp "Description: (.*)\r" "$_cli_result" var desc

//Для каждого адреса в строке адресатов
action 600  foreach email "$_email_to" ";"

//Отправляем письмо
 action 700   mail server "$_email_server" to "$email" from "$_email_from" subject "$desc is $interface_state!" body "$desc got $interface_state  at $time, Moscow time."

//Конец цикла
 action 800  end

// Вот и все
 action 900 end

четверг, 18 ноября 2010 г.

Using VTI VPN with Zone-Based Policy Firewall


   Задача


Обеспечить полный доступ из сетей филиалов (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:
  • Зона может состоять из интерфейса или нескольких интерфейсов, в том числе виртуальных, например, 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