Безопасность VPN-клиента, часть 1: проблемы раздельного туннелирования

Безопасность VPN-клиента, часть 1:
Проблемы с раздельным туннелированием

Томас Шиндер, доктор медицины

Если вы следили за моими статьями здесь, на www.isaserver.org, вы, возможно, заметили, что я довольно мало написал о VPN. Причина этого в том, что виртуальные частные сети являются неотъемлемой частью вашей инфраструктуры безопасности и прекрасно работают с ISA Server. Вы видели, как мастеры ISA Server делают настройку VPN-сервера или VPN-шлюза несложной задачей.

Но есть проблема с VPN, которая может доставить вам массу неприятностей, если вы не знаете, что происходит. Эта проблема связана с тем, как настроены клиенты VPN. Конфигурация клиентов Microsoft VPN по умолчанию достаточно безопасна. Если вы или ваши пользователи не будете возиться с конфигурацией по умолчанию, вы будете в хорошей форме. Вы столкнетесь с проблемами только при изменении конфигурации по умолчанию. Иногда вам нужно внести это изменение, а иногда это изменение делается для того, чтобы подорвать вашу сетевую безопасность.

Сила опции «использовать шлюз по умолчанию в удаленной сети»

Важным параметром конфигурации VPN-клиента является использование шлюза по умолчанию в удаленной сети. Этот параметр отображается в разных местах в зависимости от используемой версии клиента Microsoft VPN. На компьютере с Windows XP Professional вы найдете это следующим образом:

1. Щелкните правой кнопкой мыши значок «Мое сетевое окружение» на рабочем столе и выберите «Свойства».
   
2. Щелкните правой кнопкой мыши клиентское соединение VPN в окне «Сетевые подключения» и выберите «Свойства».
   
3. Перейдите на вкладку «Сеть», затем щелкните запись «Протокол Интернета (TCP/IP)» и нажмите кнопку « Свойства».
   
4. На вкладке «Общие » диалогового окна «Свойства протокола Интернета (TCP/IP)» нажмите кнопку «Дополнительно».
   
5. На вкладке «Общие» диалогового окна «Дополнительные параметры TCP/IP» обратите внимание на параметр « Использовать шлюз по умолчанию в удаленной сети».

Это очень важный параметр, потому что он может иметь значение между наличием безопасного подключения VPN-клиента или предоставлением вашим VPN-клиентам возможности стать хакерскими шлюзами.

Маршрут по умолчанию VPN-клиента

По умолчанию параметр Использовать шлюз по умолчанию в удаленной сети включен. Когда VPN-клиент устанавливает связь с VPN-сервером, на VPN-клиенте создается новый маршрут по умолчанию, который появляется в таблице маршрутизации VPN-клиента. Вы можете просмотреть новый маршрут, открыв командную строку и введя команду печати маршрута. Этот новый маршрут по умолчанию заменяет старый шлюз по умолчанию, который мог быть установлен на VPN-клиенте при установлении коммутируемого соединения. Если используется коммутируемое соединение, шлюзом по умолчанию обычно является маршрутизатор поставщика услуг Интернета. Это позволяет клиентам коммутируемого доступа получать доступ в Интернет.

Однако при добавлении нового маршрута по умолчанию VPN-клиенты с параметром Использовать шлюз по умолчанию в удаленной сети не могут получить доступ к Интернету, поскольку теперь клиенты используют интерфейс VPN для маршрутизации пакетов в удаленные (нелокальные) сети. Как администратор VPN, это именно то, что вам нужно. Вы не хотите, чтобы VPN-клиенты могли одновременно получать доступ к вашей частной сети и Интернету. Это создает значительный риск для безопасности, поскольку клиент VPN может стать шлюзом между Интернетом и частной сетью.

Хотя это наилучшая конфигурация для вас и безопасности вашей сети, она приведет к большому количеству обращений в службу поддержки. Пользователи VPN будут громко жаловаться, что они не могут просматривать веб-страницы, подключаться к своим секс-чатам AOL и выполнять любые другие неприятные действия, которые вы должным образом запретили им делать через корпоративный сервер ISA.

Настройка VPN-клиентов для использования ISA Server

Лучшее решение этой проблемы — настроить VPN-клиентов на использование ISA Server в качестве прокси-сервера. Это можно сделать, настроив браузер на клиенте VPN на использование внутреннего IP-адреса ISA-сервера для подключения веб-прокси клиента VPN. Выполните следующие шаги в браузере VPN-клиентов Internet Explorer, чтобы разрешить VPN-клиенту использовать ISA Server в качестве своего веб-прокси:

1. Откройте Internet Explorer, откройте меню «Сервис» и выберите «Свойства обозревателя».
   
