Когда пользователи VPN подключаются к корпоративной VPN HQ, их доступ к интернету в основном осуществляется из внешней сети во внешнюю.
Для этого у нас есть правило NAT:
nat (outside, outside) source dynamic RemoteUsers interface
Где “RemoteUsers” фактически представляет диапазон IP-адресов VPN.
На мой взгляд, это фактически позволяет удаленным пользователям без ограничений доступ к интернету при подключении. Я не уверен, что это лучший практический подход. Я знаю, что можно ограничить доступ только к HTTP и HTTPS для повышения безопасности.
Это правило ранее реализовывалось в ASA, а сейчас оно также есть в нашей тестовой среде FMC/FTD. Так что у меня вопрос:
- Есть ли другой способ сделать это?
- В случае FMC/FTD, могут ли такие трафики “внутри-в-один” анализироваться IPS/IDS/URL/AMP?
Я слишком далек от практики, чтобы сказать, может ли FTD обеспечивать безопасность на трафике VPN, который идет внутри-снаружи, но я могу сказать, что избежание неэффективного маршрутизации интернет-трафика пользователей — причина существования технологии SSE.
Даже если трафик идет внутри-снаружи, он все равно проходит через фаервол. На самом деле, это работает только потому, что у вас есть правило, разрешающее этим VPN-пользователям все, или ваше правило по умолчанию разрешено. Если хотите ограничить доступ, измените правило по умолчанию на запрет и начните создавать правила для вашего трафика.
Если у вас лучшее управление интернетом на вашей сети, вы можете перенести VPN-трафик внутрь сети, переопределив маршрут ASA для VPN-клиентов, например:
route inside 0.0.0.0 0.0.0.0 <ip.of.next.hop> tunneled
В моей организации мы разделяем трафик Teams для клиентов AnyConnect с помощью динамического списка исключений и туннелируем все остальное. Когда трафик достигает ASA, он маршрутизируется внутри сети и следует по умолчанию через Palo, что обеспечивает отличный контроль, видимость и регистрацию их трафика.
Обратите внимание, что это переопределяет только маршрут 0.0.0.0, и если у ASA есть другие префиксы в RIB, он будет следовать за ними как обычно, и вы не можете добавить “tunneled” к префиксу, отличному от 0.0.0.0.
- Раньше мы так делали, перенаправляя наши трафики через ASA и модуль SFR. На этом мы также принуждали все локальные подсети отправлять в головной офис, где они были заблокированы. Это делается для того, чтобы пользователи не могли получить доступ к локальной сети. Это кажется экстремальным, но так мы поступали.
Что касается FTD, у нас только модуль SFR, поэтому не могу сказать о полном FTD, но на модуле SFR весь трафик пропускается, у нас также есть глобальный блок как часть системы разведки безопасности.
- Теперь мы перешли на Umbrella, и многие пользователи перенаправляют трафик через HQ. Umbrella отлично работает.
Прикрепите ваш ACL к VPN-фильтру в групповой политике. Прикрепление его к внешнему интерфейсу ничего не делает.
*редакция - не забудьте разрешить доступ к вашим внутренним сетям для таких вещей, как DNS, иначе при разрешении только HTTP/HTTPS у пользователей не получится решения имен хостов. Обычно я разрешаю весь доступ внутри (permit ip к вашему внутреннему адресу), но можно настроить это очень точно или максимально ограниченно.
Вы абсолютно правы, у нас уже есть соответствующий ACL в ASA, например:
access-list outside_access_in extended permit tcp object RemoteUsers any object-group HTTP
access-list outside_access_in extended deny ip object RemoteUsers any log
Таким образом, мы уже разрешаем только порты, указанные в группе HTTP, и блокируем все остальные.
Но это лучший практический подход?
Правило по умолчанию должно быть блоком, ха-ха.
Лучшая практика для чего? Вы спрашиваете, стоит ли блокировать весь трафик, кроме HTTP? Тогда нужно блокировать всё, кроме HTTP, HTTPS и QUIC.
Вы удивитесь, сколько мест имеют правило по умолчанию с разрешением или вставляют ACL перед правилом по умолчанию, чтобы разрешить всё.
Мои два списка ACL уже делают “блокировать весь трафик, кроме HTTP”. Просто интересно, делают ли кто-то иначе… ха-ха.