Зачистка следов
Ты никогда не задумывался о том, сколько информации о себе ты оставил в системе? Если нет, то зря. А ведь админу системы не составит никакого труда вычислить откуда ты вылез и написать письмо твоему провайдеру, послав кусочек лога. Конечно ситуация меняется если ты сканировал через прокси или логинился в систему по телнету через несколько шелов, но результат на лицо! Моему знакомому однажды сам провайдер прислал логи его CGI сканирования на несколько МБ - наверно трафика жалко стало >).
* примечание:
После сканирования своего сервера на cgi скрипты, я обнаружил, что мой error.log увеличился на 67 кб., база сканера составляла 650 скриптов. Хотя запросы были на меньшее количество информации, но все же представь, сколько КБ проходит через провайдера после сканирования хотя бы 50 сайтов. А таких как ты, в сети тысячи.
Но у нас сегодня другая тема, я бы хотел заострится на вопросе где же все-таки хранятся лог файлы? Ниже будут рассмотрены наиболее известные на мои взгляд системы и сервера.
Unix OS's
# вся информация о входах в систему:
/etc/utmp
/var/log/utmp
/usr/adm/wtmp
/var/log/wtmp
# когда и откуда логинились последний раз:
/var/log/lastlog
/usr/adm/lastlog
* В UNIX просто так логи удалить не получиться (конечно если ты не root). Также удобно использовать так называемые log wiper'ы, которые заранее автоматизированы на зачистку логов (в зависимости от ОС).
Win NT*
# лог файлы с сервера:
WINNTsystem32logfilesW3SVC1
..W3SVC3
..W3SVC4
# FTP лог файлы:
WINNTsystem32logfilesMSFTPSVC3
..MSFTPSVC4
* все лог файлы в каждой директории хранятся по дате (к примеру in010411.log - 2001 11ое апреля).
** На NT стирание логов под nobody иногда возможно (все зависит от прав доступа и мозгов администратора). Если попытаетесь стереть лог файл на текущую дату то так просто не выйдет, придется останавливать web server.
Sambar WEB server
..Sambarlog*.log
Apache Web server
# ошибочные запросы:
../apache/logs/error.log
# доступ к файлам:
../apache/logs/access.log
* Для web server'ов требуется остановка сервера.
Зачистка
Удаление содержимого лог-файлов без применения специализированных програм возможно только лишь при работе с root шелла !!!!
Как всем нам стало известно, всё больше и больше людей начинают интересоваться собственной безопасностью. Всё больше волнуют последствия взломов в различных областях хакинга, всплывают темы, касающиеся уничтожения следов взлома системы. Явной причиной этому является заинтересованность людей в проблеме зачистки лог-файлов. Эта статья поможет вам подробно разобраться в механизме программной записи данных о песещениях и действиях в системе, а так же ответит на все подобные вопросы.
Для начала хочу разбить все представления читателя о возможности отсутствия программной записи лог-файлов. Хороший админ, мать его за ногу, приставленный к ценному или же популярному ресурсу пишет всё: от попыток введения неправильного логина, до действий в доступе на FTP и исполнения комманд. Т.е. после взлома системы все до единого пункта твоей атаки прописаны в разных лог-файлах разбросанных по системе. Таким образом, администратор, при обнаружении взлома способен по лог-файлам изучить твой метод действия + твои данные. Или же, если ты был достаточно умён, данные цепочки используемых прокси-серверов. По традиционному методу вычисляется провайдер и если не были применены методы приводящие к сбиванию номера на АТС, тебя пеленают "маски". Это всего лишь стандартная схема, новости которой доходят до меня ежедневно. Если тебе будет суждено пойти под подсудное дело без помощи стукачей, то спеленают тебя именно так. Как вы видете, начальной ошибкой приводящей к подобному исходу, является игнорирование зачистки лог-файлов при взломе системы. На мой взгляд, после длинного языка именно они становяться причиной поимки хакера.
Локализация лог-файлов
Поскольку я отдаю предпочтение работе с Юникс системами, ниже будут описаны лог-файлы именно систем Юникс.
В зависимости от версии и разновидности систем Юникс файлы и содержащие их директории будут различны.
Наиболее распространённые директории лог-файлов таковы:
/var/log - используется в некоторых версиях Solaris, LinuxBSD и FreeBSD.
/usr/adm - распространено среди систем ранних версий.
/var/adm - здесь содержаться логи более свежих систем.
/etc - большинство версий Юникс хранят utmp, некоторые wtmp с syslong.conf.
В зависимости от директории в которой вы находитесь распологаются соответствующие лог-файлы:
lastlog -- Логи последних логинов каждого пользователя, и иногда логи последних неверно введёных логинов.
loginlog -- Записи ввода всех неверных логинов.
messages -- Записи вывода на системную консоль (т.е. всё то, что пишет тебе на терминал система ) и другие сообщения от syslog.
security -- Запись всех атак, использующих uucp систему.
sulog -- Логи команды SU.
acct OR pacct -- Пишет команды, используемые каждым пользователем.
access_log -- Для серверов NCSA HTTPd. Этот лог хранит информацию о сайтах, контактируемых с сервером.
aculog -- Хранит записи исходящих модемных связей.
utmp -- Запись всех посещений системы пользователями.
utmpx -- Удлинённый utmp.
uucp -- содержит логи пересылок, различных контактов и активности пользователя.
vold.log -- сборщик внешних ошибок лог-файлов.
xferlog -- логи FTP доступов.
Также существуют некоторые типы лог-файлов не имеющих специфических предназначений, но выполняющих запись определённых действий. Таких файлов теоретически достаточно много. Находясь в системе, стоит изучить все вышеупомянутые файлы и множество других файлов на наличие записи лога.
Не стоит недооценивать их функцию. Не важно, что вы делаете в системе - СИСТЕМА ПИШЕТ ВСЁ!!! Потратив минут 20-30 на изучение и корректировку специфических файлов вы избавите себя от головной боли по поводу последствий дела.
Я приведу пример файлов, без затирания которых не происходит ни одна моя атака. Это xfer файл - файл записи попыток перемещения и пересылок файлов в систему и ( или ) из неё. И rexe файл - запись попыток исполнения комманд, которые запрещены в системе (т.е. предположим, команды недоступные с данного шелла).
Существует множество лог-файлов, о которых хакер может и не догадываться. Большинство администраторов руководствуются простым правилом - располагать лог-файлы так, что бы ему они были легко доступны для чтения. Я давно проследил тенденцию размещения файлов в корневых директориях. Как я заметил, с годами, возможно из-за любви сисопов к комфорту и их врождённой лени, файлы перемещаются всё ближе и ближе к корневым каталогам. Порой я находил их в открытом виде. Иногда логи валялись в самых непредсказуемых местах.
Несколько раз мне попадались текстовики со списками лог-файлов системы, причём один из списков хранился в мусорке. Вероятно, уставший от постоянных копаний админ составлял их для того, чтобы самому проще было разобраться и найти многочисленные логи. Настоятельно реккомендую изучать все текстовые файлы системы. В первую очередь файлы рабочего стола и корневых директорий, т.к. именно в них хранится наиболее часто используемая администратором информация.
Сливки темы
Наряду с традиционными лог-файлами Юникс содержит так называемые "истории шеллов", т.е. полной записи активности пользователя при работе с одним из шеллов системы. Желательно затирать хистори файлы после завершения каждой работы с системой, но будьте осторожны с подлыми сисопами. У них сейчас мода пошла: создавать линки для активации хистори файла, которые выкладываются в директории недоступные для чтения хакера. В итоге получается что-то вроде активного pgp disk`а.
Сегодня они готовы на всё, и никогда не знаешь, чего от них ждать. Я уже давно ничему не удивляюсь.
Ещё один файл, который вы должны проверить, файл записи почтовых операций определённых пользователей. Имя этого файла различно. Иногда это может быть фрагмент syslog файла. Syslog - это программа записи определенных действий в определённые файлы. Для того, чтобы выяснить куда программа пишет логи достоточно изучить файл конфигурации syslog.conf. После обнаружения данного файла вся лог-защита системы рушится. Syslog попадает под ваш тотальный контроль.
Файл должен располагаться в /etc директории !!!
Эта статья предназначена только для ознакомительных целей. Ни в коем случае не реализовывайте на практике то, что Вы прочитаете, так как Вы несете полную ответственность за свои поступки в соответствии с действующим законодательством. Я не отвечаю за достоверность информации и не несу ответственности за Ваши поступки! Все что вы делаете, вы делаете на свой страх и риск!!!