2. Нажмите на вкладку Подключения. В поле со списком Параметры удаленного доступа и виртуальной частной сети выберите соединение, представляющее коннектоид VPN. Затем нажмите кнопку «Настройки».

3. В диалоговом окне « Настройки» установите флажок « Использовать прокси-сервер для этого подключения ». Введите IP-адрес внутреннего интерфейса прокси-сервера в текстовое поле Address и 8080 в текстовое поле Port. Нажмите «ОК», а затем снова нажмите «ОК».

Теперь браузер настроен на использование службы веб-прокси. Возможно, вам удастся обойтись без использования параметра «Автоматически определять параметры», если доменное имя машины установлено на домен в вашей внутренней сети (и у вас есть запись WPAD, настроенная для этого домена). Забудьте об использовании DHCP. Чтобы получить хорошее объяснение того, почему использование DHCP является беспроигрышным вариантом, см. Q312864.

Доступ к другим службам Интернета, которые не работают через службу веб-прокси, таким как NNTP, SMTP и ужасный IRC, требует использования клиента брандмауэра на клиентской машине VPN. Вы не можете настроить VPN-клиентов как клиентов SecureNAT, используя внутренний интерфейс ISA Server в качестве шлюза по умолчанию, поскольку у клиентов уже есть маршрут по умолчанию, созданный для них VPN-сервером. Если вы замените этот маршрут по умолчанию вручную, вы не сможете использовать ссылку VPN для доступа к корпоративным сетевым ресурсам через VPN.

Примечание:

Вы можете настроить VPN-клиентов как клиентов SecureNAT, если клиенты вызывают VPN-сервер, который НЕ является ISA-сервером. Если VPN-сервер настроен на использование внутреннего интерфейса ISA-сервера в качестве шлюза по умолчанию, клиенты VPN/RAS смогут подключаться к Интернету через ISA-сервер.

Работа с хныкающими пользователями

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

Затем они также могут сами вносить эти изменения в конфигурацию. Имейте в виду, что предоставление пользователям доступа к корпоративной сети с удаленного компьютера является решением для обеспечения безопасности. Если пользователь не может выполнять эти простые задачи, можно ли ему доверить защищенные корпоративные данные?

Действительно, отказ от этих простых шагов настройки безопасности может быть хорошей мерой «надежности безопасности» сотрудника. Если они не могут сделать эти простые вещи для защиты корпоративных информационных ресурсов, то какие другие «сокращения» они используют, чтобы подорвать меры корпоративной безопасности?

Я останавливаюсь на этом моменте, потому что он важен. Я читал много вопросов о том, как автоматизировать или иным образом скрыть очень простые этапы настройки, чтобы позволить клиентам ISA Server работать, чтобы упростить работу или сделать ее более прозрачной для пользователей. Я говорю, забудьте об этом. Если вы не управляете домом для умственно отсталых, вам не нужно делать эти вещи. И если пользователи активно или с помощью пассивно-агрессивных действий пытаются подорвать вашу инфраструктуру безопасности, о них следует сообщить сотруднику корпоративной безопасности и пометить как потенциальную угрозу корпоративной безопасности.

Нет смысла проверять биографические данные сотрудников (при условии, что проверки биографических данных действительно имеют некоторую степень внешней достоверности), если вы решите игнорировать фактические доказательства того, что эти сотрудники представляют угрозу безопасности. Если вы считаете иначе, действуйте с осознанием того, что вы снизили общий уровень сетевой и корпоративной безопасности.

Уничтожить несовместимых пользователей, которые отключили настройку шлюза по умолчанию

Мы сталкиваемся с более серьезными проблемами, если пользователи решат, что они хотят активно использовать сетевую безопасность, отключив параметр «Использовать шлюз по умолчанию в удаленной сети ». Когда пользователи отключают эту опцию, сетевой маршрут добавляется в таблицу маршрутизации VPN-клиента, но это не маршрут по умолчанию. Добавленный маршрут отправляет запросы на идентификатор классовой сети, который VPN-клиент был назначен для своего VPN-интерфейса.

Например, если VPN-клиенту назначен IP-адрес 10.0.1.100, на VPN-клиенте устанавливается маршрут по умолчанию для идентификатора сети 10.0.0.0/8. Все пакеты для этого идентификатора сети (и всех подсетей этого идентификатора сети) отправляются на сервер VPN через интерфейс VPN клиента. Все остальные нелокальные пакеты отправляются на удаленный маршрутизатор провайдера. VPN-клиент теперь имеет прямую связь как с Интернетом, так и с корпоративной сетью и может эффективно стать шлюзом между Интернетом и корпоративной сетью. Вы видите в этом проблему?

