1. Когда размер файла /var/log/messages превышает максимально допустимое значение или проходит определенный промежуток времени, содержимое текущего журнала переносится в файл /var/log/messages.1, а файл /var/log/messages очищается и заполняется заново.
2. В следующий раз, при достижении максимального размера, содержимое файла /var/log/messages.1 переносится в /var/log/messages.2, а из журнала /var/log/messages — в /var/log/messages.1.
Таким образом, история изменений сохраняется в отдельных файлах, и ее можно всегда просмотреть, при этом сам журнал никогда не превысит определенного размера, и с ним будет удобно работать.
За сохранение истории и перенос данных между файлами отвечает программа
logrotate
. Рассмотрим ее конфигурационный файл (/etc/logrotate.conf), который показан в листинге 12.5.
Листинг 12.5. Файл конфигурации программы /etc/logrotate.conf
# see "man logrotate" for details
# Выполните команду man logrotate для получения дополнительной информации
# rotate log files weekly
# Смена файлов происходит еженедельно
weekly
# keep 4 weeks worth of backlogs
# Будут использоваться 4 файла для сохранения истории
rotate 4
# create new (empty) log files after rotating old ones
# После сохранения журнала создается пустой новый файл
create
# uncomment this if you want your log files compressed
# Уберите комментарий со строки compress,
# чтобы файлы журналов сжимались
#compress
# RPM packages drop log rotation information into this directory
# Пакеты RPM переносят информацию о смене журнала в эту директорию
include /etc/logrotate.d
# no packages own wtmp -- we'll rotate them here
# для журнала /var/log/wtmp задаются собственные правила
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
# system-specific logs may be also be configured here.
# специфичные системные журналы могут быть сконфигурированы здесь
Посмотрим на параметры, которые нам доступны:
□
weekly
— указывает на то, что файлы журналов должны меняться еженедельно. Если сервер используется редко, то можно изменить это значение на
monthly
, чтобы обновление происходило ежемесячно;
□
rotate
— задает количество файлов, которые будут использоваться для хранения истории. В данном случае стоит число 4, т.е. имена журналов будут иметь вид: /etc/log/имя.X, где X изменяется от 1 до 4;
□
create
— требует создания нового пустого документа после смены файла журнала;
□
compress
— позволяет сжимать файлы журналов. На серверах, обрабатывающих запросы огромного количества пользователей, журналы могут занимать очень много места, и чтобы сэкономить дисковое пространство, их можно сжимать. Так как журналы содержат текст, компресс-версия может иметь объем на 70 % (и даже более) меньше.
В начале файла идут описания значений по умолчанию. Затем можно указать специфичные значения для определенных журналов. В данном конфигурационном файле выделен журнал /var/log/wtmp:
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
В данном файле нет ограничения на размер журнала, но его можно задать с помощью параметра
size
. Например, в следующем примере задается максимальный размер журнала в 100 Кбайт:
/var/log/wtmp {
monthly size = 100k
create 0664 root utmp
rotate 1
}
Теперь файл журнала будет меняться в двух случаях (по событию, которое наступит раньше):
□ ежемесячно, т.к. указан параметр
monthly
;
□ когда файл достигнет размера 100 Кбайт.
За счет смены журналов мы получаем как удобства, так и недостатки. Например, после проведения атаки хакер может уничтожить свои следы, даже если не имеет непосредственного доступа к файлам журнала. Достаточно только засыпать журнал мусорными сообщениями и превысить максимальный размер, чтобы система четыре раза произвела ротацию.
Пытаться защищать журнал, увеличивая его размер до бесконечности, бесполезно, потому что хакер не будет добавлять записи в log-файл вручную, а воспользуется простой программой на Perl или написанной прямо из командного интерпретатора (Shell). Такая программа чрезвычайно проста. Достаточно только в цикле выполнять команду:
logger -р kern.alert "Текст сообщения"
С помощью директивы
logger
можно записывать в журнал сообщения. Если организовать бесконечный цикл выполнения этой команды, то система сама уничтожит журнал.
Чтобы данные не исчезали бесследно, можно добавить команду, которая будет отправлять журнал на почтовый адрес администратора:
/var/log/wtmp {
monthly
size = 100k
create 0664 root utmp
postrotate
# Команда отправки журнала имя.1
endscript
rotate 1
}
В данном случае после первой смены журнала будет выполняться сценарий отправки этого файла на почтовый ящик администратора.