Неизвестный IPSec

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

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

Немного теории

Политика IPSec в Windows состоит из набора Security Policy Database (SPD). Только одна из них может применяться к компьютеру и, соответственно, использоваться драйвером IPSec. База SPD содержит набор правил, которые, в свою очередь, состоят из двух частей: селектора и правила. Селектор представляет собой фильтр, на основе которого правило применяется к тому или иному пакету. В роли параметров фильтра могут выступать IP-адреса, адреса сети или FQDN отправителя и получателя пакета, тип IP-протокола (ICMP, TCP, UDP и т. д.), номера TCP и UDP портов отправителя и получателя. Правило определяет реакцию драйвера на пакет, соответствующий тому или иному селектору. Существует три типа реакции: пакет может быть отброшен (Block), передан без применения IPSec (Permit) и передан с применением IPSec (Negotiate Security).

Если пакет соответствует правилу, требующему установления безопасного соединения, запускается процесс получения метки безопасной ассоциации (Security Association, SA). Компьютеры - участники соединения - должны пройти взаимную аутентификацию, согласовать типы и параметры используемых протоколов защиты и сформировать общий ключ, применяемый для шифрования и контроля целостности данных.

Реализация IPSec в Windows поддерживает три способа взаимной аутентификации: Preshared Key, Kerberos и Certificates. В случае использования Preshared Key для успешного согласования параметров оба компьютера должны обладать разделяемым ключом, который задает администратор. Во втором случае оба компьютера должны принадлежать к одной области (realm) Kerberos или находиться в областях, связанных доверительными отношениями. И в случае применения третьего способа оба компьютера должны иметь действующий сертификат стандарта X.509, выданный центром сертификации, которому доверяет вторая сторона.

В IPSec определены два протокола защиты передаваемых данных - Authentication Header (AH) и Encapsulated Security Payload (ESP). Протокол AH гарантирует целостность и аутентичность данных, т. е. принимающая сторона может быть уверена, что пакет отправлен именно указанным лицом и не был искажен в процессе передачи. Подобная функциональность достигается путем добавления в пакет дайджеста пакета, вычисляемого на основе его содержимого и общего секретного ключа. Протокол AH защищает весь исходный пакет, включая заголовок IP. Для шифрования передаваемых данных используется протокол ESP, зашифровывающий содержимое пакета (все данные, начиная с заголовков транспортного уровня). Кроме того, ESP добавляет в пакет дайджест, обеспечивающий целостность данных. При расчете дайджеста заголовок IP не применяется. Возможно совместное использование AH и ESP в тех случаях, когда требуется обеспечить целостность заголовка IP и конфиденциальность данных.

Для шифрования данных в протоколе IPSec можно задействовать алгоритмы DES, 3DES и Null (только контроль целостности), а для обеспечения целостности - MD5 и SHA1.

В Windows 2000/2003 реализована поддержка двух режимов функционирования IPSec: транспортный (Transport Mode) и туннельный (Tunnel Mode). В транспортном режиме пакет, соответствующий фильтру IPSec, защищается при помощи протокола AH или ESP и пересылается в адрес, указанный в заголовке IP. В туннельном режиме к пакету добавляется новый заголовок IP, где в качестве IP-адреса отправителя указывается адрес данного компьютера, а в качестве адреса получателя - адрес, указанный в правиле; это вторая конечная точка туннеля. Затем пакет защищается при помощи AH или ESP. Использование транспортного режима позволяет защищать коммуникации между двумя компьютерами (схема «точка-точка»). Туннельный режим позволяет защищать коммуникации двух сетей (схема «шлюз-шлюз»).

