Cистемное протоколирование в Linux

Sep 17 08:32:56 kos3 kernel: Linux version 2.4.2-2 (root@porky.devel.redhat.com) 
(gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 8 20:41:30 EDT 2001

Sep 17 08:32:56 kos3 kernel: Kernel command line: auto BOOT_IMAGE=linux ro 
                             root=303 BOOT_FILE=/boot/vmlinuz-2.4.2-2

Sep 17 08:32:56 kos3 kernel: Detected 1594.849 MHz processor.
Sep 17 08:32:56 kos3 kernel: Memory: 125652k/130560k available (1365k kernel code, 
                             4200k reserved, 92k data, 236k init, 0k highmem)
Sep 17 08:32:56 kos3 kernel: CPU: L1 I cache: 12K, L1 D cache: 8K
Sep 17 08:32:56 kos3 kernel: CPU: L2 cache: 256K
Sep 17 08:32:56 kos3 kernel: CPU: Intel(R) Pentium(R) 4 CPU 1.60GHz stepping 02

Sep 17 08:32:56 kos3 kernel: hda: MAXTOR 6L020J1, ATA DISK drive
Sep 17 08:32:56 kos3 kernel: hdc: SAMSUNG CD-ROM SC-148C, ATAPI CD/DVD-ROM drive
Sep 17 08:32:56 kos3 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Sep 17 08:32:56 kos3 kernel: ide1 at 0x170-0x177,0x376 on irq 15
Sep 17 08:32:56 kos3 kernel: hda: 40132503 sectors (20548 MB) w/1819KiB Cache, 
                             CHS=2498/255/63, UDMA(100)
Sep 17 08:32:56 kos3 kernel: Partition check:
Sep 17 08:32:56 kos3 kernel:  hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 >
Sep 17 08:32:56 kos3 kernel: Floppy drive(s): fd0 is 1.44M

Sep 17 08:32:56 kos3 kernel: usb-uhci.c: USB UHCI at I/O 0x1820, IRQ 11
Sep 17 08:32:56 kos3 kernel: usb-uhci.c: Detected 2 ports
Sep 17 08:32:56 kos3 kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
Sep 17 08:32:56 kos3 kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A
Sep 17 08:32:56 kos3 kernel: eth0: Intel(R) 8255x-based Ethernet Adapter
Sep 17 08:32:56 kos3 kernel: Intel(R) PRO/100 Fast Ethernet Adapter - 
                             Loadable driver, ver 1.5.6
Sep 17 08:32:56 kos3 kernel: PCI: Found IRQ 11 for device 02:08.0

Sep 17 08:32:56 kos3 kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Sep 17 08:32:56 kos3 kernel: IP Protocols: ICMP, UDP, TCP, IGMP
Sep 17 08:32:56 kos3 kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Sep 17 08:32:56 kos3 kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP]
Sep 17 08:32:56 kos3 kernel: parport0: irq 7 detected
Сен 17 08:32:42 kos3 rc.sysinit: Turning on user and group quotas for local 
                                 filesystems: succeeded 
Сен 17 08:32:43 kos3 rc.sysinit: Enabling swap space:  succeeded 
Sep 17 08:32:44 kos3 init: Entering runlevel: 3 
Сен 17 08:32:45 kos3 kudzu: Updating /etc/fstab succeeded 
Сен 17 08:32:55 kos3 kudzu:  succeeded 
Сен 17 08:32:55 kos3 network: Устанавливаются параметры сети:  succeeded 
Сен 17 08:32:55 kos3 network: Поднимается интерфейс lo:  succeeded 
Сен 17 08:32:56 kos3 network: Активируется интерфейс eth0:  succeeded 
Сен 17 08:32:56 kos3 keytable: Загружается раскладка клавиатуры: 
Сен 17 08:32:56 kos3 keytable: Загружается системный шрифт: 
Сен 17 08:32:56 kos3 random: Инициализируется генератор произвольных чисел: succeeded
Sep 17 08:32:41 kos3 rc.sysinit: Configuring kernel parameters:  succeeded 
Sep 17 08:32:41 kos3 rc.sysinit: Setting default font (cyr-sun16):  succeeded 
Sep 17 08:32:41 kos3 rc.sysinit: Activating swap partitions:  succeeded 
Sep 17 08:32:41 kos3 rc.sysinit: Setting hostname kos3:  succeeded 
Sep 17 08:33:03 kos3 xinetd: запуск xinetd succeeded
Сен 17 08:33:05 kos3 gpm: запуск gpm succeeded
Сен 17 08:33:05 kos3 crond: запуск crond succeeded
Sep 17 08:33:06 kos3 xfs: listening on port 7100 
Сен 17 08:33:06 kos3 xfs: запуск xfs succeeded

