Это далеко не полный результат. Даже если в данный момент вы один работаете с системой, количество открытых файлов может исчисляться парой десятков, и число их заметно растет, если в системе несколько пользователей, ведь один файл может открываться несколько раз каждым из них. Это касается в основном системных конфигурационных файлов.
12.5.2. Системные текстовые журналы
Представленные в этом разделе журналы — это текстовые файлы. Их можно без проблем просматривать такими командами, как cat, или любыми текстовыми редакторами.
В файле /var/log/messages находится основная информация о заходах пользователей, о неверных авторизациях, остановках и запусках сервисов и многое другое. В один документ все подобные события поместиться не могут, иначе он будет нечитаемым, поэтому в папке /var/log/ могут находиться файлы с именами messages.X, где X — это число.
Этот журнал один из самых главных для любого админа. Если взломщик пытается подобрать пароль, то вы сможете заметить быстрый рост этого файлам появление большого количества записей о неверной авторизации. На рис. 12.1 показан пример содержимого файла.
Рис. 12.1. Снимок экрана с открытым файлом /var/log/messages
Следующий журнал расположен в файле /var/log/secure. Что в нем такого особенного? Это самый основной журнал, который нужно проверять максимально часто, и каждой записи следует уделять особое внимание. В этом файле отображается, под каким именем и с какого адреса пользователь вошел в систему. Например, на сервис FTP может подключаться главный бухгалтер. Если вы увидели, что он пользуется сервисом, но при этом журнал показывает чужой IP-адрес, то это может стать поводом для беспокойства.
В этом же файле отображается информация а внесении изменений в список пользователей или групп. Злоумышленники очень редко используют запись root для своих злобных целей и заводят какую-нибудь более незаметную, с нулевым идентификатором. Если это сделано не руками, а с помощью команды Linux, то вы в журнале /var/log/secure увидите подозрительные изменения.
Хакеры, конечно же, знают о таких уловках, поэтому корректируют список вручную, ведь это не так уж и сложно — добавить по одной записи в файлы /etc/passwd и /etc/shadow. Но даже в этом случае вы почувствуете неладное, когда увидите запись о том, что в систему вошел пользователь, которого вы не создавали.
Но чтобы реагировать на подозрительные записи, вы должны быть внимательны. Самые опытные и крайне опасные хакеры используют очень интересные методы. Например, в вашей системе есть пользователь robert. Хакер видит эту запись и добавляет пользователя с именем rodert. Разница всего лишь в третьей букве, и если быть невнимательным, то это отличие не заметишь, и взломщик будет безнаказанно гулять по вашему компьютеру.
Журнал почтового сервера Sendmail находится в файле /var/log/maillog. В данном файле можно будет увидеть строки примерно следующего вида:
Jan 16 13:01:01 FlenovM sendmail[1571]: j0GA11S01571: from=root, size=151, class=0, nrcpts=1,
msgid=<[email protected]>, [email protected]
Из этого файла вы можете узнать, кто, когда и кому отправлял сообщения.
Вспоминается случай, когда один администратор после того, как взломали его сервер, вручную осматривал все директории на предмет чужих файлов. Не проще ли проанализировать журнал, где все записано. Если злоумышленник не подчистил журналы до выхода из системы, то можно узнать достаточно много.
На журналы надеяться можно, но это не очень надежно. Умные хакеры всегда заметают свои следы и уничтожают ненужные записи из журналов, поэтому ручной осмотр действительно может пригодиться, но первым делом проверьте журнал.
12.5.3. Журнал FTP-сервера
Войдя в систему, взломщики нередко закачивают на сервер собственные программы для повышения своих прав или для открытия потайных дверей. Для закачки можно использовать FTP-протокол. Кто подключался к серверу можно узнать из файла /var/log/secure. А вот что закачивали — подскажет /var/log/xferlog. О журнале FTP-сервера мы уже немного говорили в разд. 10.3. Теперь познакомимся с ним поближе.
Журнал FTP-сервера текстовый, как и у почтового сервера, но мы его рассматриваем отдельно. Из моей практики, если вы используете сервис FTP, то именно он чаще всего приводит к проблемам. Нет, программа достаточно хороша, но злоумышленник, как правило, стремится получить доступ к учетной записи с правами на FTP, чтобы иметь возможность размещать свой боевой софт на сервере. С помощью анализа журнала вы быстро узнаете, кто и что закачивал.
Посмотрим на пример содержимого файла /var/log/xferlog:
Sun Jan 16 13:21:28 2005 1 192.168.77.10 46668 /home/flenov/sendmail.cf b _ o r flenov ftp 0 * c
Из данной строки видно, что 16 января в 13:21 пользователь с адреса 192.168.77.10 скачал файл /home/flenov/sendmail.cf.
Протокол FTP является наиболее опасным, потому что через него злоумышленник может скачать секретные данные (например, файл с паролями) или положить на сервер свою программу (в частности, rootkit или трояна). Необходимо научиться понимать каждую запись, чтобы знать, что происходит с файлами в системе. Давайте рассмотрим каждый параметр в журнале:
□ полная дата, которая состоит из дня недели, месяца, числа, времени и года;
□ продолжительность сеанса или время, потраченное на скачивание/закачивание файла;
□ имя или IP-адрес удаленного хоста;
□ размер файла в байтах;
□ полный путь к файлу, который был скачен или закачен;
□ тип передачи — буква a (символьная) или b (бинарная);
□ символ, определяющий специальные действия над файлом:
• C — сжат;
• U — разархивирован;
• T — обработан программой tar;
• _ — не было никаких действий;
□ символ, определяющий направление передачи: о (скачивание с сервера) или i (закачивание на сервер);
□ символ, определяющий тип пользователя: a (анонимный), g (гость) или r (действительный);
□ локальное имя пользователя. Для анонимных пользователей здесь можно увидеть номер ID;
□ имя сервиса, обычно это слово ftp;
□ способ аутентификации. Здесь можно увидеть 0, если определение подлинности отсутствовало, или 1 для идентификации по RFC 931;
□ идентификатор пользователя. Если он не определен, то можно увидеть звездочку;
□ символ, определяющий состояние передачи: с (прошла успешно) или i (была прервана).
Если вы никогда не работали с журналом FTP, то советую сейчас остановиться на минуту и внимательно изучить строку примера, показанную выше, и записи из вашего журнала. Вы всегда должны подходить к проблеме уже подготовленными, а не изучать ее после появления, иначе вы проиграете.
12.5.4. Журнал прокси-сервера squid
Основным журналом прокси-сервера squid является /var/log/squid/access.log. Это текстовый файл, в котором каждая строка состоит из следующих полей:
□ время начала соединения или события;
□ продолжительность сессии;
□ IP-адрес клиента;
□ результат обработки запроса. Здесь может быть одно из следующих значений:
• TCP_HIT — в кэше найдена нужная копия;
• 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. Эти журналы позволяют узнать об активности и доступе пользователей.
