Snort использует простой язык описания правил с широкими возможностями и достаточной гибкостью. Ниже приводится множество примеров, которые помогут разобраться с правилами Snort.
Большинство правил Snort записывается в одну строку. В прежних версиях программы (до 1.8) запись правила в одну строку была обязательной, но в современных вариантах программы допускается запись одного правила в несколько строк, если все строки, за исключением последней, завершаются символом \.
Каждое правило Snort делятся на две части – заголовков и опции. Заголовок правила включает действие, протокол, IP-адреса и маски для отправителя и получателя, а также номера портов отправителя и получателя. Опции правила включают сообщение и информацию о том, какие части пакета следует проверить, чтобы определить следует ли применять по отношению к пакеты заданное действие.
Ниже показан пример простого правила Snort
alert tcp any any -> 192.168.1.0/24 111 \
(content:”|00 01 86 a5|”; msg:”mountd access”;)
Опции правила указываются в круглых скобках, слова, за которыми следует двоеточие, являются ключевыми.
При соблюдении всех указанных в правиле условий по отношению к пакету выполняется заданное правилом действие (генерация сигнала в приведенном примере).
Заголовок правила имеет вид
<действие> <протокол> <отправитель> <порт> <направление> <получатель> <порт>
Заголовок правила содержит ключевое слово, которое определяет действие, выполняемое при совпадении всех заданных правилом условий. Действие всегда указывается первым и может быть одним из ключевых слов
alert – генерировать сигнал с использованием выбранного метода и записать информацию о пакеты в журнальный файл;
log – записать информацию о пакеты в журнальный файл;
pass – пропустить (игнорировать) пакет;
activate – генерировать сигнал и активизировать другое динамическое правило;
dynamic – правило не выполняет никаких действий до его активации с помощью действия activate в другом правиле, а при активации действует как log.
Можно также создавать свои типы правил (ruletype) и связывать с ними подключаемые модули (plugin), используя в дальнейшем такие правила как действия Snort. В приведенном примере создается тип правила для записи пакетов
ruletype suspicious
{
type log
output log_tcpdump: suspicious.log
}
Во втором примере создается тип правила, который будет записывать информацию в syslog и базу данных MySQL
ruletype redalert
{
type alert
output alert_syslog: LOG_AUTH LOG_ALERT
output database: log, mysql, user=snort dbname=snort host=localhost
}
Следующее поле заголовка указывает протокол. Snort в настоящее время различает 4 протокола - tcp, udp, icmp и ip. В будущем планируется включить также протоколы ARP, IGRP, GRE, OSPF, RIP, IPX и т. п.
После протокола в правиле указываются адреса и номера портов для данного правила. Ключевому слову any будут соответствовать все адреса IP (0.0.0.0/0). Snort не поддерживает механизма определения адресов по именам хостов, поэтому в правилах должны указываться адреса IP или блоки CIDR [RFC1518]. Блок CIDR показывает префикс сети и размер маски, которая будет применяться правилом к адресам во всех пакетах для проверки соответствия указанному префиксу. Блок CIDR /24 указывает сеть класса C, /16 – класса B, а /32 указывает адрес отдельного хоста. Например, запись 192.168.1.0/24 будет соответствовать адресам в диапазоне 192.168.1.0 - 192.168.1.255. Нотация CIDR обеспечивает краткий и удобный способ представления непрерывных блоков сетевых адресов.
Приведенному ниже правилу будут соответствовать пакеты, отправленные с любого (any) адреса в сеть класса C 192.168.1.0
alert tcp any any -> 192.168.1.0/24 111 \
(content:”|00 01 86 a5|”; msg:”mountd access”;)
Применительно к адресам и блокам может использоваться оператор отрицания !. При использовании этого оператора правилу будут соответствовать пакеты, которые не попадают в указанный диапазон адресов. Например, правилу
alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 111 \
(content:”|00 01 86 a5|”; msg:”mountd access”;)
будут соответствовать пакеты, отправленные в сеть класса C 192.168.1.0 из всех остальных сетей (не 192.168.1.0/24).
Адреса можно задавать также в виде списка, заключенного в квадратные скобки и разделенного запятыми. Правилу
alert tcp ![192.168.1.0/24,10.1.1.0/24] any -> [192.168.1.0/24,10.1.1.0/24] 111 \
(content:”|00 01 86 a5|”; msg:”mountd access”;)
будут соответствовать пакеты, направленные в сети класса C 192.168.1.0 и 10.1.1.0 из всех прочих сетей.
Номера портов можно задавать в виде конкретного значения, диапазона, списка или ключевого слова any (любой порт). Для портов также поддерживается оператор отрицания. Для задания диапазона указываются верхний и нижний пределы, разделенные двоеточием (:). Граничные значения включаются в диапазон. Правилу
log udp any any -> 192.168.1.0/24 1:1024 log udp
будут соответствовать все пакеты UDP, адресованные в порты с 1 по 1024 хостов сети класса C 192.168.1.0. Если одна из границ диапазона не задана вместо нее используется минимальный (0) или максимальный (65535) номер порта. Правилу
log tcp any any -> 192.168.1.0/24 :6000
будут соответствовать пакеты TCP, адресованные в порты с номерами не более 6000 сети класса C 192.168.1.0. Более сложному правилу
log tcp any :1024 -> 192.168.1.0/24 500:
будут соответствовать пакеты TCP, направленные из портов с номерами не более 1024 в порты с номерами от 500 и выше всех хостов сети класса C 192.168.1.0. Оператор отрицания позволяет задать соответствие всем номерам портов за исключением указанных в правиле. Например, правилу
log tcp any any -> 192.168.1.0/24 !6000:6010
будут соответствовать пакеты TCP направленные с любого адреса в сеть класса C 192.168.1.0 и адресованные в любые порты, за исключением портов X Window (6000 – 6010). Отметим, что оператор отрицания недопустимо использовать применительно к ключевому слову any.
Оператор направления -> показывает направление передачи трафика для данного правила. Адреса и порт слева от этого оператора относятся к отправителю, а справа – к получателю пакетов. Можно также создавать “двунаправленные” правила с помощью оператора <>. В этом случае каждая из пар “адрес-порт” будет трактоваться программой Snort как отправитель и как получатель. Такие правила удобны для анализа пакетов в сеансовых соединениях (например, POP3). Пример двунаправленного правила показан ниже.
log tcp !192.168.1.0/24 any <> 192.168.1.0/24 23
В соответствии с этим правилом будут записываться все пакеты, адресованные в порт telnet каждого хоста сети класса C 192.168.1.0 с любого хоста за пределами этой сети, а также все пакеты, исходящие из порта telnet хостов сети 192.168.1.0 и адресованные в другие сети.
Отметим, что использование оператора <- недопустимо в правилах Snort.
Пары правил activate/dynamic существенно расширяют возможности Snort. Вы можете с помощью одного правила (activate) активизировать при наступлении определенных условий другое правило, действие которого будет выполнено для заданного числа пакетов. Это очень полезно в тех случаях, когда вы хотите сохранить некоторое количество пакетов при возникновении того или иного события. Правила активизации похожи на правила alert, но включают добавочное поле activates. Динамические правила похожи на правила log, но включают два добавочных поля – activated_by и count. Все добавочные поля правил activate/dynamic являются обязательными.
Правила activate подобны правилам alert, но кроме генерации сигнала говорят программе Snort о необходимости добавления (активизации) другого правила при выполнении заданных условий. Правила dynamic подобны правилам log, но включаются только при выполнении правила activate с заданным идентификатором. Ниже приведен пример пары правил с активизацией по условию.
activate tcp !$HOME_NET any -> $HOME_NET 143 (flags: PA \
content: ”|E8C0FFFFFF|/bin”; activates: 1 \
msg: “IMAP buffer overflow!”;)
dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by: 1; count: 50;)
Эта пара правил говорит Snort о необходимости генерации сигнала при обнаружении переполнения буфера IMAP и записи следующих 50 пакетов, адресованных в порт 143 из сетей за пределами $HOME_NET на хосты $HOME_NET. Если переполнение буфера произойдет, такая пара правил позволит записать 50 (или иное число) следующих пакетов, адресованных в тот же порт для их последующего анализа.