Thursday, November 15th, 2018

Настраиваемый шлюз приложений Microsoft Intelligent Application Gateway 2007 (IAG 2007) (Часть 1)

Published on Февраль 11, 2009 by   ·   Комментариев нет

Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:

Многие из вас возможно знают, что недавно компания 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». На самом деле, идеей я обязан Уэйну Смолу, который на одном из моих семинаров сказал, что это было бы неплохо.

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

  • История SSL VPN
  • Чем обладает SSL VPN

История SSL VPN

Сети SSL VPN появились для решения одной проблемы: трудность и сложность предоставления сотрудникам удаленного доступа к приложениям, расположенным в корпоративной сети. Старейшим решением является сервер удаленного коммутируемого доступа, который был страшно медленным, а поддержка коммутируемого доступа в масштабе предприятия могло быть очень дорогим проектом. Если вы работаете в данной сфере еще с тех времен, когда Интернет не получил такого широкого распространения, вы наверняка с «нежностью» вспоминаете RAS-модемы.

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

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

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

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

С учетом всех этих проблем и разрабатывалась концепция SSL VPN. Основными целями SSL VPN были:

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

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

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

  • Устройства типа простого обратного прокси с поддержкой только web-приложений. Примером служит возможность web-публикации 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 решили, что им нужен удаленный доступ к общим файлам без использования 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

Рисунок 1

Сегодня каждое решение SSL VPN масштаба предприятия обладает следующими возможностями:

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

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

Резюме

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

www.isaserver.org


Смотрите также:

Tags: , , , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]