Тема 11. Использование защищенных компьютерных систем (стр. 4 )

·  Второй вид информации - уникальное содержимое или уникальные характеристики предмета. Простейший пример - ключ от любого замка. В случае же компьютерной аутентификации в этом качестве выступают любые внешние носители информации: смарт-карты, электронные таблетки iButton, USB-токены и т. д.

·  Третий вид аутентификации - по биометрической информации, которая неотъемлема от пользователя. Это может быть отпечаток пальца, рисунок радужной оболочки глаза, форма лица, параметры голоса и т. д.

Очень часто комбинируют несколько видов информации, по которой проводится аутентификация. Типичный пример: аутентификационная информация хранится на смарт-карте, для доступа к которой нужно ввести пароль (PIN-код). Такая аутентификация называется двухфакторной. Существуют реальные системы и с трехфакторной аутентификацией.

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

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

Простейший протокол аутентификации - доступ по паролю (Password Access Protocol, PAP): вся информация о пользователе (логин и пароль) передается по сети в открытом виде (рис. 11.1). Полученный сервером пароль сравнивается с эталонным паролем данного пользователя, который хранится на сервере. В целях безопасности на сервере пароли обычно не хранятся в открытом виде, а хранятся их хэш-значения.

Рис. 11.1. Схема протокола PAP

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

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

В семейство протоколов, называемых обычно по процедуре проверки "запрос-ответ", входит несколько протоколов, которые позволяют выполнить аутентификацию пользователя без передачи информации по сети. К протоколам семейства "запрос-ответ" относится, например, один из наиболее распространенных - протокол CHAP (Challenge-Handshake Authentication Protocol).

Процедура проверки включает как минимум четыре шага (см. рис. 11.2):

·  пользователь посылает серверу запрос на доступ, включающий его логин;

·  сервер генерирует случайное число и отправляет его пользователю;

·  пользователь шифрует полученное случайное число симметричным алгоритмом шифрования на своем уникальном ключе, результат зашифрования отправляется серверу;

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

Рис. 11.2. Схема протокола аутентификации типа "запрос-ответ"

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

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

Однако в качестве клиентского компьютера может выступать и смарт-карта либо аналогичное "носимое" устройство, обладающее достаточной вычислительной мощностью, например, мобильный телефон. В таком случае теоретически допустима аутентификация и получение доступа к серверу с любого компьютера, оснащенного устройством чтения смарт-карт, с мобильного телефона или КПК.

Протоколы типа "запрос-ответ" легко "расширяются" до схемы взаимной аутентификации (см. рис. 11.3). В этом случае в запросе на аутентификацию пользователь (шаг 1) посылает свое случайное число (N1). Сервер на шаге 2, помимо своего случайного числа (N2), должен отправить еще и число N1, зашифрованное соответствующим ключом. Тогда перед выполнением шага 3 пользователь расшифровывает его и проверяет: совпадение расшифрованного числа с N1 указывает, что сервер обладает требуемым секретным ключом, т. е. это именно тот сервер, который нужен пользователю. Такая процедура аутентификации часто называется рукопожатием.

Рис. 11.3. Схема протокола взаимной аутентификации

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

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

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

Рис. 11.4. Схема протокола Kerberos

Прежде всего стоит сказать, что при использовании протокола Kerberos нельзя напрямую получить доступ к какому-либо целевому серверу. Для того, чтобы запустить собственно процедуру аутентификации, необходимо сначала обратиться к специальному серверу аутентификации с запросом, содержащим логин пользователя. Если сервер не находит автора запроса в своей базе данных, запрос отклоняется. В противном случае сервер аутентификации формирует случайный ключ, который будет использоваться для шифрования сеансов связи пользователя с еще одним специальным сервером системы: сервером предоставления билетов (Ticket-Granting Server, TGS). Данный случайный ключ (обозначим его Ku-tgs) сервер аутентификации зашифровывает на ключе пользователя (Kuser) и отправляет последнему. Дополнительная копия ключа Ku-tgs с рядом дополнительных параметров (называемая билетом) также отправляется пользователю зашифрованной на специальном ключе для связи серверов аутентификации и TGS (Ktgs). Пользователь не может расшифровать билет, который необходим для передачи серверу TGS на следующем шаге аутентификации.

Следующее действие пользователя - запрос к TGS, содержащий логин пользователя, имя сервера, к которому требуется получить доступ, и тот самый билет для TGS. Кроме того, в запросе всегда присутствует метка текущего времени, зашифрованная на ключе Ku-tgs. Метка времени нужна для предотвращения атак, выполняемых повтором перехваченных предыдущих запросов к серверу. Подчеркнем, что системное время всех компьютеров, участвующих в аутентификации по протоколу Kerberos, должно быть строго синхронизировано.

В случае успешной проверки билета сервер TGS генерирует еще один случайный ключ для шифрования сеансов связи между пользователем, желающим получить доступ, и целевым сервером (Ku-serv). Этот ключ шифруется на ключе Kuser и отправляется пользователю. Кроме того, аналогично шагу 2, копия ключа Ku-serv и необходимые целевому серверу параметры аутентификации (билет для доступа к целевому серверу) посылаются пользователю еще и в зашифрованном виде (на ключе для связи TGS и целевого сервера - Kserv).

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

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

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

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

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

Выбор того или иного протокола зависит в первую очередь от важности информации, доступ к которой предоставляется по результатам аутентификации. Другой критерий - удобство использования. И здесь, как и везде, полезно соблюдать разумный баланс. Иногда, если нет особых требований к секретности процедуры аутентификации, вместо надежного (но непростого в реализации) протокола типа Kerberos лучше использовать "элементарный" парольный протокол РАР, простота и удобство применения которого часто «перевешивают» все его недостатки.

С момента своего появления в 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.

Для удобства политику 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.

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

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

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

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

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

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

Еще одна интересная возможность в отношении фильтрации трафика появилась в Windows Server 2003. Она позволяет задать режим обработки трафика в процессе загрузки операционной системы, до момента применения политик IPSec. Драйвер может пропускать все пакеты или блокировать их, однако оптимальным методом является использование режима 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. /default. aspx? scid=kb;en-us;224196&sd=tech). Кроме того, разделяемый ключ хранится в открытом виде в реестре (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\ Windows\IPSec). В том случае если настройка IPSec осуществляется посредством групповых политик, Preshared Key сохраняется в файлах политик \\<dc-name>\SYSVOL\<domain-name>\ и по умолчанию доступен для чтения любому аутентифицированному пользователю (в Windows Server 2003 группе Domain Computers). Поэтому необходимо посредством разрешений Active Directory запрещать доступ к объектам GPO, содержащим подобные политики IPSec, всем пользователям, за исключением администраторов домена и компьютеров, применяющих политику IPSec.