S

^ nort- это бесплатная система обнаружения вторжений с открытым исходным кодом, разработанная Мартином Рошем (Martin Roesch). Первоначально Мартин создал Snort для перехвата трафика при своей повседневной работе, а затем она была улучшена до многофункциональной сетевой системы обнаружения вторжений. Мартину удалось завоевать симпатии многих программистов, коллективные усилия которых позволили усовершенствовать программный код программы и выпустить ее новые версии. В начале 2002 года за одну неделю программа Snort была загружена более 10000 раз для защиты сетей правительственных организаций и учебных учреждений, корпоративных сетей и компьютеров домашних пользователей.

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

В марте 2002 года (на момент выхода английского издания этой книги) последней версией Snort была 1.8.3, которая в сжатом виде занимала 1,8 Мбайт. Она полностью переносима и может работать приблизительно на 23 различных платформах, включая Linux, Solaris, BSD, IRIX, HP-UX, Mac OS X и Win 32. Система Snort легко настраивается и позволяет пользователям создавать собственные сигнатуры и изменять исходные функциональные возможности с помощью подключаемых модулей. Подключаемый модуль - это программный код, который по желанию может быть скомпилирован совместно с программой Snort во время установки и позволяет расширить возможности базовой программы, например организовать ответные действия против отправителя вредоносного трафика.

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

Режимы запуска Snort

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

Запуск Snort обычно выполняется из командной строки, независимо от того, на каком хосте (Windows или UNIX) она запущена. Специальная программа ID-Scenter предоставляет графический пользовательский интерфейс для пользователей Windows-хостов, a Demarc/Puresecure позволяет работать в графическом пользовательском интерфейсе как на Windows-, так и на UNIX-системах. Существует множество параметров командной строки, которые можно использовать при запуске Snort, но самым востребованным является параметр (-с snort. conf), применяемый для запуска Snort в режиме сетевой системы обнаружения вторжений (NIDS-режим). При этом происходит обращение к файлу конфигурации. Информация этого файла позволяет настроить работ)' Snort, в том числе присвоить значения для переменных в правилах, указать Snort на необходимость использования тех или иных препроцессоров и правил для анализа трафика. Исходный конфигурационный файл snort. conf сохраняется в каталоге установки Snort. Пользователь должен отредактировать этот файл в соответствии с задачами своего узла.

Если система Snort запущена в NIDS-режиме, по умолчанию отчеты о событиях, которые соответствуют заданным сигнатурам, сохраняются в нескольких файлах. Snort позволяет для каждого правила задать действие, выполняемое системой при обнаружении пакета, который соответствует этому правилу. Предупреждение (alert) определяет запись пакета в файл alert, который по умолчанию создается в каталоге /var/log/snort многих UNIX-систем. На Windows-хостах файл alert создается в подкаталоге log того каталога, из которого запускается программа Snort. Рассмотрим примеры записей в файле alert системы Snort.

[**] NMAP TCP ping [**]

03/21 - 13:33.51:880120 1.2.3.4:1029 -? 192.168.5.5:80

TCP TTL:46 TOS:0x0 ID:19678

Seq. 0XE4F00003 Ack: 0x0 Win: OxCOO

Можно сформулировать сообщение, которое будет выдаваться на экран при появлении предупреждения. Это уведомление не является обязательным, но позволяет проинформировать аналитика о возникшей проблеме. Для приведенного выше предупреждения использовалось сообщение “NMAP TCP ping”. В следующей строке указаны дата и время события, IP-адрес (1. 2 . 3 .4) и порт (1029) отправителя, направление трафика (отправитель слева от “стрелки”, а получатель - справа), 1Р-адрес (192.168.5.5) и порт (8 0) получателя, указанные в опасном пакете. Третья строка содержит тип вложенного пакета (TCP-сегмент), значения полей TTL (46), TOS (0), а также идентификатор (19678). В последней строке перечислены установленные TCP-флаги (символ А обозначает установленный флаг АСК), затем следует значение порядкового номера в шестнадцатеричном формате и размер окна. Вся эта информация позволяет больше узнать о пакете, вызвавшем предупреждение.

Предупреждение регистрируется в результате “срабатывания” правила при получении TCP-сегмента с установленным флагом АСК и значением номера подтверждения, равным 0. В большинстве случаев подобный пакет является характерным признаком попытки сканирования nmap с целью выявления активного хоста. Если пакет с установленным флагом АСК достигнет хоста-получателя, то он должен ответить на незапрошенное подтверждение пакетом с установленным флагом RESET, независимо от того, открыт запрошенный порт или нет. Поэтому предупреждению сопутствует сообщение “NMAP TCP ping”.

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

[**] Attempted anonymous ftp access [**]

