просматривать программным кодом.
«Что искать», – спросишь ты? Все подозрительное: некорректные входы в систему, отказы в аутентификации пользователя, строки login/password etc. Как пример, многие win-пользователи привыкли к тому, что при входе в систему имя пользователя уже введено и остается только вбить пароль. В *nix это не так. В результате, в логе вполне могут оказаться актуальные пароли, вбитые как имя пользователя. Система, конечно же, не пропустила, но в лог записала. Если это повторится, то пора с данным юзером профилактическую беседу проводить.
Особое внимание стоит уделить поиску строк типа /bin/sh. В этом случае, если строчка чередуется с «мусором», вполне логично предположить, что тебя пытались поломать (и ты видишь shell-код).
Кроме того, при логировании сетевых служб следует искать некорректные входы в систему, попытки подбора пароля.
Здесь самое главное – опыт админа. Чутье ищейки и знание того, что же ты должен увидеть, понимание, как тот или иной механизм должен работать. Я подчеркиваю, это важно как при конфигурации системы протоколирования, так и при анализе результатов ее работы.
Логи должны храниться в течение некоторого разумного времени (к примеру, в течение недели). В особенных случаях можно писать логи на 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, или по-русски система обнаружения атак. С ее помощью админы всего мира уже предотвратили огромное число взломов. Пора и тебе включить ее в постоянный рацион :).
При анализе атак, причем как на реальные, работающие системы, так и на различные OpenHack honeypothoneynet (о которых ты сможешь прочесть в этом номере), были выявлены общие признаки, демаскирующие взломщика. И основываясь именно на этих признаках, умные девелоперы создали первую 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
Но рано радоваться. Увы, старина Снорт уязвим. У взломщика есть возможность (и ещё какая!) заставить Снорт никак не реагировать на твои действия. Если есть правила, то их не стоит нарушать, их