Подробнее о принципах работы IPSec можно узнать из документов RFC, опубликованных на сервере Internet Engineering Task Force ( http://www.ietf.org ).

Фильтрация трафика

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

Таким образом, политика IPSec, даже без настройки защищенного соединения, может использоваться для повышения безопасности узла. Создавая политику IPSec, разрешающую трафик применяемых на узле сетевых служб и запрещающую весь остальной трафик, мы повышаем уровень защиты от атак через неиспользуемые сетевые службы, а также ограничиваем возможности злоумышленника в случае компрометации существующих приложений. Яркими примерами подобных атак являются эпидемии сетевых «червей» Code Red и Slammer. Первый из них использовал устанавливаемую по умолчанию в Windows 2000 Server службу Internet Information Server, а второй - уязвимые места в Microsoft SQL Server и MSDE.

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

Настраивать политику фильтрации можно при помощи оснастки консоли управления IP security policies или утилит командной строки. В Windows 2000 для настройки IPSec из командной строки применяется утилита из состава Resource Kit ip-secpol (данный подход описан в статье «Защита приложений пользователя», Windows & .NET Magazine № 4 за 2003 год).

При использовании оснастки можно предварительно создать набор фильтров, а потом уже осуществить привязку фильтров к правилам. Для этого в оснастке редактирования объекта групповой политики следует щелкнуть правой кнопкой мыши на пункте IP Security Policies и выбрать Manage IP filter lists and filter actions. В появившемся диалоговом окне нужно нажать Add и указать название и параметры фильтра. Создавать фильтр можно в двух режимах - в режиме мастера и в режиме диалога. Мне лично удобнее работать в режиме диалога, для использования которого в окне IP filter list необходимо очистить флажок Use Add Wizard.

Некоторым администраторам может показаться более удобной возможность настройки фильтров через интерфейс командной строки при помощи утилиты netsh. Эта функция появилась в Windows Server 2003.

В Листинге 1 приведен пример использования утилиты netsh для добавления набора фильтров, описывающих обращение клиента к серверу DNS. Предварительно список правил очищается.

Обратите внимание на способ указания IP-адресов источника и получателя пакета. Зарезервированные слова Me и DNS указывают на IP-адрес компьютера и серверов DNS, сконфигурированных в настройках стека TCP/IP. Поддерживаются также ключевые слова gateway, WINS и DHCP, указывающие на IP-адреса шлюзов по умолчанию, серверов WINS и DHCP, установленных вручную или полученных от сервера DHCP.

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

В первой строке мы формируем список правил, описывающий весь IP-трафик. Во второй создается правило Block, запрещающее прохождение трафика, в третьей - правило Permit, разрешающее его прохождение без применения IPSec. Далее создается политика IP filter, в которую включаются фильтры DNS client и All traffic, причем первому из них назначается разрешающее правило Permit, а второму запрещающее Block.

Если выполнить команду netsh, в появившемся приглашении указать контекст ipsec static, а затем последовательно ввести команды из первого и второго сценариев, то компьютер перестанет принимать и обрабатывать любой трафик, кроме запросов DNS и ответов на них.

Разработка политик фильтрации

При разработке политик фильтрации всегда встает вопрос, какой трафик необходимо разрешить. К его решению существует несколько подходов. Проще всего обратиться к рекомендациям разработчика сетевой службы, в которых обычно описываются используемые порты и протоколы. Если подобной документации нет, можно воспользоваться бесплатной утилитой fport (доступной на сервере www.foundstone.com ), отображающей привязку процессов к открытым портам. Для выяснения, какие системные службы задействуют тот или иной процесс (поскольку один и тот же процесс может использоваться несколькими системными службами), можно прибегнуть к помощи утилиты tlist, запущенной с ключом -s из состава Windows 2000 Support Tools. В Windows Server 2003 те же функции выполняет утилита tasklist, запущенная с ключом -SVC. Поскольку утилита fport в Windows Server 2003 не работает, для определения привязки приложения к порту используется утилита netstat с ключами -aon.

Описание основных протоколов Windows можно найти в статьях «Windows Server 2003 Security Guide» ( http://go.microsoft.com/fwlink/?LinkId=14845 ) и «Active Directory Replication over Firewalls» ( http://www.microsoft.com/serviceproviders/ columns/config_ipsec_p63623.asp ). В Таблице 1 приведен пример настройки фильтрации трафика, типичного для контроллера домена.

Необходимо помнить, что многие службы используют RPC для сетевого взаимодействия, и, соответственно, номер порта выдается им при загрузке системы. Некоторые из них можно привязать к статическому порту, что сделано в данном примере для службы NTDS, которая привязывается к порту 57952, согласно рекомендациям статьи KB 224196.

При построении политик фильтрации трафика необходимо понимать, что они не являются полнофункциональным пакетным фильтром, поскольку в них нельзя указывать направление соединения. К примеру, если в политиках разрешено соединение с удаленным компьютером на порт 88 (т. е. компьютер сконфигурирован как клиент протокола Kerberos), злоумышленник, используя порт 88 как номер клиентского порта, может соединиться с любым портом на данном компьютере. Это можно сделать при помощи различных утилит, например утилиты netcat. Запустив ее с параметрами nc -p 88 machinename 445, мы получаем соединение на порт 445 (CIFS), даже если правило доступа к нему отсутствует.

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

Еще одна интересная возможность в отношении фильтрации трафика появилась в Windows Server 2003. Она позволяет задать режим обработки трафика в процессе загрузки операционной системы, до момента применения политик IPSec. Драйвер может пропускать все пакеты или блокировать их, однако оптимальным методом является использование режима stateful, разрешающего прохождение только исходящих пакетов и тех пакетов, которые пришли в ответ на них. Настройка данного параметра возможна только через netsh в контексте ipsec static. Ниже приведен пример включения режима stateful для локальной машины.

netsh ipsec dynamic set config
 property=bootmode value=stateful

Разграничение доступа

Рассмотрим довольно распространенный сценарий: в сети присутствует Web-приложение, использующее сервер SQL в качестве хранилища данных. Сервер Web аутентифицирует пользователя посредством Active Directory и создает запросы к серверу SQL уже в контексте конкретного пользователя. Однако, если у пользователя есть возможность соединиться непосредственно с сервером SQL, он может попытаться обойти логику приложения, к примеру, получить доступ к данным других пользователей.

Для того чтобы ограничить список компьютеров, которые могут взаимодействовать по сети с сервером SQL, можно применить простую фильтрацию трафика, описанную выше. Однако, как уже говорилось, политики IPSec не являются полнофункциональным фильтром. Кроме того, если злоумышленник находится в одном сегменте с любым из серверов, у него есть возможность задействовать IP-адрес Web-сервера для соединения с SQL-сервером, используя механизм man-in-middle, и таким способом избежать фильтрации.

В Windows 2000 эта проблема решалась с использованием аутентификации IPSec. На SQL-сервере создавался фильтр IPsec, описывающий трафик с любого IP-адреса на локальный порт 1434. Создавалась политика IPSec, сопоставляющая данному фильтру действие Negotiate Security и применяющая для аутентификации Preshared Key. На сервере Web также создавалось правило IPSec, которое описывало трафик, направленный на 1434-й порт SQL-сервера, и требовало установления защищенного соединения, использующего для аутентификации тот же общий ключ.

Таким образом, попытка установить соединение с 1434-м портом сервера SQL будет успешна только в том случае, если инициирующая сторона настроена на использование тех же параметров IPSec (типа протокола защиты, протоколов шифрования и контроля целостности данных), а также задействует тот же ключ, что и сервер. Поскольку Preshared Key задается администратором на обеих сторонах соединения, попытка соединиться с SQL-сервером будет успешной только для сервера Web.

Однако в более сложных схемах такой подход не слишком удобен. Дело в том, что стойкость аутентификации Preshared Key очень сильно зависит от режима работы IPSec и сложности общего ключа, что подробно описано в «Restricting Active Directory Replication Traffic to a Specific Port» ( http://support.microsoft.com/default.aspx?scid=kb;en-us;224196&sd=tech ). Кроме того, разделяемый ключ хранится в открытом виде в реестре (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\ Windows\IPSec). В том случае если настройка IPSec осуществляется посредством групповых политик, Preshared Key сохраняется в файлах политик \\\SYSVOL\\ и по умолчанию доступен для чтения любому аутентифицированному пользователю (в Windows Server 2003 группе Domain Computers). Поэтому необходимо посредством разрешений Active Directory запрещать доступ к объектам GPO, содержащим подобные политики IPSec, всем пользователям, за исключением администраторов домена и компьютеров, применяющих политику IPSec.

Kerberos

Метод аутентификации Kerberos позволяет решить давнюю проблему: доступ в сеть с компьютеров, которые не являются членами домена. Групповая политика представляет собой прекрасное средство настройки рабочих станций пользователя, но, к сожалению, она применяется только в том случае, если компьютер включен в домен. Этот факт зачастую используется для обхода ограничений групповых политик. Пользователь переустанавливает операционную систему на своем компьютере и включает ее в рабочую группу, имя которой совпадает с именем домена. Затем он заводит локальную учетную запись, совпадающую с доменной учетной записью, включает ее в группу локальных администраторов и может работать с любыми доменными ресурсами, при этом к его компьютеру групповые политики не применяются.

Решая эту проблему, администратор сети может настроить политики IPSec серверов таким образом, чтобы они требовали установления защищенного соединения, используя в качестве метода аутентификации Kerberos. Тогда пользователи, чьи компьютеры не являются членами домена, не получат доступ к серверам, поскольку не сумеют согласовать параметры соединения. К сожалению, данный подход применим только в том случае, если на клиентских компьютерах установлена Windows 2000/XP.

В Windows Server 2003 появилась интересная возможность, связанная с разграничением сетевого доступа при помощи IPSec. В случае если сервер требует установления защищенного соединения с использованием методов аутентификации Kerberos или Certificate, администратор может применить права пользователей Access this computer from network и Deny Access this computer from network к учетным записям компьютеров.

Таким образом, в сценарии с Web- и SQL-сервером появляется возможность отказаться от использования разделяемого ключа. Если сервер баз данных построен на основе Windows Server 2003, мы можем создать политику IPSec, требующую установления соединения IPSec с применением аутентификации Kerberos, и в политиках безопасности указать, какие компьютеры имеют возможность сетевого доступа. Эта очень мощная функция позволяет ограничивать доступ к любым сетевым службам, задействующим TCP/IP при помощи стандартных прав Windows. Впервые настроив Windows Server 2003 для использования данной возможности, я не мог поверить своим глазам. К этому не сразу привыкаешь: добавляя учетную запись компьютера в список с правом Deny access this computer from network, мы запрещаем ему, например, устанавливать соединение telnet.

При использовании метода аутентификации Kerberos необходимо помнить, что оба участника сеанса IPSec должны иметь возможность непосредственного (без использования IPSec) взаимодействия с KDC, роль которого играет контроллер домена AD, т. е. в случае применения IPSec в масштабах леса необходимо обеспечить взаимодействие защищаемых компьютеров со всеми доменами в лесу. В Windows 2000/XP это реализовано при помощи исключений по умолчанию (Default Exempt). Дело в том, что политики IPSec имеют встроенные разрешающие фильтры для трафика, соответствующего протоколам Kerberos, RSVP, ISAKMP, а также широковещательного и группового трафика. В Windows 2003 по умолчанию в ряд исключений попадает только трафик ISAKMP.

Разрешения по умолчанию Windows 2000/XP, как было показано выше, позволяют обходить защиту IPSec, поэтому рекомендуется отключать их. Согласно статье KB 811832 для этого необходимо модифицировать параметр реестра HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC\ NoDefaultExempt. Обратите внимание, что удаление из исключений протокола Kerberos и RSVP появилось в четвертом пакете обновлений для Windows 2000 и Windows XP Service Pack 2. Для настройки данного параметра в пределах домена можно использовать групповую политику, добавив этот параметр в раздел Local Settings - Security Options (см. статью «Все и сразу», Windows & .NET Magazine/RE № 1 за 2003 год).

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

Сертификаты открытых ключей

От подобных проблем избавлен метод аутентификации с использованием сертификатов. Рассмотрим следующий сценарий. В разветвленной сети имеется сервер резервного копирования, на котором хранятся резервные копии критичных данных (таких, как System State контроллеров домена и хранилища Exchange) всего предприятия. Очевидно, что доступ к данному серверу необходимо очень тщательно разграничивать.

Используя инфраструктуру открытых ключей предприятия, администратор выдает сертификаты на применение IPSec для всех компьютеров (контроллеров домена, серверов Exchange, рабочих станций администратора), работающих с сервером резервного копирования, после чего создает на нем политику IPSec, требующую установления защищенного соединения для всего IP-трафика с использованием сертификатов для аутентификации. Затем на сервере делегируется право Access this computer from network только для определенных компьютеров и пользователей.

Теперь соединение с сервером резервного копирования будет возможно только с компьютера, который обладает сертификатом открытых ключей, выданным корпоративной системой PKI, и имеет право Access this computer from network. В этом случае даже для доступа к контроллерам домена сервер резервного копирования сможет задействовать защищенное соединение IPSec.

Использование такого метода позволяет также разграничивать доступ для компьютеров, не принадлежащих данному лесу. Для этого в AD реализован механизм привязки сертификатов к учетной записи компьютера. Он позволяет создать учетную запись компьютера и привязать к нему один или несколько сертификатов. Затем такая «фантомная» учетная запись может использоваться для разграничения доступа. Подробнее об этом можно будет узнать в Distributed Services Guide из состава Windows Server 2003 Resource Kit.

Организация VPN

Текущие спецификации IPSec не поддерживают использование протокола VPN в сетях с трансляцией адресов (Network Address Translation). Это затрудняет использование IPSec для организации виртуальных частных сетей. В Windows Server 2003 реализован механизм использования IPSec в сетях с NAT согласно проектам RFC «UDP Encapsulation of IPSec packets» и «Negotiation of NAT-Traversal in the IKE». В случае применения ESP протокол установления защищенного соединения автоматически определяет наличие трансляции адресов и инкапсулирует пакеты IPSec в UDP-пакеты с номером порта отправителя и получателя 4500 (см. статью «IPSec NAT Traversal Overview»; http://www.microsoft.com/technet/columns/ cableguy/cg0802.asp ). Данная возможность должна появиться в стеке IPSec Windows 2000/XP. Протокол AH совместно с трансляцией адресов применяться не может, поскольку системы NAT изменяют заголовок IP, нарушая его целостность.

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

В случае использования L2TP совместно с IPSec по умолчанию включается метод аутентификации Certificates, что затрудняет применение этого протокола для создания VPN в сетях, не имеющих собственной инфраструктуры открытых ключей. Однако существует возможность задействовать IPSec/L2TP с использованием метода аутентификации Preshared Key. Настройка сервера и клиентов для применения общих ключей в Windows 2000 описана в статье KB 240262, а для Windows 2003/XP - в статье 324258. Однако использовать данную возможность не рекомендуется в связи с уже описанными выше проблемами этого метода аутентификации.

Отладка и протоколирование

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

Включение категории Audit logon events приводит к появлению в журнале Security событий 541, в случае успешного согласования параметров соединения, и 547, в случае сбоя. Данная возможность очень полезна на этапе отладки политик, однако в рабочей среде протоколирование процесса установления всех защищенных соединений может привести к переполнению журналов аудита. Для отключения протоколирования процесса IKE в Windows 2003 необходимо выполнить команду

netsh ipsec dynamic set
 config ikelogging 0

В Windows 2000/XP отключение данной функции осуществляется путем присвоения значения 1 параметру реестра HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\ PolicyAgent\Oakley\EnableLogging и перезапуска системной службы IPSec Policy Agent.

Для отслеживания работы фильтров можно воспользоваться возможностями протоколирования драйвера IPSec. Для этого параметру реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\IPSec\EnableDiagnostics присваивается значение от нуля до семи. После перезагрузки компьютера драйвер IPSec начнет фиксировать события в журнале System. В Windows Server 2003 можно воспользоваться командой

netsh ipsec dynamic set
 config ipsecdiagnostics

По умолчанию драйвер сохраняет события в журнале раз в час, что очень неудобно при отладке политик. В параметре реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\IPSec\LogInterval интервал сохранения событий устанавливается в секундах. В Windows Server 2003 для изменения этого параметра можно воспользоваться командой

netsh ipsec dynamic set config
ipsecloginterval

Подробнее о настройке и отладке политик IPSec рассказано в разделе Troubleshooting tools документа «Designing and planning IPSec policies» http://www.microsoft.com/technet/prodtechnol/ windowsserver2003/proddocs/entserver/ sag_IPSECimplemntg.asp .

Реализация IPSec в Windows 2000/2003 основана на отраслевых стандартах и совместима с решениями других производителей. Политики IPSec, в сочетании с Active Directory и PKI, позволяют построить высокозащищенную, централизованную сетевую инфраструктуру предприятия. Однако в связи с богатой функциональностью и изрядной сложностью его использование требует от администратора ясного понимания процесса работы сетевых служб и возможных последствий того или иного варианта использования данного протокола.

Листинг 1. Команды утилиты netsh для добавления фильтров

delete all
add filter filterlist="DNS client" srcaddr=Me
 dstaddr=DNS protocol=TCP mirrored=YES dstport=53
add filter filterlist="DNS client" srcaddr=Me
 dstaddr=DNS protocol=UDP mirrored=YES dstport=53

Листинг 2. Создание политики прохождения пакетов

add filter filterlist="All traffic" srcaddr=Any
 dstaddr=Any protocol=ANY mirrored=YES
add filteraction name=Block action=block
add filteraction name=Permit action=Permit
add policy name="Ip filter" assign=yes
add rule name="Permit DNS" policy="Ip filter"
 filterlist="DNS client" filteraction=Permit
add rule name="Block All" policy="Ip filter"
 filterlist="All traffic" filteraction=Block

Врезки: Таблица 1. Таблица для фильтра на контроллере домена