Привязка статического IP адреса VPN пользователям и настройка политик на Cisco ASA.

Исходные данные: На ASA настроена аутентификация пользователей через LDAP. Для LDAP аутентификации  используется Microsoft Windows сервер. Настройка производится с использованием ASDM. Клиенты соединяются по IPSec.

Необходимо выполнить 2 задачи:  

1.  Привязка статического IP к имени пользователя в AD.  

2. Настройка политик в соответствии с LDAP атрибутами пользователя.

1.    Привязка статического IP к имени пользователя в AD.

Постановка задачи: Привязать статический IP удаленным пользователям.

Решение: 

• на сервере аутентификации назначить пользователю статический IP адрес. 
•  проассоциировать соответствующий LDAP атрибут с внутренними атрибутами ASA.

Подробнее:

1.1. В AD пользователю необходимо назначить статический IP адрес, используя вкладку Dial-in.

1.2. Для сопоставления LDAP атрибутов, передаваемых в процессе аутентификации MS Windows сервером, и внутренних атрибутов ASA, необходимо настроить “LDAP Attribute Map” (“Configuration”->”Remote Access VPN” -> “AAA/Local Users” -> “LDAP Attribute Map”). Добавляем LDAP Attribute Map (или модифицируем существующую). В созданной LDAP Attribute Map (или существующей) создаем ассоциацию windows-атрибута msRADIUSFramedIPAddress с  cisco’вским IETF-Radius-Framed-IP-Address.

2.    Настройка политик в соответствии с LDAP атрибутами пользователя.

Постановка задачи: Разрешить удаленное подключение только пользователям, имеющим отмеченный переключатель Allow во вкладке Dial-in в AD.

Решение: 

• на сервере аутентификации пометить пользователя как имеющего право на удаленный доступ (установить соответствующий LDAP атрибут).
• создать Connection Profile на ASA, назначить ему политику, запрещающую всем коннект.
• создать на ASA политику разрешающую коннект. 
• проассоциировать ранее установленный LDAP атрибут, возвращаемый сервером аутентификации с соответствующей разрешительной политикой.

Подробнее:

2.1. В AD пользователю, имеющему право на удаленное подключение, необходимо отметить переключатель Allow, используя вкладку Dial-in.

2.2. К пользователю можно применить политики, определяющие различные атрибуты.

Приоритеты атрибутов политик показаны на схеме:

Существуют следующие типы атрибутов:

1.    Dynamic Access Policy (DAP) Attributes– атрибуты динамических политик доступа, хранятся на флешке в файле dap.xml. Для редактирования из CLI недоступны, следует во всех случаях использовать ASDM.

2.    User Attributes – атрибуты, предоставляемые сервером LDAP. Если на сервере атрибут не установлен, он не возвращается. Например, если на вкладке Dial-in атрибут Remote Access Permission (msNPAllowDialin) выставлен в положение Control Access through Remote  Access Policy, он считается не установленным и  не передается на ASA при аутентификации.

3.    Group Policy Attributes – атрибуты, полученные из групповой политики, ассоциированной с пользователем.

4.    Group Policy Attributes Associated with Connection Profile – атрибуты групповой политики, ассоциированные с Connection Profile

5.    System Default Group Policy – системный атрибуты, определяются в политике по умолчанию DfltGrpPolicy. Применяются всегда в последнюю очередь, обладают самым низким приоритетом.

ASA  складывает атрибуты всех политик с учетом приоритетов политик.  Т.е. атрибуты, определенные в DAP являются более приоритетными, чем User Attributes и  т.д.

В политике  DfltGrpPolicy (“Configuration”->”Remote Access VPN” -> “Network (Client) Access” -> “Group Policies”) атрибут Simultaneous Logins выставлен в 0, запрещая таким образом удаленный коннект.

Создаем Connection Profile (“Configuration”->”Remote Access VPN” -> “Network (Client) Access” -> “IP Connection Profiles”)  и устанавливаем в качестве дефолтной системную  политику DfltGrpPolicy.

2.3. Создаем свою политику, разрешающую VPN соединения AllowVPN (“Configuration”->”Remote Access VPN” -> “Network (Client) Access” -> “Group Policies”). Определяем ее параметры, не забываем выставить атрибут Simultaneous Logins отличный от 0.

2.4. Создаем/редактируем “LDAP Attribute Map” (“Configuration”->”Remote Access VPN” -> “AAA/Local Users” -> “LDAP Attribute Map”), добавляя в нее ассоциацию  атрибута msNPAllowDialin на IETF-Radius-Class (определяет имя Group Policy) . Добавляем также ассоциацию значений TRUE=AllowVPN.

Полезные ссылки:

Supported Cisco Attributes for LDAP Authorization

VLSM шпаргалка.

Принципы управления адресным пространством описаны в руководстве Cisco здесь.

Разбиение сети на подсети иногда является нетривиальной задачей. Использование калькулятора не только не всегда возможно, но и мешает понять суть вещей. Когда-то мною был найден в интернете документ, облегчающий этот процесс. Cам документ и ссылка на него были утеряны. Однако, методику я тут изложу, потому что идея простая, наглядная и красивая :)

Смотрим на рисунок(вертикальными линиями обозначены все возможные варианты границ сетей. Поскольку официально минимальная сеть /30, т.е. содержит 4 адреса, то и линии через каждые 4):

И используем правило:

Можно содавать любые подсети, если вертикальные линии внутри интересующего промежутка ниже линий, ограничивающих этот промежуток. Адрес подсети будет равен цифре под самой левой линией, ограничивающей промежуток, маску подсчитать уже не сложно.

Например, нам необходимо создать подсеть на 5 хостов. Ближайшая к пятерке степень двойки равна 3 (число 8). Теперь откладываем по оси Х 8 от интересующей нас цифры подсети. Например, нам приглянулась подсеть 56:

Видим, что все вертикальные линии в промежутке 56-64 ниже, чем граничные, значит подсеть Х.Х.Х.56/29 допустима.

Теперь посмотрим то же самое для подсети Х.Х.Х.76/29:

Посередине интересующего нас отрезка есть вертикальная линия выше граничных линий, значит сеть Х.Х.Х.76/29  существовать не может.

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

   Задача

Необходимо отслеживать состояние IPSec каналов до филиалов. В случае изменения состояния отсылать сообщение на почту администраторов.

Оборудование центрального офиса – CISCO 38хх

Оборудование филиалов – CISCO 18хх

Шифрованный канал организован с использованием VTI.

Cisco IOS Embedded Event Manager (EEM)

Ссылки:

Cisco IOS Embedded Event Manager 3.2

Writing Embedded Event Manager Policies Using Tcl

Writing Embedded Event Manager Policies Using the Cisco IOS CLI

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

Using VTI VPN with Zone-Based Policy Firewall

   Задача

Обеспечить полный доступ из сетей филиалов (Branch Office) к сети центрального офиса (HQ Office) по шифрованному каналу. Организовать защиту внешнего периметра: запретить все входящие соединения из Интернет в центральный офис, выход в Интернет разрешить только прокси серверу из центрального офиса.

Оборудование центрального офиса – CISCO 38XX

Оборудование филиалов – CISCO 18XX

Шифрованный канал организован с использованием VTI, защита периметра - ZBF.

 Zone-Based Firewall (ZBF)

Ссылки:

IPSec Virtual Tunnel Interface

Cisco IOS Firewall Zone-Based Policy Firewall Release 12.4(6)T Discussion

Zone-Based Policy Firewall Design and Application Guide

Начиная с версии 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