Cisco AnyConnect Source IP restrict: ограничение доступа по внешнему IP клиента

Здесь описан способ решения одной нетривиальной задачи: разрешить доступ пользователю к локальным ресурсам сети через Cisco AnyConnect VPN только, если он подключается с конкретного внешнего IP-адреса (source/public-IP).

Такое ограничение доступа может потребоваться в целях повышения безопасности и имеет свои плюсы:
1. Например, если вы выдаете доступ сотруднику компании-подрядчика и хотите чтоб он подключался только с внешнего IP-адреса этой компании, а не где-то из дома, кафе и т.п.
2. Таким образом, даже если злоумышленник похитит сертификат и узнает учетную запись пользователя, он все равно не получит доступ к локальным ресурсам вашей сети, т.к. он наверняка будет подключатся с внешнего IP, отличного от IP компании-подрядчика.


Вариант 1. Если в качестве AAA используется RADIUS.

Решение:
Здесь все гораздо проще чем с LDAP. Чтобы идентифицировать внешний IP клиента, можно воспользоваться атрибутом NAS-Port-ID (RADIUS attribute 87). На сервер RADIUS создаем нечто похожее на такое условие:

Вариант 2. Если в качестве AAA используется LDAP.

Решение:
Предлагаю нестандартное решение, при котором клиенты все равно подключатся, но будут иметь ограниченный доступ или доступ будет полностью запрещен, если внешний IP-адрес отличается (например, в Whois у компании одна подсеть, а запрос на VPN-подключение приходит из другой подсети). ASA будет создавать динамический auto-NAT 1:1, как только клиент подключится, и удалять это NAT, при отключении клиента. Схематично это выглядит так:





Требования к VPN-инфраструктуре:
1. Клиент должен иметь сертификат вашего Certificate Authority (CA).
2. VPN AnyConnect должен быть настроен на проверку подключения по сертификатам.
3. (опционально) Должна быть настроена проверка списков отзыва сертификатов (OCSP, CRL, SCEP).


Приступим к настройке...

Выбираем в сертификате поле, с которым в дальнейшем работаем (в нашем случае поле CN из Subject-Name - имя пользователя).Подменяем Tunnel-Group, если в сертификате subject-name содержит cn = ivan ivanov.Создаем отдельную Tunnel-Group для таких "особенных" клиентов.Когда подключится клиент, в NAT появится динамическая запись типа:Это значит, что клиент теперь идет в локальную сеть с адресом 1.2.3.4 (вместо 10.254.1.100 - адрес из VPN пула). Далее можно фильтровать по этому Src-IP = 1.2.3.4 доступ к локальным ресурсам по ACL inside-out, который нужно вешать на inside на выход (out):ACL inside-out должен полностью копировать outside-in для хостов в LAN + добавляются записи для внешнего IP клиента. Обратный трафик по инспекции пропускается обратно в VPN-туннель.
Плюс еще применяется ACL из Dynamic Access Policy (DAP) к VPN-сессии клиента.

Из минусов:
1. Такая схема работает только тогда, когда подключен только один клиент с этого внешнего IP-адреса в текущий момент времени, т.к. NAT 1:1 (т.е. 1 клиент = 1 внешний IP).
2. В списках доступа (ACL) необходимо будет разрешать доступ к ресурсам локальной сети для внешнего IP, а не для локального (RFC1918).



P.S.:
В принципе, ограничение описанное в п.2 (по поводу ACL для внешних IP), можно обойти, если пользователю 'ivan ivanov' при подключении к VPN выдавать всегда один и тот же IP-адрес (как в примере, 10.254.1.100). Как это красиво сделать, не прибегая к созданию отдельных Tunnel-Group и Group-Policy я напишу в следующей статье.