Sep 17 08:32:56 kos3 kernel: VFS: Mounted root (ext2 filesystem) readonly.
Sep 17 08:32:56 kos3 kernel: Adding Swap: 265032k swap-space (priority -1)
Sep 17 08:32:56 kos3 kernel: MSDOS FS: Using codepage 866
Sep 17 08:32:56 kos3 kernel: MSDOS FS: IO charset koi8-r
Sep 17 08:32:41 kos3 rc.sysinit: Mounting USB filesystem:  succeeded 
Sep 17 08:32:41 kos3 rc.sysinit: Checking root filesystem succeeded 
Sep 17 08:32:41 kos3 rc.sysinit: Remounting root filesystem in read-write mode:  succeeded 
Sep 17 08:32:41 kos3 rc.sysinit: Mounting proc filesystem:  succeeded 
Sep 17 08:32:41 kos3 fsck: /: clean, 30407/160000 files, 95270/319410 blocks 
Sep 17 08:32:42 kos3 fsck: /HOME: clean, 6573/432864 files, 689090/863722 blocks 
Sep 17 08:32:42 kos3 fsck: /usr: clean, 55105/329952 files, 286888/659602 blocks 
Sep 17 08:32:42 kos3 rc.sysinit: Checking filesystems succeeded 

Sep 17 08:32:42 kos3 mount: SMB connection failed 
Sep 17 08:32:42 kos3 mount: Packet send failed to 10.104.129.245(137) ERRNO=Network 
                            is unreachable 
Sep 17 08:32:42 kos3 mount: mount: /dev/sda4: unknown device 
Сен 17 08:32:59 kos3 mount: error connecting to 192.168.36.20:139 (No route to host)
Сен 17 08:32:59 kos3 mount: mount: /dev/sda4: unknown device

Sep 17 08:33:14 kos3 login(pam_unix)[916]: session opened for user kos by LOGIN(uid=0)
Sep 17 08:33:14 kos3  -- kos[916]: LOGIN ON tty1 BY kos
Сен 17 08:41:39 kos3 su(pam_unix)[1138]: authentication failure; logname=kos uid=500 
					euid=0 tty= ruser= rhost=  user=root

Сен 17 10:30:07 kos3 rc: Stopping keytable:  succeeded
Sep 17 10:30:07 kos3 Font Server[870]: terminating 
Сен 17 10:30:08 kos3 xfs: останов xfs succeeded
Сен 17 10:30:08 kos3 gpm: останов gpm succeeded
Sep 17 10:30:08 kos3 xinetd[668]: Exiting...
Sep 17 10:30:10 kos3 rpc.statd[506]: Caught signal 15, un-registering and exiting.
Sep 17 10:30:11 kos3 kernel: Kernel logging (proc) stopped.
Sep 17 10:30:11 kos3 kernel: Kernel log daemon terminating.
Сен 17 10:30:12 kos3 syslog: останов klogd succeeded
Sep 17 10:30:12 kos3 exiting on signal 15

Примерно такую же структуру имеют и записи в других файлах протоколов, упоминаемых в файле /etc/syslog.conf.

logger [-isd] [-f file] [-p PRI] [-t TAG] [-u socket] [MSG ...]

Пошлите несколько сообщений с помощью программы logger и полюбуйтесь на результат в файле /var/log/messages (если, конечно, вы не изменили заданное по умолчанию значение).