Могут быть способы запретить пользователям изменять настройку шлюза. Комплект администрирования диспетчера подключений позволяет создавать коннектоиды VPN, и может быть функция, позволяющая запретить пользователям изменять этот параметр. Я знаю, что на компьютере с Windows XP Professional администратор может создать коннектоид VPN и установить параметр, доступный для всех пользователей. Когда обычный пользователь входит в систему, он не может получить доступ к диалоговому окну «Свойства». Однако, если пользователи настроят свои собственные VPN-коннектоиды, они смогут вносить любые изменения в коннектоид.

Улучшите безопасность VPN-клиента с помощью адресов вне подсети

Возможно, лучшим способом обеспечения безопасности вашей внутренней сети является разработка схемы IP-адресации и маршрутизации таким образом, чтобы, если пользователи могли настроить свои VPN-клиенты так, чтобы они не использовали шлюз по умолчанию в удаленной сети, они все равно выиграли. не иметь доступа ни к чему, кроме ресурсов на самом сервере ISA/VPN.

Лучший способ сделать это — назначить VPN-клиентам IP-адреса вне подсети. IP-адрес вне подсети — это тот, который не относится к тому же сетевому идентификатору, что и внутренний интерфейс ISA/VPN-сервера. Например, внутренний интерфейс сервера ISA/VPN подключен к сети с идентификатором 10.0.0.0/16, а клиентам VPN назначаются IP-адреса в диапазоне 169.254.0.0/16. При такой настройке VPN-клиенты, которые настроены не использовать ISA/VPN-сервер в качестве своего шлюза по умолчанию, смогут получить доступ к ресурсам на ISA/VPN-сервере, но не будут иметь доступа к ресурсам где-либо еще во внутренней сети.

Причина этого в том, что когда клиент настроен не использовать шлюз по умолчанию в удаленной сети, фактический шлюз по умолчанию на клиенте указывает на провайдера (Интернет). Таким образом, любые нелокальные запросы (в том числе для сетевого идентификатора 10.0.0.0/16) будут перенаправлены в Интернет, что явно не сработает. Несмотря на то, что сервер ISA/VPN содержит надлежащие записи в таблице маршрутизации для пересылки запросов на все идентификаторы сети во внутренней сети, VPN-клиент вне подсети не сможет воспользоваться ими, поскольку он не использует ISA/VPN. сервер в качестве шлюза по умолчанию.

Существует еще одно преимущество использования IP-адресов вне подсети для клиентов VPN. Рассмотрим следующий сценарий:

Клиент VPN настроен так, чтобы не использовать шлюз по умолчанию в удаленной сети. Однако VPN-клиенту назначается IP-адрес, действительный для идентификатора сети, который напрямую подключен к внутреннему интерфейсу ISA/VPN-сервера. Предположим, что сервер ISA/VPN напрямую подключен к сети с идентификатором 10.0.0.0/16, а клиенту VPN назначен IP-адрес 10.0.0.100/8. Почему VPN-клиенту назначается другой идентификатор сети? Причина в том, что VPN-клиенты всегда назначают полноклассовые адреса, поскольку маршрут на VPN-клиенте является классовым маршрутом.

Если вы настроили красивую иерархическую инфраструктуру маршрутизации, идентификаторы вашей внутренней сети и все подсети 10.0.0.0/8 с идентификатором сети 10.0.0.0/16 наверху иерархии. У вас будет несколько идентификаторов подсети, например 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16 и т. д. Это все подсети идентификатора сети classfull 10.0.0.0/8.

Теперь подумайте о том, как бы вы суммировали свой внутренний сетевой идентификатор. Вы должны создать маршрут к сети с идентификатором 10.0.0.0/8, что и делает VPN-сервер для VPN-клиента. Следовательно, даже если VPN-клиент не использует VPN-сервер в качестве шлюза по умолчанию, в этом нет необходимости. Причина этого в том, что все ваши внутренние подсети хорошо суммируются записью таблицы маршрутизации, созданной на клиенте VPN. Если клиенту необходимо получить идентификатор сети 10.1.0.0/16, он может это сделать, поскольку запись в таблице маршрутизации для интерфейса VPN действительна для маршрутизации запросов к этому идентификатору сети через интерфейс VPN.

Именно по этой причине вам следует настраивать VPN-клиенты с адресами вне подсети. В приведенном выше сценарии показано, что если вы не настроите клиенты с адресами вне подсети, эти клиенты могут получить доступ ко всем внутренним подсетям при определенных обстоятельствах. Если бы клиент был назначен на адрес вне подсети, он не смог бы распознать ни одну из внутренних сетей.

Невозможно использовать DHCP для назначения адреса вне подсети

