Gentoo Linux Handbook Page --

1. Введение

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

Также немаловажно, чтобы файлы журналов были легко читаемыми и обозримыми. В Gentoo Linux при установке на выбор предлагается 3 разных средства журналирования.

1. Журналирование: Syslogd

Syslogd является самым распространенным средством журналирования для Linux и Unix. Он способен делать ротацию журналов, однако использование /usr/sbin/logrotate с вызовом по расписанию (logrotate настраивается с помощью файла /etc/logrotate.conf) может оказаться полезней, так как у logrotate есть много дополнительных возможностей. Частота ротации подбирается в зависимости от загрузки системы.

Ниже приведен стандартный файл syslog.conf с некоторыми добавлениями. Мы раскомментировали строки cron и tty, и добавили удаленный сервер журналирования. Для дальшейшего усиления журналирования можно настроить ведение журнала в двух местах.

Листинг 1.1: /etc/syslog.conf

#  /etc/syslog.conf     Файл настройки syslogd.
#
#                       За дополнительной информацией обращайтесь к
#                       странице справки syslog.conf(5).
#                       Взято из Debian, пока пользуемся им
#                       Daniel Robbins, 5/15/99

#
# Сначала стандартные файлы журналов.  Журналирование по подсистемам.
#

auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          /var/log/mail.log
user.*                          -/var/log/user.log
uucp.*                          -/var/log/uucp.log
local6.debug                    /var/log/imapd.log

#
# Журналирование почтовой системы. Разбито на части, чтобы
# легко писать сценарии для разбора этих файлов.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

# Журналирование новостной системы INN
#
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice

#
# Журналы, куда может попадать "все подряд".
#
*.=debug;\
        auth,authpriv.none;\
        news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

#
# Предупреждения и чрезвычайные сообщения, посылаемые всем вошедшим.
#
*.emerg                         *
*.=alert                        *

#
# Мне нравится вывод сообщений на консоль, но только на ту виртуальную
# консоль, что я обычно оставляю простаивать.
#
daemon,mail.*;\
       news.=crit;news.=err;news.=notice;\
       *.=debug;*.=info;\
       *.=notice;*.=warn       /dev/tty8

# Настройка сервера удаленного журналирования
*.*                        @logserver

# Именованный канал /dev/xconsole - для утилиты `xconsole'. Чтобы использовать,
# следует запускать `xconsole' с параметром `-file':
#
#    $ xconsole -file /dev/xconsole [...]
#
# ПРИМЕЧАНИЕ: измените список, данный ниже, или вы с ума сойдете, если
#      у вас осносительно загруженная площадка..
#
#daemon.*,mail.*;\
#       news.crit;news.err;news.notice;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       |/dev/xconsole

local2.*                --/var/log/ppp.log

Злоумышленники, скорее всего, будут стараться уничтожать следы своего пребывания, исправляя или удаляя файлы журналов. Можно затруднить им работу, ведя журналирование на одном или нескольких удаленных серверах журнала, расположенных на других компьютерах. Узнать больше о syslogd можно, запустив man syslog.

1. Metalog

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

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

Для postfix:

Листинг 1.1: /usr/local/sbin/mail_pwd_failures.sh для postfix

#! /bin/sh
echo "$3" | mail -s "Warning (program : $2)" root

Для netqmail:

Листинг 1.1: /usr/local/sbin/mail_pwd_failures.sh for netqmail

#!/bin/sh
echo "To: root
Subject:Failure (Warning: $2)
$3
" | /var/qmail/bin/qmail-inject -f root

Не забудьте сделать сценарий исполняемым командой /bin/chmod +x /usr/local/sbin/mail_pwd_failures.sh.

Затем в файле /etc/metalog/metalog.conf раскомментируйте строку под «Password failures»:

Листинг 1.1: /etc/metalog/metalog.conf

command  = "/usr/local/sbin/mail_pwd_failures.sh"

1. Syslog-ng

Syslog-ng, за некоторыми отличиями, обладает теми же возможностями, что и syslog и metalog. Он может фильтровать сообщения по уровню и содержимому (как metalog), вести удаленное журналирование, как syslog, обрабатывать журналы, получаемые от syslogd (даже потоки от Solaris), записывать в TTY, запускать программы, и служить сервером журналирования. То есть, он сочетает лучшие черты обоих средств журналирования с возможностью расширенной настройки.

Ниже приведен слегка подправленный классический конфигурационный файл.

Листинг 1.1: /etc/syslog-ng/syslog-ng.conf

options { chain_hostnames(off); sync(0); };

#источник, откуда читать журнал
source src { unix-stream("/dev/log"); internal(); };
source kernsrc { file("/proc/kmsg"); };

#получатели
destination authlog { file("/var/log/auth.log"); };
destination syslog { file("/var/log/syslog"); };
destination cron { file("/var/log/cron.log"); };
destination daemon { file("/var/log/daemon.log"); };
destination kern { file("/var/log/kern.log"); };
destination lpr { file("/var/log/lpr.log"); };
destination user { file("/var/log/user.log"); };
destination mail { file("/var/log/mail.log"); };

destination mailinfo { file("/var/log/mail.info"); };
destination mailwarn { file("/var/log/mail.warn"); };
destination mailerr { file("/var/log/mail.err"); };

destination newscrit { file("/var/log/news/news.crit"); };
destination newserr { file("/var/log/news/news.err"); };
destination newsnotice { file("/var/log/news/news.notice"); };

destination debug { file("/var/log/debug"); };
destination messages { file("/var/log/messages"); };
destination console { usertty("root"); };
destination console_all { file("/dev/tty12"); };
destination xconsole { pipe("/dev/xconsole"); };

#создание фильтров
filter f_authpriv { facility(auth, authpriv); };
filter f_syslog { not facility(authpriv, mail); };
filter f_cron { facility(cron); };
filter f_daemon { facility(daemon); };
filter f_kern { facility(kern); };
filter f_lpr { facility(lpr); };
filter f_mail { facility(mail); };
filter f_user { facility(user); };
filter f_debug { not facility(auth, authpriv, news, mail); };
filter f_messages { level(info..warn)
        and not facility(auth, authpriv, mail, news); };
filter f_emergency { level(emerg); };

filter f_info { level(info); };
filter f_notice { level(notice); };
filter f_warn { level(warn); };
filter f_crit { level(crit); };
filter f_err { level(err); };
filter f_failed { match("failed"); };
filter f_denied { match("denied"); };

#связывание фильтров с получателями
log { source(src); filter(f_authpriv); destination(authlog); };
log { source(src); filter(f_syslog); destination(syslog); };
log { source(src); filter(f_cron); destination(cron); };
log { source(src); filter(f_daemon); destination(daemon); };
log { source(kernsrc); filter(f_kern); destination(kern); };
log { source(src); filter(f_lpr); destination(lpr); };
log { source(src); filter(f_mail); destination(mail); };
log { source(src); filter(f_user); destination(user); };
log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };
log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); };
log { source(src); filter(f_mail); filter(f_err); destination(mailerr); };

log { source(src); filter(f_debug); destination(debug); };
log { source(src); filter(f_messages); destination(messages); };
log { source(src); filter(f_emergency); destination(console); };

#журнал по умолчанию
log { source(src); destination(console_all); };

Syslog-ng очень легко настраивается, но с той же легкостью можно что-либо упустить в файле настройки, так как он очень велик. Автор также обещает дополнительные возможности, например, шифрование, опознание, сжатие и обязательную проверку прав доступа (MAC — mandatory access control). С такими возможностями программа станет незаменимой для журналирования в сети, так как злоумышленник не сможет перехватывать журнал.

К тому же у syslog-ng есть еще одно достоинство: он не требует прав администратора для запуска!

1. Анализ журналов с помощью Logcheck

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

Logcheck и logtail входят в состав пакета app-admin/logsentry.

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

Предупреждение: Не оставляйте logcheck.violations.ignore пустым. Для обработки журналов Logcheck использует grep, некоторые версии которого считают пустой файл знаком подстановки (wildcard). В таком случае все нарушения будут игнорироваться.

Обновлено 25 ноября 2005

Исходный документ обновлен 2 апреля 2010

Donate to support our development efforts.