Microsoft Intelligent Application Gateway 2007 (IAG 2007), часть 1: SSL VPN 101

Как многие из вас, кто читал информационный бюллетень ISAserver.org, возможно, знают, что Microsoft недавно выпустила свое предложение SSL VPN, известное как Intelligent Application Gateway 2007 (IAG 2007). IAG 2007 предоставляет услуги SSL VPN, которых очень не хватало в продуктах Microsoft для обеспечения безопасности. С введением IAG 2007 у Microsoft появилась полная линейка продуктов для обеспечения безопасности на границе сети, для защиты серверных служб и для защиты клиентов.

Однако, прежде чем вы сможете получить хорошее представление о том, что может предложить вам IAG 2007, вам необходимо ознакомиться с SSL VPN. Поскольку сетевые администраторы Microsoft могут не иметь опыта работы с концепцией SSL VPN, я подумал, что было бы неплохо предоставить курс «SSL VPN 101» для всех вас. На самом деле, я должен отдать должное Уэйну Смоллу из SBS за эту идею, поскольку он упомянул, что это было бы хорошей идеей на недавнем занятии IAG 2007, которое я недавно проводил.

В этой статье мы обсудим следующее:

• История SSL VPN
• Что есть у каждой SSL VPN

История SSL VPN

SSL VPN были введены для решения проблемы. Проблема заключалась в сложности и сложности предоставления сотрудникам удаленного доступа к корпоративным размещенным приложениям. Самым старым решением этой проблемы был RAS-сервер удаленного доступа. Проблема с коммутируемым удаленным доступом RAS заключалась в том, что он был мучительно медленным, а поддержка коммутируемого решения для всего предприятия могла быть очень дорогим предложением. Если вы занимаетесь этим бизнесом еще до появления Интернета, вы будете вспоминать свои модемные банки RAS с любовью (не очень!).

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

Сначала казалось, что технология VPN — идеальное решение. Используя VPN-сервер Microsoft со службой Windows NT RRAS, мы могли подключаться с помощью PPTP (и позже L2TP/IPSec) и получать полный доступ к корпоративной сети точно так же, как когда мы сидели перед нашими корпоративными настольными компьютерами. При подключении через быстрое подключение к Интернету (например, по линии ISDN 128 кбит/с) качество связи было намного лучше, чем при подключении через модем. Ситуация стала еще лучше, когда из дома, гостиниц и конференц-центров стали доступны настоящие высокоскоростные соединения от 1,5 Мбит/с и выше.

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

• Пользователям приходилось не забывать щелкать значок VPN на рабочем столе перед запуском своих приложений, таких как Outlook или клиентское приложение базы данных. Пользователи ожидают, что все будет «просто работать»
• Конфигурация VPN-клиента может быть сложной. Пользователи звонили в службу поддержки, потому что не могли понять, как правильно настроить программное обеспечение VPN-клиента.
• Даже если VPN-клиент настроен правильно, в некоторых средах он может не работать. Эта переменная функциональность программного обеспечения VPN-клиента привела к еще большему количеству обращений в службу поддержки и увеличению расходов.
• VPN-клиент должен иметь идентификатор сети, отличный от сети назначения, которую вызывает VPN-клиент. Когда VPN-клиент находится в сети с идентификатором, совпадающим с сетью назначения, пакеты не могут правильно маршрутизироваться через VPN. Это становилось все более проблематичным, поскольку отели начали предоставлять клиентам Интернет-услуги, но часто использовали те же идентификаторы сети с частными адресами, которые используют компании.
• Поскольку PPTP имеет проблемы с безопасностью, когда сложные пароли не используются, L2TP/IPSec получило более широкое распространение. Проблема в том, что для корректной работы IPSec все устройства, участвующие в соединении, должны поддерживать NAT Traversal для IPSec, так как NAT в нормальных условиях нарушит IPSec. Не все устройства поддерживали обход NAT, и даже группы Windows XP SP2 и Windows Vista внесли свой вклад в эту проблему, сразу же отключив обход NAT для этих клиентов (это можно исправить с помощью записи в реестре).
• Традиционное подключение к VPN обеспечивало полный доступ к сети после установления VPN-подключения. Таким образом, VPN-подключение было универсальным обходным портом брандмауэра, через который внешние пользователи могли делиться своими вирусами, червями и другими эксплойтами с корпоративной сетью. Это по-прежнему остается серьезной проблемой, если только вы не используете расширенный VPN-сервер и брандмауэр, такой как брандмауэр ISA 2004 или ISA 2006.
• Пользователи, находящиеся за брандмауэрами, должны были надеяться и молиться, чтобы на этом брандмауэре был либо редактор PPTP NAT (что часто не случалось), либо чтобы были открыты порты L2TP/IPSec NAT-T. Во многих случаях были открыты только TCP 80 и 443. Хотя никогда не было серьезной причины для ограничения исходящего доступа только этими портами, это было и остается популярным грешком для сетевых операторов в отелях и конференц-центрах.

