Ключевые слова:snort, ids, (найти похожие документы)
From: Dr_UF0_51 <civufo[AT]mail[DOT]ru>
Newsgroups: http://rst.void.ru
Date: Mon, 17 Sep 2008 17:02:14 +0000 (UTC)
Subject: Система обнаружения вторжений на базе IDS Snort
Оригинал: http://rst.void.ru/papers/snort.txt
Введение
На сегодняшний день Интернет и другие сети достигли небывалых вершин. Почти
все компании на всем земном шаре так или иначе связаны с миром Интернет, а
большая часть из них имеет еще и внутренние сети. С появлением Интернета жизнь
и работа стала намного проще. Сейчас сеть - это кислород, без которого
остановится прогресс. И кажется, что все замечательно: технологии развиваются,
данные передаются с высочайшей скоростью, можно сидеть и наблюдать за всеми
этими процессами практически беззаботно, но все это может рухнуть в любую
секунду, когда в сети оказывается человек, которому что-то нужно от вас или
вашей компании. Тогда все встает под угрозу. И в один момент вы заметите, что
ваши технологии начали использовать конкуренты, секреты компании раскрылись,
так же как и коммерческая информация. И становится ясно, что все эти
технологии могут использоваться не только во благо, но и во вред. Для того
чтобы отрезать возможные пути и попытки взломщика на стадии изучения вашей
сети, чтобы детектировать многие атаки, чтобы обнаружить нежелательную
деятельность внутри сети - используются ситемы обнаружения вторжений (IDS). В
этой статье я хотел бы рассказать про мощнейшую систему под названием Snort.
Немного о Snort
Snort является свободно распространяемой программой с открытым исходным кодом
под лицензией GPL. Изначально Snort был создан одним из известнейших людей в
мире информационной безопасности, автором многих книг Мартином Рошем в 1998
году. Основной причиной создания этой IDS было отсутствие на тот момент
достаточно эффективного, тем более бесплатного, инструмента оповещения об
атаках.
Сейчас совершенно точно можно сказать, что Snort является самой
распространенной IDS в мире, во многом благодаря ее открытости и великолепной
работе авторов.
Возможности
Эта IDS выявляет следующее:
- Плохой трафик
- Использование эксплоитов (выявление Shellcode)
- Сканирование системы (порты, ОС, пользователи и т.д.)
- Атаки на такие службы как Telnet, FTP, DNS, и т.д.
- Атаки DoS/DDoS
- Атаки связанные с Web серверами (cgi, php, frontpage, iss и т.д.)
- Атаки на базы данных SQL, Oracle и т.д.
- Атаки по протоколам SNMP, NetBios, ICMP
- Атаки на SMTP, imap, pop2, pop3
- Различные Backdoors
- Web-фильтры (порнография)
- Вирусы
А если еще учесть
- Возможность написания собственных правил
- Расширение функциональности, используя возможность подключения модулей
- Гибкую систему оповещения об атаках (Log файлы, устройства вывода, БД и.д.)
то мы получаем мощнейшую систему, которая действительно является одним из
лучших инструментов в борьбе против злоумышленников.
Snort поддерживает следующие интерфейсы для прослушивания:
- Ethernet
- SLIP
- PPP
IDS Snort может работать на многих операционных системах :Linux, Windows,
IRIX, SunOS, *BSD и др. Поскольку настройка на всех платформах одинакова, то я
рассмотрю версию для Linux.
Также хотелось бы отметить отличное расширение функциональности для Snort под
названием inline, который позволяет связать firewall с действиями правил. К
примеру, можно передать firewall?у IP адрес того хоста, с которого пришел
подозрительный пакет, и дать команду игнорировать весь трафик с этого IP.
Часто это применяется при DDoS атаках. В свою очередь Snort получает пакеты не
от библиотеки libpcap, а от iptables. Но существует и обратная сторона.
Рассмотрим ситуацию, когда злоумышленник поймет как происходит блокирование и
сможет воспользоваться этим, подделывая пакеты и присылая их с важных для вас
и вашей компании серверов, вызывая тем самым состояние DoS. Поэтому
специалисты по безопасности крайне не рекомендуют реализовывать данную
возможность или же использовать ее только в исключительных случаях. В том
случае, если вы все-таки решили использовать inline, то обязательно надо
создать список неблокируемых серверов, которые жизненно необходимы для вас и
вашей компании.
Подробнее об Snort-inline можно узнать с официального сайта: http://www.snort-inline.comУстановка Snort
Где скачать
Последнюю версию Snort всегда можно найти на сайте разработчиков:
http://www.snort.org. С этого же ресурса необходимо скачать стандартный пакет
с правилами. Можно установить дополнительные правила, и даже купить некоторые
из них, недоступные широкой публике. На этом же сайте существует возможность
подписаться на неплохую подписку. Для тех, кто желает задать вопросы, может
получить ответы на IRC канале #snort сервера irc.freenode.net.
Куда лучше установить IDS
Дальше возникает вопрос: где в сети должен находиться Snort? Конечно, если в
вашей сети есть выход в Internet, то можно установить IDS до или после
межсетевого экрана. Если мы запустим Snort до брандмэуера, то сможем получать
все предупреждения о попытках взлома и принять соответствующие меры, если
после, то мы получим малые результаты, так как фаервол может отбрасывать
интересные пакеты.
Многие специалисты по сетевой безопасности советуют устанавливать Snort сразу
на двух машинах до и после - это обеспечит максимальную надежность получения
нужной информации. Также эффективно можно использовать систему обнаружения
вторжений с помощью маршрутизаторов, поддерживающих зеркалирование трафика. К
примеру, настраиваем IDS на машине и зеркалируем весь трафик с маршрутизатора
на машину с IDS. Для менее крупных сетей можно использовать концентратор для
того, чтобы прослушивать весь трафик.
Конфигурация установочной программы
Я буду описывать все опции настроек, используя последнюю на данный момент
версию Snort 2.4.3.
Установка не вызывает трудностей. Выполняем:
$ ./configure && make && make install
Важно заметить, что у configure существует множество довольно интересных
опций. Ниже приведены некоторые из них:
Инсталляционные директории:
--prefix=PREFIX префикс к архитектурно-независимым файлам [/usr/local]
--exec-prefix=EPREFIX префикс к архитектурно-зависимым файлам [PREFIX]
Опции для указания инсталляционных директорий
--bindir=DIR пользовательское исполнение (PREFIX/bin)
--sbindir=DIR исполнение системного администратора (PREFIX/sbin)
--libexecdir=DIR выполнение программ (PREFIX/lib)
--datadir=DIR только для чтения архитектурно-независимый каталог
(PREFIX/share)
--sysconfig=DIR только для чтения конфигурационный каталог
(PREFIX/etc)
--sharedstatedir=DIR изменяемый архитектурно-независимый каталог
(PREFIX/com)
--localstatedir=DIR изменяемый конфигурационный каталог (PREFIX/var)
--includedir=DIR заголовочные файлы C (PREFIX/include)
--oldincludedir=DIR заголовочные файлы не C (/usr/include)
--infodir=DIR документация (PREFIX/info)
--mandir=DIR документация man (PREFIX/man)
Опции пакета
--with-PACKAGE[=ARG] использовать PACKAGE [ARG=yes]
--without-PACKAGE не использовать PACKAGE
(аналогично --with-PACKAGE=no)
--with-libpcap-includes=DIR директория с вложенными файлами для
библиотеки libpcap
--with-libpcap-libraries=DIR каталог с библиотекой libpcap
--with-libpcre-includes=DIR каталог с вложенными фалами для библиотеки
libpcre
--with-libpcre-libraries=DIR каталог с библиотекой libpcre
--with-libnet-includes=DIR директория с вложенными файлами для
библиотеки libnet
--with-libnet-libraries=DIR каталог с библиотекой libnet
--with-mysql=DIR поддержка mysql
--with-odbc=DIR поддержка odbc
--with-postgresql=DIR поддержка postgresql
--with-pgsql-includes=DIR директория с вложенными файлами postgresql
--with-oracle=DIR поддержка oracle
--with-libprelude-prefix=PFX префикс, куда установлена библиотека
libprelude
--with-libipq-includes=DIR каталог с вложенными файлами для библиотеки
libipq
--with-libipq-libraries=DIR каталог с библиотекой libipq
--enable-perfmonitor включить препроцессор perfmonitor
--enable-inline использовать интерфейс libipq для snort inline
--enable-ipfw использовать ipfw для snort inline
--enable-debug это только для разработчиков, опция для
отладки
После завершения установки нужно убедиться, что удовлетворены все зависимости
удолетворены и Snort находится в рабочем состоянии (запускаем в режиме
sniffer):
$ snort -dev
Запустим любое сетевое приложение и проверим, выводит ли Snort данные о
пакетах. Конечно, запуск должен осуществляться с правами суперпользователя,
так как основа Snort построена на использования библиотеки libpcap. Libpcap и
осуществляет прослушивание всего трафика. Библиотека позволяет видеть Snort
пакеты до того, как они будут восприняты остальными приложениями, а на этом
уровне требуются права суперпользователя. Последнюю версию библиотеки можно
найти на : http://www.tcpdump.org.
Примечание: если вы используете Snort под windows, то потребуется аналог
библиотеки libpcap под названием winpcap. Ее можно найти на сайте: http://www.winpcap.comНастройка snort.conf
Далее следует настроить файл : "snort.conf". Пример этого файла можно найти в
каталоге "etc/", который в свою очередь находится в разархивированной
директории вместе со Snort. Остановимся подробнее на опциях.
Примечание: символом "#" обозначены комментарии, которые Snort не распознает.
Фаил опций можно разбить на 5 основных частей:
1) Установка значений для вашей сети
2) Конфигурация препроцессоров
3) Конфигурация плагинов
4) Добавление директив
5) Используемые правила
Ниже приведен файл конфигурации snort.conf с описанием всех опций и
препроцессоров:
snort.conf
####################################################
## Установка значений для вашей сети
var HOME_NET any
# Домашняя сеть, из которой возможны атаки, то есть хост или список хостов,
# трафик которых, будет анализировать Snort.
# Примечание: тут возможны исключения для некоторых видов атак и некоторых
# препроцессоров.
# Можно задать маску и указать несколько адресов:
#
# var HOME_NET [10.1.1.0/24,192.168.1.0/24]
#
# Как видно из примера значение переменной $HOME_NET соответствует стандарту
# RFC 1918 (адресное пространство).
# Имеется возможность указания сетевого интерфейса : $_ADDRESS.
# Значение переменной будет равно IP адресу. Чаще всего этот параметр
# используется на компьютерах, которые получают IP адрес динамически.
# К примеру:
#
# var HOME_NET $eth0_ADDRESS
#
# Примечание: если сетевой интерфейс был перезапущен, то придется
# перестартовать Snort.
#
# НО НЕЛЬЗЯ СТАВИТЬ ПРОБЕЛЫ В УКАЗАНИИ ДАННОЙ ПЕРЕМЕННОЙ
var EXTERNAL_NET any
# Сеть, из которой может грозить атака. Аналогично вышеописанной опции можно
# задать маску, сетевой интерфейс и другие переменные.
#
# Также существует возможность использования логического отрицания, используя
# символ "!".
# Пример:
#
# var EXTERNAL_NET !$HOME_NET
#
# исключает из переменной $EXTERNAL_NET сеть $HOME_NET. Важно помнить, что
# нельзя использовать оператор исключения "!" в списках внутри скобок.
# Исключение имеет силу за скобками.
#
# Самое оптимальное значение для этой переменной "!$HOME_NET"
# Часто используется значение "any".
# Список DNS серверов нашей сети
var DNS_SERVERS $HOME_NET
# Список SMTP серверов нашей сети
var SMTP_SERVERS $HOME_NET
# Список Web серверов нашей сети
var HTTP_SERVERS $HOME_NET
# Список SQL серверов нашей сети
var SQL_SERVERS $HOME_NET
# Список TELNET серверов нашей сети
var TELNET_SERVERS $HOME_NET
# Список SNMP серверов нашей сети
var SNMP_SERVERS $HOME_NET
# Порт для Web сервера. Параметр может использоваться в том случае, если на
# машине установлено несколько web-серверов или web-сервер находится на
# нестандартном порту.
# Здесь также можно указать список портов [80:8000].
var HTTP_PORTS 80
# Указания тех портов, на которых находятся ПО, подверженное атакам типа
# Buffer Overflow.
var SHELLCODE_PORTS !80
# Порт ORACLE
var ORACLE_PORTS 1521
# Список AIM серверов.
var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,
64.12.29.0/24,64.12.161.0/24,64.12.163.0/24,205.188.5.0/24,205.188.9.0/24]
# Путь к каталогу с правилами Snort
var RULE_PATH /etc/rules
## Конфигурация декодера
# =======================
# Выключает алерты, произведенные фазой расшифровывающей Snort
# config disable_decode_alerts
# Остановить алерты для экспериментальных TCP опций
# config disable_tcpopt_experimental_alerts
# Остановить алерты для устаревших TCP опций
# config disable_tcpopt_obsolete_alerts
# Остановить алерты для T/TCP (усовершенствование TCP)
# config disable_tcpopt_ttcp_alerts
# Остановить алерты для всех других TCP опций
# config disable_tcpopt_alerts
# Остановить алерты для неправильных IP опций
# config disable_ipopt_alerts
## Конфигурация движка
# Используется для машин с очень ограниченными ресурсами
# config detection: search-method lowmem
## Конфигурация inline
# Если на машине с IDS Snort имеется фаервол iptables, то используя inline
# можно расширить возможности, выполнять сброс пакета через физическое
# устройство. Опция берет в качестве аргумента MAC адрес устройства, используя
# который, iptables отбрасывает пакет.
# config layer2resets: 00:06:76:DD:5F:E3
###################################################
# Конфигурация препроцессоров
## Ниже представлена конфигурация препроцессоров. Синтаксис для конфигурации
# должен соответствовать:
# preprocessor :
## Конфигурация препроцессора flow
# --------------------------------
# Этот препроцессор отслеживает поток данных. Предназначен он для объединения
# многих механизмов, используемых в Snort. На данный момент flow используется
# только для определения попыток сканирования портов, используя другие
# препроцессоры. Для более подробной информации об этом препроцессоре можно
# посмотреть в файле README.flow
#
preprocessor flow: stats_interval 0 hash 2
## Конфигурация препроцессора frag2
# --------------------------------
# Этот препроцессор выполняет IP дефрагментацию.
#
# timeout [секунды] - устанавливает время ожидания в секундах до
# завершения фрагментации
#
# memcap [байты] - память, выделяемая для работы препроцессора
# frag2 (значение по умолчанию: 4194304)
#
# min_ttl [целое_число] - минимальная жизнь пакета
#
# ttl_limit [целое_число] - предел жизни пакета
#
# Препроцессор frag2 использует идентификационный номер 113 и SID:
# SID Описание
# ----- ----------
# 1 Oversized fragment (reassembled frag > 64k bytes)
# 2 Teardrop-type attack
preprocessor frag2
## Конфигурация препроцессора frag3
# --------------------------------
# Frag3 - это совершенно новый препроцессор дефрагментации, который
# обрабатывает базовые параметры IP фрагментов.
#
# Опции frag3_global:
#
# max_frags <целое_значение>:
# Максимальное число отслеживаемых фрагментов, которые могут быть активны
# одновременно. (Значение по умолчанию 8192)
#
# memcap <число_байтов>:
# Максимальное количество памяти, используемое для препроцессора frag3.
# Размер указывается в мегабайтах. (Значение по умолчанию 4MB)
#
# prealloc_frags <целое_значение>:
# Этот параметр используется для оптимизации работы. Это альтернативный
# способ управления памятью. В некоторых случаях изменение этого параметра
# ускорит процесс обработки. Не имеет значения по умолчанию. Каждый фрагмент
# равен ~1550 байт.
#
# Опции frag3_engine:
# timeout <секунды>:
# Время, за которое фрагментированный пакет может быть обработан. (Значение
# по умолчанию 60 секунд).
#
# ttl_limit <целое_значение>:
# Максимальный предел времени жизни пакета (Значение по умолчанию 5).
#
# min_ttl:
# Минимальный предел времени жизни фрагментированного пакета. (Значение по умолчанию 0)
#
# detect_anomalies:
# Активирует механизмы по обнаружению аномалий во фрагментах.
#
# policy <тип>:
# Основная политика способа фрагментации. Допустимые параметры: first, last,
# bsd, bsd-right, linux (Значение по умолчанию BSD).
#
# bind_to <список_IP_адресов>:
# IP адреса, связанные с этим движком. (Значение по умолчанию - все хосты).
#
# Пример использования frag3:
# preprocessor frag3_global: max_frags 65536 prealloc_frags 262144
# preprocessor frag3_engine: policy linux \
# bind_to [10.1.1.12/32,10.1.1.13/32] \
# detect_anomalies
# preprocessor frag3_engine: policy first \
# bind_to 10.2.1.0/24 \
# detect_anomalies
# preprocessor frag3_engine: policy last \
# bind_to 10.3.1.0/24
# preprocessor frag3_engine: policy bsd
# stream4: Анализатор потока для Snort
#----------------------------------------------------------------------
# Используется совместно с опцией -z [all|est] для защиты от генераторов шумов
# (stick/snot). Анализирует и проверяет TCP поток. Может определить типы
# сканирования портов, fingerprint, ECN, и другое.
# Если не указываются опции, то используются значения по умолчанию:
# timeout 30, memcap 8388608
#
# Аргументы:
# detect_scans - препроцессор может детектировать stealth (скрытое
# сканирование) портов и сгенерировать алерт, если
# использовать данную опцию
#
# detect_state_problems - включает тревоги для событий потока
#
# disable_evasion_alerts - отключает возможное наложение пакетов
#
# min_ttl [целое_значение] - минимальное значение времени жизни пакета
#
# ttl_limit [целое_значение] - максимальное значение времени жизни пакета
#
# keepstats [machine|binary] - сохраняет статистику сессии в
# logdir/session.log. Если значение не определено, то используется
# читабельный, понятный для человека формат записи.
#
# noinspect - отключает подробную экспертизу пакетов
#
# timeout [целое_значение] - устанавливает время ожидания в секундах
# (Значение по умолчанию 30).
#
# memcap [целое_значение] - устанавливает предел используемой памяти для
# препроцессора stream4 (Значение в байтах)
#
# log_flushed_streams - если обнаружено нечто интересное в потоке, то
# эта опция запишет все пакеты из буфера пакетов
# stream4 на диск
#
# server_inspect_limit [байты] - предел осмотра трафика со стороны сервера.
#
# state_protection - защита от нападений DoS.
#
# Препроцессор использует идентификатор 111. Значения этих идентификаторов (SID)
# приведены ниже.
#
# SID Описание
# ----- ----------
# 1 Stealth activity
# 2 Evasive RST packet
# 3 Evasive TCP packet retransmission
# 4 TCP Window violation
# 5 Data on SYN packet
# 6 Stealth scan: full XMAS
# 7 Stealth scan: SYN-ACK-PSH-URG
# 8 Stealth scan: FIN scan
# 9 Stealth scan: NULL scan
# 10 Stealth scan: NMAP XMAS scan
# 11 Stealth scan: Vecna scan
# 12 Stealth scan: NMAP fingerprint scan stateful detect
# 13 Stealth scan: SYN-FIN scan
# 14 TCP forward overlap
preprocessor stream4: disable_evasion_alerts
## Директива повторной сборки потока tcp.
# Если не передавать аргументы, то загружаются параметры по умолчанию:
# Только пересборка клиентской части
# Только пересборка по списку портов, указанных ниже
# Использует алерты для "плохих" потоков
#
# Доступны опции:
# clientonly - пересобрать трафик с клиентской стороны
# serveronly - пересобрать трафик с серверной стороны
# both - пересобрать со стороны клиента и сервера
# noalerts - выключить алерты из потока на уровне пересборки
# ports [list] - список портов. Можно указать [список], значение "all" для
# всех портов и "default" для списка портов по умолчанию.
# Список портов по умолчанию: 21, 23, 25, 53, 80, 143, 110, 111, 513
# favor_old - одобрять старый сегмент поверх нового (базируется на SEQ)
# Этот параметр является параметром по умолчанию.
# favor_new - одобрять новый сегмент поверх старого (базируется на SEQ)
# flush_begavior[режим] - имеет три параметра:
# default - использовать старый статический flushpoint. Значение по
# умолчанию.
# large_window - использовать новый статический flushpoint.
# random - использовать случайное значение в соответствии с опциями:
# flush_base, flush_seed, flush_range.
# flush_base [целое_значение] - нижняя граница диапазона, значение которого
# может принять flushpoint. Значение по
# умолчанию: 512
# flush_range [целое_значение] - число, в пределах которого может изменяться
# flushpoint. Значение по умолчанию: 1213
# flush_seed [целое_значение] - случайно генерирует flushpoint. По
# умолчанию это значение равно текущему
# времени + Snort PID
preprocessor stream4_reassemble
## Статистика
# Более подробная информация находится в файле doc/snort_manual.pdf
# preprocessor perfmonitor: time 300 file /var/snort/snort.stats pktcnt 10000
# http_inspect: Нормализует и детектирует HTTP трафик, а также аномалии
# протокола
#
# Более подробная информация находится в файле
# "doc/README.http_inspect.unicode.map"
preprocessor http_inspect: global \
iis_unicode_map unicode.map 1252
preprocessor http_inspect_server: server default \
profile all ports { 80 8080 8180 } oversize_dir_length 500
#
# Пример конфигурации:
#
# preprocessor http_inspect_server: server 1.1.1.1 \
# ports { 80 3128 8080 } \
# flow_depth 0 \
# ascii no \
# double_decode yes \
# non_rfc_char { 0x00 } \
# chunk_length 500000 \
# non_strict \
# oversize_dir_length 300 \
# no_alerts
# Препроцессор rpc_decode: нормализует RPC трафик
# -----------------------------------------------
# Препроцессор использует идентификационный номер 106
#
# Аргументы:
# alert_fragments - сообщать о любых RPC с фрагментацией
# no_alert_multiple_requests - не сообщать, если есть многократные rpc записи
# в одном пакете
# no_alert_large_fragments - не сообщать, если фрагментированный размер
# превышает размер пакета
# no_alert_incomplete - не сообщать в том случае, если количество
# данных одного фрагмента превышает размер
# пакета
preprocessor rpc_decode: 111 32771
## Конфигурация препроцессора bo [Back Orifice detector]
# ------------------------------------------------------
# Детектирует трафик Back Orifice в сетях
# Аргументы:
# Синтаксис:
# preprocessor bo: noalert { client | server | general | snort_attack } \
# drop { client | server | general | snort_attack }
# Пример:
# preprocessor bo: noalert { general server } drop { snort_attack }
#
# Препроцессор Back Orifice использует ID 105 и генерирует значения SID:
# SID Описание
# ----- -----------
# 1 Back Orifice traffic detected
# 2 Back Orifice Client Traffic Detected
# 3 Back Orifice Server Traffic Detected
# 4 Back Orifice Snort Buffer Attack
preprocessor bo
# telnet_decode: Нормализатор telnet трафика
# ------------------------------------------
# Этот препроцессор "нормализует" telnet строки при передаче данных по telnet
# и ftp. Он работает почти так же, как и препроцессор http_decode. Данный
# препроцессор не имеет никаких параметров. Используется генератор ID 109 и он
# не генерирует SID.
preprocessor telnet_decode
# sfPortscan: детектирует сканирование портов.
# ----------------------------------------------
# Этот модуль детектирует сканирование портов.
#
# Это самый новый препроцессор, объединивший в себе некоторые предыдущие
# способы детектирования.
# Для более подробной информации посмотрите файл: "README.sfportscan".
#
# Опции конфигурации:
#
# proto { tcp udp icmp ip all }
# В этом параметре указывается тип протокола. Значение all обозначает
# все перечисленные протоколы. Аргументы должны быть разделены пробелами.
#
# scan_type { portscan portsweep decoy_portscan distributed_portscan all }
# Аргумент scan_type указывает на тип сканирования. Аргументы должны
# быть разделены пробелами.
#
# sense_level { low|medium|hight }
# Этот параметр указывает на уровень чувствительности детектирования
# сканирования.
#
# memcap { целое_значение }
# Memcap указывает на максимальное количество байтов памяти для
# препроцессора sfportscan.
#
# watch_ip { Список_IP }
# Список IP адресов, за которыми следует наблюдать. Те IP адреса, которые
# не попадают в данный диапазон, будут игнорироваться.
#
# ignore_scanners { Список_IP }
# Игнорировать список IP адресов с которых будет осуществляться
# сканирование.
#
# ignore_scanned { Список_IP }
# Игнорировать список IP адресов которые будут подвержены сканированию портов.
#
# logfile { имя_файла }
# С помощью этого параметра можно указать имя файла для ведения журнала.
#
# Ниже приведен пример файла, созданного при помощи опции logfile.
#
#-[scan.log]---------------------------------
#Time: 09/08-15:07:31.603880
#event_id: 2
#192.168.169.3 -> 192.168.169.5 (portscan) TCP Filtered Portscan
#Priority Count: 0
#Connection Count: 200
#IP Count: 2
#Scanner IP Range: 192.168.169.3:192.168.169.4
#Port/Proto Count: 200
#Port/Proto Range: 20:47557
preprocessor sfportscan: proto { all } \
memcap { 10000000 } \
sense_level { low }
# arpspoof
# --------
# Это экспериментальный код для детектирования ARP атак.
# Arpspoof использует идентификационный номер ID 112 и генерирует
# нижеизложенные SID:
#
# SID Описание
# ----- ----------
# 1 Unicast ARP request
# 2 Etherframe ARP mismatch (src)
# 3 Etherframe ARP mismatch (dst)
# 4 ARP cache overwrite attack
#preprocessor arpspoof
#preprocessor arpspoof_detect_host: 192.168.40.1 f0:0f:00:f0:0f:00
# X-Link2State мини препроцессор
# ------------------------------
# Этот препроцессор детектирует уязвимость X-Link2State
# (www.microsoft.com/technet/security/bulletin/MS05-021.mspx).
#
# Синтаксис:
# preprocessor xlink2state: ports { <порт> [<порт> <...>] } [drop]
#
# Опции:
# ports - список проверяемых портов
# drop - разорвать соединение
# Опция "drop" используется только при включенном Inline режиме.
#
# SID Описание
# ----- ----------
# 1 X-Link2State length greater than 1024
preprocessor xlink2state: ports { 25 691 }
####################################################################
# Конфигурация плагинов вывода
#
# Конфигурация должна соответствовать синтаксису:
# output <имя_плагина>: <конфигурационные_опции>
# alert_syslog: передача информации syslog
# output alert_syslog: LOG_AUTH LOG_ALERT
# log_tcpdump: логирование пакетов в бинарный формат tcpdump
# output log_tcpdump: tcpdump.log
# database: запись в базы данных
# Более подробную информацию можно узнать в файле "README.database"
# output database: log, mysql, user=root password=test dbname=db
# host=localhost
# output database: alert, postgresql, user=snort dbname=snort
# output database: log, odbc, user=snort dbname=snort
# output database: log, mssql, dbname=snort user=snort password=test
# output database: log, oracle, dbname=snort user=snort password=test
# unified: бинарный формат файлов Snort (unified)
# В этом параметре поддерживается два аргумента
# filename - базовое имя файла для записи
# limit - Максимальный размер в мегабайтах (значение по умолчанию: 128)
#
# output alert_unified: filename snort.alert, limit 128
# output log_unified: filename snort.log, limit 128
# Здесь также можно создать свои новые типы для вывода в специальном формате.
#
# Вот пример, который создает новый тип:
# ruletype suspicious
# {
# type log
# output log_tcpdump: suspicious.log
# }
#
# ПРИМЕР ПРАВИЛА ДЛЯ ТИПА SUSPICIOUS:
# suspicious tcp $HOME_NET any -> $HOME_NET 6667 (msg:"Internal IRC Server";)
#
# Этот пример создает тип, который позволяет использовать базу данных mysql и
# syslog в качестве журнала:
# ruletype redalert
# {
# type alert
# output alert_syslog: LOG_AUTH LOG_ALERT
# output database: log, mysql, user=snort dbname=snort host=localhost
# }
#
# ПРИМЕР ПРАВИЛА ДЛЯ ТИПА REDALERT:
# redalert tcp $HOME_NET any -> $EXTERNAL_NET 31337 \
# (msg:"Someone is being LEET"; flags:A+;)
include classification.config
include reference.config
####################################################################
# Подключение правил
include $RULE_PATH/local.rules
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/rservices.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
#include $RULE_PATH/dns.rules
include $RULE_PATH/tftp.rules
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/web-coldfusion.rules
include $RULE_PATH/web-iis.rules
include $RULE_PATH/web-frontpage.rules
include $RULE_PATH/web-misc.rules
include $RULE_PATH/web-client.rules
include $RULE_PATH/web-php.rules
#include $RULE_PATH/sql.rules
include $RULE_PATH/x11.rules
include $RULE_PATH/icmp.rules
#include $RULE_PATH/netbios.rules
include $RULE_PATH/misc.rules
include $RULE_PATH/attack-responses.rules
#include $RULE_PATH/oracle.rules
#include $RULE_PATH/mysql.rules
include $RULE_PATH/snmp.rules
include $RULE_PATH/smtp.rules
include $RULE_PATH/imap.rules
include $RULE_PATH/pop2.rules
include $RULE_PATH/pop3.rules
include $RULE_PATH/nntp.rules
include $RULE_PATH/other-ids.rules
# include $RULE_PATH/web-attacks.rules
include $RULE_PATH/backdoor.rules
# include $RULE_PATH/shellcode.rules
# include $RULE_PATH/policy.rules
# include $RULE_PATH/porn.rules
# include $RULE_PATH/info.rules
# include $RULE_PATH/icmp-info.rules
include $RULE_PATH/virus.rules
# include $RULE_PATH/chat.rules
# include $RULE_PATH/multimedia.rules
# include $RULE_PATH/p2p.rules
include $RULE_PATH/experimental.rules
Опции запуска
После завершения конфигурации рассмотрим опции для запуска.
Примечание: опции в командной строке имеют более высокий приоритет, чем snort.conf
-A Может принимать значения: fast, full, console или none. Fast
предназна для быстрого генерирования алертов. Этот параметр
рекомендуют использовать не только разработчики, но и
специалисты в информационной безопасности. Full - самый
медленный способ, используется при необходимости.
-b Журналировать пакеты в формате tcpdump. (Это наиболее быстрый и
производительный вариант)
-c После этого параметра указывается имя с конфигурационным файлом.
-C Убирать из дампа пакета HEX значения.
-d Журналировать дамп (содержимое) пакетов.
-D Запуск Snort в режиме демона.
-e Журналировать информацию о заголовке пакета.
-f Отключает вызовы fflush() после записи бинарных логов.
-F Читать bpf фильтры из файла .
-g Запустить IDS с правами группы .
-G <0xid> Идентификатор логов. Используется, если на машине работают
несколько программ Snort.
-h Домашняя сеть = .
-i Прослушивать интерфейс с именем .
-I Добавить имя интерфейса в созданный алерт.
-k Режим контрольной суммы. Может принимать значения:
(all,noip,notcp,noudp,noicmp,none).
-K Режим логирования. Значения: pcap, ascii, none. По умолчанию
устанавливается значение pcap.
-l Писать логи в каталог .
-L Писать логи в tcpdump файл с именем .
-m Устанавливает маску .
-n Выход после получения пакета.
-N Отключает логирование (но алерты работают).
-o Выбрать правило для тестирования в Log|Alert|Pass
-O Скрывать IP адреса.
-p Отключение promisc режима.
-q Не показывать баннер Snort.
-r Записывать журнал в декодированной форме, то есть в более
читабильном виде в отличие от бинарных логов tcpdump.
-R Вставить 'id' в имя файла snort_intf.pid
-s Журналировать в syslogd. Для работы данного ключа необходимо
записать в файл syslog.conf:
"auth.alert@managmentserverIP"
-S Устанавливает значение файла с правилами n равному v.
-T Протестировать и сообщить о текущей конфигурации Snort.
-u Запустить IDS с правами пользователя .
-U Использовать UTC.
-v Подробный режим.
-V Показать версию Snort.
-w Делать дамп 802.11 контрольных фреймов.
-X Делать дамп содержимого пакета.
-y Помещать год в дату логов и алертов.
-Z Использовать путь к файлу и имя из препроцессора
performonitor (статистика).
-z Использовать гарантийный режим, используется для установленных
(established) соединений. С помощью этой опции можно распознать
генераторы шумов и успешно их блокировать, используя
препроцессор stream4.
-h Экран с помощью.
После того, как указаны эти опции, можно использовать так называемые опции
фильтров BPF. Это довольно интересная возможность, позволяющая исключать
определенные хосты для того, чтобы игнорировать их трафик. Это быстрый способ,
так как Snort при этом вообще не "видит" пакеты, так как они сбрасываются на
интерфейс BPF.
Пример использования:
$ snort <опции_командной_строки> not host 127.0.0.1
позволяет игнорировать все пакеты от 127.0.0.1.
Или, чтобы игнорировать весь ICMP трафик (ICMP ECHO-REQUESTS, ICMP-ECHO REPLY)
от машины :
$ snort <опции_командной_строки> ``not ( (icmp[0] = 8 or icmp[0] = 0) and host )``
Запуск IDS
Далее нам потребуется скопировать все файлы из каталога etc/, находящиеся в
разархивированном каталоге snort (в зависимости от вашей конфигурации файла
snort.conf), например, в /etc. Если запускать IDS не с ключом "-l", то логи
будут записываться в каталог /var/log/snort. Создадим каталог для ведения
журналов:
$ mkdir /var/log/snort
Затем скачиваем и распоковываем архив с правилами (http://www.snort.org) в
указанный в файле "snort.conf" каталог.
Теперь можно попробовать запустить IDS в режиме демона:
$ snort -D -dev -c /etc/snort.conf
После запуска демона проверим сетевой интерфейс, прослушиваемый Snort:
$ ifconfig -a
Если интерфейс находится в promisc режиме, то все отлично.
Для того, чтобы демон IDS стартовал при загрузке Unix-like системы, можно
написать простейший сценарий. Вот пример моего bash скрипта:
/etc/rc.d/rc.snort
#!/bin/bash
# Запуск IDS
snort_up()
{
if [ -x /usr/local/bin/snort ]; then
echo "Snort daemon starting: /usr/local/bin/snort"
/usr/local/bin/snort -D -dev -i any -c /etc/snort.conf
else
echo "Error! Snort daemon not found!"
fi
}
# Завершение работы демона
snort_down()
{
echo "Killing Snort daemon..."
killall -9 snort
echo "Snort daemon shutdown"
}
start()
{
if[ -r /var/run/snort_any.pid ]; then
echo "Snort alredy running"
else
snort_up
fi
}
start
Далее выполняем команду :
$ chmod +x /etc/rc.d/rc.snort
для того, чтобы сделать файл исполняемым.
И немного подправим файл "/etc/rc.inet2". Для запуска скрипта допишем
нижеизложенные строки:
/etc/rc.inet2
# Start Snort daemon
if [ -x /etc/rc.d/rc.snort ];then
/etc/rc.d/rc.snort start
fi
Примечание: файл "/etc/rc.d/rc.inet2" и сам каталог "/etc/rc.d" в вашей
системе могут называться по другому (например "/etc/init.d" или
"/etc/sysconfig" и т.п.).
Правила
Написание собственных правил - не сложное занятие, а часто даже необходимое,
так как ежедневно обнаруживаются уязвимости, а вместе с ними появляются и
программы эксплуатирующие программное обеспечение. Для того, чтобы вовремя
следить за попытками вторжения, следует научиться простому языку правил для
IDS Snort. Ведь для новой уязвимости легче написать правило самому, чем ждать
очередной версии Snort или обновления пакета с нужными правилами. Поэтому я
хотел бы рассказать об этом языке правил.
Примечание: для указания параметров в правилах часто используются переменные,
значения которых указаны в файле "snort.conf".
Примеры:
$HOME_NET - обозначает домашнюю сеть, которую надо защищать и на которую чаще
всего будут приходить пакеты. Я употребил словосочетание ?чаще всего? для
того, чтобы указать на то, что следует следить не только за входящим трафиком,
но и наблюдать за исходящими пакетами.
$HOME_NET any
any означает любой порт для $HOME_NET. Или
$EXTERNAL_NET $HTTP_PORTS
будет указывать на все HTTP порты, в свою очередь перечисленные в
"snort.conf", для $EXTERNAL_NET.
Для начала хотелось бы рассказать о структуре правил. Модель можно представить
по следующей схеме:
<действие_правила> <протокол> <порт> <оператор_направления>
<порт> ([мета_данные] [даные_о_содержимом_пакета]
[данные_в_заголовке] [действие_после_обнаружения])
Действия правил
Действия правил делятся на следующие категории:
alert - Создать предупреждение, используя выбранный метод, и передать
информацию системе журналирования.
log - Использовать систему журналирования для записи информации о
пакете.
pass - Игнорировать пакет.
activate - Использовать другое динамическое правило.
dynamic - После того, как выполнится активное правило, задействуется
правило с процедурой журналирования.
drop - Отбросить пакет, используя программный брандмэуер, и передать
информацию системе журналирования. Работает только в режиме
inline.
sdrop - Отбросить пакет при помощи программного брандмэуера и не
использовать систему журналирования. Работает только в режиме
inline.
reject - Используя брандмэуер, отбросить пакет в том случае, если протокол
TCP, или же записать в файл журнала сообщение: ICMP порт
недоступен, если пакет приходит по протоколу UDP. Работает только
в режиме inline.
Я бы хотел подробнее остановиться на activate и dynamic. Эта комбинация
позволяет создавать довольно гибкие правила. К примеру, когда приходит
подозрительный пакет и условия его содержимого совпадают с правилом activate,
то вызывается следующее динамическое правило dynamic для дальнейшего
анализа и журналирования. Это довольно удобно при анализе нескольких пакетов и
записи информации о них. Совсем не сложно создать правило, которое бы
записало 10 пакетов в журнал после того, как была обнаружена важная
информация о безопасности в предыдущем пакете.
Действие activate похоже на alert, но отличается тем, что оно указывает на
динамическое правило. В свою очередь динамическое правило схоже с log, только
вызываются оно после activate.
Протокол
После указания действия правила нужно указать протокол, по которому придет
пакет. Этот параметр может принимать следующие значения: TCP, UDP, IP, ICMP.
Но разработчики обещают в скором времени сделать поддержку следующих
протоколов: IPX, ARP, IGRP, GRE, RIP, OSPF.
IP адреса
Далее следуют два IP адреса. Первый, как правило, с которого приходит пакет, а
второй, на какой пакет отсылается. Но это не обязательно, так как между двумя
адресами можно использовать так называемый оператор направления "->", "<>"
(двустороннее), который подобно стрелкам указывает направление передачи. Важно
отметить отсутствие оператора "<-".
Поскольку Snort не имеет встроенного механизма получения IP адреса, используя
доменное имя, то нужно указывать конкретный IP адрес или же диапазон IP
адресов. В этом параметре можно использовать маски. Например, для сетей класса
C /24, для сетей класса B - /16, также можно использовать
/32. Здесь может применяться и отрицание (инвертирование),
обозначаемое символом "!" (Например: !127.0.0.1). Если вместо IP адреса
указать "any", то это будет подразумеваться абсолютно все хосты. Для указания
списка можно использовать перечисление IP адресов через "," содержащихся в
квадратных скобках "[", "]". (Например: [212.116.1.1,10.10.1.0/24]).
Порты
После IP адреса указывается номер порта, с которого отсылаются данные и на
который приходит информация (в случае применения оператора направления "->").
$EXTERNAL_NET 123 -> $HOME_NET 321
Как упоминалось выше, можно указать диапазон портов: 1:1024 (все порты в
диапазоне от 1 до 1024 включая 1 и 1024). Часто используется оператор
отрицания "!" (Например: !123:321 исключает все порты в диапазоне от 123 до
321). Если опущен один из параметров диапазона (:321 или 123:), то
пропускаемый параметр принимает крайнее значение общего количества портов, то
есть 0 или 65535.
Опции
После указания всех параметров так называемого заголовка правила, указываются
опции, по которым и будет осуществляться основной анализ пакетов.
Все опции можно разделить на четыре большие категории:
meta-data - В этих опциях не указываются данные для осуществления
проверки пакета. Здесь содержится информация о типе атаки,
возможные материалы об уязвимости, ссылки, и т.п.
payload - В параметрах этой категории указывается информация
непосредственно о данных, которые содержит пакет.
non-payload - В этой категории содержится служебная информация о пакете
(заголовок).
post-detection - Здесь указываются задачи, которые необходимо осуществить
после нахождения информации в пакете.
В тексте правила можно указывать перенос строки с помощью символа "\". Опции
указываются в между "(" и ")". А параметры, указываемые в опциях, отделяются
друг от друга точкой с запятой ";".
META-DATA (Опции для анализа данных пакета)
> MSG
В MSG указывается сообщение, которое будет выведено или же записано, используя
систему журналирования. Это сообщение обычно является идентификатором атаки.
Синтаксис:
msg:"<сообщение>";
> REFERENCE
В этом поле указываются ссылки на online системы идентификации атак.
Значениями этого поля могут быть ссылки на ресурсы bugtraq, cve, nessus,
arachnids, mcafee и другие url. Идентификация осуществляется по SID номерам.
Поддерживаемые системы:
Система URL
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 (currently down) http://www.whitehats.com/info/IDS
mcafee http://vil.nai.com/vil/dispVirus.asp?virus_k=
url http://
Синтаксис:
reference:<идентификатор_системы>,<идентификатор_запроса>; [reference:
<идентификатор_системы>,<идентификатор>;]
> SID
Этот параметр идентифицирует правила Snort. По этому значению можно определить
тип атаки. SID в правилах стандартной поставки может принимать значения от
100 до 1 000 000. Значения до 100 зарезервированы для использования в будущем.
Чаще всего при написании собственных правил используется значения свыше одного
миллиона. Подробнее об этих значениях можно узнать из файла "sid-msg.map".
Синтаксис:
sid:<целое_значение>;
> REV
В REV указывается значение версии правила. С помощью REV интерпретатор правил
Snort определяет версию написанного правила. Этот параметр используется в паре
с SID.
Синтаксис:
rev:<целое_значение>;
> CLASSTYPE
Параметр classtype используется для присвоения приоритета атаки. Для того,
чтобы узнать значения этого параметра необходимо воспользоваться данными,
находящиеся в файле "classification.config".
Синтаксис:
classtype: <класс>;
> PRIORITY
Параметр предназначен для задания правилам уровня приоритета. Возможно,
использовать параметр priority вместе с classtype, при этом изменится уровень
приоритета параметра classtype.
Синтаксис:
priority:<целое_значение>.
PAYLOAD (Опции для проверки данных, содержащихся в пакете)
> CONTENT
Можно назвать content одной из основных опций в правилах. Именно со значением
этой опции Snort сравнивает содержимое пакетов. Это некий шаблон, который
должен присутствовать в данных искомого пакета. Если в этом шаблоне IDS найдет
ту последовательность данных, которая указана в правиле, то продолжится
сравнение и выполнение действий текущего правила. Значениями этого параметра
могут быть как ASCII символы, так и бинарные коды (чаще обозначаемые HEX
последовательностями). Рекомендуется использовать в правилах именно опцию
content, так как это самый быстрый способ поиска, использующий минимум
ресурсов. Существует возможность указания нескольких content опций в одном
правиле для увеличения вероятности детектирования нужного пакета.
Синтаксис:
content:[!] "<шаблонная_строка>";
Пример:
alert tcp any any -> any 80 (content:!"GET";)
> CONTENT-LIST
Аналогично content, только искомый шаблон загружается из файла. Также можно
использовать в файле как ASCII символы, так и бинарные коды (обозначаемые HEX
последовательностями).
> RAWBYTES
Позволяет просматривать низкоуровневые, необработанные (raw) пакеты, игнорируя
любое декодирование, которое было сделано препроцессорами. То есть
осуществляет сравнение еще необработанных данных.
Работает совместно с опцией content.
Синтаксис:
rawbytes;
Пример:
alert tcp any any -> any 21 (msg:"Telnet NOP"; content: "|FF F1|";
rawbytes;)
> OFFSET
Указывает на количество байтов для смещения, с которого будет начинаться
анализ пакета. Другими словами, анализ начнется с того числа байт, указанного
в опции offset.
Работает вместе с content.
Синтаксис:
offset: <количество_байтов>;
> DEPTH
Глубина (число байт), до которого будет произведен анализ данного пакета с
помощью content. То есть поиск шаблона будет происходить только в пределах
указанной глубины. Как можно заметить, очень удобно использовать эту опцию в
паре с offset.
Работает с content.
Синтаксис:
depth: <количество_байтов>;
Пример:
alert tcp any any -> any 80 (content: "cgi-bin/phf"; offset:4; depth:20;)
> DISTANCE
После найденной последовательности информации в content, Snort пропускает
после content количество указанных байтов для дальнейшего анализа при помощи
второй опции content. Если же в строке встречается несколько строк content, то
в обработку берется только последнее значение.
Работает с content.
Синтаксис:
distance: <количество_байтов>;
Пример:
alert tcp any any -> any any (content:"ABC"; content: "DEF"; distance:1;)
> WITHIN
С помощью этого параметра, после того, как будет найден шаблон в content,
задается количество байтов, до которых будет осуществляться дальнейший анализ.
То есть анализ происходит от конца предыдущего значения content, до количества
байтов, указанных в within.
Работает с content.
Синтаксис:
within: <количество_байтов>;
Пример:
alert tcp any any -> any any (content:"ABC"; content: "EFG"; within:10;)
> URICONTENT
Параметр uricontent используется для поиска шаблона в нормализованных полях
URI. С этим параметром нужно работать осторожно, так как он обрабатывает
только нормализированные запросы.
Например:
Запрос:
/scripts/..%c0%af../winnt/system32/cmd.exe?/c+ver\end{verbatim}
В нормализованном виде:
\begin{verbatim}/winnt/system32/cmd.exe?/c+ver
URI запрос:
\begin{verbatim} /cgi-bin/aaaaaaaaaaaaaaaaaaaaa/..%252fp%68f?\end{verbatim}
Нормализованный вид:
\begin{verbatim}/cgi-bin/phf?
Синтаксис:
uricontent:[!]<строка_шаблон>;
> ISDATAAT
С помощью этого параметра можно находить и сравнивать данные пакета в
указанном диапазоне байт.
Синтаксис:
isdataat:<целое_число>[,relative]
Пример:
alert tcp any any -> any 111 (content:"PASS"; isdataat:50,relative;
content:!"|0a|"; distance:0;)
> PCRE
Довольно интересный параметр, который позволяет значительно расширить
возможность применения правил, используя регулярные выражения, похожие на те,
которые применяются в perl.
Синтаксис:
pcre:[!]"(//|m)[ismxAEGRUB]";
Думаю, следует остановиться на этом немного поподробнее.
Perl совместимые модификаторы:
i - Не учитывается регистр.
s - Метасимволы включают символ перевода строки.
m - По умолчанию строка это один большой массив символов. Если требуется
выполнить проверку на начало и конец строки, то можно использовать
символы "^" и "$" соответственно. То есть при применении модификатора
m можно анализировать все разбитые строки (при помощи "^" и "$") по
отдельности.
x - Игнорировать символы пробелов в шаблонах, если он не используется перед
символом escape или же не включен в символьный класс.
PCRE совместимые модификаторы:
A - Поиск подстроки по шаблону осуществляется в начале буфера, аналогично
"^".
E - Значение "$" задает конец строки. В том случае если отсутствует
модификатор E, то поиск осуществится перед символом новой строки.
G - Инвертирует жадность количества повторов.
Snort модификаторы:
R - Аналог distance:0;
U - Аналог uricontent.
B - Аналог rawbytes.
Пример:
alert ip any any -> any any (pcre:"/BLAH/i";)
> BYTE_TEST
Параметр для сравнения байт. Можно указывать как ASCII, так и бинарные
значения (чаще HEX).
Синтаксис:
byte_test: <число_байтов>, [!]<оператор>, <значение>,<смещение>[,relative]
[,<порядок>] [,<тип>, string];
Поясню все параметры:
число_байтов - Количество байтов ;)
оператор - Значения: >(больше), <(меньше), =(равно), !(отрицание), &(и), -(или).
значение - Сравниваемый шаблон.
смещение - Байт, с которого начинается анализ.
relative - Относительность от последнего найденного параметра.
порядок - big - старший разряд слева.
little - старший разряд справа.
тип - тип значения: oct, dec, hex.
string - Поясняет, что все данные представлены в ASCII.
Пример:
alert udp any any -> any 1234 byte_test: 4, =, 1234, 0 string, dec; msg: "got 1234!";)
> BYTE_JUMP
С помощью этого параметра можно пропустить некоторые данные, с помощью правил
внутри опции, при анализе пакета.
Синтаксис:
byte_jump: <число_байтов>, <смещение>[,relative] [,multiplier <число_байтов>]
[,big] [,little][,string][,hex][,dec][,oct][,align][,from_beginning];
Параметры:
число_байтов - Количество байтов, которые будут считаны.
смещение - Смещение, с которого начинается анализ.
relative - Анализ с последнего найденного параметра.
multiplier - Множитель на число_байтов для пропуска байт.
big - Старший разряд.
little - Младший разряд.
string - Поясняет, что все данные представлены в ASCII.
hex - Шестнадцатеричная система счисления.
dec - Десятичная система счисления.
oct - Восьмеричная система счисления.
align - Выравнивание числа байтов до следующего 32-х битного блока.
from_beginning - Указывает, что считать нужно от начала пакета.
Пример:
alert tcp any any -> any any (msg:"RPC kcms_server directory traversal
attempt"; flow:to_server,established; content:"|00 00 00 00|"; offset:8;
depth:4; content:"|00 01 87 7D|"; offset:16; depth:4;
byte_jump:4,20,relative,align; byte_jump:4,4,relative,align; content:"/../";
distance:0; reference:cve,CAN-2003-0027;reference:url,
www.kb.cert.org/vuls/id/850785; classtype:misc-attack; sid:2007;rev:5;)
> FTPBOUNCE
Этот параметр для того, чтобы определять атаки типа FTP bounce.
Синтаксис:
ftpbounce;
Пример:
alert tcp any any -> any any (msg:"FTP PORT bounce attempt";
flow:to_server,estabilished, content:"PORT"; nocase; ftpbounce;
pcre:"/^PORT/smi"; classtype:misc-attack; sid 3441; rev:1;)
> REGEX
Вместо regex нужно использовать PCRE.
NON-PAYLOAD (Опции для проверки полей заголовка пакета)
> TTL
Проверка времени жизни пакета. В этом параметре можно указать диапазон времени
жизни знаками "<"(меньше), ">"(больше), "-"(диапазон), "="(равно). К примеру,
для указания диапазона от 1 до 5 мы можем использовать значение : ttl:1-5;
Синтаксис:
ttl:[[<целое_значение->
<=]<целое_значение>;
Пример:
ttl:<3;
> TOS
Проверка типа обслуживания.
Синтаксис:
tos:[!]<целое_значение>;
Пример:
tos:!4;
> ID
Идентификационный номер в заголовке IP пакета.
Синтаксис:
id:<целое_значение>;
Пример:
id:31337;
> IPOPTS
Опции в IP пакете. Нельзя задавать в одном правиле несколько параметров
IPOPTS.
На этой опции я хотел бы остановиться подробнее.
rr - Запись маршрута (информация о том, какой метод маршрутизации был
выбран для данного пакета).
eol - Конец.
nop - Без опций.
ts - Время.
sec - Безопасность.
lsrr - Не жестко выбранный маршрут.
ssrr - Жестко выбранный маршрут.
satid - Идентификатор потока (устаревшая опция).
any - Любые опции.
Синтаксис:
ipopts:;
Пример:
ipopts:lsrr;
> DSIZE
Параметр для ограничения по размеру пакета. В этом параметре также можно
указывать диапазон чисел. (123<>321 это значит от 123 до 321)
Синтаксис:
dsize:[<>][целое_значение][<>
<целое_значение>];
Пример:
dsize:300<>400;
> FLAGS
Флаги установленные в TCP пакете. Ниже я приведу значения параметра flags.
F - FIN флаг.
S - SYN флаг.
R - RST флаг.
P - PSH флаг.
A - ACK флаг.
U - URG флаг.
1 - Зарезервированный бит 1.
2 - Зарезервированный бит 2.
0 - Флаги отсутствуют.
Модификаторы:
+ - Если установлены флаги.
* - Если установлен любой из флагов.
! - Если не установлен ни один из флагов.
Синтаксис:
flags:[+|*|!]<флаги>[<флаги>];
Пример:
alert tcp any any -> any any (flags:SF,12;)
> SEQ
Номер SEQ в TCP пакете.
Синтаксис:
seq:<целое_значение>;
Пример:
seq:0;
> ACK
Поле ACK в TCP пакете.
Синтаксис:
ack:<целое_значение>;
Пример:
ack:0;
> WINDOW
Поле размера окна в TCP пакете.
Синтаксис:
window:[!]<целое_значение>;
Пример:
window:55808;
> FLOW
Это довольно важная опция, благодаря которой правила становятся более гибким
оружием в руках системного администратора. Параметр позволяет указывать, к
какой стороне (клиент/сервер) относится правило, а также можно задать значение
типа установленного соединения.
Ниже приведены параметры опции flow:
to_client - К клиенту.
to_server - К серверу.
from_client - От клиента.
from_server - От сервера.
established - Установленное состояние потока.
no_stream - Не принимает во внимание пакеты перестроения потока.
only_stream - Только пакеты перестроения потока.
stateless - Установка состояния потока.
Синтаксис:
flow:[(established|stateless)]
[,to_client|to_server|from_client|from_server)] [,(no_stream|only_stream)];
Пример:
alert tcp !$HOME_NET any -> $HOME_NET 21 (msg:?cd incoming detected?; \
flow:from_client; content:?CWD? incoming?; nocase;)
> FLOWBITS
Позволяет работать с состояниями потока. Работает с flow
Параметры:
set - Устанавливает состояние.
unset - Убирает состояние.
toggle - Устанавливает состояние, убирая предыдущее.
isset - Проверяет, установлено ли состояние.
isnotset - Проверяет, не установлено ли состояние.
noalert - Отключает алерты.
Синтаксис:
flowbits: [set|unset|toggle|isset, isnotset,noalert]
[,<название_статуса>];
Пример:
alert tcp any any -> any 143 (msg:?IMAP LIST?; content:?LIST?; \
flowbits:isset, logged_in;)
> ITYPE
Тип ICMP пакета.
Синтаксис:
itype:[<|>]<целое_значение>[<>
<целое_значение>];
Пример:
itype:>30;
> ICODE
Код в ICMP пакете.
Синтаксис:
icode:[<|>]<целое_значение>[<>
<целое_значение>];
Пример:
icode:>30;
> ICMP_ID
Поле ECHO ID в ICMP пакете.
Синтаксис:
icmp_id:<целое_значение>;
Пример:
icmp_id:0;
> ICMP_SEQ
Номер SEQ в ICMP пакете.
Синтаксис:
icmp_seq:<целое_значение>;
Пример:
icmp_seq:0;
> NOCASE
Игнорировать регистр в пакете.
Синтаксис:
nocase;
Пример:
alert tcp any any -> any 21 (msg:"FTP ROOT"; content:"USER root"; nocase;)
> RPC
Параметры вызовов RPC (удаленный вызов процедур).
Синтаксис:
rpc:<идентификатор_приложения>, [<версия>|*],
[<идентификатор_процедуры>|*]>;
Пример:
alert tcp any any -> any 111 (rpc: 100000,*,3;);
POST-DETECTION (Задачи после обнаружения нужной информации)
> LOGTO
С помощью этой опции можно указать файл, куда запишется информация о пакете.
Примечание: logto не создает бинарные файлы.
Синтаксис:
logto:"filename";
> REACT
Этот параметр специально создавался для блокировки web-сайтов. С помощью него
можно запретить доступ к указанному web-серверу. При этом можно передать
сообщение, которое получит web-браузер при попытке посетить блокированный web
сайт.
Базовые модификаторы:
block - закрыть соединение и передать сообщение о блокировке
warn - передать предупреждение (опция будет скоро доступна)
Дополнительные модификаторы:
msg - использовать данный текст в сообщении
proxy: <порт> - использовать порт proxy для передачи сообщения браузеру
(опция будет скоро доступна)
Примечание: опция react должна находиться в конце правила.
Синтаксис:
react: <базовый_модификатор[, дополнительный_идентификатор]>;
Пример:
alert tcp any any <> 192.168.1.0/24 80 (content: "bad.htm"; \
msg: "Not for children!"; react: block, msg;)
> SESSION
Довольно интересный параметр, с помощью которого можно анализировать TCP
сессии. То есть можно просмотреть введенные пользовательские данные, к
примеру, ftp, telnet, rlogin, web сессии и т.п. трафик. Это очень полезная
возможность, которая используется в Snort довольно редко.
Синтаксис:
session: [printable|all];
Пример правила для ftp сессии:
log tcp any any <> any 21 (session:printable;)
> RESP
Данный параметр используется для "обратной связи" с тем компьютером, с
которого идут подозрительные пакеты, к примеру если установлено TCP
соединение, можно отослать пакет, позволяющий его закрыть.
Список опций для разных сообщений:
rst_snd - отсылка сообщения TCP-RST отправляемому сокету.
rst_rcv - отсылка сообщения TCP-RST принимающему сокету.
rst_all - отсылка сообщения TCP-RST и отправляющему и принимающему
сокетам.
icmp_net - отсылка сообщения ICMP_NET_UNREACH отправителю.
icmp_host - отсылка сообщения ICMP_HOST_UNREACH отправителю.
icmp_port - отсылка сообщения ICMP_PORT_UNREACH отправителю.
icmp_all - отсылка всех вышеперечисленных ICMP сообщений.
Пример:
alert tcp any any -> any 1524 (flags:S; resp:rst_all;)
> TAG
Параметр tag позволяет передавать системе журналирования указанное количество
пакетов после того, как придет подозрительный пакет, совпадающий с условиями
правила. То есть все пакеты после интересующего, включая и исходящие, будут
помечаться и записываться, но не будет журналироваться тот пакет, который
совпал с условиями правила.
Синтаксис:
tag: <тип>, <длина>, <что_помечать>, [direction]
Подробнее:
тип - Тут возможны два значения session и host. Session - указывает
на запись сессии с интересующими нас пакетами, а host
указывает на запись пакетов, пришедших с хоста, приславшего
пакет. Если используется host, то учитывается направление.
длина - В этом параметре содержится количество единиц, указанных в
параметре "что_помечать", которые нужно передать процедуре
журналирования.
что_помечать - Здесь так же существует два значения: packets и seconds.
Packets - для журналирования определенного количества
пакетов (количество в "длина"), seconds - время, которое
нужно для журналирования трафика.
Пример:
alert tcp any any -> any 23 (flags:s,12; tag:session,10,seconds;)
Логические операции
В правилах есть возможность добавлять логические операторы "OR" и "AND".
Работать с ними легко, принимая во внимание то, что для того, чтобы сработало
правило, все параметры в правиле должны совпасть. Эти параметры можно
объединить с помощью "AND" и использовать логическое или ("OR"), чтобы выбрать
совпадения.
Заключение
Конечно, IDS Snort не дает стопроцентной уверенности в том, что будут замечены
и отображены все подозрительные события, но если разобраться, то на
сегодняшний день ни одна система не обладает такими свойствами. Snort
теоретически не сложно обойти многими способами. К примеру, примем во внимание
применение эксплоитов. Snort может обнаружить подозрительный код, анализируя
NOP, но этот посылаемый код можно без особых трудностей модернизировать, что
сделает зловредные пакеты недетектируемыми для IDS. Должен заметить, что Snort
может определять атаки под прикрытием (шум). Это когда злоумышленник отсылает
множество подозрительных пакетов на целевую систему и во время этого шума
проводит атаку.
В любом случае проект развивается стремительно и за то время, пока я писал
данную статью, выходили новые версии со значительными изменениями, а это
влекло появление новых опций, препроцессоров, ключей. Хочу поблагодарить всех
разработчиков, принимавших участие в создании IDS Snort, они отлично
поработали.
Благодарности
Во время написания данной статьи использовалась англоязычная литература по
той причине, что материала по IDS Snort на русском языке очень мало, поэтому
иногда возникали вопросы, с которыми я успешно справлялся благодаря мэмберам
команды и просто друзьям - спасибо RST/GHC, отдельное спасибо 1dt.w0lf'у
и Edisan'у. Также хотелось бы поблагодарить еще и Unl0ck Research Team [UKT].
Используемый материал
При написании статьи использовались следующие источники:
http://www.snort.org/docs/snort_htmanuals/htmanual_2.4http://www.snort.org/docs/faq/1Q05/
Последнюю версию этой статьи вы можете найти на сайте: http://rst.void.ru
или же на моем homepage: http://ufo.gnu.kz
При запуске в тест-режиме выдает ошибку ERROR: /etc/snort/snort.conf(326) => Invalid keyword '}' for server configuration. Fatal Error, Quitting.. в чем проблема и как это можно решить?
