Михаил Флёнов - Linux глазами хакера

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.

# 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

}

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

Если вы настраиваете сервис таким образом, убедитесь, что ваш почтовый ящик способен принять необходимое количество данных. Например, если вы установили максимальный размер файла в 10 Мбайт, а ваш почтовый ящик способен принять только 5 Мбайт, то вы никогда не получите этот файл, он будет удален почтовым сервером.

Все команды, которые выполняются пользователем, сохраняются в файле .bash_history(если используется интерпретатор команд /bin/bash), который находится в пользовательской домашней директории. Когда вы определили, под какой учетной записью в системе находился взломщик, его действия можно проследить по этому журналу.

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

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

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

Если вы в командной строке набирали директиву и указывали пароль администратора root, то не поленитесь удалить соответствующую запись из пользовательского журнала. Такая ошибка может вам обеспечить не одну бессонную ночь.