04/24-12:11:08.724441 192.168.143.15:3484 -> 192.168.143.16:21 TCP TTL:64 TOS:0x10 ID:30124 DF

*****рд* seq: 0Х93ЕЕ0АВ7 Ack 0xB8352E61 Win: 0x7D78 TCP Options => NOP NOP TS: 112024246 27551686

55 53 45 52 20 61 6E 6F 6E 79 6D 6F 75 73 0D 0A USER anonymous..

Сохраненный отчет содержит ту же информацию, что выдается при предупреждении, а также предоставляет сведения о полезной нагрузке при использовании в командной строке параметра -d. Это сообщение указывает на присутствие правила, которое определяет фильтрацию анонимного FTP-трафика к порту 21. Более подробный анализ подобных сообщений содержится в главе 14, “Параметры правил Snort”, но по полезной нагрузке зарегистрированного пакета сразу можно сказать, что была предпринята попытка доступа к анонимному FTP-

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

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

Правила Snort

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

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

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

Возможность анализировать любое поле пакета является отличительной чертой системы Snort. Существует множество различных параметров, позволяющих задать в правиле Snort любое поле и проверить его значение. Кроме того, если несколько полей не могут быть проверены с помощью доступных параметров создания правил, то Snort помогает проанализировать их с помощью фильтра, указываемого в конце командной строки, или параметра -F, который позволяет использовать сохраненные в файле фильтры BPF (Berkeley Packet Filters). Фильтры BPF мы ранее называли фильтрами TCPdump. С их помощью в пакете конкретного протокола можно определить значение интересующего поля. Например, в Snort нет специального параметра для проверки значения поля “Версия IP”, которое занимает старший полубайт нулевого байта IP-заголовка. С помощью BPF-фильтра система Snort может исследовать пакеты прямо из сети или из двоичного файла данных TCPdump, чтобы найти все пакеты, в которых указанное значение версии IP не равно 4. Для анализа пакетов, перехваченных из сети, можно использовать следующую команду, snort -V 'ip [ О] & OxfO != 0x4 0'

Как уже было подробно рассказано в главе 12, “Создание фильтров TCPdump”, использованный здесь фильтр, позволяет замаскировать младший полубайт нулевого байта IP-заголовка и проверить, равно ли значение старшего полубайта 4. Результаты анализа выводятся на экран (параметр -v).

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

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

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

Скрытые сигнатуры

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

Первым делом я спросил, есть ли способ узнать активные сигнатуры? Представитель клиента возмутился и спросил, зачем мне это нужно. “Мне необходимо знать, является атака настоящей или имеет место ложная тревога", - вежливо ответил я. В ответ я услышал, что, если я считаю, что столкнулся с редким случаем ложной тревоги, то могу позвонить в службу поддержки и попросить о помощи. При том количестве ложных тревог, которое генерировала система обнаружения вторжений этого поставщика, я мог только вообразить, что бы произошло, если бы эта глупость стала реальностью. Я с негодованием продолжал настаивать и спросил, почему же все-таки мне нельзя увидеть сигнатуры? Ответ был следующим: “Если вы узнаете наши сигнатуры - их смогут узнать хакеры!”. Честное слово, это было самое нелепое объяснение, какое я только слышал. Я стал догадываться, что на самом деле он боится, чтобы сигнатуры его программы не узнали конкуренты, но не решается этого сказать. Как вы считаете, следует серьезно воспринимать таких людей и их "собственные” сигнатуры? К сожалению, мы не всегда можем оказывать влияние на решение о покупке той или иной системы обнаружения вторжений. Что если вы работаете в сети, в которой установлена NIDS, ограничивающая просмотр активных сигнатур и перехваченного трафика или не допускающая его? Вы безропотно примиритесь с такой ситуацией? Нет, следует проявить изобретательность и попытаться улучшить работу NIDS. Всегда можно запустить TCPdump в фоновом режиме, одну или совместно с системой Shadow. Кроме того, можно попытаться внести правки в выдаваемые отчеты с помощью других источников информации, например брандмауэров, маршрутизаторов или журналов хостов. Конечно, такое решение не идеально, но очевидно лучше, чем полное неведение.

Мы запустили Shadow совместно с системой обнаружения вторжений этого клиента. Через некоторое время мне сообщили, что система обнаружения вторжений выявила проводимую атаку Loki, и попросили проверить отчеты TCPdump, чтобы определить, была ли эта атака действительно, или тревога была ложной. Я помнил, что много лет назад стандартной сигнатурой атаки Loki было значение OxfOOl или 0x01f для порядкового номера ICMP-сообщения. Мне сообщили IP-адреса отправителя и получателя подозрительных пакетов. Просмотрев записи TCPdump, я обнаружил нужный отчет. Оказалось, что в данном случае имело место случайное использование этих значений для порядкового номера обычной пары эхо-запроса и эхо-ответа ICMP. Этот метод определения ложной тревоги был слишком трудным и потребовал много времени, но оказался лучше, чем полное доверие данной NIDS.

