Михаил Флёнов - Linux глазами хакера
С другой стороны, журналы текстовые и легко читаемые. Любой хакер может просмотреть их. А т.к. в журнале сохраняются пароли, с которыми пользователи получили доступ к серверу, то хакер легко их может вычислить.
Отказаться совсем от ведения журнала нельзя. Но необходимо сделать все возможное, чтобы он не был доступен злоумышленнику. Как минимум, я всегда изменяю расположение журнала по умолчанию. По моим наблюдениям редко кто смотрит файл httpd.conf, а лезут сразу в каталоги по умолчанию. Если журналов нет, то хакер думает, что они отключены.
Итак, в директории /var/log/httpd создайте пустые файлы access_log, access_log.1, access_log.2, access_log.3, access_log.4, error_log, error_log.1, error_log.2, error_log.3 и error_log.4. Для большей правдоподобности в них можно поместить копию реальных данных, только убедитесь, что там нет важной информации. Правда по дате изменения и по строкам внутри файла злоумышленник легко увидит, что данные старые, но не догадается, что эта информация только для отвода глаз. Главное, чтобы даты изменения файла и формирования записей в нем совпадали.
Для упрощения создания подобных файлов можно на время включить журналы в директории по умолчанию, чтобы они набрали информации, а потом отключить.
После этого измените директивы ErrorLog и CustomLog в файле конфигурации Apache-сервера httpd.conf, указав другую директорию для хранения журналов. Вот такой простой метод позволяет затуманить мозги большинству взломщиков.
12.5.6. Кто пишет?
Записью в журналы, находящиеся в директории /var/log, занимаются демоны syslogd и klogd, но в программе setup при настройке автоматически загружаемых сервисов вы увидите только первый. Настройки автозапуска syslogd влияют и на загрузку klogd. Если вы используете изолированную систему или просто не нуждаетесь в протоколировании событий, происходящих в системе, то можете отключить эти сервисы, чтобы они не расходовали процессорное время. Для сервера я не рекомендую этого делать. Если сейчас вы еще не почувствовали необходимость использования журналов, то после первой проблемы или взлома системы увидите все их преимущества.
Программа syslogd сохраняет в файлах журналов всю информацию о сообщениях системы. Программа klogd предназначена для сохранения сообщений ядра. Настройки журналов находятся в файле /etc/syslog.conf. Пример содержимого файла можно увидеть в листинге 12.3.
Листинг 12.3. Файл конфигурации программы syslogd# Log all kernel messages to the console.
# Logging much else clutters up the screen.
# Выводить все сообщения ядра на экран
# Вывод других параметров создаст на экране беспорядок
#kern.* /dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
# Протоколировать в указанный файл все сообщения
# уровня info и выше
# Исключения составляют письма, сообщения аутентификации и демона cron
*.info;mail.none;authpriv.none;cron.none /var/log/messages
# The authpriv file has restricted access.
# Файл authpriv содержит ограниченный доступ
authpriv.* /var/log/secure
# Log all the mail messages in one place.
# Сохранять все события почтовой системы в указанное место
mail.* /var/log/maillog
# Log cron stuff
# Протоколировать сообщения cron
cron.* /var/log/cron
# Everybody gets emergency messages
# Все получают критические сообщения
*.emerg
# Save news errors of level crit and higher in a special file.
# Сохранять сообщения новостей уровня crit (критический)
# и выше в специальный файл
uucp,news.crit /var/log/spooler
# Save boot messages also to boot.log
# Сохранять сообщения, происходящие во время загрузки в указанный файл
lосаl7.* /var/log/boot.log
Назначение директив легко можно проследить по их комментарию. Все они имеют вид:
название.уровень
В качестве названия выступает имя параметра, который надо протоколировать. Это могут быть следующие категории сообщений:
□ kern — от ядра;
□ auth — о нарушении безопасности и авторизации;
□ authprith — об использовании привилегированного доступа;
□ mail — от почтовых программ;
□ cron — от планировщиков задач cron и at;
□ daemon — генерируются сервисами;
□ user — от пользовательских программ;
□ uucp — UUCP-сообщения (Unix To Unix Copy, копирование с Unix на Unix). В настоящее время практически не используется;
□ news — из новостей;
□ lpr — поступает с принтеров.
Уровень может быть один из следующих:
□ * — протоколировать все сообщения системы;
□ debug — отладочная информация;
□ info — информационные сообщения;
□ notice — уведомления;
□ warn — предупреждения;
□ err — ошибки;
□ crit — критические сообщения;
□ alert — требуется немедленное вмешательство;
□ emerg — авария, дальнейшая работа невозможна.
В журнал попадают сообщения указанного уровня и выше. Например, установка значения err определяет, что в журнал будут попадать сообщения уровней err, crit и emerg.
Чем больше ошибок вы сохраняете, тем выше нагрузка на жесткий диск, да и расход ресурсов увеличивается. Для большей эффективности функционирования системы раздел /var, на котором хранятся журналы, лучше всего перенести на отдельный винчестер. Таким образом, запись в журналы и работа ОС сможет происходить параллельно. Но вы должны быть уверенными, что раздел /var содержит достаточное количество дискового пространства.
Я уже говорил, что в своих системах убираю журналы из расположения по умолчанию, что усложняет хакеру жизнь. Но этого недостаточно. Опытный взломщик просмотрит конфигурационный файл /etc/syslog.conf и найдет новое расположение журналов.
Но мы можем поступить еще умнее, и для этого достаточно штатных средств ОС Linux. В моей системе в сервисе cron установлено задание, по которому каждый час делается резервная копия директории /var. Таким образом, если хакер подчистит журнал, я легко смогу определить его по резервной копии.
Если у вас есть возможность установить в сети еще один Linux-сервер, то можно все сообщения журнала отправлять на специально выделенный компьютер, что будет еще более выгодным. Чтобы хакер смог подправить журнал, ему придется взламывать еще один сервер. А если он используется только для протоколирования и никаких лишних портов на нем не открыто, то взлом может оказаться слишком затруднительным.
Для сброса содержимого журнала по сети в файле /etc/services должна быть доступна строка:
syslog 514/udp
После этого открываем файл /etc/syslog.conf и добавляем следующую строку:
сообщения @адрес
Первый параметр указывает, какие сообщения нужно отправлять на сервер. Если вы хотите пересылать всю информацию, то в качестве этого параметра указывается *.*, если только критические, — то *.crit.
Второй параметр — это адрес сервера, на который будут отправляться сообщения журналов. Если вы хотите, чтобы все сообщения отправлялись на сервер Iog.myserver.com, то добавьте строку:
*.* @log.myserver.com
Но тут есть одна проблема — для определения IP-адреса необходим DNS. При загрузке системы сервис syslogd стартует раньше DNS, поэтому определение адреса окажется невозможным. Чтобы решить эту задачу, соответствие IP-адреса и имени сервера можно прописать в файл /etc/hosts.
И последнее, на сервере служба syslogd должна быть запущена с ключом -r, который позволяет получать сообщения по сети и сохранять их в журнале. Для этого нужно изменить сценарий запуска сервиса. Напоминаю, что все сценарии хранятся в директории /etc/rc.d/init.d/, и для syslogd это файл syslog, основное содержимое которого можно увидеть в листинге 12.4.
Листинг 12.4. Содержимое файла /etc/rc.d/initd/syslog# /bin/bash
. /etc/init.d/functions
[ -f /sbin/syslogd ] || exit 0
[ -f /sbin/klogd ] || exit 0
# Source config
# Загрузка конфигурационного файла
if [ -f /etc/sysconfig/syslog ] ; then
. /etc/sysconfig/syslog
else
SYSLOGD_OPTIONS="-m 0"
KLOGD_OPTIONS="-2"
fi
RETVAL=0
umask 077
start() {
echo -n $"Starting system logger: "
daemon syslogd $SYSLOGD_OPTIONS
RETVAL=$?
echo
echo -n $"Starting kernel logger: "
daemon klogd $KLOGD_OPTIONS
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/syslog
return $RETVAL
}
stop() {
