А. Н. Андрончик, В. В. Богданов, Н. А. Домуховский, А. С. Коллеров, Н. И. Синадский, Д. А. Хорьков
 Скачать 9.2 Mb.
|
|
Задать домашнюю сеть (home network) -i Подключиться к сетевому интерфейсу номер -I Добавлять к предупреждению наименование интерфейса. -K -l Сохранять результаты регистрации в каталог -L -n Завершить работу программы после получения -N Не сохранять в файлах регистрации содержимого пакетов (со- храняется лишь текст предупреждений). -p Анализировать только пакеты, отправленные на локальный ад- рес, и широковещательные пакеты. -r Прочитать и обработать файл -S Установить значение переменной n файла правил, равной v. -U Записывать временные метки в универсальном скоординиро- ванном времени (UTC). -v Отображать на экране заголовки всех перехваченных пакетов. -V Показать версию Snort. -W Показать доступные сетевые интерфейсы. -X Сохранять в файле журнала регистрации событий содержимое перехваченных пакетов в «сыром» виде, начиная с уровня link модели OSI. 85 Параметр Описание -y Добавить месяц, день и год в отображаемые и сохраняемые временные отметки. -? Показать помощь по параметрам командной строки. Для проверки работоспособности СОА Snort рекомендуется выполнить следующие действия. ВЫПОЛНИТЬ! 1. Установить СОА Snort. 2. Вывести на экран список доступных сетевых интерфейсов командой snort –W 3. Запустить Snort на выбранном интерфейсе в режиме анализатора пакетов с выводом информации на экран, указав программе завершить работу после приема третьего пакета: snort –v –i 1 –n 3 4. Выполнить любые действия, которые приведут к отправке или приему се- тевых пакетов (например, отправить эхо-запрос на любой IP-адрес коман- дой ping). Убедиться, что пакеты перехватываются и отображаются на эк- ране. 4.5.3. Описание языка правил Рассмотрим краткое описание языка правил, на котором задаются сиг- натуры атак, обнаруживаемых СОА Snort. Полное описание языка правил со- держится в файле документации «с:\snort\doc\snort_manual.pdf» Правила записываются в одну строку, если возникает необходимость перенести текст правила на следующую строку, необходимо добавить в конце строки символ обратной косой черты «\». Правила состоят из двух частей: заголовка и набора атрибутов. Заголо- вок, в свою очередь, состоит из: 1. Указания действия, которое необходимо выполнить (alert, log, pass и др.). 2. Протокола (tcp, udp, icmp, ip). 3. IP-адреса и маски подсети источника и приемника информации, а также информации о портах источника и приемника. Действие alert заключается в генерации предупреждающего события и сохранении содержимого пакета для дальнейшего анализа. Действиеlog предполагает сохранение пакета без генерации предупреждения. Действие 86 pass означает пропуск пакета (его игнорирование). Существует также ряд более сложных действий, которые здесь не рассматриваются. Текст атрибутов располагается в скобках, каждая пара атрибут — зна- чение имеет вид <атрибут>: <значение>;. Значения строковых атрибутов записываются в кавычках. Рассмотрим пример простого правила (одна строка): alert <протокол> <адрес_подсети1>[/маска_подсети1] <порт1> <направление> <адрес_подсети2>[/маска_подсети2] <порт2> ([msg:"Текст сообщения";] [другие_атрибуты]) где − alert — действие, которое необходимо выполнить при обнаружении пакета, удовлетворяющего данному правилу, и которое заключается в генера- ции «предупреждения» — записи в журнале регистрации − <протокол> — наименование протокола (tcp, udp, icmp, ip) − <адрес_подсети>[/маска_подсети] — IP-адрес и маска подсети, либо IP-адрес узла участника обмена в формате: 192.168.247.0/24, либо 192.168.247.1 − <порт> — номер порта либо диапазон портов в формате 1:1024 для обозначения диапазона портов от 1 до 1024, 1024: — с номерами больше или равными 1024, или :1024 — меньше или равными 1024 соответственно − <направление> — обозначение направления в виде ->, <- или <> Вместо IP-адресов и номеров портов могут использоваться псевдонимы any, являющиеся заменителем любого значения. Атрибуты являются наиболее значимой частью правил, так как позво- ляют искать интересующую информацию в полях заголовков и содержимом пакетов. Существует четыре категории атрибутов: − meta-data — предоставляют информацию о правиле, но не влияют на процесс обнаружения; − payload — атрибуты данного типа предназначены для поиска информа- ции в «полезной нагрузке» (содержимом) пакета; − non-payload — предназначены для поиска информации в заголовках паке- тов; − post-detection — определяют поведение системы после обнаружения па- кета, удовлетворяющего правилу. В табл. 4.2 приведен неполный список атрибутов, которые могут быть использованы при написании правил. Если известно местонахождение интересующей информации в пакете, то целесообразно ограничить область поиска при помощи модификаторов offset и depth, так как это существенно сократит время, затрачиваемое на анализ пакета. 87 Таблица 4.2 Список атрибутов СОА Snort Атрибут Описание meta-data msg: "<текст>"; Сообщение, которое добавляется в журнал регист- рации при активации правила. sid: <идентификатор>; Уникальный номер, используемый для идентифи- кации правил. Идентификаторы от 100 до 1 000 000 используются для правил, включенных в дистрибутив Snort. Для локальных правил следует использовать значения больше 1 000 000. rev: <номер_редакции>; Целое число, служащее для обозначения номера редакции правила. classtype: <имя_класса>; Используется для обозначения класса атаки. Пол- ный список классов приведен в документации по Snort. priority: <приоритет>; Целое число, используемое для переопределения приоритета, задаваемого указанным ранее классом атаки, или для назначения приоритета новому правилу. Наивысший приоритет — 1, типичное значение атрибута составляет от 1 до 4. payload content: [!]"<строка>"; Позволяет искать заданную подстроку в содержи- мом полезной нагрузки пакета. Восклицательный знак означает отсутствие указанной информации в пакете. По умолчанию данный атрибут является чувствительным к регистру. Для обозначения дво- ичных данных следует использовать шестнадцате- ричные значения, отделенные вертикальными чер- тами: |00 5С|. Атрибут content имеет не- сколько модификаторов, которые могут распола- гаться следом за ним. nocase; Модифицирует стоящий ранее атрибут content, делая его нечувствительным к регистру. depth: <число_байт>; Значение атрибута (в байтах) определяет, как да- леко в полезной нагрузке пакета должен произво- диться поиск. 88 Атрибут Описание offset: <число_байт>; Значение атрибута определяет, сколько байтов по- лезной нагрузки следует пропустить. Поиск будет вестись, начиная с число_байт+1-го байта. distance: <число_байт>; Атрибут похож на depth, но указывает, сколько байт необходимо пропустить после предыдущей совпавшей подстроки перед продолжением поис- ка. within: <число_байт>; Атрибут указывает системе искать совпадения лишь в первых число_байт, начиная с конца предыдущей совпавшей подстроки. non-payload dsize: <размер>; Сравнить размер полезной нагрузки с заданным. Возможно указание диапазонов значений с ис- пользованием знаков >, < и <>. Например: >128, 300<>500 (от 300 до 500). flags: [!|*|+]<флаги> Проверить, установлены ли указанные флаги в принятом TCP-пакете. Флаги записываются под- ряд без пробелов и обозначаются следующим об- разом: F — FIN (LSB в байте флагов) S — SYN R — RST P — PSH A — ACK U — URG 1 — Резерв 1 (MSB в байте флагов) 2 — Резерв 2 0 — флаги не установлены Могут быть дополнительно использованы сле- дующие модификаторы: ! — указанные флаги не установлены * — установлен хотя бы один из указанных + — установлены указанные и любые другие itype: <тип>; Сравнить тип ICMP сообщения с указанным. Воз- можно указание диапазонов значений с использо- ванием знаков >, < и <> (см. выше). icode: <код>; Сравнить код ICMP сообщения с указанным. 89 Вместо IP-адресов могут использоваться переменные, заданные выше по тексту следующим образом: var <имя_переменной> <значение_переменной> Чтобы сослаться на переменную далее в тексте, перед ее именем следу- ет поставить знак доллара $. В текст файла правил можно включать комментарии, которые отделя- ются знаком #. Вся информация справа от этого знака и до конца строки счи- тается комментарием и не интерпретируется системой: #<комментарий> Рассмотрим пример задания двух переменных последующего их ис- пользования в правиле, фильтрующем входящие ICMP-пакеты ECHO (тип 8): # Глобальные переменные var HOME_NET 192.168.247.1 var EXTERNAL_NET !$HOME_NET # Обнаружение эхо-запросов (ping'ов) alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"Incoming ECHO REQUEST"; itype: 8;) 4.5.4. Использование СОА Snort СОА Snort можно использовать как анализатор трафика, обладающий значительными возможностями по фильтрации пакетов. Например, можно создать файл с правилами, использующими исключительно действия типа log. В результате из входящего потока данных будут отобраны и сохранены пакеты, удовлетворяющие указанным правилам. Так как по умолчанию жур- нал ведется в двоичном формате tcpdump, он может быть импортирован почти всеми специализированными программами анализа трафика. Обычно эти про- граммы позволяют наглядно отображать содержимое пакетов, но не обладают такими возможностями по их фильтрации, как Snort. Для запуска Snort в режиме анализатора трафика, как и для запуска его в режиме системы обнаружения атак, необходимо выполнить следующую ко- манду в командной строке Windows: snort -i <интерфейс> -c <файл_конфигурации> -l <путь_к_журналу> где <интерфейс> — номер интерфейса, полученный в результате выполнения команды snort –W 90 <файл_конфигурации> — путь к файлу, в котором хранятся настройки программы и правила обнаружения <путь_к_журналу> — путь к каталогу, в котором необходимо сохранить файл журнала Пример: snort -i 3 -c ../etc/my.conf -l ../log Следует обратить внимание, что при записи пути используются не об- ратные, а прямые «косые черты». Для завершения работы СОА Snort, необходимо нажать клавиши Рассмотрим несколько правил (табл. 4.3), которые позволят обнаружи- вать атаки, описанные в разделе 2. Текст правил должен записываться в одну строку. Таблица 4.3 Примеры правил СОА Snort № Описание Правило 1 Обнаружение входящих ECHO-запросов (ping’ов) alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg: "Incoming ECHO REQUEST"; itype: 8;) 2 Обнаружение исходящих ECHO-ответов alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg: "Outgoing ECHO REPLY"; itype: 0;) 3 Обнаружение больших ICMP-пакетов (атака «Ping of Death») alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg: "Incoming large ICMP packet"; dsize: >800;) 4 DoS-атака Winnuke alert tcp $EXTERNAL_NET any -> $HOME_NET 135:139 (msg: "DoS Winnuke attack"; flags: U+;) 5 Запрос на подключение к 139 порту (служба SMB) из внешней сети (два ва- рианта) alert tcp $EXTERNAL_NET any -> $HOME_NET 139 (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 139 (msg:"NETBIOS SMB IPC$ share access (unicode)"; flags: A+; content: "|00|"; offset: 0; depth: 1; content: "|FF|SMB|75|"; offset: 4; depth: 5; content: 91 № Описание Правило "|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 6. Добавить в файл «my.conf» правило, позволяющее обнаруживать входящие ECHO-запросы. Проверить, происходит ли обнаружение, запустив СОА из каталога «\snort\bin» следующей командой (из «командной строки»): snort -i <интерфейс> -c ../etc/my.conf -l ../log Для проверки выполнить несколько ECHO-запросов с другого компьютера, используя команду: ping 7. Дополнить файл «my.conf» правилами, указанными в табл. 4.3. Для про- верки обнаружения подключений к службе SMB использовать команду: net use \\ 92 К какому порту производится подключение? Как это зависит от исполь- зуемой операционной системы? 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 } 93 При данной настройке Snort будет выявлять все описанные в разделе 2 методы сканирования портов. Необходимо отметить, что две и больше проце- дуры сканирования портов, выполненные во время одного сеанса работы Snort, будут отражены в файле регистрации событий только один раз. Это ос- тается справедливым даже в том случае, когда используются разные методы сканирования. Таким образом, для поверки возможности обнаружения скани- рования, выполняемого разными методами, Snort необходимо закрывать и за- пускать снова. ВЫПОЛНИТЬ! 8. Дополнить файл «my.conf» приведенными выше строками для настройки препроцессора sfPortscan. С использованием утилиты nmap проверить, происходит ли обнаружение попыток сканирования портов защищаемого узла. Использовать следующие команды для запуска сканирования: nmap NULL) nmap (метод XMAS) 9. Какие методы сканирования позволяют практически выявлять наличие от- крытых портов? Как это зависит от используемой операционной системы? Все ли указанные методы сканирования обнаруживает СОА Snort? 94 5. ОРГАНИЗАЦИЯ ВИРТУАЛЬНЫХ ЧАСТНЫХ СЕТЕЙ 5.1. Задачи, решаемые VPN Защищенные компьютерные сети на сегодняшний день применяют тех- нологию защиты информации, включающую в себя как элементы межсетевого экранирования, так и механизмы криптографической защиты сетевого трафи- ка. Такая технология получила название VPN — Virtual Private Network (вир- туальная частная сеть). В литературе (см. [2]) встречаются различные опреде- ления виртуальной частной сети. Мы будем использовать следующее. VPN — это технология, объединяющая доверенные сети, узлы и пользователей через открытые сети, к которым нет доверия. Основная идея данного определения приведена на схеме (рис. 5.1). Рис. 5.1. Схема VPN Предположим, имеются две локальных сети (LAN-1 и LAN-2, рис. 5.1), принадлежащие одной организации (например, головной офис и филиал). Обе эти локальные сети объединены при помощи иной сети, в большинстве случа- ев для этого используется Интернет. С точки зрения пользователей соедине- ния могут устанавливаться между любыми узлами этих локальных сетей. На самом же деле реальные соединения устанавливаются через посредников, не- ких «черных ящиков», устанавливаемых на входе в каждую из них. Задача этих «черных ящиков» так обработать идущий между ними сетевой трафик, чтобы злоумышленник или просто внешний наблюдатель не мог совершить с 95 передаваемой информацией какого-либо действия, приводящего к ущербу. А именно, не должен нарушить конфиденциальность, целостность и подлин- ность информации. Иными словами, передаваемая информация, включая ад- реса ее получателя и отправителя, должна быть зашифрована и криптографи- чески подписана. Кроме того, задача «черных ящиков» — защищать сами ло- кальные сети от несанкционированного доступа к ним из глобальной сети. Та- ким образом, внешний наблюдатель должен увидеть в сети лишь зашифро- ванный обмен информацией между двумя «черными ящиками» и ничего бо- лее. Таким образом, можно сформулировать, что VPN призвана решать сле- дующие задачи: − обеспечивать защиту (конфиденциальность, целостность, подлинность) передаваемой по сетям информации 1 . Как указывалось выше, данная задача решается применением криптографического метода защиты передаваемой информации; − выполнять защиту внутренних сегментов сети от НСД извне. Решение за- дачи возможно благодаря встроенным в VPN-системы функциям межсетевого экранирования, а также криптографическим механизмам, запрещающим не- зашифрованный сетевой трафик; − обеспечивать идентификацию и аутентификацию пользователей. Данная задача возникает вследствие того, что, как сказано в определении VPN, в сети должны взаимодействовать лишь доверенные узлы, доверие к которым воз- можно после прохождения процедур идентификации и аутентификации. Отдельно стоящей задачей, решаемой VPN, является экономия финан- совых ресурсов организации, когда для обеспечения защищенной связи с фи- лиалами применяются не защищенные выделенные каналы связи, а Интернет. Сформулируем ряд требований, которые предъявляются к программно- аппаратным комплексам, реализующим VPN: − масштабируемость, т. е. возможность со временем подключать новые ло- кальные сети без необходимости изменения структуры имеющейся VPN; − интегрируемость, т. е. возможность внедрения VPN-системы в имею- щуюся технологию обмена информацией; − легальность и стойкость используемых крипоалгоритмов, т. е. система должна иметь соответствующий сертификат, позволяющий ее использовать на территории Российской Федерации с целью защиты информации ограничен- ного доступа; − пропускная способность сети, т. е. система не должна существенно уве- личивать объем передаваемого трафика, а также уменьшать скорость его пе- редачи; 1 Заметим, что классическую задачу защиты информации в виде обеспечения ее доступно- сти технология VPN самостоятельно решать не может. 96 − унифицируемость, т. е. возможность устанавливать защищенные соеди- нения с коллегами по бизнесу, у которых уже установлена иная VPN-система; − общая совокупная стоимость, т. е. затраты на приобретение, развертыва- ние и обслуживание системы не должны превосходить стоимость самой ин- формации, особенно если речь идет о защите коммерческой тайны. |