CC BY
164
ЗАЩИТА ИНФОРМАЦИИ ПРИ МЕЖСЕТЕВОМ ВЗАИМОДЕЙСТВИИ С ПОМОЩЬЮ МЕЖСЕТЕВЫХ ЭКРАНОВ
С.В. Егоров, М.С. Иванов, Ю.И. Рядчин Научный руководитель - доктор технических наук, профессор А.Г. Коробейников
В статье описаны структура межсетевых экранов и выполняемые ими функции. На основе практического опыта авторов подробно рассмотрены особенности внедрения программного комплекса VipNet Custom как части системы защиты информации автоматизированной системы ООО «Ленспецпроизводство».
Перед авторами стояла практическая задача - создание системы защиты информации автоматизированной системы ООО «Ленспецпроизводство». Неотъемлемой частью современной системы защиты информации автоматизированной системы (АС) являются межсетевые экраны (МСЭ). В данной статье описаны принципы их функционирования, а также практические особенности их выбора и применения для защиты конкретной автоматизированной системы от несанкционированного доступа (НСД).
В рекламе современных производителей МСЭ обычно представляются в виде непроницаемой кирпичной стены, практически непобедимого защитника. Пользователям обещают полную автоматизированную защиту, способную блокировать все опасности еще на стадии их возникновения. Но так ли это?
Чтобы ответить на этот вопрос, необходимо определиться с основными понятиями. Прежде всего, чем является программный МСЭ? Его ядро есть не что иное, как фильтр - то, что находится между вашими приложениями и сетевыми компонентами ОС, и решает, что можно, а что нельзя. Для этого происходит внедрение данного фильтра в ключевые места взаимодействия приложений и сети и анализ всего проходящего трафика на предмет соответствия определенному набору правил. Все, что соответствует этим правилам, пропускается через фильтр, остальной трафик блокируется.
Как это отразится на внутренней архитектуре? По каким критериям производится анализ данных? Два этих вопросы являются основными при создании МСЭ, и результаты их решения становятся двумя основными компонентами архитектуры программного межсетевого экрана.
Первый компонент работает на пакетном уровне (уровни 3 и 4 модели OSI). Его задача заключается в обнаружении подозрительных и некорректных пакетов, опознавании сканирования портов и принятии решения о пропуске пакета в стек протокола. Пакеты могут анализироваться в соответствии со следующими критериями: формальная корректность пакета, направление пакета (входящий или исходящий), хост и порт отправителя, наличие установленных флагов.
Другой компонент МСЭ работает на более высоком уровне, имея дело с конкретными процессами. В его задачи входит определение, можно ли позволить процессу X инициировать соединение с данным хостом по данному порту, можно ли прослушивать данный диапазон портов и т.д. По сути своей, межсетевой экран является совокупностью двух фильтров - на уровне пакетов и на уровне процессов.
Детали реализации изменяются от продукта к продукту, но функциональные принципы ядра очень схожи. Серьезные программные МСЭ используют два драйвера для фильтрации на двух вышеупомянутых уровнях. Также обычно есть графический интерфейс, позволяющий изменять настройки, но основная работа происходит на уровне ядра, с использованием всего двух драйверов [1, 2].
Что касается более низкого уровня, пакетный фильтр обычно реализуется одним из двух способов.
Первый способ основан на использовании драйвера NDIS (Network Driver Interface Specification). Этот драйвер находится между драйвером сетевой карты и драйверами протоколов (TCP/IP и т.д.). В сущности, это виртуальный адаптер, который является
NIC драйвером для драйверов протокола и наоборот. Так как каждый входящий и исходящий пакет проходит через этот промежуточный драйвер, это позволяет осуществить атаку «man-in-the-middle - человек посередине» (в данном случае с благой целью).
Другой стандартный способ реализации пакетного фильтра основан на внедрении в NDIS, путем перехвата части функций библиотеки NDIS, используемых драйверами протоколов. Это означает, что пакетный фильтр находится в самом NDIS, между драйверами протоколов и чем-либо более низкоуровневым. Несмотря на то, что этот способ очень сильно отличается от предыдущего по реализации, функционально они подобны.
Теперь принцип работы пакетного фильтра должен быть понятен. Он анализирует каждый пакет в соответствии с критериями, указанными в наборе правил МСЭ, сохраненными в некоторой внутренней структуре данных. Осуществляется анализ таких параметров, как хост и порт отправителя и получателя, уровень фрагментации, тип протокола, флаги пакета, действительно ли пакет является частью уже открытого соединения и т.д. Например, если протокол - TCP, и пакет имеет SYN флаг (попытка открыть соединение), фильтр в зависимости от правил разрешит или запретит соединение для данного исходного и целевого хоста. Если все же соединение будет разрешено, фильтр добавит его во внутренний список открытых соединений. Таким способом межсетевой экран следит за текущими соединениями, осуществляя непрерывную инспекцию пакетов. Если пакет удовлетворяет правилам или принадлежит соединению из вышеупомянутого списка открытых соединений, он пропускается. Пакетный фильтр передает пакет на следующий уровень - драйвера протоколов, если пакет входящий, или драйвера сетевой карты, если пакет исходящий. Если пакет блокируется правилами, он никогда не будет передан на следующий сетевой уровень. В этом случае опционально, для обратной связи с пользователем, на экране может появиться предупреждение и запись в лог-файле.
Этот драйвер также присутствует во многих программных МСЭ. На уровне рассмотренного выше пакетного фильтра у нас не никакой информации о процессах. Работа происходит только с входящими и исходящими пакетами - вещами, которые с точки зрения прикладного приложения, происходят вне машины. Таким образом, для реализации фильтрации на уровне процессов нужно создавать фильтр, работающий на более высоком уровне. Данный механизм будет работать на уровне ядра, являясь оберткой над TDI (Transport Driver Interface) и перехватывая функции, которые приложения и/или вспомогательные библиотеки (WinSock) используют для передачи данных между собой и драйверами протоколов.
Есть также и другие методы. Например, WinSock API, набор функций, использующийся большинством приложений для доступа к сети, основан на многоуровневой модели, позволяющей вставлять расширения (extensions) третьих лиц между интерфейсом приложений и базовым сетевым протоколом. Такое расширение можно добавить, реализовав Layered Service Provider (LSP) и вставив его в LSP-цепочку. LSP - это стандартная Windows DLL, соответствующая некоторой спецификации и имеющая специальную функцию, которая предназначается для вставки в цепочку WinSock протокола. Согласно модели WinSock, все сетевые данные проходят через эту цепочку, в которой каждый LSP принимает решение о пропуске данных на уровень выше (или ниже, в зависимости от того, являются ли конкретные данные входящими или исходящими), предварительно обработав или изменив данные в соответствии со своей функцией. Quality of Service (QoS) является примером такого расширения, реализованного как LSP. Фильтр процессов может быть реализован в виде LSP, находясь в цепочке протокола и выборочно передавая данные к следующему элементу цепочки или блокируя их, руководствуясь собственными критериями.
Однако описанный метод - не лучшее решение для реализации фильтра, так как он действует только для приложений, использующих WinSock для передачи данных.
Для обхода фильтра процессов, основанного на LSP, нужно всего лишь воспользоваться собственным драйвером для прямой связи через TDI c драйвером протокола, что позволить обойтись без WinSock. Первый способ, основанный на обертке над TDI, является лучшей альтернативой, так как работает на более низком уровне.
Задача фильтра процессов - анализ попыток создания соединений приложениями. Он смотрит на идентификатор (PID) процесса, пытающегося отправлять или получать данные, и анализирует его характеристики на соответствие набору правил, используя более или менее сложный набор критериев, в зависимости от качества реализации фильтра процессов МСЭ. Но основной вопрос обычно выглядит так: разрешено ли приложению, создавшему этот процесс, выполнять те действия, которые оно пытается выполнить? Это задача сводится к проверки целостности файла, создавшего процесс, путем сравнения текущего хэша с известным, поиску файла в наборе правил, а затем проверке разрешения на выполнение соответствующих действий.
Существует несколько проблем, связанных с реализаций фильтров процессов. Например, неплохо было бы проверять, какие DLL присутствуют в адресном пространстве процесса, и действительно ли они должны там находиться. Это имеет смысл, так как код загруженных модулей исполняется в контексте процесса, в адресном пространстве которого они находятся. Таким образом, злонамеренный процесс может загрузить свой DLL в адресное пространство «хорошего» процесса X, и процесс X выполнит код из этого DLL перед своим собственным. Решением этой проблемы будет нахождение всех загруженных модулей, поиск их образов на диске и затем проверка на наличие в таблице модулей, разрешенных для загрузки данным процессом. МСЭ часто осуществляют такую проверку и спрашивают разрешения на загрузку модуля, но очевидно, что это не лучшее решение проблемы. Межсетевой экран не может знать все возможные настоящие и будущие DLL, «плохие» и «хорошие», поэтому пользователю приходится решать, разрешить ли загрузку данного модуля или нет. Другая проблема - был ли код процесса изменен в памяти. Такое также возможно, если процесс был создан злонамеренной программой. Это список можно долго продолжать...
Только некоторые из этих проблем адекватно решаются в современных МСЭ. Существует слишком много путей маскировки злонамеренного кода, которые могут ввести в заблуждение фильтры и простых, и сложных межсетевых экранов. Злонамеренный процесс может изменить в памяти код другого процесса. Можно использовать в своих интересах возможности легитимной программы, например, запустив из командной строки браузер, передав ему в аргументах указание загрузить злонамеренную страницу. Даже если фильтр отслеживает отношение родительский-дочерний процесс, можно использовать много уровней косвенности. Или враждебное приложение может применить агрессивную тактику против МСЭ, вообще его отключив с помощью эмуляции кликов мыши, закрывающих предупреждения. Все, что может сделать пользователь, может сделать и программа.
Все что написано выше, фокусируется на введении в заблуждение фильтра процессов. Совсем другие возможности открываются, если атакующему даже не нужно проходить через этот фильтр. Представьте, что информация о процессах, которую использует фильтр процессов, потеряна. Вся информация, которую в этом случае имеет МСЭ, - это входящий и исходящий трафик, работа с которым ведется на уровне пакетного фильтра. Все, что нужно сделать атакующему, - это использовать драйвер, который произведет инъекцию пакетов на уровень более низкий, чем уровень фильтра процессов, что даст возможность волноваться только о пакетном фильтре. Пока он будет использовать разрешенные порты, пакетный фильтр будет пропускать пакеты атакующего. А еще остается возможность работы под уровнем пакетного фильтра ...
МСЭ является неотъемлемой частью созданной авторами системы защиты информации автоматизированной системы ООО «Ленспецпроизводство», включающей в
себя комплекс организационных мер и программно-технических средств защиты информации от несанкционированного доступа ней в АС.
Был проведен аналитический обзор представленных на рынке МСЭ и осуществлен выбор лучшего по соотношению «стоимость - эффективность - защищенность - надежность» решения для защиты серверов и рабочих станций. В табл. 1 представлены основные параметры программных МСЭ, наиболее широко распространенных на российском рынке [3-6].
Производитель, модель Производитель-ность, Мбит/с Класс МСЭ Стоимость (для АС), долл. США Метод шифрования трафика Сертификат Гостехкомиссии России / класс защиты
1 2 3 4 5 6
Check Point, FW-1/VPN-1, ver. 1 100 Enterprise 2995 DES 40, 56, 168, RSA 512 /1024 На партию / 3
Cisco, PIX 520, ver. 4.2 1000 SOHO / Enterprise 5400 DES 56, 112, 186, CISCO PIX Ravlin encr. card На единичные экземпляры / 4
ОАО «ЭЛВИС+», Застава, ver. 3.3 30-90 Enterprise 4040 DES 56, 112, 186, RSA 512/1024 На производство / 3
ОАО «Инфотекс», VipNet Custom 15-44 SOHO / Enterprise 2410 DES 56, 112, 186, RSA 512/1024, ГОСТ 28147-89 На производство / 3
ЗАО «НИП «Информ-защита», АПКШ Континент 100 SOHO / Enterprise 2900 ГОСТ 28147-89 На производство / 4
Таблица 1. Анализ распространенных на российском рынке МСЭ
На основе проведенного анализа был сделан вывод о том, что самым предпочтительным МСЭ для автоматизированной системы ООО «Ленспецпроизводство» является сертифицированный программный комплекс VipNet Custom (Сертификат Гостехкомиссии России № 545 от 17.12.01 г.), в состав которого входит средства криптографической защиты информации «Домен-К» версии 2.0 (Сертификаты ФАПСИ №№ СФ/114-0613, СФ/124-0614 от 19.05.03 г.), а также МСЭ VipNet (Сертификат Гостехкомиссии России № 546 от 17.12.01 г., Сертификат ФАПСИ № СФ/525-0558 от 01.10.01 г.).
Средства защиты семейства VipNet Custom было решено установить в АС согласно табл. 2 и настроить в соответствии с эксплуатационной документацией на средства защиты и разработанной политикой безопасности.
Технология VipNet предназначена для создания целостной системы доверительных отношений и безопасного функционирования главного узла АС и удаленных узлов АС, взаимодействующих как между собой, так и с сетью, и позволяет обеспечить защищенную передачу конфиденциальной информации по линиям связи, выходящим за пределы контролируемой зоны по сети Интернет. Технология ViPNet позволяет объединить в единую виртуальную сеть главный узел АС и локальные вычислительные сети удаленных филиалов, а также защитить ее от НСД по классу 1Г для автоматизированных систем и по 3 классу для МСЭ.
В качестве криптографического ядра системы должно использоваться криптоядро «Домен-К», обеспечивающее использование в АС симметричных и асимметричных процедур распределения ключей, электронных цифровых подписей, автоматических процедур ключевого взаимодействия в системе.
№ п/п Наименование элемента АС Устанавливаемые компоненты системы VipNet Custom Кол-во, клиентов Примечание
1 Главный узел ЛВС АС VipNet [Администратор] 1
VipNet [Клиент] 10 Устанавливается на серверы и рабочие станции, обрабатывающие наиболее критичную информацию
2 Удаленный узел ЛВС АС № 1 VipNet [Координатор] 1
VipNet [Клиент] 6 Устанавливается на серверы и рабочие станции, обрабатывающие наиболее критичную информацию
3 Удаленный узел ЛВС АС № 2 VipNet [Координатор] 1
VipNet [Клиент] 6 Устанавливается на серверы и рабочие станции, обрабатывающие наиболее критичную информацию
4 Портативные ПЭВМ сотрудников АС VipNet [Клиент] 2
Таблица 2. Установка средств защиты семейства VipNet Custom
В состав системы ViPNet CUSTOM, предполагаемой к использованию в АС, включаются следующие программные компоненты.
1. ViPNet [Администратор] устанавливается на один из компьютеров (администратора безопасности) распределенной сети (в ООО «Ленспецпроизводство» - в главном здании). Он позволяет:
• создать топологию VPN-сети АС и сгенерировать ключевую информацию для объектов VPN-сети, задать названия объектам VPN-сети и разрешить или запретить связи между ними;
• модифицировать объекты VPN-сети с последующей рассылкой обновленной справочной и ключевой информации тем объектам VPN-сети, которых коснулось конкретное изменение;
• централизовано обновить установленное ПО (ViPNet [Клиент] и ViPNet [Координатор]) в случае выхода новой версии.
2. ViPNet [Координатор] - многофункциональный модуль, выполняющий следующие функции:
• маршрутизацию почтовых и управляющих защищенных сообщений при взаимодействии объектов сети между собой и ViPNet [Администратором];
• осуществление в реальном времени регистрации и предоставление информации о состоянии объектов сети, их местоположении, значении их IP-адресов;
• обеспечение работы защищенных компьютеров локальной сети в VPN от имени одного адреса (функция proxy);
• туннелирование пакетов от обслуживаемой ViPNet [Координатором] группы незащищенных серверов и рабочих станций ЛВС для передачи трафика от них к другим объектам VPN в зашифрованном виде по открытым каналам связи;
• фильтрацию трафика от источников, не входящих в состав VPN, в соответствии с заданной политикой безопасности (функция межсетевого экрана);
• обеспечение возможности работы защищенных по технологии ViPNet серверов и рабочих станций ЛВС через сетевые экраны и прокси-серверы других производителей.
3. ViPNet [Клиент] - модуль, обеспечивающий защиту информации при ее передаче в сеть, защиту от доступа к ресурсам рабочей станции или сервера ЛВС и атак на нее из локальных и глобальных сетей, а также реализующий следующие функции: защищенные службы для организации циркулярного обмена сообщениями, проведения конференций, защищенную почтовую службу и др. При этом ViPNet [Клиент] может быть установлен как на рабочую станцию, так и на все типы серверов с целью обеспечения безопасных режимов их использования.
Основой всех модулей системы ViPNet CUSTOM является ViPNet-драйвер, взаимодействующий непосредственно с драйвером сетевого интерфейса, что обеспечивает максимально возможную независимость программы от операционной системы и ее приложений. Драйвер контролирует весь IP-трафик, поступающий и исходящий из сервера или рабочей станции, и выполняет его фильтрацию по многочисленным параметрам и, при необходимости, шифрование и инкапсуляцию в единый тип IP-пакетов [5].
В статье описано, как фактически работают программные МСЭ, рассмотрены принципы работы пакетного фильтра и фильтра процессов. Выявлены потенциально уязвимые места, а также приемы обхода защиты межсетевых экранов в целом. Это позволяет сказать, что МСЭ, хотя и являются обязательной частью современных систем защиты информации, но панацеей от всех бед их назвать нельзя, как это иногда пытаются представить в рекламных буклетах их разработчики. Только применение МСЭ в комплексе с другими средствами защиты, описание которых выходит за рамки данной статьи, позволяет говорить о надежной и эффективной защите информации автоматизированной системы от несанкционированного доступа.
Литература
1. Голицкий А.В. и др. Защита информации в сети - анализ технологий и синтез решений. М.: ДМК Пресс, 2004. 616 с.
2. Щеглов А.Ю. Защита компьютерной информации от несанкционированного доступа. СПб: Наука и Техника, 2004. 384 с.: ил.
3. Информационно-методический журнал «Защита информации. Конфидент» № 6 (60). Ноябрь - декабрь 2004. СПб: «Келла Принт», 2004.
4. http://www.infotecs.ru
5. http://www.sec.ru
6. http://www.iss.net
