Брандмауэры и специальное программное обеспечение 8 Часть 4

Вид материала

Реферат

Содержание Глава 23. Просмотр и анализ журналов syslog Изучите файлы, расположенные в каталоге /etc/sysconfig/daemons/, так как все демоны, запускаемые в процессе начального запуска, Базовая конфигурация syslog Демон syslogd

Подобный материал:

• Муниципальное общеобразовательное учреждение средняя общеобразовательная школа №12, 174.77kb.
• Управление экономикой и создание экономических информационных систем Изучив данную, 148.93kb.
• Программное обеспечение ЭВМ, 209.59kb.
• Программное обеспечение вычислительной системы, 824.71kb.
• Учебная программа (Syllabus) Дисциплина: Интерфейсы компьютерных систем (iks 3304), 321.31kb.
• Реферат по Информационной безопасности Тема: «Антивирусы», 711.1kb.
• Пк программный комплекс; по программное обеспечение; ппо прикладное программное обеспечение, 208.41kb.
• Лекция 4 Обеспечивающие подсистемы асу. Математическое, программное, лингвистическое,, 59.3kb.
• Математическое и программное обеспечение систем оперативной оценки характеристик сложных, 247.51kb.
• Учебная программа (Syllabus) Дисциплина «Инструментальные средства разработки программ», 374.12kb.

OpenSSH

На момент написания данной книги пакет OpenSSH находится в стадии разработки. Автор этого пакета намерен разработать программное средство OpenSSH, которое можно будет использовать в качестве полноценной замены пакета SSH. Отличие состоит в том, что по сравнению с SSH лицензирование пакета OpenSSH будет более открытым и его развитие будет продолжено (в настоящее время осуществляется поддержка ssh-1.2.27, однако развитие этого пакета не осуществляется, — вместо него разрабатывается пакет версии 2.0.x, в отношении которого действует коммерческая схема лицензирования).

Программное средство OpenSSH наряду с обычными возможностями SSH позволит воспользоваться защищенными версиями протоколов FTP и RCP. Разработчики отказались от использования любого криптографического кода, с которым могут быть связаны патентные проблемы (например, IDEA или RSA), однако при этом им удалось обеспечить надежную криптографическую защиту.

Заключение

В данной главе я рассказал вам о том, как настроить, скомпоновать и установить программный пакет SSH — программное средство для защищенного удаленного администрирования систем и взаимодействия между системами. Вы узнали о том, как осуществляется настройка и использование данного программного средства. После этого я рассказал вам о том, как скомпилировать пакет FreeS/WAN и включить его в состав ядра Linux, а также выполнить настройку этого программного механизма для того, чтобы обеспечить надежное соединение WAN через публичную сеть, или просто соединить зашифрованным каналом две системы.


Часть IV
Аудит системы безопасности

Глава 22. Конфигурирование syslog

Глава 23. Просмотр и анализ журналов syslog

Глава 24. Использование средств наблюдения за защитой сети

Глава 25. Средства наблюдения за сетью

Глава 26. Где найти сведения о безопасности

₂₂

Конфигурирование syslog


В данной главе рассматриваются следующие вопросы:

- демоны syslog и klog;

- настройка файла syslog.conf;

- что такое каналы протоколирования и приоритеты;

- как узнать об имеющихся каналах протоколирования и приоритетах;

- конфигурирование syslogd;

- параметры syslogd;

- настройка параметров в процессе начальной загрузки.

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

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

В операционной среде Linux одновременно функционируют два механизма протоколирования сведений в журналах. Первый из них является системным (system logger), второй используется для слежения за ядром (kernel logger). В обычных условиях механизм слежения за ядро передает все сообщения системному механизму протоколирования. В результате сообщения, имеющие отношение к ядру, смешиваются с ситемными сообщениями. При желании вы можете настроить механизм слежения за ядром (klog) таким образом, чтобы он направлял все сообщения в отдельный файл, не совпадающий с syslog, однако эта настройка должна осуществляться в момент запуска. Необходимо изменить файл /etc/syslog/daemons/syslog следующим образом. Вместо строки


OPTIONS_KLOG="-k /boot/System.map-'uname -г ' "1

необходимо разместить в файле строку


OPTIONS_KLOG="-k /boot/System.map-'uname -r' -f /var/log/kmesg"

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


