Андрончик А.Н., Богданов В.В., Домуховский Н.А. Защита информации в компьютерных сетях. Практический курс

Подождите немного. Документ загружается.

№ Описание Правило

"|5c00|I|00|P|00|C|00|$| 00|";

nocase;)

6 Запрос на подключение к

445 порту (служба SMB)

из внешней сети (два ва-

рианта)

alert tcp $EXTERNAL_NET any ->

$HOME_NET 445 (msg: "NETBIOS SMB IPC$

share access"; flags: A+; content:

"|00|"; offset: 0; depth: 1; content:

"|FF|SMB|75|"; offset: 4; depth: 5;

content: "\\IPC$|00|"; nocase;)

alert tcp $EXTERNAL_NET any ->

$HOME_NET 445 (msg:"NETBIOS SMB IPC$

share access (unicode)"; flags: A+;

content: "|00|"; offset: 0; depth: 1;

content: "|FF|SMB|75|"; offset: 4;

depth: 5; content:

"|5c00|I|00|P|00|C|00|$|00|"; nocase;)

6 Обнаружение сканиро-

вания портов методом

NULL.

alert tcp $EXTERNAL_NET any ->

$HOME_NET any (msg:"NULL port

scanning"; flags:!FSRPAU;)

7 Обнаружение сканиро-

вания портов методом

XMAS.

alert tcp $EXTERNAL_NET any ->

$HOME_NET any (msg:"XMAS port

scanning"; flags:FPU+;)

ВЫПОЛНИТЬ!

5. Создать в каталоге «\snort\etc» файл «my.conf», содержащий следующие

строки:

var HOME_NET <IP-адрес_СОА>

var EXTERNAL_NET !$HOME_NET

6. Добавить в файл «my.conf» правило, позволяющее обнаруживать входящие

ECHO-запросы. Проверить, происходит ли обнаружение, запустив СОА из

каталога «\snort\bin» следующей командой (из «командной строки»):

snort -i <интерфейс> -c ../etc/my.conf -l ../log

Для проверки выполнить несколько ECHO-запросов с другого компьютера,

используя команду:

ping <IP-адрес_СОА>

7. Дополнить файл «my.conf» правилами, указанными в табл. 4.3. Для про-

верки обнаружения подключений к службе SMB использовать команду:

net use \\<IP-адрес_СОА>\IPC$ "" /user:""

К какому порту производится подключение? Как это зависит от исполь-

зуемой операционной системы?

4.5.5. Выявление факта сканирования портов

В СОА Snort встроен программный модуль, позволяющий выявлять

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

нирование, основан на том, что при сканировании портов существенно увели-

чивается количество исходящих TCP-пакетов с установленным флагом RST.

Установка этого флага на отправляемом в ответ пакете означает, что порт, к

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

личество пакетов с установленным флагом RST, можно обнаружить факт ска-

нирования портов системы.

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

ки Snort, инициализируется из файла конфигурации следующим образом. В

конфигурационный файл следует добавить следующие строки:

preprocessor flow: stats_interval 0 hash 2

preprocessor sfportscan: proto { <протокол> } scan_type

{ <тип_сканирования> } sense_level

{ <чувствительность> } logfile { <файл_с_отчетом> }

Первая строка предназначена для инициализации препроцессора Flow,

без которого модуль обнаружения сканирования не работает. Вторая строка

инициализирует препроцессор sfPortscan, при этом задаются следующие па-

раметры (жирным шрифтом показаны рекомендуемые значения):

<протокол> — анализируемый протокол (tcp, udp, icmp, ip_proto,

all)

<тип_сканирования> — выявляемые типы сканирования (portscan,

portsweep, decoy_portscan, distributed_portscan, all)

<чувствительность> — чувствительность (low, medium, high)

<файл_с_отчетом> — имя файла, в который будет помещен отчет об обна-

руженных попытках сканирования портов

Файл с отчетом будет располагаться в каталоге, указанном параметром

-c при запуске Snort. Чувствительность определяет перечень анализируемой

информации и в итоге сказывается на вероятности «ложной тревоги» (для high

она наибольшая). За более подробной информацией о параметрах модуля

sfPortscan следует обращаться к документации на Snort.

Приведем пример настройки модуля sfPortscan:

preprocessor flow: stats_interval 0 hash 2

preprocessor sfportscan: proto { all } scan_type { all }

sense_level { medium } logfile { portscan.log }

При данной настройке Snort будет выявлять все описанные в разделе 2

методы сканирования портов. Необходимо отметить, что две и больше проце-

дуры сканирования портов, выполненные во время одного сеанса работы

Snort, будут отражены в файле регистрации событий только один раз. Это ос-

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

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

рования, выполняемого разными методами, Snort необходимо закрывать и за-

пускать снова.

ВЫПОЛНИТЬ!

8. Дополнить файл «my.conf» приведенными выше строками для настройки

препроцессора sfPortscan. С использованием утилиты nmap проверить,

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

узла. Использовать следующие команды для запуска сканирования:

nmap <IP-адрес_СОА> -v -sT -p <диапазон_портов> — для

сканирования методом с полным циклом подключения (метод Connect)

nmap <IP-адрес_СОА> -v -sS -p <диапазон_портов> — для

сканирования с неполным циклом подключения (метод SYN)

nmap <IP-адрес_СОА> -v -sN -p <диапазон_портов> — для

сканирования при помощи TCP-пакета со сброшенными флагами (метод

NULL)

nmap <IP-адрес_СОА> -v -sX -p <диапазон_портов> — для

сканирования при помощи TCP-пакета со всеми установленными флагами

(метод XMAS)

9. Какие методы сканирования позволяют практически выявлять наличие от-

крытых портов? Как это зависит от используемой операционной системы?

Все ли указанные методы сканирования обнаруживает СОА Snort?

5. ОРГАНИЗАЦИЯ ВИРТУАЛЬНЫХ ЧАСТНЫХ СЕТЕЙ

5.1. Задачи, решаемые VPN

Защищенные компьютерные сети на сегодняшний день применяют тех-

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

экранирования, так и механизмы криптографической защиты сетевого трафи-

ка. Такая технология получила название VPN — Virtual Private Network (вир-

туальная частная сеть). В литературе (см. [

2]) встречаются различные опреде-

ления виртуальной частной сети. Мы будем использовать следующее. VPN —

это технология, объединяющая доверенные сети, узлы и пользователей через

открытые сети, к которым нет доверия. Основная идея данного определения

приведена на схеме (

рис. 5.1).

Рис. 5.1. Схема VPN

Предположим, имеются две локальных сети (LAN-1 и LAN-2, рис. 5.1),

принадлежащие одной организации (например, головной офис и филиал). Обе

эти локальные сети объединены при помощи иной сети, в большинстве случа-

ев для этого используется Интернет. С точки зрения пользователей соедине-

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

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

ких «черных ящиков», устанавливаемых на входе в каждую из них. Задача

этих «черных ящиков» так обработать идущий между ними сетевой трафик,

чтобы злоумышленник или просто внешний наблюдатель не мог совершить с

передаваемой информацией какого-либо действия, приводящего к ущербу. А

именно, не должен нарушить конфиденциальность, целостность и подлин-

ность информации. Иными словами, передаваемая информация, включая ад-

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

чески подписана. Кроме того, задача «черных ящиков» — защищать сами ло-

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

ким образом, внешний наблюдатель должен увидеть в сети лишь зашифро-

ванный обмен информацией между двумя «черными ящиками» и ничего бо-

лее.

Таким образом, можно сформулировать, что VPN призвана решать сле-

дующие задачи:

− обеспечивать защиту (конфиденциальность, целостность, подлинность)

передаваемой по сетям информации

. Как указывалось выше, данная задача

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

информации;

− выполнять защиту внутренних сегментов сети от НСД извне. Решение за-

дачи возможно благодаря встроенным в VPN-системы функциям межсетевого

экранирования, а также криптографическим механизмам, запрещающим не-

зашифрованный сетевой трафик;

− обеспечивать идентификацию и аутентификацию пользователей. Данная

задача возникает вследствие того, что, как сказано в определении VPN, в сети

должны взаимодействовать лишь доверенные узлы, доверие к которым воз-

можно после прохождения процедур идентификации и аутентификации.

Отдельно стоящей задачей, решаемой VPN, является экономия финан-

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

лиалами применяются не защищенные выделенные каналы связи, а Интернет.

Сформулируем ряд требований, которые предъявляются к программно-

аппаратным комплексам, реализующим VPN:

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

кальные сети без необходимости изменения структуры имеющейся VPN;

− интегрируемость, т. е. возможность внедрения VPN-системы в имею-

щуюся технологию обмена информацией;

− легальность и стойкость используемых крипоалгоритмов, т. е. система

должна иметь соответствующий сертификат, позволяющий ее использовать на

территории Российской Федерации с целью защиты информации ограничен-

ного доступа;

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

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

редачи;

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

сти технология VPN самостоятельно решать не может.

− унифицируемость, т. е. возможность устанавливать защищенные соеди-

нения с коллегами по бизнесу, у которых уже установлена иная VPN-система;

− общая совокупная стоимость, т. е. затраты на приобретение, развертыва-

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

формации, особенно если речь идет о защите коммерческой тайны.

5.2. Туннелирование в VPN

Как указывалось выше, основная задача, решаемая VPN, — скрыть пе-

редаваемый трафик. При этом необходимо скрыть как передаваемые данные,

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

ходимо обеспечить целостность и подлинность передаваемых данных. Для

защиты передаваемых данных и реальных IP-адресов применяются крипто-

графические алгоритмы. При отправке пакетов применяется туннелирование,

т. е. в пакетах, которые идут в открытой сети, в качестве адресов фигурируют

только адреса «черных ящиков». Кроме того, туннелирование предполагает,

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

осуществляется только тогда, когда он попадает в «туннель».

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

торые подлежат защите (

рис. 5.2). Для защиты применим криптографические

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

печить скорость обработки информации, то для зашифрования, естественно,

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

Известно, что применение симметричных алгоритмов шифрования тре-

бует решения задачи распространения симметричных ключей. Поэтому по-

ступим следующим образом: прикрепим симметричный ключ прямо к зашиф-

рованным с его использованием данным. Назовем симметричный ключ пакет-

ным ключом (его еще называют сеансовым ключом). Этот пакетный ключ бу-

дем генерировать случайным образом при отправлении каждого нового пакета

(тогда он действительно «пакетный» ключ). Либо будем его генерировать

также случайно при каждом сеансе обмена. Тогда данные всех пакетов, пере-

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

и это уже «сеансовый» ключ.

Конечно, нельзя отправлять пакетный ключ в открытом виде, прикреп-

ляя его к зашифрованным им данным. Следует его зашифровать. Воспользу-

емся тем, что ключ, в отличие от данных, — это лишь пара сотен бит (в зави-

симости от реализации, например, 256 бит — длина ключа алгоритма ГОСТ

28147-89, 56 бит — длина ключа алгоритма DES). Таким образом, можем

применить более медленные асимметричные алгоритмы и зашифровать с их

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

может быть применен и симметричный алгоритм. Ключ алгоритма шифрова-

ния пакетного ключа назовем ключом связи.

Данные IP-заголовок

Шифруются на пакетном ключе и подписываются ЭЦП

Данные IP-заголовок Пакетный ключ ЭЦП пакета

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

новый IP-пакет (IP-адреса устройств защиты)

Данные IP-заголовок Пакетный ключ ЭЦП пакета IP-заголовок

Аутентифицирующий заголовок

Рис. 5.2. Преобразование отправляемого пакета

Кроме того, для обеспечения целостности пакетов сгенерируем элек-

тронно-цифровую подпись (ЭЦП) нашего пакета и прикрепим ее к формируе-

мому пакету.

Совокупность ЭЦП и зашифрованного пакетного ключа называют ау-

тентифицирующим заголовком.

Для того чтобы отправить сгенерированный нами пакет, необходимо

добавить к нему IP-адреса источника и приемника. В случае туннеля этими

адресами будут адреса пограничных VPN-узлов. Если же защищается трафик

между двумя узлами без применения туннеля, то эти адреса совпадут с адре-

сами в исходном пакете.

Таким образом, исходный пакет защищен. Осталось выяснить ряд мо-

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

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

ные прикладного уровня либо относящиеся к транспортному или сетевому

уровню.

Чтобы ответить на второй вопрос, рассмотрим уровни защищенных ка-

налов.

5.3. Уровни защищенных каналов

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

лежат шифрованию в процессе организации VPN.

Рассмотрим упрощенную модель OSI, реализованную в стеке протоко-

лов TCP/IP. Эта модель предполагает наличие четырех уровней: прикладного,

транспортного, сетевого и канального. Соответственно, для каждого уровня

возможность шифрования передаваемой информации различна. Так, на при-

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

получаемой web-страницы. Однако факт передачи письма, т. е. диалог по про-

токолу SMTP скрыть невозможно. На транспортном уровне может быть вме-

сте с данными скрыт и тип передаваемой информации, однако IP-адреса полу-

чателя и приемника остаются открытыми. На сетевом уровне уже появляется

возможность скрыть и IP-адреса. Эта же возможность имеется и на канальном

уровне.

Чем ниже уровень, тем легче сделать систему, функционирование кото-

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

передаваемой информации можно скрыть.

Для каждого уровня модели разработаны свои протоколы (табл. 5.1).

Таблица 5.1

Уровни защищенных каналов и протоколы

Уровень

Протоколы

Прикладной S/MIME / PGP / SHTTP

Транспортный (TCP/UDP) SSL / TLS / SOCKS

Сетевой (IP) IPSec / SKIP

Канальный PPTP / L2F / L2TP

Так, на прикладном уровне для защиты электронной почты применяется

протокол S/MIME (Secure Multipurpose Internet Mail Extension) либо система

PGP. Для защиты обмена по протоколу HTTP применяется протокол SHTTP

(Secure HTTP). На данном уровне шифруется текст передаваемого почтового

сообщения или содержимое HTML-документа. Недостатками организации

VPN на базе протоколов прикладного уровня является узкая область действия,

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

ваться в соответствующие приложения. В пособии мы не будем подробно рас-

сматривать системы этого уровня.

На транспортном уровне чаще всего применяются протоколы SSL (Se-

cure Socket Layer) и его более новая реализация — TSL (Transport Layer Secu-

rity). Также применяется протокол SOCKS. Особенность протоколов транс-

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

шифрование осуществляется для передачи по протоколу HTTP (режим

HTTPS). Недостатком является невозможность шифрования IP-адресов и тун-

нелирования IP-пакетов.

На сетевом уровне используются два основных протокола: SKIP (Simple

Key management for Internet Protocol – простое управление ключами для IP-

протокола) и IPSec. На данном уровне возможно как шифрование всего тра-

фика, так и туннелирование, включающее скрытие IP-адресов. На сетевом

уровне строятся самые распространенные VPN системы.

Канальный уровень представлен протоколами PPTP (Point-to-Point Tun-

neling Protocol), L2F (Layer-2 Forwarding) и L2TP (Layer-2 Tunneling Protocol).

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

ний прикладного уровня, но и для служб сетевого и транспортного уровня. В

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

сетевого и транспортного уровня — это может быть не только IP-протокол, но

и протоколы IPX (применяется в локальных сетях с серверами на основе ОС

Novell Netware) и NetBEUI (применяется в локальных сетях Microsoft). Шиф-

рованию подлежат как передаваемые данные, так и IP-адреса.

В каждом из указанных протоколов по-разному реализованы алгоритмы

аутентификации и обмена ключами шифрования.

5.4. Защита данных на канальном уровне

На канальном уровне применяются упомянутые выше протоколы PPTP

(разработчик Microsoft), L2F (разработчик Cisco Systems) и L2TP (совместная

разработка Microsoft и Cisco Systems).

Протоколы PPTP и L2TP основываются на протоколе Point-to-Point

Protocol (PPP). PPP — протокол канального уровня, разработан для инкапсу-

ляции данных и их доставки по соединениям типа точка-точка.

В основе протокола PPTP лежит следующий алгоритм: сначала произ-

водится инкапсуляция данных с помощью протокола PPP, затем протокол

PPTP выполняет шифрование данных и инкапсуляцию. PPTP инкапсулирует

PPP-кадр в пакет Generic Routing Encapsulation (протокол GRE). Схема инкап-

суляции приведена на

рис. 5.3.

заголовок

GRE

заголовок

PPP

заголовок

TCP,

UDP

Данные

Рис. 5.3. Инкапсуляция в протоколе PPTP

К исходному отправляемому IP-пакету (обозначенному на рисунке се-

рым цветом) последовательно добавляются PPP-, GRE- и IP-заголовки. В но-

вом IP-пакете в качестве адресов указываются адреса туннелирующих узлов.

Протокол PPTP очень часто используется провайдерами Интернет при

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

пользователям назначается IP-адрес из диапазона «домашних» сетей (напри-

мер, 10.1.1.189 или 192.168.1.1). Сервер провайдера имеет два адреса — внут-

ренний (для «домашней» сети) и внешний («настоящий»). Когда пользователь

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

альный IP-адрес.

Внутри локальной сети между пользователем и PPTP-сервером цирку-

лируют IP-пакеты с внутренними IP-адресами, внутри которых инкапсулиро-

ваны пакеты с внешними адресами.

100

Source IP

195.12.90.175

Dest IP

194.226.237.16

Source Port

1134

Dest Port

110

Source IP

195.12.90.175

Dest IP

194.226.237.16

Source Port

1134

Dest Port

110

Рис. 5.4. Пакет протокола PPTP

На рис. 5.4 приведен пример обмена по протоколу POP3 (порт приемни-

ка 110), осуществляемого между удаленным POP3-сервером с адресом

194.226.237.16 и пользователем, которому назначен динамический адрес

195.12.90.175. В локальной сети видны пакеты протокола IP/GRE, проходящие

между узлами 10.1.1.189 (внутренний адрес пользователя) и 10.1.0.2 (внутрен-

ний адрес PPTP-сервера).

Обычно провайдеры не включают возможность шифрования и сжатия

инкапсулируемых пакетов, поэтому при анализе трафика в локальной сети со-

держимое IP/GRE-пакетов легко распознать и увидеть адреса, протокол и пе-

редаваемые данные.

Для шифрования передаваемых данных с использованием клиентов с

ОС Windows XP необходимо в настройках подключения указать пункт «Re-

quire Data Encryption» («Требовать шифрование данных»,

рис. 5.5).

В протоколе PPTP для аутентификации предусматриваются различные

протоколы аутентификации:

− Extensible Authentication Protocol (EAP),

− Microsoft Challenge Handshake Authentication Protocol (MSCHAP),

− Challenge Handshake Authentication Protocol (CHAP),

− Shiva Password Authentication Protocol (SPAP)

− Password Authentication Protocol (PAP)