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

Как правило, большая часть демонов, функционирующих в системе, имеет в опциях конфигурации настройку параметров подсистемы протоколирования (см. тот же BIND). Со стороны системы все еще проще. Существует файл (у меня это /etc/syslog.conf) – основа для конфигурации всей работы демона syslogd, и если что-то надо поменять в протоколировании сообщений системы, то именно здесь.

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

Для настройки надо понять, что есть ряд уровней («уровней приоритета» или «серьезности») того или иного условия, которое протоколируется, и ряд типов приложений («средств»). Для каждой конкретной системы они описаны в коде ядра. И их значения разъяснены в манах.

«Серьезность» имеет 8 значений (0-7), где 0 – аварийная ситуация, когда всем пользователям шлется широковещательное сообщение и система останавливает свою работу. После такого отказа система, в принципе, может и не завестись. 7 – отладочное сообщение (для отладки приложения, и не более). Стоит заметить, что аналогичные уровни серьезности используются и в Cisco IOS. Эта система протоколирования очень похожа на никсовую.

«Средства» – это ряд типов процессов от ядра до подсистемы почтовых сообщений, включая аутентификацию, авторизацию, демонов etc.

То есть любая запись в файлы логов производится на основании того, что процесс хочет записать и с каким уровнем серьезности. Система (syslogd) перехватывает вывод процесса и отправляет строку в файл, указанный в конфиге. Как видишь, все просто.

Настраивая демона syslogd через /etc/syslog.conf, вполне можно добиться достойной нас информативности.

Вот пример (кусок реального файла) с комментариями:

ЛИСТИНГ

#Все, что касаемо аутентификации.

authpriv.* -/var/log/secure

#Все сообщения уровня Emergency (0) всем пользователям.

*.emerg *

#Писать сообщения от info до warn для сервисов, за исключением

#authpriv, cron – для этих сервисов есть другое место

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

.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 …) – два. Это минимум. В данном случае любые попытки доступа и/или использования наших серверов будут записываться. Получаем картинку того, что в сети творится.

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

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