Заметание следов в Unix

Статью скопирастил.

Вся правда о логвайперах

Все, кому приходится сталкиваться с проблемой компьютерной безопасности, знают, что главным предметом изучения являются логи. Для администраторов систем логи - сигнализатор дневной активности и атак, для хакеров - предмет немедленного уничтожения, для анализаторов безопасности - главный источник информации. Нас, несомненно, интересует золотая середина, а именно способы чистки и уничтожения записей в лог-файлах, чем мы сегодня и займемся.

Я считаю, что вариант ручного просмотра логов незамедлительно отпадает. Не спорю, что в мире полно мазохистов, но умные люди дали нам возможность программировать, а грамотные кодеры написали автоматические тулзы для удаления информации в линуксовых логах.

ВВЕДЕНИЕ В ЛОГИ

Немного теории. Все логи в *nix'ах делятся на два вида: текстовые и бинарные. Текстовые, как правило, могут заполняться различными данными, которыми располагают внешние программы и утилиты. Головным мозгом всей системы текстовых логов является демон syslogd (либо его альтернативы). С его помощью достигается гибкое ведение журналов, а также возможность записи в логи со стороны любого приложения без рутовых прав (через функцию syslog()). Вдобавок к вышесказанному, администратор системы может изменить дефолтовые названия всех текстовых логов на любые другие. Но для нас устройство и работа syslogd не является главной проблемой, это тема отдельной статьи. Поэтому перейдем к разбору другого вида логов.

Бинарные логи - журналы для хранения информации по успешным заходам в систему со стороны. Нас интересуют три важных бинарных журнала - /var/log/wtmp, /var/run/utmp и /var/log/lastlog (вариант Linux, в других системах они могут называться по-другому). Как видишь, ручками такие логи уже не почистить ;).

Я встречал умников, которые боролись с логами после захвата системы следующим образом: прибивали syslogd и уничтожали бинарные журналы дедовским способом (rm -f). Ничего удивительного, что на следующий день администраторы просекали, что их систему поимели, и закрывали доступ к системе (предварительно настучав горе-хакеру по башке).

ЧИСТИМ ПРАВИЛЬНО!

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

Итак, что для нас важно в процессе чистки журналов в правильной оси? Навскидку выделяются три главных критерия, которые должны выполняться:

1. Надежность. После запуска логвайпера все логи должны быть корректно вычищены и остаться доступными для дальнейшего журналирования.
2. Скорость. Я думаю, тебе не понравится, если процесс чистки логов затянется до двадцати минут. Поверь, такие случаи тоже бывают.
3. Маскировка и скрытность. Тулзы не должны оставлять за собой каких-либо временных файлов либо фатальных корок (core-dump'ов).

После тестирования я убедился, что идеальных логвайперов не бывает, ибо для каждого отдельно взятого вайпера выполнялось максимум два критерия. Что сказать, лень программистов берет свое, да и системы отличаются своей капризностью (в Linux, например, структура логов отличается от структуры в SunOS).

Ты спросишь, как осуществлялась проверка всех трех критериев? Отвечаю: самым тщательнейшим образом. Все данные, которые я намеренно записал в логи, должны быть уничтожены коварным логвайпером. Скорость проверялась при помощи команды интерпретатора time -p. Маскировка выяснялась при завершении работы программы (нередко фатальном)...

ТЕСТ - ВСЕМУ ГОЛОВА!

Для обзора потребовалось найти шесть добровольцев. Почему шесть? Потому что я хотел отличиться от других своей неординарностью, чтобы добиться более объективной оценки ;). Жертвами стали следующие логвайперы: vanish2, grlogwipe, zap3, wipe, zap2, gh0st. Авторам отдельное спасибо за их код и баги, которые намного повышали наглядность моего обзора, приближая его к реальному. Полигоном являлись три независимых и самых популярных unix-like оси: Linux RedHat 7.1, FreeBSD 4.7 и SunOS 5.8. Я уверен, что ты имел дело, по крайней мере, с одной из упомянутых. Обзор проводился в трезвом состоянии и завершился без всяких запарок и эксцессов, поэтому не вздумай сомневаться в моей искренности.

VANISH2 - ЛУЧШЕЕ ЧИСТЯЩЕЕ СРЕДСТВО ДЛЯ ПОРТАТИВНОГО УНИТАЗА ;)