Кстати сказать, имеется очень интересный способ просмотра сообщений, записываемых в файл /var/log/messages командой logger. Способ этот основан на использовании специальной программы tailf. Откройте окно терминала, получите права суперпользователя (командой su) и выполните в этом окне команду
tailf /var/log/messages
После этого переключитесь в другой терминал и выполните там команду logger произвольный_текст. Ваше сообщение тут же отобразится в том окне, где запущена программа tailf. То есть с помощью этой программы администратор системы может отслеживать запись новых сообщений в протокол в реальном режиме времени. Правда, у системного администратора вряд ли найдется время, чтобы следить за поведением системы таким образом (разве что в экстренных ситуациях). Поэтому для анализа протоколов разработаны специальные программы. Но о них чуть ниже, а пока перейдем к вопросу о том, как организовать надзор за удаленным компьютером (помните как поймал злоумышленника Шимомура?).

Как было сказано, сообщения системы протоколирования могут отправляться демоном syslogd на удаленный хост. Но там его кто-то должен принять. Оказывается делает это такой же демон syslogd, запущенный на этом удаленном хосте. Точнее, syslogd на любом компьютере может прослушивать не только сокет /dev/log (принимая тем самым сообщения от местных источников), но еще и порт 514/UDP, что обеспечивает прием сообщений с других компьютеров локальной сети (и последующую запись их в локальный файл). Тем самым обеспечивается возможность создания "сервера протоколирования", что может оказаться очень удобно для системного администратора (в одном месте отслеживаются все события в сети), а также повышает безопасность сети, поскольку сообщения о проникновении хакера на один из хостов сети не могут быть тут же этим хакером удалены из протокола.

Однако, для организации такого "сетевого протоколирования" необходимо предпринять некоторые дополнительные усилия.

Во-первых, поскольку для приема и отправки сообщений по сети используется порт 514/UDP, он должен быть доступен на обеих компьютерах (клиенте и сервере). Для этого в файле /etc/services на обеих компьютерах должна присутствовать строка
    syslog       514/udp
Если такая строка в /etc/services отсутствует, syslogd не может ни принимать сообщения, ни отправлять их в сеть, поскольку не может открыть UDP-порт. Если такая ситуация возникает, syslogd немедленно прекращает записывать какие-либо сообщения даже в локальный протокол. При этом, как показывает команда ps, он остается в памяти и даже сохраняет сообщения в каких-то буферах, поскольку, если строку "syslog   514/udp" восстановить в файле /etc/services на клиенте, то по крайней мере часть "пропавших" сообщений все же появляется в протоколе (после перезапуска syslogd).

Во-вторых, при запуске демона syslogd на сервере должна быть указана опция -r, которая обеспечивает возможность удаленного протоколирования (по умолчанию демон syslogd ждет сообщения только от локального сокета). О том, как и где задать эту опцию, будет рассказано ниже, в разделе о запуске демона syslogd.

Ну, и в-третьих, должны быть соответствующим образом исправлены настройки в файлах /etc/syslog.conf на обеих компьютерах. Например, если вы хотите все сообщения перенаправить на сервер протоколирования, необходимо на компьютере-клиенте прописать в файле /etc/syslog.conf строку следующего вида:
*.*     @hostname
Если во время старта демона syslogd сервер окажется недоступен (например, он в этот момент отключен от сети) или не удастся найти его по имени (служба DNS не сработала должным образом) syslogd осуществляет еще 10 попыток нахождения сервера и только если и после этого найти сервер не удалось, прекращает попытки и посылает соответствующее сообщение.

Если в вашей сети имеется несколько доменов, которые обслуживаются одним сервером протоколирования, то не удивляйтесь тому, что в протоколе на сервере будут указаны полные имена клиентов (с указанием домена). Правда, при запуске syslogd можно использовать опции -s список_доменов или -l список_хостов, которые обеспечивают замену в протоколе полных имен хостов на их краткие имена (без указания домена).

Не забудьте после корректировки опций запуска и файла /etc/syslog.conf перезапустить демон, поскольку, в отличие от cron, sysklogd не перечитывает конфигурационные файлы автоматически.

После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid.

Демон klogd имеет не меньше опций запуска, чем syslogd, однако приводить их здесь не будем, отсылая читателя к соответствующей man-страничке (пользователю не стоит заниматься настройкой klogd, лучше оставить ее в том состоянии, как она произведена разработчиками дистрибутива).

Сначала необходимо упомянуть, что в Linux имеется команда с таким же названием. Если сравнить вывод этой команды (когда она запущена без параметров) с содержимым файла /var/log/dmesg, то обнаружится что они очень похожи, хотя и не идентичны (направьте вывод команды в файл dmesg2 и сравните файлы dmesg и dmesg2). Точнее, файл /var/log/dmesg один в один совпадает с началом того вывода, который мы получим по команде dmesg. Как следует из [4,6], в ядре имеется кольцевой буфер, в который записываются сообщения демона протоколирования ядра. Те сообщения, которые записываются в этот буфер в процессе загрузки, и составляют содержание файла /var/log/dmesg. По-видимому, этот файл формируется по окончанию загрузки системы.

Если вы снова посмотрите на приведенный листинг файла /etc/syslog.conf, то увидите, что все сообщения категории kern выдаются также и на консоль. Но там они быстро пробегают по экрану и вы вряд ли успеваете их прочитать и осмыслить. Зато они сохранены в файле /var/log/dmesg и тем самым доступны для неторопливого осмысления (если процесс загрузки успешно завершился). После окончания процесса загрузки запись сообщений от ядра в кольцевой буфер продолжается. Когда выполняется команда dmesg, выдается текущее состояние буфера. Поэтому вывод этой команды содержит больше сообщений, чем файл /var/log/dmesg: в выводе этой команды вы видите и те сообщения, которые ядро выдает после окончания процесса загрузки.

Все сообщения из /var/log/dmesg вы обнаружите и в файле /var/log/messages, только там они чередуются с сообщениями от других программ. Имеется только одно существенное различие: в файле dmesg время и источник сообщения (имя хоста и категория сообщения) не указываются. Хост тут всегда "местный", а начало отсчета времени определяется последней перезагрузкой компьютера.

Кроме файла dmesg в каталоге /var/log/ есть еще два файла, не упоминавшихся в /etc/syslog.conf, но имеющих непосредственное отношение к протоколированию - это файлы lastlog и wtmp. Но заглядывать в них так же, как мы просматривали файл /var/log/messages не имеет смысла - вы ничего не поймете. Дело в том, что информация в эти файлы записывается в особом формате, и просматривать ее надо с помощью специальных программных средств. Но сначала надо сказать несколько слов о назначении этих файлов.

Файл lastlog хранит информацию о последнем входе пользователя в систему. Не знаю, обращали ли вы внимание на то, что когда вы вводите имя и пароль пользователя, на экране появляется примерно следующее ссобщение:

localhost login: kos
Password:
Last login: Wed Oct 9 19:25:53 on tty1 

В отличие от файла /var/log/lastlog, который содержит записи о времени последнего входа в систему каждого пользователя, в файле /var/log/wtmp запоминаются все входы и выходы пользователей в систему с момента создания этого файла. Как и в файле lastlog, записи в /var/log/wtmp делаются в специальном формате, так что просматривать их можно только с помощью специальных команд. Но, прежде чем рассказывать об этих командах, скажем, что существует еще один файл, содержащий записи о логировании пользователей - это файл /var/run/utmp. Этот файл содержит информацию о том, кто из пользователей работает в системе в данный момент.

Вот теперь можно рассказать о том, как просматривать информацию о работающих или ранее работавших в системе пользователях. Основной командой для этого является команда last. Она выводит все записи из файла /var/log/wtmp, причем указывается имя пользователя, указание на терминал, с которого работал пользователь, время входа пользователя в систему и время выхода его из системы, а также продолжительность сеанса работы пользователя в системе. В случае, если работа пользователя прервалась только из-за отключения самой системы, вместо времени выхода пользователя стоит слово "down" (по этим строкам легко определить время остановки системы). Время повторного запуска отображается отдельными строками, начинающимися словом "reboot".

Команда lastb подобна команде last, но выводит информацию о неудачных попытках входа пользователей в систему. Однако, надо отметить, что эта команда будет работать только в том случае, если существует файл /var/log/btmp. Впрочем, ни одна из рассматриваемых здесь программ не создает файлов регистрации, поэтому если какой-то из них удален, то ведение записей заканчивается.

Команда lastlog форматирует и выводит содержание файла /var/log/lastlog. Будут выведены поля имя пользователя, имя терминала, с которого вошел пользователь и время последнего входа в систему. По умолчанию (когда команда введена без параметров) элементы файла /var/log/lastlog будут выводиться в порядке номеров идентификаторов пользователей. Если указать параметр -u login-name, будет выведена только информация о времени последнего входа указанного пользователя. Указав параметр -t days, Вы получите только записи за последние days дней. Если пользователь вообще пока не заходил в систему, то вместо имени терминала и времени последнего входа будет указана строка "**Never logged in**".

При выполнении команды lastlog на медленном компьютере в некоторых случаях может возникнуть впечатление, что команда "зависла". Это происходит в силу того, даже если в системе зарегистрировано всего два пользователя (root и user), в файле /var/log/lastlog все равно отведено место для максимально возможного числа пользователей, которые могут работать в системе. Поэтому в файле /var/log/lastlog могут иметься большие промежутки между номерами идентификаторов работавших в системе пользователей. Поскольку при просмотре таких интервалов программа не выводит информацию на экран, и возникает впечатление "зависания".

Для вывода информации о том, кто работает в текущий момент в системе, используются команды w, who и users. Команда users используется тогда, когда вы хотите только знать, кто из пользователей работает в данный момент в системе, но не интересуетесь тем, с какого терминала он подключился и что делает. Если вы хотите знать, кто с какого терминала вошел в систему, используйте команду who. Эта команда выводит информацию из файла /var/run/utmp. Можно заставить ее выводить данные из файла /var/log/wtmp (или любого другого файла, для которого это имеет смысл), если указать имя этого файла в командной строке. Но в выводе вы все равно увидите только имя пользователя, указание на терминал, с которого вошел пользователь, время входа и, в случае входа с удаленного компьютера, имя этого компьютера.

Существенно больше информации выводит команда w. В ее выводе вы увидите текущее время, как долго система уже работает, сколько пользователей в данное время работает в системе и средняя загузка системы за последнюю минуту, 5 и 15 минут. Затем для каждого пользователя выводится:

Как уже говорилось, команда w выводит информацию, сохраненную в файле utmp. Между прочим, руководство man утверждает, что простые пользователи должны быть лишены права записи в файл utmp, так как многие системные программы (по каким-то необъяснимым причинам) зависят от его целостности. Вы рискуете спутать системные файлы статистики и внести изменения в системные файлы, если Вы предоставите любому пользователю возможность производить записи в файл utmp .

192.168.36.21 - - [18/Oct/2002:11:58:05 +0400] "GET /ve/papers/new/log/ HTTP/1.1" 200 1774 
		"-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
192.168.36.21 - - [18/Oct/2002:11:58:05 +0400] "GET /icons/back.gif HTTP/1.1" 304 - "-" 
		"Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
192.168.36.21 - - [18/Oct/2002:11:58:05 +0400] "GET /icons/folder.gif HTTP/1.1" 304 - "-" 
		"Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
192.168.36.21 - - [18/Oct/2002:11:58:05 +0400] "GET /icons/text.gif HTTP/1.1" 304 - "-" 
		"Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
