daemon klogd $KLOGD_OPTIONS
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/syslog
return $RETVAL
}
stop() {
# Команды остановки сервиса
}
rhstatus() {
# Команды вывода состояния
}
restart() {
stop
start
}
...
...
Самое интересное спрятано в следующих строчках:
if [ -f /etc/sysconfig/syslog ] ; then
. /etc/sysconfig/syslog
else
SYSLOGD_OPTIONS="-m 0"
KLOGD_OPTIONS="-2"
fi
Здесь происходит проверка. Если файл /etc/sysconfig/syslog существует, то используются опции загрузки из этого файла, иначе явно задаются в строке:
SYSLOGD_OPTIONS="-m 0"
Здесь в кавычках указываются параметры. Чтобы добавить ключ -r, измените строку следующим образом:
SYSLOGD_OPTIONS="-m 0 -r"
Если файл /etc/sysconfig/syslog существует, то в нем будет такая же строка, и вам достаточно внести изменения туда, и не надо будет трогать сценарий запуска /etc/rc.d/init.d/syslog.
Использование выделенного сервера для сохранения сообщений из журналов позволяет как скрыть записи, так и сделать их доступными для всеобщего просмотра. Дело в том, что сообщения передаются по сети в незашифрованном виде. Это не проблема, если вы отделены от Интернета сетевым экраном и злоумышленник не смог проникнуть внутрь сети. Но если ему удалось взломать хотя бы один компьютер в защищенной сети, то хакер может установить программу прослушивания и увидеть все сообщения в журналах.
Вопрос решается достаточно просто, если зашифровать трафик, направив его через туннель SSL. Самый простой вариант — выполнить следующие действия:
□ на сервере, отправляющем сообщения, в конфигурационном файле прописываем пересылку сообщений на локальный компьютер:
*.* @localhost
□ все сообщения будут передаваться на локальный компьютер, т.е. самому себе на 514 порт UDP. Чтобы все работало верно, сервер не должен находиться в режиме приема сообщений, т.е. запущен без ключа -r. Иначе порт 514 будет занят, а нам это не нужно;
□ на 514 порту локального компьютера запускаем stunnel-клиент:
stunnel -c -d 127.0.0.1:514 -r loagserver:1050
Все сообщения, полученные на этот порт, будут шифроваться и передаваться на порт 1050 компьютера loagserver. В вашем случае вместо имени loagserver нужно указать адрес вашего сервера;
□ на компьютере loagserver создаем stunnel-сервер:
stunnel -d 1050 -r 127.0.0.1:514
После этих действий stunnel-сервер будет получать зашифрованные сообщения на 1050 порт и в расшифрованном виде направлять их на порт 514. На сервере loagserver сервис syslogd должен быть запущен с ключом -r для приема сообщений на 514 порту.
Теперь все сообщения будут передаваться по сети в зашифрованном виде.
12.5.7. logrotate
Чтобы файлы журнала слишком сильно не раздувались, в Linux включена утилита logrotate. Рассмотрим принцип ее работы на примере журнала /var/log/messages:
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
}
В данном случае после первой смены журнала будет выполняться сценарий отправки этого файла на почтовый ящик администратора.
Если вы настраиваете сервис таким образом, убедитесь, что ваш почтовый ящик способен принять необходимое количество данных. Например, если вы установили максимальный размер файла в 10 Мбайт, а ваш почтовый ящик способен принять только 5 Мбайт, то вы никогда не получите этот файл, он будет удален почтовым сервером.
12.5.8. Пользовательские журналы
Все команды, которые выполняются пользователем, сохраняются в файле .bash_history (если используется интерпретатор команд /bin/bash), который находится в пользовательской домашней директории. Когда вы определили, под какой учетной записью в системе находился взломщик, его действия можно проследить по этому журналу.
