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

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

Учимся писать логи

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

Открываем подсистему логов из приложения с помощью функции 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 ([e-mail])

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

Теория

При анализе атак, причем как на реальные, работающие системы, так и на различные OpenHack\honeypot\honeynet (о которых ты сможешь прочесть в этом номере), были выявлены общие признаки, демаскирующие взломщика. И основываясь именно на этих признаках, умные девелоперы создали первую 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-кодов. Ох-ох-ох, что ж я маленьким не сдох… ;)