Аутентификация пользователей Cisco ASA через Microsoft Windows NPS.

Задача:

Аутентифицировать Remote IPSec VPN пользователей, терминирующихся на ASA, в домене Windows.

Решение:

Используем для этого Radius. В качестве Radius сервера настроим Microsoft Network Policy Server.

1. ASA получает запрос на установление туннеля от клиента.
2. ASA отсылает запрос на аутентификацию/авторизацию к Radius серверу, чьи функции выполняет NPS.
3. NPS делает запрос в AD.
4. AD отвечает NPS.
5. NPS посылает ответ ASA по Radius протоколу.
6. Устанавливается (или не устанавливается) IPSec туннель.


1. Настройка Cisco ASA.

1) Запустить ASDM, выбрать вкладку Configuration.
2) Выбрать секцию Remote Access VPN
3) Выбрать в меню AAA Setup -> AAA Server Groups
4) Выбрать Add рядом с секцией  AAA Server Groups
5) Выбрать имя группе, например NSP-RADIUS и не забыть указать протокол RADIUS
6) Оставить все остальные настройки по умолчанию и нажать OK.
7) Выбрать только что созданную Server Group.
8) Ниже в секции Servers in the Selected Group нажать Add
9) В поле Interface Name вырать интерфейс, через который ASA будет отсылать запросы на Radius Server.
10) В поле Server Name or IP Address ввести IP адрес нашего Radius сервера.
11) Придумать (и запомнить) пароль и ввести его в поле Server Secret Key. Его же вводим в поле Common Password.
12) Остальное по дефолту и нажать OK.



2. Настройка Microsoft Windows Network Policy Server


Установить Windows Server 2008, который будет нашим Radius сервером.
Добавить функцию Network Policy Server на установленный сервер.

 1) На Windows Server 2008 запустить Server Manager.
 2) Выбрать Roles и нажать правую клавишу мыши и выбрать Add Roles.
 3) На странице Before You Begin нажать Next.
 4) Выбрать роль Network Policy and Access Services role и нажать Next.
 5) Среди Role Service выбрать только Network Policy Server service и нажать Next.
 6) Нажать Install.

По окончании инсталляции регистрируем сервер. Для выполнения этой процедуры нужны права администратора домена.
 7) Выбираем Roles -> Network Policy ans Access Services -> NPS(Local) и нажимаем правую клавишу.
 8) В меню выбираем Register Server in Active Directory.
 9) Выбираем все по дефолту.

Создаем клиентскую запись для ASA.
 10) Выбираем NPS(Local) -> RADIUS Clients and Servers -> Radius Clients.
 11) По правой клавише выбираем New.
 12) Придумываем Friendly Name для нашей ASA. Например, “ASA” :)
 13) Вводим Address(IP or DNS).
 14) Вводим Server Secret Key, который мы указывали в шаге 11 при настройке ASA.
 15) Остальное оставляем по дефолту.

Создаем Connection Request Policy.
 16) Выбираем NPS(Local) -> Policies ->  Connection Request Policies.
 17) В правой половине окна выбираем политику по умолчанию, щелкаем правой клавишей и выбираем Disable.
 18) Встаем обратно на NPS(Local) -> Policies ->  Connection Request Policies и правой клавишей выбираем New.
 19) Выбираем осмысленное имя политики, например ASA.
 20) Оставляем в поле Type of Access значение Unspecified, кликаем Next.
 21) На странице Conditions щелкаем Add. Выбираем и указываем Client IPv4 Address.
 22) Щелкаем Next, на остальных страницах оставляем настройки по умолчанию.

