Как писать правила для snort
Перейти к содержимому

Как писать правила для snort

  • автор:

Snort: Часть 8. Создание собственных правил для Snort. Синтаксис правил.

Данная статья в основном основана на официальной документации SNORT Users Manual.

Snort использует правила, написанные простым, но в то же время гибким и достаточно мощным языком. Большинство правил пишутся в одну строку, хотя могут занимать и несколько строк, в этом случае каждая строка, кроме последней, должна заканчиваться символом “» (без кавычек). В более сложных случаях можно также вызывать другие программы, используя инструкцию включения. Правила для Snort делятся на два вида:

  • Бесконтекстные (обычные) — применяются для каждого пакета отдельно, без связи с другими пакетами
  • Контекстные (правила препроцессоров) — применяться к той или иной совокупности (последовательности) пакетов.

Правила Snort состоят из заголовка (Rule Header) и опций (Rule Options). Заголовок содержит описание действия, протокол передачи данных, IP-адреса, сетевые маски и порты источника и назначения. После заголовка правила следует необязательная часть правила — его опции, они включают определение дополнительных критериев выполнения правила и определение дополнительных реагирующих действий. Они используются для организации более жесткой и направленной фильтрации траффика. Весь набор опций заключается в круглые скобки, сами опции отделяются друг от друг с помощью точки с запятой “;” (последняя опция в списке тоже должна заканчиваться этим символом). Ключевые слова (keywords) опций отделяются от своих аргументов (values) двоеточием “:”. Структура правил Snort в общем случае выглядит следующим образом:

Заголовок Опции
Действие Протокол IP-адреса отправителей Порты отправителей Оператор направления IP-адреса получателей Порты получателей [Мета данные] [Данные в полезной нагрузке] [Данные в заголовке] [Действие после обнаружения]

Синтаксис записи правил Snort:

       (ключ_1 : значение_1; ключ_2 : значение_2; . ключ_N : значение_N;)

Заголовок правила

Допустимые параметры для каждого поля заголовка правил Snort:

Действия правила

Действие Описание
alert генерирует предупреждение, используя указанное предупреждение, и передаёт информацию системе журналирования
log просто протоколирует пакеты без предупреждений
pass игнорирует пакеты
activate генерирует предупреждение, затем включает указанное динамическое правило
dynamic остаётся пассивным, пока не активируется динамическим правилом, затем действует как log

В режиме inline к предыдущим действиям добавляются дополнительные действия:

Действие Описание
drop блокирует (отбрасывает) пакет и передаёт информацию системе журналирования
sdrop блокирует (отбрасывает) пакет и не использует систему журналирования
reject блокирует (отбрасывает) пакет, передаёт информацию системе журналирования, а затем посылает сегмент сброса TCP (TCP RST), если протокол TCP, или сообщение ICMP-порт недоступен, если протокол UDP

Также можно создать свои собственные типы правил и связать один или несколько выходных модулей с ними. Можно затем использовать созданные типы правил в качестве действий в правилах Snort. В примере ниже создаётся тип правила, который будет регистрировать только tcpdump:

ruletype suspicious

А в этом примере создаётся тип правила, регистрирующей и tcpdump, и syslog:

ruletype redalert

Протоколы

Обозначает протокол передачи данных. На данный момент Snort умеет анализировать на предмет подозрительного содержания/поведения 4 типа протоколов: TCP, UDP, ICMP, IP, соответственно, возможны 4 значения: tcp, udp, icmp или ip, что означает любой IP-протокол. В будущем, возможно, этот список пополнят и другие протоколы, к примеру, ARP, IGRP, GRE, OSPF, RIP, IPX и другие.

IP-адресация

Поскольку Snort не имеет встроенного механизма получения IP адреса, используя доменное имя, то нужно указывать конкретный IP адрес или же диапазон IP адресов. В этом параметре можно использовать маски. Адреса задаются в формате: IP/mask, где IP – IP-адрес сети или узла, mask – маска сети, которая задаётся как десятичное число, которое равняется числу единиц в двоичной маске. Например, для сетей класса C /24 (число 24 эквивалентное шестнадцатеричной маске FF.FF.FF.0), для сетей класса B — /16, также можно использовать маску /32 и другие. Здесь может применяться и отрицание (инвертирование), обозначаемое символом “!” (Например: !127.0.0.1). Если вместо IP адреса указать ключевое слово any, то это будет подразумевать абсолютно все хосты. Для указания списка можно использовать перечисление IP адресов через “,” содержащихся в квадратных скобках. (Например: [212.116.1.1,10.10.1.0/24]). В качестве IP-адреса можно использовать переменные HOME_NET, EXTERNAL_NET и другие.

Порты

После IP адреса указывается номер порта, с которого отсылаются данные и на который приходят. Можно указать диапазон портов: 1:1024 (все порты в диапазоне от 1 до 1024 включая 1 и 1024). Часто используется оператор отрицания “!” (Например: !123:321 исключает все порты в диапазоне от 123 до 321). Если опущен один из параметров диапазона, например “:321” или “123:”, то пропускаемый параметр принимает крайнее значение общего количества портов, то есть 0 или 65535.

Операторы направления

Оператор направления служит для обозначения направления траффика, для которого применяется правило, и обозначается “->” (знаком минуса и закрывающей угловой скобкой). IP-адрес и номер порта слева от оператора определяют источник траффика, а справа от него — назначение. Существует также оператор так называемой “двунаправленности” и обозначается “<>” (двумя угловыми скобками). Этот оператор говорит Snort рассматривать указанные пары адресов и портов в обе стороны, вне зависимости от того, кто является источником, а кто – получателем. Это удобно в тех случаях, когда нужно сохранить траффик от обеих сторон, например, в Telnet или POP3 сессиях. Важно отметить, что оператор “

