Cистемное протоколирование в Linux. FreeBSD tips: использование syslog Linux логирование

Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь lnav будет активно развиваться, очень полезная программа на мой взгляд.

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

Одним из самых известных случаев использования файлов протоколов для обнаружения вторжения злоумышленника является история поимки специалистом по компьютерной безопасности Тсуомо Шимомура знаменитого хакера Кевина Митника. Вот один абзац из статьи , описывающей, как это произошло.

"В Рождество, когда Шимомура поехал на каникулах покататься на лыжах в Неваду, кто-то (мы уже знаем, кто именно) проник в его суперзащищенный домашний компьютер в Солана Бич, Калифорния, и начал копировать его файлы - сотни засекреченных файлов. Один магистрант из Центра Суперкомпьютеров в Сан Диего, где работал Шимомура, заметил изменения в системных "журнальных" (log) файлах и быстро сообразил, что происходит. Все это оказалось возможным благодаря тому, что Шимомура установил на свой компьютер программу, автоматически копирующую "журнальные" записи на дублирующий компьютер в Сан Диего. Студент позвонил Шимомуре, и тот помчался домой, чтобы провести инвентаризацию украденного."

Я не буду рассказывать здесь всю эту историю, нам важно отметить только то, что анализ протоколов работы системы послужил основой для успеха проведенного расследования неправомерных действий. Более подробное описание того, как проводятся такие расследования, вы сможете найти в статье . Но, чтобы суметь воспользоваться результатами протоколирования, надо понимать, как создаются протоколы, где они хранятся и что из них можно извлечь. Рассмотрению всех этих вопросов и посвящена настоящая статья.

Как формируются сообщения для протокола

Начать надо с того, что при создании программ на языке С программисты имеют возможность в необходимых случаях вставить вызов специальных функций openlog, setlogmask, syslog и closelog , включенных в стандартную библиотеку языка C. Эти функции служат для посылки сообщений о тех или иных событиях при выполнении программы специальному системному демону syslogd , ведущему системный протокол. Функция openlog устанавливает связь с демоном syslogd , функция syslog формирует конкретное сообщение для записи в протокол, а функция closelog закрывает открытую связь.

Сообщения, формируемые функцией syslog , состоят из нескольких полей, разделяемых пробелами. Каждое сообщение начинается с поля PRI , которое в закодированном виде содержит информацию о категории сообщения (facility) и уровне серьезности (severity level) или приоритете (priority) сообщения.

Категория (facility) - это информация о том, к какому классу относится данное сообщение. Категория кодируется числом от 0 до 23. Существуют следующие категории (они определяются в файле /usr/include/sys/syslog.h ):

Таблица 1.

Категория auth имеет устаревшее наименование-синоним security , которое не рекомендуется использовать. Кроме того, существует особая категория mark (не имеющая цифрового эквивалента), которая присваивается отдельным сообщениям, формируемым самим демоном syslogd . Эта категория используется для того, что бы помещать в протокол специальные отметки через заданный интервал времени (по умолчанию каждые 20 минут), что позволяет, например, узнать с 20-ти минутной точностью, когда же завис ваш компьютер.

Отметим, что категория не имеет вообще говоря никакого отношения к имени программы, которая шлет сообщения демону syslogd . Как говорится, всякое совпадение - чистая случайность. Более того, некоторые программы могут порождать сообщения разных категорий. Например, демон telnetd в случае неудачных попыток логирования порождает сообщения категории authpriv , а в других случаях относит свои сообщения к категории daemon .

Второй параметр, на основе которого формируется значение поля PRI , - это уровень или приоритет сообщения (priority), то есть информация о степени важности сообщения. Стандартно заданы 8 уровней важности (они тоже определены в файле /usr/include/sys/syslog.h ), которые кодируются числами от 0 до 7:

Таблица 2.

Поле PRI сообщения образуется следующим образом: числовое значение категории умножается на 8 и складывается с числовым значением приоритета, получившееся число заключается в угловые скобки и записывается в поле.

Вслед за полем PRI в сообщение включаются следующие поля:

• TIMESTAMP - время формирования сообщения,
• HOSTNAME - имя или IP-адрес хоста в десятичной записи,
• MSG - произвольный текст сообщения - некоторая текстовая (информационная) строка в коде US-ASCII (0x20 - 0x7e).

Время (местное!) записывается в формате: Feb 13 21:12:06. Если номер дня является однозначным числом, то перед ним ставится дополнительный пробел (не 0!). Обратите внимание на отсутствие года и зоны в дате, что необходимо учесть при организации долговременного хранения файлов протокола. Для того, чтобы время в сообщении было правильным, оно должно быть синхронизовано (например, по протоколу NTP).

Имя хоста включается в сообщение с той целью, чтобы не путать сообщения от разных хостов, поскольку, как будет показано ниже, ведение протоколов может вестись на одном из выделенных компьютеров в сети. В качестве имени хоста указывается простое сетевое имя компьютера, без указания домена. Если компьютер имеет несколько интерфейсов с различными IP-адресами, то в качестве имени или адреса хоста может быть использовано любое из них.

Текст сообщения (MSG ) обычно содержит этикетку (TAG ), указывающую на программу или процесс, выдавшую это сообщение, и тело сообщения (CONTENT ). Этикетка может содержать латинские буквы и цифры. Обычно в качестве этикетки используется простое имя программы, иногда дополненное идентификатором процесса, заключенным в квадратные скобки. Тело сообщения отделяется от этикетки специальными символами - в Linux это обычно двоеточие и пробел.

Обработка сообщений демоном syslogd

Все сообщения, формируемые отдельными программами с помощью функции syslog , отправляются через сокет /dev/log системному демону syslogd , который отвечает за обработку этих сообщений. Надо сказать, что вообще-то в системе запускаются два демона протоколирования - syslogd и klogd . Оба демона входят в состав пакета sysklogd , последнюю версию которого вы можете найти на сайте .

Демон klogd отвечает за протоколирование событий, происходящих в ядре системы. Необходимость в отдельном демоне klogd объясняется тем, что ядро не может использовать стандартную функцию syslog . Дело в том, что стандартные библиотеки (включая ту библиотеку, в которой находится функция syslog ) предназначены для использования только обычными приложениями. Поскольку ядро тоже нуждается в аналогичных функциях, в него включены свои библиотеки, недоступные приложениям. Поэтому ядро использует свой собственный механизм генерации сообщений. Демон klogd предназначен для организации обработки этих сообщений. В принципе он может производить такую обработку полностью самостоятельно и независимо от syslogd , например, записывая эти сообщения в файл, но в большинстве случаев используется принятая по умолчанию настройка klogd , при которой все сообщения от ядра пересылаются тому же демону syslogd .

Чтобы убедиться, что демоны syslogd и klogd запущены в вашей системе, выполните команду ps -ax | grep log . У меня эта команда дала следующий результат:

Обработка сообщений демоном syslogd состоит в том, что он постоянно отслеживает появление сообщений и сравнивает каждую пришедшую запись с правилами, которые находятся в файле /etc/syslog.conf . Каждое правило записывается в виде строки файла /etc/syslog.conf , состоящей из двух полей. Левое поле ("selector") задает один или несколько шаблонов, по которым отбираются сообщения. Шаблоны разделяются точкой с запятой (смотри приведенный ниже пример файла /etc/syslog.conf ). Правое поле ("действие") определяет порядок обработки отобранных сообщений. Поля разделены одним или несколькими пробелами или символами табуляции.

Каждый шаблон в поле "selector" имеет вид "категория.уровень" (то есть "facility.priority"). Значениями поля "категория" может служить:

• одно из перечисленных в таблице 1 условных наименований категорий,
• несколько таких наименований (в этом случае они разделяются запятыми)
• или символ * (что означает "все категории").

Значениями поля "уровень" может служить:

• одно из перечисленных в таблице 2 условных наименований уровня,
• символ * (записывать все сообщения данной категории, независимо от уровня),
• или слово none (не записывать сообщения данной категории).

Задание конкретного значения в поле "уровень" трактуется как "все значения данного уровня и выше". Если нужно записывать сообщения только одного уровня, то нужно перед задаваемым значением поставить знак равенства ("="). Если требуется записывать сообщения всех уровней, кроме указываемого, то перед наименованием уровня ставится восклицательный знак ("!"). Простановка двух этих знаков одновременно трактуется как "не записывать сообщения указанного уровня и выше".

Прописные и строчные буквы в поле "selector" не различаются. Можно также использовать числа (см. /usr/include/syslog.h). Кроме перечисленных в таблице 1 категорий можно указывать mark (регулярные временные метки) и security (устаревший синоним для auth ). Кроме перечисленных в таблице 2 значений приоритета можно использовать warn (синоним для warning ), error (синоним для err ), panic (синоним для emerg ).

Когда обнаруживается соответствие категории и уровня полученного сообщения с одним из шаблонов поля "selector" какой-то строки, syslogd обрабатывает запись в соответствии с действием, прописанным в поле "действие" данной строки.

В поле "действие" может стоять

• имя обычного файла (файла протокола), причем должен быть указан полный путь к файлу, начиная с корня "/", а если указанного файла не сущестует, syslogd создает его,
• название именованного канала (named pipe) - FIFO ; в этом случае перед именем ставится вертикальная черта ("|"), а сам канал должен быть создан перед запуском syslogd командой mkfifo ,
• указание на терминал или консоль (как на устройство: /dev/tty1),
• указание на удаленный хост (перед которым ставится символ @),
• или список пользователей (через запятую), на терминалы которых будет послано сообщение по данному правилу. Вместо списка пользователей можно поставить звездочку (*), что будет означать, что сообщения посылаются всем пользователям, работающим в данный момент в системе.

Чаще всего в поле "действие" все же стоит имя файла протокола. Причем, перед именем файла можно проставить знак минуса ("-"), что будет означать, что система может хранить файл в буфере кеша, а не сбрасывать его после записи каждого сообщения на диск. Это, конечно, ускоряет работу, особенно если в протокол записывается много больших сообщений, однако может привести к потере части сообщений при неожиданном крахе системы, то есть именно тогда, когда такие сообщения особенно нужны. В качестве устройства в поле "действие" можно указать также принтер - /dev/lp0. Такой вариант "действия" целесообразно применять в тех случаях, когда речь идет об особо важных системах. Протоколы, которые распечатаны, не могут быть стерты или изменены хакерами, так что это неплохое применение для старого матричного принтера.

Кроме строк с правилами в файле /etc/syslog.conf могут содержаться пустые строки и строки комментариев, начинающиеся символом #. Подробнее о структуре файла /etc/syslog.conf вы можете прочитать на man-страничке syslog.conf , где приведено достаточно много примеров записей правил в этом файле. Отметим, что при задании пар "категория.уровень" в файле syslog.conf нельзя использовать числовые значения, приведенные в таблицах 1 и 2, допускаются только их условные наименования.

Если сообщение соответствует шаблонам двух или более строк, оно будет обрабатываться по каждому из этих правил (т.е. обработка сообщения не прекращается при первом успехе). Это означает, что для одного сообщения может быть выполнено произвольное количество действий. Поэтому вы можете и записать сообщение в файл протокола и отправить его пользователю(лям) или на удаленный хост.

Кроме того, если в поле "selector" перечислены (через точку с запятой) несколько пар "категория.уровень", то последующие пары могут отменить действие предыдущих. Пример такой отмены вы видите в приводимом ниже листинге файла /etc/syslog.conf : в файл /var/log/messages записываются все сообщения, уровень которых равен или выше info, однако при этом пропускаются (не записываются) сообщения категорий mail, authpriv и cron.

Файл протокола /var/log/messages

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

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

• дата в стандартном текстовом формате (поле TIMESTAMP из сообщения syslog ),
• имя хоста (поле HOSTNAME из сообщения syslog )
• текст сообщения (поля TAG и CONTENT из сообщения syslog )

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

Sep 17 08:32:56 kos3 syslogd 1.4-0: restart. Сен 17 08:32:56 kos3 syslog: запуск syslogd succeeded Sep 17 08:32:56 kos3 kernel: klogd 1.4-0, log source = /proc/kmsg started. Sep 17 08:32:56 kos3 kernel: Inspecting /boot/System.map-2.4.2-2 Сен 17 08:32:56 kos3 syslog: запуск klogd succeeded

Параметр rotate число может находиться как среди глобальных, так и среди локальных параметров и определяет сколько старых версий надо хранить; если число равно 0, то архивные версии протокола не создаются.

Если задан параметр compress , то старые версии сжимаются с помощью gzip, а если указано nocompress - то не сжимаются. Параметр compresscmd позволяет указать, какая программа сжатия будет использоваться (по умолчанию - gzip), а uncompresscmd задает программу разжатия (по умолчанию - ungzip). compressoptions задает параметры программы сжатия; по умолчанию - "-9", т.е. максимальное сжатие для gzip. С помощью параметра compressext можно изменить суффикс для сжатых файлов, а параметр extension суффикс задает суффикс, добавляемый к именам файлов при ротации (перед суффиксом сжатия).

Среди ключевых слов, встречающихся в конфигурационных файлах, надо особо отметить слова postrotate и prerotate , которые служат открывающими скобками для включения в конфигурационные файлы скриптов оболочки shell. Все строки конфигурационного файла от строки postrotate до строки endscript исполняются как команды shell после процесса смены версии файла протокола. Соответственно, все строки от строки prerotate до строки endscript исполняются до выполнения ротации файлов протокола. С помощью этих скриптов можно организовать различные процедуры обработки файлов протоколов в процессе ротации.

С помощью других параметров конфигурационого файла можно переопределить права доступа к файлам протоколов (если этот параметр не задан, то используются аттрибуты старого файла протокола); указать, кому посылать сообщения об ошибках функционирования системы протоколирования; послать архивную копию журнала указанному пользователю; задать каталог, в который будут перемещаться протоколы во время смены версий (каталог должен находиться на том же физическом устройстве, что и /var/log) или задать список суффиксов-исключений для директории include . Подробное описание этих возможностей и параметров (а также тех, которые не были упомянуты) вы найдете по команде man logrotate .

Как уже было сказано, дополнительные конфигурационные файлы logrotate могут быть заданы в командной строке запуска скрипта. Можно указать произвольное число имен конфигурационных файлов или каталогов. Имена файлов и каталогов в этом списке разделяются просто пробелами. Порядок перечисления имен в списке имеет значение, поскольку параметры, указанные в следующем конфигурационном файле, перекрывают значение параметров, указанных в предыдущем файле. Порядок файлов в конфигурационной директории не определен.

Кроме того, в командной строке запуска можно указать следующие параметры:

• -d - отладочный режим, реальных изменений не производится,
• -f - производить изменения, даже если logrotate не видит необходимости - используется при изменениях в списке обрабатываемых журналов,
• man logwatch
• Mick Bauer, "Paranoid Penguin: swatch: Automated Log Monitoring for the Vigilant but Lazy"
• RFC 3164. C. Lonvick, The BSD Syslog Protocol, August 2001.
• RFC 3195. D. New, M. Rose, Reliable Delivery for syslog, November 2001.
• Пер. С.Лапшанский, "Демон следит за системой"
• Денис Колисниченко,

Демоном в Unix называют программу, которая работает "на заднем фоне" , не требуя управления с терминала, и предоставляя вам возможность выполнять "на переднем фоне" другую вашу работу. Демон может быть запущен либо другим процессом, например, одним из системных стартовых скриптов вообще без обращения к какому-либо управляющему терминалу, либо пользователем с какого-нибудь терминала, но и в этом случае демон "не захватывает" терминал на время своей работы. Естественно, возникает вопрос, какие программы-демоны необходимы в вашей системе, а какие можно и отключить.

Происхождение термина
В реальном (т.е., не-компьютерном) мире термином (или словом) "демон" обозначают духа (чаще всего - злого) или "внутренний голос". Стоит отметить, что оба эти значения применимы и к программам-демонам в Unix. Подобно мифологическим демонам, демоны в Unix прячутся где-то "за кулисами", стараясь остаться невидимыми. И, подобно внутреннему голосу или нашему подсознанию, они все время "начеку", всегда доступны, всегда могут "проявиться". Само слово "демон" представляет один из тех компьютерных акронимов , происхождение которого так же трудно выяснить, как и решить вопрос о том, была ли вначале курица или яйцо. Предположительно этот термин ("DAEMON") происходит от слов "Disk And Execution MONitor" program.

Задавшись целью изучить вопрос, поехал к одному батюшке, который пользуется компьютером с операционной системой Ubuntu. На всякий случай взял диск с виндой. Мало ли... Человек я прямолинейный, ходить вокруг да около не стал, сразу выдал всю информацию. Объяснял долго и подробно. К моему огромному счастью, воспринял он все это спокойно, местами, пока я рассказывал даже улыбался, особенно когда рассказал о причинах отказа мужа моей сестры от ubuntu. Батюшка, мужик нормальный, ему уже лет 50. Мы еще немного поговорили, точнее поговорил я, чтобы понять что он правильно усвоил то, что я сказал. После чего он мне сказал, дословно не помню, а записать на диктофон, голова не сообразила, поэтому опишу своими словами. В общем в том, что применяется этот термин в линукс, нет ничего страшного, главное вера в Бога.

Введение в сервисы

Демоны, ссылки на которых присутствуют /etc/init.d, призваны работать в Linux как сервисы или службы. Сервисы - это программы, которые запускаются и останавливаются через инициализационные скрипты, расположенные в каталоге /etc/init.d. Многие из этих сервисов запускаются на этапе загрузки системы. Утилита /sbin/service обеспечивает интерфейс (взаимодействие) пользователя с инициализационными скриптами. А сами эти скрипты обеспечивают интерфейс для управления сервисами, предоставляя пользователю опции для запуска, остановки, перезапуска, запроса состояния сервиса и выполнения других воздействий на сервис. К примеру, инициализационный скрипт сервиса httpd имеет следующие опции:

/sbin/service httpd Usage: httpd {start|stop|restart|condrestart|reload|status|fullstatus|graceful|help|configtest}

Вы можете просмотреть текущее состояние всех системных служб с помощью следующей опции утилиты service:

/sbin/service --status-all acpid (pid 2481) is running... anacron (pid 2647) is running... atd (pid 2657) is running... auditd (pid 2189) is running...

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

/sbin/chkconfig --list syslog syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off

Мы видим, что сервис syslog автоматически запускается при переходе на уровни 2, 3, 4 и 5. Для того, чтобы отключить его запуск на уровнях 3 и 4 (не очень хорошая идея, кстати), можно воспользоваться следующей опцией команды chkconfig:

/sbin/chkconfig --levels 34 syslog off

Утилита /usr/bin/system-config-services предоставляет графический интерфейс к системным службам, позволяющий просматривать и модифицировать их текущее состояние, а также задавать их запуск на различных уровнях исполнения

Давайте посмотрим, как эти сервисы и демоны отображаются в выводе команды ps. Вот небольшая выдержка:

UID PID PPID C STIME TTY TIME CMD root 1 0 0 23:36 ? 00:00:00 init root 2161 1 0 23:37 ? 00:00:00 auditd root 2177 1 0 23:37 ? 00:00:00 syslogd -m 0 root 2180 1 0 23:37 ? 00:00:00 klogd -x root 2207 1 0 23:37 ? 00:00:00 mcstransd root 2254 1 0 23:37 ? 00:00:00 rpc.statd root 2287 1 0 23:37 ? 00:00:00 rpc.idmapd root 2577 1 0 23:37 ? 00:00:00 crond root 2631 1 0 23:37 ? 00:00:00 /usr/sbin/atd root 2654 1 0 23:37 ? 00:00:00 rhnsd --interval 240

Что здесь интересно отметить (кроме того, конечно, что я сегодня слишком поздно засиделся за компьютером)? Для каждого из демонов идентификатор родительского процесса (PPID) равен 1. Это показывает, что демоны были запущены процессом init во время загрузки системы.

Более наглядно этот результат можно видеть в выводе такой полезной команды как "pstree", отображающей "дерево" процессов с указанием "родителей". Вот небольшой фрагмент из вывода pstree:

Init-+ |-NetworkManager---2*[{NetworkManager}] |-NetworkManagerD |-acpid |-atd |-auditd-+-python | `-{auditd} |-avahi-daemon---avahi-daemon |-bonobo-activati---{bonobo-activati} |-crond |-cupsd---cups-polld |-2* |-dbus-launch |-dhcdbd---dhclient

Подробнее о демонах в вашей системе

С вводной информацией покончили. Теперь давайте поговорим о системных демонах по отдельности и посмотрим, с какими из них можно безопасно экспериментировать. Отмечу еще раз, что в этой заметке идет речь о системе, использующей Red Hat Enterprise Linux Beta 2, в конфигурации рабочей станции. В зависимости от специфики вашей системы вы можете увидеть большее или меньшее число демонов, в том числе и таких, которые здесь не рассматриваются.

В описании каждого демона приведены ссылки на сайты, где вы сможете получить дополнительную информацию, но все же лучше всего начинать изучение демонов с просмотра соответствующих man-страниц. У O"Reilly имеется великолепный список команд Linux, перечисленных в алфавитном порядке, и в википедии (wikipedia.org) также приведены разделы по большинству из этих демонов. Еще не забудьте заглянуть в файлы README.

Это служба усовершенствованного интерфейса конфигурирования системы и управления энергопитанием (the Advanced Configuration and Power Interface - ACPI). ACPI - это открытый промышленный стандарт, определяющий действия по управлению системой, в первую очередь - определение устройств по принципу plug-and-play и управлению питанием, в том числе действия при запуске и остановке системы, а также при переводе ее в режим пониженного энергопотребления.

Вероятно не следует отключать эту службу, разве только в случае, когда вы делаете это в целях отладки или разрешения проблем с оборудованием.

Дополнительная информация: http://www.acpi.info

Если вы используете лэптоп, как делают многие в наши дни, то одна из проблем заключается в том, что, задавая какую-то работу демону cron, вы не всегда уверены в том, что ваш комьютер будет включен в то время, на которое назначено выполнение задания. Anacron (это название происходит от "anachronistic cron", то есть что-то вроде "устаревший cron") решает эту проблему путем проверки того, выполнялись ли задания в определенный промежуток времени. Например, anacron запустит задачу на выполнение, если она не запускалась заданное число дней.

В каких случаях вы можете отказаться от использования anacron? Если ваша система запущена постоянно.
Можете ли вы просто отказаться от запуска cron, если у вас запущен anacron? Нет; для anacron период перезапуска заданий может быть задан только в днях, а не в минутах и секундах.

Дополнительная информация:

Это демон расширенного управления питанием (the Advanced Power Management - APM) через драйвер в BIOS. Стандарт APM и демон apmd в настоящее время заменены на ACPI и acpid. Если ваша аппаратура поддерживает ACPI, вам нет нужды запускать apmd.

Это демон запуска заданий в указанное время. Если вы его не используете, вполне можно его отключить.

Этот демон автоматически монтирует диски и файловые системы, которые определены в конфигурационном файле. Использование этого демона делает более удобной работу со съемными дисками.

Дополнительная информация: http://freshmeat.net/projects/autofs

Система аудита в Linux состоит из средств протоколирования системных вызовов, работающих на уровне ядра, и средств сбора и просмотра логов, работающих в пространстве пользователя. Демон auditd осуществляет запись протоколируемых сообщений на диск. Auditd можно конфигурировать, что позволяет осуществлять контроль и управление тем, какая информация будет сохранена на диске.

Нужно ли держать auditd в запущенном состоянии? Информация из журналов протоколирования может быть очень полезной в настройке всего, что связано с безопасностью системы. Например, auditd используется в протоколировании событий SELinux. Существуют также такие утилиты, как aureport, которые позволяют вам просматривать журналы аудита. Вот пример отчета, созданного утилитой aureport:

Summary Report
======================

Range of time in logs: 11/28/2006 06:07:04.800 - 02/06/2007 21:10:09.957 Selected time for report: 12/31/1969 19:00:00 - 02/06/2007 21:10:09.957 Number of changes in configuration: 285 Number of changes to accounts, groups, or roles: 32 Number of logins: 145 Number of failed logins: 11 Number of users: 2 Number of terminals: 22 Number of host names: 11 Number of executables: 27 Number of files: 91 Number of AVC denials: 688 Number of MAC events: 12 Number of failed syscalls: 404 Number of anomaly events: 0 Number of responses to anomaly events: 0 Number of crypto events: 0 Number of process IDs: 14022 Number of events: 70694 Avahi-daemon и avahi-dnsconfd

Веб-сайт Avahi дает такое определение: "Avahi - это система, которая обеспечивает возможность обнаружения сервисов в локальной сети. Это означает, что после подключения вашего компьютера к локальной сети вы сможете мгновенно обнаружить доступные принтеры, увидеть, какие разделяемые ресурсы имеются в сети, узнать, с кем из других пользователей сети вы можете поговорить через chat и так далее". Avahi является реализацией протокола Zeroconf. А Zeroconf - это подход, который позволяет пользователям создавать IP-сети без специальных конфигурационных служб типа DNS-серверов.
Чаще всего avahi-daemon используется вместе с Rhythmbox, так что вы можете видеть музыкальные файлы, которые сделаны общедоступными для других. Если вы не предоставляете музыку или файлы с вашего компьютера в общий доступ, вы можете отключить этого демона.

Дополнительная информация: http://avahi.org , http://zeroconf.org

Bluetooth и демоны hidd и pand

Сами названия все объясняют. Запустите эти сервисы, если хотите использовать Bluetooth-устройства. Название реально запускаемого демона - hcid (Host Controller Interface Daemon).

Название демона hidd происходит от "the Bluetooth Human Interface Device Daemon". Он обеспечивает поддержку клавиатуры, мыши и трекбола по протоколу Bluetooth. А демон pand поддерживает подключение вашего компьютера к ethernet-сети посредством Bluetooth.

Дополнительная информация: http://www.bluetooth.com ,

Этот демон поддерживает the Common ISDN Application Programming Interface (интерфейс прикладного программирования для цифровой сети с интеграцией услуг). Его следует запускать, если вы подключаетесь к аппаратным ISDN-компонентам. Эта служба запускает capiinit.

Дополнительная информация: http://www.capi.org/pages

Нет, это не имеет никакого отношения к ночным передачам про инвестиции в недвижимость. Сервис conman (и демон conmand) поддерживают управление консолями. Обеспечивается поддержка нескольких консольных устройств и одновременная работа пользователей, поддержка локальных последовательных устройств и удаленных терминальных серверов (по протоколу telnet). Если вы управляете несколькими серверами, вам может потребоваться conman.

Дополнительная информация: http://home.gna.org/conman/
cpuspeed

Этот демон изменяет скорость работы центрального процессора с целью снижения энергопотребления. Если ЦПУ простаивает, можно снизить скорость, тем самым понижая затраты энергии, а для повышения производительности прихоодится энергопотребление увеличивать. Если вы работаете на портативном компьютере, имеет смысл запустить cpuspeed.

Дополнительная информация: http://carlthompson.net/Software/CPUSpeed
crond

Этот демон служит для автоматического запуска задач. Это необходимо во всех Linux и Unix-системах. Не останавливайте и не отключайте эту службу.

Дополнительная информация: http://www.unixgeeks.org/security/newbie/unix/cron-1.html , http://www.linuxhelp.net/guides/cron/

CUPS and cups-config-daemon

Это демон общей службы печати UNIX (the "Common UNIX Printing Solution"). Как следует уже из названия, это система печати, которая обеспечивает работу с различными форматами файлов и различными типами принтеров. Если вы хотите печатать, пусть этот демон работает в вашей системе.

Дополнительная информация: http://www.cups.org , http://www.easysw.com/cups/index.php

Название этого демона является аббревиатурой от "DHcp Client D-Bus Daemon". Ресурс The Free DeskTop wiki дает следующее определение:

D-Bus - это система шины сообщений, простой способ общения (или взаимодействия) приложений между собой. В дополнение к межпроцессному взаимодействию (interprocess communication) D-Bus помогает координировать жизненный цикл процесса; она обеспечивает простую и надежную реализацию в программном коде возможности запуска "отдельного экземпляра" приложения или демона, что позволяет запускать приложения и демоны по требованию, тогда, когда возникает потребность в соответствующих сервисах.

Нужно ли вам запускть этого демона? Если ваша система работает в сети (а как же иначе?), в особенности если вы перемещаетесь между сетями (например, переключаетесь из проводной сети в беспроводную), то вы должны запускать NetworkManager (мы рассмотрим NetworkManager чуть ниже).

Демон dhcdbd обеспечивает интерфейс к D-Bus для dhclient, DHCP-клиента от ISC. Это дает возможность NetworkManager-у обращаться к dhclient-у и управлять им.

Дополнительная информация: http://www.freedesktop.org/wiki/Software/dbus

Этот демон дает вам возможность использовать мышь в консольных (text-based) приложениях, таких как файловый менеджер Midnight Commander. Это может оказаться полезным, если вы часто работаете в консоли; в противном случае, то есть если вы все время работаете через систему X Window, gpmd вам может никогда не понадобиться.

Нет, это не злобный компьютер из фильма "Космическая одиссея 2001". В данном контексте HAL означает "Hardware Abstraction Layer" - "уровень абстрагирования от оборудования". Демон HAL собирает (с помощью ядра и самих устройств) информацию об аппаратных устройствах и предоставляет ее приложениям в согласованном виде.

Не отключайте эту службу. Ее используют многие приложения.

Дополнительная информация: "Desktop and hardware configuration," by David Zeuthen

Этот демон обеспечивает поддержку системы HP Linux Imaging and Printing (HPLIP), используемой для печати, сканирования и обработки факсов на струйных и лазерных устройствах от HP. HPLIP взаимодействует с CUPS, обеспечивая для последней доступ к устройствам от HP.

Дополнительная информация:

Это демон для реляционных баз данных на Java. Свое название он унаследовал от проекта Hypersonic SQL, который более не поддерживается. hsqldb широко используется в проектах с открытыми кодами, таких как OpenOffice.org, а также в демонстарционных программах, так как он может исполняется полностью в оперативной памяти. За счет чего быстро работает. Надо ли вам запускать эту службу? Только если вы запускаете какие-то программы, использующие ее. Но вообще-то это очень полезный инструмент и, если вы с ним не знакомы, стоит на него посмотреть.

Дополнительная информация: http://hsqldb.org , http://dba.openoffice.org

Веб-серве Apache. Используется почти на 60% всех веб-сайтов. Если вы хотите поддерживать веб-сайт, вы запускаете Apache. Нужно ли еще что-то говорить?

Дополнительная информация: http://httpd.apache.org

ip6tables и iptables

Это файерволы или межсетевые экраны. Согласно Википедиа, "Межсетевой экран или брандмауэр (жарг. файрвол или файервол от англ. firewall) - комплекс аппаратных и/или программных средств, осуществляющий контроль и фильтрацию проходящих через него сетевых пакетов на различных уровнях модели OSI в соответствии с заданными правилами. Основной задачей сетевого экрана является защита компьютерных сетей или отдельных узлов от несанкционированного доступа."

Iptables работает путем задания правил фильтрации пакетов IPv4 в виде таблицы ядра. Входящие и исходящие пакеты проверяются на соответствие этим правилам и те из них, которые не удовлетворяют правилам, блокируются. Ip6tables делает то же самое по отношению к пакетам IPv6.

Которую из двух служб необходимо запускать? Обе. Всегда. Сеть - это опасная штука!

Дополнительная информация: http://www.netfilter.org , http://www.ipv6.org

IrDA (Infrared Data Association) - это промышленный стандарт для беспроводной связи между устройствами по инфракрасному каналу. Большинство лэптопов оборудовано инфракрасным передатчиком, соответствующим стандарту IrDA. Запускать эту службу нужно только в том случае, если вы собираетесь организовывать связь с другими устройствами по инфракрасному каналу.

Дополнительная информация:

irqbalance

Этот демон занимается распределением аппаратных прерываний между ЦПУ в мультипроцессорных SMP (symmetric processor) архитектурах с целью повышения производительности.

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

Дополнительная информация: http://www.irqbalance.org

Это очень полезный демон. Он работает во время загрузки и проверяет, какие аппаратные устройства были добавлены в или удалены из системы. Имеет смысл запускать kudzu во время загрузки, даже если вы не планируете часто добавлять или удалять устройства. Потому что рано или поздно вы равно окажетесь в ситуации, когда добавите какое-то устройство и будете ожидать, что система его обнаружит. К тому же, поскольку kudzu отрабатывает на этапе загрузки, это не оказывает отрицательного влияния на производительность системы.

Дополнительная информация: http://fedora.redhat.com/projects/additional-projects/kudzu

Этот демон получил свое название от Lan Information Server. Lisa обеспечивает функционал, подобный тому, который предоставляет служба "Мое сетевое окружение" (Network Neighborhood) в MS-Windows, то есть обеспечивает доступ к серверам вашей локальной сети, включая сервера CIFS (Common Internet File Systems). lisa работает по протоколам TCP/IP, рассылая ICMP-запросы по IP-адресам в заданном диапазоне, который вы указали в конфигурационном файле, и ожидая, какие компьютеры откликнутся.

Дополнительная информация: http://docs.kde.org/stable/en/kdenetwork/lisa , http://docs.kde.org/userguide/networking-with-windows.html ,

lm_sensors

Этот демон обеспечивает мониторинг температур и напряжений на материнской плате. Для работы системы мониторинга необходимо наличие соответствующих датчиков в аппаратуре. Запускать этот демон имеет смысл только в том случае, если обеспечена аппаратная поддержка. Вероятно не стоит запускать его на обычных рабочих станциях. Он скорее нужен на hi-end-серверах, выполняющих критически важные функции.

Дополнительная информация: http://www.lm-sensors.org , http://freshmeat.net/projects/lm_sensors

mcstrans

SELinux Context Translation System Daemon. Этот демон преобразует информацию контекста безопасности (security context informartion) в форму, приспособленную для восприятия человеком. Вы можете остановить этот демон, но в таком случае вы увидите, что изменится информация SELinux, выдаваемая по команде ls -Z. Например, при запущенном демоне вы увидите:

Ls -Z -rw-r--r-- jsmith jsmith user_u:object_r:user_home_t bookmarks.html drwxr-xr-x jsmith jsmith user_u:object_r:user_home_t Desktop -r-xr-xr-x jsmith jsmith user_u:object_r:user_home_t hello -r--r--r-- jsmith jsmith user_u:object_r:user_home_t hello.c

А если демон остановлен, вы увидите следующее:

Ls -Z -rw-r--r-- jsmith jsmith user_u:object_r:user_home_t:s0 bookmarks.html drwxr-xr-x jsmith jsmith user_u:object_r:user_home_t:s0 Desktop -r-xr-xr-x jsmith jsmith user_u:object_r:user_home_t:s0 hello -r--r--r-- jsmith jsmith user_u:object_r:user_home_t:s0 hello.c

Обратите внимание на то, что если демон остановлен, отображается значение контекста безопасности "s0". Mctrans в данном случае обнулил контекст. Другие значения контекста безопасности преобразуются из буквенно-цифровых значений в их названия.

Дополнительная информация: http://fedoraproject.org/wiki/SELinux/Understanding , http://danwalsh.livejournal.com

mdmonitor и mdmpd

Эти два демона используются в системах хранения данных с RAID-массивами (redundant array of inexpensive/independent disks). Mdmonitor запускает, останавливает и перезапускает mdadm (multipath device monitoring and management) - программную службу мониторинга и управления RAID. Запускать эту службу нужно только в том случае, если в вашей системе имеются RAID-устройства.

Дополнительная информация: http://www.linuxdevcenter.com/pub/a/linux/...12/05/RAID.html

messagebus

Это демон системной шины сообщений D-BUS. Он рассылает широковещательные сообщения о системных событиях и таких событиях, как изменения в очереди печати, или добавление или удаление устройств (заметьте, что это не то же самое, что делает kudzu, поскольку такие события могут иметь место в любой момент работы системы, а не только на этапе загрузки).

Дополнительная информация: http://www.freedesktop.org/software/dbus

netplugd и ifplugd

Эти демоны производят настройку Ethernet-устройств в том случае, когда происходит подключение сетевого кабеля, и отключают эти устройства когда кабель отсоединяется. Когда вам это нужно? Например, на лэптопах, чтобы ваши сетевые подключения восстанавливались только на то время, когда подсоединен сетевой кабель.

Отметим, что поддержка netplugd была прекращена, сейчас вместо него используется ifplugd.

Дополнительная информация: http://0pointer.de/lennart/projects/ifplugd

NetworkManager и NetworkManagerDispatcher

Демон NetworkManager автоматизирует переключение между сетевыми соединениями. Этот демон полезен для пользователей лэптопов, которые переключаются между беспроводными WiFi-соединениями и соединениями по Ethernet. Демон NetworkManagerDispatcher автоматически запускает скрипты для выполнения необходимых операций (например, скрипты для задания специфических направлений маршрутизации пакетов), когда NetworkManager изменяет состояние сети.

Дополнительная информация: http://www.gnome.org/projects/NetworkManager

Это демон, который выполняет функции сервера доменных имен (Domain Name Server). Вы должны его запускать только в том случае, если ваш компьютер является DNS-сервером для вашей сети.

Дополнительная информация: http://www.dns.net/dnsrd

Демон nfsd осуществляет поддержку протокола сетевых коммуникаций nfs, который служит для предоставления доступа к сетевым ресурсам в TCP/IP-сетях. Вам нужно его запускать, если вы предоставляете доступ другим пользователям к своим файловым системам по протоколу nfs.

Дополнительная информация:

Это демон кэширования для службы имен. Он поддерживает таблицу групп и паролей для запущенных программ, а затем выдает запомненный результат по следующему запросу тех служб, которые иначе работают слишком медленно, например, NIS или LDAP. Если у вас запущены эти службы, вам следует запустить и nscd.

Это демон, который поддерживает протокол сетевой службы времени (Network Time Protocol). Он устанавливает системное время и синхронизуирует его со временем, задаваемым Интернет-серверами, поддерживающими эталонное время. Если ваша система подключена к Интернет (а разве нет?), то этот демон будет следить за правильностью установки системного времени на вашем компьютере.

Дополнительная информация: http://www.ntp.org

Демон oddjobd обеспечивает работу службы com.redhat.oddjob на системной шине. Каждая возможность, предоставляемая oddjobd, предоставляется как отдельный метод D-Bus. Oddjobd обеспечивает поддержку выполнения привелигированных операций для непривелигированных приложений.

Запускать этот демон следует только в том случае, если вы используете приложения, которым он необходим, такие как Conga.

Дополнительная информация: http://people.redhat.com/nalin/oddjob/oddjob.html ,

Этот демон поддерживает виртуальные частные стеи (virtual private networks, VPNs). В стартовом скрипте этого демона сказано следующее:

OpenVPN - это надежное и в высшей степени гибкое приложение для обеспечения туннелирования, которое использует возможности шифрования, аутентификации и сертификации, заложенные в библиотеке OpenSSL, для организации безопасного тоннеля в IP-сети через один UDP порт.

Если ваша система является узлом VPN, то вам, вероятно, следует запустить OpenVPN.

Дополнительная информация: http://openvpn.net

pcscd (PC/SC Smart Card Daemon) - демон для pcsc-lite (программное обеспечение для доступа к смарт-картам) и (основанной на java) среде разработки MuscleCard. Он обеспечивает обмен данными со считывателями смарт-карт и самими смарт-картами.

(Смарт-карта - это небольшая плата, в которую встроен либо модуль памяти, дибо микропроцессор с модулем памяти. А Muscle расшифровывается как Movement for the Use of Smart Cards in a Linux Environment (движение за использование смарт-карт в среде Linux).

Дополнительная информация: http://www.smartcardalliance.org , http://pcsclite.alioth.debian.org , http://www.linuxnet.com/musclecard/index.html

Демон portmapper управляет соединениями по протоколу RPC (remote procedure call - удаленный вызов процедур). Он преобразует номера RPC-программ в номера портов протокола TCP/IP (или UDP/IP). Чаще всего portmapper используется службами NFS и NIS.

Так что, если ваша система зависит от NIS или NFS, не отключайте демон portmap.

Дополнительная информация: http://www.linux-nis.org/nis-howto/HOWTO/portmapper.html

Это агент передачи (транспортировки) почты. Если ваша система не является ретранслятором в системе электронной почты, вам не требуется запускать эту службу.

Дополнительная информация: http://www.postfix.org

Этот демон (the router discovery daemon) находит маршруты в локальной подсети. Он запускается на этапе загрузки для того, чтобы внести в таблицы маршрутизации маршруты, выбираемые по умолчанию.

Дополнительная информация: http://www.informit.com/articles/article.asp?p=23951&rl=1

restorecond

Это демон из SELinux. Restorecond отслеживает создание файлов (для файлов, перечисленных в /etc/selinux/restorecond.conf) и следит за тем, чтобы файлы имели правильный файловый контекст, соответствующий установленой политике (policy), а также определяет файловый контекст SELinux, используемый по умолчанию.

Не отключайте эту службу. Она необходима для SELinux.

Дополнительная информация: http://fedoraproject.org/wiki/SELinux/Understanding , http://danwalsh.livejournal.com/

Этот демон периодически проверяет, какие операции должны быть выполнены через сетевой интерфейс Red Hat (Red Hat Network web interface), и запускает их. Эти операции включают инсталляцию, удаление или обновление программного обеспечения, перезагрузку системы, установку конфигурационных файлов и так далее.

Дополнительная информация: https://www.redhat.com/rhn/

rpcgssd, rpcidmapd и rpcsvcgssd

Демоны rpcgssd и rpcsvcgssd служат для обеспечения безопасности при работе через RPC. Rpcidmapd преобразует имена пользователей в номера UID и GID.

Если вы используете NFS или NIS, эти демоны у вас должны быть запущены.

Дополнительная информация:

readahead_early и readahead_later

Демон readahead обеспечивает загрузку в память программ, используемых при старте системы, до того, как они будут использоваться, что сокращает время начальной загрузки.

saslauthd

Это демон сервера аутентификации SASL. SASL (Simple Authentication and Security Layer) добавляет возможности аутентификации в протоколы, основанные на удаленных соединениях.

Дополнительная информация: http://asg.web.cmu.edu/sasl

sendmail

Это сервер SMTP (Simple Mail Transfer Protocol). Sendmail пересылает почту от одной системы к другой, то есть является агентом передачи почты (Mail Transport Agent). Если вы используете такие почтовые программы как Thunderbird или Evolution, вам не требуется запускать sendmail.

Дополнительная информация: http://www.sendmail.org

setroubleshoot

Это демон разрешения проблем SELinux. Setroubleshooter - одно недавних великолепных новшевств в SELinux. Setroubleshooter обеспечивает в реальном времени обратную связь с пользователями при отказах SELInux AVC (Access Vector Cache). Причем эта обратная связь предоставляется в удобном формате.

Дополнительная информация: https://hosted.fedoraproject.org/projects/setroubleshoot

Этот демон следит за показаниями датчиков SMART (Self-Monitoring, Analysis and Reporting Technology), устанавливаемых во многих типах дисководов, например, в жестких дисках типа SCSI-3. Демон обеспечивает наблюдение за нормальной работой таких устройств и выполняет самотестирование. Если ваше оборудование поддерживает технологию SMART, нужно запускать эту службу.

Дополнительная информация:

spamassassin

Этот демон использует программу Apache SpamAssassin для проверки почты на наличие спама. Он обычно запускается совместно с сервером доставки почты (a mail deleivery agent (MDA) server). Если вы используете клиентские программы вроде Thunderbird или Evolution для доступа к вашей почте, вам не требуется запускать spamassassin.

Дополнительная информация: http://spamassassin.apache.org

Это демон для протокола open ssh. Ssh заменяет небезопасные программы rsh и rlogin и обеспечивает шифрование соединений между хостами в небезопасных сетях. Если вы используете соединения с другими системами через открытый Интернет, вы должны использовать ssh и запускать этот демон.

Дополнительная информация: http://www.ssh.com , http://www.openssh.com

syslog - это стандартная система протоколирования для Linux. Не отключайте её.

Дополнительная информация: http://www.syslog.org

Этот демон является частью пакета Samba. Он дает возможность пользователям домена Windows подключаться как пользователям Unix к Unix-серверам. Запускать этот демон следует в том случае, когда вы имеете дело со смешанной сетью, состоящей из Windows и Linux/Unix-компьютеров.

Дополнительная информация: http://www.samba.org/samba/docs/man/Samba-...on/winbind.html , http://www.samba.org

Это сервер шрифтов (font server). Этот демон загружает шрифты в память для того, чтобы графические приложения работали быстрее, чем в том случае, когда они вынуждены загружать шрифты с жесткого диска. Эту службу надо запускать для повышения производительности приложений в вашей системе.

Дополнительная информация: http://linuxreviews.org/howtos/xfree/xfs

Эта служба связывает NIS-клиента с доменом NIS. Буквы "yp" в ее названии произошли от "yellow pages," поскольку каталоги NIS подобны телефонным справочникам "желтые страницы". Запускать эту службу нужно только в том случае, если ваша система использует NIS (Network Information Service) для организации доступа к пользовательским бюджетам и системным именам.

Дополнительная информация: http://www.linux-nis.org

yum-updatesd

yum-updatesd отслеживает появление обновлений программного обеспечения и рассылает извещения об этих обновлениях по электронной почте, d-bus или в виде системных сообщений, а также может произвести автоматическое обновление ПО. D-bus-сообщения принимаются утилитой "puplet" (package updater), которая информирует пользователя о наличии обновления, а также позволяет установить это обновление.

Дополнительная информация: http://linux.duke.edu/projects/yum , http://www.redhat.com/magazine/024oct06/features/fc62

Благодарю ZOOL за предоставленную информацию на сайте http://www.centrlan.ru/node/17929

Источник не указан

Размещение перед именем файла символа канала (|) позволит использовать fifo (first in - first out, первый пришел - первый вышел) или именованный канал (named pipe) в качестве приемника для сообщений. Прежде чем запускать (или перезапускать) syslogd, необходимо создать fifo при помощи команды mkfifo. Иногда fifo используются для отладки.

Терминал и консоль

Терминал, такой как /dev/console.

Удаленная машина

Чтобы сообщения пересылались на другой хост, поместите перед именем хоста символ (@). Обратите внимание, что сообщения не пересылаются с принимающего хоста. (для работы данного назначения на клиенте и сервере в файле /etc/services должна быть прописана строчка syslog 514/udp , и открыт UTP-порт 514)

Список пользователей

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

Все зарегистрированные пользователи

Чтобы известить всех зарегистрированных пользователей при помощи команды wall, используйте символ звездочки (*).

Пример несложного syslog.conf:

# Все сообщения ядра выдавать на консоль. #kern.* /dev/console # Все логи уровня info или выше, кроме сообщений электронной почты, а так же # не логировать сообщения аутентификации и сообщений демона cron! *.info;mail.none;authpriv.none;cron.none /var/log/messages # Записывать в отдельный файл сообщения, содержащие конфиденциальную # информацию аутентификации, независимо от их уровня. authpriv.* /var/log/secure # Все сообщения почтовой системы тоже записывать в отдельный файл. mail.* -/var/log/maillog # Логировать сообщения планировщика в файл /var/log/cron cron.* /var/log/cron # Сообщения о чрезвычайных ситуациях должны немедленно получить # все пользователи системы *.emerg * # Сохранять сообщения новостей уровня crit и выше в отдельный файл. uucp,news.crit /var/log/spooler # Сохранять сообщения загрузки в boot.log local7.* /var/log/boot.log

Как и во многих конфигурационных файлах, синтаксис следующий:

• строки, начинающиеся с #, и пустые строки игнорируются.
• Символ * может использоваться для указания всех категорий или всех приоритетов.
• Специальное ключевое слово none указывает, что журналирование для этой категории не должно быть выполнено для этого действия.
• Дефис перед именем файла (как -/var/log/maillog в этом примере) указывает, что после каждой записи журнал не должен синхронизироваться. В случае аварии системы вы можете потерять информацию, но отключение синхронизации позволит повысить производительность.

В синтаксисе конфигурационного файла можно поставить перед приоритетом знак! , чтобы показать, что действие не должно применяться, начиная с этого уровня и выше . Подобным образом, перед приоритетом можно поставить знак = , чтобы показать, что правило применяется только к этому уровню, или != , чтобы показать, что правило применяется ко всем уровням, кроме этого. Ниже показано несколько примеров (man syslog.conf можно найти множество других примеров):

# Посылать все сообщения ядра в /var/log/kernel. # Посылать все сообщения уровня critical и higher на удаленную машину sysloger и на консоль # Посыласть все сообщения уровня info, notice и warning в /var/log/kernel-info # kern.* /var/log/kernel kern.crit @sysloger kern.crit /dev/console kern.info;kern.!err /var/log/kernel-info # Посылать все сообщения почтовой системы, кроме уровня info в /var/log/mail. mail.*;mail.!=info /var/log/mail

Я постарался максимально понятно работу syslogd показать на схеме:

Запуск демона syslogd

Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog , однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт - начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian) .

Вот некоторые возможные параметры запуска демона syslogd:

• -a /folder/socket - указание дополнительного слушающего сокета (не забудьте предварительно создать сокет)
• -d - отладочный режим. При этом демон не переходит в фоновый режим и выдает все сообщения на текущий терминал;
• -f имя-конфигурационного-файла . Задает имя альтернативного конфигурационного файла, который будет использоваться вместо заданного по умолчанию /etc/syslog.conf;
• -l список-хостов - задание списка хостов, имена которых не должны записываться с указанием полного доменного имени (FQDN - Full Qwalified Domain Name);
• -m минут - запущенный без этой опции sysklogd через каждые 20 минут записывает в протокол сообщения категории mark (временные отметки). С помощью опции -m можно либо изменить интервал между отметками, либо вовсе отменить выдачу таких сообщений;
• -p socket - задание альтернативного сокета UNIX (вместо прослушиваемого по умолчанию /dev/log);
• -r - разрешение принимать сообщения от удаленных хостов;
• -x - запрет определения имени хоста по его адресу для предотвращения зависания при работе на одном хосте с сервером DNS.
• -v - показать версию и закончить работу

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

С помощью команды
kill -SIGNAL `cat /var/run/syslogd.pid`

можно послать демону syslogd один из следующих сигналов: SIGHUP - перезапуск демона; SIGTERM - завершение работы; SIGUSR1 - включить/выключить режим отладки.

Вообще-то в системе запускаются два демона протоколирования - syslogd и klogd . Оба демона входят в состав пакета sysklogd .

Демон klogd отвечает за журналирование событий, происходящих в ядре системы . Необходимость в отдельном демоне klogd объясняется тем, что ядро не может использовать стандартную функцию syslog. Дело в том, что стандартные библиотеки С (включая ту библиотеку, в которой находится функция syslog) предназначены для использования только обычными приложениями . Поскольку ядро тоже нуждается в функциях журналирования, в него включены свои библиотеки, недоступные приложениям. Поэтому ядро использует свой собственный механизм генерации сообщений.

Демон klogd предназначен для организации обработки этих сообщений. В принципе он может производить такую обработку полностью самостоятельно и независимо от syslogd, например, записывая эти сообщения в файл, но в большинстве случаев используется принятая по умолчанию настройка klogd, при которой все сообщения от ядра пересылаются тому же демону syslogd.

Автоматическая ротация (обновление заполненных файлов) и архивирование журналов

Со временем, файл журнала имеет свойство увеличиваться, особенно при интенсивной работе какого-либо сервиса. Соответственно, необходимо иметь возможность контролировать размер журналов. Это делается при помощи команды logrotate , которая обычно выполняется демоном cron . О работе cron я расскажу в следующих статьях. Главная цель команды logrotate состоит в том, чтобы периодически создавать резервные копии журналов и создавать новые чистые журналы. Сохраняется несколько поколений журналов и, когда завершается срок жизни журнала последнего поколения, он может быть заархивирован (сжат). Результат может быть отправлен по почте, например, ответственному за ведение архивов.

Для определения порядка ротации и архивирования журналов используется конфигурационный файл /etc/logrotate.conf . Для разных журналов можно задать разную периодичность, например, ежедневно, еженедельно или ежемесячно, кроме того, можно регулировать количество накапливаемых поколений, а также указать, будут ли копии архивов отправляться ответственному за ведение архивов и, если будут, когда. Ниже показан пример файла /etc/logrotate.conf:

# сначала заданы параметры "по-умолчанию" (глобальные опции) # обновлять файлы журнала еженедельно weekly # хранить архив логов за 4 последние недели rotate 4 # создавать новый (пустой) файл после ротации (обновления) create # раскомментируйте, если желаете, чтобы сохраненные файлы сжимались #compress # включить настройки ротации из указанного каталога include /etc/logrotate.d # не хранить wtmp, или btmp -- настройки ротации данных журналов следующие: /var/log/wtmp { missingok monthly create 0664 root utmp rotate 1 } /var/log/btmp { missingok monthly create 0664 root utmp rotate 1 } # специфичные системные журналы могут быть настроены ниже

Глобальные опции размещаются в начале файла logrotate.conf . Они используются по умолчанию, если где-то в другом месте не задано ничего более определенного. В примере ротация журналов происходит еженедельно и резервные копии сохраняются в течение четырех недель. Как только производится ротация журнала, на месте старого журнала автоматически создается новый. Файл logrotate.conf может содержать спецификации из других файлов. Так, в него включаются все файлы из каталога /etc/logrotate.d.

В этом примере также содержатся специальные правила для /var/log/wtmp и /var/log/btmp (хранящие информацию о удачных и неудачных попытках входя в систему), ротация которых происходит ежемесячно. Если файлы отсутствуют, сообщение об ошибке не выдается. Создается новый файл и сохраняется только одна резервная копия.

В этом примере по достижении резервной копией последнего поколения она удаляется, поскольку не определено, что следует с ней делать.

Резервные копии журналов могут также создаваться, когда журналы достигают определенного размера, и могут быть созданы скрипты из наборов команд для выполнения до или после операции резервного копирования. Пример:

/var/log/messages { rotate 5 mail logadmin@sysloger size 100k postrotate /usr/bin/killall -HUP syslogd endscript }

В этом примере ротация /var/log/messages производится по достижении им размера 100 КБ. Накапливается пять резервных копий, и когда истекает срок жизни самой старой резервной копии, она отсылается по почте на адрес logadmin@sysloger. Командное слово postrotate включает скрипт, перезапускающий демон syslogd после завершения ротации путем отправки сигнала HUP. Командное слово endscript необходимо для завершения скрипта, а также в случае, если имеется скрипт prerotate. Более полную информацию см. в страницах руководства man для logrotate.

Параметры , задаваемые в конфигурационном файле logrotate.conf:

• compress | nocompress (старые версии сжимаются или не сжимаются с помощью gzip)
• compresscmd (задает программу сжатия, по умолчанию - gzip)
• uncompresscmd (задает программу разжатия, по умолчанию - ungzip)
• compressext (задает суффикс для сжатых файлов)
• compressoptions (задает параметры программы сжатия; по умолчанию - "-9", т.е. максимальное сжатие для gzip)
• copytruncate | nocopytruncate (обычно старая версия переименовывается и создается новая версия журнала; при задании этого параметра logrotate копирует журнал в новый файл, а затем обрезает старый; используется, если программа, создающая журнал, не умеет его закрывать; теряются записи, сделанные в промежутке между копированием и обрезанием; а поможет ли, если создающая журнал программа вместо режима append просто пишет в файл, используя внутренний указатель?)
• create [права-доступа владелец группа] | nocreate (сразу после переименования старой версии журнала и до вызова postrotate создается новый журнал с указанными атрибутами - права доступа задаются в восьмеричном виде, как в chmod.2; если атрибуты не указаны, то берутся от старого журнала)
• daily (смена версий в серии происходит ежедневно)
• delaycompress | nodelaycompress (некоторые программы не сразу закрывают журнал, в этом случае сжатие надо отложить до следующего цикла)
• errors email (кому направлять сообщения об ошибках)
• extension суффикс (задается суффикс, добавляемый к именам файлов при ротации перед суффиксом сжатия)
• ifempty | notifempty (смена версий даже если файл пуст; действует по умолчанию)
• include имя-файла | имя-директории (текстуально подставить файл или все файлы из указанной директории; не включаются поддиректории, специальные файлы и файлы с суффиксами из списка исключений; нельзя использовать внутри секции)
• mail адрес | nomail (когда смена версий приводит к необходимости удалить старый журнал, то послать его по указанному адресу)
• mailfirst (посылать не удаляемую версию журнала, а первую)
• maillast (посылать удаляемую версию журнала; действует по умолчанию)
• missingok | nomissingok (не посылать сообщения об ошибке, если журнал отсутствует)
• monthly (смена версий происходит ежемесячно)
• olddir директория | noolddir (во время смены версий журнал перемещается в указанную директорию; д.б. на том же физическом устройстве)
• postrotate (все дальнейшие строчки до строки endscript исполняются как команды shell после процесса смены версии)
• prerotate (все дальнейшие строчки до строки endscript исполняются перед процессом смены версии)
• rotate число (сколько старых версий хранить; если 0, то ни одной)
• size байт (смена версии происходит, если размер журнала превысил указанное число; можно использовать суффиксы "k" - килобайт - и "M" - мегабайт)
• sharedscripts | nosharedscripts (выполнять команды prerotate и postrotate только один раз для всех файлов, описанных в секции)
• tabooext [+] список-суффиксов (задание списка суффиксов-исключений для include; если указан знак "плюс", то дополнение, иначе замена; по умолчанию: .rpmorig, .rpmsave, .rpmnew, ",v", .swp и "~")
• weekly (смена версий происходит еженедельно)

Изучение и мониторинг журналов

Записи в журналах обычно содержат метку времени, имя хоста, на котором выполняется описываемый процесс, и имя процесса. Просматривать журналы можно при помощи программы постраничного вывода, например, less , искать определенные записи (например, сообщения ядра от определенного демона) можно при помощи команды grep :

# less /var/log/messages # grep "ppp" /var/log/messages | tail Dec 17 16:34:25 proxy pppd: Connection terminated. Dec 17 16:34:25 proxy pppd: Exit. Dec 17 16:35:57 proxy pppd: LCP terminated by peer (^P]kV^@

Компьютер может работать не постоянно и выключаться, допустим на ночь. Поэтому в /var/log/messages записи хранятся циклически от запуска компьютера к выключению, это можно заметить по сообщениям:

Дек 17 08:32:56 syslog-server syslogd 1.4-0: restart. Дек 17 08:32:56 syslog-server syslog: запуск syslogd succeeded Дек 17 08:32:56 syslog-server kernel: klogd 1.4-0, log source = /proc/kmsg started. Дек 17 08:32:56 syslog-server syslog: запуск klogd succeeded

Dec 17 08:32:56 syslog-server kernel: Kernel command line: auto BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz-2.4.2-2 Dec 17 08:32:56 syslog-server kernel: Memory: 125652k/130560k available (1365k kernel code, 4200k reserved, 92k data, 236k init, 0k highmem) Dec 17 08:32:56 syslog-server kernel: CPU: Intel(R) Pentium(R) 4 CPU 1.60GHz stepping 02

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

Иногда может возникать необходимость мониторинга системных журналов с целью поиска текущих событий. Например, можно попробовать поймать редко случающееся событие в тот момент, когда оно произошло. В таком случае можно использовать команду tail с опцией -f для отслеживания содержимого системного журнала. Пример:

# tail -f /var/log/messages | grep syslog-server Dec 17 16:46:09 syslog-server pppd: pptpd-logwtmp.so ip-up ppp0 maikop 94.77.0.150 Dec 17 16:46:09 syslog-server pppd: Script /etc/ppp/ip-up finished (pid 12552), status = 0x0 Dec 17 16:46:49 syslog-server pptpd: CTRL: Client 85.175.197.65 control connection started Dec 17 16:46:49 syslog-server pptpd: CTRL: Starting call (launching pppd, opening GRE) Dec 17 16:46:49 syslog-server pppd: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.

Кроме файлов-журналов, указанных в /etc/syslog.conf, существуют так же и другие файлы, например файл , который хранит информацию о процессе загрузки системы до запуска syslogd, а так же файлы , имеющие двоичный формат и и хранящие информацию о последнем входе пользователя в систему, о всех удачных входах пользователей в систему и о всех неудачных входах пользователей в систему соответственно. Так же в каталоге /var/log/ могут находится лог-файлы таких демонов как веб-сервер или прокси-сервер. Формат данных файлов аналогичен журналам syslogd.

На последок, хотелось бы сделать акцент на том, что данный протокол очень не защищен, т.к. syslog не содержит никаких средств защиты от подделок сообщений. Хуже того, использование протокола UDP позволяет злоумышленникам посылать сообщения от имени любого хоста. Ваша локальная сеть должна быть защищена экраном от приема пакетов с поддельными локальными адресами (хотя это не помешает посылать поддельные сообщения изнутри локальной сети) и от приема пакетов снаружи на порт 514/udp. Известны случаи переполнения диска ложными сообщениями.

Протокол syslog и UDP не обеспечивают гарантированной доставки (сообщения могут быть потеряны при перегрузке сети или перехвачены, поврежденные сообщения удаляются без предупреждения), правильной последовательности доставки (сообщение о завершении процесса может придти раньше сообщения о его запуске), приоритетной доставки.

Конфиденциальность сообщений не обеспечивается, так как они передаются открытым текстом.

Если при настройке генератора сообщений указать неправильный адрес коллектора или релея, то никаких сообщений об ошибке не будет - сообщения будут удаляться (или записываться в чужой журнал).

Были предложены несколько проектов улучшения протокола syslog. Например, документ RFC 3195 предлагает систему протоколирования (syslog-conn), основанную на TCP, обеспечивающую гарантированную доставку сообщений в правильной последовательности. Проект syslog-sign предлагает обеспечить аутентификацию, упорядоченность, целостность сообщений и обнаружение пропавших сообщений за счет генерации специальных сообщений, содержащих цифровую подпись (signature) блока предыдущих сообщений с сохранением стандартного протокола и формата syslog и использованием UDP.

Подведем небольшой итог:

В линукс есть единый демон, отвечающий за журналирование событий локальной системы и удаленных систем. Все события собираются из сокета /dev/log, порта UDP - 514, а так же от "помощника" - демона klogd, который присылает сообщения от ядра. Все собранные сообщения фильтруются демоном syslogd через правила в файле /etc/syslog.conf и в соответствии с правилами распределяются по соответствующим местам назначения. Файлы логов периодически "обрезаются". Периодичность определяет файл logrotate.conf и команда logrotate, которая запускается системным планировщиком - cron.

На сегодня это все. Надеюсь описал все максимально понятно. Со временем буду дополнять статью!

С Уважением, Mc.Sim!