Самоучитель системного администратора. 5-е издание

Глава 11 
Исследовав файл конфигурации 
rsyslog.conf
, можно понять, для чего используется 
тот или иной журнал. Но некоторые сервисы, например Apache, ведут свои собст-
венные журналы, минуя демон протоколирования, — все они тоже хранятся в ката-
логе 
/var/log
. Именно этим объясняется, что в каталоге 
/var/log
содержатся дополни-
тельные файлы и каталоги, не упомянутые в 
rsyslog.conf
. Вот примеры некоторых 
файлов (каталогов) журналов: 
/httpd/
— журналы веб-сервера Apache; 
/cups/
— журналы системы CUPS (в вашей системе может быть установлена одна 
из этих систем печати); 
auth.log
— журнал аутентификации: кто и когда входил в систему. В некоторых 
дистрибутивах такого файла нет, а сообщения системы аутентификации записы-
ваются в файл 
messages
; 
boot.log
— журнал загрузки системы. В некоторых дистрибутивах сообщения за-
грузки системы также записываются в файл 
messages
; 
dmesg
— загрузочные сообщения ядра (до запуска системы инициализации). Такой 
файл имеется не во всех дистрибутивах, но вы всегда сможете просмотреть загру-
зочные сообщения ядра с помощью команды 
dmesg
. Если файл 
/proc/sys/ 
kernel/dmesg_restrict
содержит 0, то команду 
dmesg
может выполнить непривилегиро-
ванный пользователь, если же в этом файле единица, команду 
dmesg
может выпол-
нить только пользователь root или пользователь с правами 
CAP_SYS_ADMIN
; 
messages
— основной журнал системы; 
secure
— сообщения системы безопасности. Сюда, например, помещаются со-
общения при входе пользователя через GDM; 
syslog
— журнал демона syslog; 
Xorg.0.log
— журнал системы X.Org; 
zypper.log
, 
yum.log
, 
dpkg.log
— журналы менеджеров пакетов (в openSUSE, Fedora 
и Ubuntu/Debian соответственно). 
В каком же журнале искать ошибку? Тут нужно исходить из принципа взаимоис-
ключения: если у вас не работает веб-сервер Apache, то искать причину нужно 
в каталоге 
/var/log/httpd/
, но никак не в файле 
/var/log/mail
. 
В UNIX-системах для повышения детализации протоколирования той или иной 
службы нужно редактировать ее конфигурационный файл. Дополнительную ин-
формацию об этом можно получить в документации по службе. Например, в кон-
фигурационных файлах часто встречается строка вида 
syslog = 0
. Чтобы повысить 
уровень детализации протоколирования, нужно изменить 
0
на большее значение 
(какое именно — можно уточнить в документации). После этого надо или переза-
пустить службу (командой: 
servive <имя службы> restart
), или заставить ее пере-
читать файл конфигурации (командой: 
service <имя службы> reload
). 
К слову сказать, изменение детализации протоколирования большинства служб 
Windows осуществляется посредством изменения параметров реестра. Названия 

---

Порядок выявления неисправностей и их устранения 
531 
этих параметров можно найти в документации по службе или на сайтах разработ-
чиков программного обеспечения. 
Централизованное ведение журналов 
Системным администраторам приходится анализировать данные журналов не-
скольких серверов. Удобно, если эта операция будет выполняться из одной консоли. 
В этих целях в системах Windows 7/10, Server 2008 R2 и 2012/2016 присутствует 
возможность настройки сбора событий с различных компьютеров. Для этого ис-
пользуется опция 
Подписка
. 
При создании подписки (рис. 11.3) необходимо указать, с каких систем будут соби-
раться данные, настроить фильтры (указать, какие события копировать), назначить 
журнал, в который станет осуществляться запись. Также нужно настроить парамет-
ры учетной записи, которая будет иметь доступ к журналу на удаленном компью-
тере. Кроме того, надо еще выполнить некоторые настройки на удаленной системе 
(см. онлайновую справку). Подписку можно оформлять как для компьютеров до- 
Рис. 11.3. 
Настройка подписки в Windows Server 2016 

---

532 
Глава 11 
мена, так и рабочей группы (особенности настройки в этом случае следует уточ-
нить по справочной документации). 
При желании использовать для анализа журналов графический интерфейс, можно 
обратиться к специальной утилите — EventCombMT, бесплатно загружаемой с сер-
вера Microsoft по ссылке: 
https://support.microsoft.com/ru-ru/kb/824209/ru
.
Утилита EventCombMT позволяет просматривать данные протоколов работы сразу 
нескольких систем. Администратор может задать желаемые условия поиска (номер 
события, имена компьютеров для анализа, диапазон дат и т. п.). Утилита содержит 
несколько встроенных описаний условий поиска — например, по ошибкам DNS, 
FRS, жестких дисков, службы каталогов. Результаты работы программа сохраняет 
в виде текстовых файлов. 
П
РИМЕЧАНИЕ
Существует много коммерческих средств, предназначенных для централизации сбора 
и анализа событий журналов нескольких систем. При желании найти эти решения не 
составит особого труда. 
События журналов важны и в случае разбора инцидентов. Поскольку злоумышлен-
ник будет пытаться очистить журналы атакуемой системы, то при предъявлении 
повышенных требований к хранению событий последние необходимо копировать 
на выделенный сервер. 
Установка триггеров на события протоколов 
Основным способом мониторинга систем на основе Windows является реагирова-
ние на события журналов. Подобные настройки легко сделать и собственными
силами, если представлять контролируемый объем. 
В Windows 7/10 и Server 2008/2016 настройку триггеров можно сделать в програм-
ме просмотра событий. Достаточно выделить событие, которое будет использовано 
в качестве образца, и в столбце задач по ссылке 
Назначить задачу
(или 
Привязать 
задачу к событию
— в последних версиях Windows) запустить мастер операций 
(рис. 11.4). Мастер позволяет назначить для события отправку сообщения, в том 
числе и электронной почты, либо запуск произвольной программы. 
Настройка аудита событий безопасности 
Объем событий, которые фиксируются в журнале безопасности, целиком определя-
ется настройками системы, и их журналирование по умолчанию на рабочих стан-
циях не ведется. Наиболее полный объем аудита событий безопасности можно
установить при наличии на диске файловой системы NTFS. 
Чтобы начать протоколирование событий безопасности, необходимо сначала 
раз-
решить
аудит
событий безопасности в политике безопасности. Это может быть 
сделано как локально — в локальной политике безопасности, так и централизован-
но — путем задания соответствующих параметров в групповой политике. Если
администратор хочет отслеживать доступ к файлам и принтерам, то следует 
задать
объекты
, для которых должен осуществляться аудит событий. 

---

Порядок выявления неисправностей и их устранения 
533 
Рис. 11.4. 
Мастер создания простой задачи на возникновение события в журнале 
П
РИМЕЧАНИЕ
Политика безопасности включает возможность аудита как успешных, так и неудачных 
событий для различных объектов. Не следует без необходимости вести аудит всех 
событий, поскольку это может привести к нерациональной загрузке компьютера и по-
тери производительности. 
Если необходимо вести протокол работы с файлами, то следует включить аудит 
доступа к объектам, после чего в свойствах объекта на вкладке 
Безопасность
на-
жать кнопку 
Дополнительно
и выбрать вкладку 
Аудит
. Затем нужно добавить све-
дения о том, какие действия и от каких пользователей должны фиксироваться 
в журнале. 
Утилиты от Sysinternals 
Сайт Sysinternals был создан в далеком 1996 году Марком Руссиновичем (Mark 
Russinovich) и Брайсом Когсвеллом (Bryce Cogswell). На сайте размещались соз-
данные ими усовершенствованные сервисные программы и выкладывалась различ-
ная техническая информация. Спустя 10 лет, в 2006 году, корпорация Microsoft 
приобрела компанию Sysinternals. Сайт Sysinternals стал частью сайта TechNet
(
https://technet.microsoft.com/ru-ru/sysinternals)
, откуда вы можете скачать раз-
личные полезные программы. Одна из таких программ (а именно Process Monitor) 
изображена на рис. 11.5. 

---

534