Методики обработки журнальных файлов
Категория: Система Syslog и журнальные файлы | Автор: admin | 3-12-2009, 06:04 | Просмотров: 3534

У каждой организации свои принципы работы с журнальными файлами. Вот некоторые общепринятые схемы:

  • немедленное уничтожение всей регистрационной информации;
  • сброс журнальных файлов в исходное состояние через определенные промежутки времени;
  • повторное использование журнальных файлов (данные хранятся в течение фиксированного периода времени);
  • сжатие данных и архивирование их на ленту или постоянные носители других типов.

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

Независимо от выбранной схемы процедуру управления журнальными файлами необходимо автоматизировать с помощью демона cron.

 

Уничтожение журнальных файлов

 

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

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

 

Повторное использование журнальных файлов

 

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

В нашей организации мы выделяем под файлы регистрации раздел диска (/var/log) на центральной регистрационной машине. Данные за последнюю неделю не сжимаются, а остальная информация сжимается с помощью программы gzip.

Один из наиболее распространенных методов реализации этой стратегии называется ротация. Ротационная система предполагает хранение резервных файлов с разбивкой по времени создания: файлы однодневной давности двухдневной и т.д. Каждый день файлы переименовываются, в результате чего более старые данные сдвигаются в конец цепочки. Если, например, журнальный файл называется logfile, то резервные копии могут носить имя logfile.l. logfile.2 и т.д. Когда в организации хранится недельный комплект данных, то последняя копия будет называться logfile.7, а файла logfile.8 уже не будет. Каждый день данные в файле logfile.7 пропадают, так как на их место записываются данные из файла logfile.6.

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

#!/bin/sh

cd /var/log

mv logfile.2 logfile.3

mv logfile.l logfile.2

mv logfile logfile.l

cat /dev/null > logfile

chmod 600 logfile

 

Для некоторых журнальных файлов большое значение имеет информация о принадлежности. Возможно, понадобится запускать сценарий ротации средствами демона cron от имени владельца журнальных файлов, а не в качестве пользователя root, или добавить в сценарий команду chown.

В некоторых организациях журнальные файлы классифицируются по датам, а не по порядковым номерам, например logflle.tues или logfile.aug26. Такую систему имен немного труднее реализовать, но усилия окупятся, если необходимость обращаться к старым журнальным файлам возникает довольно часто. Вот самая простая реализация:

mv logfile logfile. date +%Y.%m.%d'

 

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

Некоторые демоны все время держат свои журнальные файлы открытыми. Из-за особенностей работы файловой системы вышеописанный сценарий с такими демонами использовать нельзя: вместо того чтобы направляться во вновь созданный файл logfile, данные регистрации начнут таинственным образом исчезать. Активная ссылка (обращение из какого-либо процесса) на исходный файл позволяет ему оставаться в системе даже после того, как был удален соответствующий элемент каталога и создан новый файл с таким же именем. Файл не исчезает (и занимаемое им дисковое пространство не используется системой) до тех пор, пока не будут закрыты все указывающие на него ссылки. Для того чтобы инсталлировать новый журнальный файл, нужно либо послать демону сигнал, либо уничтожить и перезапустить его.

Вот пример, в котором используется сжатие журнальных файлов и посылается сигнал демону:

#!/bin/sh

cd /var/log

mv logfile.2.gz logfile.3.gz

mv logfile.l.gz logfile.2.gz

mv logfile logfile.1

cat /dev/null > logfile kill -сигнал pid

gzip logfile.1

 

Программа gzip сжимает файл logfile.1, вследствие чего к нему добавляется расширение gz. В поле сигнал указывается соответствующий сигнал для программы, записывающей данные в журнальный файл; поле pid — это идентификатор ее процесса. Сигнал жестко задается в сценарии, а вот идентификатор процесса нужно вычислять динамически: либо путем чтения специального файла (например, /etc/syslog.pid; см. ниже), либо фильтруя результаты работы программы ps. В некоторых системах имеется стандартная команда (такая как skill, написанная Альбертом Кахаланом (Albert Cahalan), или killall, написанная Вернером Альмсбергером (Werner Almesberger); обе входят в состав Red Hat), упрощающая типичную цепочку команд ps-grep-kill .

Каждая программа ведет себя в плане регистрации по-своему. Для того чтобы определить, какие процедуры нужны в каждой конкретной ситуации, обратитесь к той главе, где описана та или иная программа (или к интерактивному руководству).

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

Если в системе нет модуля ротации, советуем воспользоваться Perl-сценарием rotz, написанным Маттом Сегуром (Matt Segur) и Майклом Бернстайном (Michael Bernstein). Он доступен на Web-узле www.admin.com.

Архивирование журнальных файлов

 

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

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



 (голосов: 2)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page