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

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

Формат параметров правила

В Snort параметры правила отделяются от его заголовка с помощью круглых скобок. Рассмотрим следующее правило.

alert tcp !$HOME_NET any -> $HOME _NET any (flags: SF; \ msg: "SYN-FIN scan";)

В данном случае параметры заданы в строке (flags: SF; \ msg: "SYN-

FIN scan";). Каждый параметр включает в себя ключевое слово и (возможно) его значение. В этом примере для ключевого слова flags установлено значение SF, а для ключевого слова msg - значение SYN-FIN scan. Для некоторых параметров в качестве значений ключевого слова должны устанавливаться численные значения, для других это должны быть специальные коды. Между ключевым словом и его значением устанавливается символ двоеточия ( : ), а параметры отделяются друг от друга точкой с запятой ( ; ). Кроме того, точка с запятой должна быть установлена после последнего параметра. В противном случае будет выдано сообщение об ошибке. Хотя значения большинства ключевых слов требуется устанавливать, но есть и несколько исключений. Например, не существует значений для ключевого слова nocase, которое определяет, что при исследовании содержимого полезных данных пакета не должен учитываться регистр символов.

Для Snort не имеет значения наличие нескольких или полное отсутствие пробелов между символами разделения (; и :), параметрами и значениями. Например, оба следующих набора параметров являются равнозначными.

(f lags : S F ,-msg : "SYN-FIN scan" ; )

(flags: SF ; msg : "SYN-FIN scan" ;)

Символ обратной косой черты (\) является символом продолжения правила. Он устанавливается в конце строки незавершенного правила и позволяет продолжить его написание в следующей строке. Символ “решетки” (#) используется для добавления комментариев в правила Snort.

Параметры правил

Теперь приступим к рассмотрению наиболее популярных параметров правил Snort, которые позволят нам продемонстрировать всю мощь возможностей этой системы. Описание всех доступных параметров правил Snort можно найти на сайте www. snort. org, открыв в ссылке Documentation раздел Snort Users Manual.

Параметр msg

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

Ниже приведены формат параметра, пример правила и запись о зарегистрированном предупреждении в результате “срабатывания” этого правила.

Формат:

msg: "<текст сообщения>";

Пример правила:

alert udp апу апу ->192.168.5.0/24 31337 \

(msg: "Back Orifice";)

Пример отчета:

[**] Back Orifice [**]

04/24-08:49:21.318567 192.168.143,15:60256 -> 192.168.5.16:31337 UDP TTL: 41 TOS: 0x0 ID: 49951 Len : 8

Это правило Snort вызывает предупреждение (и регистрацию) при получении с любого IP-адреса и порта отправителя пакета, предназначенного хостам подсети 192.168.5 на порт 31337. При этом должно выдаваться сообщение “Back Orifice”.

Параметр logto

Параметр logto позволяет задать имя файла, в который будут записываться отчеты. Он используется только для правил, для которых определено действие предупреждения или регистрации. Обычно при “срабатывании” таких правил информация сохраняется в каталоге по умолчанию (var/log/snort для UNIX-хостов, а для хостов под управлением Windows - в подкаталоге log каталога, в который была установлена Snort) или в каталоге, указанном после параметра командной строки -1 при запуске Snort. При этом предполагается, что пользователь не изменил применяемую по умолчанию регистрацию на сохранение информации в двоичном формате (с помощью параметра командной строки -Ь) или на передачу данных демону системного журнала syslog (с помощью параметра командной строки - s) и полностью не отменил регистрацию (с помощью параметра командной строки -N).

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

Формат: logto: "<имя_файла>";

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

Пример правила:

alert udp any any -> 192.168.5.0/24 31335 \

(msg: "trinoo port"; logto: "DDoS";)

Пример отчета (при “срабатывании” правила запись об этом событии на UNIX-хосте заносится в файл /var/log/snort/DDoS):

[**] trinoo port [**]

04/24-09:07:41.320938 192.168.143.15:56881 -> 192.168.5.16:31335 UDP TTL: 42 TOS: 0x0 ID:4011 Len : 8

Параметр tel

С помощью параметра tel можно проверить значение поля TTL полученного пакета. Для использования этого параметра существует множество причин. Одной из них является поиск пакетов с небольшими значениями поля TTL, что сви детельствует об использовании программы Traceroute удаленным UNIX-xoctom или программы Tracert удаленным Windows-компьютером. Если при этом используется один из UDP-портов в диапазоне от 33000 до 34000, то скорее всего применяется программа Traceroute. Windows-программа Tracert работает с помощью эхо-запросов ICMP.

Следующее правило позволяет обнаружить запросы программы Traceroute к сети 192.168.5 с указанным портом отправителя в диапазоне от 33000 до 34000 и значением поля TTL, равным 1.

Формат:

ttl: <число>;

Пример правила:

alert udp any any ->192.168.5.0/24 33000:34000 \

(msg: "Unix traceroute"; ttl: 1;)

Пример отчета:

[**] Unix traceroute [**]

04/24-09:29:37.971353 192.168.143.15:40920 -> 192.168.5.16:33437 UDP TTL: 1 TOS: 0x0 ID:40923 Len : 18

Параметр id

Для хранения значения идентификатора в IP-заголовке используется 16-битовое поле. Для каждой новой дейтаграммы устанавливается уникальный идентификатор, и его значение обычно увеличивается на 1 для каждого следующего пакета. При фрагментации это число называют идентификатором фрагмента, по которому выполняется сборка получаемой последовательности фрагментов. В следующем примере представлено правило, с помощью которого можно выявить пакеты с необычным значением идентификатора, равным 0. К сожалению, ядро операционной системы Linux 2.4 устанавливает значение 0 для идентификатора 1Р-дейтаграмм, когда в дейтаграмме также установлен флаг DF (Don’t Fragment - не фрагментировать). Объясняют это тем, что если пакет не может быть фрагментирован, то зачем думать об идентификаторе фрагмента.

Формат:

i d: < число>

Пример правила:

alert icmp any any -> 192.168.5.0/24 any \

(msg: "Suspect IP Identification ID:0;)

Пример отчета:

[**] Suspect IP Identification # [**]

04/25-09:21:36.371005 192.168.143.15 -> 192.168.5.16 ICMP TTL:64 TOS:0XÖ ID:00

Параметр dsize

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

Формат:

dsize: [< >] число

Пример правила:

alert icmp any any ->192.168.5.0/24 any \

(msg: "Превышение стандартной длины ICMP-данных"; dsize: >1024;)

Пример отчета:

[**] Превышение стандартной длины ICMP-данных [**]

04/24-11:24.110169 192.168.143.100 -> 192.168.5.16 ICMP TTL: 2 55 TOS: 0x0 ID:5487 DF ID : 7564 Seq: 0 ECHO

Параметр sequence

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

Формат: seq: <число>

Пример правила: alert tcp any any -> any any \

msg: "Возможно, проводится DDoS-атака Shaft"; seq:0x2 83 74839 ;)

Пример отчета:

[**] Возможно, проводится DDoS-атака Shaft [**]

04/25-07:19:58.582562 192.168.143.100:35680 -> 192.168.143.15:23 TCP TTL : 2 55 TOS : 0x0 ID-.7705 DF

«■*****£* Seq. 0x28374839 Ack : 0x0 Win: 0x2238 TCP Options => MSS: 1460

Параметр acknowledgement

С помощью параметра acknowledgement можно проверить значение номера подтверждения TCP-сегмента. Основным предназначением такой проверки является выявление попыток сканирования, осуществляемых программой nmap. Для выявления активного хоста nmap отправляет TCP-пакет с установленным флагом АСК, а значение номера подтверждения в этом пакете равно 0. В нормальном TCP-сеансе полу чение пакета с таким номером подтверждения является довольно редким, так как это означает, что в предыдущем полученном TCP-сегменте значение порядкового номера достигло 2’ -1 (только тогда номер подтверждения обнуляется).

Формат: ack: <число>;

Пример правила:

alert tcp any any -> any any \

(msg: "nmap TCP ping"; flags: A; ack: 0;)

Пример отчета:

[**] nmap TCP ping [**]

04/25-07:27:13.578488 192.168.143.15:63367 -> 192.168.143.16:80 TCP TTL:42 TOS: 0x0 ID:26253

seq: 0x16680003 Ack: 0x0 Win: OxCOO

Параметры itype и icode

Параметр itype используется для указания типа ICMP-сообщения. Поле “Тип” находится в нулевом байте ICMP-пакета. Возможные значения этого поля и поля для хранения кода ICMP-сообщения, которое проверяется с помощью параметра icode, можно узнать по адресу www.iana.org/assignments/icmp-parameters. Чаще всего параметры itype и icode используются совместно. Код ICMP-сообщения указывается в первом байте ICMP-пакета. Многие ICMP-сообщения отличаются только кодом и имеют один и тот же тип. Например, существует довольно много различных кодов для ICMP-сообщений типа 3. Чтобы выявить ICMP-сообщения о недостижимости порта, нужно создать правило Snort, согласно которому значение параметра itype равнялось бы 3, и значение параметра icode тоже бы составляло 3.

Формат:

itype: <число>; t icode : < число ;

Пример правила:

alert icmp 1.1.1.0/24 any -> 192.168.5.0/24 any \

(msg: "port unreachable"; itype: 3; icode: 3;)

Пример отчета:

[**] port unreachable [**]

04/25-07:56:37.129338 1.1.1.16 -> 192.168.5.15 ICMP TTL: 2 55 TOS:OxCO ID:33569 DESTINATION UNREACHABLE:, PORT UNREACHABLE

Параметр flags

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

■ F - установлен флаг FIN;

■ S - установлен флаг SIN;

■ R - установлен флаг RESET ;

■ Р - установлен флаг PUSH;

■ А - установлен флаг АСК;

■ U - установлен флаг URG;

■ R - установлен флаг RESET;

■ 2 - установлен эхо-бит ECN (ранее зарезервированный бит);

■ 1 - установлен бит CWR (ранее зарезервированный бит);

■ 0 - не установлено ни одного флага.

Кроме того, для проверки установленных комбинаций флагов допускается использование трех модификаторов (+,*,!). Например, запись А+ означает, что в пакете должен быть установлен флаг АСК. При этом он может быть единственным установленным флагом или вместе с ним могут быть установлены и другие флаги. Описание подходит и для пакетов со стандартной комбинацией флагов PUSH (т.е. новые данные отправляются одновременно с подтверждением получения прошлой порции). Модификатор * используется для выявления пакетов, в которых установлен один или несколько флагов из заданной комбинации. Например, строка SFP* определяет поиск пакетов с установленным хотя бы одним из трех флагов SYN, FIN и PUSH, а также пакетов с любой их комбинацией. Последний модификатор ! позволяет задать поиск пакетов, в которых не установлен данный флаг. Параметр flags : ! S, например, позволяет найти все пакеты, в которых не установлен флаг SYN.

Формат:

flags : <код_установленных_флагов>

На рис. 14.1 показано графическое представление кодов Snort для флагов TCP. Доступные модификаторы флагов:

■ + - все пакеты, в которых установлен заданный флаг (или флаги) и любые другие флаги;

■ * - все пакеты, в которых установлен один из указанных флагов;

■ ! - все пакеты, в которых не установлен указанный флаг (флаги).

Рис. 14.1. Байт TCP-флагов в кодах системы Snort

Пример правила:

aiert tcp any any -> any any (msg: "Сканирование с помощью null-пакетов"; / flags:0;)

Пример отчета:

[**]Сканирование с помощью null-пакетов [**]

04/25-05:49:51.914748.192.168.143.15:54746 -> 192.168.143.16:21 TCP TTL:51 TOS:0x0 ID:23446

******** Seq: 0X1CED3E2E Ack: 0x0 Win:0xl000

TCR Options => WS: 10 NOP MSS: 265 TS: 1061109567 0 EOL EOL

В приведенном выше примере отчета содержится строка из восьми символов звездочек (*******■*). Snort заменяет звездочки соответствующими кодами для установленных в пакете флагов (12UAPRSF), если получение этого пакета вызвало предупреждение. Так как в данном случае проводилось сканирование с помощью null-пакета (в пакете не установлено никаких флагов), то все звездочки остались на месте.

Параметр content

Один из самых важных параметров - content - зачастую используют неверно. С его помощью осуществляется проверка содержимого полезных данных пакетов. Доступны различные способы задания значений для параметра content, и можно организовать проверку по нескольким таким значениям. Просмотр содержимого полезных данных требует значительного расхода вычислительных средств, другими словами, неправильное использование параметра content может серьезно замедлить работу Snort. Хотя создатели Snort максимально оптимизировали алгоритм для просмотра полезных данных пакетов, но все равно эта операция выполняется значительно медленнее, чем, например, поиск заданных значений в полях заголовков. Это объясняется тем, что длина поля заголовка составляет максимум 4 байт, а размер полезной нагрузки обычно намного больше.

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

Строка поиска может быть задана как текст, как шестнадцатеричное представление двоичных данных или как комбинация текста и шестнадцатеричных символов. Текстовые строки заключаются в кавычки и при поиске учитывается регистр символов (если не использован параметр nocase). Шестнадцатеричный код отделяется с помощью символов конвейеризации (). С помощью параметра content (или нескольких подобных ему) для поиска в пакете могут быть заданы различные значения, при этом для “срабатывания” правила в пакете должны присутствовать все заданные значения. Значения, заданные с помощью нескольких параметров content, могут находиться в подозрительном пакете в любой последовательности, независимо от порядка параметров content. Существует и другой параметр content-list, который позволяет считать правило “сработавшим” при нахождении соответствия хотя бы с одним из заданных параметров content-list. Описание этого параметра и пример его использования можно найти на сайте www. snort. org в разделе The Snort Users Manual.

Формат: content: <"value">;

content: <"value">; content: <"value">;

Пример правила:

alert udp $EXTERNAL_NET any -> $HOME_NET 53 \

(msg: "Атака BIND попытка переполнения буфера tsig"; \ content: " I 00 FA 0 0 FFI "; content: "/bin/sh";);

Пример отчета:

02/22-15:33:19.472301 ATTACKER:1024 -> VICTIM:53 UDP TTL:64 TOS:0x0 ID:6755 IpLen:20 DgmLen:538 Len:518

«пропущенные строки для сокращения отчета>

00 3F 90 E8 72 FF FF FF 2F 62 69 6E 2F 73 68 00 .?..r.../bin/sh.

0E 0F 10 11 12 13 14 15 16 17 18 19 1A IB 1C ID ................

IE IF 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D .. !"#$%&'()*+,-

2E 2F ЗО 31 32 33 34 35 36 37 38 39 ЗА ЗВ ЗС ЕВ ./0123456789.

07 СО 00 00 00 00 00 3F 00 01 02 03. 04 05 06 07 .......?........

08 09 ОА OB ОС OD OE OF 10 11 12 13 14 15 16 17 ................

18 19 1А 1В 1C ID IE 1F 20 21 22 23 24 25 26 27 ................!"#$%&'

28 29 2А 2В 2С 2D 2Е 2F ЗО 31 32 33 34 35 36 37 ()*+,-./01234567

38 39 ЗА ЗВ ЗС ЕВ 07 СО 00 00 00 00 00 3F 00 01 89: ;<........?..

02 03 04 05 06 07 08 09 ОА OB ОС OD OE OF 10 11 ................

D8 FA FF BF D8 F7 FF BF DO 7C OD 08 04 F7 10 40 ..............@

22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 "#$%&'()*+,-./01

32 33 34 35 36 37 38 39 ЗА ЗВ ЗС ЕВ 07 СО 00 00 23456789:;<.....

00 00 00 3F 00 01 02 03 04 05 06 07 08 09 ОА OB ...?............

ОС OD ОЕ OF 10 11 12 13 14 15 16 17 18 19 1А IB ................

1C ID IE IF 2 0 21 22 23 24 2 5 26 27 28 2 9 2A 2B .... !"#$%&'()*+

2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 ЗА ЗВ ,-./0123456789:;

ЗС ЕВ 07 СО 00 00 00 00 00 00 00 FA 00 FF <.............

В этом отчете обнаруженные в полезных данных шестнадцатеричные символы отображены слева, а справа представлены соответствующие им ASCII-символы. Созданное правило предназначено для обнаружения входящего UDP-трафика, отправленного на порт 53 одному из компьютеров защищаемой сети. В частности, отслеживается передача двух строк: первая из них представлена в шестнадцатеричном формате 00 FA 00 FF, а вторая - в текстовом (строка /bin/sh). Проверяется присутствие обоих этих строк в полезной нагрузке в любом порядке. Это правило будет использовано только после проверки всех остальных параметров для поступившего пакета.

Некоторые параметры правил используются только в качестве модификаторов для параметра content, другими словами, при их самостоятельном использовании без этого параметра будет выдано сообщение об ошибке. Такими параметрами являются: offset, depth, nocase и regex. Они уточняют характеристики поиска только для указанного непосредственно перед ними параметра content.

Какой флаг

Если исследовать правила Snort, поставляемые совместно с самой системой, то можно обнаружить, что в очень многих правилах кроме параметра content используется параметр flags со значением А+. Таким образом, для “срабатывания” правила в пакете должен быть установлен флаг АСК (и, возможно, другие флаги). Это может показаться неправильным, и многие могут логично возразить: “А почему не использовать параметр flags со значением р+?”. В конце концов, разве система Snort не должна исследовать содержимое, когда в пакете передаются байты полезной нагрузки?

Все это так, и обработка пакетов становится более эффективной, если правило с использованием параметра content будет применяться только для тех пакетов, в которых передаются полезные данные. Но, как сказано в книге Ричарда Стивенса TCP/IP Illustrated, Volume 1, несмотря на то, что стеки TCP/IP многих BSD-систем устанавливают флаг PUSH для каждого пакета, в котором передаются данные, в других операционных системах этот флаг устанавливается только тогда, когда пользователь инициирует немедленную отправку данных из исходящего буфера. Это означает, что если получатель устанавливает небольшой размер TCP-окна, и отправитель не освобождает весь свой выходной буфер, то в отправляемых пакетах устанавливается только флаг АСК. Поэтому для параметра flags используется значение А+. Несмотря на то что многие пакеты с флагом АСК не несут полезной нагрузки, они также будут проверяться.

Альтернативным вариантом проверки наличия в пакете полезных данных является использование параметра dzise > о. Это позволяет обнаружить необычный трафик, например, передачу данных в SYN-пакетах, в которых флаг АСК не устанавливается.

В качестве примера отправки полезных данных в пакете, в котором установлен только флаг АСК, рассмотрим два отчета о действиях программы LaBrea версии 2. Как указывалось в главе 9, “Анализ заголовков вложенных пакетов”, эта программа позволяет замедлить атаку злоумышленника с помощью искусственного занижения размера окна. В первой записи хост с программой LaBrea (IP-адрес ю .10 . ю . 155) выдает себя за Web-сервер и устанавливает необычно малое значение размера окна, равное 5. Хост нарушителя attacker.net отправляет 5 байт полезных данных. Как вы видите, в передаваемом пакете установлен только флаг АСК и нет флага PUSH, так как размер отправленных данных не позволил полностью освободить буфер хоста attacker.net.

10.10.10.155.WWW > attacker.net.2045: S 998514038:998514038(0) ack 882335287 win 5

attacker.net.2045 > 10.10.10.155.www: . 1:6(5) ack 1 win 8576 (DF)

Параметр offset

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

Формат: offset: <число>;

Пример правила:

alert tcp any any -> 192.168.5.0/24 21 \

(msg: " Попытка анонимного доступа к ftp-серверу \

content: "anonymous"; offset: 5;)

Пример отчета:

[**] Попытка анонимного доступа к ftp-cepBepy [**]

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

* * *AP* * * Seq: 0X93EE0AB7 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..

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

Параметр depth

Параметр depth представляет собой еще один параметр, с помощью которого можно ограничить размер исследуемых Snort полезных данных пакета. Он определяет количество байтов, исследуемых после заданного смещения. Если смещение не задано, оно считается равным 0. Этот параметр позволяет значительно повысить эффективность работы Snort при обработке пакетов с большими объемами полезных данных, для которых известна структура этих передаваемых данных (в какой части пакета находятся те или иные данные).

Формат:

depth: <число>

Пример правила:

alert udp !$HOME_NET any -> $HOME_NET 5632 \

(msg: "PCAnywhere Startup"; content: "ST"; depth: 2;)

Пример отчета:

[**] PCAnywhere Startup [**]

04/24-12:11:08.724441 192.168.143.15:3484 -> 192.168.143,16:56 32 UDP TTL: 64 TOS:OxlO ID:30124 DF 73 74 61 72 74 75 70 STARTUP

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

Параметр nocase

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

Формат:

nocase

Пример правила: alert tcp any any -> any 21 \

(msg: "FTP warez snooping"; content: "warez"; nocase;)

Пример отчета:

[**] FTP warez snooping [**]

04/25-05:28:28.146374 192.168.143.15:3487 -> 192.168.143.16:21 TCP TTL: 64 TOS: 0x10 ID:30637 DF ,

* * *AP* * * Seq: 0XE1977C8D Ack: 0X452F7F9 Win: 0X7D78

TCP Options => NOP NOP TS: 118248207 33775174

43 57 44 20 57 61 52 65 5A 0D 0A CWD WareZ..

Параметр regex

Параметр regex позволяет в строке символов, задаваемой для поиска с помощью параметра content, использовать универсальные символы. Возможно использование двух универсальных символов: знак ? можно применять для обозначения одного любого символа, а звездочка * позволяет заменить любое количество символов.

С помощью параметра regex можно выявить признаки атак на переполнение буфера. При успехе этой атаки на хосте под управлением UNIX злоумышленник, скорее всего, захочет получить доступ к командному интерпретатору, например интерпретатору Bourne (файл /bin/sh), хотя существует много других командных интерпретаторов, таких как командный интерпретатор С (chs), Korn (ksh) и Bourne again (bash). Таким образом, с помощью одной строки и универсального символа можно обнаружить попытки доступа ко всем командным интерпрета торам. До появления параметра regex единственным способом проверить попытки доступа к командным интерпретаторам являлось создание отдельных правил. Не забывайте, что параметр regex стал полнофункциональным только в версии Snort 2.0.

Формат:

regex;

Пример правила: log tcp any any -> 192.168.5.0/24 515/

(msg: "Попытка получения доступа к командному интерпретатору / посредством lpd"; content: "/bin/*sh"; regex;)

Пример отчета:

[**Попытка получения доступа к командному интерпретатору посредством lpd**]

03/23-07:41:11.282960 1.1.0.1:1892 -> 192.168.5.55:515

TCP TTL:64 TOS:0x0 ID:63821 IPLen:20 DgmLen:60

♦**AP*** Seq: 0X32A77D55 Ack: 0x0 Win: 0x200 TcpLen: 20

2F 62 69 6E 2F 63 73 68 0A 00 00 00 00 00 00 00 /bin/csh.......

00 00 00 00

Приведенное выше правило позволяет контролировать попытки доступа к командному интерпретатору с помощью пакетов, отправленных на порт 515 (порт lpd). Уточняющее значение параметра regex (/bin/*sh) для параметра content позволяет выявить любые попытки доступа к командному интерпретатору.

Параметр session

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

Для параметра существует два доступных ключевых слова: printable и all. С помощью ключевого слова printable сохраняются печатаемые символы. Ключевое слово all позволяет зарегистрировать также и все непечатаемые символы с их шестнадцатеричными эквивалентами.

Будьте готовы к тому, что применение параметра session может снизить производительность Snort, поэтому его лучше использовать для уже зарегистрированных данных: можно сохранить данные в двоичном формате (файлы TCPdump) и затем просмотреть их с помощью Snort. Кроме того, при применении этого параметра должны проверяться данные, передаваемые в обоих направлениях (как показано в примере). И последнее: желательно добавлять в командную строку параметр -d для сохранения данных на уровне приложений, в противном случае использование параметра session не имеет особого смысла.

По умолчанию отчеты о сеансах сохраняются в каталоге log. Затем информация разделяется по подкаталогам, названия которых аналогичны IP-адресам хостов, инициировавших соединение. Формат имени файла регистрации сеанса - SESSION:sourceport-destport, где sourceport и destport - номера портов отправителя и получателя для данного сеанса соответственно.

Формат: session: [printable/all]

Пример правила: log tcp any any <> 192.168.5.0/24 21 (session: printable;)

Если предположить, что IP-адресом хоста-отправителя является 1.2. 3.4, а порт отправителя 1025, то следующий отчет будет сохранен в каталоге log в подкаталоге 1.2.3.4b файле SESSION.

Пример отчета:

220 1inux2 FTP server (Version wu-2.5.0(l) Tue Sep 21 16:48:12 EDT 1999) ready.

USER jsmith

331 Password requied for jsmith.

PASS snorty-the-plg

230 User jsmith logged in.

SYST

215 UNIX Type: L8 QUIT

221-You have transferred 0 bytes in 0 files.

221-Total traffic for this session was 239 bytes in 0 transfers.

221-Thank you for using the FTP service on linux2.

221 Goodbye

Параметр resp

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

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

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

./configure -enable-flexresp

Она позволяет добавить необходимый программный код для последующей компиляции. Возможно, что в состав вашей версии UNIX не входит файл libnet .h, который требуется для выполнения компиляции. Этот файл можно загрузить с сайта www.packetfactory.net.

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

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

Формат:

resp <resp-параметр[, resp-параметр...]>;

Доступными вариантами ответов являются:

■ rst_snd- отправить TCP-пакет с установленным флагом RESET на сокет хоста-отправителя;

■ rst_rcv- отправить TCP-пакет с установленным флагом RESET на сокет получателя;

■ rst_all - отправить TCP-пакеты с установленным флагом RESET на сокеты хоста-отправителя и получателя;

■ icmp_net - вернуть отправителю ICMP-сообщение о недостижимости сети (network unreachable);

■ icmp_host - вернуть отправителю ICMP-сообщение о недостижимости хоста (host unreachable);

■ icmp_port - вернуть отправителю ICMP-сообщение о недостижимости порта (port unreachable);

■ icmp_all - вернуть отправителю все три перечисленных выше ICMP-сообщения.

Пример правила:

alert tcp any any -> $HOME_NET 21

(msg: "Получение файла паролей FTP";

flags: A+; resp: rst_all; content: "passwd";)

Пример отчета о сеансе:

[rootiaverbo hping2-beta53]# ftp sparky Connected to sparky.

220 sparky FTP server (SunOS 5.7) ready.

Name (sparky:root): jsmith

331 Password required for jsmith.

Password:

230 User jsmith logged in.

Remote system type is UNIX.

Using binary mode to transfer files. ftp> cd /etc

250 CWD command successful. ftp> get passwd local: passwd remote: passwd 200 PORT command successful.

421 Service not available, remote server has closed connection

В предыдущем правиле было задано ответное действие при попытке подключиться к FTP-серверу и получить доступ к файлу паролей passwd. Snort пытается оборвать соединение на обоих концах, так как была выбрана опция rst_all для параметра resp.

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

Параметр tag

При использовании параметра tag система Snort регистрирует все пакеты, поступающие после “срабатывания” правила. Если не указывать этот параметр, сохраняется только пакет, непосредственно соответствующий правилу. Таким образом, можно увидеть, какие события происходят после получения опасного пакета, что поможет узнать, была тревога ложной или нет.

Формат:

tag: <тип>, <количество>, <показатель>, [направление]

■ Тип. Указывает, пакеты какого типа следует регистрировать.

■ session- сохранять все пакеты, которыми обмениваются участники соединения;

■ host - сохранять только те пакеты, которые поступают от хоста - отправителя пакета, вызвавшего “срабатывание” правила (необходимо использовать модификатор направление).

■ Количество. Позволяет определить количество единиц, заданных с помощью модификатора показатель.

я Показатель. Определяет, в каких единицах число указано в модификаторе количество.

* packets - сохранить <х> пакетов сеанса или отправленных с атакующего хоста;

■ seconds - сохранить пакеты за <х> секунд после “срабатывания” правила для данного сеанса или отправленных с атакующего хоста;

■ Направление. Используется только для типа host и указывает, по какому IP-адресу (отправителя или получателя) следует выбирать регистрируемые пакеты.

■ scr - сохранить все пакеты с IP-адресом отправителя, совпадающим с IP-адресом отправителя в пакете, получение которого привело к “срабатыванию” правила;

■ dst - сохранить все пакеты с IP-адресом получателя, совпадающим с IP-адресом получателя в пакете, получение которого привело к “срабатыванию” правила.

Пример правила:

alert tcp any any -> any 21 (msg: "FTP-доступ к файлу passwd"; flags: A+; \ content: "passwd"; tag: session, 10, packets;)

Пример отчета.

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

[**] FTP-доступ к файлу passwd [**]

03/21-20:31:05.610035 10.10.10.101:1454 -> 10.10.10.100:21 TCP TTL:128 TOS:0x0 ID:50697 IpLen:20 DgtnLen:58 DF

* * *AP*.* Seq: 0x17806739 Ack: 0X121C07E5 Win: 0X1FD3 TcpLen: 20

Создается каталог по имени 10.10.10.101 с файлом TCP: 1454-21, в котором сохраняются отчеты о всех операциях, выполненных во время сеанса с момента попытки получения файла паролей (еще 10 последующих записей). Обратите внимание на то, что, указав при запуске Snort в командной строке параметр -d, можно сохранить все полезные данные передаваемых пакетов. Ниже приведен фрагмент такого отчета.

03/21-20:31:05.610035 10.10.10.101:1454 -> 10.10.10.100:21 TCP TTL:128 TOS:0x0 10:50697 IpLen:20 DgmLen:58 DF

Seq. 0x17806739 Ack: 0xl21C07E5 Win: 0xlFD3 TcpLen: 20 52 45 54 52 20 2F 65 74 63 2F 70 61 73 73 77 64 RETR /etc/passwd 0D 0A

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

03/21-20:31:05.610731 10.10.10.100:21 -> 10.10.10.101:1454

TCP TTL:64 TOS:0x10 ID:1752 IpLen:20 DgmLen:109 DF

***Ap*** Seq. 0X121C07E5 Ack: 0x1780674В Win: 0X7D78 TcpLen: 20

31 35 30 20 4F 70 65 6E 69 6E 67 20 41 53 43 49 150 Opening ASCI

49 20 6D 6F 64 65 20 64 61 74 61 20 63 6F 6E 6E I node data conn

65 63 74 69 6F 6E 20 66 6F 72 20 2F 65 74 63 2F ection for /etc/

70 61 73 73 77 64 20 28 36 37 39 20 62 79 74 65 passwd (679 byte

73 29 2E 0D 0A s) . . .

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= <несколько пропущенных записей> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 03/21-20:31:08.924038 10.10.10.101:1454 -> 10.10.10.100:21 TCP TTL:128 TOS:0x0 ID:52489 IpLen:20 DgmLen:58 DF

* * *AP* * * Seq: 0x17806764 Ack: OX121C0860 Win: 0xlF58 TcpLen: 20 52 45 54 52 20 2F 65 74 63 2F 73 68 61 64 6F 77 RETR /etc/shadow 00 0A

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

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

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

Предположим, что у нас есть программа атаки, использующая ошибку переполнения буфера записей TSIG (transaction signature) базы данных DNS-сервера. Это реальпая атака, которая была эффективна против пакетов BIND начиная с версии 4.x (за исключением версии 8.2.3), для которых не была установлена специальная заплата. Запись TSIG является одной из записей о ресурсах наподобие адресной записи (А) или записи указателя доменного имени (PRT). Она используется распознавателями и при динамическом обновлении информации базы данных DNS-сервера с целью поддержания целостности передаваемой DNS-записи с помощью одностороннего хэширования и совместно используемого секретного ключа.

Программа атаки предназначена для получения доступа к командному интерпретатору на привилегированном уровне, на котором запущена BIND (демон named). Исходя из этого и следует создавать сигнатуру для обнаружения вредоносных пакетов. Ниже представлен пакет, в котором организовано переполнение буфера BIND и затем следует попытка получить доступ к командному интерпретатору. 02/22-15:33:19.472301 ATTACKER:1024 -> VICTIM:S3

UDP TTL.-64 TOS: 0x0 ID: 6755 IpLen:20 DgmLen:538 Len: 518

DE AD 01 80 00 07 00 00 00 00 00 01 3F 00 01 02 ............?...

03 04 05 06 07 08 09 0A ОБ OC OD OE OF 10 11 12 ...........

13 14 15 16 17 18 19 1A IB 1C 10 IE 1F 20 21 22 ............. !"

23 24 25 26 27 28 29 2A 2B 2С 2D 2Е 2F ЗО 31 32 #$%&1 ()* + ,-./012

33 34 35 36 37 38 39 ЗА ЗВ ЗС ЕВ ОА 02 00 00 СО 3456789:;<......

00 00 00 00 00 3F 00 01 ЕВ 44 5Е 29 СО 89 46 10 .....?...DA)..F.

40 89 СЗ 89 46 ОС 40 89 46 08 8D 4Е 08 ВО 66 CD @...F.@.F.,N.,f.

80 43 C6 46 10 10 66 89 5E 14 88 46 08 29 СО 89 . С . F . . f . A . . F . ) . .

C2 89 46 18 ВО 90 66 89 46 16 8D 4E 14 89 4E OC ..F...f.F..N..N.

BD 4E 08 EB 07 СО 00 00 00 00 00 3F EB 02 EB 43 .N.........?...C

ВО 66 CD 80 89 5E OC 43 43 ВО 66 CD 80 89 56 OC .f...A.CC.f...V.

89 56 10 ВО 66 43 CD 80 86 C3 BO 3F 29 C9 CD 80 .V..fC.....?)...

BO 3F 41 CD 80 BO 3F 41 CD 80 88 56 07 89 76 OC .?A...?A...V..V.

87 F3 8D 4B OC BO OB CD 80 EB 07 СО 00 00 00 00 ...К............

00 3F 90 E8 72 FF FF FF 2F 62 69 6E 2F 73 68 00 .?..r.../bin/sh.

OE OF 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D ................

IE 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D .. !"#$%&'()*+,-

2E 2F 30 31 32 33 34 35 36 37 38 39 ЗА ЗВ 3C EB ./0123456789 : ;<.

07 СО 00 00 00 00 00 3F 00 01 02 03 04 05 06 07 .......?........

08 09 OA OB OC OD OE OF 10 11 12 13 14 15 16 17 ................

18 19 1A 1B 1C ID IE 1F 20 21 22 23 24 25 26 27 ................!"#$%&'

28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 ()* + ,-./01234567

38 39 ЗА ЗВ 3C EB 07 СО 00 00 00 00 00 3F 00 01 89:;<........?..

02 03 04 05 06 07 08 09 OA OB OC 00 OE OF 10 11 ................

D8 FA FF BF D8 F7 FF BF DO 7C OD 08 04 F7 10 40 ..............@

22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 "#$%&'()*+,-•/01

32 33 34 35 36 37 38 39 ЗА ЗВ 3C EB 07 СО 00 00 23456789:;<.....

00 00 00 3F 00 01 02 03 04 05 06 07 08 09 OA OB ...?............

OC OD OE OF 10 11 12 13 14 15 16 17 18 19 1A 1B ................

1C ID IE 1F 20 21 22 23 24 25 26 27 28 29 2A 2B .... !"#$%&'()*+

2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 ЗА 3B ,-./0123456789:;-

ЗС EB 07 СО 00 00 00 00 00 00 00 FA 00 FF <.............

Первой очевидной сигнатурой атаки является строка /Ьіп/вЬ., с помощью которой предпринимается попытка получить доступ к командному интерпретатору после успешного переполнения буфера. Другой сигнатурой для этого отчета является определенная проверка использования записи ТЗЮ для О^-сервера.

' Тип DNS-записи хранится в 2-байтовом поле, и TSIG-записи соответствует значение 250 (OxOOFA). Кроме того, каждому типу записи о ресурсах соответствует свой класс записи, который также хранится в 2-байтовом поле. Для TSIG-записи в поле класса используется значение 255 (OxOOFF), которое соответствует любому классу. Таким образом, в полезных данных DNS для обозначения TSIG-записи должна присутствовать строка (OxOOFAOOFF). Обычный TSIG-запрос не содержит строки /bin/sh, поэтому одновременный поиск двух указанных значений позволит выявить вредоносные действия без вызова ложных тревог. Хотя в этом конкретном пакете для создания правила могут быть использованы и другие значения, но злоумышленник может изменить исходный код программы атаки таким образом, что, несмотря на изменение DNS-заголовка и TSIG-записи, программа атаки все равно будет работать. Следующее правило позволяет выявить описанную атаку.

alert udp $EXTERNAL_NET any -> $HOME_NET 53 \

(msg: "tsig-атака на BIND посредством переполнения буфера"; \ content: "I 00 PA 00 FF"; offset: 12; \

content: "/bin/*sh"; regex; offset: 12;)

В рассмотренном примере выявляются пакеты, передаваемые посредством протокола UDP, которые поступают от удаленного пользователя на порт получателя 53. Два отдельных параметра content позволяют выявлять в пакетах искомые строки. Параметр regex применяется на случай, если будет предпринята попытка доступа к командному интерпретатору, отличному от Bourne. Параметр regex стал полнофункциональным в текущей версии Snort и имеет ограниченный набор возможностей в версии Snort 1.8.3 (недоступно использование универсального символа *).

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

Программа атаки, использующая TSIG-записи

Более подробную информацию о tsig можно получить в RFC 2845, озаглавленном “Secret Key Transaction Authentication for DNS (TSIG)” (“Аутентификация для DNS-службы с помощью передачи секретного ключа (TSIG)"). Об описанной атаке можно прочитать на сайте www.cert.org, ссылка СА-2001-02. Еще одно полное исследование этой атаки провел Пол Асадориан (Paul Asa-doorian). Его статью можно найти по адресу www.sans.ofg/newlook/resourses/INFAQ/ TSiG.htm. Большое спасибо, Пол, за совместное обсуждение правил Snort и отчетов об атаках.

Резюме

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

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

Система snort | Обнаружение нарушений безопасности в сетях | Атака митника


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



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

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