LASG - Log files and other forms of monitoring
Log-файлы и другие формы наблюдения
Обзор
Основы протоколирования
Протоколирование системы
Log-мониторы
Протоколы ядра
Shell-протоколы
Одной из главных частей любой UNIX-системы является протоколирование
(logging). В Linux оно обеспечивается двумя основными программами: sysklogd и
klogd, первая предоставляет сервис протоколирования программам и приложениям,
вторая делает то же самое в отношении ядра Linux. Klogd фактически посылает
большинство сообщений syslogd, но при необходимости выдает сообщения и на
консоль (например, kernel panics). Sysklogd фактически решает задачу
обработки большинства сообщений и посылки их в соответствующий файл или на
устройству, это настраивается в /etc/syslog.conf. По умолчанию большинство
файлов протокола лежат в /var/log, и вообще говоря, программы, которые ведут
свой протокол (большинство httpd-серверов обрабатывают события сами), имеют
файл с именем вида /var/log/program-name, который позволяет Вам
централизовать журналы и делает работу с ними проще, что позволяет поместить
их в отдельный раздел (некоторые нападения могут заполнять файлы регистрации
очень быстро, а полный корневой раздел приводит к проблемам). Дополнительно
имеются программы, которые обрабатывают их собственные протоколы полностью
сами, в этом плане интересна bash command shell. По умолчанию bash хранит
файл хронологии команд в ~username/.bash_history. Apache обрабатывает события
сам с перестраиваемой конфигурацией в httpd.conf. Sendmail обрабатывает
требования регистрации через syslogd но также имеет и опцию (параметр -X в
командной строке) регистрации всех SMTP-транзакций прямо в файл. Это
нецелесообразно, поскольку файл будет становиться огромным за короткий
промежуток времени, но полезно для отладки.
Вообще говоря, Вы не хотите позволять пользователям видеть журналы
сервера, и Вы особенно не хотите, чтобы они были способными изменять или
удалять их. Вообще говоря, большинство журналов принадлежит пользователю и
группе root, и не имеет никаких прав для кого-то еще, так что в большинстве
случаев единственный пользователь, способный изменять файлы протоколов root.
Есть несколько способов дополнительной защиты, самый простой из них команда
“chattr” (CHange ATTTRibutes) для перевода log-файлов в режим
append only. Файл может дополняться, но стереть его будет нельзя. Для
перевода его в такой режим нужно:
chattr +a filename
Только суперпользователь имеет доступ к этой функции chattr. Если Вы
устанавливаете все журналы в такой режим, помните что программы прокрутки
журналов будут терпеть неудачу, поскольку они не будут способны временно
удалить журнал. Добавьте к скрипту обновления журналов строку для отмены
режима append only:
chattr -a filename
и добавьте строку в тот же скрипт после обработки журнала, чтобы
восстановить атрибут append only. Если Вы храните журналы в системе, Вы
можете также установить атрибут immutable, так что с ними что-то сделать
будет гораздо сложнее. Для установки атрибута immutable просто:
chattr +i filename
Теперь файл не сможет удалить никто, кроме root.
chattr -i filename
Только пользователь root имеет доступ к атрибуту immutable.
Одно свойство Linux средства syslog и klog, которые позволяют программному
обеспечению генерировать сообщения для протоколов, которые затем передаются
log daemon и обрабатываются (пишутся в локальный файл, пересылаются на другой
сервер, посылаются программе или обрабатываются как-то еще).
klogd обрабатывает ядерные сообщения, в зависимости от вашей установки, их
может быть разное количество. Например, можно включить учет процессов в
системе. Реально почти все сообщения передаются syslogd для дальнейшей
обработки. man-страницы для sysklogd, klogd и syslog.conf довольно хорошие с
ясными примерами. Одна чрезвычайно мощная и часто пропускаемая способность
syslog состоит в том, чтобы регистрировать сообщения на удаленный хост на
котором работает syslog. Так как Вы можете определять много мест назначения
для сообщений syslog (i.e. посылать все сообщения в файл /var/log/messages,
на консоль, на удаленный хост или на несколько таких хостов) это позволяет
Вам централизовать регистрацию на одном хосте. Но если кто-то все же
доберется до протоколов и поправит их в своих интересах, Вы об этом можете и
не узнать: встроенных средств контроля целостности тут нет.
Стандартные log-файлы, которые обычно определяются в файле syslog.conf:
/var/log/messages
/var/log/secure
/var/log/maillog
/var/log/spooler
Первый (messages) получает большую часть информации: входы в систему
пользователей, дампы TCP_WRAPPERS, данные о IP-firewall и многое другое.
Второй обычно записывает события подобные изменениям пользователями своих
UID/GID (через su, sudo), ошибки авторизации паролей и прочее в таком духе.
Файл maillog обычно хранит сведения о соединениях pop/imap (вход и выход
пользователей) и заголовок каждого письма прошедшего через систему (от кого,
кому, msgid, status и прочая информация). Файл spooler не часто используется
поскольку число людей использующих usenet или uucp резко упало, uucp был в
основном заменен на ftp и email, а большинство серверов usenet обычно
чрезвычайно мощные машины, чтобы обработать полный или даже частичный
newsfeed, значит их немного (обычно одна на ISP или чуть больше в зависимости
от размера).
Можно задавать дополнительные log-файлы, например:
kern.* /var/log/kernel-log
Можно также разделить поток сообщений на разные файлы в соответствии с
типом сообщений:
*.emerg @syslog-host
mail.* @mail-log-host
Теперь все сообщения ядра будут записываться в /var/log/kernel-log. Во
втором случае все аварийные сообщения будут регистрироваться на “
syslog-host”, и все журналы почты будут посланы на “mail-log-host
”, позволяя Вам легко поддерживать централизованные журналы различных
услуг. Значение по умолчанию syslogd, которое поставляется во многих
дистрибутивах ужасно опасно, журналы легко можно поправить или вообще
разрушить.
По умолчанию файлы протоколов доступны на чтение/запись только для root.
К тому же можно и нужно установить для них режим append only (помните, что
программы ротации журналов воспринимают это болезненно).
Основная проблема, это исправленные журналы. Можно установить режим append
only с помощью “chattr +a”, но с правами root его также легко снять
и поставить на место после необходимой правки журнала. Есть безопасная версия
syslogd, доступная на
http://www.core-sdi.com/english/freesoft.htm (эти парни вообще делают
хорошие инструментальные средства и имеют хорошую репутацию). Здесь есть
возможность криптоподписи файла протокола, что гарантировано обеспечит данные
о том, что его никто не трогал. В конечном счете, однако, нападавший может
все же удалять журналы, так что хорошая идея послать их другому хосту,
особенно в случае firewall, чтобы предотвратить диск от переполнения.
Другая альтернатива: “syslog-ng” (Next Generation Syslog),
который кажется намного больее настраиваемым чем syslog или secure-syslog, он
поддерживает цифровые сигнатуры, чтобы предотвратить вмешательство в файлы
регистрации, и может фильтровать данные, исходя из содержания сообщения, а не
только того, откуда это исходит или приоритета (что является очень полезным
для сокращения объема). Syslog-ng доступен на
http://www.balabit.hu/products/syslog-ng.
Nsyslogd поддерживает tcp и SSL для протоколирования удаленных систем.
Работает на разных UNIX-платформах и доступен на
http://coombs.anu.edu.au/~avalon/nsyslog.html.
Log-файлы бесполезны, если не уметь извлекать из них данные. К сожалению,
они часто превосходят все разумные размеры, так что вопрос об автоматизации
извлечения нужных данных вполне логичен.
Psionic Logcheck регулярно (можно из crontab) изучает файл messages (и
другие) и посылает по e-mail отчет о всем подозрительном. Он легко
настраивается с помощью ‘классов’ событий: которые нужно
игнорировать, активные попытки проникновения, просто плохие действия. Psionic
Logcheck доступен на
http://www.psionic.com/abacus/logcheck.
colorlogs ракрашивает log-файлы, позволяя легко найти подозрительное.
Основанный на файле конфигурации, он ищет ключевые слова и сопоставляет им
цвета строк (red, cyan и другие), требуется ввод с STDIN, так что Вы можете
использовать это средство чтобы сделать быстрый обзор журналов (используя
“cat”, “tail” или другие утилиты, чтобы передать файл
программе). Получить можно на
http://www.resentment.org/projects/colorlogs.
WOTS собирает log-файлы с нескольких источников и генерирует отчеты или
сам принимает меры основываясь на том, что Вы ему велели. WOTS ищет
регулярные выражения которые Вы определяете, и затем выполняет команды,
которые Вы вносите в список. WOTS требует установки Perl и доступен на
http://www.vcpc.univie.ac.at/~tc/tools.
swatch очень подобен WOTS, и настройка журналов тоже очень похожа. Вы
можете скачать swatch с
ftp://ftp.stanford.edu/general/security-tools/swatch.
Самый низкий уровень регистрации идет на уровне ядра. Вообще говоря,
пользователи не могут отключить этот тип регистрации и даже обычно не знают,
что такое существует.
Информация здесь.
Ряд оболочек имеет встроенные возможности регистрации.
Я рассмотрю bash поскольку это заданная по умолчанию оболочка в
большинстве версий Linux. bash имеет большое количество переменных, которые
Вы можете конфигурировать во время выполнения. Можно настроить все: от стиля
приглашения ко вводу команды, до того сколько строк хранить в журнале.
HISTFILE
имя файла протокола, по умолчанию ~username/.bash_history
HISTFILESIZE
максимальное количество команд, хранимых в файле, обеспечивается прокрутка
при необходимости.
HISTSIZE
сколько команд помнить (при использованни клавиши up arrow).
Переменные обычно задаются в /etc/profile, который настраивает bash для
всех пользователей глобально, но они могут быть перекрыты в файле
~username/.bash_profile вручную используя команду export чтобы установить
переменные типа export EDITOR=emacs. Это одна из причин того, почему каталоги
пользователей не должны быть всемирно читаемыми; файл .bash_history может
содержать много ценной информации. Вы можете запретить запись в него,
выключить ведение протокола через свой файл .bash_profile или связать его с
/dev/null, дабы не дать bash вести протокол. Для root я рекомендую задать
минимальные значения HISTFILESIZE и HISTSIZE (например 10). С другой стороны,
если Вы хотите регистрировать хронологию оболочки пользователей для анализа
их действий задайте для этих файлов атрибуты immutable и append only,
используя команду .bash_history. Правда, такой подход создаст еще ряд
проблем, так что заручитесь согласием пользователей.
Back
| 