Первым добровольцем стал Vanish2 - логвайпер для правильной оси. Испытывался в Linux, как и было написано в комментариях к коду. Представляет собой отдельный хеадер и сишник без всяких Makefile (вот оно - гуманное отношение программистов к людям!). Ну да ладно, руки у меня растут откуда надо, и компилить я еще не разучился. Быстро набираю gcc vanish2.c -o vanish2 и... не получаю ни одной ошибки (странновато, правда? ;)).

Далее идет ознакомление с параметрами, которые должны быть переданы логвайперу. А параметры такие: строка для чистки, ip-адрес и hostname (резолвить адреса программисты, видимо, не научились, поэтому поручили это нам - бедным юзерам). Выбираю фактор, который хочу испытать на полную катушку, - это скорость. Поэтому тестирование происходило на 486dx процессоре. Автор Ваниша обещал, что будут вычищены все текстовые логи (messages, secure, xferlog, maillog, httpd.access_log и httpd.error_log, а также бинарные wtmp, utmp и lastlog), но он не сказал время, за которое вайпер справится с работой. Ухмыльнувшись, запускаю клинер и ухожу пить кофе. Какого же было мое удивление, когда к моему приходу процесс не сдвинулся с места! Чистка логов заняла чуть больше 10 минут. Даже для 486 процессора это очень много (я пытался приблизить ситуацию к реальной, когда вайперу придется обрабатывать гигабайтный wtmp-файл). Посмотрев в сорцы, я понял, что в скорости виноват именно Ваниш, а никак не система. Программист решил пролистывать каждый рекорд wtmp до встречи с шаблоном, хотя правильнее бы было смещаться от конца файла...

Со скоростью все ясно. Просмотрев логи, я увидел, что мои следы действительно исчезли. Временных файлов на месте замечено не было, равно как и core.

Мне стало интересно, что будет, если я скомпилю Ваниш под FreeBSD. Как оказалось, ничего хорошего из этого не вышло - система ругнулась на отсутствие хеадера. Испытывать на SunOS я не стал, ибо знал о фатальном завершении эксперимента (в солярке все по-другому: от имен логов до их структуры).

Открыв блокнотик, я записал небольшой отчет по Ванишу (оценивал по 10-бальной шкале).

Оценка

• Надежность
  • Текстовые логи - 9 баллов.
  • Бинарные логи - 10 баллов.
• Скорость - 2 балла.
• Маскировка - 7 баллов (временные файлы имелись, но они удалялись после работы. Если юзер прервет работу логвайпера - темпы удалены не будут).
• Многоплатформенность - 4 балла.
• Общая оценка - 7 баллов.

GRLOGWIPE - ЛУЧШЕЕ РЕШЕНИЕ ДЛЯ FREEBSD

Небрежно переместив Ваниш в папку испытанных, я взялся за следующий экземпляр: grlogwipe, который первоначально решил проверить на фряхе (зачем зацикливаться на Linux - для нас важна многоплатформенность). Компиляция прошла без всяких сложностей. Запустив grlogwipe без параметров, я удивился многофункциональности этого клинера. Но обо всем по порядку.

Первый минус grlogwipe - это отсутствие возможности чистки текстовых логов. Он предназначался только для трех бинарных файлов. Но программисты подошли к этой проблеме довольно неплохо. Логвайпер умеет как менять хост в рекорде лога, так и имя пользователя. Разумеется, все данные могут быть удалены - все зависит от желания юзера, то бишь тебя ;). По скорости клинер показал себя довольно неплохо - всего несколько долей секунды (просмотр лога начинался именно с конца, а не с начала, как в Vanish2).

К сожалению, файл /var/log/lastlog во фряхе не обрабатывался. Запись о подключении юзера сохранилась в нем, как будто лог никто и не изменял.

Далее я решил поиграть с опциями замены хоста и юзера и проверить, действительно ли это рабочие возможности, а не просто декорации. Чтобы изменить имя пользователя в записях wtmp, достаточно указать имя старого и нового пользователя через опции -u и -U соответственно. Аналогично с ip-адресом. В довершение всего, должна быть опция -w (write), которая и будет изменять рекорды wtmp. Опция -r необходима для удаления всех записей, удовлетворяющих заданному шаблону. Шаблон, как ты уже понял, задается при помощи -u и -h опций, указывающих на имя пользователя и хост (ip-адрес).

Скрытность была идеальной. Ни в сорцах, ни на практике не было следов от временных файлов. Логвайпер завершался корректно, не оставляя за собой корок.

Grlogwipe испытывался как в Лине, так и в FreeBSD. Итоги экспериментов были практически одинаковыми, что еще раз подчеркивало универсальность клинера.

