Безопасность VPN-клиентов, часть 2: принудительное применение политики брандмауэра к VPN-клиентам
Безопасность VPN-клиента, часть 2:
Принудительное применение политики брандмауэра к VPN-клиентам
Томас Шиндер, доктор медицины
Большинство из нас создали VPN, чтобы клиенты из внешней сети могли получить безопасный доступ к частной сети. Мы обычно думаем о VPN-сервере как об устройстве безопасности, которое защищает внутреннюю сеть от внешних атак. Но так ли это на самом деле? На самом деле VPN-сервер — это просто сервер удаленного доступа, который позволяет клиентам RAS использовать Интернет вместо телефонной сети общего пользования в качестве транзитной сети. Объединение VPN-сервера не обеспечивает автоматически безопасность подключений удаленного доступа.
Одна из самых важных вещей, которую вы можете сделать для защиты клиентских VPN-подключений с удаленным доступом, — это предотвратить раздельное туннелирование. По умолчанию новый шлюз по умолчанию устанавливается, когда клиент Microsoft VPN подключается к VPN-серверу. Этот новый шлюз по умолчанию направляет все пакеты, не находящиеся в сети клиента, напрямую подключенной к VPN-серверу. Это предотвращает возможность подключения клиента к Интернету через подключение к интернет-провайдеру на время вызова VPN.
Это создает проблемы для пользователей, которые хотят подключаться к интернет-сайтам и службам, оставаясь при этом подключенными к VPN. Если VPN-клиент подключен к VPN-серверу, совмещенному с ISA Server, VPN-клиент не сможет подключиться к Интернет-службам при использовании настроек по умолчанию.
Это хорошая конфигурация безопасности, поскольку она позволяет поддерживать безопасность сети на протяжении всего VPN-вызова. Почему вы позволяете VPN-клиенту обходить вашу политику брандмауэра, в то же время ожидая, что все остальные сетевые клиенты будут контролироваться этой политикой? VPN-клиент обычно имеет тот же уровень доступа, что и любой другой узел внутренней сети, поэтому имеет смысл применять ту же политику для VPN-соединений. Вы не позволяете пользователям приносить модемы и подключать их к своим рабочим столам (что позволит им обходить брандмауэр), так почему вы позволяете клиентам VPN выполнять раздельное туннелирование?
Раздельное туннелирование разрешено или запрещено в зависимости от настроек конфигурации VPN-клиента. Ключевым параметром клиента является использование шлюза по умолчанию в удаленной сети. Если этот флажок установлен, раздельное туннелирование отключено. Если флажок не установлен, клиент может получить доступ в Интернет через своего интернет-провайдера (или другое прямое соединение) и в корпоративную сеть через интерфейс VPN. Дополнительные сведения о последствиях раздельного туннелирования и безопасности VPN-клиентов см. на странице http://www.isaserver.org/tutorials/VPN_Client_Security_Issues.html.
Что делать, если вы хотите разрешить VPN-клиентам доступ в Интернет? Единственное приемлемое решение — отключить раздельное туннелирование и заставить их подключаться к Интернету через ISA Server. Относительно легко настроить VPN-клиентов в качестве клиентов веб-прокси. Клиент VPN/веб-прокси может получить доступ к протоколам HTTP, HTTPS, FTP с туннелированием HTTP и Gopher через службу веб-прокси сервера ISA. Вы можете найти подробности этой конфигурации по адресу http://www.isaserver.org/tutorials/Solving_the_Mystery_of_the_VPNRASWeb_Proxy_Client.html.
Все становится немного сложнее, когда вы хотите разрешить доступ к другим протоколам. Давайте рассмотрим два разных сценария: когда VPN-сервер расположен рядом с ISA-сервером, и когда VPN-сервер расположен на машине, отдельной от ISA-сервера.
============================
Совместно расположенные VPN и ISA Server
============================
Очень легко настроить компьютер с ISA Server в качестве VPN-сервера. Все, что вам нужно сделать, это запустить мастер VPN-сервера из консоли управления ISA. Просто щелкните правой кнопкой мыши узел «Конфигурация сети» на левой панели консоли и выберите команду « Разрешить подключения VPN-клиента». Следуйте инструкциям мастера, и служба маршрутизации и удаленного доступа будет запущена и настроена для вас. После того, как мастер запустит RRAS, необходимо выполнить несколько вспомогательных действий, но большую часть работы он выполняет. Подробнее о настройке ISA Server в качестве VPN-сервера см. на странице http://www.isaserver.org/tutorials/Configuring_ISA_Server_For_Inbound_VPN_Calls.html.
Возможно, вы уже пробовали это и обнаружили, что клиенты VPN не могут подключиться к Интернету через ISA Server. Причина этого в том, что клиенты VPN не могут работать как клиенты SecureNAT. У вас нет возможности настроить VPN-клиент на использование внутреннего интерфейса ISA Server в качестве шлюза по умолчанию. Шлюз по умолчанию уже установлен, когда VPN-клиент подключается, и это явно не внутренний интерфейс ISA Server. Хотя детали немного сложнее, факт остается фактом: решения этой проблемы нет; вы никогда не сделаете VPN-клиент клиентом SecureNAT.
Единственный другой вариант, который у вас есть, — настроить VPN-клиентов как клиентов брандмауэра. Это легко сделать, когда клиентский компьютер VPN может быть подключен к внутренней сети, так как вы можете установить клиент брандмауэра, когда компьютер подключен к локальной сети.
Немного сложнее настроить VPN-клиент в качестве клиента брандмауэра, когда машина никогда не подключается к корпоративной локальной сети. Обычно вы сталкиваетесь с такой ситуацией, когда VPN-клиенты представляют собой настольные компьютеры, подключенные к удаленной локальной сети. Это по-прежнему можно выполнить, но это нужно делать при активном VPN-подключении, а VPN-клиент должен иметь доступ к общему ресурсу mspclnt на ISA-сервере (или где-либо еще, где этот общий ресурс может быть установлен). Ваша инфраструктура разрешения имен должна быть на месте, и она должна работать, если вы ожидаете успешного подключения к общему ресурсу mspclnt.
Проблемы с разрешением имен для VPN-клиента часто вызывают проблемы. Клиент брандмауэра должен иметь возможность преобразовать имя ISA-сервера во внутренний IP-адрес ISA-сервера. Вы можете подумать, что настройки WINS и DNS-сервера будет достаточно, но я обнаружил, что результаты несколько противоречивы, даже когда я изо всех сил старался создать ссылочную зону WINS в DNS. Лучшее решение — настроить VPN-клиент на получение адреса DNS-сервера, который может преобразовать имя внутреннего интерфейса ISA-сервера в его внутренний IP-адрес.
Если вы решили использовать WINS или DNS, обратите особое внимание на внешний вид значка клиента брандмауэра на панели задач. Проведите некоторое тестирование, используя FTP-приложение командной строки. Если вы не можете подключиться и не видите ЗЕЛЕНУЮ стрелку, указывающую вверх, наведите указатель мыши на значок клиента брандмауэра на панели задач. Если вы видите сообщение о том, что ISA Server не может быть найден, вы знаете, что столкнулись с проблемой разрешения имен.
Проблема с DNS-клиентами заключается в том, что если они настроены на использование одного имени метки для ISA-сервера в конфигурации клиента брандмауэра (как показано на рисунке ниже), то им придется квалифицировать запрос перед его отправкой в DNS. сервер. Когда клиентам брандмауэра предоставляется одно имя метки, клиент DNS должен попытаться полностью квалифицировать запрос. Обычно это не проблема в корпоративной сети, если DNS-клиенты настроены на первичное доменное имя DNS, которое они добавляют к неполным запросам. Но клиенты VPN часто настраиваются с другим доменным именем или вообще без доменного имени. В этом случае попытка подключения к службе брандмауэра ISA Server будет неудачной. Помните об этих проблемах при устранении проблем с разрешением имен для удаленных клиентов VPN.
Еще одна вещь, на которую следует обратить внимание, — это параметр «Автоматически определять сервер ISA» (см. рисунок ниже). Вы не можете использовать параметр DHCP для назначения записи WPAD клиенту VPN (поскольку агент DHCP-ретрансляции не работает после установки ISA Server), и клиент VPN должен иметь возможность корректно разрешать псевдоним wpad, если вы используете DNS. Клиент будет использовать свой собственный первичный DNS-суффикс для полного уточнения записи wpad, поэтому это может стать серьезной проблемой для ваших VPN-клиентов. Это можно решить с помощью записи в файле HOSTS, как описано ниже.
Если вы не хотите возиться с разрешением имен через WINS или DNS, вы можете использовать один из двух надежных методов. Вы можете настроить настройку клиента брандмауэра для использования IP-адреса внутреннего интерфейса ISA-сервера (см. рисунок ниже) или настроить запись файла HOSTS, которая включает полное доменное имя ISA-сервера и внутренний IP-адрес ISA-сервера.. К сожалению, ни один из этих вариантов не очень хорошо масштабируется, хотя вы можете легко предоставить пользователям файл HOSTS для копирования в соответствующее место (SYSTEMROOTsystem32driversetc).
Вы сможете подключаться к Интернету по любому протоколу, как только клиент брандмауэра будет установлен на клиенте VPN. Обратите внимание, что вы должны отключить клиент брандмауэра при установке VPN-подключения. Если вы оставите клиент брандмауэра включенным при попытке установить VPN-подключение, попытка подключения завершится ошибкой.
============================
VPN-сервер на выделенном сервере RRAS
============================
Ситуация отличается, когда VPN-клиент подключается к VPN-серверу, расположенному не на ISA-сервере. В этом случае на VPN-клиенте будет работать «псевдо» конфигурация клиента SecureNAT. Я называю это «псевдо» клиентом SecureNAT, потому что вы не настраиваете клиент VPN как клиент SecureNAT, потому что сервер VPN автоматически назначает клиенту VPN шлюз по умолчанию. Но это будет работать , если VPN-сервер настроен как клиент SecureNAT для ISA-сервера.
VPN-клиент в этом сценарии может получить доступ к протоколам, отличным от веб-прокси, поскольку VPN-сервер отвечает за маршрутизацию запросов, отправленных ему от VPN-клиента. VPN-сервер не имеет специальной записи в таблице маршрутизации для поддержки запросов, связанных с Интернетом, но у него есть шлюз по умолчанию. Когда VPN-сервер настроен на использование ISA-сервера в качестве шлюза по умолчанию, он может направлять эти связанные с Интернетом запросы на ISA-сервер и пересылать ответы обратно VPN-клиенту. Обратите внимание, что серверу VPN не обязательно использовать внутренний интерфейс ISA Server в качестве шлюза по умолчанию. Единственное требование состоит в том, чтобы он был настроен как клиент SecureNAT.
Хотя эта настройка кажется простой, подумайте о том, как вы настраиваете интернет-интерфейс на сервере VPN. Поскольку VPN-сервер должен быть настроен как клиент SecureNAT, его нельзя использовать в качестве сервера доступа в Интернет. Вам придется использовать Интернет-соединение только для входящих запросов от VPN-клиентов или других «известных» клиентов, для которых вы можете создать записи в таблице маршрутизации. Если у вас есть загруженный VPN-сервер, это не проблема, поскольку вы можете использовать всю доступную пропускную способность. Но вам не повезло, если вы хотите использовать полосу пропускания, не используемую VPN-клиентами, для общего доступа в Интернет.
Еще раз, способ обойти эту проблему состоит в том, чтобы сделать VPN-клиентов клиентами брандмауэра. Когда вы делаете VPN-клиенты клиентами брандмауэра, вы можете изменить настройку шлюза по умолчанию на VPN-сервере и использовать его для общего доступа в Интернет. Вы также можете воспользоваться другими преимуществами клиента брандмауэра, такими как доступ к сложным протоколам и более высокая производительность.
Проблемы с разрешением имен такие же, как и при подключении к совмещенному серверу VPN/ISA. Вы должны быть уверены, что настроили адреса WINS и DNS-сервера, которые могут правильно разрешить имя внутреннего интерфейса ISA-сервера, или используйте файл HOSTS для упрощения разрешения имен, если у вас нет собственного опыта работы с DNS.
ПРИМЕЧАНИЕ:
Некоторые сетевые администраторы писали мне о проблемах с назначением DNS-сервера для VPN-клиентов. Вот одно из таких сообщений:
«Я заметил странное поведение в отношении назначений DNS-серверов VPN. Вот моя головоломка. При первом VPN-подключении после коммутируемого доступа я выполнил «nslookup», чтобы увидеть, какой DNS-сервер используется для разрешения имен. Это был DNS-сервер нашего коммутируемого провайдера, в данном случае AT&T. Если я отключусь от VPN, а затем снова подключусь к ней и выполню еще один «nslookup», результаты будут другими. Теперь используемый DNS-сервер является нашим сетевым DNS-сервером! То же самое происходит при каждом последующем подключении к нашему VPN-серверу, пока компьютер не будет перезагружен. Затем снова повторяется та же картина».
У меня нет решения этой проблемы, и я не исследовал проблему подробно, но если у вас есть какая-либо информация по этому поводу, сообщите мне об этом по адресу [email protected], и я обновлю эту статью, добавив вашу информацию.
============================
Вывод
============================
Безопасность VPN не ограничивается установкой и настройкой VPN-сервера. Предотвращение раздельного туннелирования для VPN-клиентов имеет решающее значение для безопасной настройки VPN-клиент/сервер. Вы по-прежнему можете разрешить VPN-клиентам доступ в Интернет, просто они должны делать это через ISA Server. Если клиентам VPN требуется доступ только к протоколам веб-прокси (HTTPS, HTTPS и FTP с туннелированием HTTP), вы можете настроить VPN-клиент как клиент веб-прокси. Если VPN-клиенту требуется доступ ко всему спектру интернет-сервисов, вам следует рассмотреть возможность установки клиента брандмауэра на VPN-клиенте. VPN-клиенты имеют разные уровни доступа в Интернет в зависимости от того, совмещен ли VPN-сервер с ISA-сервером.
Надеюсь, вам понравилась эта статья, и вы нашли в ней что-то, что вы можете применить в своей собственной сети. Если у вас есть какие-либо вопросы по поводу того, что я обсуждал в этой статье, зайдите на http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=13;t=001201 и разместите сообщение. Я буду проинформирован о вашем сообщении и отвечу на ваши вопросы как можно скорее. Спасибо! -Том