Чтение онлайн

□ полная дата, которая состоит из дня недели, месяца, числа, времени и года;

□ продолжительность сеанса или время, потраченное на скачивание/закачивание файла;

□ имя или IP-адрес удаленного хоста;

□ размер файла в байтах;

□ полный путь к файлу, который был скачен или закачен;

□ тип передачи — буква a (символьная) или b (бинарная);

□ символ, определяющий специальные действия над файлом:

 • 

— сжат;

 • 

— разархивирован;

 • 

— обработан программой tar;

 • 

— не было никаких действий;

□ символ, определяющий направление передачи:

(скачивание с сервера) или (закачивание на сервер);

□ символ, определяющий тип пользователя:

(анонимный), (гость) или (действительный);

□ локальное имя пользователя. Для анонимных пользователей здесь можно увидеть номер ID;

□ имя сервиса, обычно это слово

;

□ способ аутентификации. Здесь можно увидеть 0, если определение подлинности отсутствовало, или 1 для идентификации по RFC 931;

□ идентификатор пользователя. Если он не определен, то можно увидеть звездочку;

□ символ, определяющий состояние передачи:

(прошла успешно) или (была прервана).

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

Основным журналом прокси-сервера squid является /var/log/squid/access.log. Это текстовый файл, в котором каждая строка состоит из следующих полей:

□ время начала соединения или события;

□ продолжительность сессии;

□ IP-адрес клиента;

□ результат обработки запроса. Здесь может быть одно из следующих значений:

 • 

— в кэше найдена нужная копия;

 • 

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

 • 

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

 • 

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

 • 

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

 • 

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

 • 

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

 • 

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

 • 

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

 • 

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

 • 

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

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

□ метод запроса —

, , или ;

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

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

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

 • 

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

 • 

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

 • 

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

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

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

Сервер 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, указав другую директорию для хранения журналов. Вот такой простой метод позволяет затуманить мозги большинству взломщиков.

Записью в журналы, находящиеся в директории /var/log, занимаются демоны syslogd и klogd, но в программе setup при настройке автоматически загружаемых сервисов вы увидите только первый. Настройки автозапуска syslogd влияют и на загрузку klogd. Если вы используете изолированную систему или просто не нуждаетесь в протоколировании событий, происходящих в системе, то можете отключить эти сервисы, чтобы они не расходовали процессорное время. Для сервера я не рекомендую этого делать. Если сейчас вы еще не почувствовали необходимость использования журналов, то после первой проблемы или взлома системы увидите все их преимущества.