Оценка

• Надежность
  • Текстовые логи - 0 баллов.
  • Бинарные логи - 9 баллов.
• Скорость - 10 баллов.
• Маскировка - 10 баллов.
• Многоплатформенность - 8 баллов.
• Общая оценка - 7 баллов.

ZAP3 - МОДНЫЙ КЛИНЕР НОВОГО ПОКОЛЕНИЯ

Следующим экземпляром в обзоре был логвайпер под именем Zap3 (правда, сишник называется по-другому, что осложняет его поиски). Порадовало, что Zap3 способен чистить как бинарные, так и текстовые логи. Причем, делает это с особой тщательностью (нетронутых записей замечено не было). Что примечательно, клинер работает с логами напрямую и не оставляет за собой временных файлов.

Скорость колеблется в пределах от двух долей до секунды (в зависимости от размера журнала). Все благодаря продуманному алгоритму и успешной его реализации ;). К сожалению, текстовые логи вычищались не полностью (в auth-логе была замечена запись, которой по логике не должно было быть).

Что касается многоплатформенности, компиляция на Фре ни к чему хорошему не привела. Как пишут авторы, логвайпер тестировался лишь на RedHat и Mandrake дистрибутивах правильной оси, поэтому их можно понять и простить.

А теперь самое интересное. После того как zap3 дошел до лога /var/log/syslog, он жестко обломался, ибо этого файла в системе не было. Обычно на такой случай делается проверка. Тут она полностью отсутствовала, и бинарник выпал в кору. Разумеется, что после такого случая доверять клинеру нельзя, ибо кора в рабочем каталоге - недобрый знак.

Несмотря на недостатки, общее впечатление от этого лога неплохое. Клинер справился с задачей практически на 100%, но мелкие недочеты сделали свое грязное дело.

Оценка

• Надежность
  • Текстовые логи - 6 баллов.
  • Бинарные логи - 9 баллов.
• Скорость - 10 баллов.
• Маскировка - 2 балла.
• Многоплатформенность - 5 баллов.
• Общая оценка - 5 баллов.

СКАЗКА ПРО SUNOS

Как ты, наверное, заметил, я упоминал лишь о Linux и FreeBSD и ни слова не сказал о других системах. Это не совсем правильно. Если подумать, Солярка всегда была и будет надежной системой, поэтому упомянуть ее имя в обзоре я просто обязан. Для этой цели я выбрал два логвайпера, которые опишу в одном флаконе. Это zap2 (кстати, удивительно, но ничего общего с zap3 у него нет ;)) и wipe.

Посмотрев комментарии к коду Wipe, я понял, что это многоплатформенная вещь, но в целом клинер ориентирован на SunOS. Скомпилив его с параметром solaris, я попытался почистить заранее подготовленные логи. Wipe предназначался только для чистки бинарных файлов (как и grlogwipe). Причем, для каждого лога существовала своя опция (универсальная чистка была бы намного приятнее). Я запустил логвайпер три раза с параметрами u, w и l (для utmp, wtmp и lastlog, соответственно). К моему удивлению, wtmp остался без изменений. Остальные файлы были успешно обработаны.

Скорость опять же не подкачала. Весь процесс выполнился за несколько долей секунды. Временных файлов поблизости нигде не было.

Вердикт - wipe пригоден лишь для чистки utmp и lastlog. На большее он вряд ли потянет.

Следующим шагом была компиляция zap2. Этот чудо-клинер был ориентирован только на Солярки и поэтому оставлял большие надежды. Компиляция прошла без проблем. Запуск без параметров выдал единственное слово Error, что привело меня в задумчивость. То ли логвайпер отказывался запускаться на этой платформе, то ли у него просто не было процедуры usage(). К моему счастью, второе предположение подтвердилось. Поразмыслив логически, я запустил zap2 с параметром user (где user - имя пользователя). Увидел магическое слово Zap! и догадался, что клинер успешно выполнил поставленную ему задачу. Просмотрев результаты работы, я убедился, что zap2 действительно все сделал, как я просил.

Оценка

• Надежность:
  • Текстовые логи - 0 баллов.
  • Бинарные логи - 8 баллов.
• Скорость - 8 баллов.
• Маскировка - 5 баллов.
• Многоплатформенность - 4 балла.
• Общая оценка - 5 баллов.

И ЭТО НЕ ТОЛЬКО СИ

