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

#см. первую строку.

.info;*.!warn;\

authpriv.none, cron.none -/var/log/messages

Обрати внимание: я описываю только то, что есть в моей системе. Один из признаков профессионализма админа – логи, соответствующие реально используемым сервисам.

Далее. Есть еще горячая парочка логов – wtmp и utmp, бинарные файлы, и с ними нам придется работать аккуратно. В них хранится информация о подключении пользователей к системе. Но есть ряд тонкостей:

1) utmp хранит данные о подключении пользователей в текущий момент (см. команду who, к примеру);

2) wtmp хранит данные обо всех подключениях к системе. Если, к примеру, некто вошел в систему и сразу вышел, то именно здесь он и «наследил». Самые свежие записи хранятся в начале файла;

3) если файлов в системе нет, syslogd их создавать не станет. Самому придется создать через touch. Но! Если они были, то где они теперь?

Во-первых, до настройки логов определяемся, что и с каких хостов писать, так как логи не резиновые и их надобно смотреть. Потеряется смысл записи, если в них будет куча всякого мусора. Необходимо четко понять, что писать важно, а что нет.

К примеру, есть роутер Cisco, есть web-сервер, FTP-сервер (на одной системе), есть мэйл-сервер и DNS (на второй). Знаю, что не по правилам, но так уж вышло.

Также есть тачка админа, который для повседневной работы использует ту же систему, что и на его серверах. Где писать логи? Ответ сам напрашивается: на компьютере админа! Если система взломана, то логов хакер на ней не найдет! Придется еще и систему админа ломать :).

Что писать? Аутентификация – раз, подсистемы (FTP, mail …) – два. Это минимум. В данном случае любые попытки доступа и/или использования наших серверов будут записываться. Получаем картинку того, что в сети творится.

Во-вторых (я противник такого метода, но… он самый надежный), все логи, поступающие на машину админа, следует немедленно отправлять на печать. Даже в случае взлома системы админа, при котором все логи, конечно, будут неизменны, у нас останется жесткая копия. Здесь, правда, перед нами встает этический вопрос – а стоит ли весь этот бред жизни деревьев, переводимых на бумагу :)?

Получив логи, отвечающие должным требованиям, не стоит забывать об их обслуживании.

Как правило, рекомендации «лучших собаководов» сводятся к тому, что необходимо поставить некий софт, отвечающий за работу с логами. Все верно. Но это должен быть софт, написанный тобой лично. Тут поможет Perl, писавшийся, между прочим, специально для этих целей.

Лог представляет собой некую последовательность форматированных строк, которые удобно просматривать программным кодом.

«Что искать», – спросишь ты? Все подозрительное: некорректные входы в систему, отказы в аутентификации пользователя, строки login/password etc. Как пример, многие win-пользователи привыкли к тому, что при входе в систему имя пользователя уже введено и остается только вбить пароль. В *nix это не так. В результате, в логе вполне могут оказаться актуальные пароли, вбитые как имя пользователя. Система, конечно же, не пропустила, но в лог записала. Если это повторится, то пора с данным юзером профилактическую беседу проводить.

Особое внимание стоит уделить поиску строк типа /bin/sh. В этом случае, если строчка чередуется с «мусором», вполне логично предположить, что тебя пытались поломать (и ты видишь shell-код).

Кроме того, при логировании сетевых служб следует искать некорректные входы в систему, попытки подбора пароля.

Здесь самое главное – опыт админа. Чутье ищейки и знание того, что же ты должен увидеть, понимание, как тот или иной механизм должен работать. Я подчеркиваю, это важно как при конфигурации системы протоколирования, так и при анализе результатов ее работы.

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

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

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

Открываем подсистему логов из приложения с помощью функции 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, или по-русски система обнаружения атак. С ее помощью админы всего мира уже предотвратили огромное число взломов. Пора и тебе включить ее в постоянный рацион :).

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

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

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

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

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