Для оптимального контроля над мошенническими VPN-клиентами следует настроить их на использование IP-адресов вне подсети. У этого подхода есть один недостаток: вы не сможете использовать DHCP для назначения адресов клиентам, так как DHCP-сервер должен находиться в том же сегменте сети, что и внутренний интерфейс ISA-сервера. Клиенты VPN по-прежнему могут получать адреса WINS и DNS-серверов на основе тех, которые установлены на внутреннем интерфейсе ISA/VPN-сервера, так что это не должно создавать особых проблем. Однако, если вам требуется назначение параметров DHCP, вам не повезло.

Примечание:

Если вы настраиваете агент DHCP-ретрансляции на ISA/VPN-сервере, вы можете использовать удаленный DHCP-сервер. Однако мой опыт показывает, что хотя ISA/VPN-сервер может получать IP-адреса с удаленного DHCP-сервера, он не передает параметры DHCP DHCP-клиентам. Я затрудняюсь объяснить эту ситуацию. Если вы знаете ответ, дайте мне знать на [email protected]

Настройка инфраструктуры маршрутизации для поддержки адресов вне подсети

Если вы настраиваете сервер ISA/VPN для назначения адресов вне подсети, вы должны убедиться, что ваша инфраструктура маршрутизации настроена таким образом, чтобы идентификатор сети вне подсети был доступен для всех клиентов внутренней сети (или, по крайней мере, для тех, которые вы хотите, чтобы клиенты VPN подключиться к). Это означает добавление записей таблицы маршрутизации на сетевых маршрутизаторах, которые указывают на внутренний интерфейс сервера ISA/VPN для идентификатора сети вне подсети. Вы можете добавить их вручную или использовать протокол маршрутизации, такой как RIP или OSPF, который сделает всю тяжелую работу.

Использование политик RAS для настройки поведения маршрутизации VPN-клиентов

Последний способ решить проблему маршрутизации трафика с неаутентифицированных машин VPN-клиентами через VPN-подключение — воспользоваться преимуществами политик удаленного доступа. Вы можете настроить профили политики удаленного доступа VPN для использования фильтров пакетов, чтобы ограничить обмен данными только с VPN-клиентом. Это эффективно предотвращает работу VPN-клиента в качестве маршрутизатора между Интернетом и внутренней сетью.

Настройте следующие фильтры пакетов политики удаленного доступа, чтобы ограничить обмен данными только клиентом VPN:

1. Откройте консоль маршрутизации и удаленного доступа.
   
2. Разверните имя своего сервера и щелкните узел Политики удаленного доступа на левой панели консоли.
   
3. Дважды щелкните Политику удаленного доступа VPN-клиента. В этом примере мы не настроили специальную политику удаленного доступа VPN, поэтому будем использовать политику по умолчанию.
   
4. На вкладке «Настройки» нажмите кнопку «Редактировать профиль».

5. В диалоговом окне «Редактировать профиль входящего подключения» щелкните вкладку «IP». Затем нажмите кнопку От клиента.

6. В диалоговом окне «Фильтры ввода» нажмите кнопку «Добавить».
   
7. В диалоговом окне «Добавить IP-фильтр» установите флажок «Сеть назначения», чтобы снять флажок. Оставьте протокол установленным как Any. Нажмите ОК.

8. В диалоговом окне «Фильтры ввода» выберите параметр « Запретить весь трафик, кроме перечисленных ниже». Нажмите ОК.

9. На вкладке IP нажмите кнопку К клиенту.
   
10. В диалоговом окне «Фильтры вывода» нажмите кнопку «Добавить».
    
11. В диалоговом окне «Добавить IP-фильтр» выберите параметр «Исходная сеть» и снимите флажок. Оставьте протокол как Any. Нажмите ОК.

12. Нажмите «ОК» в диалоговом окне «Фильтры вывода».

13. Нажмите «Применить», а затем нажмите «ОК» в диалоговом окне «Редактировать профиль подключения».
    
14. Нажмите «ОК» в диалоговом окне «Свойства» в диалоговом окне «Разрешить доступ, если разрешение на телефонный звонок включено».
    
15. Перезапустите службу маршрутизации и удаленного доступа.

Эти фильтры должны препятствовать маршрутизации запросов через VPN-клиент злоумышленниками из Интернета, которые компрометируют VPN-клиент.

Резюме

Безопасность клиента VPN является неотъемлемой частью успеха вашего сетевого решения VPN. В этой статье мы обсудили несколько методов, которые вы можете использовать, чтобы ваши VPN-клиенты не стали серьезной угрозой безопасности для вашей внутренней сети. В следующих статьях мы обсудим некоторые другие методы, которые вы можете использовать для защиты соединений VPN-клиентов.