МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Государственное образовательное учреждение высшего профессионального образования
«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ»
КУРСОВАЯ РАБОТА (ПРОЕКТ)
ЗАЩИЩЕНА С ОЦЕНКОЙ отлично
РУКОВОДИТЕЛЬ
доц., к. т.н., доц. | ||||
должность, уч. степень, звание | подпись, дата | инициалы, фамилия |
||
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА К КУРСОВОЙ РАБОТЕ (ПРОЕКТУ) |
||||
Практика использования IDS SNORT |
||||
по дисциплине: инженерно-техническая защита информации |
||||
РАБОТУ ВЫПОЛНИЛ(А)
СТУДЕНТ(КА) ГР. | |||||
подпись, дата | инициалы, фамилия |
Санкт-Петербург 2011
1.. Что такое Snort?. 2
2. Режим сниффера : 2
3. Режим журналирования пакетов . 6
4. Режим обнаружения сетевых вторжений. 6
1. Что такое Snort?
Snort – облегченная система обнаружения вторжения. Snort обычно называют “облегченным” NIDS /расшифровать, перевести/, - потому что это он разработан прежде всего для маленьких сетей. Программа может исполнять анализ протокола и может использоваться, чтобы обнаружить разнообразные нападения.
Snort использует "правила" (указанные в файлах "правила"), чтобы знать какой трафик пропустить а какой задержать. Инструмент гибок, позволяя записывать новые правила и соблюдать их.
Snort может работать в 3 основных режимах:
· Режим сниффера: позволяет просто ловить пакеты из сети и отображать их на экране(как правило консоли)
· Режим журналирования пакетов: позволяет сохранять пакеты на жесткий диск
· Режим системы обнаружения вторжений (NIDS) - наиболее сложная и настраиваемая конфигурация, которая позволяет анализировать сетевой трафик на основе определяемых пользователем набора правил.
2. Режим сниффера :
В режиме анализа пакетов, Snort просто читает пакеты, приходящие из сети, и выводит их на экран. Для вывода заголовков пакетовов TCP/IP необходимо выполнить:
snort –v
Эта команда выводит заголовки IP - и TCP/UDP/ICMP-пакетов. Можно увидеть откуда отсылались пакеты, куда, во сколько /адресов?/. На рисунке /рисунки надо нумеровать, чтобы ссылаться. Ссылки нет – значит рисунок не нужен/ видно, что исходящих адреса два./откуда видно? Расшифруйте форматы записей на рисунке или хоть по номеру строки сошлитесь/
Чтобы понять, что это за адреса - достаточно выполнить команду
systeminfo
Из снимка /уже - снимки. а не рисунки? В пределах документа должно соблюдаться единообразие! Или это – нечто другое?/ становится понятно, что это за исходящие адреса. /ну и перечислите – или по крайней мере укажите. что их номера приведены в квадратных скобках/
Для того чтобы увидеть данные, содержащиеся в пакетах, необходимо ввести:
snort - vd
https://pandia.ru/text/78/320/images/image004_112.jpg" alt="подробный_вывод.jpg" width="589" height="338">
Ключи могут быть заданы в любой форме, например: "snort - vde", "snort - d - ev" и "snort - e - v -d".
Snort будет собирать информацию до тех пор, пока его не прервать. Для завершения захвата пакетов необходимо нажать Ctrl-C. После нажатия Ctrl-C будет выведен отчет о захваченных пакетах. Ниже показан отчет, полученный после работы Snort в течение приблизительно минуты.
Из снимка видно, что большинство проанализированных пакетов являются пакетами TCP/IP. Также были захвачены и UDP пакеты.
3. Режим журналирования пакетов
Режим журналирования пакетов позволяет записывать поток информации на диск. Это полезно при проведении анализа за определенный интервал времени или проверки изменений в настройках и политике безопасности.
Необходимо создать и указать каталог для логов, а Snort автоматически перейдет в режим журналирования пакетов.
Пример: создаем каталог logs и запускаем:
snort - dev - l../log
В результате операции /куда, где его искать, как указать желательное место?/ запишется файл snort. log.. Цифры в конце новых имен файлов являются временными метками, что позволяет избегать конфликтов при создании файлов. /желателен пример лог-файла/
4. Режим обнаружения сетевых вторжений
Третий режим Snort, это режим обнаружения сетевых вторжений (Network Intrusion Detection, NIDS).
В своей базовой форме правило Snort /где они хранятся?/ имеет две части: заголовок и параметры. Ниже представлен пример правила.
alert tcp any any -> any any (content: "www. "; msg: "Someone is visiting youtube now"; sid:1000002; rev:1)
Модель структуры правил можно представить /она жестко задана или может изменяться? то, что элементы в квадратных скобках – необязательны, надеемся. известно. Но есть ли между ними спецразделители?/ по следующей схеме:
<действие_правила> <протокол> <порт> <оператор_направления>
<порт> ([мета_данные] [даные_о_содержимом_пакета]
[данные_в_заголовке] [действие_после_обнаружения])
Действия правил делятся на следующие категории:
1. alert - Создать предупреждение, используя выбранный метод, и передать информацию системе журналирования.
2. log - Использовать систему журналирования для записи информации о пакете.
3. pass - Игнорировать пакет.
4. activate - Использовать другое динамическое правило.
5. dynamic - После того, как выполнится активное правило, задействуется правило с процедурой журналирования.
6. drop - Отбросить пакет, используя программный брандмэуер, и передать информацию системе журналирования
7. sdrop - Отбросить пакет при помощи программного брандмэуера и не использовать систему журналирования.
8. reject - Используя брандмэуер, отбросить пакет в том случае, если протокол TCP, или же записать в файл журнала сообщение: ICMP порт недоступен, если пакет приходит по протоколу UDP
Второй частью правила Snort служат опции, задающие дополнительные детали выявляемого трафика. Можно искать по набору полей в заголовке TCP/ или по полезной нагрузке пакета. За каждой опцией должны следовать кавычки и разыскиваемое значение. Можно добавить несколько опций, разделяя их с помощью точки с запятой. Ниже приведены допустимые опции.
sid – уникальная метка, идентифицирующая правило. Эта опция должна использоваться с опцией rev .
<100 зарезервировано для дальнейшего использования
100-999,999 уже зарезервированные правила
>=1,000,000 правила, задаваемые пользователем
rev - значение версии правила. С помощью rev интерпретатор правил
Snort определяет версию написанного правила.
Запуск Snort в режиме IDS можно осуществить командой:
snort - c "D:\Program Files\Snort\etc\snort. conf" - l " D:\Program Files\Snort\log" - A console - i 1
ключ –с означает, что включен режим IDS
ключ – l включает режим записи на жесткий диск с указанием пути к файлу
ключ – A показывает что все предупрежления(alerts) будут дублтроваться выводом на консоль
ключ – i указывает на порядковый номер(index) интересующего нас интерфейса
чтобы узнать поддерживаемые интерфейсы необходимо выполнить команду:
snort – W
Содержимое файла snort. conf
Содержимое файла *****les:
В файл snort. conf можно подсоединять правила использую ключевое слово include .
Результат выполнения команды:
Видно, что Snort зафиксировал попытку попасть на “опасный” сайт.
Нет информации об источнике, откуда был взят дистрибутив, об ОС, на которой велось исследование
В целом работа весьма интересна. /
Безопасность превыше всего. Лучше спать спокойно, чем проводить выходные за консолью, восстанавливая убитый сервак.
История о том, как я ставил SNORT + OINKMASTER + BASE
1. Установка SNORT
Идем в /usr/ports/security/snort/. Собираем SNORT (с опциями DYNAMIC и MYSQL):
# make install clean
Прописываем его в rc.conf:
Snort_enable="YES"
Начиная где-то с версии 2.4, в комплекте со snort НЕ предоставляются правила. По-этому, их надо скачивать самостоятельно. Существует два способа. Первый — скачивать руками, второй автоматизировать процесс через OINKMASTER. Так или иначе, надо будет зарегистрироваться на сайте www.snort.org, а для OINKMASTER надо еще сгенерировать OINK CODE в своем аккаунте на snort.org.
2. Установка и настройка OINKMASTER
Идем в /usr/ports/security/oinkmaster и ставим порт:
# make install clean
После установки, в директории /usr/local/etc появляется файл oinkmaster.conf.sample. Его надо переименовать в oinkmaster.conf и поправить в нем следующие строчки:
# Example for Snort-current ("current" means cvs snapshots). url = http://www.snort.org/pub-bin/oinkmaster.cgi/oinkcode/snortrules-snapshot-CURRENT.tar.gz tmpdir = /tmp/
Вместо oinkcode надо вставить свой код, который мы получили после регистрации на сайте snort.org.
Чтобы теперь получить последние правила, надо выполнить команду:
# oinkmaster -o /usr/local/etc/snort/rules
Правила скачаются в папку /usr/local/etc/snort/rules. Убедитесь, что папка существует. По идеи, она должна автоматически создаться после установки SNORT.
3. Настройка SNORT
Все файлы настроек хранятся в папке /usr/local/etc/snort
Первым делом редактируем файл snort.conf, правим в нем следующие строчки:
# Наша подсеть var HOME_NET 192.168.0.0/24 # Порты, на которых висит апач portvar HTTP_PORTS
// Интересно, надо ли сюда вписывать порт 443 # Где храить логи output database: log, mysql, user=snort password=test dbname=snort host=localhost
Чтобы теперь логи хранились в базе данных, надо создать саму базу данных:
# mysql -u root -p Password: вводим пароль mysql> create database snort; mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to ; mysql> SET PASSWORD FOR "snort"@"localhost"=PASSWORD("password"); mysql> exit
Теперь ее надо заполнить. Файл create_mysql я взял в папке /usr/ports/security/snort/work/snort-2.8.1/schemas. Если его там нет, то просто соберите порт (make).
# mysql -u root -p ~/create_mysql snort
Пробуем запустить snort:
# /usr/local/etc/rc.d/snort start
Смотрит /var/log/messages. Если все запустилось без ошибок, то хорошо)))
4. Установка и настройка BASE
Сначала надо поставить pear. Идем в /usr/ports/devel/pear
# make install clean
Теперь надо еще несколько пакетов к pear:
# pear install Image_Color # pear install Log # pear install Numbers_Roman # pear install Numbers_Words-alpha # pear install Image_Canvas-alpha # pear install Image_Graph-alpha
Теперь надо поставить adodb. Я ставил версию 5.02а.
# cd /usr/ports/databases/adodb5 # make install clean
BASE в портах я не нашел. Может, плохо искал. Его можно скачать с сайта www.secureideas.sf.net
Распаковываем его в любую папку на веб сервере. В моем случае — это /usr/local/www/base. В этой папке переименовываем файл base_conf.php.dist в base_conf.php. Редактируем в файле следующие строки:
# Включаем русский язык $BASE_Language = "russian"; # Если установить 0, то не будет авторизации при доступе к BASE. ВНИМАНИЕ! Чтобы инициализировать BASE, надо сначала установить значение 0! $Use_Auth_System = 1; # Если, например, BASE доступен через http://localhost/base, то заносим значение /base. # Я использую виртуальный домен www.base.server.ru, по этому ничего не вношу. $BASE_urlpath = ""; # Указываем путь до adodb $DBlib_path = "/usr/local/share/adodb"; # Параметры для подключения к базе данных $alert_dbname = "snort"; $alert_host = "localhost"; $alert_port = ""; $alert_user = "snort"; $alert_password = "mypassword";
Все. Сохраняем файл и закрываем его. Открываем BASE через браузер. Он скажет, что у нас не оптимизирована база данных и предложит ее оптимизировать. Соглашайтесь. После этого установка BASE завершена.
1. Что такое IDS.
На сегодняшний день, когда сайтов с описаниями взломов, а также статей, эксплоитов, программ на эту же тему, появилось очень много, намного участились попытки взлома серверов. Ведь любой юзер, вообразивший себя хакером, может испробовать на вас свежескачаный эксплоит и получить контроль над вашим сервером. На самом деле все не так легко, но все же...
Для того, чтобы узнать про атаки, ну или просто быть в курсе всех событий, происходящих на сервере, многие админы ежедневно просматривают журналы регистрации – логи. Но когда лог файл, например веб-сервера Apache, за день вырастает на 10 Mb, то приходиться автоматизировать процесс контроля безопасности сервера. Одним из решений являются IDS – системы обнаружения вторжения, эффективность которых за последние несколько лет значительно возросла, и теперь они являются неотъемлемой частью любой сетевой защиты.
Из многих разновидностей IDS (Intrusion Detection System), можно выделить две: основанные на анализе протокола (выявляющие пакеты несоответствующие стандартам), и основанные на анализе сигнатур (в пакетах ищется сигнатура атаки – строка (образец) указывающая на принадлежность данного пакета к вредному трафику. Такие IDS называют NIDS (Network Intrusion Detection System). В общем принцип действия NIDS можно описать так: весь трафик анализируется на наличие пакетов содержащих вредоносные данные, и если такой пакет находиться, то выполняются различные сигнализирующие действия (выводится сообщение на консоль, посылается почта, пишется в лог, отправляется Winpopup сообщение и.т.д.). Оба типа IDS имеют свои достоинства и недостатки, например анализ протоколов работает более медленно из-за преобразования пакета в вид доступный для анализа. Зато ложных тревог намного меньше, так как регистрируются действительно реальные отклонения от стандартов. IDS на основе анализа сигнатур более быстры, и к тому же легко настраиваются и обновляются (увидел новую уязвимость, добавил ее в базу, и твой IDS ее обнаружит). Но лучше все таки использовать IDS на основе двух методов анализа, это даст действительно прекрасный результат.
2. Краткий обзор IDS
На данный момент существует огромное количество IDS, каждая из которых обладает своими качествами и недостатками. Приведу краткое описание некоторых из них (данные сведения о программах взяты с сайта www.opennet.ru , там же вы можете и найти все эти IDS):
PortSentry
Программа позволяющая в реальном режиме времени определить и блокировать попытки сканирования UDP и TCP портов сервера. Определяются также скрытые попытки сканирования портов (SYN/half-open, FIN, NULL, X-MAS, oddball).
Система анализа и слежения (ведения логов) за проходящими пакетами, распознаются такие атаки как "buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts". Присутствует возможность real-time извещения администратора при обнаружении атаки
Nidsbench
Система тестирования сети на предмет типовых уязвимостей и выяснения реакции установленной системы обнаружения попыток несанкционированного доступа. Присутствует неплохая подборка документации по NIDS.
Монитор TCP/IP трафика, способен вести логи о проходящем трафике, обнаруживать сканирования портов, флуд и некоторые виды атак.
Библиотека для построения NIDS систем, эмулирует TCP/IP стэк Linux 2.0.x, что позволяет не только перехватывать пакеты (хаотично идущий набор пакетов), как делает большинство снифферов (например, libpcap, tcpdump), но и отслеживать отдельные сессии (например, перехватывать SMTP трафик и разделять каждую SMTP сессию) с учетом дефрагментации и сборки TCP кусков пакетов. Работает под Linux, *BSD и Solaris.
Программа позволяет отследить и поместить в лог файл все данные проходящие через последовательный порт.
Это далеко не все IDS, и даже не самые известные, но эти легко найти.
Из всех этих программ, Snort - наиболее понравившаяся мне. Почему? Вот ее плюсы: два режима анализа , по сигнатуре и анализ протоколов, легкая установка и настройка программы, небольшой размер и системные требования, определение огромного количества атак.
3. Установка и настройка Snort
Для начала скачаем Snort с сайта www.snort.org .Вот прямая ссылка на последнюю версию на данный момент http://www.snort.org/dl/binaries/linux/snort-1.9.1-1snort.i386.rpm . Также существуют различные модификации Snort, например с поддержкой MySQL, postgresql, snmp, все это вы можете скачать с этого же сайта, а наш вариант программы я выбрал, как самый легкий в установке.
Установка достаточна проста:
rpm –i snort-1.9.1-1snort.i386.rpm
После этого все необходимые файлы будут скопированы в систему.
Теперь необходимо настроить программу под себя, чем мы сейчас и займемся... Перейдем в директорию /etc/snort , здесь вы можете найти базы сигнатур (точнее их можно назвать правилами, по которым Snort определяет вредный трафик) и несколько файлов конфигурации, нам нужен snort.conf. Тут настраиваем переменные переменные типа HOME_NET, EXTERNAL_NET и другие... Разобраться будет нетяжело, так как каждая опция сопровождается довольно внятными комментариями, хоть и на английском. В самом конце конфигурационного файла идут подключаемые сигнатуры, ненужные можно закомментировать, для повышения производительности.
Приведу пример своего конфига:
# Шаг #1: Установка переменных касающихся сети
# Измените IP, на адреса вашей локальной сети
# Можно указать несколько диапазонов, разделяя их запятыми
var HOME_NET 192.168.168.0/24
var EXTERNAL_NET !$HOME_NET
var DNS_SERVERS $HOME_NET
var SMTP_SERVERS $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var TELNET_SERVERS $HOME_NET
var ORACLE_PORTS 1521
var HTTP_PORTS 80
var SHELLCODE_PORTS !80
# Путь к сигнатурам
var RULE_PATH /etc/snort
#Подключаем необходимые файлы содержащие классификацию обнаруженной атаки
и ссылки на
# багтраки
Include classification.config
include reference.config
###################################################
# Шаг #2: Настройка механизма обнаружения атак
Preprocessor frag2
preprocessor stream4: detect_scans, disable_evasion_alerts
preprocessor stream4_reassemble
preprocessor http_decode: 80 unicode iis_alt_unicode double_encode iis_flip_slash
full_whitespace
preprocessor rpc_decode: 111 32771
preprocessor portscan: $HOME_NET 4 3 portscan.log
# Мне пришлось добавить эту опцию, из за некоторых специфических программ,
используемых в моей
# сети, из за которых часто случались ложные срабатывания
preprocessor portscan-ignorehosts: 192.168.168.0/24
preprocessor arpspoof
preprocessor conversation: allowed_ip_protocols all, timeout 60, max_conversations
32000
preprocessor portscan2: scanners_max 3200, targets_max 5000, target_limit
5, port_limit 20, timeout 60
####################################################################
# Шаг #3: Указываем какие сигнатуры нам нужны
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/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/dns.rules
include $RULE_PATH/web-cgi.rules
# Следующую опцию я оставил для статистики – мой сервер регулярно сканят на
предмет IIS багов,
# Точнее не мой сервер а диапазон адресов, в котрый попадаю и я:)
include $RULE_PATH/web-iis.rules
include $RULE_PATH/web-client.rules
include $RULE_PATH/web-php.rules
include $RULE_PATH/sql.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/mysql.rules
Include $RULE_PATH/pop3.rules
include $RULE_PATH/pop2.rules
include $RULE_PATH/other-ids.rules
include $RULE_PATH/web-attacks.rules
include $RULE_PATH/backdoor.rules
include $RULE_PATH/shellcode.rules
Теперь все готово для для запуска Snort. Пропишите его в inittab и он будет запускаться вместе с системой.
4. Добавление собственных сигнатур
Snort – это очень гибкий и удобный в настоке IDS. Одно из его качеств позволяет нам самим добавлять сигнатуры атак (или как я уже говорил, это больше похоже на правила). Такие правила у нас лежат в файлах *.rules. Синтаксис правил довольно прост:
ACTION PROTO IP_ADDR1 PORT1 DIRECTION IP_ADDR2 PORT2 [ (OPTIONS) ]
Рассмотрим поля правил более детально:
Поле Action имеет три основных директивы, которые определяют действия, при обнаружении сетевого пакета, соответствующего некоторому правилу: pass, log и alert.
pass - игнорировать пакет
log - пакет должен быть передан процедуре журналирования, для записи в файл журнала
alert генерирует уведомление об обнаружении пакета, удовлетворяющего правилу
Протокол пакета, может иметь значения tcp,udp,icmp
Как это понятно из названия опции, это поле означает IP адрес. any позволяет задать все возможные адреса. Символ! инвертирует условие, т.е. !192.168.168.0/24 означает любой не принадлежащий подсети 192.168.168.0/24. Можно перечислять несколько IP адресов через запятую
Кроме единственного номера порта можно задать диапазон портов через двоеточие, например, 6000:6010, символ ! инвертирует условие, а any обозначает все порты
DIRECTION
Определяет направление движения пакета:
-> (одностороннее) - правило будет применяться только к пакетам, идущим с IP_ADDR1 на IP_ADDR2;
(двустороннее) - направление движения пакета роли не играет
Заключаемые в круглые скобки параметры являются необязательной частью правила, но они определяют текст уведомляющего об угрозе сообщения, задают дополнительные действия при срабатывании правила и дополнительные условия на соответствие анализируемых пакетов данному правилу. Параметры отделяются друг от друга точкой с запятой, а ключевое слово параметра отделяется от его аргумента двоеточием.
Параметры, задающие дополнительные условия на соответствие правилу:
ttl - задает значение поля TTL в заголовке IP-пакета;
tos - задает значение поля TOS в заголовке IP-пакета;
id - задает значение поля номера фрагмента в заголовке IP-пакета;
ipopts - задает значение поля параметров IP-пакета;
fragbits - задает биты фрагментации IP-пакета;
dsize - задает условия на размер IP-пакета;
flags - задает условия на наличие или отсутствие определенных TCP-флагов;
seq - задает номер сегмента TCP-пакета в последовательности;
ack - задает значение поля подтверждения в TCP-пакете;
itype - задает значение поля типа ICMP-пакета;
icode - задает значение поля кода ICMP-пакета;
icmp_id - задает значение поля ICMP ECHO ID в ICMP-пакете;
icmp_seq - задает номер ICMP ECHO пакета в последовательности;
content - задает искомый шаблон в содержимом пакета, а не в заголовке (шаблон можно задавать как в текстовом виде, так и в шестнадцатеричном);
content-list - этот параметр аналогичен параметру content за исключением того, что список искомых шаблонов берется из заданного файла;
offset - работает совместно с опцией content для определения смещения в пакете, с которого будет производиться анализ содержимого;
depth - аналогичен параметру offset и определяет положение в пакете, до которого будет производиться анализ содержимого;
nocase - отключает чувствительность к регистру при анализе содержимого пакета;
rpc - этот параметр позволяет более точно задать характеристики программных или процедурных вызовов RPC-сервисов.
Как можно заметить, перечисленные параметры позволяют создавать правила для перехвата практически любых пакетов, которые как-то могут угрожать безопасности. А если учесть, что Snort может перехватывать пакеты на канальном уровне, то его применение особенно интересно на хостах, защищенных файрволлом, так как отбрасываемые файрволлом пакеты все равно будут находиться в поле зрения Snort.
Параметры, значения которых имеют смысл при соответствии анализируемого пакета всем условиям:
msg - содержит текст сообщения;
logto - задает альтернативный файл для записи в него содержимого пакета;
session - этот параметр позволяет включить очень интересную возможность Snort - извлечение пользовательских данных из TCP-сессии, например, для последующего анализа того, какие команды вводил пользователь во время telnet-сессии;
resp - если пакет соответствует правилу, то Snort выполнит одно из указанных действий - например, закроет соединение, отправив TCP-RST-пакет одному из хостов.
react - блокирует заданные в правиле web-сайты, закрывая соединение с ними и/или отправляя заданное сообщение браузеру, с которого была предпринята попытка зайти на сайт.
Вот пара примеров построения собственных правил:
В случае обнаружения запроса к Napster-серверу соединение принудительно закрывается. Как видно, при помощи Snort организовать фильтрацию нежелательного трафика можно более эффективно, чем просто закрывая соответствующие порты на файрволе, поскольку имеется возможность ввести дополнительное условие на содержимое пакетов.5. Тестирование Snort
Для тестирования работоспособности Snort, возьмем простейший пример. В коммандной строке наберите ping –s 65507 . Теперь идем в /var/log/snort, здесь по умолчанию хранятся логи. Открываем файл alert и видим такие строки:
[**] ICMP Large ICMP Packet [**]
01/06-07:37:37.119752 192.168.168.99 -> 192.168.168.9
ICMP TTL:255 TOS:0x0 ID:18479 IpLen:20 DgmLen:63028
Type:0 Code:0 ID:512 Seq:19456 ECHO REPLY
Первая строка говорит нам, какое действие вызвало тревогу, в данном случае - слишком большой ICMP пакет. Вторая строка показывает класс атаки и ее приоритет (эта информация определяется из файла classification.config). Третья строка содержит время атаки, а также IP адреса хоста пославшего пакет, и хоста которому пакет был предназначен. Далее идут остальные поля пакета, как например TTL, TOS – по которому, кстати, можно определить OS нападающего, и другие...
6. Заключение
Из всего, сказанного выше, как мне кажется, можно сделать вывод о чрезвычайной полезности Snort. В любом случае, применение этой программы сделает жизнь хакеров немного сложнее. А разве не эту цель преследует любой системный администратор?
Данная статья не претендует на полное руководство по Snort, но надеюсь она поможет вам разобраться в его установке, настойке и работе. Много мыслей взяты из различных документов, в основном английских, встреченных мной на различных security сайтах, но в основном это результат моего опыта работы с Snort.
Ежедневно по корпоративным сетям передаются миллиарды пакетов данных. Некоторые из них опасны; авторы таких пакетов приняли специальные меры, чтобы обойти брандмауэры и пробиться через линии обороны по периметру сетей, нарушая работу всех встреченных на пути систем. Разрушительное действие таких проведенных с использованием пакетов атак, как Code Red, Nimda, SQL Slammer и MSBlaster, хорошо известно. Все эти вредоносные программы используют в своих целях доверенные протоколы (например, HTTP) или сетевой трафик систем Microsoft. Такие протоколы нельзя просто взять и блокировать, поэтому администраторы обычно стараются как можно быстрее зафиксировать опасный трафик с помощью систем обнаружения несанкционированного доступа, Network Intrusion Detection System (NIDS), чтобы вовремя среагировать на угрозу.
В продаже имеется несколько NIDS, разнообразных по возможностям и стоимости. В целом все они работают успешно. Все коммерческие пакеты, с которыми мне пришлось столкнуться, произвели отличное впечатление. Но что делать организациям со скромным бюджетом, если обнаружение несанкционированного доступа не относится к числу приоритетных задач? На такой случай существует Snort - мощный бесплатный пакет NIDS. В отличие от многих пакетов с открытым кодом, он совместим с Windows.
Знакомство с Snort
Первый разработчик Snort Мартин Реш предоставил программу открытому сообществу на условиях лицензии GNU General Public License (GPL). История этого пакета началась в 1998 г., и с тех пор он не раз доказал свою надежность. Благодаря вкладу членов открытого сообщества и сетевых администраторов во всем мире Snort превратился в очень мощный продукт. Текущая версия обеспечивает анализ сетевого трафика в реальном времени и регистрацию IP-трафика со скоростями Fast Ethernet и Gigabit Ethernet.
Майкл Дэвис перенес Snort 1.7 на платформу Win32, сделав его доступным для сообщества Windows. Затем Крис Рейд взял на себя задачу компиляции новых версий Snort в готовые исполняемые файлы, которые можно без труда развернуть в среде Windows.
Администраторы, незнакомые с NIDS, могут считать инструмент особой разновидностью сетевого анализатора. NIDS проверяет каждый пакет, проходящий через интерфейс, в поисках известных последовательностей в информационном наполнении, где обычно скрыт вредоносный программный код. С помощью Snort можно выполнять операции поиска и сопоставления над каждым пакетом, проходящим через сеть организации, и обнаруживать множество типов атак и нелегитимного трафика в реальном времени.
Требования Snort
Для работы Snort необходим компьютер Windows, оснащенный по крайней мере одним сетевым адаптером. Лучше иметь два сетевых адаптера, один из которых подключен к контролируемой сети, а другой - к производственной сети; последний пересылает отчеты. Snort совместим не только с Windows 2000 Server и более поздними версиями, но и с Windows XP Professional Edition, XP Home Edition и Windows 2000 Professional. Лицензии для сервера не требуется. Ежедневно я подключаю ноутбук XP Pro ко многим сетям клиентов и обычно запускаю Snort в качестве службы. Таким образом, программа работает в фоновом режиме, обнаруживая любые атаки на мою систему, исходящие из данной клиентской сети. Я использую Snort как переносной сенсор - программа играет роль NIDS для любого порта, к которому подключается ноутбук.
В небольших сетях развернуть Snort можно на сервере начального уровня. Для обнаружения попыток несанкционированного доступа выделенная машина большой мощности не нужна. Например, мне приходилось слышать об узлах Snort на платформе FreeBSD с процессорами на 1 ГГц и оперативной памятью объемом 1 Гбайт, которые успешно обслуживали сети с 15 000 пользователей и несколькими соединениями T-3 каналов WAN. Благодаря эффективности исходного текста Snort для работы программы очень мощная машина не требуется.
В каком месте сети лучше расположить NIDS? Первая мысль - поместить устройство перед брандмауэром. В этом месте NIDS обнаружит больше всего нападений, но и число ложных срабатываний будет наиболее велико, и администратор получит массу бесполезных предупреждений об опасности. Не следует беспокоиться об угрозах, остановленных брандмауэром, гораздо важнее обнаружить опасные программы, проникшие за него. Поэтому в любом случае лучше разместить Snort позади брандмауэра.
Однако если пользователи подключаются к сети через соединение VPN (по Internet или беспроводной линии связи), имеет смысл разместить NIDS еще дальше за брандмауэром, например за VPN-сервером или концентратором, где пакеты расшифровываются на выходе из туннеля VPN. В противном случае NIDS не сможет противостоять вредоносным программам, встроенным в трафик VPN, так как анализируемые пакеты будут зашифрованы. То же относится и к зашифрованному SMTP-трафику, зашифрованным.zip-файлам, вложенным в сообщения электронной почты, и зашифрованным данным других типов.
В идеале NIDS следует разместить достаточно далеко за любыми компонентами, шифрующими трафик, и довольно близко к периметру сети для анализа трафика в максимальном количестве сегментов и подсетей. В коммутируемой сетевой среде коммутатору, как правило, требуется диагностический порт, в котором собираются все пакеты, проходящие через сеть. В результате NIDS получает удобный доступ ко всему сетевому трафику.
Теперь, познакомившись с Snort и зная требования к его размещению, можно установить и протестировать NIDS. Более подробную информацию о Snort можно получить из документов, ссылки на которые приведены во врезке «Ресурсы в Web». Данный процесс состоит из семи этапов:
- Установка WinPcap
- Установка Snort
- Тестирование Snort
- Настройка Snort
- Задание правил
- Настройка предупреждений и журналов
- Запуск в качестве службы
Этап 1. Установка WinPcap
В сущности, Snort представляет собой сетевой анализатор, работающий в режиме приема всех пакетов (promiscuous-mode), поэтому ему необходима поддержка на уровне драйверов. Эту поддержку обеспечивает WinPcap. Лорис Диджиоанни создал WinPcap, перенеся в среду Windows широко распространенный среди пользователей Unix драйвер перехвата пакетов libpcap. В состав WinPcap входят фильтр пакетов на уровне ядра, низкоуровневая DLL (packet.dll) и высокоуровневая системно-независимая библиотека (wpcap.dll, на базе libpcap 0.6.2).
WinPcap можно загрузить по адресу http://winpcap.polito.it . Драйвер совместим с Windows Server 2003, XP, Windows 2000, Windows NT, Windows Me и Windows 9x. WinPcap также поддерживает открытый анализатор пакетов Ethereal, который можно получить по адресу . С помощью Ethereal можно убедиться в корректности установки Snort.
Загрузив из сети установочный файл WinPcap, достаточно пройти по нескольким экранам процедуры инсталляции. Самых больших усилий со стороны пользователя требует экран, на котором необходимо выразить согласие с условиями лицензии.
Этап 2. Установка Snort
Следующий шаг - установка Snort. Новейшую версию можно найти на Web-узлах CodeCraft Consultants (http://www.codecraftconsultants.com/snort.aspx ) или Snort.org (http://www.snort.org ). Я рекомендую загрузить Snort из CodeCraft Consultants, так как с этого сайта можно получить саморазворачивающийся исполняемый файл. Программа даже проводит пользователя по элементарным операциям установки Snort на компьютере. При подготовке данной статьи использовалась последняя версия Snort 2.1.1, сборка 18. С тех пор были выпущены обновленные версии.
При запуске программы установки в первом диалоговом окне необходимо выбрать режим настройки базы данных для хранения результатов. Если используется MySQL или ODBC-совместимая база данных, можно согласиться на режим, выбираемый по умолчанию (экран 1). Но если предстоит хранить протоколы в базе данных Microsoft SQL Server или Oracle, то необходимо выбрать соответствующий режим и убедиться, что на машине имеется нужная клиентская программа. При подготовке данной статьи использовался режим по умолчанию.
На следующем шаге следует определить компоненты Snort, которые требуется установить. Стандартный набор (экран 2) вполне приемлем, поэтому я рекомендую принять его и щелкнуть на кнопке Next. В диалоговом окне Choose Install Location необходимо указать каталог, в котором будет развернут Snort. Введя имя каталога, следует щелкнуть на кнопке Next, чтобы завершить процесс установки.
 |
| Экран 2. Выбор компонентов установки |
Этап 3. Тестирование установки Snort
Завершив процесс установки, Snort требуется протестировать. По умолчанию исполняемому файлу Snort необходимо сообщить два адреса: куда записывать журналы и где найти файл конфигурации (snort.conf). Эту информацию предоставляет пользователь при запуске Snort из командной строки с помощью ключей -l и -c соответственно. Например, команда
Snort -l F:snortlog -c F:snortetcsnort.conf -A console
указывает программе, что журналы следует записывать в каталог F:snortlog, а snort.conf находится в каталоге F:snortetc. Ключ -A задает способ передачи генерируемых программой предупреждений. В данном примере предупреждения выводятся на экран консоли, и администратор может убедиться, что Snort работает корректно. Обратите внимание, что в статье команда напечатана на нескольких строках, но в командном окне ее необходимо вводить в одной строке. То же самое относится и к другим многострочным командам в данной статье. Многие ключи командной строки Snort чувствительны к регистру символов, поэтому вводить команды следует именно так, как они напечатаны.
Если система располагает несколькими сетевыми интерфейсами, то по умолчанию Snort прослушивает первый обнаруженный интерфейс. Если порядок сетевых интерфейсов на машине неизвестен, можно выполнить команду Snort с одним ключом -W. Snort выдает список имен и номеров сетевых интерфейсов в том порядке, в котором их обнаруживает программа. Чтобы заставить Snort использовать определенный сетевой интерфейс, необходимо ввести ключ -i с номером интерфейса при запуске Snort. После выполнения Snort на экране появится информация, подобная приведенной на экране 3 .
Запустив Snort, можно проверить его чувствительность, направив в NIDS специально подготовленный трафик. Один из самых простых способов вызвать предупреждение об опасности - обратиться к командному интерпретатору (cmd.exe) на удаленной машине в рамках запроса HTTP URL (типичный прием «червей» Code Red и Nimda). Чтобы имитировать эту фазу нападения, следует обратиться к любому URL и добавить в конце запроса символы /cmd.exe. Например, в ответ на обращение к http://www.a-website-that-I-can-trust.com/cmd.exe Snort должен вывести предупреждение в командном окне, по виду напоминающее первые три предупреждения на экране 4 . Эти сообщения и записываются в журнал F:snortlog.
Целевые Web-узлы для тестирования следует выбирать с осторожностью. С технической точки зрения большинство администраторов Web-узлов будут рассматривать подобные действия как попытку взлома. Такая попытка не приведет к успеху (если только в конфигурации сервера не допущены серьезные ошибки), но я рекомендую проводить тестирование только с собственным сервером или доверенным сервером, администраторам которого известно о проведении испытаний.
Если тестирование сделать невозможно, существует другой способ проверить Snort - послать через сеть необычайно длинный эхо-запрос на сервер или компьютер с активной программой Snort. Например, можно воспользоваться командой Ping
Ping -l 32767 ip_address
где ip_address - IP-адрес целевого сервера или Snort-компьютера. Данная команда должна послать очень длинный пакет (точная длина - 32 Кбайт), что явно необычно для команды Ping. Snort должен обнаружить этот пакет, как видно на примере нижних восьми предупреждений на экране 4 .
Если предупреждения получены, можно приступать к настройке Snort для конкретных условий. В противном случае необходимо вернуться к процедуре установки и проверить, не был ли пропущен какой-нибудь этап.
Этап 4. Настройка Snort
Основные данные о конфигурации Snort хранятся в файле snort.conf, который по умолчанию располагается в каталоге %systemdrive%snortetc. Файл можно оставить в этой папке или переместить в другую, если указать программе путь в командной строке.
Детальное описание всех параметров, представленных в snort.conf, может заполнить весь номер журнала, так как Snort - удивительно мощная программа. Мы пока рассмотрим лишь основные ее параметры.
Чтобы отличить входящий трафик от исходящего, необходимо сообщить Snort узлы и IP-адреса сети предприятия. Для ввода этой информации в файле snort.conf должна быть задана переменная HOME_NET. Следует отыскать строку
Var HOME_NET any
и заменить ее диапазоном IP-адресов. Можно задать один диапазон, например
Var HOME_NET 192.168.0.1/24
или несколько диапазонов. Указывая несколько диапазонов, необходимо заключить набор диапазонов в квадратные скобки и отделить каждый диапазон запятой. Вводить пробелы между диапазонами IP-адресов нельзя. Например, строка
Var HOME_NET
указывает Snort, что подсети 10.0.1.0/24, 10.0.2.0/24 и 10.0.3.0/24 относятся к сети предприятия. По умолчанию Snort воспринимает все остальные адреса как внешние. Можно явно указать сети, которые следует считать внешними, задав переменную EXTERNAL_NET. В файле snort.config необходимо отыскать строку
Var EXTERNAL_NET any
и заменить ее IP-адресом сети, которую следует считать внешней. Однако, как правило, для начала лучше оставить переменную EXTERNAL_NET со значением any.
Потратив некоторое время, можно указать типы серверов, имеющиеся на предприятии, и их местоположение. Эта информация содержится в переменных DNS_SERVERS, SMTP_SERVERS, HTTP_SERVERS, SQL_SERVERS и TELNET_SERVERS в следующих строках файла snort.conf:
Var DNS_SERVERS $HOME_NET var SMTP_SERVERS $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var TELNET_SERVERS $HOME_NET var SNMP_SERVERS $HOME_NET
По умолчанию всем шести серверным переменным присвоено значение $HOME_NET; это означает, что Snort будет контролировать все типы нападений на все системы в диапазоне HOME_NET. Такая конфигурация вполне приемлема для небольшой сети, администраторы которой допускают некоторое число ложных предупреждений. Но для мониторинга интенсивного трафика желательно выполнить более тонкую настройку Snort для проверки только части сигнатур для определенных узлов. Не имеет смысла защищать Web-сервер, работающий только с Microsoft IIS, от атак с переполнением буфера SQL. Чтобы определить особый класс узлов, необходимо заменить $HOME_NET диапазоном IP-адресов целевых серверов в соответствии с форматом, использованным для переменной HOME_NET. Например, для переменной DNS_SERVERS вместо $HOME_NET следует подставить диапазон IP-адресов DNS-серверов.
Точность настройки можно повысить, если определить порты, используемые серверами для конкретных приложений. Например, если Web-серверы задействуют специальный порт 8080 для трафика HTTP вместо порта 80 (этот порт обычно применяется для Web-серверов и браузеров), то можно настроить Snort на отслеживание порта 8080, изменив переменную HTTP_PORTS. В snort.conf следует отыскать строку
Var HTTP_PORTS 80
и заменить ее строкой
Var HTTP_PORTS 8080
Точно так же можно изменить порты для Oracle (определяемые переменной ORACLE_PORTS) и других приложений. Как и переменная HTTP_PORTS, по умолчанию ORACLE_PORTS имеет значение 80. Если сервер использует вместо него порт 1521, то строка будет иметь вид
Var ORACLE_PORTS 1521
Таким образом, в файле snort.conf можно настроить много параметров. Следует просмотреть snort.conf, отыскать параметры, наиболее важные для конкретной среды, и соответствующим образом настроить их.
Этап 5. Задание правил
В одной из строк snort.conf встречается переменная RULE_PATH. Примерный вид этой строки:
Var RULE_PATH ../rules
Параметр../rules указывает, что правила (т. е. сигнатуры) можно найти в каталоге rules, который находится в структуре каталогов на одном уровне с двоичными файлами Snort. Поэтому, например, если установить Snort в типовой папке F:snort, двоичные файлы Snort находятся в F:snortin, а правила - в F:snort ules. При желании можно изменить переменную RULE_PATH, но вполне приемлем и вариант, выбираемый по умолчанию.
Правила - основа Snort. Они представляют собой последовательности байтов, сигнатуры нападений и данные других типов, при обнаружении которых генерируется предупреждение. Snort располагает более чем 1500 готовых сигнатур.
Как выглядит правило? Правило для cmd.exe, которое было нарушено при проведении теста Snort, имеет следующий вид: alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:»WEB-IIS cmd.exe access»; flow:to_server, established; content:»cmd.exe»; nocase; classtype:web-application-attack; sid:1002; rev:5;). Рассмотрим основные компоненты правила. Ссылка $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS указывает, что следует анализировать только трафик, поступающий в сеть извне (как определено переменной EXTERNAL_NET). Параметр content: задает поиск последовательности символов cmd.exe в потоке данных. Обнаружив такую последовательность, Snort генерирует предупреждение, задаваемое параметром msg:.
Как видно на примере cmd.exe, правила в основном просты. Можно составить собственные правила для трафика любых типов. Например, если требуется обнаружить несанкционированные попытки удаленного доступа к каталогу на машине через командный интерпретатор, то можно провести поиск строки volume in drive или volume serial number в портах, где они бывают редко, таких как порты для передачи исходящего трафика. Благодаря гибкому подходу к назначению правил, администраторам предоставляются широкие возможности конфигурирования Snort.
1500 правил Snort хранятся в различных файлах в соответствии с типами анализируемых данных. Например, правило для cmd.exe находится в файле web-iis.rules. Если на предприятии IIS не применяется, то программе не нужно обнаруживать атаки IIS. Файл web-iis.rules легко удалить из конфигурации целиком, отыскав и обозначив как комментарий строку
Include $RULE_PATH/web-iis.rules
в файле snort.conf. Чтобы сделать строку комментарием, нужно поставить перед ней символ (#):
# include $RULE_PATH/web-iis.rules
По умолчанию файлы правил некоторых типов (например, icmp-info.rules, chat.rules) представлены комментариями в snort.conf. Используемая по умолчанию конфигурация правил в snort.conf вполне удачна. После активизации блокированных правил программа, как правило, генерирует много лишних предупреждений.
В некоторых файлах содержится ряд полезных правил, но несколько правил генерируют слишком много ненужных предупреждений. Чтобы отключить то или иное правило, нужно обозначить как комментарий соответствующую строку в файле правил. В дальнейшем Snort будет игнорировать это правило при работе с файлом.
При появлении новых источников угрозы файл правил необходимо обновить. Лучший ресурс для новых правил - Web-узел Snort.org. На этом Web-узле нет службы автоматического обновления, поэтому администратору придется регулярно обращаться к нему за обновлениями при возникновении очередной опасности.
Этап 6. Настройка предупреждений и журналов
Как уже отмечалось, Snort обеспечивает запись информации в MySQL, SQL Server, Oracle и ODBC-совместимых базах данных. Достаточно выбрать подходящий тип базы данных в процессе установки Snort. Чтобы чрезмерно не увеличивать объем статьи, рассмотрим стандартные режимы протоколирования с использованием текстового файла и функции записи сообщений в журнал событий Windows.
При запуске NIDS с помощью команды Snort ключ консоли -A обеспечивает вывод предупреждений на экран. Чтобы пересылать сообщения в текстовый файл, следует заменить этот ключ на -A fast или -A full, в зависимости от предпочтительного режима протоколирования. Параметр full выводит подробное описание угрозы в нескольких строках текстового файла с именем alerts.ids каталоге, путь к которому указывает ключ -l. Такой тип протоколирования сообщает исчерпывающие детали, но в них трудно разобраться, если в сети отмечается много событий. В таких «шумных» сетях рекомендуется использовать режим fast для внесения в alerts.ids однострочных записей, содержащих основные характеристики подозрительного трафика. На мой взгляд, работать с текстовым файлом в режиме fast проще, чем в режиме full.
Текущая версия Snort обеспечивает протоколирование в журнале событий Windows. Многие организации уже приобрели инструменты централизованного мониторинга событий, протоколирования и сбора данных, и данная функция будет отличным дополнением для среды Windows.
Для записи предупреждений в журнал событий Application системы, на которой работает Snort, вместо ключа -A используется ключ -E (параметры не обязательны). На экране 5 показано, как выглядит событие Snort (в данном случае попытка обращения к cmd.exe), опубликованное в журнале Application. Событие Windows обеспечивает такую же детальную информацию, как экран консоли.
NIDS бесполезен, если администратор заглядывает в журналы событий (или текстовые журналы) раз в неделю. Если что-то случается в сети, администратор должен узнать об этом незамедлительно. Централизованная система мониторинга и обработки событий может посылать сообщения по электронной почте, на пейджер и другие устройства связи. Но если такой системы нет, это не повод для беспокойства. Компания NETIKUS.NET предлагает бесплатный пакет EventSentry Light, с помощью которого можно посылать предупреждения.
EventSentry Light - ознакомительная версия EventSentry, ее можно загрузить по адресу http://www.netikus.net/products_downloads.html . С помощью EventSentry Light можно настроить систему на мониторинг журналов событий и автоматическую рассылку по электронной почте подробных сообщений о любых событиях Snort, записанных в журнал. На экране 6 показано почтовое сообщение о попытках нападения на cmd.exe. Я получил это сообщение от EventSentry Light спустя несколько секунд после проведения атаки.
Как упоминалось выше, обычно Snort генерирует массу ненужных сообщений, которые быстро переполняют журналы событий. Об этом следует помнить при выборе размеров файлов для журналов событий и метода их ротации. Чтобы EventSentry Light не переполнял почтовый ящик сообщениями о незначительных событиях, можно создать фильтр для поиска ключевых строк. Например, я организовал фильтр поиска строки в тексте сообщений.
Этап 7. Запуск в качестве службы
Завершив все приготовления, можно задействовать Snort в качестве службы, вместо того чтобы регистрироваться на настольном компьютере всякий раз, когда требуется запустить программу. Если запустить Snort с параметрами /SERVICE и /INSTALL (наряду с другими параметрами командной строки), то Snort настраивается на работу в качестве службы Windows и автоматически запускается вместе с Windows без вмешательства пользователя.
Следующий уровень: модули расширения
Snort представляет собой полнофункциональное приложение. Однако в некоторых случаях программа нуждается в расширении. Например, если в разных участках сети развернуто несколько NIDS, то управлять Snort удобно из графического интерфейса. Такие возможности реализованы в модулях расширения IDScenter фирмы Engage Security и IDS Policy Manager компании Activeworx. Иногда бывает необходимо проанализировать информацию, которая содержится в сообщениях. Просмотреть и проанализировать сохраненные данные можно с помощью модуля Analysis Console for Intrusion Databases (ACID), разработанного в Университете Карнеги - Меллона.
Надежная защита
Snort - полнофункциональная программа, которая не нанесет ущерба бюджету компании. Объединив Snort с мощным приложением мониторинга событий, таким как EventSentry Light, можно своевременно предупреждать атаки против сети.
Введение
Основная цель данной работы заключается в описании и изучении популярного IDS приложения Snort. Snort является крупным проектом с открытым исходным кодом, который используется многими сетевыми администраторами для фиксирования вредоносных сигнатур и оповещения о атаке на сеть. Snort перехватывает от сетевых интерфейсов весь трафик, проверяя пакеты на наличие подозрительных запросов, попыток вторжения.
Основным его плюсом является доступность, и возможность редактировать его работу под свою конкретную рабочую сеть. Программа предназначена для работы как в малых, так и больших организациях. Так же не маловажна возможность редактирования собственных уникальных правил исходя из требований безопасности конкретной организации (например, запрет на доступ персонала к социальным сетям).
Из минусов можно выделить неудобность настройки и установки на некоторых ОС (например, Windows), отсутствие единого достаточно полного и подробного описания настройки и разработки собственного набора правил.
Также, очень тяжело отсечь ложные тревоги, так как не редко на разных предприятиях разные ограничения, и требуется достаточно тонкая настройка правил. Множество режимов запуска приложения с помощью ключей чувствительных к регистру очень сложно запоминаемы и могут привести к ошибочному выводу.
Основная задача этой работы состоит в том, что бы разобраться с функциональными особенностями работы IDS Snort, проверить работу приложения производя на него разного рода сетевые атаки. Выяснить есть ли аналогичные IDS в более удобном формате. Как Snort взаимодействует с базами данных. Разработать несколько уникальных правил и проверить их на работоспособность.
Установка и настройка IDS Snort
Snort: Установка на ОС Windows XP
При установке Snort на операционную систему Windows могут возникнуть некоторые сложности. Поэтому в этой работе уделяется достаточно подробная часть установки и возможностей настройки. Для начала нужно скачать требуемые программы на рабочий компьютер.
Правила для Snort.
Все вышеуказанное скачивается с официальных сайтов этих приложений.
Winpcap - приложение, которое перехватывает и фильтрует пакеты на уровне ядра. Это аналог встроенному драйверу Unix систем libpcap. Установка не доставит особых не удобств, запускается через обычный инсталлятор. После этого требуется скачать с официального сайта саму IDS, после этого мы скачиваем оттуда же свежий архив с правилами. Следующим шагом станет полное копирование всех папок, которые находились в архиве с правилами в корневой каталог приложения с полной заменой содержимого, где это требуется. Затем для правильной работы программы потребуется провести важные изменения в конфигурационном файле.
var RULE_PATH c:snort ules
var SO_RULE_PATH c:snortso_rules
var PREPROC_RULE_PATH c:snortpreproc_rules
dynamicpreprocessor directory c:snortlibsnort_dynamicpreprocessor
dynamicengine c:snortlibsnort_dynamicenginesf_engine.dll
#dynamicdetection directory /usr/local/lib/snort_dynamicrules
Находим подобные строчки в конфигурационном файле и заменяем теми которые предоставлены выше. После этого пробуем протестировать приложение. Запускаем командную строку и переходим к каталогу приложения в раздел "bin". Введем команду "snort -W"
Рис. 1.1.
Этой командой мы проверяем работоспособность приложения просматривать наши интерфейсы. Убедившись что их более одного, выбираем тот который подключен к рабочей сети, что бы приступить к перехвату пакетов и отслеживанию работы IDS.
С:Snortinsnort -i 3 -c C:snortetcsnort.conf -l C:snortlog -A console
Разберем теперь команду которую мы ввели. "- i 3" означает что мы будем просматривать интерфейс который имеет ID= 3 в списке наших интерфейсов. Затем мы указали путь до файла конфигурации и путь до каталога куда следует записывать "log" перехваченных пакетов. "-A console" обозначает что тревожные пакеты будут выявляться у нас в консоли. Если во время обработки возникают какие либо неполадки устраняем их по ходу выявления. Snort указывает строку и вид ошибки при сборке. Если все сработало, то мы ничего не увидим до тех пор пока не сработает одно из запущенных правил. Что бы задействовать одно из них попробуем имитировать сетевую атаку и запустим подозрительный пакет по нашей локальной сети. Для этого к примеру откроем командную строку и введем следующее: "Ping 192.168.1.16". Snort перехватит попытку прослушать хост под адресом 192.168.1.1624 и выведет сообщение и информацию об подозрительном действии в сети. К сожалению у подобных IDS систем есть сильный недостаток -это ложные срабатывания. В связи с этим для того что бы Snort был полезным и не вводил в заблуждение, нужно достаточно емко и четко прописывать правила и разграничивать просматриваемые сети, что бы избежать этих ложных срабатываний.
Рис. 1.2.
Сейчас в консоли, где работает наш IDS, появятся сообщения о подозрительном пакете, который напоминает "прослушивание". Это задействованное правило показало, что Snort полностью работоспособен. Рассмотрим режимы его работы и синтаксис правил для дальнейшей работы.