СОВЕТ

Изучите файлы, расположенные в каталоге /etc/sysconfig/daemons/, так как все демоны, запускаемые в процессе начального запуска, конфигурируются в этом каталоге.

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

Базовая конфигурация syslog

Чтобы понять, что именно протоколируется, когда и куда заносится соответствующая информация, необходимо владеть несколькими базовыми концепциями, имеющими отношение к протоколированию сведений в журналах. Механизм протоколирования оперирует тремя основными понятиями: канал протоколирования (facility), приоритет сообщений (priority) и местоположение журнала (logging location).

Канал syslog — это специальный канал для внутренних сообщений демона syslogd. Специальные определения каналов протоколирования содержатся в файле /usr/ include/sys/syslog.h. Фрагменты этого файла показаны в листинге 22.1. Комментарии переведены на русский язык.


Листинг 22.1. Фрагмент файла /usr/include/sys/syslog.h, в котором определяются каналы протоколирования syslog

/* коды каналов протоколирования */

fdefine LOG_KERN (0<<3) /* kernel messages - сообщения ядра*/

fdefine LOG_USER (1<<3) /* random user-level messages • сообщения пользовательского режима */

#define LOG_MAIL (2<<3) /* mail system - почтовая систена */

#define LOG_DAEMON (3<<3) /* system daemons - системные демоны */

продолжение

#define LOG_AUTH (4<<3) /* security/authorization messages */

/*сообщения безопасности/авторизации */

#define LOG_SYSLOG (5<<3) /* messages generated internally by syslogd */

/* внутренние сообщения syslogd */

#define LOG_LPR (6<<3) /* line printer subsystem - подсистема печати LPR */

#define LOG_NEWS (7<<3) /* network news subsystem - сетевая подсистема */

#define LOG_UUCP (8<<3) /* UUCP subsystem - подсистема UUCP */

#define LOG_CRON (9<<3) /* clock daemon - демон счетчика времени */

#define LOG_AUTHPRIV (10«3) /* security/authorization messages (private) */

/*сообщения безопасности/авторизации (закрытые) */

#define LOG_FTP (11<<3) /* ftp daemon - демон ftp*/

/* остальные коды вплоть до 15 зарезервированы для системного использования */

#define LOG_LOCALO (16<<3) /* зарезервировано для локального использования */

#define LOG_LOCAL1 (17<<3) /* зарезервировано для локального использования */

#define LOG_LOCAL2 (18<<3) /* зарезервировано для локального использования */

#define LOG_LOCAL3 (19<<3) /* зарезервировано для локального использования */

#define LOG_LOCAL4 (20<<3) /* зарезервировано для локального использования */

#define LOG_LOCAL5 (21<<3) /* зарезервировано для локального использования */

#define LOG_LOCAL6 (22<<3) /* зарезервировано для локального использования */

#define LOG_LOCAL7 (23<<3) /* зарезервировано для локального использования */

#define LOG_NFACILITIES 24 /* текущее количество каналов протоколирования */

#define LOG_FACMASK Ox03f8 /* маска для извлечения кода канала */

/* канал pri */

#define LOG_FAC(p) (((p) & LOG_FACMASK) >> 3)

#ifdef SYSLOG_NAMES CODE facilitynames[] =

{

{ "auth", LOG_AUTH },

{ "authpriv", LOG_AUTHPRIV },

{ "cron", LOG_CRON },

{ "daemon", LOG_DAEMON },

{ "ftp", LOG_FTP },

{ "kern", LOG_KERN },

{ "Ipr", LOG_LPR },

{ "mail", LOG_MAIL },

{ "mark", INTERNAL_MARK }, /* INTERNAL - канал внутреннего пользования*/

{ "news", LOG_NEWS },

{ "security", LOG_AUTH }, /* DEPRECATED • устаревшее */

{ "syslog". LOG_SYSLOG }.

{ "user", LOG_USER },

{ "uucp", LOG_UUCP },

{ "local0", LOG_LOCALO },

{ "local1". LOG_LOCAL1 },

{ "local2", LOG_LOCAL2 },

{ "local3", LOG_LOCAL3 },

{ "local4", LOG_LOCAL4 },

{ "local5", LOG_LOCAL5 }.

{ "Iocal6", LOG_LOCAL6 },

{ "local7", LOG_LOCAL7 },

{ NULL, -1 }

}:

