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

    Введение.

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

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


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

    image

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

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

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

    Компиляция 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, которым следует проверять работу снорта каждый раз после внесения каких-либо изменений.

    С удовольствием отвечу на вопросы.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 23
    • 0
      Чем отличается SNORT от SourceFire?
    • +2
      Извините за занудство, но перед словом «как» не всегда ставится запятая, и в заголовке данного поста она не нужна.
    • +1
      Расскажите, пожалуйста, можно ли использовать snort для обнаружения Ddos-атак без декодирования пакетов? Насколько эффективны правила вида:

      alert tcp !$HOME_NET any -> $HOME_NET 80 (flags: S; msg:"Possible TCP DoS"; flow: stateless; threshold:
      type both, track by_src, count 70, seconds 10; sid:10001;rev:1;)
      • 0
        Снорт? Для отражения DDoS? Да вы чего??
        • +1
          для обнаружения
        • 0
          Технически можно — обнаружить вы скорее всего успеете. Но смысла нет, так же легко констатировать ддос можно, обнаружив падение сервиса. Смысл обнаружения и наблюдения DDOS в том, чтоб можно было оценивать эффективность принимаемых мер, то есть сама система наблюдения за DDOS должна быть уязвима в гораздо меньшей степени. В описанном случае лучшим источником по которым следует наблюдать ddos являются счётчики на активном сетевом оборудовании.

          Snort это, конечно, очень гибкий инструмент, но нацелен он на обнаружение\предотвращение вторжений.
        • +4
          в системах с пакетным менеджментом… нужно по аккуратнее с make install.
          в идеале, забыть про make install

          правильный вариант сделать пакет и установить его
          sudo auto-apt update && auto-apt -y run ./configure
          checkinstall -D
          sudo dpkg -i ваш_пакет.deb

          Установка пакетов по запросу
          www.debian.org/doc/manuals/apt-howto/ch-search.ru.html

          Как правильно компилировать
          vasilisc.com/tips_ubuntu#right_compile
          • +1
            Спасибо, интересно.
            А что именно make install может поломать? Какие косяки могут быть результатом make install и как с ними бороться?
            • +1
              make install ставит в обход системы управления пакетов, может установить в не принятые в данном дистрибутиве пути.

              установленная программа в системе никак «не зарегестрирована».
              нельзя штатно обновить/удалить программу и тд и тп
              в системах с пакетным менеджментом нужно всячески стремится использовать пакеты
              1) лучше в репозиториях
              2) хотя бы из одиночных пакетов
              3) создавать пакеты из исходников и делится ими, чтобы не «опять-двадцать-пять»
              • 0
                Если делаете 'make install' на пакетном дистрибутиве, вызывайте как минимум:
                configure --prefix=/usr/local
              • +1
                checkinstall — это тоже quick&dirty хак. Если совсем по фен-шую, то нужно собирать пакеты с помощью debuild и майнтейнить собственный PPA.
              • 0
                Ну а чем вам анализатор снорта snorby.org не понравился? По сравнению с тем же (BASE, ACID…) он выгодно отличается в лучшую сторону. Намного лучшую)
                • 0
                  Я 2 дня пытался его запустить, но драйвер для связи с субд работать так и не начал. И ruby я не знаю.
                  • 0
                    Я установил все из пакета (который предложил разработчик) и все отлично заработало. Все логи складываются в MySQL базу плюс после небольшого «шаманства» в эту же базу складываются и логи с удаленных сенсоров. ruby я тоже не знаю…
              • 0
                Кстати, есть неплохая альтернатива
                Тут можно посмотреть сравнение
                • 0
                  Позвольте поинтересоваться, что вы искали по запросу «kiss my babushka» или это чисто пасхальное яйцо?
                  • 0
                    Ссылка на Splunk битая. Брать отсюда: www.splunk.com/download
                    • 0
                      А как вы думаете — удобно анализировать ( правилами ) TCP трафик в или например HTTP. Как я понял препроцессоры могут переводить TCP в HTTP, или я что то путаю? На каком уровне рекомендуется анализировать. Спасибо

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.