Учитывая все эти проблемы, родилась концепция SSL VPN. Первоначальные цели SSL VPN заключались в том, чтобы обеспечить:

• Беспрепятственный доступ через брандмауэры
• Решение для удаленного доступа, которое будет работать из любого места, независимо от наличия устройств NAT.
• «Бесклиентское» решение, поэтому пользователям не нужно устанавливать или настраивать сложное клиентское программное обеспечение VPN.

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

Однако по мере того, как SSL VPN начинал немного развиваться, вы могли обнаружить, что существует по существу четыре типа доступа или типов устройств (некоторые устройства обеспечивают более одного типа SSL VPN). Этими четырьмя типами SSL VPN были:

• Простые обратные прокси-устройства, поддерживающие только веб-приложения. Примером этого может служить набор функций веб-публикации брандмауэра ISA. В этой реализации вообще не было ничего, что могло бы предложить что-то, связанное с VPN. Однако эти устройства поддерживали предварительную аутентификацию и перезапись URL-адресов, что делало некоторые из них несколько более безопасными, чем решение с обратным NAT.
• Туннелирование протокола. Клиенты и шлюзы, поддерживающие туннелирование протоколов приложений в сеансе SSL. Примером этого типа SSL VPN может быть клиент Outlook RPC/HTTP и прокси-сервер RPC/HTTP. Клиент Outlook RPC/HTTP туннелирует вызовы RPC/MAPI в сеансах с шифрованием SSL и перенаправляет их на прокси-сервер RPC/HTTP. Затем прокси-сервер RPC/HTTP детуннелирует соединения RPC/MAPI и перенаправляет их на сервер почтовых ящиков.
• Устройства переадресации сокетов или портов, которые будут устанавливать клиентское программное обеспечение, которое прослушивает вызовы на определенном порту или сокете, перехватывает эти вызовы и перенаправляет их на шлюз SSL VPN по ссылке SSL для детуннелирования. Примером такого типа SSL VPN может быть ситуация, когда на клиенте установлен локальный прокси-сервер SOCKS, настроенный на прием вызовов на TCP-порты 25 и 110 и переадресацию этих подключений на шлюз SSL VPN, где они детуннелируются и перенаправляются на почтовый сервер.
• Настоящие SSL VPN. Эти типы SSL VPN обеспечивают реальный доступ к корпоративной сети на сетевом уровне. Клиентам назначается действительный IP-адрес в корпоративной сети, и все протоколы поддерживаются в двух направлениях между клиентом SSL VPN и хостами в корпоративной сети. Этот тип SSL VPN обеспечивает тот же тип взаимодействия с пользователем, что и традиционные VPN-серверы и протоколы сетевого уровня.

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

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

Многие потенциальные клиенты SSL VPN решили, что им нужен удаленный доступ к общим файловым ресурсам без использования VPN-подключения на уровне сети. Они знали, что SMB/CIFS не является хорошим протоколом для работы в Интернете, поэтому решили, что именно для этого следует использовать SSL VPN. Другие люди думали, что SSL VPN — это то же самое, что и VPN на сетевом уровне, но она позволяет вам обойти «ограничительные» брандмауэры (разве не для этого предназначены брандмауэры — ограничивать доступ?). Почему это называется VPN, если это на самом деле не VPN?

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

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