Создание правила Snort

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

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

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

Кроме того, если система Snort определяет, что пакет удовлетворяет первому правилу, то остальные правила уже не проверяются. Порядок правил, в котором они указаны в файлах, имеет определенное значение, но все же Snort зачастую самостоятельно решает, какое правило должно иметь приоритет. По умолчанию Snort располагает правила в порядке заданных ответных действий: предупреждение, пропуск и регистрация. Этот порядок можно изменить с помощью параметра командной строки. Однако Snort этим не ограничивается и систематизирует правила, объединяя их по одинаковым заголовкам (более подробную информацию по этой теме можно получить по адресу www. snort .org/docs/faq.html#3 .13).

Рассмотрим пример правила Snort (рис. 13.1). Заголовок этого правила содержит сведения о действиях, которые должны быть предприняты при выявлении пакета, соответствующего правилу, и информацию об отправителе и получателе этого пакета. В данном случае должно выдаваться предупреждение (alert), если поступает ТСР-трафик из любого порта хостов сети, отличной от 10.1.1.x, на любой порт локальной сети (мы считаем локальной сеть 10.1.1.x). Таким образом, правило сработает при попытке установить TCP-соединение любым удаленным хостом.

Рис. 13.1. Строение правила Snort

Теперь рассмотрим параметры правила, чтобы узнать, какими особенностями должны обладать подозрительные пакеты. В данном случае должна присутствовать нестандартная комбинация ТСР-флагов: SYN и FIN, и, если они будут обнаружены, в качестве предупреждения должно выводиться сообщение “SYN-FIN scan” (“сканирование с помощью пакетов с установленными флагами SYN и FIN”). В следующих разделах будут более подробно рассмотрены ключевые слова, используемые при создании правил Snort.

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

Поля заголовка правила

Как мы уже рассказали, в заголовке правила указывается, какое действие должно выполняться при его “срабатывании”, протокол и заданные IP-адреса, а также порты отправителя и получателя. При соблюдении всех этих условий будут проверены параметры правил (параметры правил Snort подробно рассмотрены в главе 14, “Параметры правил Snort”).

Поле “Действие”

Поле “Действие” (Action) является первым полем в заголовке правила. В этом поле Snort уведомляется о том, какое действие должно выполняться при “срабатывании” правила. Ниже перечислены доступные значения для этого поля.

■ Alert (предупреждение). Если в поле “Действие” содержится это значение, то при получении пакета, соответствующего данному правилу, Snort создает запись в специальном файле (файл регистрации предупреждений) и регистрирует этот пакет. По умолчанию информация, сохраняемая в файле регистрации предупреждений, представляет собой копию заголовка подозрительного пакета. Регистрация пакета заключается в сохранении этой же информации в отдельном файле в создаваемом каталоге, имя которого обычно совпадает с IP-адресом отправителя подозрительного пакета (при использовании в командной строке параметра - d может также сохраняться полезная нагрузка пакета).

■ Log (регистрация). Это значение поля определяет только регистрацию пакета, удовлетворяющего правилу. Записи в файл регистрации предупреждений (alert file) не добавляются. В файлы регистрации (log file) могут записываться данные вложенного пакета, если в командной строке будет указан параметр -d.

■ Pass (пропуск). Если полученному пакету соответствует правило, в поле “Действие” которого содержится значение pass, система Snort прекращает исследование пакета. Это может пригодиться, например, при отслеживании попыток установить анонимное соединение с обычным (неанонимным) FTP-сервером. В этом случае можно сформулировать правило, которое бы позволило организовать прохождение пакетов с попытками анонимного подключения к анонимному FTP-серверу локальной сети. Второе правило предупреждения позволит выявить все остальные попытки анонимных FTP-соединений.'

■ Activate (запуск). Это значение позволяет не только выдать предупреждение, но и запустить другие (динамические) правила.

■ Dynamic (динамическое). Правила с этим значением поля “Действие” остаются неактивными до тех пор, пока не будут выполнены правила со значением activate. После активирования этих правил их действия аналогичны обычным правилам регистрации.

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

Кроме того, можно определить собственные действия, что позволяет указать, куда следует вывести информацию о “срабатывании” правила. Здесь мы не станем рассматривать такие возможности, а все желающие могут получить интересующую информацию на официальном сайте Snort (www. snort. org). Как уже указывалось, по умолчанию правила выполняются в следующем порядке: предупреждение, пропуск, регистрация. Изменить этот порядок позволяет параметр -о в командной строке запуска Snort. Параметр -о позволяет организовать обработку первыми правил пропуска, затем - правил предупреждения и последними - регистрации. Принятая по умолчанию последовательность выполнения правил предназначена для неопытных пользователей и не позволяет случайно заданному правилу пропуска отключить все предупреждения и регистрацию опасных пакетов.

Поле “Протокол”

Информация этого поля указывает Snort на то, пакеты какого протокола следует проверять. Snort поддерживает работу со следующими протоколами: TCP, UDP, ICMP и IP. В будущем планируется добавить поддержку ARP, RARP, GRE, OSPF, RIP и IPX. Система Snort работает с дейтаграммами протокола IP только версии 4, поэтому она не определит использование для пакета протокола IPv6. Snort не поддерживает спецификацию IPSec, поэтому не способна расшифровать 'информацию полей пакетов этого набора протоколов.

Поля “IP-адрес отправителя” и “IP-адрес получателя”

По информации полей IP-адресов отправителя и получателя можно определить, откуда исходит и куда направляется подозрительный трафик. В качестве IP-адресов может быть указан IP-адрес хоста, подсети или нескольких хостов или подсетей. IP-адреса записываются согласно простому и понятному стандарту записи CIDR (Classless Inter-Domain Routing - бесклассовая междоменная маршрутизация). Этот формат записи содержит необходимый IP-адрес и количество битов, используемое для маски подсети. Давайте рассмотрим этот формат на примере нескольких 1Р-адресов.

Формат:

адрес/маска_подсети или any или [адрес/маска_подсети, адрес/маска_подсети] адрес = х.х.х.х маска подсети = количество битов сетевой части адреса 24.0.0.0/8 = Сеть класса А

135.1.0.0/16 = Сеть класса В

192.168.5.0/24 = Сеть класса С

192.168.5.5/32 = Адрес хоста

Ключевые слова:

any - все возможные адреса;

! - символ отрицания;

$HOME_NET - переменная, значение которой определено в файле правила.

Таким образом формат CIDR определяет базовый адрес и количество битов, которое отведено для хранения сетевой части адреса. Например, запись 24 . 0 . 0 . 0/8 означает, что это адрес сети класса А, первый байт которого (24) является сетевой частью адреса, а остальные байты используются для обозначения хостов этой сети. Хотя в наших примерах использованы стандартный формат CIDR для сетей классов А, Б и С, основное преимущество этого формата заключается в том, что разделительная линия между сетевой и узловой частью адреса может отделять любое число битов 32-разрядного IP-адреса, и не обязательно разделять его по байтам.

Можно задать перечень контролируемых IP-адресов, указав их в квадратных скобках и разделив запятыми (никакие пробелы не допускаются). Например, если необходимо отслеживать трафик, предназначенный хосту 1. 2 . 3 . 4 и подсети 2.3.4.x, можно использовать следующую запись.

[1.2.3.4,2.3.4.0/24]

Ключевое слово any означает любой IP-адрес. Символ отрицания (!) позволяет сделать в правиле исключение для какого-то IP-адреса. И, наконец, можно за давать IP-адреса с помощью значения переменной, что обеспечивает дополнительную гибкость и переносимость правил. Для указания адреса локальной сети в правилах Snort часто применяется переменная $HOME_NET. Можно использовать любое другое имя переменной, но так как во многих правилах уже существуют ссылки на переменную $HOME_NET, то лучше воспользоваться именно ею. Эта переменная должна быть определена в файле правила, в конфигурационном файле или в командной строке (с помощью параметра -S) до ее использования. Переменные могут использоваться и в других полях правил Snort.

Поля “Порт отправителя” и “Порт получателя”

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

статический порт Ш

все порты any

диапазон 33000:34000

исключение !80

меньше или равно : 10 2 3

больше или равно 1024:

Первый пример соответствует указанию номера статического порта, например, порта 111, который обычно используется RPC-службой portmapper. Как и для IP-адресов ключевое слово any позволяет обозначить все возможные порты. Также может быть указан диапазон контролируемых портов, например 33000-34000 (33000:34000) для выявления действий UNIX-программы Traceroute. С помощью символа отрицания можно организовать исключение конкретного порта из контролируемого диапазона (! 80). Можно задать проверку пакетов для портов, номера которых меньше (:1023) или больше (1024:) определенного значения, например для проверки доступа к временным портам. Кроме того, можно задать номер порта как переменную, значение которой должно быть присвоено до ссылки на эту переменную.

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

Указатель направления

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

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

Резюме

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

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

Tcp-фильтры программы tcpdump | Обнаружение нарушений безопасности в сетях | Параметры правил snort


Обнаружение нарушений безопасности в сетях



Новости за месяц

  • Сентябрь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс