Спецвыпуск журнала «Хакер» #47, октябрь 2004 г. - Хакер

Логи должны храниться в течение некоторого разумного времени (к примеру, в течение недели). В особенных случаях можно писать логи на CD и хранить их столько, сколько нужно. Для этих целей есть фича logrotate. Идея такова: прописать в /etc/logrotate.conf, как и что хранить (пересылать ли на e-mail, копировать, сжимать, обрезать размер до нуля – см. man logrotate), а затем через cron раз в какой-то период запускать этого хозяйство. Важно то, что ты сам можешь настроить механизм замены логов так, как это нужно. К примеру, все отладочные сообщения просто и без затей уничтожать, доступ к HTTP – хранить и т.д.

На этом все! Если возникли вопросы, то читай маны, рой сеть и только потом пиши мне :).

Сначала добавляем к сорцу хидер <syslog.h> .

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

На этом этапе можно писать лог с помощью функции syslog(уровень_серьезности, сообщение) или vsyslog(), которая работает с форматированным выводом, как и printf.

В конце закрываем подсистему: closelog().

Для программного доступа к буферу ядра есть функция (man klogctl), которая очень похожа на syslog(). По идеям. По релизу – разберешься.

Увеличить размер буфера ядра можно (к примеру, для Linux-2.4.20 в файле /usr/src/linux/kernel/printk.c). Тебе должно быть интересно значение LOG_BUF_LEN. Естественно, придется пересобрать ядро.

Демон syslog работает на порту 514/UDP (сокет /dev/log), но можно перенаправить его и на иной порт через фаервол.

Хранилище логов в любом случае должно принадлежать root'у.

IDS/SNORT / Системы обнаружения атак

the_Shadow ([email protected])

Крайне важным помощником в админовском деле является IDS, или по-русски система обнаружения атак. С ее помощью админы всего мира уже предотвратили огромное число взломов. Пора и тебе включить ее в постоянный рацион :).

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

Системы обнаружения вторжений в «чистом виде» бывают двух типов:

– (HIDS) host based intrusion detection system – анализ того, что творится на хосте. Системы tripware, анализаторы log'ов.

– (NIDS) network based intrusion detection system – анализ сетевого трафика. Это куда интереснее, но и сложнее. Дело в том, что такая система работает как снифер, перехватывая и анализируя весь собранный трафик. По идее, NIDS должен уметь обнаруживать атаки как по сигнатурам, встречающимся в перехваченных пакетах, так и по хитрому анализу протоколов. Отличным примером такой системы является SNORT, о котором и пойдет дальше речь. Снорт седлает сетевые интерфейсы и осуществляет наблюдение за трафиком. Если вдруг что-то ему кажется подозрительным, то он громко «визжит» в логи. Идея несложная, правда?

Для начала надо понять, где же предпочтительнее всего ставить поросячью IDS. Так как наша задача – герметизировать сеть или подсети, то в достаточной мере очевидным будет то, что основное место для установки SNORT'а – роутеры.

Но помни: вторжение может осуществляться как извне, так и изнутри сети. Да, и свои «внутресетевые», пардон, дятлы могут «помочь».

Скачивай Снорта с его официальной паги: www.snort.org/downloads/snort-stable.tgz, растаривай в каталог, а в нем набирай:

ЛИСТИНГ

./configure; make; su; make install

Затем создавай директорию для поросячьих логов:

ЛИСТИНГ

mkdir /var/log/snort.

Теперь Снорт должен быть готов к настройке.

Конфигурировать нужно файлик /etc/snort.conf. Конкретно ты должен сделать следующее:

1. Опиши свою сеть – адреса, используемые протоколы (порты) и т.п. Тем самым ты укажешь, за чем надо присматривать. Чем полнее пропишешь, тем лучше.

2. Укажи, где и какие брать сигнатуры. В стандартной поставке хряка должны быть файлы типа *.rules. Тебе надо указать только те правила, которые реально необходимы твоей системе (какие сервисы в сети крутятся, такие *.rules и отбирай). По этим сигнатурам будет анализироваться трафик. Все это чем-то напоминает работу антивируса, только для TCP/IP. Кстати, когда разберешься, как работает эта IDS, то и сам сможешь создавать рулесы.

3. Опиши правила, на основании которых анализировать трафик, то есть какие атаки, с какого интерфейса возможны и что делать. Тут также все зависит от сервисов и их настроек.

Настроив, имеем полное право запустить SNORT:

ЛИСТИНГ

snort -D -c snort.conf

Но рано радоваться. Увы, старина Снорт уязвим. У взломщика есть возможность (и ещё какая!) заставить Снорт никак не реагировать на твои действия. Если есть правила, то их не стоит нарушать, их следует обойти. Свинка-то у нас глупенькая, и даже если она поймает в свои лапки shell-код, но сигнатура его окажется ей неизвестна, то будет молчать себе свинка в тряпочку.

Придется разбираться с *.rules. Есть некое свинское правило, shellcode.rules зовется. Ты только посмотри на него: в нем практически все мыслимые и несколько немыслимых shell-кодов. Ох-ох-ох, что ж я маленьким не сдох… ;)

Но как ни странно, не зря не сдох. Обойти это правило очень просто. Дело в том, что SNORT – это не антивирус, и он не обладает эмулятором кода, который сможет распознать shell-код не по сигнатуре, а по алгоритму (даешь эвристический IDS :)! – прим. AvaLANche'а). Следовательно, тебе надо несколько видоизменить сигнатуру shell-кода. Это можно сделать, просто переписав shell-код до неузнаваемости под себя. Самый простой способ – изменить (но без потери функциональности!) порядок следования команд или понатыкать NOP'ов (op-код – 90), создав «промежутки» в shell-коде. Конечно, при этом вырастет размер кода, но зато его сигнатура обманет Снорта. Как еще можно поменять сигнатуру?

1) Менять одни команды на другие. Тут тебе надо очень хорошо ориентироваться в асме и инструкциях целевого процессора. По сути дела, нужно написать свой shell-код, «неизученный» Снортом.

2) Вариант попроще – поменять вызов шелла. Строка /bin/sh приводит к поросячьей активности Снорта и, позже, админа, а строка %2Fbin%2Fsh – нет. Вот только не всегда это возможно. Хорошо этот способ работает, как правило, на web-сервисах.

3) Более сложный вариант – применение вирусных технологий (правда, вирусами тут и не пахнет). Никто не забыл о шифрации/дешифрации исполняемого кода? Можно написать (и многие пишут) shell-код, который будет в зашифрованном виде передаваться жертве, а при запуске расшифровываться «на лету». Меняя алгоритм шифрования или ключ, можно будет получать все новые и новые сигнатуры, неизвестные ранее этой IDS. Естественно, в сигнатуре будет светиться коротенький расшифровщик, но его видоизменить до неузнаваемости не составляет труда (подробнее о написании shell-кодов читай в августовском Спеце #08.04(45)).

Таким образом, грамотный взломщик помнит о SNORT'е и готовит эксплоиты собственоручно. Как в армии, где есть правило: оружие, обмундирование и снаряжение каждый готовит себе САМ!

SNORT – одна из самых первых и наиболее удачных реализаций системы IDS, работающая на основе анализа трафика. Я называю эту систему обнаружения атак «грязным свинтусом», так как на первом сайте, посвященном Снорту (еще до версии 1.0), на титульной странице, была вывешена фотография матерого хряка, упершегося рылом прямо в объектив фотографа. С тех пор система значительно повзрослела, сайт перенесли из домена .au в домен .org, а тельце старины Снорта отправили живым весом на колбасу, но имя его и образ живут. На логотипе по-прежнему присутствует довольная рожа (или рыло?) мультяшного хряка.

ТИП: Soft

Не одинок наш Снорти в этом мире. Полезно посмотреть:

– libnids – библиотека для создания такого рода систем (libnids.sourceforge.net). Собственно, я сам при необходимости именно ей и пользуюсь. Всегда приятно несколько обескуражить скриптодятла.

– iplog – анализ протокола на предмет атак.

– courtney – старушка Кортни, которая является простеньким перловым скриптом для обнаружения факта сканирования. Безнадежная пенсионерка.

Антон Карпов, специалист по сетевой безопасности, системный администратор

Часто говорят: если ты отражаешь атаку – ты уже проиграл. Доля правды в этих словах есть. Любые атаки желательно выявлять еще на стадии их зарождения, нежели разбираться с их результатом. К счастью, *nix-системы имеют для этого все средства. Развитая система протоколирования событий и своевременное наблюдения за аномалиями в системном журнале, а также использование сетевых средств обнаружения вторжений, конечно, помогут, но все что они позволяют – это отработать по факту того, что атака уже идет. Вот почему популярны не только системы обнаружения, но также и системы предотвращения вторжений. Простейший пример превентивной меры – соединение IDS с пакетным фильтром и подача команды на блокирование атакующего адреса.