04 апреля 2012
Защита от несанкционированного доступа в сетях передачи данных
Часть 2: защита данных на базе технологий шифрования
Введение
При построении виртуальных частных сетей широкое распространение получило использование криптографических технологий.
К сожалению, многие термины, как было указано в первой части настоящей статьи, не всегда трактуются и понимаются одинаково всеми участниками информационного взаимодействия. На это было обращено внимание Федеральным агентством правительственной связи и информации при Президенте РФ (ФАПСИ), которое в своем письме указывало, что «...в области защиты информации пока не выработан единый, принятый во всей стране понятийный аппарат ... Многие понятия и термины, вводимые принимаемыми законами и иными нормативными актами, используемые различными органами, работающими в сфере защиты информации, или отдельными авторами, носят неоднозначный противоречивый характер. В одни и те же термины часто вкладывается различное смысловое содержание...»1. Далее разъяснялось, что ФАПСИ (ныне - ФСБ России2) в своей деятельности использует понятийный аппарат, определенный такими документами как ГОСТ 28147-89, ГОСТ Р 34.10-94 (на сегодня это соответственно ГОСТ 34.10-20013), ГОСТ Р 34.11-94, Указом Президента № 1268 (на сегодня это Указ Президента РФ от 05.05.2006 г. № 5804), Система сертификации СКЗИ5. Таким образом, если какие из терминов буду вызывать затруднения, то читателю следует обратиться к указанным источникам. Помимо этого, нельзя не сказать о вкладе Академии криптографии России и Института проблем информационной безопасности МГУ им. М.В. Ломоносова в формирование единого современного понятийного аппарата по направлению криптографической защиты информации. Одним из результатов проведенной работы стал словарь терминов6, на который по мере необходимости будем ссылаться в настоящей статье.
Общая информация о построении VPN на базе технологии шифрования
По сути, технология построения VPN на базе технологии шифрования представляет собой совокупность методов обеспечения конфиденциальности и контроля целостности данных, передаваемых между конечными узлами сети, и реализуется при помощи криптошлюзов (VPN-шлюзов, VPN-маршрутизаторов, криптомаршрутизаторов) и центра управления VPN
7.
Криптошлюз (или - криптомаршрутизатор), будучи средством, осуществляющим туннелирование исходящих и входящих пакетов, а также зашифрование исходящих и расшифрование входящих пакетов8, решает задачу обеспечения конфиденциальности данных, а используя аутентификаторы сообщений - решает задачу контроля целостности сообщений.
Криптошлюз реализуется:
- на базе сетевых операционных систем со встроенными функциями реализации VPN;
- на базе маршрутизаторов /коммутаторов, программное обеспечение которых имеет функции построения VPN;
- на базе межсетевых экранов, в программное обеспечение которых интегрированы функции по построению VPN;
- на базе специализированного программно-аппаратного обеспечения, предназначенного исключительно для построения VPN.
В свою очередь Центр управления VPN:
- выполняет мониторинг и управление работой криптошлюзов;
- обеспечивает распределение криптографических ключей между криптошлюзами.
Между криптошлюзами устанавливаются так называемые «виртуальные соединения» («туннели»), по которым передаются защищаемые данные.
Взаимодействие между криптошлюзами осуществляется с использованием криптопротоколов, которые реализуются на разных уровнях модели взаимодействия открытых систем (OSI).
В общем случае, криптошлюз, получив данные от отправителя (конечной рабочей станции):
- зашифровывает полученные данные;
- вычисляет аутентификатор для передаваемых данных;
- формирует пакет для передачи, в адресе получателя которого прописывает адрес криптошлюза, через который передаваемые данные достигнут рабочую станцию получателя;
- размещает зашифрованные данные и аутентификатор в новом пакете;
- передает сформированный пакет по каналу связи.
Криптошлюз, получивший данные из «туннеля»:
- извлекает из принятого пакета зашифрованные данные;
- проводит контроль целостности принятых данных;
- расшифровывает извлеченные данные;
- передает расшифрованные данные в адрес рабочей станции получателя.
В теории защиты информации принято рассматривать передачу данных через «туннель» («туннелирование») как самостоятельный сервис безопасности, который используется для
9:
- передачи по каналу связи пакетов протокола, не поддерживаемого в данном канале (сети передачи данных);
- сокрытие в передаваемом трафике истинных адресов и служебной информации;
- обеспечения конфиденциальности и целостности передаваемых данных при использовании совместно с криптографическими сервисами.
Именно совместное использование туннелирования и шифрования лежит в основе защитных функций виртуальных частных сетей.
Криптопротоколы
Само по себе понятие "протокола" относится к так называемым "многозначным терминам"10 и в общем случае представляет собой определенный порядок действий (или распределенный алгоритм взаимодействия) его участников11.
Тогда, в нашем случае, криптографический протокол будет представлять собой протокол, ориентированный на выполнение криптографических функций, таких как:
- генерация ключей и псевдослучайных последовательностей;
- шифрование,
- вычисление и проверка значений кода аутентичности сообщения и электронной подписи,
- вычисление значения хэш-функции и др., в рамках обеспечения безопасности информации в части обеспечения конфиденциальности, целостности, аутентификации, невозможности отказа и неотслеживаемости.
Приведем примеры криптопротоколов. Если говорить о канальном уровне модели OSI, то здесь нельзя не сказать о таких протоколах как L2F, PPTP, L2TP.
Протокол Layer 2 Forwarding Protocol (L2F)был предложен компанией Cisco Systems и на сегодняшний день перешел в разряд «исторических реликвий»12. В нем для связи компьютера удаленного пользователя с сервером провайдера допускалось использование различных протоколов удаленного доступа (PPP, SLIP и др.). Публичная сеть, используемая для переноса данных через туннель, могла функционировать не только по протоколу IP.
В свою очередь протокол Point-to-Point Tunneling Protocol (PPTP) был разработан группой компаний Microsoft Corporation, Ascend Communications, 3Com, Cooper Mountain Networks, ECI Telematics и позволял создавать защищенные каналы для передачи PPP-траффика через ip-сети13. Передаваемые данные могли быть зашифрованы и/или сжаты.
На основе L2F и PPTP был предложен протокол Layer 2 Tunneling Protocol (L2TP)14, особенностью которого являлась возможность создания туннелей выходила за рамки исключительно IP-сетей (в частности поддерживается ATM, X.25).
Бросив взгляд на сетевой уровень модели OSI невозможно не упомянуть такого представителя мира криптопротоколов как IPsec15.
При этом использовать в единственном числе термин «протокол» в данном случае наверное будет несовсем уместно, так как по своей сути под указанной аббревиатурой скрывается целая система стандартов и протоколов, ориентированных на защиту данных, передаваемых по открытым каналам связи. IPSec обеспечивает: целостность передаваемых данных, аутентичность отправителя и конфиденциальность передаваемых данных. При этом для:
- распределения секретных ключей между пользователями в открытой сети используется обмен ключами согласно алгоритму Диффи — Хеллмана;
- обеспечения гарантии подлинности двух сторон и защиты от атак «человек по - середине» применяется криптозащита открытых ключей для подписи пакетов обмена Диффи — Хеллмана;
- подтверждения подлинности открытых ключей поддерживаются цифровые сертификаты;
- шифрования данных реализованы блочные симметричные алгоритмы;
- аутентификации сообщений вычисляют хэш-сумму сообщений.
Основными составляющими архитектуры средств безопасности IPsec являются:
- протокол обеспечения аутентичности (протокол аутентифицирующего заголовка - Authentication Header, AH)16;
- протокол обеспечения конфиденциальности (протокол инкапсулирующей защиты содержимого - Encapsulating Security payload, ESP)17;
- механизмы управления криптографическими ключами18;
- конкретные алгоритмы шифрования, контроля целостности и аутентичности;
- домен интерпретации (Domain of Interpretation, DOI), по сути, представляющий собой базу данных, хранящую сведения об алгоритмах, их параметрах, протокольных идентификаторах и т.п.
Особенностью спецификации IPsec является то, что протоколы обеспечения аутентичности и конфиденциальности в IPsec не зависят от конкретных криптографических алгоритмов. В каждой стране могут применяться свои алгоритмы, соответствующие национальным стандартам.
Одним из представителей криптопротоколов на транспортном уровне модели OSI является протокол TLS19. В данном протоколе всегда выполняется криптографическая аутентификация Сервера. Это позволяет Клиенту быть уверенным в том, что соединение установлено именно с тем Сервером, с которым запланировано взаимодействие. Опционально в рамках протокола TLS поддерживается и аутентификация Клиента. Для защиты данных между Клиентом и Сервером для каждого соединения вырабатываются специальные ключи шифрования. Эти ключи носят название «сессионных», т.к. они действуют только в рамках конкретного соединения, а по его завершению – уничтожаются. Протокол TLS допускает использовать различные криптоалгоритмы. Набор этих криптоалгоритмов (так называемый «cipher suite») должен быть одинаков у взаимодействующих сторон. На стадии установления TLS-соединения стороны обмениваются данными о поддерживаемых наборах криптоалгоритмов и «договариваются» о том, какой набор криптоалгоритмов будет использоваться в рамках их соединения.
Если обратить взгляд на сеансовый уровень модели OSI, то нельзя оставить без внимания такой протокол, как SSH (Secure Shell Protocol)20. В нем предусматривается возможность аутентификации по паролю, ip-адресу клиента или по публичному ключу клиента. Передаваемые данные зашифровываются на симметричном ключе. В целом, этот протокол позволяет выполнять удаленное управление операционной системой и туннелирование TCP-соединений. По создаваемому зашифрованному каналу можно успешно передавать и команды управления, и обычные данные, и аудио/видео-потоки.
В качестве примера протокола прикладного уровня назовем SSH File Transfer Protocol (SFTP), который обеспечивающий работу с файлами поверх защищенного соединения. Т.е. защиту данных обеспечивает нижележащий протокол – SSH. Данный протокол так и не стал стандартом интернет, однако существует его «рабочая версия»21.
Можно и дальше продолжать перечисление криптопротоколов, однако мы остановимся на указанном – с задачей демонстрации того, что средства защиты существуют и ими можно пользоваться мы справились. Детальное описание самих протоколов выходит за рамки данной ознакомительной статьи.
А нужна ли защита?
На сколько беззащитны и уязвимы обычные протоколы, ориентированные на взаимодействие узлов в сети? Они ведь тоже разрабатывались людьми, понимающими необходимость в соблюдении определенных правил безопасности!
Смоделируем следующую ситуацию. Пусть у нас имеются две организации OFFICE 1 и OFFICE 2, работники которых используют ресурсы, расположенные в локальных сетях, объединенных через сеть «Интернет».
Схема стенда
Если не задуматься о защите созданного канала связи, то все передаваемые данные будут доступны злоумышленникам. Как так?!
Пусть происходит передача некоторого сообщения от пользователя Ivanov для пользователя Petrov, содержащего конфиденциальную информацию – его PIN-код.
В этом случае данная информация может стать известна злоумышленнику. При этом нет никакой необходимости использовать хитроумное оборудование.
Соединение с SMTP-сервером
Воспользуемя общедоступным сетевым анализатором. С его помощью, для начала, найдем какой-либо пакет smtp-сессии, а затем «попросим» собрать все пакеты данной сессии:
Перехваченные пакеты
В результате такой манипуляции нам станет известен PIN-код, указанный в сообщении:
Пример 1 раскрытия конфиденциальной информации в почтовом сообщении
А в случае получения почтовых сообщений:
Соединение с POP3-сервером
станет доступной не менее интересная информация:
Перехваченные пакеты
Пример 2 раскрытия конфиденциальной информации в почтовом сообщении
Таким образом удалось получить и имя регистрации, и соответствующий пароль, и конфиденциальную информацию внутри сообщения.
Безусловно данное моделирование может показаться несколько «надуманным» - как так при огромном количестве доступных защитных технологий, большом внимании общественности к проблемам обеспечения конфиденциальности в сети, разве будет кто-то сейчас предоставлять доступ к своим ресурсам не позаботившись о защите?!
Давайте проверим как действительно обстоят дела. Сайт, предоставляющий доступ зарегистрированным пользователям к библиотеке ГОСТов и нормативных документов, предусматривает регистрацию посетителей:
Введем логин, пароль и войдем на сайт:
Вроде бы нет проблем – визуально вводимый пароль не отображается. А что покажет нам сканер? В перехваченном трафике введем в качестве искомого слова «password»:
и получим следующую информацию:
Таким образом, не используя никакого специального атакующего оборудования мы получили и адрес и имя регистрации и пароль доступа к ресурсу.
В качестве другого примера рассмотрим подключение к одной из популярных социальных сетей:
Обратимся к нашему сетевому анализатору:
Получаем необходимую конфиденциальную информацию:
Таким образом, остается надеяться только на то, что ситуация изменится в лучшую сторону, если устанавливать защищенное соединение между локальными сетями организаций с использованием криптопротоколов.
В качестве примера для построения защищенного соединения в следующей части статьи рассмотрим подход, основанный на применении системы Microsoft Forefront TMG с использованием L2TP/IPsec.
Заключение
В рамках данной части статьи были даны начальные сведения, касающиеся таких понятий, как «криптошлюз», «туннель», «криптопротокол» и др., связанных с созданием защищенных соединений. Даны ссылки на публикации, дающие более глубокое представление о технологиях защиты информации в публичных сетях передачи данных с использованием криптопротоколов. На практических примерах показаны уязвимости протоколов обмена данными и тем самым обоснована потребность использования защищенных каналов данных.
Продолжение следует
1 Письмо Статс-секретаря - первого заместителя генерального директора ФАПСИ В.И.Маркоменко от 22.01.99 N 76-ВМ «О порядке лицензирования деятельности».
2 Указ Президента РФ от 11.03.2003 № 308 «О мерах по совершенствованию государственного управления в области безопасности».
3 ГОСТ Р 34.10-2001. Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи. - М.: ИПК Издательство стандартов, 2001 (Предисловие, п.4).
4 Указ Президента РФ от 05.05.2004 г. № 580 «Об утверждении списка товаров и технологий двойного назначения, которые могут быть использованы при создании вооружений и военной техники и в отношении которых осуществляется экспортный контроль» (п. 3).
5 Система сертификации средств криптографической защиты информации (Система сертификации СКЗИ) //Утверждена Генеральным директором ФАПСИ при Президенте РФ 28.10.1993 г., регистрационный номер Госстандарта России РОСС RU.0001.030001 от 15.11.1993 г.
6 Словарь криптографических терминов / Под ред. Б.А. Погорелова и В.Н. Сачкова. – М.: МЦНМО, 2006. – 94 с.
7 Устинов Г.Н., Новиков А.А. Уязвимость и информационная безопасность телекоммуникационных технологий. – М.: Радио и связь, 2003. – 296 с.
8 Словарь криптографических терминов / Под ред. Б.А. Погорелова и В.Н. Сачкова. – М.: МЦНМО, 2006. – 94 с.
9 Галатенко В.А. Основы информационной безопасности – М.: ИНТУИТ.РУ «Интернет-Университет Информационных Технологий», 2003. – 280 с.
10 Протокол. Материал из Википедии — свободной энциклопедии. http://ru.wikipedia.org/wiki/ %D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB.
11 Словарь криптографических терминов / Под ред. Б.А. Погорелова и В.Н. Сачкова. – М.: МЦНМО, 2006. – 94 с.
12 RFC 2341. Cisco Layer Two Forwarding (Protocol) “L2F”. May 1998.
13 RFC 2637. Point-to-Point Tunneling Protocol (PPTP).July 1999.
14 RFC 2661. Layer Two Tunneling Protocol “L2TP”. August 1999.
15 RFC 4301. Security Architecture for the Internet Protocol. December 2005.
16 RFC 4302. IP Authentication Header. December, 2005.
17 RFC 4303. IP Encapsulating Security Payload (ESP). December, 2005.
18 RFC 5996. Internet Key Exchange Protocol Version 2 (IKEv2). September, 2010.
19 RFC 5246. The Transport Layer Security (TLS) Protocol. Version 1.2. August, 2008.
20 RFC 4251. The Secure Shell (SSH) Protocol Architecture. January 2006.
21 SSH File Transfer Protocol (draft-ietf-secsh-filexfer-02.txt). October, 2001.
