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.* 6. Archive = archiv/secure.*.gz 7. Archive = authlog.* 8. Archive = authlog.*.gz 9. *ExpandRepeats 10. *OnlyHost 11. *ApplyStdDate
Строки 1 и 2 определяют имена настоящих файлов журналов. Здесь вы можете использовать абсолютные имена, а если нет, то имена берутся относительно каталога LogDir, определенного в основном файле настройки и указывающего на /var/log. В данном примере содержимое /var/log/secure и /var/log/authlog передается в цепочку фильтров для этого сервиса.
Строки 3–8 определяют местоположение архивов журналов; они используются, только если logwatch запускается с опцией --archives или если строка Archives = yes определена в главном файле настройки. Строки 9, 10 и 11 определяют последующие три фильтра (также в каталоге scripts/shared), которые будут помещены в начале цепочки фильтров. Фильтр ExpandRepeats был изначально спроектирован для надставки последнего сообщения, которое повторяется N раз, сообщениями syslog (как вы помните из прошлого урока), но авторы, видимо, передумали, и теперь фильтр просто подавляет эти сообщения. OnlyHosts фильтрует сообщения в соответствии с узлом, от которого они пришли – надеюсь, вы помните, что syslog может принимать сообщения от других узлов сети. Этот фильтр используется совместно с командной опцией --splithosts, она заставляет logwatch создать отдельный отчет для каждого узла, обнаруженного в исходных журналах. Наконец, фильтр ApplyStdDate отклоняет те строки, временные отметки которых не попадают на обрабатываемый день.
Цепочка фильтров для данных журнала
Все эти настройки «сшивают» вместе цепочку обработки фильтров, которые работают под управлением скрипта logwatch.pl, как показано во врезке Рис. «Цепочка фильтров для данных журнала». Показанные здесь общие фильтры располагаются в /usr/share/logwatch/scripts/shared; сервис-ориентированные скрипты – в /usr/share/logwatch/scripts/services. Именно сервис-ориентированные скрипты генерируют вывод.
Пропажа файлов
Если хотите увидеть logwatch в действии, можете запустить ее прямо из командной строки, благодаря символьной ссылке в /usr/sbin. Понадобится также определить опцию --print, чтобы увидеть вывод, так как по умолчанию вывод отправляется на почту root. Вот простой запуск:
########### Logwatch 7.2.1 (01/18/06) ############# Processing Initiated: Thu Feb 1 04:02:02 2007 Date Range Processed: yesterday ( 2007-Jan-31 ) Period is day. Detail Level of Output: 0 Type of Output: unformatted Logfiles for Host: www.example.com ################################################### ------------------- httpd Begin ------------------- Requests with error response codes 400 Bad Request /: 1 Time(s) 404 Not Found /media/images/premiumskin07d/bg.gif: 51 Time(s) /favicon.ico: 3 Time(s) -------------------- httpd End -------------------- ------------------ pam_unix Begin ----------------- sshd: Authentication Failures: unknown (61.19.233.102): 27 Time(s) admin (61.19.233.102): 3 Time(s) admin (61.136.58.249): 1 Time(s) root (61.136.58.249): 1 Time(s) unknown (61.136.58.249): 1 Time(s) Invalid Users: Unknown Account: 28 Time(s) su: Authentication Failures: pete(571) -> root: 1 Time(s) Sessions Opened: pete(uid=571) -> root: 3 Time(s)
Что мы можем извлечь из этого вывода? Похоже, на нашем web-сайте не хватает файла. Судя по названию, это нечто косметическое. Во-вторых, было некоторое число неудачных попыток зайти в систему по sshd (sshd и Apache – единственные сервисы, включенные на нашей машине). В-третьих, пользователь Pete заходил как root три раза (и случайно ошибся один раз; с кем не бывает, Pete). Так как прямой доступ root на этой машине запрещен, все попытки (удачные или неудачные) будут зарегистрированы, как показано здесь. Короче, ничего примечательного нет. Просто демоны делают свою рутинную работу.
Logwatch – не единственная рыбка в этом океане. Пользователи Debian возможно, напомнят нам о logcheck, которая выкидывает «нормальные» строки из журналов, пользуясь регулярными выражениями, а затем отправляет оставшиеся «аномальные» строки системному администратору. И, конечно, если у вас есть навыки Perl или PHP, вы сможете и сами сделать нечто подобное.
Ну, вот и все. Журналы. Мы вас предупреждали, что захватывающего в них мало! Но в дождливый день, если вы просмотрели газету, прочли Linux Format от корки до корки и вам нужен предлог, чтобы не мыть кошку, вы всегда можете скрыться в своем кабинете и почитать файлы журналов. LXF
Анализ web
Когда дело доходит до анализа журналов web-сервера, то вы можете использовать один из замечательных инструментов вроде Google Analytics и Clicktracks. Они помогут отделу маркетинга установить, как люди путешествуют по вашему сайту и откуда они туда попадают.
Открытый инструмент The Webalizer (http://www.mrunix.net/webalizer) – более традиционный: он считывает журналы, написанные Apache. Зато вы получаете статистику использования в HTML-формате, которую можно просмотреть в браузере. Можно получить статистику по годам, месяцам, дням и часам, а также отобразить статистику по сайту, URL, местам, откуда пришел пользователь, строке User Agent (т.е. браузеру), имени пользователя, строке поиска, странице входа/выхода и стране. Снимок экрана (на рис. 3) является примером вывода; каждая подчеркнутая ссылка в таблице ведет к более подробной статистике для этого месяца, включая графики использования по дням и часам, а также список популярных адресов URL.
Практично, что The Webalizer поддерживает собственный коллектор статистики деятельности сайта, так что он может предоставить данные, которые уходят в прошлое намного дальше, чем способен обеспечить движок смены файлов журналов. Он также поддерживает журналы передач по FTP с сервера wu-ftpd, и при необходимости сам разархивирует сжатые журналы.
