Использование протокола IPSec вне VPN

Протокол IPSec предназначен для защиты не только удаленного доступа, но и соединений между хостами. Наряду с «классической» областью применения — взаимодействие с деловыми партнерами и удаленными сотрудниками через Internet, — этот протокол можно также использовать для защиты внутреннего трафика в локальной сети.

В статье рассматриваются технические аспекты применения обоих сценариев.

IPSec получил признание в качестве стандарта для надежной коммуникации по IP. Он повсеместно употребляется как расширение IPv4 и является неотъемлемой составной частью IPv6. Пакет протоколов обеспечивает конфиденциальность, целостность и аутентификацию источника данных. Аутентификация достигается посредством заранее предоставленных общих секретных ключей или цифровых подписей; надежный обмен ключами осуществляется по протоколу обмена ключами Internet (Internet Key Exchange, IKE).

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

IPSec работает на сетевом уровне стека TCP/IP, таким образом, он является прозрачным для приложений, благодаря чему безопасность с помощью IPSec можно обеспечивать во многих различных средах без необходимости изменения приложений.

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

МЕЖДУ ХОСТАМИ

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

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

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

Рисунок 1. К серверам IPSec, расположенным в демилитаризованной зоне, можно обращаться из других сетей и из Internet, а также из корпоративной локальной сети.

Чтобы защищенный трафик IP мог пройти через межсетевые экраны сетей партнеров, администраторы должны открыть UDP-порт 500 для протоколов IKE и NAT Traversal. Последнее гарантирует, что информационный обмен по протоколу IPSec не будет прерываться при прохождении через оборудование NAT.

Протокол NAT Traversal (NAT-T) инкапсулирует трафик IPSec и одновременно создает пакеты UDP, которые NAT корректно пересылает. Для этого NAT-T помещает дополнительный заголовок UDP перед пакетом IPSec, чтобы он во всей сети обрабатывался как обычный пакет UDP и хост получателя не проводил никаких проверок целостности. После поступления пакета по месту назначения заголовок UDP удаляется, и пакет данных продолжает свой дальнейший путь как инкапсулированный пакет IPSec. Итак, с помощью техники NAT-T возможно установление связи между клиентами IPSec в защищенных сетях и общедоступными хостами IPSec через межсетевые экраны.

ЗАЩИЩЕННЫЕ КОММУНИКАЦИИ В ЛОКАЛЬНОЙ СЕТИ

Система ИТ подвергается не только внешним атакам. Почти столь же велика вероятность присутствия злоумышленника внутри сети предприятия. При атаке со стороны осведомленного сотрудника последствия могут быть намного серьезнее и масштабнее, так как это лицо хорошо знакомо с инфраструктурой сети. Кроме того, такие злоумышленники часто имеют конкретную цель и причину для атаки, в то время как атаки извне нередко выполняются из чистого любопытства. Хотя потенциальный ущерб от атаки изнутри, как правило, больше, ответственные за ИT специалисты до сих пор уделяют мало внимания защите внутрисетевого трафика. Возможно, они считают, что собственная локальная сеть надежна по определению. Несмотря на это, некоторые составляющие внутреннего информационного обмена должны ограничиваться конкретными группами пользователей (например, финансовые транзакции, конфиденциальная внутренняя информация, закрытые данные о клиентах или пароли для технических систем). Законодательство требует от предприятий ввести специальные процедуры контроля, чтобы гарантировать защиту конфиденциальной информации клиентов, в том числе и внутри сети самого предприятия. Банки и другие финансовые институты даже обязаны соблюдать внутренние правила аудита для защиты части информационного обмена в собственной сети.

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

IPSec можно поэтапно вводить в существующие сетевые среды. На переходном этапе администратор имеет возможность разрешить незащищенные соединения с хостами, которые еще не могут поддерживать IPSec.

При защите трафика локальной сети удаленные пользователи вряд ли не применяют IPSec-VPN для связи с локальной сетью. Чтобы они могли воспользоваться защищенными службами, необходима итерационная техника туннелирования. При итерационном туннелировании хост имеет две или более ассоциации безопасности (Security Association), в соответствии с которыми производится информационный обмен с другими хостами. Так, например, сначала трафик инкапсулируется на внутреннем участке локальной сети, а затем защищается еще раз для передачи через VPN. Итерационное туннелирование может быть невидимым для хоста: например, если хосты устанавливают соединение в транспортном режиме от одного сегмента к другому через туннель IPSec, который проходит через VPN между двумя филиалами.

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

Рисунок 2. Защита различных взаимонезависимых зашифрованных соединений через инфраструктуру ИТ.

АУТЕНТИФИКАЦИЯ И УПРАВЛЕНИЕ

Общие секретные ключи (Preshared Key, PSK) или цифровые подписи с сертификатами предназначены для аутентификации участвующих в коммуникации друг с другом хостов. Ключи проще в обращении, чем сертификаты, зато последние обеспечивают более высокую степень защиты, легче масштабируются и управляются в крупных сетях.

Обмен открытыми ключами для цифровой подписи обычно происходит через сертификаты, которые с открытым ключом связывают блок данных. Если сертификат был подписан третьим лицом, которому оба партнера по коммуникации доверяют (Certificate Authority, CA), то он заслуживает доверия. Иерархия этих CA и их конфиденциальных отношений называется инфраструктурой открытых ключей (Public Key Infrastructure, PKI).

Далее рассмотрим несколько практических вариантов реализации контроля доступа с общими секретными ключами и сертификатами.

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

Однако общие секретные ключи подходят для надежной аутентификации только тогда, когда процедура передачи ключа находится под абсолютным контролем. Поэтому сертификаты более заслуживают рекомендации. Если предприятие уже располагает PKI, то оно может использовать ее также для поддержки удаленного доступа. Доступ к серверу (обслуживающему хосту) можно ограничивать только пользователями определенных сертификатов, созданных специально для этой цели. Если администратор предоставляет кому-либо доступ к службе, то это выглядит так, как если бы пользователю был выдан сертификат. С помощью PKI администратор к тому же имеет возможность ограничивать доступ посредством списка аннулированных сертификатов (Certifica te Revocation List, CRL). Техническое обслуживание такой среды в любом случае не так сложно, как управление бесчисленными общими секретными ключами.

Если на предприятии нет PKI, то внедрение такого решения только для удаленного доступа не всегда целесообразно. Однако сертификаты можно использовать и без PKI. Сервер и пользователи обмениваются собственными подписанными сертификатами и объявляют о своей готовности доверять им. Процесс можно до определенной степени автоматизировать, однако пользователь должен верифицировать конфиденциальные отношения, прежде чем будет установлена связь. Таким образом, описанный метод почти так же сложен, как использование PSK, но он дает более высокую степень безопасности и упрощает последующую миграцию к PKI.

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

ВЫВОДЫ

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

Миика Лаппалайнен, Томми Лампила — независимые авторы. С ними можно связаться по адресу: gg@lanline.awi.de.