#endif


Информация из этого файла включается разработчиком в состав каждой службы, которая должна взаимодействовать с механизмом syslog. Доступность механизма протоколирования является базовым правилом для всех служб с ограниченным доступом и сетевых служб. В первой части листинга 22.1 содержатся выражения #define, при помощи которых определяются числовые коды для каждого из каналов протоколирования. В разделе facilitynames каждому коду канала ставится в соответствие символьное имя этого канала. Имена каналов, содержащиеся в массиве facilitynames, используются для конфигурирования демона syslog. Вы должны знать, какой из каналов используется той или иной службой для протоколирования.

Многие имена каналов говорят сами за себя, к тому же предназначение каналов объясняется в комментариях, сопровождающих определения кодов каналов. Для каналов группы local (с порядковыми номерами от 0 до 7) никаких объяснений нет. Эти каналы используются службами, у которых нет своих собственных каналов. Многие службы используют каналы, не соответствующие именам этих служб. Например, служба telnet не имеет собственного канала, однако для протоколирования эта служба использует каналы auth и authpriv, так как любой пользователь, подключающийся к системе через telnet, должен пройти через процедуру аутентификации, основанной на анализе пары «пользовательское_имя/пароль».

С другой стороны, программа pppd, работающая на уровне привилегий root (благодаря чему она обладает возможностью модифицировать таблицы маршрутизации, читать привилегированные файлы и т. п.), не обладает специальным связанным с ней каналом. Поэтому она протоколирует сообщения в канале daemon, a если ее компиляция была выполнена с использованием параметра debug, протоколирование отладочных сообщений осуществляется в канале lосаl2. Версия pppd, входящая в состав OpenLinux, по умолчанию компилирована с использованием параметра debug. Однако отладочные сообщения по умолчанию не записываются в lосаl2. Этот режим необходимо включить явно. Для этого необходимо внести в файл /etc/ppp/options строку kdebug 1 или разместить эту команду в командной строке, которая вызывает pppd.

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

Вторым элементом системы протоколирования является приоритет протоколируемых сообщений. Каждое сообщение обладает уровнем приоритета, в зависимости от которого это сообщение либо вносится в журнал, либо отбрасывается. Далеко не все возможные сообщения для каждого канала вносятся в журнал. Приоритеты также определяются в файле /usr/include/sys/syslog.h, как показано в листинге 22.2.


Листинг 22.2. Фрагмент файла /usr/include/sys/syslog.h, в котором определяются приоритеты сообщений syslog

/* приоритеты (в порядке убывания важности)

*/

#define LOG_EMERG 0 /* дальнейшее использование системы невозможно */

#define LOG_ALERT I /* необходимо немедленно принять меры */

#define LOG_CRIT 2 /* критическое состояние */

#define LOG_ERR 3 /* состояние ошибки */

#define LOG WARNING 4 /* предупреждение */

#define LOG_NOTICE 5 /* состояние нормальное, но произошло нечто важное */

#define LOGJNFO 6 /* информационное сообщение */

#define LOG_DEBUG 7 /* отладочное сообщение */


#define LOG_PRIMASK 0x07 /*маска для извлечения приоритета (для внутреннего использования)*/

/* извлечение приоритета */

#define LOG_PRI(p) ((p) & LOG_PRIMASK)

#define LOG_MAKEPRI(fac, pri) (((fac) <<3) | (pri))

#ifdef SYSLOG_NAMES

#define INTERNAL_NOPRI 0x10 /* приоритет "no priority", то есть "без приоритета" */

/* mark "facility" */

#define INTERNAL_MARK LOG_MAKEPRI(LOG_NFACILITIES, 0) typedef struct _code {

char *c_name;

int c_val; } CODE:


CODE prioritynames[] =

{

{ "alert", LOG_ALERT },

{ "crit", LOG_CRIT },

{ "debug", LOG_DEBUG },

{ "emerg", LOG_EMERG },

{ "err", LOG_ERR },

{ "error", LOG_ERR }, /* DEPRECATED - устаревшее */

{ "info", LOG_INFO },

{ "none", INTERNAL_NOPRI }, /* INTERNAL */

{ "notice", LOG_NOTICE },

{ "panic", LOG_EMERG }, /* DEPRECATED - устаревшее */

{ "warn", LOG_WARNING }, /* DEPRECATED - устаревшее */

{ "warning", LOG_WARNING },

{ NULL, -1 }

}:

#endif


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

В составе OpenLinux используется стандартный конфигурационный файл /etc/syslog.conf. Этот файл содержит в себе записи, относящиеся к наиболее часто конфигурируемым службам, и указывает, какие файлы журналов, содержащиеся в каталоге /var/log, соответствуют этим службам. Стандартный конфигурационный файл показан в листинге 22.3. Комментарии переведены на русский язык.


Листинг 22.3. Файл /etc/syslog.conf, используемый в OpenLinux по умолчанию

#Все сообщения ядра протоколируются прямо на консоль.

#Если вы будете протоколировать на консоль какие-либо другие данные,

# вы рискуете заполнить весь экран информацией,

kern.* /dev/console

#Протоколировать все на уровне info и выше за исключением сообщений,

#связанных с электронной почтой, новостями,

#а также закрытых аутентификационных сообщений в файле messages

*.infо;news,mai1,authpriv,auth.none •/var/log/messages

# Протоколировать отладочные сообщения

*.debug;news,mail,authpriv,auth.none -/var/log/debug

#Файл для закрытых сообщений аутентификации обладает ограничениями на доступ

authpriv.*;auth.* /var/log/secure

#Канал auth в двух предыдущих правилах является устаревшим,

# однако он до сих пор используется.

#Все сообщения, связанные с почтой, протоколируются в одном месте

mail.* /var/log/mail

#Демон innd блокирует /var/log/news

#(вместо того, чтобы использовать /var/log/news.d)

#поэтому

#news.* /var/log/news.all

#Сохраняем сообщения об ошибках uucp и news уровня err и выше

#в специальном файле.

#uusp,news.err /var/log/spooler

#Сообщения уровня emergency получают все,

#кроне того, они протоколируются на другом компьютере.

*.emerg *

#*.emerg @loghost


Строки, начинающиеся с символа #, являются комментариями и игнорируются демоном syslog. Комментарии помогают понять, какие именно сведения протоколируются и в каких файлах размещаются соответствующие записи.

Записи файла syslog.conf обладают следующим форматом:

канал.приоритет путь/к/файлу/журнала

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

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


ПРИМЕЧАНИЕ

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


Например, если вы хотите протоколировать в файле /var/log/lnm сообщения из каналов lpr, news и mail с уровнем приоритета info или выше, вы можете использовать для этой цели следующую запись:

Ipr,news,mail.info /var/log/lnm

Эта запись аналогична следующей:

Ipr.info;.news.info;.mail.info /var/log/lnm


СОВЕТ

Символами-разделителями являются символы запятой и точки с запятой. Запятая используется для разделения имен каналов. Если в списке указываются разделенные запятыми уровни приоритетов, все уровни, за исключением последнего, игнорируются. Символ точки с запятой используется для разделения полных определений вида канал/приоритет.

С другой стороны, если вы хотите протоколировать все сообщения, за исключением сообщений cron и news в файле /var/log/messages, вовсе не обязательно перечислять в записи все каналы, за исключением каналов cron и news. Достаточно воспользоваться исключающим определением:

*.*;news,сгоп,authpriv.none /var/1og/messages

Первое определение (*.*) предписывает протоколировать абсолютно любые сообщения. Однако далее в строке располагается специально определенный список каналов news,cron,authpriv с уровнем приоритета попе. Уровень приоритета попе является специальным уровнем, указывающим демону syslogd на то, что для данных каналов ни один из уровней не представляет интереса и не должен протоколироваться. Таким образом, в рассматриваемой записи первое определение (*.*) разрешает протоколирование всех сообщений, однако второе определение (news,cron,authpriv.none) отменяет протоколирование сообщений любого приоритета для каналов news, cron и authpriv.


ВНИМАНИЕ

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

Совместно с приоритетами допускается использование двух дополнительных специальных символов. Первым специальным символом является восклицательный знак (!), который обозначает «отрицание», то есть все уровни приоритета, за исключением указанных. Второй специальный символ — это знак равенства (=), который обозначает единственный указанный уровень приоритета и никаких других. Например, если вы хотите, чтобы сообщения из всех каналов с уровнем приоритета debug (и никаким другим) записывались бы в файл /var/log/debug, вы можете воспользоваться следующей записью:

*.=debug /var/log/messages

Если вы также хотите, чтобы в этот же самый файл протоколировались сообщения с уровнем приоритета notice, после приведенной ранее записи добавьте запись:

*.!notice /var/log/debug

Если при всем при этом вы также желаете, чтобы все сообщения за исключением сообщений info записывались бы в файл /var/log/noinfo, вы можете добавить в конфигурацию также следующую запись:

*.!=info /var/log/noinfo

В данном случае оба специальных символа (! и =) использовались для того, чтобы исключить из всего возможного набора сообщений только сообщения с уровнем info. Имейте в виду, что если вы используете оба символа, вы должны располагать их так, как показано в примере, то есть символ восклицательного знака должен располагаться на первом месте.

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

Таким образом, сброс буферов на диск — важная составляющая процесса протоколирования сообщений. Однако в связи с этим вы должны учитывать также один немаловажный нюанс. Если протоколируемые сообщения пересылаются на один центральный сервер протоколирования и если при этом сразу же после получения каждого из сообщений будет выполняться синхронизация буферов с диском, производительность сервера может заметно снизиться и другие работающие на нем процессы замедлят функционирование. Чтобы решить проблему, необходимо отключить выполнение немедленной синхронизации сразу же после записи сообщения в файл, однако сделать это следует лишь для тех сообщений, которые не считаются особенно важными. Чтобы явно отключить немедленную синхронизацию, следует поставить перед именем файла символ дефиса (-). Вот пример подобной записи из стандартного файла syslog.conf, входящего в комплект поставки Caldera OpenLinux:

*.debug;news,mail,authpriv,auth.none -/var/log/debug

Эта запись указывает на то, что выполнение немедленной синхронизации сразу после записи отладочного сообщения в файл /var/log/debug не является обязательным.

Существует еще одна спецификация, которую можно использовать в качестве цели при протоколировании сообщений. Эта спецификация имеет формат @имя_узла. В качестве имени узла указывается имя вашего центрального протоколирующего сервера. При этом все сообщения, к которым относится данная запись, направляются указанному узлу в порт UDP с номером 514.


ПРИМЕЧАНИЕ

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


Сообщения, принимаемые через сеть центральным протоколирующим сервером, будут обрабатываться работающим на нем демоном syslogd в соответствии с расположенным на этом сервере файлом /etc/syslog.conf. Сообщения без указания места назначения (отсутствует определение канал.приоритет или соответствующая сообщению пара канал.приоритет исключена) будут отбрасываться.

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

*. * @центральный - протоколирующий - сервер

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


ВНИМАНИЕ

Центральный протоколирующий узел должен блокировать неавторизированные клиенты, посылающие ему сообщения syslog. Мало того, журналы должны располагаться в файловой системе, которая не является корневой. Благодаря этим мерам вы исключите возможность атаки типа Denial of Service, нацеленной на то, чтобы заполнить файлы журналов и остановить работу протоколирующего сервера.

Наконец в качестве цели для протоколируемых сообщений можно указать список пользователей. Имена пользователей в списке должны разделяться символом запятой. Как правило, подобным образом обрабатываются только сообщения с приоритетом emergency. Если в момент поступления сообщения пользователь не подключен к системе, сообщение ему передано не будет. Символом звездочки (*) обозначаются все пользователи. При этом используется команда wall, которая осуществляет широковещательную передачу сообщения всем подключенным пользователям в локальной сети. Сообщения с уровнем приоритета emergency зарезервированы системой для безвыходных ситуаций, поэтому, скорее всего, вы захотите настроить syslog таким образом, чтобы сообщение этой категории было принято вами вне зависимости от того, какую пользовательскую учетную запись вы использовали для подключения.

Демон syslogd

Настройка файла syslog.conf — это только половина всего дела. Некоторые настройки можно выполнить только при помощи командной строки при запуске демона syslogd. Ранее мы с вами уже использовали эту возможность: в ходе создания тюрьмы с измененным корнем для сервера DNS мы использовали ключ -а и указывали путь к дополнительному файлу журнала. Однако это был лишь один из множества возможных аргументов командной строки.

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

