Linux глазами хакера

 • TCP_NEGATIVE_HIT — объект кэширован негативно, получена ошибка при его запросе;

 • TCP_MISS — объект не найден в кэше;

 • TCP_DENIED — отказ в обслуживании запроса;

 • TCP_EXPIRED — объект найден, но устарел;

 • TCP_CLIENT_REFRESH — запрошено принудительное обновление;

 • TCP_REFRESH_HIT — при попытке обновления сервер сообщил, что объект не изменился;

 • TCP_REFRESH_MISS — после попытки обновления сервер вернул новую версию объекта;

 • TCP_REFRESH_HIT — после обновления выяснилось, что объект в кэше свежий;

 • TCP_REF_FAIL_HIT — объект из кэша устарел, а новую версию получить не удалось;

 • TCP_SWAPFAIL — объект должен находиться в кэше, но он не найден;

□ количество байт, полученных клиентом;

□ метод запроса — GET, POST, HEAD или ICP_QUERY;

□ URL-адрес запрашиваемого объекта;

□ поле ident (знак "-", если недоступно);

□ результат запроса к другим кэшам:

 • PARENT_HIT — объект найден;

 • PARENT_UDP_HIT_OBJECT — объект найден и возвращен в UDP-запросе;

 • PARENT — объект запрошен с оригинального сервера;

□ тип содержимого MIME.

Когда в гл. 9 мы говорили о squid-прокси-сервере, то упоминали и о других журналах, например, cache.log и useragent.log.

12.5.5. Журнал Web-сервера

Сервер Apache хранит свои журналы в файлах access.log и error.log, которые расположены в директории /var/log/httpd. Эти журналы позволяют узнать об активности и доступе пользователей.

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

Отказаться совсем от ведения журнала нельзя. Но необходимо сделать все возможное, чтобы он не был доступен злоумышленнику. Как минимум, я всегда изменяю расположение журнала по умолчанию. По моим наблюдениям редко кто смотрит файл 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 — о нарушении безопасности и авторизации;