Создаем Network Policy.
 23) По правыму щелчку мыши на  Network Policy выбрать  New.
 24) Дать осмысленный Policy Name. Оставить в поле Type of network access server значение Unspecified и нажать Next.
 25) Требуется определить хотя бы 1  условие в Conditions. Нжимаем Add.
 26) Добавим UsersGroup, чтобы обозначить, что данная политика применяется для соответствуюшей группы в  AD. Можно добавить Client IPv4 Address или любые другие условия. Нажать Next.
 27) В секции Access Permission оставим Access granted (в принципе этот параметр утрачивает влияние, если в шаге 30) мы определим атрибут Class. Но если хотим по-простому можно контролировать доступ этой кнопкой). Жмем Next.
 28) В качестве Authentication methods выбираем только Unencrypted authentication (PAP, SPAP). жмем Next.
 29) Для доступа по VPN выбираем NAS Port Type = Virtual(VPN). жмем Next.
 30) В Settings -> RADIUS Attributes -> Standard выбираем Service-Type = Framed, Framed-Protocol = PPP. По желанию, можно добавить Class с названием политики на ASA, которую надо применять к данному подключению. Жмем Next.
 31) Жмем Finish.

Перестартуем Network Policy Server service.

Проверяем RADIUS аутентификацию.

1) В ASDM выбираем Configuration -> Remote Access VPN -> AAA Setup -> AAA Server Groups
2) Выбираем только что созданную группу.
3) Внизу выбираем сервер и нажимаем справа кнопку Test.
4) Выбираем Authentication, вводим логин, пароль и убеждаемся, что все работает.



Ссылки:

RFC2865 - The RFC "Remote Authentication Dial In User Service (RADIUS)"

Многое взято отсюда

Использование NAT совместно с ZBF

Рассмотрим различные варианты:

1. Традиционный NAT c ZBF
Схема:

При использовании традиционного NAT ZBF отрабатывается ПОСЛЕ NAT, причем ZBFне отслеживает преобразования NAT. Т.е. при прохождении пакета inside-to-outside будет сначала выполнено преобразование NAT, затем к нему применится политика ZBF INSIDE-OUTSIDE.

Т.о. в политике INSIDE-OUTSIDE необходимо разрешить прохождение пакетов с source IP в диапазоне NAT pool. Инспектить эти пакеты смысла нет, т.к. ZBF не являетс я NAT-aware и не отслеживает преобразования NAT, и при этом применяется ПОСЛЕ  NAT. Т.е. при прохождении обратного пакета ZBF будет отрабатываться на destination IP из inside local диапазона, которые следует разрешить в режиме pass в политике OUTSIDE-INSIDE. Не очень  красивая ситуация. Stateful Inspection мы не получим и  входящий ACL на внешнем интерфейсе, прямо запрещающий обращение к адресам inside local, не помешает.
class-map type inspect match-all NAT_cmap
 match access-group name NAT_cmap
class-map type inspect match-all NAT-IN
 match access-group name NAT-IN
policy-map type inspect INSIDE-OUTSIDE
 class type inspect NAT_cmap
  pass
 class class-default
  drop
policy-map type inspect OUTSIDE-INSIDE
 class type inspect NAT-IN
  pass
 class class-default
  drop
zone security INSIDE  
 description Head Office Internal Zone
zone security OUTSIDE
 description ISP Links
zone-pair security INSIDE-OUTSIDE source INSIDE destination OUTSIDE
 service-policy type inspect INSIDE-OUTSIDE
zone-pair security OUTSIDE-INSIDE source UTSIDE destination INSIDE
 service-policy type inspect OUTSIDE-INSIDE  
ip access-list extended NAT_cmap
 permit ip 1.1.1.0 0.0.0.255 any
ip access-list extended NAT-IN
 permit ip any 192.168.0.0 0.0.0.255
ip access-list extended NAT_LIST
 permit ip 192.168.0.0 0.0.0.255 any


NVI с ZBF подружить не удалось.
Создание отдельного  виртуального маршрутизатора для NVI, а ZBF применим на глобальном VRF.


К сожалению,  в режиме inspect реализовать эту схему мне не удалось.


Классический NAT на отдельном VRF плюс ZBF на глобальном. Также получилось только в режиме pass.

IPSec и фрагментация пакетов

Отличная статья про фрагментацию пакетов и PMTUD

При использовании IPSec необходима инкапсуляция пакетов, что ведет к увеличению их размеров.

 