Парни из SSL VPN быстро обнаружили, что, решив ряд проблем, связанных с удаленным доступом, они расширили и без того широкую дыру в безопасности, созданную традиционными «аппаратными» поставщиками VPN. С появлением SSL VPN все больше и больше пользователей могли получить доступ к корпоративной сети, что открывало все больше и больше незащищенных соединений с корпоративной сетью. Это быстро стало невыносимой ситуацией и стало еще одной проблемой, которую пришлось решать ребятам из SSL VPN.

Что есть у каждой SSL VPN

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

фигура 1

Каждое корпоративное решение SSL VPN сегодня должно включать следующие функции:

• Туннелирование Все шлюзы SSL VPN должны иметь возможность туннелировать как веб-приложения, так и не-веб-приложения, а также протоколы прикладного уровня в сеансе SSL.
• Безопасность на стороне клиента Все шлюзы SSL VPN должны обеспечивать некоторый тип обнаружения конечных точек, который обеспечивает средства оценки текущего состояния работоспособности клиентской системы SSL VPN. Цель состоит в том, чтобы предотвратить подключение к сети систем, которые не соответствуют рекомендациям политики сетевой безопасности. Безопасность конечной точки особенно важна в сценарии SSL VPN, потому что пользователи могут подключаться буквально из любого места, от компьютера друзей, который также используют дети, до киоска за доллар в час в местном водопое. Нельзя считать само собой разумеющимся, что клиенты SSL VPN не были заражены или не запускались злоумышленниками.
• Предварительная аутентификация Внешние пользователи никогда не должны иметь возможности создавать прямой сеанс с корпоративным сервером. Даже для попыток аутентификации. Жизнеспособный шлюз SSL VPN должен иметь возможность предварительно аутентифицировать пользователей на шлюзе, а затем, после аутентификации и авторизации этого пользователя, делегировать эти учетные данные опубликованному веб-серверу. Также должна быть поддержка аутентификации не-веб-протоколов.
• Авторизация Шлюз SSL VPN должен иметь возможность разрешать и запрещать доступ к одному или обоим порталам или приложениям, размещенным на портале SSL VPN.
• Пользовательский портал Пользовательский портал — это веб-страница, которую пользователи посещают для доступа к приложениям, которые становятся доступными для пользователей SSL VPN после входа на портал. Пользователям нужно только запомнить URL-адрес страницы портала. Как только они перейдут на страницу портала, все их приложения появятся в списке на этой странице. Пользователям не нужно запоминать конкретные URL-адреса для каждого приложения, к которому им нужен удаленный доступ.
• Проверка прикладного уровня Чтобы решение можно было квалифицировать как SSL VPN-шлюз корпоративного уровня, оно должно обеспечивать некоторую форму проверки прикладного уровня. Проверка на уровне приложения может быть ограничена только соединением HTTP/HTTPS, или более надежные решения будут включать проверку на уровне приложения для других протоколов, таких как SMTP, POP3, RPC, IMAP4 и других широко используемых протоколов, которые туннелируются к шлюзу SSL VPN.

Как видите, концепция SSL VPN сильно изменилась и развилась с момента ее первоначального представления в виде простого обратного веб-прокси-сервера. Сегодняшняя современная SSL VPN предоставляет все функции, которые определяют SSL VPN: обратный прокси-сервер, туннелирование веб-протоколов и не-веб-протоколов, а также подлинное подключение на сетевом уровне через сеанс SSL. Более того, современная SSL VPN обеспечивает не только конфиденциальность соединения, но и некоторый уровень безопасности благодаря проверке на уровне приложений.

Резюме

В этой статье я предоставил вам краткий обзор SSL VPN, начиная с краткой истории SSL VPN и их ранних определений и заканчивая SSL VPN, которые мы видим сегодня. В следующей статье из этой серии статей о SSL VPN я расскажу о IAG 2007, который построен на базе усиленного Windows Server 2003 с брандмауэром ISA Firewall для обеспечения его безопасности. В этой статье я укажу, что я считаю наиболее важными функциями и технологиями, и укажу, чем IAG 2007 отличается от конкурентов в области SSL VPN.