29 апр. 2013 г.

Сбор логов на windows-сервере. Часть 1 - syslogd for windows.

Логи - это важно. Если устройств много, в целях удобства и резервного копирования хорошим решением является создание некоего log-сервера, на который серверы и оборудование будут свои логи по сети пересылать.
Далее речь пойдет о задаче сбора syslog-сообщений от unix-серверов и активного оборудования (cisco ios) на windows-сервере. В процессе разработки решения были найдены два opensource-продукта - syslog for windows и nxlog. Первый более прост в освоении и подходит для случаев, когда источников или немного, или не стоит задачи сортировки входящих сообщений. Второй продукт более "развесист", при его развертывании не обойтись без чтения документации, однако эта "развестистость" дает очевидно большую гибкость в решении задач сбора и сортировки входящих логов.
Теперь чуть более подробно. 
Syslog for windows - это форк классического unix-демона syslog. Собранный для работы в Windows, умеет регистрироваться и работать как системная служба (конечно, возможен и "ручной" запуск). Также имеется возможность работы в режиме "multi-instance" - регистрируются несколько служб с уникальными названиями. Документация по настройке довольно куцая, однако ее вполне достаточно для написания собственного конфиг-файла, ибо софт написан под выполнение конкретной задачи сбора и хранения логов и умеет только это. Но умеет хорошо.
Для тех, кто знаком с внешниим видом юниксового syslog.conf, многое покажется знакомым - разница лишь в том, что все они пишутся в xml-"обертке". Логика файла проста - в простейшем случае должны быть описаны три сущности: источник (source), назначение (destination) и путь (logpath). У каждой из сущностей есть свой набор настроек, с помощью которых задается их поведение.
Для решения задачи сортировки входящих логов должна быть определена директива filter, работа которой основана на понятиях facility и priority. У каждого отправляемого удаленным syslog-сервером сообщения определен уровень того и другого: facility может иметь численное значение в диапазоне 0..23 или буквенное kern...debug (полный список смотрим в документации); prority, аналогично, задается или численно в диапазоне 0..7, или буквенно - emerg..debug.  Таким образом, общая идея сортировки входящих сообщений - группировка по источнику (используем разные уровни facility для разных устройств) или по важности сообщений (по уровню proirity). Количество описанных фильтров и назначений не ограничено (разве что уровней facility всего 24, а удобных для работы уровней local - и того меньше, 8), главное, чтобы в каждом logpath было по одному того и другого. 
В итоге может получиться такой кофигурационный файл:

<?xml version="1.0"?>
<!--
syslog.conf    Configuration file for syslogd.
        Based on Debian's syslog.conf.
-->
<conf>

<options logdir="log"/>
<source name="src_udp_0" type="udp" port="514"/>
<source name="src_udp_1" type="udp" port="515"/>

<!-- cisco switches -->
<destination name="cisco_switches" file="cisco_switches.log" rotate="monthly" backlogs="12"/>
<filter name="cisco_switches">
    <facility name="local3"/>
    <priority name="emerg"/>
    <priority name="alert"/>
    <priority name="crit"/>
    <priority name="error"/>
    <priority name="warning"/>
    <priority name="notice"/>
    <priority name="info"/>
    <priority name="debug"/>
</filter>
<logpath source="src_udp_0" filter="cisco_switches" destination="cisco_switches"/>

<!-- cisco inet routers -->
<destination name="inet_routers" file="inet_routers.log" rotate="monthly" backlogs="12"/>
<filter name="inet_routers">
    <facility name="local4"/>
    <priority name="emerg"/>
    <priority name="alert"/>
    <priority name="crit"/>
    <priority name="error"/>
    <priority name="warning"/>
    <priority name="notice"/>
    <priority name="info"/>
    <priority name="debug"/>
</filter>
<logpath source="src_udp_0" filter="inet_routers" destination="inet_routers"/>

<!-- linux firewalls -->
<destination name="linux_fw" file="linux_fw.log" rotate="daily" backlogs="30"/>
<filter name="linux_fw">
    <facility name="local1"/>
    <priority name="emerg"/>
    <priority name="alert"/>
    <priority name="crit"/>
    <priority name="error"/>
    <priority name="warning"/>
    <priority name="notice"/>
    <priority name="info"/>
    <priority name="debug"/>
</filter>
<logpath source="src_udp_1" filter="linux_fw" destination="linux_fw"/>

<!-- linux servers -->
<destination name="linux_srv" file="linux_srv.log" rotate="weekly" backlogs="10"/>
<filter name="linux_wrk">
    <facility name="local2"/>
    <priority name="emerg"/>
    <priority name="alert"/>
    <priority name="crit"/>
    <priority name="error"/>
    <priority name="warning"/>
    <priority name="notice"/>
    <priority name="info"/>
    <priority name="debug"/>
</filter>
<logpath source="src_udp_1" filter="linux_srv" destination="linux_srv"/>

<!--Сборная солянка - все логи за текущий день-->
<destination name="default" file="default.log" rotate="daily" backlogs="7"/>
<destination name="default1" file="default1.log" rotate="daily" backlogs="7"/>
<filter name="default">
    <facility name="kern"/>
    <facility name="user"/>
    <facility name="mail"/>
    <facility name="daemon"/>
    <facility name="syslog"/>
    <facility name="lpr"/>
    <facility name="news"/>
    <facility name="uucp"/>
    <facility name="cron"/>
    <facility name="ftp"/>
    <facility name="local0"/>
    <facility name="local1"/>
    <facility name="local2"/>
    <facility name="local3"/>
    <facility name="local4"/>
    <facility name="local5"/>
    <facility name="local6"/>
    <facility name="local7"/>
    <priority name="emerg"/>
    <priority name="alert"/>
    <priority name="crit"/>
    <priority name="error"/>
    <priority name="warning"/>
    <priority name="notice"/>
    <priority name="info"/>
    <priority name="debug"/>
</filter>

<logpath source="src_udp_0" filter="default" destination="default"/>
<logpath source="src_udp_1" filter="default" destination="default1"/>
Пара пояснений по ходу. С таким конфиг-файлом мы можем запустить две службы syslogd:
 syslogd --install --instance cisco
 syslogd --install --instance linux
одна из них зарегистрируется как syslogd_cisco и будет слушать 514/udp, другая - как syslogd_linux на порту 515/udp.
Входящие сообщения с удаленных syslog-серверов (настроенных на передачу данных на заданный сервер) пишутся в разные файлы согласно назначенным уровням facility. Опцией logdir мы задаем каталог хранения логов. В данном случае указан относительный (от места установки syslogd) путь, однако можно указывать и абсолютный.
Прямо в описании destination можно задать и опции ротации - с какой периодичностью и глубиной хранить историю (filename переименовывается в filename.1 и так далее до величины backlogs).
Помимо этого, все сообщения (включая те, что не попали ни в один из фильтров) записываются в общие log-файлы default.log и default1.log.
Практическая эксплуатация показала надежность этого решения - службы работают стабильно, друг дружке не мешают, никаких подвисаний себе не позволяют. Однако стоит помнить, что при наличии проблем в сети, связанных как с загруженностью каналов, настройкой коммутаторов или с иными причинами, данные могут быть не доставлены - протокол udp не гарантирует доставку пакетов.
 

16 апр. 2013 г.

Убиение чмода =)

Attack: chmod -x /bin/chmod
Defense: /lib/ld-linux.so.2 /bin/chmod 755 /bin/chmod