Если размеры получившегося пакета превышают MTU, то маршрутизатор шифрует пакет, а затем его фрагментирует.  Таким образом, принимающий маршрутизатор, должен сначала собрать все фрагменты воедино, а затем расшифровать получившийся пакет. Процесс сборки обычно происходит на process level, что серьезно влияет на производительность. По этой причине фрагментации пакетов желательно избегать, где это возможно. Существуют несколько способов решения данной проблемы. Некторые требуют настройки маршрутизаторов, другие предполагают изменение настроек на конечных клиентах и серверах.

1.       Изменение MTU на конечных станциях. Возможно установить значение MTU на клиентах и серверах меньше, чем стандартное 1500 байт. Рекомендуемое в таком случае значение MTU равно 1300 байт.  К сожалению, масштабы сети часто не позволяют легко и непринужденно поменять настройки на всех машинах. В таком случае, можно попробовать ограничиться серверами, т.к. по большей части именно они являются генераторами больших пакетов.

2.       Path MTU Discovery

Эта фича была придумана, чтобы избежать необходимости фрагментации в принципе.  Она позволяет узлам определить самое маленькое MTU на пути следования пакетов и использовать его в дальнейшем. В этом случае конечная станция шлет пакеты с выставленным битом DF (запрет на фрагментирование).  Если на пути пакета попадается маршрутизатор, чей MTU меньше размеров пакетов, то этот маршрутизатор отсылает ICMP сообщение  type 3, code 4 Fragmentation needed and DF set. В неиспользуемой части ICMP пакета содержится значение MTU, используемое маршрутизатором.  Передающий хост может использовать это значение для корректировки собственного MTU. К сожалению, очень часто маршрутизаторы настроены подавлять отсылку ICMP сообщений type 3, например, с помощью популярной команды настройки интерфейса no ip unreachables. Лучше этого не делать, а если очень хочется, то использовать ip local route-map (разрешив отправку ICMP type 3, code 4). Если, конечно, IOS поддерживает cef switching для route-map (и если cef для local route-map возможен в принципе?).

3.       VPN Interface MTU

Можно подкорректировать, выставить значение 1300 на туннельном интерфейсе

ip mtu 1300

4.       Look Ahead Fragmentation

Фундаментально решает проблемы фрагментации, изменив порядок фрагментации и шифрования. Получив пакет, маршрутизатор просчитывает размер пакета после инкапсуляции, и в случае превышения MTU сначала  фрагментирует пакет, а затем шифрует получившиеся пакетики. Фича доступна с версии IOS 122(13)T и включена по умолчанию.

5.       TCP Maximum Fragment Size

Единственный способ повлиять на размер входящего пакета в условиях, когда не удается договориться с админами на втором конце. TSP MSS определяет максимальный размер TCP сегмента, что, в конечном итоге, определяет размер пакета. Влияет, естественно, только на TCP трафик.  UDP пакеты в основном не превышают  300  байт  за исключением видео.

По историческим причинам (до изобретения PMTUD) MTU для хостов за пределами локальной сети был равен 1300 байт. Отсюда взялось ограничение TCP MSS в 1260 байт (1300 – 20-byte-IP-header – 20-byte-TCP-header).  После внедрения PMTUD это ограничение было снято.

Каждый  из хостов при установлении TCP соединения анонсирует свой MSS в SYN пакетах(необязательно совпадающие).

Команда конфигурирования интерфейса

ip tcp adjust-mss 1260

принудительно переводит поведение TCP сессий в до-PMTUD эпоху. При использовании этой команды на интерфейсе  маршрутизатор переписывает значения MSS в TCP SYN пакетах, полученных на этом интерфейсе. Что, впрочем, заметно нагружает маршрутизатор.

Applying ACL on VTI

По результатам испытаний на тестовом стенде (Cisco 1841 IOS  12.4(25c)) место применения ACL на VTI интерфейсах определено как:

Входящий:

 

Исходящий:

Подавление нежелательных сообщений Host Unreachable

 Вообще для этого есть команда интерфейса no ip unreachable. Но применять ее следует крайне осторожно, т.к. она не позволяет отрабатывать процессу PMTUD.

 В связи с этим возникает естественное желание использовать ACL. Но ACL'ы к трафику, генерируемому самим маршрутизатором, не применяются, поэтому контролировать ICMP пакеты, сгенерированные маршрутизатором мы с их помощью не можем.

 Для этого существует команда ip local policy route-map.

Self-signed certifiactes

Программа для генерации самоподписанных сертификатов живет тут: C:\Program Files\Microsoft Office\Office <version number>\selfcert.exe

Настройка ICMP политик

Для предотвращения reconnaissance атак следует запретить все ICMP сообщения, кроме разрешенных.

В зависимости от условий, могут быть различные настройки, но, как правило, необходимо  разрешать: 

1.   PING   

Название	Type	Code
Echo request	8	0
Echo reply	0	0

2.   TRACEROUTE

Название	Type	Code
Time Exceeded	11	1
Destination port unreachable	3	3

3.   Для обеспечения работы Path MTU discovery

Название	Type	Code
Fragmentation required, and DF flag set	3	4

Необходимо помнить, что маршрутизатор  применяет ACL только к транзитным пакетам (за некоторым исключением на некоторых платформах) и не применяет  к пакетам, сгенерированным самим маршрутизатором.  Для подавления сообщений, сгенерированных маршрутизатором,  ICMP Type 3 существует команда интерфейса no ip unreachable.  Однако, на внешнем интерфейсе она не всегда хороша, т.к. эта команда подавляет  отправку сообщений ICMP Type 3 Code 4 (Fragmentation required, and DF flag set), делая невозможным Path MTU Discovery. Чтобы маршрутизатор не генерировал сообщения ICMP Type 3 при обращении на диапазон неиспользуемых адресов, нужно на Null интерфейсе (предполагаем, что маршрут к неиспользуемым адресам указывает именно туда)  прописать  ip unreachable, тогда маршрутизатор пакеты к этим адресам будет отбрасывать молча.

List of permitted control messages (incomplete list)

Type Code Description 0 - Echo Reply[3] 0 Echo reply (used to ping) 1 and 2 Reserved 3 - Destination Unreachable[4] 0 Destination network unreachable 1 Destination host unreachable 2 Destination protocol unreachable 3 Destination port unreachable 4 Fragmentation required, and DF flag set 5 Source route failed 6 Destination network unknown 7 Destination host unknown 8 Source host isolated 9 Network administratively prohibited 10 Host administratively prohibited 11 Network unreachable for TOS 12 Host unreachable for TOS 13 Communication administratively prohibited 4 - Source Quench 0 Source quench (congestion control) 5 - Redirect Message 0 Redirect Datagram for the Network 1 Redirect Datagram for the Host 2 Redirect Datagram for the TOS & network 3 Redirect Datagram for the TOS & host 6 Alternate Host Address 7 Reserved 8 - Echo Request 0 Echo request 9 - Router Advertisement 0 Router Advertisement 10 - Router Solicitation 0 Router discovery/selection/solicitation 11 - Time Exceeded[5] 0 TTL expired in transit 1 Fragment reassembly time exceeded 12 - Parameter Problem: Bad IP header 0 Pointer indicates the error 1 Missing a required option 2 Bad length 13 - Timestamp 0 Timestamp 14 - Timestamp Reply 0 Timestamp reply 15 - Information Request 0 Information Request 16 - Information Reply 0 Information Reply 17 - Address Mask Request 0 Address Mask Request 18 - Address Mask Reply 0 Address Mask Reply 19 Reserved for security 20 through 29 Reserved for robustness experiment 30 - Traceroute 0 Information Request 31 Datagram Conversion Error 32 Mobile Host Redirect 33 Where-Are-You (originally meant for IPv6) 34 Here-I-Am (originally meant for IPv6) 35 Mobile Registration Request 36 Mobile Registration Reply 37 Domain Name Request 38 Domain Name Reply 39 SKIP Algorithm Discovery Protocol, Simple Key-Management for Internet Protocol 40 Photuris, Security failures 41 ICMP for experimental mobility protocols such as Seamoby [RFC4065] 42 through 255 Reserved