пятница, 26 июля 2013 г.

Чистим логи в Linux

Первое что нам необходимо сделать после получения рут привилегий это:

Отключить сохранение команд текущей сессии в истории Bash:
unset HISTFILE
или
export HISTFILE=/dev/null
export MYSQL_HISTFILE=/dev/null 

freebsd
setenv histfile /dev/null
setenv MYSQL_HISTFILE /dev/null

Далее после работы, нам нужно очистить логи с записями о нашем присутствии в системе. Сделать это можно двумя способами:
1. С помощью специальных утилит (Log Wiper,Log Cleaner, etc)
2. В ручную

Не помешает также подчистить .bash_history, в котором сохраняется история команд.

Далее перед отключением делаем:
kill -9 $$
kill -9 $$ - это выход из консоли без без сохранения истории, где $$ идентификатор текущего процесса консоли.

Если вы решили довериться утилитам, то можно воспользоваться одной из этих утилит:
http://packetstormsecurity.com/UNIX/penetration/log-wipers/
Наиболее популярные: vanish , whitecat

Рассмотрим whitecat. Она поддерживает FreeBSD, Linux, SOLARIS.
Последняя версия 1.1: http://forum.antichat.ru/threadnav36595-4-10.html
Пути к логам находятся в массиве APACHE_PATH[] (стр. 54, файл witecat.c). Чтобы добавить новый путь - просто добавьте строчку в массив, соблюдая запятые. Во время работы при попытке обработать несуществующий путь ошибки не вываливаются.  
Компиляция: gcc whitecat.c -o whitecat
Запуск(например хотим почистить свой ip в логах):
./whitecat -u root -a 127.0.0.1

Для ручной чистки можно использовать следующие команды:
egrep -rl "127.0.0.1" /var | while read f; do sed -e '/127.0.0.1/d' $f>1.back;touch -r $f time.tmp;mv -f 1.back $f;touch -r time.tmp $f;rm -f time.tmp;done
Если остаются пустые строчки - их тоже можно удалить:
sed '/^$/d' new
Обратите внимание, мы не используем mv, для затирания файлов, тк после этой команды не производится дальнейшая запись в логи.  После команды mv запись продолжается в переименованный файл и только по SIGHUP демон переключается на новый файл лога.

Описание системы ведения логов

В Unix программы могут вести свои собственные логи или использовать для этого демон syslogd. С помощью этого демона любые другие демоны или службы могут заносить в общие логи (файлы журналов) свою информацию. Таким образом для всех программ можно установить единый метод регистрации событий, за что и отвечает syslogd. Итак сислог-демон распределяет события по категориям и важности (приоритетам), а также в зависимости от конфигурации решает куда отправить запись о данном событии. Все настройки, отвечающие за это, хранятся в файле /etc/syslog.conf. Посмотрим на пример конфигурационного файла syslog'a, который мы взяли из Red Hat linux 9.0 установленного с дефолтными параметрами:
# 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;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.
authpriv.* /var/log/secure

# Log all the mail messages in one place.
mail.* /var/log/maillog


# Log cron stuff
cron.* /var/log/cron

# Everybody gets emergency messages
*.emerg *

# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log
local7.* /var/log/boot.log
Слева пишется категория и привилегия события, а справа - файл куда это событие заносится:
катeгория.приоритет адрес_лог_файла
Звездочка, как можно легко догадаться, означает все категории или все приоритеты. Теперь немного поподробнее о категориях:

auth - сообщения о нарушении авторизации доступа;
authpriv - сообщения о привилегированном доступе;
cron - сообщения демона крон;
daemon - сообщения других демонов;
kern - сообщения ядра;
lpr - сообщения системы печати;
mail - сообщения почтовых программ;
news - сообщения новостных программ;
syslog - сообщения самого демона сислог;
security - тоже самое что и auth (не должно использоваться в новых системах);
user - сообщения программ юзеров;
uucp - сообщения UUCP;
local0-local7 - определяется для конкретной системы.

Почти понятно? Тогда рассмотрим уровни приоритетов:
emerg - системе амбец;
alert - нужно срочное вмешательство;
crit - состояние критично и представляет угрозу работе системы;
err - сообщение об ошибках;
warnity - предупреждение;
notice - состояние допустимое, но админ должен это увидеть;
info - просто информация;
debug - отладочные сообщения;
none - нет приоритета.
Таким образом, настройки файла /etc/syslog.conf определят заносить ли какое-либо конкретное сообщение в файл журнала или нет.

 Теперь посмотрим куда могут отправляться сообщения.
/путь/имя_файла - сообщения записываются в лог-файл;
/dev/console (что в нашем примере) - сообщение передается на терминал (т.е. их можно увидеть на мониторе, подключенном к данной машине);
root,user1,user2 - имена пользователей, на терминал которых будет выводиться сообщение;
* - сообщения выводятся на терминалы всех пользователй (см. пример с *.emerg);
mail.=info                   /dev/tty12

| - знак конвеера означает, что сообщение передается другой программе (например | "mail root" - сообщение передается руту по почте);
@имя_хоста - сообщения отправляются на удаленный компьютер (демону syslogd).
Последнее и есть самая опасная вещь - логи удастся почистить только если взломать второй хост.
*.*             @megalohost

Рекомендуется также заглянуть в файл /var/log/messages, где могут сохраниться системные сообщения от применения эксплойтов или других действий.

  /var/log/lastlog
lastlog — содержит записи о времени последнего входа в систему для каждого пользователя. Этот файл содержит только одну запись для каждого пользователя.

/var/log/wtmp/
wtmp — содержит записи обо всех входах в систему (и выходах из системы) по пользователям. На загруженном компьютере этот файл имеет большой размер, поскольку содержит по одной записи входа и одной – выхода из системы. Файл также содержит дополнительную системную информацию, такую как перезагрузка, выключение и изменение даты.

/var/run/utmp 
Файл utmp позволяет получать информацию о том, кто в данный момент работает в системе. Пользователей, в данное время использующих систему, может быть большое количество, поскольку не все программы используют регистрацию через utmp.

Файл /var/log/btmp записывает неправильные регистрации. 

При входе пользователя в систему открывается файл lastlog, и в нем обновляется запись о дате и времени входа. Затем открывается файл utmp, и в него записывается информация о текущем нахождении в системе. Запись о входе в систему (как правило, копия информации, добавленной в lastlog) записывается также в журнал wtmp для регистрации входа в систему.
При выходе пользователя из системы запись о нахождении в системе, внесенная в utmp, удаляется (с этого момента пользователь не зарегистрирован в системе), а в wtmp вносится дополнительная запись для регистрации того, что пользователь вышел из системы. 

Мы можем отредактировать wtmp файл вручную с помощью утилиты fwtmp.

Преобразуем двоичный файл wtmp в текстовый файл:
fwtmp < wtmp.mmdd > wtmp.new
Команда fwtmp преобразует wtmp из двоичного кода в текстовый формат.
Отредактируйте текстовый файл wtmp.new, удалив/отредактировав нужные записи
Преобразуем текстовый файл wtmp.new обратно в двоичный формат:
fwtmp -ic < wtmp.new > wtmp.mmdd
Если файл wtmp восстановить невозможно, то с помощью команды nulladm создайте пустой файл wtmp:
nulladm wtmp

Утилита wtmpfix поможет скорректировать согласованность системной даты и времени в файле wtmp, если в нем появились ошибки.

http://xaknotdie.org/defaced/3/d3_09.html 

Комментариев нет:

Отправить комментарий