Чтобы приказать демону syslogd выполнять функции центрального сервера протоколирования, следует использовать ключ -r. По этой команде демон syslogd начинает принимать сообщения от клиентов. Имейте в виду, что syslogd принимает протоколируемые сообщения через порт UDP с номером 514, поэтому syslogd должен работать на уровне привилегий root, так как только на этом уровне можно связать порт с номером ниже 1024. Также следует учитывать, что по умолчанию syslogd не осуществляет пересылку сообщений, принимаемых им от клиентов, на другие сетевые узлы. Иначе говоря, если в файле /etc/syslogd.conf в качестве цели для сообщения, принятого от клиента, указан удаленный сетевой узел, сообщение не будет передано этому узлу, если только не был использован ключ -h.

Благодаря ключу -h сообщения syslog можно передавать от клиента к серверу, а затем еще одному серверу. В нормальных условиях эта возможность вряд ли когда может потребоваться, однако если некоторые из ваших систем находятся вне зоны, защищенной при помощи брандмауэра, а протоколирующий сервер расположен за брандмауэром, и при этом брандмауэр не осуществляет перенаправление UDP-порта с номером 514, то вы можете использовать брандмауэр в качестве ретранслятора сообщений syslog. Такую конфигурацию нельзя назвать идеальной, однако она вполне работоспособна.

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

Два эти ключа работают по-разному, хотя и'близки по назначению. По команде -l демон syslog будет заносить в журнал только короткое имя узла. По команде -s демон syslog отбрасывает от полного доменного имени узла некоторую часть. Предположим, что требуется внести в журнал доменное имя roadrunner.marketing. acme.com. При использовании команды -l и указании узла roadrunner в журнал попадет только краткое имя этого узла — roadrunner. Если же использовать команду -s acme.com, от полного доменного имени сетевого узла будет отсечено имя домена acme.com, и в журнал попадет только оставшаяся часть имени, а именно roadrunner.marketing. Эта возможность может оказаться полезной в случае, если в вашей сети используются субдомены и в некоторых из них встречаются дублирующиеся имена сетевых узлов.

Еще одним полезным параметром командной строки является ключ -р. При помощи этого ключа вы можете изменить сокет (имя или местоположение), через который демон syslogd осуществляет запись. Однако используя эту возможность, вы не сможете повысить защиту вашей системы. По умолчанию используется сокет с именем /dev/log. Существует очень мало причин, по которым может потребоваться скрыть данный канал (pipe). Любой пользователь системы, обладающий возможностью запустить утилиту netstat, при желании сможет обнаружить этот канал. Это видно в листинге 22.4, где показан сокращенный вывод утилиты netstat.


Листинг 22.4. Фрагмент вывода команды netstat -а, в котором показан канал syslog

Active UNIX domain sockets (servers and established)

Proto RefCnt Flags Type State I-Node Path

unix 0 [ ACC ] STREAM LISTENING 12556 /dev/log

unix 1 [ ] STREAM CONNECTED 12560 /dev/log


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


ПРИМЕЧАНИЕ

Для повышения уровня безопасности демон syslogd можно запустить от имени непривилегированного пользователя, однако в этом случае его нельзя будет использовать в качестве центрального механизма протоколирования для всей сети. Дело в том, что UDP-порт с номером 514, используемый для приема сообщений syslog через сеть, может быть связан только на уровне привилегий root.

Совместно с демоном syslogd можно использовать и многие другие параметры командной строки, однако здесь я расскажу вам еще только об одном ключе. Ключ -m используется для добавления в файлы журналов пометок о времени. В числе прочих механизмом syslog используется канал mark, который на самом деле не является обычным каналом. Этот канал используется только для того, чтобы добавлять в журналы пометки о времени. Эти пометки многим могут показаться раздражающими, однако на самом деле, проанализировав их или обнаружив их отсутствие, вы сможете сделать вывод о том, что с файлами журналов кто-то производил несанкционированные операции. По умолчанию пометки о времени добавляются в файлы журналов через каждые 20 минут, однако длительность этого промежутка можно изменить при помощи ключа -m, к которому в качестве аргумента необходимо добавить желаемую длительность временного интервала. Если установить временной интервал равным нулю, пометки о времени не будут добавляться в файлы журналов.