Во все большем числе продуктов для построения виртуальных частных сетей используется протокол SSL. Административные издержки невелики, поскольку браузер с поддержкой SSL имеется практически на каждой машине. Но все ли в порядке с безопасностью?

В последние годы стандартом для виртуальных частных сетей (Virtual Private Network, VPN) фактически стал протокол IPSec, серьезную конкуренцию которому и составляет SSL.

УРОВНИ В СТЕКЕ IP

В обоих случаях — как IPSec, так и SSL — речь идет о сетевых протоколах, находящихся, однако, на разных уровнях сетевого стека. IPSec работает на уровне IP и является самостоятельным типом IP, наподобие TCP или UDP (см. Рисунок 1). Если после успешной аутентификации строится зашифрованное соединение, то все типы протоколов над уровнем IP могут запаковываться в пакеты IPSec. На практике чаще всего ими становятся уже упомянутые протоколы TCP и UDP. Поскольку почти все приложения базируются на одном из них, виртуальная частная сеть с IPSec может быть универсальным образом сконфигурирована для любых вариантов.

Рисунок 1. Сетевой стек в случае IPSec (на примере Ethernet). Рисунок 2. Сетевой стек в случае SSL (на примере Ethernet).

Несколько иначе выглядит ситуация с SSL. Хотя SSL в сетевом стеке и расположен над уровнем ТСР, он все еще находится на транспортном уровне (см. Рисунок 2). Поэтому после построения аутентифицированного и зашифрованного соединения все базирующиеся на TCP приложения могут работать по каналу SSL. Коммуникацию по UDP, к примеру при разрешении имени DNS, возможно выполнить с привлечением SSL лишь нетривиальным образом.

БРЕМЯ ИНСТАЛЛЯЦИИ

Построение виртуальной частной сети на базе IPSec — в большинстве случаев дело достаточно затратное. Протокол IPSec принадлежит к стандартному пакету поставки последних версий Windows и UNIX, однако нередко приходится устанавливать и конфигурировать дополнительный клиент VPN. Сюда же добавляются издержки на управление ключами для их обмена при аутентификации и шифровании.

С построением же виртуальной частной сети на базе SSL справится и дилетант, по крайней мере, если он умеет обращаться к желаемым услугам посредством своего браузера. В этом случае требуется лишь установить в сети сервер Web с поддержкой SSL и снабдить его необходимым содержимым для осуществления коммуникации. Если же коммуникация происходит посредством иных механизмов, нежели защищенный при помощи SSL протокол HTTP (HTTPS), то на клиентской машине должно быть установлено дополнительное программное обеспечение. Адаптация уже имеющихся приложений, не базирующихся на HTTP, также ведет к дополнительным затратам, поскольку пользователи вынуждены приобретать и инсталлировать связующее программное обеспечение. Тогда по виртуальной частной сети VPN можно проводить, к примеру, эмуляцию терминалов для мэйнфреймов или AS/400.

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

БЕЗОПАСНОСТЬ МЕТОДОВ

Сравнение достижимых при помощи двух методов уровней безопасности показывает, что каждый из них находит свою область применения, но VPN на базе SSL ни в коем случае не могут рассматриваться в качестве единственного решения для коммуникаций будущего. Однако умеренные издержки и отсутствие необходимости инсталляции программного обеспечения вручную приводят к тому, что полная стоимость владения (Total Cost of Ownership, TCO) виртуальной частной сети на базе SSL оказывается заметно ниже.

В классическом варианте IPSec администратор должен инсталлировать программное обеспечение с обеих сторон соединения или, по меньшей мере, позаботиться об управлении ключами — не важно, использует он «разделяемые ключи» (Preshared Key), ключи RSA или объединенную мощь инфраструктуры X.509. То, что с точки зрения ТСО кажется пустой тратой денег, оправдывает себя применительно к безопасности: администратор обладает полным контролем над используемыми программами, алгоритмами и ключами. Кроме того, в последние годы у IPSec было выявлено относительно немного проблем с безопасностью. Их причиной всегда являлись отдельные ошибки программистов и никогда — принципиальные недостатки решения. Поэтому хакер практически не в состоянии взломать правильно построенную VPN на базе IPSec.

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

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

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

Пользователь, естественно, получает предупреждающее сообщение, и ему задается вопрос, хочет ли он принять хакерский сертификат. Однако это означает недопустимый перенос ответственности за безопасность на плечи конечного пользователя — если он примет предложение, то виртуальная частная сеть на базе SSL окажется скомпрометирована. Тогда на хакерском компьютере открытым текстом показываются все проходящие данные, и он легко может считывать интересующую его информацию, включая пароли или корпоративные секреты, и даже манипулировать ею.

К этому добавляются заметно чаще, по сравнению с IPSec, обнаруживаемые «дыры» безопасности в инфраструктуре SSL. Противодействовать подобным угрозам должен прежде всего Internet Explorer от Microsoft. Так, к примеру, не всегда проверяется вся цепочка от обладателя ключа до доверительного центра. Кроме того, многие эксперты считают ненадежными апплеты Java и управляющие элементы ActiveX, которые шлюз SSL использует для туннелирования других протоколов на клиент.

Конечно, виртуальная частная сеть SSL может быть защищена таким образом, что она практически ни в чем не будет уступать с точки зрения безопасности IPSec. Для этого в первую очередь необходимо заменить апплеты Java и управляющие элементы ActiveX на «настоящий» клиент VPN, затем построить собственную структуру Х.509, а собственный сертификационный центр указать в браузере в качестве единственно возможного. И наконец, SSL должен работать с двусторонней аутентификацией, для чего на клиенте требуется разместить дополнительные ключи. Тем самым VPN на базе SSL становится абсолютно надежной, однако при этом не обладает никакими преимуществами в отношении ТСО.

ВОЗМОЖНОСТИ ПРИМЕНЕНИЯ

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

Одной из двух типичных областей применения VPN является межсоединение двух отдельных сетей по каналам VPN. В большинстве случаев речь идет о компаниях или организациях, чьи офисы расположены в разных местах. При такой структуре никогда нельзя предсказать, какими данными будут обмениваться сети, и тогда можно использовать только VPN на базе IPSec.

Другая крупная область применения VPN — подключение мобильных сотрудников, к примеру обеспечение коммуникаций для разъездных работников или находящегося в командировке директора предприятия. Им постоянно приходится подключаться через Internet к корпоративной сети для доступа к данным. При таком сценарии теоретически можно применять оба варианта. Решение зависит исключительно от необходимости защиты передаваемых данных.

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

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

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

ЗАКЛЮЧЕНИЕ

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

Маркус а Кампо — независимый консультант, эксперт по обучению и автор в области безопасности информационных технологий. С ним можно связаться по адресу: wj@lanline.awi.de.