LXF92:Ведение журналов
|
|
|
Содержание |
Расчистка файлов журналов
- За деревьями не видите леса? Урежьте файлы журналов по разумнымправилам, и вашими данными станет проще управлять. Д-р Крис Браун вам все объяснит.
Ввашем ведении – Linux-системы, критичные для вашего бизнеса? Web-сервер, сервер баз данных или почтовый сервер, и, возможно, пограничные укрепления типа межсетевого экрана? Знайте, что мониторинг состояния этих систем жизненно важен, и файлы журналов – ваше первое прибежище: они могут подсказать, что настроено не так, предупредить о попытках взлома или просто подтвердить, что все идет как надо.
В прошлый раз мы разбирались, как ведется запись в файлы журналов. Сейчас мы бегло просмотрим содержимое некоторых из них и поймем, что там находится; затем изучим инструменты, помогающие анализировать журналы и управлять ими.
Сообщения в журналах делятся на две категории: маленькие, которые можно читать по строкам, и большие, которые невозможно охватить без дополнительной обработки. Давайте рассмотрим несколько коротких записей.
e1000: 0000:04:03.0: e1000_probe: (PCI:66MHz:32-bit) 00:0e:0c:4a:42:4e e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection e1000: eth0: e1000_watchdog_task: NIC Link is Up 10 Mbps Full Duplex
Экспонат А взят из кольцевого буфера ядра, который мы обсуждали в прошлый раз. Его строки показывают, что модуль ядра обнаружил и инициализировал сетевой интерфейс – важное подспорье, если вы добавили новое оборудование и пытаетесь проверить, распознает ли его Linux.
Feb 6 15:11:56 shrek named: zone localdomain/IN: loaded serial 42 Feb 6 15:11:56 shrek named: zone localhost/IN: loaded serial 42 Feb 6 15:11:56 shrek named: named.local:9: unknown RR type ‘PT’
Экспонат B, взятый из журнала общего назначения, /var/log/messages, показывает, что DNS-сервер не запустился из-за синтаксической ошибки в одном из файлов зон. Feb 6 15:11:56 – дата события; shrek – имя компьютера. Далее, named – имя сервиса, рапортующего о проблеме, квалифицированной как loaded serial 42. Третья строка сообщает подробности, показывая номер строки и имя файла, где произошла ошибка.
Следующие три примера представляют собой сообщения, которые в большом количестве попадаются даже на здоровых машинах.
Feb 6 15:08:06 shrek su: pam_unix(su:session): Session opened for user root by pete (uid=571)
Экспонат C, из /var/log/secure, показывает, что обычный пользователь получил права root с помощью su. На данной конкретной машине запрещен прямой вход root’a, и при попыке получить полномочия root пользователи обязаны раскрыть свою личность (а значит, оставить контрольный след).
Feb 2 18:54:16 shrek sshd[4244]: Failed password for root from 125.246.84.5 port 39409 ssh2
Экспонат D демонстрирует неудачную попытку захода root по SSH. Увидев одно такое сообщение, вы подумаете, что, наверное, косорукий пользователь ошибся при вводе пароля, но осознав, что их 10 000, и что уже 12 часов подряд они повторяются каждые пять секунд...
194.105.66.18 - - [05/Feb/2007:08:31:38 +0000] “GET /media/images/premiumskin07d/bg.gif HTTP/1.1” 404 320
Наконец, экспонат E – строка из журнала доступа к Apache. Это пример типового формата журнала, о котором говорилось в LXF91. Конечно, web-сервер и предназначен для обращений, поэтому появление новых строк само по себе не сюрприз; однако именно эта строка интересна тем, что говорит об ошибке 404 (файл не найден), подавая, возможно, сигнал о битой ссылке на сайте. Кстати, если вы настроите собственный формат журнала, Apache запишет в него более детальную информацию, включая содержимое любых полей заголовка HTTP-ответа. На самом деле, существует довольно стандартное расширение, называемое комбинированным форматом журнала, который понимают многие инструменты анализа журналов (более подробно об этом читайте на http://httpd.Apache.org/docs/1.3/logs.html#combined).
В принципе, никому не охота строка за строкой разбирать записи типа C, D и E. Хорошо бы кто-то проанализировал их за вас и выдал вам отчет, например: ‘pete хотел стать root-пользователем и использовал команду su 26 раз,’.
Стать супер-чистильщиком
Без вмешательства размер журнала выйдет за пределы разумного, а большая часть его данных устареет до полной бесполезности. Чтобы оставаться на гребне волны, отсекайте части журналов и посылайте старые журналы в архив. Для этого в дистрибутивах Linux используется инструмент logrotate. Он занимается ротацией журналов, то есть периодически разделяет их на осмысленные части и, со временем, удаляет старые. Обычно logrotate запускается раз в день как задача Cron. У logrotate есть собственный файл настройки, определяющий, какими он управляет журналами – укажите, как часто производить их смену (раз в день, неделю или месяц, или когда они достигнут определенного размера, который также можно задать). Старые журналы можно сжать и отправить по почте заинтересованным пользователям.
Главный файл настройки для logrotate находится в /etc/logrotate.conf – взглянем на него. Он определяет некоторые параметры по умолчанию и использует директиву include для включения файлов настройки отдельных сервисов из каталога /etc/logrotate.d. Исключая строки комментариев, на тестовой установке Fedora Core 5 logrotate.conf выглядит следующим образом (для удобства ссылок здесь вставлены номера строк):
1. weekly
2. rotate 4
3. create
4. include /etc/logrotate.d
5. # no packages own wtmp -- we’ll rotate them here
6. /var/log/wtmp {
7. monthly
8. create 0664 root utmp
9. rotate 1
10. }
В строке 1 мы велим logrotate обновлять журналы еженедельно.
Строка 2 говорит, что хранятся последние четыре файла журналов; в контексте данного примера это означает журналы за последние четыре недели. Когда происходит ротация, текущий журнал (например, /var/log/messages) переименуется в messages1; файл messages1 переименуется в messages2, и так далее. Строка 3 сообщает, что после смены журналов создадутся новые журналы. Можно настроить работу logrotate для каждого журнала в отдельности: например, журнал /var/log/messages менять каждый день и оставлять семь его поколений, а журнал /var/log/mail.log – каждую неделю, и оставлять последние четыре журнала.
Строка 4 говорит logrotate, чтобы он читал все файлы настройки из /etc/logrotate.d. В этом каталоге находится набор файлов, каждый из которых приписан к определенному сервису (или, более точно, к определенному журналу). Такое разбиение настроек позволяет упростить конфигурацию: по мере установки программ просто добавляются новые файлы настройки в каталог /etc/logrotate.d. Однако вполне возможно добавлять настройку определенных сервисов (или проводить всю настройку) прямо в logrotate.conf, именно такой пример мы видим в строках 5–10, с настройкой замены файла wtmp.
Примером отдельного файла настройки служит /etc/logrotate.d/ppp (также из Fedora Core 5). Данный файл управляет настройкой смены журнала, создаваемого демоном ppp, который управляет телефонными соединениями.
1. /var/log/ppp/connect-errors {
2. missingok
3. compress
4. notifempty
5. daily
6. rotate 5
7. create 0600 root root
8. }
Пройдемся по нему. Строка 1 описывает, к какому журналу применяется вся запись. В строке 2 logrotate велено не жаловаться, если журнала нет. Строка 3 требует, чтобы старые (уже смененные) журналы сжимались – в этом примере они примут вид connect-errors.1.gz. В строках 4 и 5 администратор указал, чтобы смена журналов не происходила, если журнал пуст, в противном случае журналы сменяются ежедневно (заметим, что эти настройки имеют преимущество над настройками по умолчанию в logwatch.conf). Понятно, что при таком раскладе необходимо запускать logrotate хотя бы раз в день.
Оставшиеся настройки должны быть вам теперь ясны: строка 6
говорит о сохранении пяти поколений журналов (подавляя настройки по умолчанию), а строка 7 (также подавляет настройки по умолчанию) говорит, что после смены журнал должен быть создан с заданными правами доступа. Существует еще несколько директив logrotate, указывающих, как работать с журналом; посмотрите man-страницы logrotate, чтобы узнать подробности.
Результат смены журналов можно увидеть, просмотрев содержимое каталога /var/log. Ниже приводится пример четырех смен журнала maillog:
$ ls -l /var/log/maillog* -rw------- 1 root root 4112 Jan 19 04:02 /var/log/maillog -rw------- 1 root root 6584 Jan 14 04:02 /var/log/maillog.1 -rw------- 1 root root 5771 Jan 7 04:02 /var/log/maillog.2 -rw------- 1 root root 7794 Dec 31 04:02 /var/log/maillog.3 -rw------- 1 root root 5561 Dec 24 04:02 /var/log/maillog.4
Вы можете видеть, что все эти файлы были созданы в 4:02 утра (не потому, что нервный сисадмин сорвался с койки и запустил logrotate, а потому, что запуск logrotate прописан как задача в Cron), но смена их происходит только раз в неделю. Так как мы держим только четыре последних поколения, то почтовые журналы, записанные до 17 декабря (когда был начат maillog.4), удалены. В этом примере файлы не сжимаются.
Наблюдаем за журналами
Хотя logrotate занимается проблемой разделения журналов на части требуемого размера, никакого анализа содержимого здесь не делается. Существует ряд открытых приложений (и несколько проприетарных), способных нам в этом помочь. Один из широко используемых инструментов – logwatch, простая, но полезная программа, выполняющая всю черновую работу по чтению и анализу журналов, так что вместо просмотра десятков тысяч строк текста журнала Apache вы получите отчеты с графиками использования сайта за день, час, по URL и так далее.
Logwatch доступна в большинстве дистрибутивов Linux. Как и logrotate, она обычно запускается ежедневно как задача Cron, и обычно настроена на отправку своего вывода по почте пользователю root; и если вы войдете как root на свой позабытый сервер и почитаете почту, то наверняка увидите длинный список ежедневных депеш от logwatch (и самую малость других писем). Сердцевина logwatch – Perl-скрипт /usr/share/logwatch/scripts/logwatch.pl. Но к нему еще поставляется малодоступная для восприятия иерархия файлов настройки и целый набор фильтров, вырезающих информацию из журналов о сервисах, которые вас не интересуют. В Fedora Core 5 logwatch запускается раз в день благодаря символьной ссылке на главный скрипт logwatch в каталоге /etc/cron.daily.
Структура каталогов logwatch
Большинство пользователей спокойно оставят для logwatch настройки по умолчанию, но когда вы освоитесь в запутанном лабиринте настроек и скриптов, то сможете много чего понаделать: например, написать собственные скрипты фильтров, если вы обладаете нужными навыками программирования – скорее всего, в Perl или PHP. Диаграмма Структура Каталогов Logwatch показывает основную структуру logwatch, корнем которой является /usr/share/logwatch. Крайний левый эллипс на рисунке (каталог /usr/share/logwatch/default.conf) содержит файлы, определяющие базовую настройку. Файлы в этом каталоге одинаковы для всех установок logwatch. Эллипс посередине (каталог dist.conf) содержит подкаталоги, аналогичные default.conf. В них содержатся настройки, специфичные для дистрибутива.
На самом деле, есть и третий каталог, /etc/logwatch/conf (на диаграмме не показан), дублирующий каталог default.conf: в нем содержится настройка под конкретную машину. Идея заключается в том, что вы должны не портить настройки по умолчанию, а использовать настройки для дистрибутива и машины для переопределения или расширения настроек (на нашей тестовой системе с Fedora настройки для дистрибутива и машины пусты). Так поступают не все дистрибутивы: Red Hat Enterprise Linux, например, имеет только один такой каталог, корень которого находится в /etc/log.d.
Центральным для настройки logwatch является понятие «сервис». Мы чувствуем себя обязанными заключить это слово в кавычки, потому что не имеем в виду конкретный сетевой сервис типа DNS или FTP, которые представлены особыми демонами в Linux. На языке logwatch, сервис – это просто некий источник журналируемой информации, идентифицируемый по имени. Все понятно?
Вы, вероятно, уже изнемогли от обилия сервисов; вернемся к любезным сердцу файлам настройки, точнее, к файлу настройки logwatch /usr/share/logwatch/default.conf/logwatch.conf. Вот он, лишенный комментариев (но с добавленными номерами строк):
1. LogDir = /var/log 2. TmpDir = /var/cache/logwatch 3. MailTo = root 4. Print = No 5. Range = yesterday 6. Detail = Low 7. Service = All 8. Service = “-zz-network” 9. Mailer = /bin/mail
Строка 1 говорит logwatch, где искать файлы журналов. Мы займемся этим через минуту, когда увидим, как определять группы журналов. Строки 3 и 4 объясняют, что вывод logwatch следует отправлять root по почте, а не выводить на STDOUT. Строка 5 определяет отметку времени, с которого начинается обработка записей в журнале (допустимые значения – yesterday, today и all), а строка 6 определяет уровень детализации получаемого отчета – имеются значения Low, Med, High, а как их интерпретировать, это уже дело фильтров данного сервиса. Если вы намерены обработать все сервисы, то установите в строке 7 значение All, как в нашем примере, но можно предусмотреть исключения, как в строке 8, которая явно запрещает сервис zz-network. Строка 9 указывает положение почтового агента.
Прежде чем двигаться дальше, стоит упомянуть, что большинство настроек можно переопределить из командной строки при вызове logwatch. Например, команда
# logwatch --detail High --service cron --print
обработает только сервис Cron, с высоким уровнем детализации, и результат отправится на стандартный вывод, а не по почте. Наберите man logwatch или logwatch --help, чтобы узнать подробности о дополнительных опциях командной строки.
Объединяемся в группы
Далее в нашем туре по файлам настройки мы остановимся на опре- делении сервисов, расположенных в default.conf/services. Файлы в этом каталоге определяют сервисы, о которых следует знать logwatch. Например, вот файл sshd.conf (комментарии опущены):
1. Title = “SSHD”
2. LogFile = secure
3. LogFile = messages
4. *OnlyService = sshd
5. *RemoveHeaders
Строка 1 определяет название сервиса. Любой вывод, генерируе-
мый фильтром для sshd, будет обрамлен так:
-------- SSHD Begin ---------
--------- SSHD End ----------
В строках 2 и 3, secure и messages – это имена пары групп журна-
лов. Группы журналов просто служат для назначения настроек, общих для нескольких определений сервисов. Группы определяются файлами в default.conf/logfiles; в нашем случае это secure.conf и messages.conf. Мы рассмотрим их далее, но попросту говоря, каждая группа журналов определяет один или более файлов, которые будут рассматриваться как источник журналируемых сообщений. Строка 4 определяет фильтр OnlyService, запускаемый с параметром sshd. Это один из разделяемых скриптов в каталоге cripts/shared; цель данного фильтра – отбор строк, начинающихся с sshd. Другой общий фильтр находится в строке 5: он удаляет «мусор» в начале каждого syslog-сообщения. Мусором мы полагаем отметку времени, имя узла и имя владельца – администрато- ру-исследователю они ни к чему.
Время взглянуть на одно из определений группы журналов.
Возьмем, к примеру, файл secure.conf. Вот он:
1. LogFile = secure 2. LogFile = authlog 3. Archive = secure.* 4. Archive = secure.*.gz 5. Archive = archiv/secure.*