192.168.36.21 - - [18/Oct/2002:11:58:09 +0400] "GET /ve/papers/new/log/protok_lovim.htm 
		HTTP/1.1" 200 46597 "http://linux/ve/papers/new/log/" "Mozilla/5.0 
		(X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
192.168.36.21 - - [18/Oct/2002:11:58:09 +0400] "GET /bugtraq.css HTTP/1.1" 404 279 
		"http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla/5.0 (X11; U; 
		Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
192.168.36.21 - - [18/Oct/2002:11:58:10 +0400] "GET /img/bug1.gif HTTP/1.1" 404 280 
		"http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla/5.0 (X11; U; 
		Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
192.168.36.21 - - [18/Oct/2002:11:58:10 +0400] "GET /img/title.gif HTTP/1.1" 404 281 
		"http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla/5.0 (X11; U; 
		Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"

Samba-сервер, кроме основного протокола работы сервера, создает в подкаталоге /var/log/samba целый ряд файлов протоколов на разные случаи, в частности отдельные файлы для каждого из пользователей, которым разрешено использовать ресурсы, предоставляемые этим сервером. Из одного такого файла и взяты следующие две записи:

[2002/03/20 13:57:07, 1] smbd/service.c:make_connection(550)
  linux (192.168.36.10) connect to service public as user kos (uid=500, gid=500) (pid 1366)
[2002/03/20 14:25:01, 1] smbd/service.c:close_cnum(550)
  linux (192.168.36.10) closed connection to service public

Различных программ и скриптов для анализа протоколов разработано достаточно много. Я ограничусь краткой характеристикой двух таких средств: logwatch и swatch.

logwatch - это скрипт на языке Perl, входящий в стандартный дистрибутив Red Hat Linux. Как раз во время подготовки настоящей статьи на сайте разработчика (а им является Кирк Бауер) была выложена версия 4.1 этой программы [7].

Основная идея, заложенная в эту программу, заключается в том, что файл протокола пропускается через фильтр, который выделяет из протокола все строки (то есть сообщения), удовлетворяющие заданному критерию. Результаты отправляются по электронной почте указанному пользователю (по умолчанию - root-у). Фильтры могут быть написаны на любом языке программирования, но автор пакета предпочитает Perl. Фильтры должны быть написаны так, что читают данные с stdin и выводят результат на stdout.

Основной способ использования logwatch состоит во включении ссылки на основной скрипт (/etc/log.d/scripts/logwatch.pl) в директорию /etc/cron.daily, что вызывает ежедневное выполнение logwatch с параметрами по умолчанию. Ссылке дают имя, которое начинается с "00" (например, 00-logwatch), чтобы скрипт запускался до logrotate.

Но можно запустить скрипт и из командной строки. Конечно, если вы не меняли параметр вывода информации, то результат его работы надо искать в почтовом ящике суперпользователя. Если же вы хотите видеть эти результаты на экране, то необходимо задать в командной строке параметр --print - выдавать отчет на stdout.

Общий формат запуска скрипта:

/etc/log.d/scripts/logwatch.pl [--detail уровень] [--logfile группа-журналов] [--service имя-сервиса] [--print] [--mailto адрес] [--save имя-файла] [--archives] [--range интервал-дат]

Параметры по умолчанию хранятся в файле /etc/log.d/logwatch.conf, комментарии в котором позволяют понять смысл параметров командной строки:

• LogDir - директория, относительно которой рассматриваются имена файлов;
• MailTo - кому отправлять отчет;
• Print - вместо посылки отчета по почте выдать его на stdout;
• Save - вместо посылки отчета по почте сохранить его в указанном файле;
• Archives - обрабатывать не только текущие версии журналов, но и созданные logrotate старые копии;
• Range - обрабатывать указанный временной интервал: All, Today, Yesterday (вчерашние календарные сутки);
• Detail - уровень подробности отчета: от 0 до 10 или Low, Med, High;
• Service - All или имя фильтра из /etc/log.d/scripts/services/ (можно указывать несколько фильтров);
• LogFile - All или имя группы журналов (можно указывать несколько групп).

Более подробную информацию о скрипте logwatch вы найдете в [8,9].

В статье [10] описан другой скрипт для обработки файлов протоколов, который входит в состав дистрибутива Mandrake Linux. Скрипт этот называется swatch ("Simple WATCHer") и тоже написан на Perl.

Управление работой swatch осуществляется с помощью единственного конфигурационного файла, по умолчанию $HOME/.swatchrc. Этот файл содержит образцы текста (в форме регулярных выражений), которые swatch будет искать в файлах протоколов. Вслед за каждым таким образцом указывается действие, которое swatch должен предпринять в том случае, если он обнаружит текст, соответствующий шаблону.

Например, вы хотите получать предупреждение при каждой попытке атаки на ваш web-сервер методом переполнения буфера при запросе очень длинного имени файла (buffer-overflow attack). И вы знаете, что в таких случаях в файле протокола /var/apache/error.log появляется сообщение, содержащее слова "File name too long". В таком случае в ваш файл .swatchrc необходимо вставить следующее указание:

watchfor /File name too long/
    mail addresses=root@somedomain.com,
    subject=BufferOverflow_attempt

Я не буду приводить здесь более подробное описаие программы swatch. Ей посвящена восторженная статья [10], а саму программу можно найти на сайте [11]. Хочется только отметить, и swatch, и logwatch реализуют довольно примитивный алгоритм обработки файлов протоколов, сводящийся к поиску в протоколе заданной строки символов (сигнатуры). Между тем, во-первых, наличие такой строки зачастую еще не свидетельствует о вторжении злоумышленника, а, во-вторых, грамотный злоумышленник может позаботиться о том, чтобы стереть следы свой деятельности [12]. Еще один очевидный недостаток рассмотренных продуктов заключается в том, что они работают в "отложенном режиме", поскольку запускаются только по расписанию. А борьбу со злоумышленниками надо вести "в режиме реального времени", немедленно реагируя на попытки проникновения в систему. Поэтому в коммерческих продуктах предлагаются системы мониторинга, работающие постоянно, и реализующие "интеллектуальные" алгоритмы анализа протоколов. Эти алгоритмы основываются на статистическом анализе потока сообщений и выявлении статистически значимых отклонений системы от ее нормального поведения.

В заключение этого раздела отмечу, что на сайте SecurityLab.ru (http://www.securitylab.ru/tools/?ID=22111) приведен список ссылок на сайты различных программных средств для обработки протоколов с краткой характеристикой этих средств. Вы можете поэкспериментировать с различными программами и выбрать ту, которая вас устроит.

Скрипт logrotate следит за ростом файлов протоколов и обеспечивает так называемую ротацию этих файлов в случае, если они превысили указанный размер (или по истечению указанного временного интервала). Ротация есть не что иное, как последовательное копирование предыдущих версий архивных файлов примерно следующим образом:

Перечень файлов для обработки скриптом logrotate и параметры этой обработки определяются конфигурационными файлами, которых может быть несколько. Имена конфигурационных файлов задаются в командной строке запуска скрипта (о параметрах запуска см. ниже). В Red Hat Linux по умолчанию в качестве конфигурационных файлов для logrotate используется файл /etc/logrotate.conf, который может иметь примерно такой вид:

weekly
rotate 4
create
compress
include /etc/logrotate.d

/var/log/wtmp /var/log/lastlog {
    monthly
    create 0664 root utmp
    rotate 1
}

Этот файл как и любой конфигурационный файл для скрипта logrotate состоит из нескольких секций. Первая секция определяет глобальные параметры (по одному на строке), задающие параметры по умолчанию для всех журналов. Следующие секции определяют локальные параметры для серии файлов протоколов. Имена этих файлов перечисляются в первой строке секции, а затем в фигурных скобках задаются локальные параметры, действующие только при обработке указанных файлов (тоже по одному параметру в строке). Имена файлов протоколов могут быть заключены в кавычки по правилам shell, если они содержат пробелы и другие специальные символы. Можно указывать несколько имен файлов или шаблонов имен файлов через пробел (шаблоны также по правилам shell). Обработка каждой секции рассматривается как единое действие. Строки, начинающиеся с символа "#" являются комментраиями. Локальные параметры имеют приоритет над глобальными.

В приведенном примере конфигурационного файла сначала описываются глобальные параметры, а затем в отдельной секции - параметры обработки файлов /var/log/wtmp и /var/log/lastlog. Кроме того, среди глобальных параметров дается ссылка на директорию /etc/logrotate.d, в которую каждый пакет записывает локальные параметры для своих журналов.

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