Что искать и где найти?

Очевидно, куда проще предупредить неполадки в сети, чем исправлять уже возникшие проблемы. Мониторинг серверов, выполняемых на них приложений и сетевых устройств поможет заблаговременно узнать о потенциальных неисправностях и предотвратить их последствия. Отслеживая функционирование сети и сохраняя предысторию ее работы, администратор к тому же может предоставить точную информацию пользователям, у которых иногда складывается неверное представление о частоте появления различных неисправностей. Не менее важно, что сетевой мониторинг позволяет получать точные сведения о событиях в сети, а также времени и источниках обращений в сеть. Итак, существует два типа мониторинга. Первый из них мы будем называть оперативным мониторингом (operations monitoring), а второй — мониторингом безопасности (security monitoring).

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

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

Объекты мониторинга

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

В целях безопасности полезно контролировать все сетевые устройства (например, брандмауэры, шлюзы, VPN-устройства, беспроводные узлы доступа — AP) на границе сети — периметре безопасности, а также любые серверы, на которых размещаются информация и процессы, требующие конфиденциальности или целостности. Для производственных целей следует контролировать все устройства и серверы, отказоустойчивость которых важна для нормальной работы предприятия. Для Windows необходим мониторинг не только операционной системы, но и важных приложений, таких как Microsoft Exchange Server, Microsoft ISA Server, Microsoft IIS и Microsoft SQL Server. Полезно контролировать высокоуровневые приложения (например, Microsoft SharePoint Portal Server), если таким образом удается обнаружить важные события, относящиеся к сфере безопасности или производства, которые могут остаться незамеченными средствами нижележащих баз данных, на которых они работают.

Источники телеметрических данных

Главный источник телеметрической информации о серверах Windows — журнал событий Security, а важнейший источник производственной телеметрии — журналы событий System и Application. Опытные пользователи оснастки Event Viewer консоли Microsoft Management Console (MMC) знают, что во всех журналах событий Windows применяется один формат файлов (.evt). Запись о каждом событии содержит стандартные поля (например, дата, время, источник события, категория, ID события), за которыми следует поле описания с данными в свободной форме, уникальными для конкретного события. Любое приложение мониторинга, совместимое с журналами событий Windows, позволяет генерировать предупреждения и отчеты на основе источника, категории или ID события, но в идеальном случае нужно иметь возможность отфильтровывать записи по данным в описании события.

Сетевые устройства, такие как маршрутизаторы, коммутаторы, беспроводные AP и брандмауэры, неизменно передают телеметрические данные через протокол SNMP или Syslog. SNMP был спроектирован в конце 1980-х для управления множеством устройств в бурно развивающейся сети Internet. Диспетчеры SNMP собирают телеметрическую информацию от агентов через UDP-порт 162. Диспетчеры могут использовать SNMP-команды Get для запроса конкретных телеметрических данных, называемых переменными (variable), или пассивно ждать отчета о важных событиях от агентов через сообщения Trap. Для мониторинга в сферах производства и безопасности достаточно собирать сообщения Trap. Для углубленного анализа тенденций и планирования ресурсов следует опрашивать агентов с помощью команд Get.

Syslog

Syslog — стандарт протоколирования событий для UNIX. Преимущество Syslog перед механизмом протоколирования событий Windows заключается в том, что весь процесс консолидации потоков событий от многочисленных систем — неотъемлемая часть Syslog. В действительности Syslog одновременно сетевой протокол и формат журнала, и по умолчанию он использует UDP-порт 514. Каждое сообщение Syslog содержит поля даты, времени, приоритета, имени хоста и текста сообщения. С технической точки зрения приоритет — число от 0 до 191. Однако большинство приложений Syslog отображают приоритет в виде двух составляющих: Facility и Level.

Facility. Первоначально Syslog проектировался для мониторинга BSD Unix, и величина Facility использовалась для идентификации процесса Unix о котором свидетельствует событие. Значения от 0 до 15 соответствуют важнейшим процессам Unix, а значения от 16 до 23 (с именами от Local0 до Local7) предназначены для приложений и устройств. В табл. 1 приведен список всех значений Facility и их имена. Большинство сетевых устройств используют значения от Local0 до Local7 (например, устройства Cisco задействуют Local6 и Local7), но не все. Маршрутизатор Xincom Twin Wan использует почти все низкие значения Facility.

Level. Другой элемент приоритета сообщений Syslog — Level, значения которого находятся в пределах от 0 до 7. Level характеризует степень важности сообщения, как показано в табл. 2.

Производительность и состояние

Для полного функционального мониторинга полезно контролировать объекты производительности (performance-object) и состояние серверов с отдельного компьютера или от провайдера услуг. Администраторы, не знакомые с объектами производительности, могут исследовать их с помощью оснастки Performance консоли MMC. Разница между мониторингом журнала событий и объекта производительности следующая: из журналов событий можно извлечь информацию о любой части системы, в которой произошли неполадки, а объект производительности позволяет убедиться, что конкретные параметры находятся в допустимых пределах. Например, с помощью объектов производительности можно следить за пространством жесткого диска, так как системный журнал выдает предупреждение, только когда том заполняется до такой степени, что пользователь уже начинает испытывать неудобства.

Еще одна типичная проверка с применением объекта производительности — мониторинг коэффициента использования центрального процессора с отслеживанием определенных уровней в течение длительных периодов времени (например, свыше 90% в течение 10 минут). Однако при проверках коэффициента использования центрального процессора следует проявлять осторожность; нетрудно перепутать полезную нагрузку с неуправляемым процессом и сгенерировать ложное сообщение о проблеме. Замечательное свойство объектов производительности заключается в том, что другие приложения могут создавать собственные объекты производительности и публиковать телеметрические данные, специфичные для данного приложения. Например, Active Directory (AD), SQL Server и Exchange Server располагают собственными объектами производительности.

Отсутствие сообщений об ошибках в журнале и показатели производительности в пределах допустимых порогов — хорошие индикаторы корректного функционирования. Однако некоторые проблемы не находят отражений в индикаторах. Проверки состояния серверов — самый эффективный способ убедиться в том, что серверы и приложения работают в сети и успешно обрабатывают запросы. Проверки состояния серверов надежны, так как они выполняют тестовую транзакцию. Многие провайдеры приложений и служб в Internet позволяют регулярно проводить тестовые транзакции с сервером через выбранные потребителем интервалы времени. Для Web-сервера можно периодически запрашивать данную Web-страницу и проверять, успешно ли она передана. Для системы SQL Server можно периодически выполнять запрос и проверять результаты.

Однако даже проверки состояния не раскрывают всех проблем. Например, простой сигнал ping, передаваемый через каждые 5 минут, позволяет убедиться, что операционная система и набор протоколов активны, но не содержат никакой информации о состоянии самого приложения. Мне приходилось встречать зависшие серверы, которые отвечали на сигналы ping. Аналогично простой запрос HTML-страницы с сервера не доказывает, что соответствующее приложение электронной коммерции на базе Active Server Pages (ASP) работает корректно.

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

Еще одно предостережение: программу проверки состояния следует размещать вне контролируемой производственной среды. Если ошибочно разместить программу проверки состояния на контролируемом сервере, то, например, не удастся определить отказ сервера или серверного соединения, так как приложение не сможет передать администратору соответствующее сообщение. Но если приложение проверки работает на отдельном сервере (и если этот сервер доступен из Internet), то единственный случай, когда важное приложение будет не готово к работе без ведома администратора, — одновременный отказ производственной и контролирующей среды.

Необходимый инструментарий

Итак, что нужно для мониторинга всех устройств, серверов, журналов, ловушек SNMP и событий Syslog? Очевидно, необходимы один-два инструмента по доступной цене, охватывающих все элементы, которые требуется отслеживать. Продукты мониторинга высокого уровня, такие как Argent Guardian и Microsoft Operations Manager (MOM), позволяют контролировать все объекты производительности, журналы событий Windows, ловушки SNMP, потоки событий Syslog и даже выполнять различные проверки состояния. Некоторые не столь крупные, менее дорогостоящие пакеты, такие как Sentry II компании Engagent, EventTracker компании Prism Microsystems и комплекс Event Log Management компании Dorian, охватывают подмножество телеметрических источников и ограниченный набор объектов производительности.

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

Рассмотрим три полезных инструмента, которые можно добавить к арсеналу сетевого мониторинга: Log Parser, бесплатный инструмент Microsoft; tail, отличную утилиту из мира UNIX; утилиту Kiwi Syslog Daemon, которая представлена бесплатной и более мощной, но тем не менее недорогой версией. Информация будет полезна даже тем администраторам, которые уже имеют или намерены приобрести инструменты: большинство инструментов на рынке располагают лишь функциями предупреждений и отчетности, дополненными шаблонными отчетами и примерными правилами рассылки предупреждений. Методы проектирования и анализа, описанные в статье, будут чрезвычайно полезны даже для обладателей развернутой на предприятии программы мониторинга.

Мониторинг журнала Security Log

Администраторам, которые нуждаются в инструменте для мониторинга журналов событий Windows и рассылки оповещений (по электронной почте или на пейджер) при обнаружении событий, соответствующих заданным критериям, я рекомендую создать специализированный механизм предупреждений с использованием VBScript и Windows Management Instrumentation (WMI). Ранее в журнале мы уже приводили примеры сценариев для мониторинга определенных событий и пересылки почтового сообщения на указанный адрес при каждом таком событии. Сценарий не расходует ресурсы центрального процессора во время ожидания события, и администратор может легко изменить WMI-запрос, который описывает события, обрабатываемые сценарием. В WMI-запросах используется команда SQL Select, аналогичная командам, из которых построены запросы Microsoft Access. Проблема заключается в отборе сообщений, которые должны генерировать предупреждение. Если не соблюдать осторожность, пейджер или входной почтовый ящик будут переполнены не слишком важными сообщениями.

Приступая к подготовке критерия для отправки предупреждений, необходимо использовать инструмент для сбора информации из журналов событий. Лучший инструмент для опроса журналов событий — Log Parser компании Microsoft. Log Parser позволяет направлять запросы к журналу событий с использованием оператора Select, похожего на запрос WMI, но более удобного для опроса существующих журналов. Я опубликовал несколько статей о Log Parser с примерами запросов, которые можно адаптировать к конкретной ситуации. Задача администратора — составить один или несколько запросов для журнала событий каждого типа (например, Application, Security, System), чтобы отфильтровать незначительные события, но сообщать о чрезвычайных происшествиях. Я рекомендую извлекать из журнала Security наиболее типичные и важные события, приведенные в табл. 3. Примерный вид запроса:

logparser "select
TimeGenerated,EventID,Message
from mtg1security where
EventID in (675;676;
681;642;624;644;617;632;660;636)"

Мониторинг других журналов

Для других журналов событий (например, Application, System) я рекомендую составлять отчет, начиная с поиска предупреждений и ошибок, игнорируя информационные сообщения. И даже после этого остается много незначительных предупреждений и сообщений об ошибках. Например, я получаю много ошибок из источника MRxSmb, который можно смело игнорировать. Поэтому следующий шаг — идентифицировать события, которые представляют собой «шум», и исключить их с помощью предложения Where в запросе Log Parser. В следующую команду добавлено выражение, которое исключает событие ID 3019 для источника MRxSmb и информационные сообщения из любого другого источника (EventType < 4):

logparser "select
TimeGenerated,EventID,Message
from system where
EventID<>3019 and SourceName
<>'MRxSmb' and EventType < 4"

Следует помнить, что журналы событий достигают очень больших размеров. Кроме того, EVT-файлы не имеют индексации, которая обеспечивает быстрый поиск информации без просмотра всего журнала. На подготовку отчета Log Parser может уйти немало времени, так как программе каждый раз приходится просматривать весь журнал событий. К счастью, благодаря контрольным точкам Log Parser помнит, где закончился прошлый просмотр.

Задача мониторинга журналов событий Windows усложняется из-за того, что у каждого компьютера есть собственный набор журналов и не существует естественного способа собрать их воедино. Если нет инструмента, который объединял бы журналы в одной центральной базе данных для рассылки предупреждений и мониторинга, существует два варианта решения проблемы. Если предстоит управлять лишь немногочисленными серверами и устройствами, то можно просто назначить предупреждения и отчеты для каждой машины. Более централизованный подход — использовать возможность Log Parser опрашивать несколько компьютеров. Необходимо лишь перечислить журналы событий каждого компьютера в предложении From. Например, следующая команда опрашивает журнал System на машинах server1, server2 и server3.

logparser "select
TimeGenerated,EventID,Message
from server1system,
server2system,
server3system"

После того как будут составлены один или несколько отчетов для журнала каждого типа, можно готовить их ежедневно или еженедельно по расписанию. Достаточно перенаправить выход Log Parser в текстовый файл, добавив к приведенной выше команде

«> C:pathfile.txt»

а затем регулярно просматривать этот файл. Еще лучше пересылать полученный файл по электронной почте администратору. Для этого следует добавить одну строку в командный файл, для вызова Blat. С помощью общедоступной утилиты Blat удобно пересылать файлы по электронной почте через SMTP.

Настроив отчеты, можно приступать к проектированию критериев предупреждения. Было бы очень хорошо, если бы все поставщики приложений и устройств документировали события и сообщения, генерируемые их продуктами. В таком случае администраторы могли бы сделать осознанный выбор, но в жизни ничего не дается легко, поэтому приходится действовать «на ощупь». Выбор критерия напоминает процесс составления отчетов, описанный выше. Однако следует быть более разборчивым при выборе предупреждений, посылаемых на пейджер или в свой почтовый ящик. В большинстве программ предупреждения можно строить как фильтры Exclude, Include, а затем применять их последовательно, удаляя мелкие события. Если используется WMI, то можно задействовать предложение Where для фильтрации большинства ненужных событий. Если возможностей предложения Where оказывается недостаточно, можно построить дополнительный фильтр с применением сценария VBScript.

Я рекомендую использовать Log Parser для подготовки критериев предупреждения, вместо того чтобы назначать предупреждения, а потом настраивать их до тех пор, пока на пейджер не будет поступать только нужная информация. Используя информацию о событиях, уже собранную в журналах, следует начать с тех же критериев, которые применяются для отчетов, и уточнять их, отбрасывая менее значимые события, не заслуживающие предупреждения. Если собраны данные примерно за месяц, то такой подход, в сущности, позволяет моделировать обработку предупреждений за длительный период времени, чтобы оценить количество поступающих предупреждений. После того как будет найден приемлемый критерий в форме отчетов Log Parser (или другого инструмента подготовки отчетов), можно преобразовать критерий в запросы WMI внутри сценариев VBScript. Чтобы сценарии предупреждений были постоянно активны, можно настроить их на запуск в процессе начальной загрузки компьютера. Сценарии начальной загрузки можно разместить в любом объекте групповой политики Group Policy Object (GPO) в разделе настройки политик Computer ConfigurationWindowsSettingsStartup and Shutdown Scripts. Сценарии, активизируемые при начальном запуске, работают в контексте локальной учетной записи System, поэтому у них имеются все необходимые полномочия.

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

Мониторинг текстовых журналов

Большинство серверных продуктов Microsoft и компонентов Windows протоколируют любые важные события в журналах System или Application, но каждая служба или основной компонент операционной системы (например, IIS, DHCP, SMTP, Internet Authentication Service, IAS) записывают более подробную информацию в собственный текстовый журнал в специальном формате. Для мониторинга информации, имеющейся только в этих текстовых файлах, удобно использовать Log Parser. Log Parser распознает любой формат текстового файла с разграничителями, например с символами табуляции или запятыми (CSV), и позволяет задействовать ту же команду SQL Select для опроса текстовых файлов журналов.

Таким образом, с помощью Log Parser можно решить задачу подготовки отчетов на основе текстовых журналов. Но что делать с поступающими в реальном времени предупреждениями о критических событиях, информация о которых хранится в текстовых файлах? Я рекомендую воспользоваться инструментом tail, заимствованным из UNIX. Tail отслеживает добавление новых строк в указанные пользователем текстовые файлы. Как только обнаруживаются новые данные, tail посылает их в стандартный выходной поток (stdout). Выходные данные tail можно направить в сценарий, который анализирует новые записи по мере их протоколирования и при необходимости генерирует предупреждения. Например,

tail /f logfile.txt |
LoopOnNewMessages.cmd

обнаруживает новые сообщения, добавленные в файл logfile.txt, и направляет их в LoopOnNewMessages.cmd, показанные в листинге 1. Loop OnNewMessages.cmd передает каждое сообщение по адресу rsmith@ultimatewindowssecurity.com, но вместо него можно указать любой другой почтовый адрес. Чтобы не пересылать не слишком существенные сообщения, можно дополнить сценарий фильтрующей логикой. Более подробно о tail рассказано во врезке «Такой полезный Tail».

Мониторинг SNMP и журналов Syslog

Контролировать телеметрические источники SNMP и Syslog легко благодаря бесплатной версии программы Kiwi Syslog Daemon компании Kiwi Enterprises. Этот диспетчер серверов Windows Syslog и SNMP позволяет собрать все телеметрические данные о сетевых устройствах в одной программе. Из графического интерфейса программы можно настроить фильтры для сбора сообщений, отвечающих определенным критериям, а затем указать одно или несколько действий, предпринимаемых в ответ на сообщение. Можно построить фильтры для удаления ненужных сообщений и указать, что оставшиеся сообщения должны генерировать предупреждение или сохраняться в базе данных для последующих отчетов. С помощью Kiwi Syslog Daemon можно фильтровать сообщения по времени дня, дню недели, устройствам, уровню, IP-адресу отчетного агента или строкам в сообщении. Кроме того, инструмент может выполнять разнообразные действия — оповещение по электронной почте, сохранение в базе данных по ODBC, запуск программы и другие — в ответ на указанные события.

Бесплатная версия Kiwi Syslog Daemon интерактивно работает в настольном компьютере, поэтому администратор должен зарегистрироваться, чтобы контролировать устройства. Но расширенная версия продукта функционирует как служба, а ее стоимость — всего 100 долл. для одного сервера. Если активизировать мониторинг ловушек SNMP, необходимо также указать поля Facility и Level, которые используются инструментом при преобразовании ловушки в сообщение Syslog. Например, можно указать ловушки SNMP как Facility Local4 и Level 3 Error. Затем можно составить правила рассылки предупреждений специально для ловушек SNMP путем фильтрации сообщений Local4.

Покупать или строить?

Итак, существуют ресурсы для мониторинга разнообразных источников телеметрических данных. Прежде чем начать проектировать собственное решение для мониторинга, полезно познакомиться с инструментами, которые есть на рынке. Они доступны и полнофункциональны. Однако нельзя получить полное решение, просто приобретая инструмент. Нужно определить критерии для отчетов и предупреждений, чтобы не получать слишком много сообщений о незначительных событиях, но не следует впадать в другую крайность и задавать столь строгие критерии, что решение мониторинга может помешать выполнению той самой задачи, для которой оно предназначалось. Для достижения баланса следует составлять критерии, отсекая незначительные, а не выбирая важные события. Единственное исключение из этого правила — журнал Security, который гораздо короче, а кроме того, лучше документирован. Полная база данных событий журнала Security и их значений опубликована в Security Log Encyclopedia на сайте Ultimate Windows Security (www.ultimatewindowssecurity.com).

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

Рэнди Франклин Смит - Редактор Windows IT Pro и ведущий инструктор и разработчик курсов для программы по безопасности Windows NT/2000 института MIS Training. Его компания, Monterey Technology Group, занимается консалтингом в области информационной безопасности. Связаться с ним можно по адресу: rsmith@monterey techgroup.com

Такой полезный Tail

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

Tail имеется в большинстве систем UNIX, а версию Win32 можно загрузить в рамках принятия условий лицензии GNU с Web-узла Sourceforge (http://unxutils.sourceforge.net). Сначала нужно загрузить файл UnxUpdates.zip, а затем извлечь tail.exe в своем компьютере.

Автономное использование Tail

При использовании вне комбинации с другими программами, tail показывает несколько последних строк текстового файла. С помощью нескольких параметров можно изменить представление информации на экране. Особенно полезен параметр follow (-f), который позволяет непрерывно отслеживать и выводить на экран изменения в текстовом файле. Например, команда

tail -f ex050410.log

показывает последние 10 строк журнального файла с именем ex050410.log и будет отслеживать и отображать новые записи по мере их появления. Если файл представляет собой журнал Web-службы Microsoft IIS и кто-нибудь обращается к Web-узлу, IIS сделает в журнале новую запись. Новые добавления немедленно отображаются на консоли, в которой работает tail. Этот параметр упрощает диагностику, позволяя немедленно увидеть новые записи.

Совместное применение Tail и Grep

Как известно, grep — программа, которая ведет поиск указанных последовательностей символов в целевом текстовом файле. Например, при диагностике компьютера, который работает с Windows Firewall, требуется отыскать в журнале брандмауэра действия, совершенные в определенный день. Журнал не разделен по датам и довольно велик.

С помощью grep можно извлечь строки данных от 7 марта 2005 года и записать их в новый текстовый файл:

grep «2005-03-07» p-firewall.log
> 030705p-firewall.log

Как насчет tail? Команду можно использовать для обработки журналов брандмауэра в процессе диагностики или отслеживания атак в реальном времени. Но можно применить tail вместе с grep, чтобы выводить на экран только определенные данные.

Для начала следует настроить брандмауэр на запись журналов в текстовый файл. Все системы UNIX используют syslog для протоколирования событий; большинство коммерческих брандмауэров также поддерживают syslog. Если на системе UNIX используются grep и tail, то следует настроить брандмауэр на пересылку данных syslog в хост-машину syslog. Пользователи Windows могут установить и работать с сервером syslog на базе Windows. Я рекомендую Kiwi Syslog Daemon фирмы Kiwi Enterprises, отличный инструмент для сохранения данных syslog в текстовом файле.

Затем нужно построить шаблон на основе синтаксиса поставщика брандмауэра. Например, администратор использует брандмауэр Cisco PIX и хочет получать оповещения каждый раз, когда кто-то обращается к Web-службам через брандмауэр. С помощью tail и grep можно в реальном времени обнаруживать в журналах символы «/80» (представляют Web-трафик в журнале PIX), например:

tail -f pix.log | grep «/80»

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

tail -f pix.log | grep
/80[[:space:]]

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

Усложненный Tail

Grep и tail — простые в использовании и очень гибкие программы. При работе с консольными приложениями оба инструмента значительно упрощают анализ журнальных файлов и повседневное администрирование. Версия командной строки tail — быстрая и простая в эксплуатации, и, вероятно, сторонники строгих правил предпочтут ее благодаря простоте и возможности пересылать выходные данные в другие программы, такие как grep. Но существуют версии tail с графическим интерфейсом Windows, причем некоторые из них наделены более сложными функциями, например цветным выделением совпадающих последовательностей. Такое форматирование помогает отмечать важные файлы.

Образец бесплатной графической программы tail для Windows — BareTail компании Bare Metal Software (ее можно загрузить по адресу http://www.baremetalsoft.com/baretail). Как и tail, BareTail отображает текстовый файл и отслеживает дополнения к файлу, но поскольку BareTail работает с графическим интерфейсом, она располагает функциями выделения.

Благодаря таким функциям проще обнаружить определенный текст (например, конкретный IP-адрес или порт) «на ходу», наблюдая за журналом брандмауэра. Можно также изменить шрифт, без труда скопировать строку текста и открыть недавно просмотренные файлы журналов с помощью списка недавно использованных файлов Windows.

Джеф Феллинг - Директор по информационной безопасности компании Quantive. Автор книги IT Administrator?s Top 10 Introductory Scripts for Windows (издательство Charles River Media). jeff@blackstatic.com