Опции правила

Все опции можно разделить на четыре большие категории:

  • general (meta-data) — данные опции предоставляют информацию о правиле, но никак не влияют на обнаружение;
  • payload — данные опции позволяют искать информацию внутри полезной нагрузки (данных пользователя) пакетов и могут быть взаимосвязаны;
  • non-payload — данные опции позволяют искать информацию внутри служебной (управляющей) информации о пакете (заголовке);
  • post-detection — данные опции являются определёнными триггерами, указывающими задачи, которые необходимо осуществить после срабатывание правила.

General (meta-data)

  • msg Указывает сообщение, текстовое описание сигнала тревоги (для экранирования используется символ “»), которое будет выведено или же записано, используя систему журналирования. Синтаксис: msg:»»; Примеры:
  • reference Указывает ссылки на online системы идентификации атак. Значениями этого поля могут быть ссылки на ресурсы bugtraq, cve, nessus, arachnids, mcafee и другие url. Идентификация осуществляется по SID номерам. Поддерживаемые системы:
    • bugtraq: http://www.securityfocus.com/bid/
    • cve: http://cve.mitre.org/cgi-bin/cvename.cgi?name=
    • nessus: http://cgi.nessus.org/plugins/dump.php3?id=
    • arachnids: (в данный момент не работает) http://www.whitehats.com/info/IDS
    • mcafee: http://vil.nai.com/vil/content/v_
    • osvdb: http://osvdb.org/show/osvdb/
    • msb: http://technet.microsoft.com/en-us/security/bulletin/
    • url: http://

    Примеры:

     alert tcp any any -> any 7070 (msg:"IDS411/dos-realaudio"; \ flags:AP; content:"|fff4 fffd 06|"; reference:arachnids,IDS411;) 
     alert tcp any any -> any 21 (msg:"IDS287/ftp-wuftp260-venglin-linux"; \ flags:AP; content:"|31c031db 31c9b046 cd80 31c031db|"; \ reference:arachnids,IDS287; reference:bugtraq,1387; \ reference:cve,CAN-2000-1574;) 
     alert tcp any any -> any 80 (content:"BOB"; gid:1000001; sid:1; rev:1;)

    = 1.000.000 можно использовать для собственных правил

    Синтаксис: sid:; Примеры:

     alert tcp any any -> any 80 (content:"BOB"; sid:1000983; rev:1;) 
     alert tcp any any -> any 80 (content:"BOB"; sid:1000983; rev:1;) 
    config classification: ,,

    Приоритет 1 (high) является наиболее высоким, а 4 (very low) — самым низким. Также классификация типов атак представлена в таблице:

    Тип класса Описание Приоритет
    attempted-admin Попытка получения прав администратора high
    attempted-user Попытка получения прав пользователя high
    inappropriate-content Обнаружено неприемлемое (несоответствующее) содержание high
    policy-violation Потенциальное нарушение корпоративной конфиденциальности high
    shellcode-detect Обнаружен исполняемый код high
    successful-admin Успешное получение прав администратора (повышение привилегий) high
    successful-user Успешное получение прав пользователя (повышение привилегий) high
    trojan-activity Обнаружена активность сетевой троянской программы high
    unsuccessful-user Неудачная попытка получения прав пользователя high
    web-application-attack Атака на Web-приложение high
    attempted-dos Предпринята попытка атаки отказ в обслуживании (DoS) medium
    attempted-recon Попытка утечки информации (разведка) medium
    bad-unknown Потенциально нежелательный траффик medium
    default-login-attempt Попытка входа с помощью стандартного логина/пароля medium
    denial-of-service Обнаружена атака отказ в обслуживании (DoS) medium
    misc-attack Прочие атаки medium
    non-standard-protocol Обнаружено использование нестандартного протокола или нестандартное событие medium
    rpc-portmap-decode Decode of an RPC Query (Декодирован удалённый вызов процедуры (RPC)) (Обнаружен запрос RPC) medium
    successful-dos Успешная DOS-атака medium
    successful-recon-largescale Крупномасштабная утечка информации medium
    successful-recon-limited Утечка информации medium
    suspicious-filename-detect Обнаружено подозрительное имя файла medium
    suspicious-login Обнаружена попытка входа с подозрительным логином medium
    system-call-detect Обнаружено обращение к ядру системы (system call) (Обнаружен системный вызов) medium
    unusual-client-port-connection Клиент использует нестандартный порт medium
    web-application-activity Доступ к потенциально уязвимому Web-приложению medium
    icmp-event Общее событие ICMP low
    misc-activity Прочая активность low
    network-scan Обнаружена попытка сканирования сети low
    not-suspicious Не являющийся подозрительным траффик low
    protocol-command-decode Generic Protocol Command Decode (Обнаружена попытка шифрования) (Обнаружена обычная команда протокола) low
    string-detect Обнаружена подозрительная строка low
    unknown Неизвестный траффик low
    tcp-connection Обнаружено TCP соединение very low

    Синтаксис: classtype:; Примеры:

     alert tcp any any -> any 25 (msg:"SMTP expn root"; flags:A+; content:"expn root"; nocase; classtype:attempted-recon;) 
     alert tcp any any -> any 80 (msg:"WEB-MISC phf attempt"; flags:A+; content:"/cgi-bin/phf"; priority:10;) 
     alert tcp any any -> any 80 (msg:"EXPLOIT ntpdx overflow"; dsize:>128; classtype:attempted-admin; priority:10;) 
     metadata:key1 value1; metadata:key1 value1, key2 value2;

    Примеры:

     alert tcp any any -> any 80 (msg:"Shared Library Rule Example"; metadata:engine shared; metadata:soid 3|12345;) 
     alert tcp any any -> any 80 (msg:"Shared Library Rule Example"; metadata:engine shared, soid 3|12345;) 
     alert tcp any any -> any 80 (msg:"HTTP Service Rule Example"; metadata:service http;)

    Payload

    • content Позволяет устанавливать условие в правила, которые ищут определённое содержание (контент) в полезной нагрузке пакетов. Условия могут содержать как двоичные данные, так и текстовые. Двоичные данные должны быть заключены между вертикальными чертами “|” в виде байт-кода. Байт-код представляет двоичные данные в виде шестнадцатеричных чисел. В одном правиле может быть указано несколько content-условий. “!” — модификатор отрицания. Если правилу предшествует модификатор отрицания, то правило срабатывает на пакетах, которые не содержат заданный контент. Ключевое слово content имеет ряд модификаторов, которые изменяют поведение ранее указанного content. Список модификаторов:
      • nocase
      • rawbytes
      • depth
      • offset
      • distance
      • within
      • http_client_body
      • http_client_body
      • http_cookie
      • http_raw_cookie
      • http_header
      • http_raw_header
      • http_method
      • http_uri
      • http_raw_uri
      • http_stat_code
      • http_stat_msg
      • fast_pattern

      Примеры:

       alert tcp any any -> any 139 (content:"|5c 00|P|00|I|00|P|00|E|00 5c|";) 
       alert tcp any any -> any 80 (content:!"GET";)

      Предупреждения:

      Необходимо экранировать следующие символы:

      • nocase
      • fast_pattern
      • depth
      • within

      Синтаксис: protected_content:[!]»», length:orig_len[, hash:md5|sha256|sha512];

      Примеры:

      Следующие правила срабатывают на строке “HTTP”.

       alert tcp any any <> any 80 (msg:"MD5 Alert"; protected_content:"293C9EA246FF9985DC6F62A650F78986"; hash:md5; offset:0; length:4;) 
       alert tcp any any <> any 80 (msg:"SHA256 Alert"; protected_content:"56D6F32151AD8474F40D7B939C2161EE2BBF10023F4AF1DBB3E13260EBDC6342"; hash:sha256; offset:0; length:4;) 
       alert tcp any any -> any 21 (msg:"FTP ROOT"; content:"USER root"; nocase;) 
       alert tcp any any -> any 21 (msg:"Telnet NOP"; content:"|FF F1|"; rawbytes;) 
       alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_client_body;) 
       alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_header;) 
       alert tcp any any -> any 80 (content:"ABC"; content:"GET"; http_method;) 
       alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_uri;) 
       alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_raw_uri;) 
       alert tcp any any -> any 80 (content:"ABC"; content:"200"; http_stat_code;) 
       alert tcp any any -> any 80 (content:"/foo.php?id="; pcre:"/\/foo.php?id=[0-9]/iU";)

      Non-payload

      Post-detection

      Разделы: Snort

      Опубликовано: 1 февраля 2017

      Поделиться
      Оставить комментарий
      Вам также может понравиться

      Avito BI contest

      11 мин на чтение

      Разбор первой задачи из Avito BI contest

      Snort: Часть 9. Примеры правил

      11 мин на чтение

      Snort: Часть 7. GUI для Snort

      1 мин на чтение

      Snort: Часть 6. SystemD скрипт для автозапуска Snort

      3 мин на чтение

      Создадим SystemD скрипт для демонов Snort и Barnyard2

      Лабораторная работа №14. NIPS/NIDS: Snort¶

      Цель: Получить сведения о том, как осуществляется защита с помощью систем обнаружения и предотвращения вторжений. Научиться использовать SNORT.

      Система обнаружения вторжений (IDS) — программное или аппаратное средство, предназначенное для выявления фактов неавторизованного доступа в компьютерную систему или сеть либо несанкционированного управления ими в основном через Интернет.

      Сетевая система обнаружения вторжений (англ. network intrusion detection system, NIDS) — система обнаружения вторжений, которая отслеживает такие виды вредоносной деятельности, как DoS атаки, сканирование портов или даже попытки проникновения в сеть.

      В пассивной IDS при обнаружении нарушения безопасности, информация о нарушении записывается в лог приложения, а также сигналы опасности отправляются на консоль и/или администратору системы по определенному каналу связи. В активной системе, также известной как Система Предотвращения Вторжений (IPS — Intrusion Prevention system (англ.)), IDS ведет ответные действия на нарушение, сбрасывая соединение или перенастраивая межсетевой экран для блокирования трафика от злоумышленника. Ответные действия могут проводиться автоматически либо по команде оператора.

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

      Snort — свободная сетевая система предотвращения вторжений (IPS) и обнаружения вторжений (IDS) с открытым исходным кодом, способная выполнять регистрацию пакетов и в реальном времени осуществлять анализ трафика в IP-сетях.

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

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

      Большая часть правил Snort умещается в 1 строку. Это следствие того, что до версии 1.8 нельзя было использовать многострочные записи. В более поздних версиях правила можно растягивать на несколько строк, вставляя в конец строки символ “” (без кавычек).

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

      Задания к лабораторной работе¶

      • Узнайте свой ip адрес командой ifconfig
      • Установите SNORT
      • При установке будет нужно указать защищаемую сеть. ВВедите ..*.0/24 (Где ..* — первые три числа вашего ip-адреса, например эот будет 192.168.1.0/24, если вы используете VirtualBox и у вас в настройках сети стоит сетевой мост)
      • Запустите SNORT
      • Настройка правил
      • Перейдите в каталог /etc/snort/rules < cd /etc/snort/rules)
      • Создайте файл с правилами

      alert tcp any any -> any any (content:»https://www.google.ru/» ; msg:»Someone open Google website» ; sid: 12312313;)

      • Перейдите в каталог /etc/snort
      • Теперь нужно изменить содержимое конфигурационного файла Snort
      • Найдите строчки с правилами (они начинаются с include $RULE_PATH, это в части Step 7) и добавьте файл с нашими правилами

      include $RULE_PATH/test.tules

      • В файле snort.conf так же укажите домашнюю сеть. В Step 1 измените строчку «ipvar HOME_NET any» , на

      ipvar HOME_NET 192.168.1.0/24

      • Запустите snort
      • Зайдите на https://www.google.ru/ и проверьте в терминале, как работает правило.
      • Теперь нам понадобиться еще одна виртуальная машина, на ней должен быть установлен nmap.
      • Со второй ВМ используйте ping, посмотрите, как реагирует SNORT
      • Используйте различные методы сканирования nmap( используйте -sS, -sT, -sN, -sU, -sX, -sF и посмотрите, как реагирует SNORT;
      • В файл test.rules добавьте правило обнаружения сканирования nmap -sN (NULL Scan)

      alert tcp any any -> any any (msg:»NULL Scan»; flags: 0; sid:322222;)

      • Запустите snort
      • Со второй виртуальной машины произведите NULL сканирование , проверьте, как работает правило.
      • Можно загрузить обновленные правила SNORT, для этого:
      • Зарегистрируйтесь на сайте https://www.snort.org/ и скачайте последнюю версию правил
      • Разархивируйте скачанный архив и скопируйте каталоги rules, so_rules и preproc_rules в /etc/snort :

      sudo cp -R ./rules/ /etc/snort/

      sudo cp -R ./so_rules/ /etc/snort/

      sudo cp -R ./preproc_rules/ /etc/snort/

      Вопросы к лабораторной работе¶

      1. Что такое IDS?
      2. Что такое сетевая система обнаружения вторжений?
      3. Чем отличаются пассивные и активные IDS?
      4. Что такое SNORT?
      5. Какие задачи выполняет SNORT?
      6. Как работают правила SNORT?
      7. Как писать правила для SNORT?
      8. Зачем писать собственные правила SNORT?
      9. Зачем загружать обновление правил SNORT?
      10. Как в SNORT создавать логи?

      Составьте отчет о выполнении лабораторной работы.

      Включите в него копии экрана и ответы на вопросы лабораторной работы.

      © Copyright 2016, Пантюхин Игорь Сергеевич, Университет ИТМО.

      Как писать правила для snort

      В настоящее время существует ряд IDS-систем, предназначеных для обнаружения сетевых вторжений. Системы относительно сложные, по многим из них просто не найти информации в открытых источниках. Работают все они на основании заложенных в них правил. В классическом виде системы позволяют выслеживать в проходящем трафике сигнатуры сетевых атак и, в случае их нахождения, передавать сигнал на местный Firewall с тем, чтобы последний заблокировал (скажем на уровне web-сервера) доступ определенному IP адресу. Таким образом обеспечивается безопасность работы компьютера (внутренней локальной сети). Большинство IDS-систем платного характера, но есть несколько и бесплатных, одна из которых система Snort. В связи с тем, что в рунете практически нет никакой информации позволяющей оценить стойкость этой системы (как самого распространенного представителя целого класса IDS-систем), на основании проведенных тестов, мы решили провести свое исследование на предмет оценки работоспособности системы. Итак, начнем. Система Snort:

      1. Прежде всего нужно провести установку системы:
      Для установки нам понадобится библиотека Libpcap необходимая для организации стандартного межплатформенного интерфейса. Скачать библиотеку можно на сайте производителя: www.tcpdump.org.

      В разархивированном каталоге достаточно выполнить следующие команды:

      ./configure
      make
      make install

      Библиотека установлена. Можно приступать к снорту.
      Последний стабильный релиз Снорта можно скачать по адресу: http://snort.org/dl/
      После распаковки файла в выбранный каталог, необходимо выполнить прежние команды:

      ./configure
      make
      make install

      Если при выполнении configure у вас возникнет ошибка, придется остановиться и выполнить все требования предустановки нужных библиотек (например libpcap или pcre).

      Далее нам нужно создать каталог в который будут писаться события snort (это каталог с логами). Создать его можно следующей командой:

      mkdir /var/log/snort/

      Дальше два пути:

      1. Скачать готовые правила snort и установить их (полный набор правил здесь — http://snort.org/pub-bin/downloads.cgi)
      2. Разрабатывать правила с учетом особенностей своей среды (пользователей, сервисов и т.п.). В этом случае IDS будет работать быстрее.

      Есть еще третий пусть — дополнять готовую базу правил снорта своими. Эксеримента ради мы решили идти именно по этому пути. Цель нашего исследования — найти уязвимые места в последних базах снорта, в результате использования современных эксплойтов (или сканеров). Ну и как следствие, предложить правила противодйствия им, с тем, чтобы не нарушалась конфиденциальность/целостность/доступность системы.

      Итак. Настройку Снорта стоит начать с файла /etc/snort.conf
      В этом файле содержатся все необходимые параметры функционала Снорта:

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

      var HOME_NET = IP адрес

      Ниже, в том же файле, задаём внешнюю сеть, ту из которой грозит атака. Здесь можно задать маску, сетевой интерфейс и другие переменные:

      var EXTERNAL_NET = any

      Здесь же необходимо определить перечень серверов входящих в домашнюю сеть:

      Вот эти переменные:
      var DNS_SERVERS $HOME_NET//перечень используемых DNS-серверов
      var SMTP_SERVERS $HOME_NET      //перечень используемых SMTP-серверов
      var HTTP_SERVERS $HOME_NET      //перечень используемых HTTP-серверов
      var SQL_SERVERS $HOME_NET      //перечень используемых SQL-серверов
      var TELNET_SERVERS $HOME_NET      //перечень используемых TELNET-серверов
      var SNMP_SERVERS $HOME_NET      //перечень используемых SNMP-серверов

      Для начала стоит отключить все препроцессоры, которые предназначены для дополнительных пока не нужных нам проверок (проверок специфичных протоколов и др.). Для этого нам нужно закоментировать всю секцию #3

      Далее в файле (в секции 6) прописывается перечень используемых правил, которые в свою очередь разделены по видам атак. Среди прочих: DOS-атаки, DDOS-атаки, эксплойты, нежелательный трафик и т.д.

      Любой из этих наборов правил можно редактировать, дополнять. Чем мы и займемся далее.

      Снорт готов к запуску. Если в процессе запуска системы snort происходит ошибка об этом сообщает коммандная строка с описанием ошибки и номером строки конфигурационного файла.

      snort в режиме sniffer $ snort -dev
      snort как демон $ snort -D

      В случае, если snort обнаруживает совпадение с правилом, то в файл /var/log/snort/alert дописывается информация о срабатывании того или иного правила.

      Например:
      Для того, чтобы заставить snort писать не только заголовки, но и содержимое пакета нужно включить опцию «-d» для записи содержимого пакетов, или опцию «-b» для записи пакета целиком в бинарном виде.

      Как уже отмечалось выше, IDS-системы, как и сам Snort, работают на основании списка правил, по которым они и определяют есть ли в проходящем трафике «опасные» пакеты или нет. Так вот у ситемы Snort этот список правил выглядит таким образом:
      каким.
      2. Вторая часть установки снорта — это модуль SnortSam. Этот модуль позволяет связывать систему Snort с местной Firewall-системой. Другими словами это и есть активная часть системы, которая позволяет реагировать на нежелательный трафик. Итак, установка модуля SnortSam. Есть 2 варианта: Первый (более простой): — скачиваем готовые бинарники snortsam и уже модифицированный snort с сайта http://www.snortsam.net/download.html — помещаем их в каталог /usr/bin/ Второй (для опытных пользователей): — скачиваем архив с исходниками snortsam — разархивируем — компилируем snortsam (./configure , make , make install) — скачиваем архив c патчем к snort — разархивируем — запускаем pathsnort.sh в качестве параметра указываем путь к исходникам snort: $ pathsnort.sh /root/snort-2.6.0.2 — компилируем пропатченный snort (./configure , make , make install) После установка модуля нужно провести его настройку. Поключаем плагин вывода для Snort (файл /etc/snort.conf):
      img=snortsam-snortconf
      192.168.1.253 — Хост на котором запущен файрВолл и SnortSam. В качестве экспериментального фаервола мы выбрали iptables.

      Настраиваем SnortSam (файл /etc/snortsam.conf):
      ————————————————————————
      # accept /,
      #
      # В этой опции перечисляются Snort сенсоры, от которых SnortSam будет
      # принимать пакеты. Вы можете задать имя хоста, IP адресс, IP адресс и
      # маску подсети, а так же ключ шифрования, используемяй для этого хоста
      # или сети.
      #
      # Examples: accept 10.10.0.0/16, officepassword
      # accept snort1, hostpassword
      # accept 192.168.1.1
      #
      # Если паророль отсутствует, используется ключ по умолчанию DEFAULTKEY. Вы
      # можете задать только один хост в каждой строке, но Вы можете использовать
      # неограниченное количество строк.

      accept 192.168.1.253

      # bindip
      #
      # Эта опция заставляет Snortsam прослушивать только ожин IP адрес (или
      # интерфейс), вместо всех интерфейсов/адресов.
      #
      # Пример: bindip 192.168.0.1

      bindip 192.168.1.253

      # iptables
      #
      # Этот плагин вызывает iptables для блокирования хоста, путём домавления
      # правила к набору активного списка блокировки. Вы должны указать адаптер
      # на котором осущесвляется блокировка (напр. eth0), так же Вы можете указать
      # опции логирования.
      #

      ————————————————————————
      Убеждаемся, что незадано никаких правил фильтрации для ФайрВолла:
      ————————————————————————
      # iptables -L
      Chain INPUT (policy ACCEPT)
      target prot opt source destination

      Chain FORWARD (policy ACCEPT)
      target prot opt source destination

      3. Двигаемся дальше. IDS настроена. Время для проведения экспериментов. В натуральном исполнении нам понадобится web-сервер (это чуть позже), пока же проведем эмуляцию сервера с помощью программы netcat.

      Как уже было сказано выше, Snort работает с сигнатурами. Сигнатура — это совокупность байт индивидуально идентифицирующих приложение. Например любой WEB обозреватель, прежде чем запросить HTML страницу с сервера, посылает ему определённую информацию (представляется), для более комфортного взаимодействия (использования специфических функций работающих только в представляющемся приложении). Эта информация, в частности, включает в себя и уникальное имя (версию) броузера. Чтобы это увидеть, запустите на своём компьтере (в консоле) программу NetCat (которая позволяет имулировать web-сервер), как показано ниже.

      # nc -l -p 80

      Флаги:
      -l (listen) Запускает NetCat в режиме прослушивания порта;
      -p (port) Прослушивает указанный порт (в нашем случае 80)

      Все обозреватели интернет, по умолчанию запрашивают WEB страницу с 80 (http) порта. Поэтому мы будет эмулировать WEB сервер, пока нам для этого хватит только прослушивание порта сервера. Нужно помнить! Если ваш порт 80 занят другим приложением, вам необходимо закрыть это приложение, чтобы пример работал правильно. Что это проверить, нужно запустить:

      netstat -anb : для Windows
      netstat -anp | grep 80 : для Linux

      Среди результатов необходимо найти программу которая занимает порт 80.
      Если таковой нет, значит порт свободен.

      Теперь нужно запустить любой интернет обозреватель, и наберите адрес:
      http://localhost

      После этого NetCat должен Вам показать все, передаваемые броузером, HTTP заголовки. А броузер выдаст ошибку по которой он неможет найти хост или
      открыть стараницу (так как NetCat не реализует весь функционал WEB сервера).

      Ниже приведены примеры HTTP заголовков для InternetExplorer 6.0.2900 и для Firefox 2.0.0.2.

      Вот как представился InternetExplorer 6.0.2900:
      — InternetExplorer ——————————————————-
      GET / HTTP/1.1
      Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
      Accept-Language: en-ca
      Accept-Encoding: gzip, deflate
      User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Maxthon)
      Host: localhost
      Connection: Keep-Alive
      —————————————————————————-

      А вот так Firefox 2.0.0.2:
      — Firefox —————————————————————-
      GET / HTTP/1.1
      Host: localhost
      User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
      Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;
      q=0.5
      Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
      Accept-Encoding: gzip,deflate
      Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
      Keep-Alive: 300
      Connection: keep-alive
      —————————————————————————

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

      Допустим Вы убеждённый фанат открытого исходного кода и не хотите пускать коммерческий InternetExplorer на свой WEB сайт. Реализуем эту идею с
      помощью Snort. Для начала научимся просто распознавать наличие IE в Snort’е, а затем посмотрим как мождно заблокировать доступ к сайту.

      Допустим у вас установлен WEB сервер и Snort на одном компьютере. Чтобы настроить Snort на обнаружения InternetExplorer, добавим своё правило в стандартные правила Snort. По умолчанию папка для правил распологается по адрессу «/etc/snortrules/rules». Для пользовательских правил существует специальные файл «local.rules». Изначально правил там
      нет, добавим туда такую строку:

      alert tcp any any -> $HOME_NET 80 (msg: «M$ InternetExplorer detected»; content: «MSIE»; nocase;)

      Сохраниете файл и перезапустите Snort. Теперь зайдите с любого комьютера к сайт через IE. В логах Snort’a появиться соответствующее сообщение из
      нашего правила. Следует заметить, что другие обозреватели (напр. FF) не вызовут никакого логирования.

      Теперь научим Snort блокировать хост, с которого производится запрос к нашему сайту через IE. Для этого понадобиться плагин для Snort’а Snortsam (который мы уже настроили).
      Всё что необходимо сделать это немного отредактировать наше правило. Теперь оно должно выглядеть так:

      alert tcp any any -> $HOME_NET 80 (msg: «M$ InternetExplorer detected»; content: «MSIE»; nocase; fwsam: src, 1 hour;)

      1 hour — (1 час) это время на которое «злоумышленник» будет заблокирован. Попробуйте снова войти на сайт с помощью IE, и убедитесь, что этот сайт не
      сообщит вам никакой информации в течении часа. А если не смените броузер, то и никогда.
      Таким образом мы забраликовали нежелательный трафик. Сделали мы это с помощью IDS Snort, ее модуля SnortSam и фаервола IPtables. Нужно понимать, что это лишь тривиальный пример блокирования нежелательного трафика. На примере браузера сработало. Теперь стоит проверить на примере специализированных сетевых приложений, например сетевого сканера, собирающего информацию по работающему серверу. Итак, в качестве сканера мы выбрали широко распространенный и функциональный XSpider.
      Поставим задачу заблокировать сетевой сканер, на примере XSPider 7.5.
      Для этого нам понадобится установленный WEB сервер. Для примера, выберем широко известный Apache. Сначала нам необходимо найти уникальную сигнатуру сканера.
      Для наглядности определим сигнатуру XSPider’а. Сделаем это используя стандартные средства логирования сервера и с помощью сниффера. В качестве сниффера будем использовать Wireshark, но подойдём и любой другой. Все приходящии от клиентов запросы Apche записывает в файл access.log. В конфигурационном файле Apache (по умолчанию httpd.conf), должна присутствовать запись вида:

      CustomLog logs/access.log common

      Будем использовать этот факт для прослеживания действий XSPider. Итак, запускаем Wireshark на прослушивание локального интерфейса. А на втором хосте запускаем XPSpider. Добавляем хост для сканирония на котором установлен Web сервер, из контекстного меню хоста «Сканировать отдельный сервис» и вводим порт 80 (порт web сервера). Теперь нажимаем
      кнопку «Сканировать» и немного подождём.

      Переместим всё внимание на хост Web сервера. Просмотрим файл access.log, первые запросы сканера выглядят следующим образом:

      192.168.1.111 — — [17/Mar/2007:12:40:11 +0300] «GET / HTTP/1.1» 200 709
      192.168.1.111 — — [17/Mar/2007:12:40:12 +0300] «GET SCANNER HTTP/1.1» 400 342
      192.168.1.111 — — [17/Mar/2007:12:40:12 +0300] «GET /hxaiktusqunkqknr.htm HTTP/1.1» 400 395
      192.168.1.111 — — [17/Mar/2007:12:40:13 +0300] «GET / HTTP/1.1» 200 709
      192.168.1.111 — — [17/Mar/2007:12:40:13 +0300] «GET /https-admserv/bin/index HTTP/1.1» 404 297
      192.168.1.111 — — [17/Mar/2007:12:40:13 +0300] «GET /Admin.po?proceed=yes HTTP/1.1» 404 282
      192.168.1.111 — — [17/Mar/2007:12:40:14 +0300] «GET /Admin/index.jsp HTTP/1.1» 404 289
      .

      Весьма специфичным является второй запрос, где от сервера требуется предоставить файл «SCANNER»:

      192.168.1.111 — — [17/Mar/2007:12:40:12 +0300] «GET SCANNER HTTP/1.1» 400 342

      Естественно мало на каком сайте подобный файл будет существовать и мы можем воспринимать его как приветствие XSPider’a. Среди результатов Wireshark’а тоже можно увидеть эту картину. Для большей наглядносьти применим фильтр

      (ip.src == 192.168.1.105) && (http.request.method == «GET»)

      Запрос «SCANNER» явно отличается от остальных, хотя бы тем, что не указан в абсолютной форме, т.е. не начинается со знака «/». Многие сканеры
      безопасности специально оставляют свои сигнатуры при поисках уязвимостей. Теперь когда мы знаем, как представляется XSPider, мы можем его
      заблокировать при помощи системы Snort (при помощи все того же модуля Snortsam). Для этого добавим в файл «local.rules»
      строку:

      alert tcp any any -> $HOME_NET 80 (msg: «XSpider detected»; content: «GET SCANNER HTTP/1.1»; nocase; fwsam: src, 1 hour;)

      После этого эксперимента ради попробуем просканировать XSPider’ом Web сервер ещё раз. Результат: сканер заблокирован на 1 час.
      Другими словами мы заблокировали попытку сканирования с любого IP адреса наш web-сервер с использованием сканера XSpider. Подобным образом можно настроить Snort на любой другой сканер (эксплойт). Обязательным условием, в данном случае, должно быть то, что эта утилита должна как-то отличаться от обычного трафика (иметь постоянную сигнатуру, по которой ее можно вычислить).

      Мы провели анализ некоторых современных сетевых эксплойтов реализующих атаку типа DOS. Эксплойты действительно выбивали из строя современную ОС Win XP SP2, однако при этом никаким образом не представлялись, посылая лишь классические SYN пакеты с попыткой установления соединения. Так вот такие эксплойты заблокировать с помошью IDS Snort нам не удалось. Продолжаем свое исследование.

      SNORT как сервисная IPS

      Про SNORT было сказано много, но в большинстве статей речь идёт о SNORT, как о средстве тотального наблюдения за сетью, которое собирает все данные с сетевого интерфейса. В этой статье я расскажу как собрать конструкцию, в которой SNORT будет в режиме IPS следить не за всем трафиком на интерфейсе, а только за трафиком, который можно описать с помощью правил для iptables. Я не буду касаться настройки правил, речь будет исключительно о том, как на голой системе собрать SNORT для работы в режиме IPS и как подойти к защите им абстрактного сервиса. Так же будет описана сборка и запуск SNORT.

      Как работает?

      Поступив в SNORT, пакет последовательно проходит через декодеры, препроцессоры и только потом уже попадает в детектор, который начинает применять правила. Задача декодеров сводится к тому, чтоб из протоколов канального уровня( Ethernet, 802.11, Token Ring…) «вытащить» данные сетевого и транспортного уровня (IP, TCP, UDP).

      image

      • Контроль состояния (контроль соблюдения протокола)
      • Сборка сеанса (объединение данных из нескольких пакетов сеанса)
      • Нормализация протокола (довольно скользкая фича с правкой заголовка пакета на лету)

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

      Компиляция SNORT.

      Качаем последнюю Ubuntu 11.04. Установка описана для 32х разрядной системы. Скачиваем всё необходимое:

      daq-0.5.tar.gz
      libdnet-1.11.tar.gz
      libnetfilter_queue-1.0.0.tar
      libnfnetlink-1.0.0.tar
      libpcap-1.1.1.tar.gz
      pcre-8.12.zip
      snort-2.9.0.5.tar.gz
      snortrules-snapshot-2903.tar.gz

      Устанавливаем необходимые пакетики:

      apt-get install bison flex gcc g++ zlib1g-dev

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

      pcre-8.12.zip
      libpcap-1.1.1.tar.gz
      libdnet-1.11.tar.gz
      libnfnetlink-1.0.0.tar
      libnetfilter_queue-1.0.0.tar
      daq-0.5.tar.gz

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

      ./configure —libdir=/usr/lib —includedir=/usr/include

      Если при конфигурации daq мы видим строчку «Build NFQ DAQ module… :yes» и всё скомпилировалось без проблем, то мы на верном пути. Теперь ключевой момент всей затеи – сборка SNORT:

      ./configure —libdir=/usr/lib —includedir=/usr/include —enable-ipv6 —enable-gre —enable-targetbased —enable-decoder-preprocessor-rules —enable-active-response —enable-normalizer —enable-reload —enable-react —enable-zlib

      —enable-ipv6 – поддержка IP v6 (внезапно капитан!).
      —enable-gre – поддержка GRE инкапсуляции.
      —enable-targetbased – поддержка сбора фрагментированных пакетов.
      —enable-decoder-preprocessor-rules – поддержка правил для реакции на аномалии выявленные в трафике при работе препроцессоров и декодеров.
      —enable-active-response – поддержка внедрения в сеанс пакета при срабатывании правила.
      —enable-normalizer – поддержка нормализатора протоколов.
      —enable-reload – возможность загрузки/выгрузки правил без перезагрузки SNORT.
      —enable-react – поддержка немедленного обрыва сеанса (RST) при срабатывании правила.
      —enable-zlib– поддержка обработки сжатого трафика.

      Далее make; make install. SNORT установлен.

      Настройка боевого пуска.

      Свежескачанный конфиг снорта производит тяжёлое впечатление на неопытного пользователя, но если понимать его структуру, то разобраться в нём просто. Сокращённый вариант самого минимального конфига, который решает нашу задачу в общем виде выглядит так:

      # Пункт 1: Глобальные переменные для конфига
      #Используются в кофиге и правилах
      var HOME_NET any
      var RULE_PATH ../rules
      # Пункт 2: настройка декодеров
      config disable_decode_alerts
      ……
      # Пункт 3: настройка детектора
      # Разные тонкости применения правил
      config pcre_match_limit: 3500
      ……
      # Пункт 5: Настройка препроцессоров
      # Препроцессоры нормализации пакетов
      # нормализуют протоколы на лету, от чего,иногда, случаются неожиданности
      preprocessor normalize_ip4
      ….
      # Препроцессор обработки дефрагментированых пакетов
      preprocessor frag3_global: max_frags 65536
      …
      # Препроцессоры контроля состояний и построения сеансов
      preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp ….
      …
      # Пункт 6: подключение библиотек детализации вывода
      include classification.config
      …..
      # Пункт 7: подключение правил
      include $RULE_PATH/test.rules

      Для простоты в файле test.rules у нас будет только одно правило:
      reject tcp any any -> any any (msg:»Test pattern for snort abc123″; content:»abc123″; classtype:shellcode-detect; sid:310; rev:1;)
      Это правило говорит, что в случае обнаружения во входящих tcp пакетах подстроки abc123, то источнику немедленно будет послан RST, и сеанс будет прерван. Опасный пакет дальше IPS в систему не попадёт. Запускаем SNORT:

      snort -Q —daq nfq —daq-var queue=2 -c /home/ubuntu/Downloads/snort/etc/snort.conf -l /var/log/snort -A full

      -Q – работа в режиме IPS
      —daq – источника пакетов
      —daq-var – параметры источника пакетов
      -с – путь к конфигу
      -l – путь к логам
      -A full – подробные логи (описание атак и дампы трафика)
      -D – работа в режиме демона ( использовать, когда всё отлажено)

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

      Создание очереди.

      Пакетный фильтр системы можно настроить так, чтоб он передавал полученный пакет с уровня ядра на уровень пользователя, где пользовательская программа будет обрабатывать его и передавать обратно на уровень ядра, в нашем случае эта программа — SNORT. Так как SNORT у нас запущен для работы с нумерованнной очередью (NFQUEUE), то нам необходимо фильтруемый трафик в эту очередь поставить:
      iptables -t nat -A PREROUTING -p tcp —dport 8080 -j NFQUEUE —queue-num 2

      Зачем была выбрана цепочка PREROUTING ?

      image

      В модели Iptables пакет попадает в базовую очередь PREROUTING до того, как к нему будут применены какие-либо правила маршрутизации. Отправка пакета в SNORT на этом этапе удобна тем, что далее мы можем его либо обрабатывать локально, либо переслать его дальше, например, используя NAT. Плюсом использования нумерованных очередей является то, что очередей можно создать несколько и трафик каждой очереди пропустить через снорт, запущенный с набором правил, заточенным под фильтруемый трафик. Серьёзным минусом такого подхода является то, что в случае падения SNORT, защищаемый сервис становится недоступен, так как передавать данные из режима пользователя назад в ядро становится некому. После запуска SNORT и создания очереди следует сразу же проверить работу, послав, например через netcat, в очередь сигнатуру из правила – abc123. Если всё было сделано правильно, то соединение будет немедленно разорвано.

      Мониторинг.

      Запущенный с описанными параметрами SNORT будет для каждой выявленной угрозы писать в alert файл (так же он может писать в базу или отправлять syslog):

      [**] [1:310:1] Test pattern for snort abc123 [**]
      [Classification: Executable Code was Detected] [Priority: 1]
      01/19-12:03:12.155213136 172.16.249.1:56473 -> 172.16.249.130:8080
      TCP TTL:64 TOS:0x0 ID:1241 IpLen:20 DgmLen:59 DF
      ***AP*** Seq: 0x9510F391 Ack: 0xC40C0E14 Win: 0x8218 TcpLen: 32
      TCP Options (3) => NOP NOP TS: 125531844 9470333

      И писать в log файл кусок сеанса в котором была обнаружена сигнатура, это может пригодиться для выявления ошибок детектирования. На этом работа SNORT заканчивается и в дело вступают «системы анализа логов SNORT». Де факто, это наборы скриптов разной степени убогости, к которым, в некоторых случаях, прилагается душераздирающий «веб интерфейс» (BASE, ACID…). Основные их недостатки – неспособность проводить гибкий анализ данных и неэффективная работа с СУБД, которая выливается в неспособность работать с большими объёмами данных. По моему опыту, единственным решением, которое делает работу с логами снорта сносной, является Splunk. В общем виде, Splunk – система управлениями логами, которая сохраняет их, индексирует и обсепечивает удобный интерфейс для работы с получившейся базой. Это проприетарное ПО, которое является условно бесплатным (объём индексируемых данных в сутки не более 500Мb, что для snort более чем достаточно). Система сочетает в себе удобство управления и способность работать с большими объёмами данных, и самое главное: для этой система существует плагин, специально заточенный для работы с логами SNORT. Скачать Splunk можно здесь

      Устанавливаем splunk:
      dpkg -i splunk-4.2.1-98164-linux-2.6-intel.deb
      Запускаем:
      /opt/splunk/bin/splunk start

      Идём на веб-морду, находим и устанавливаем плагин:

      image

      Далее добавляем источник данных – файл. Там всё интуитивно понятно и единственный тонкий момент, в том что Source Type нужно задать вручную: snort_alert_full. Когда всё готово, то генерируем алерт ( через netcat посылаем abc123 на защищаемый порт). И видим в splunk:

      image

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

      image

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

      Заключение.
      • Выстроить систему управление версиями правил и хранить правила на стороннем хосте (SVN вполне годится).
      • Разработать план аварийного режима работы (если снорт упал, и трафик не ходит).
      • Recovery plan на случай, если железка со снортом сломается с потерей данных.
      • Создать тестовое правило типа описанного выше abc123, которым следует проверять работу снорта каждый раз после внесения каких-либо изменений.
      Похожие публикации:
      1. Compare c как работает
      2. Как расшифровать коды энигмы
      3. Почему не вышел amlogic s908x
      4. Что вам могут подбросить 100 к 1 ответ

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *