Часть 3. Просмотр логов^*. Проблемы интерпретации. Просмотр логов.

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

• "Родное" программное обеспечение для просмотра логов — обычно умеет показывать самую нужную информацию в отформатированном и удобном виде. Кроме того, встречаются такие полезные функции, как уведомление о критических событиях, фильтрация различных видов (по времени, по важности событий и т. п.). Иногда бывает, что производительно поставляет какую-нибудь программку, которая позволяет сделать дамп логов в какой-то момент, то есть получить текстовую копию логов. Это очень удобно в случае базы данных или бинарного лога. В той или иной форме сделать дамп бинарного лога или таблицы с логами из базы данных бывает довольно легко. Программы, которые позволяют это сделать, часто включены в дистрибутив самого приложения, которое пишет логи: MS SQL Server, к примеру, имеет программу bcp, которая позволяет передать базе данных SQL-запрос, результаты которого будут выведены в файл; в IBM DB2 UDB аналогичная программа — db2audit. Специализированное ПО для просмотра логов обычно интегрируется в комплекс, который позволяет создавать различного рода отчеты, которые выполняются с учетом специфических требований. Например, довольно важным этапом в анализе сетевой активности является учет событий, которые относятся к авторизации и аутентификации. Грамотно созданный отчет позволяет за очень короткое время проводить полный анализ событий, произошедших за очень длительный срок. Такой отчет не будет включать лишние данные, которые своей массой способны просто скрыть реальную картину.
• Специализированное ПО — это не только удобное представление самих логов, но и их детальный автоматический анализ
  Программное обеспечение от сторонних разработчиков — кроме узкоспециализированного ПО, которое умеет работать с логами одного конкретного приложения (всевозможные анализаторы логов squid, apache, ipfw и т. п.), есть еще и крупные программные продукты, которые поддерживают десятки и сотни различных форматов. Примерами являются проект Sawmill, который в самой полной своей версии поддерживает более 500 различных форматов логов, или проект Consul InSight Suite (ныне принадлежит компании IBM), который предоставляет даже не саму возможность просмотра логов, а куда более необходимые возможности мониторинга и анализа активности в корпоративной сети. У стороннего программного обеспечения может наблюдаться ряд проблем, которые связаны с тем, что сторонний разработчик при всем своем желании все же не всегда знает всю специфику логов. Иногда отдельные нюансы, которые ускользнули при разработке, проявляются неожиданным образом в работе. В то же время комплекс, который способен работать с аудит-информацией нескольких десятков приложений одновременно, является насущной необходимостью для администраторов, которые занимаются безопасностью. Следует отметить, что дополнительной и очень важной возможностью таких продуктов является то, что отчеты, ими генерируемые, способен понять человек, который не обладает специфическими знаниями в области операционных систем, сетей и систем безопасности. К примеру, продукт Consul InSight генерирует отчет с так называемыми нормализованными событиями, то есть данные в отчетах нормализованы так, чтобы сходные события на различных системах представлялись пользователю в сходном виде (например, вне зависимости от специфики системы или конкретного приложения информация о том, что пользователь зашел в систему, всегда будет описана в абсолютно одном и том же виде). Для удобства представления используется модель, которая абсолютно любое событие любой системы или программы представляет в виде набора определенных полей, которые полностью отвечают на следующие вопросы: какое произошло событие, когда оно произошло, где оно произошло, от чьего имени были выполнены действия, какой объект был подвержен воздействию и т. п. Зная, что все события нормализованы, процесс анализа событий в сети становится совершенно абстрактным, то есть для интерпретации данных становится совершенно неважно, какое приложение и в каком формате записало конкретное событие в лог.
• Довольно часто бывает так, что производитель не предусмотрел никакого приложения для просмотра логов. Если к тому же нет сторонних программ, которые могут помочь, то остается только брать самые обычные средства (текстовый редактор для текстовых логов или клиент базы данных, если речь идет о СУБД) и изучать логи вручную. В таком случае важно запастись необходимым инструментарием.

1. Текстовый редактор. Важны следующие функции: умение переключать основные используемые кодировки текста, умение показывать логи как целыми строками, так и с переносом по словам, умение просматривать бинарные файлы в шестнадцатеричном виде и т. п.
2. Удобное программное окружение, в котором удобно работать с большим количеством логов, то есть искать определенное слово в нескольких десятках файлов, сортировать большие массивы данных и т. п. К примеру, большинство задач работы с текстовыми логами удобно решаются в UNIX/Linux-системах. В MS Windows для этого подходят пакеты Cygwin или Utilities and SDK for Subsystem for UNIX-based Applications in Microsoft.
3. Различного рода клиенты баз данных. Желательно, чтобы была возможность писать запросы к базе данных вручную, такая возможность может понадобиться для создания различных выборок и отчетов из всей массы событий.

Список инструментов можно продолжать еще очень долго, так как для выполнения конкретных типовых задач (например, анализ логов apache) вполне могут существовать уже готовые решения, которые куда лучше, чем простой текстовый редактор.

О наболевшем: "Кодировки — зло XXI века" (Stellar).

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

1. Идеальный лог пишется всегда и везде в одной и той же кодировке
   Идеальный лог. Пишется всегда и везде в одной и той же кодировке. Хорошо, если это UTF-8. В настоящий момент это самый удобный случай, который позволяет читать и работать с логами практически на любой системе вне зависимости от того, где были сгенерированны логи. Вызывает минимум проблем и отлично поддерживается различным сторонним ПО. Примером может служить Blue Coat Systems’ Proxy GS – логи пишутся только в UTF-8, что серьезно облегчает жизнь. Или IBM Tivoli Identity Manager, инсталляционная программа которого требует, чтобы база данных была в кодировке UTF-8. Так как эта же база данных используется для логирования, то и вся информация пишется в UTF-8. В принципе, какая бы ни использовалась кодировка, главное, чтобы она была одна и та же на всех системах, при любых региональных и языковых настройках.
2. Используется кодировка из переменной окружения, в котором работает приложение. Встречается довольно часто. Вызывает массу проблем с тем, что различные системы склонны использовать экзотику и нестандартные решения. Примером может служить уже упоминавшийся Tivoli Access Manager for e-Business, у которого кодировка зависит от региональных настроек системы и определяется переменной окружения LANG (как на UNIX-системах, так и на MS Windows), или Novell Audit 2.0, в котором кодировка зависит от используемой для хранения логов базы данных.
3. Если для хранения событий используется база данных, то довольно часто используемая кодировка зависит от версии и типа продукта. К примеру, Oracle старше девятой версии для хранения событий Fine-Grained Audit (FGA) использует кодировку UTF-8, а более старые версии использовали информацию, взятую из системы. В иных базах данных все может определяться специфическими настройками на каждую базу данных или зависеть от типа данных, который используется для хранения той или иной информации.

Следует отметить, что различия в кодировках оказывают мало влияния на основные данных (event ID, имя пользователя, IP-адрес и т. п.), но дополнительные поля, в которых довольно часто содержится информации на национальных языках, страдают часто. Как правило, дополнительные поля, которые содержат описание, а не ID события или IP-адрес, являются довольно важными для тех, кто интерпретирует данные вручную. Ибо в таких случаях обычно о событии судят как раз по текстовому описанию (которое, к слову, бывает довольно расплывчатым). Именно в таких случаях проблемы с распознаванием кодировки могут стать препятствием к работе с логами.

Немного примеров. Объять необъятное довольно тяжело, но некоторые примеры могут показать некоторую специфику:

1. Symantec Antivirus. Смысл события понятен: закончено сканирование. Событие содержит информацию о дате (закодировано 2300020B1139), пользователе (User1), компьютере (USER1-XP):

2300020B1139,2,2,0,USER1-XP,User1,,,,,,,16777216,"Scan Complete: Threats:0 Infected:0 Scanned:259219 Files/Folders/Drives

2. Oracle Database Audit Trail (в текстовом представлении). Информация о пользователе (USER1), компьютере (USER1-XP), времени (2006-07-04 13:03:00) и текстовая информация о событии:

7016;1;1;;USER1;USER1-XP;;101;0;;;;;;;;;6821;0;2550;0;2006-07-04 13:03:00;"Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=172.16.10.158)(PORT=3050))";;;;;;5;18;2006-07-04 10:02:59;;;0;1840:1916;;;;;;;

3. MS SQL Server C2 Audit (в текстовом представлении, копия в текстовый файл сделана через bcp). Информация о пользователе (DOMAIN\User1), компьютере-источнике (клиент USER1-XP), компьютере-сервере (USER2-XP), времени (2006-03-09 17:01:27.507), ресурсе (mssqlsystemresource) и сам SQL-запрос к базе данных:

1|DOMAIN\User1|USER1-XP|configurations|USER2-XP|mssqlsystemresource|114|2006-03-09 17:01:27.507|select @show_advanced = cast(value_in_use as bit) from sys.configurations where name = N'show advanced options'

4. Linux Syslog. Очень кратко, но все по теме и в комментариях не нуждается:

<4>May 31 10:14:01 172.16.10.250 kernel: VFS: Mounted root (ext2 filesystem).

5. SAP R3. Совсем все закодировано, интерпретировать можно только с документацией в руках:

AUJ200104241915300019859 3D3cherryan A-CMATEW SM19 SAPMSM19 10011

6. Cisco PIX. Тоже вроде все понятно:

11-09-2002,09:47:37,192.168.0.1,192.168.0.1,LOCAL4,INFO,Sep 11 2002 22:52:45: %PIX-1-101001: PCadown TCP connection 788443 faddr 211.142.171.111/3899 gaddr 211.129.125.114/443 laddr 192.168.0.2/443 duration 0:00:04 bytes 3834 (TCP FINs)

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