Поиск

Наши координаты

Телефон:
+7 (913) 229 5479
Адрес:
г. Барнаул
пр. Строителей, 16, оф. 613
Почтовый адрес:
656067, Алтайский край, г.Барнаул, 67 отделение связи,
а/я 4180
E-mail:
support@oit-company.ru

Наши партнёры





Воскресенье, 18.04.2021, 22:03

| RSS

ОТДЕЛ
ИНФОРМАЦИОННЫХ
ТЕХНОЛОГИЙ
 
Каталог статей


Главная » Статьи » Интересные статьи

Контроль за состоянием машин учащихся средствами Linux: Часть 3. Система мониторинга состояния удаленных машин

Контроль за состоянием машин учащихся средствами Linux: Часть 3. Система мониторинга состояния удаленных машин

Татьяна Василькова, ведущий инженер, Научно-исследовательский институт средств автоматизации

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

Дата:  02.03.2010
Уровень сложности:  средний
Комментарии:  

1 star2 stars3 stars4 stars5 stars Средний показатель рейтинга (основанный на 18 голосов)

 

1. Система мониторинга – автоматизируем труд администратора

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

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

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


2. Краткий обзор работы демона syslog

Большинство приложений операционной системы Linux, включая само ядро, записывают свои события в системный журнал. В Linux ведение журнала возложено на отдельный демон syslog, для ядра событий ядра – klog. Эти демоны постоянно принимают события от приложений и в определенном формате записывают их в файлы журналов в соответствии с настройками из конфигурационного файла syslog.conf. Этот файл можно обнаружить в директории /etc. Внутри конфигурационный файл может выглядеть, например, вот так:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.
authpriv.*,security.* /var/log/secure

# Log all the mail messages in one place.
mail.* /var/log/maillog

# Log cron stuff
cron.* /var/log/cron

# Everybody gets emergency messages
*.emerg *

# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log
local7.* /var/log/boot.log

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

Все события разделяются по типу службы (facility) и по степени важности (priority). Типов событий насчитывается около двадцати (среди них auth, daemon, kern, mail и т. п., а также восемь неименованных, от local0 до local7). Степеней важности восемь: debug, info, notice, warning, err, crit, alert и emerg.

Каждое событие определяется парой значений <facility>.<priority>. Причем syslog понимает такое описание, как «все события типа <facility> с приоритетом не ниже <priority>». При указании события можно использовать знак * (любые) и слово none (никакие).

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

*.* /var/log/all

Такой «всеобщий» журнал может пригодиться, например, для быстрого обнаружения всех приложений системы, отправляющих события в системный журнал.

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

  • в журнал messages поступают все события уровня не ниже info, за исключением событий демона-планировщика cron, событий почтовой службы и событий аутентификации;
  • события безопасности и события аутентификации любого уровня важности поступают в журнал secure;
  • для ранее исключенных из обработки событий почтовой службы и планировщика имеются отдельные файлы журналов – maillog и cron.

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

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

#!/bin/bash
str=`pwd`
logger -p security.info "test from directory $str"

События сохраняются в журнале в следующем формате:

дата и время имя хоста имя службы текст описания события.

В следующем фрагменте журнала messages содержатся сообщения о попытке подключения к машине по протоколу ssh, не удавшейся из-за провала аутентификации, о подключении по протоколу ssh пользователя root, о закрытии сессии этого пользователя:

Oct 26 09:32:34 asp1 sshd(pam_unix)[25001]: authentication failure; logname= uid=0 
euid=0 tty=ssh ruser= rhost=soa2 user=root
Oct 26 09:33:21 asp1 sshd(pam_unix)[25001]: session opened for user root by (uid=0)
Oct 26 09:39:41 asp1 sshd(pam_unix)[25001]: session closed for user root


3. Анализатор журналов Logcheck

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

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

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

Пакет для установки последней версии программы можно скачать с сайта logcheck.org. Для систем, поддерживающих инсталляционные пакеты rpm, все еще проще – достаточно найти rpm, собранный под нужную версию операционной системы.

После установки в системе появится исполняемый скрипт logcheck – например, в директории /usr/sbin, а также несколько конфигурационных файлов, через которые настраиваются ключевые слова. Кроме того, для работы используется дополнительная программа logtail, которая обеспечивает возможность не просматривать файлы журналов каждый раз заново. Вместо этого logtail запоминает положение последней проанализированной записи, чтобы в следующий раз просмотр начался с той, что за ней.

Настройка ключевых слов, по которым происходит отбор событий для отчетов, осуществляется путем редактирования следующих настроечных файлов программы в директории /etc/logcheck/:

  • logcheck.hacking – содержит список ключевых слов, по которым идентифицируются возможные атаки на систему;
  • logcheck.violations – содержит ключевые слова для идентификации нежелательных системных событий;
  • logcheck.violations.ignore – содержит ключевые слова, при наличии которых сообщение не будет отнесено к нежелательным;
  • logcheck.ignore – содержит ключевые слова, при наличии которых событие не включается ни в один раздел.

Все строки журнальных файлов, которые не содержат ключевых слов из файла logcheck.ignore и не были включены в другие разделы отчета, помещаются в раздел Unusual System Events (необычные системные события).

Для настройки отправки отчетов об обнаруженных событиях на адрес электронной почты администратора в файле /usr/sbin/logcheck задайте в параметре MAIL соответствующий адрес электронной почты:

# Person to send log activity to.
SYSADMIN=admin@test.test.ru

Тогда при запуске программы на указанный адрес придет письмо. Например, такое:

From root@test.test.ru Thu Dec 11 15:01:01 2008
Return-Path: <root@test.test.ru>
Received: from test (test.test.ru [127.0.0.1]) by test
(8.14.3/8.13.1) with ESMTP id mBBD11tj005930 for <root@test.test.ru>; Thu,
11 Dec 2008 15:01:01 +0200
Received: (from root@localhost) by test.test.ru (8.14.3/8.13.1/Submit) id
mBBD11QQ005927 for root; Thu, 11 Dec 2008 15:01:01 +0200
Date: Thu, 11 Dec 2008 15:01:01 +0200
From: root <root@test.test.ru>
Message-Id: <200812111301.mBBD11QQ005927@test.test.ru>
To: admin@test.test.ru
Subject: 12/11/08:15.01 system check
X-Evolution-Source: mbox:/var/spool/mail/root
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

Security Violations
=-=-=-=-=-=-=-=-=-=
Dec 11 14:24:01 test spamd[4840]: mkdir /root/.spamassassin: Permission denied at
/usr/lib/perl5/vendor_perl/5.8.5/Mail/SpamAssassin.pm line 1536
Dec 11 14:24:01 test spamd[4840]: locker: safe_lock: cannot create tmp lockfile
/root/.spamassassin/auto-whitelist.lock.test.test.ru.4840 for
/root/.spamassassin/auto-whitelist.lock: Permission denied
Dec 11 14:24:01 test spamd[4840]: auto-whitelist: open of auto-whitelist file failed:
locker: safe_lock: cannot create tmp lockfile
/root/.spamassassin/auto-whitelist.lock.test.test.ru.4840 for
/root/.spamassassin/auto-whitelist.lock: Permission denied
Dec 11 14:24:01 test spamd[4840]: bayes: locker: safe_lock: cannot create tmp lockfile
/root/.spamassassin/bayes.lock.test.test.ru.4840 for
/root/.spamassassin/bayes.lock:
Permission denied
Dec 11 14:24:01 test spamd[4840]: spamd: result: . -1 - ALL_TRUSTED
scantime=0.0,size=1597,user=root,uid=99,required_score=5.0,rhost=test.test.ru,raddr=127.0
.0.1,rport=32787,mid=<200812111223.mBBCNqJR005762@test.test.ru>,autolearn=failed

Unusual System Events
=-=-=-=-=-=-=-=-=-=-=
Dec 11 14:24:35 test kernel: usb 1-1: USB disconnect, address 2
Dec 11 14:24:35 test fstab-sync[5871]: removed mount point /media/NO_NAME for /dev/sdb
Dec 11 14:24:01 test spamd[4840]: spamd: connection from test.test.ru [127.0.0.1] at port
32786
Dec 11 14:24:01 test spamd[4840]: spamd: setuid to root succeeded
Dec 11 14:24:01 test spamd[4840]: spamd: still running as root: user not specified with
-u, not found, or set to root, falling back to nobody at /usr/bin/spamd line
1147, <GEN9> line 4.
Dec 11 14:24:01 test spamd[4840]: spamd: processing message (unknown) for root:99
Dec 11 14:24:01 test spamd[4840]: Use of uninitialized value in pattern match (m//) at
/usr/lib/perl5/vendor_perl/5.8.5/Mail/SpamAssassin/PerMsgStatus.pm line 880,
<GEN9> line 5.

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

Кроме адреса электронной почты администратора в файле logcheck настраиваются пути к файлам ключевых слов для анализа:

HACKING_FILE=/etc/logcheck/logcheck.hacking

VIOLATIONS_FILE=/etc/logcheck/logcheck.violations

VIOLATIONS_IGNORE_FILE=/etc/logcheck/logcheck.violations.ignore

IGNORE_FILE=/etc/logcheck/logcheck.ignore,

а также перечень файлов журналов, которые необходимо анализировать. По умолчанию в этот перечень включены файлы системного журнала messages, secure и mailllog:

# LOG FILE CONFIGURATION SECTION
# You might have to customize these entries depending on how
# you have syslogd configured. Be sure you check all relevant logs.
# The logtail utility is required to read and mark log files.
# See INSTALL for more information. Again, using one log file
# is preferred and is easier to manage. Be sure you know what the
# > and > operators do before you change them. LOG FILES SHOULD
# ALWAYS BE chmod 600 OWNER root!!

# Linux Red Hat Version 3.x, 4.x, 5.x
$LOGTAIL /var/log/messages > $TMPDIR/check.$$
$LOGTAIL /var/log/secure > $TMPDIR/check.$$
$LOGTAIL /var/log/maillog > $TMPDIR/check.$$

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

Для того чтобы анализ журналов производился автоматически и по расписанию, воспользуемся планировщиком задач операционной системы Linux – демоном cron. Он запускает все сценарии, находящиеся в директориях /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly и /etc/cron.monthly в соответствии с расписанием из конфигурационного файла /etc/crontab. Для ежечасного выполнения анализа журналов поместим ссылку на скрипт logcheck в папку /etc/cron.hourly.


4. Компоненты изучены – собираем систему

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

  • настроить работу службы журналирования операционной системы Linux syslog на всех рабочих местах учащихся;
  • установить и настроить на каждом рабочем месте программу анализа журналов Logcheck, указав подлежащие анализу журналы, адрес электронной почты для отправки оповещений и настроив списки ключевых слов для анализа (либо оставить вариант списков по умолчанию);
  • настроить на каждом рабочем месте учащегося выполнение сценария logcheck один раз в час, воспользовавшись планировщиком задач cron;
  • организовать на своем рабочем месте доступ к электронному почтовому адресу, например, при помощи почтового клиента;
  • настроить регулярную проверку наличия на почтовом сервере новых писем.

5. Заключение

Анализ журналов операционной системы Linux позволяет обеспечить администратора класса актуальной информацией о состоянии машин учащихся. Однако внимательный читатель может найти в предложенной простейшей системе несколько существенных изъянов.

Поскольку программа Logcheck не посылает оповещения, когда никаких подозрительных событий не обнаружено, администратор не сможет вовремя установить, что на конкретном рабочем месте произошел сбой работы службы журналирования или программы-анализатора, принимая отсутствие отчетов за свидетельство «благополучия» на машине учащегося.

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

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


Об авторе

Татьяна Василькова - ведущий инженер Научно-исследовательского института средств автоматизации (Минск, Республика Беларусь). Основная область профессиональных интересов – защита информации в информационных системах, в том числе, программные средства безопасности с открытым исходным кодом. Имеет степень магистра технических наук.

Источник

Категория: Интересные статьи | Добавил: sashacd (04.03.2010)
Просмотров: 1107 | Комментарии: 1 | Рейтинг: 0.0/0 |
Всего комментариев: 0
Имя *:
Email *:
Код *:

Copyright ООО "Отдел Информационных Технологий" © 2021