Что примечательно, логвайперы бывают не только сишными. Наткнувшись на экземпляр под названием gh0st.sh, которое говорило о том, что клинер был написан на sh-языке, я решил добавить его в свой обзор. Первые мысли были о том, что этот реальный клинер займет первое место в моем обзоре.

Итак, начало тестирования. Запустив gh0st.sh без опций, я увидел, что он просит hostname в качестве параметра. Удовлетворив его желания, я проследил за действиями призрака. Прочесав 10 текстовых логов, он удалил из них все посторонние записи. Моему удивлению не было предела, когда на экране появились строки, касающиеся бинарных файлов. Как удалить из них записи на языке sh, я не представлял.

Скрипт очень быстро завершил чистку. Заценив wtmp, я увидел, что его попросту не было. Точнее, его размер составлял 0 байт. Первое впечатление об этом клинере быстро изменилось. В текстовых логах вся компрометирующая информация была удалена. Впрочем, алгоритм чистки текстовиков от ненужных фраз был прост. Сперва надо было прогрепать лог с ключиком -v и последующим выводом инфы в темп-файл, а затем заменить его на нужный. То есть, чтобы удалить в /var/log/messages ip-адрес 127.0.0.1, достаточно было выполнить команду grep -v 127.0.0.1 /var/log/messages > tmp && mv -f tmp /var/log/messages. Этот алгоритм и выполнялся в рассматриваемом клинере.

Что сказать... Если выбросить часть кода, касающуюся чистки бинарников, то получится неплохой логвайпер для ascii-логов ;).

Оценка

• Надежность:
  • Текстовые логи - 6 баллов.
  • Бинарные логи - 0 баллов.
• Скорость - 8 баллов.
• Маскировка - 4 балла.
• Многоплатформенность - 4 балла.
• Общая оценка - 4 балла.

И КТО ЖЕ ПОБЕДИТЕЛЬ?

Настало время подвести итоги моего тест-драйва. Первое место я присудил vanish2. Он хоть и отличается своей медлительностью, но качество работы, пожалуй, у него отличное.

Второе место отдаю grlogwipe. Имея несомненные плюсы в скорости и многоплатформенности, он одновременно лажает в ascii-логах и бинарном lastlog. Но, опять таки, дополнительные фенечки клинера мне очень понравились.

На третьем месте располагается zap3. Хоть его и контузило при неудачном открытии syslog, он неплохо справляется с поставленной задачей. Немного универсальности и стабильности - и это будет лучший логвайпер ;).

Насчет остальных экземпляров ничего говорить не буду. Все было сказано выше. Отдельных слов в их адрес у меня попросту нет.

МОРАЛЬ СЕЙ БАСНИ

Надеюсь, что после прочтения этой статьи ты поймешь - идеальных логвайперов не существует. Идеальные вещи пишутся только применительно к конкретной ситуации. Поэтому мой тебе совет: учи Си и напиши свой суперклинер, который способен удовлетворять всем вышеназванным критериям, и тебе будут благодарны много людей.

Для администраторов систем логи - сигнализатор дневной активности и атак, для хакеров - предмет немедленного уничтожения, для анализаторов безопасности - главный источник информации.

Я встречал умников, которые боролись с логами после захвата системы следующим образом: прибивали syslogd и уничтожали бинарные журналы дедовским способом (rm -f).

Полигоном являлись три независимых и самых популярных unix-like оси: Linux RedHat 7.1, FreeBSD 4.7 и SunOS 5.8.

Если подумать, Солярка всегда была и будет надежной системой, поэтому упомянуть ее имя в обзоре я просто обязан.

Чтобы удалить в /var/log/messages ip-адрес 127.0.0.1, достаточно выполнить команду grep -v 127.0.0.1 /var/log/messages > tmp && mv -f tmp /var/log/messages.

Этот обзор включает в себя лишь шесть логвайперов. Хочешь больше? Топай на http://packetstormsecurity.nl/UNIX/penetration/log-wipers и найдешь для себя множество различных клинеров на все случаи жизни.

Рассматриваемые экземпляры ты можешь утянуть по ссылке: http://k-uralsk.net/forb/1/x/logwipers.tar.gz. Для удобства - все шесть логвайперов помещены в один архив.

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

К сожалению, если админ установил другой демон для ведения логов, то их чистка будет довольно сложна. К примеру, syslog-ng формирует иерархию каталогов в /var/log и пишет в каждый журнал отдельные события. Если посчитать, то в сумме мы получим около 20 логов, пути и имена которых отличаются от дефолтовых...