Продолжение. Начало в “КГ” №2 (343)

В прошлый раз мы рассмотрели, какие логи может вести локальная система. Настало время поговорить про ведение логов на удаленных серверах. В данной заметке я рассмотрю сервер с точки зрения хакера, что даст администратору представление о том, на что стоит обратить внимание при защите системы или уже после ее взлома.
Сразу стоит сказать, что одни вообще не ведут логов, другие их не смотрят, а третьи только этим и занимаются. Отбросив все это, мы просто рассмотрим пример защиты от ведения логов — сделаем обзор logwriter'ов.
Итак, второе, что делает хакер после взлома системы, — это модификация или удаление логов. А логов может быть вагон и маленькая тележка. Это, например, всем известный демон syslogd. Потом еще и файл bash_history. Демон cron тоже помогает в этом (для примера, можно копировать выводы команд w, who, last, lastlog через каждую минуту на отдельную машину). Также имеет место установка специализированного софта для слежения за системой. Ну, а грамотная настройка файрволла/IDS'а с ведением логом для хакера тоже может плохо закончиться. Что в таком случае делать? Убедившись, что поблизости не наблюдается админа или других полномочных юзеров, можно начать работу.
Первое, что нужно сделать, — проанализировать ваш недавний взлом. Обратите внимание на использованные при этом "дырявые" сервисы (ftp, http, ssh, sendmail, pop3 и др.). Возможно, стоит посмотреть файлы /var/log/[сервис]. После этого нужно немедленно заняться стандартным демоном, таким как syslogd. Для этого и нужны logwriter'ы. Потом можно удалить файл bash_history (или соответствующий используемой оболочке). Не забудьте посмотреть /var/log/secure (это лог-файл TcpWrapper'а, который занимается подключениями).
Из дополнительного софта чаще всего ставится tripwire. Приемы противодействия можно найти на http://www.void.ru. Стоит сказать, что здесь все зависит от вашей смекалки и обширности знаний в этой области: программы ведения логов сейчас очень продвинулись, в списке процессов их не видно, и в скрытых папках лежат.
Умные админы часто применяют различные фичи. Например, syslogd сообщения можно перенаправить на отдельную станцию, на консоль root'а, всем пользователям, что и делается. Таким штучкам довольно трудно противостоять. Очень многие усиленно используют cron, выполняя им, скажем, резервное копирование логов куда-либо. Из этого следует, что лучше все тщательно проверять.
Стоит рассказать о IDS/Firewall. Что это такое? Firewall фильтрует пакеты по определенным правилам, а IDS предотвращает записанные в его базу (известные) атаки. Исходя из этого, следует, что такая связка может попортить хакеру много нервных клеток. Разберемся с файрволлом. Во-первых, он редко бывает грамотно настроен. Ну, а если и так, то все правила можно спокойно сбросить, да и обычно все логируется в syslog. С IDS'ом тоже обычно проблем не возникает, так как его мало кто ставит, также сложная его настройка многих админов просто убивает. Во-вторых, IDS известны только атаки, содержащиеся в его базе, а как часто админ ее обновляет? А если хакер придумал что-то новое, то ему беспокоиться вообще не придется.
И все же основная часть модификации логов — logwriter'ы. Правда, многие используют logwriter'ы наугад, даже не удостоверившись в их работоспособности. Ниже приведен список программ подобного рода, наиболее часто используемых взломщиками:
1. remove — очищает (очищает — это не удаляет, а просто модифицирует) файлы wtmp, utmp, lastlog.
2. marry — очищает utmp, wtmp, syslog.
3. utclean — очищает wtmp, utmp.
4. zap[2] — очищает lastlog, wtmp.
5. displant.c — очищает utmp.
6. cloak[2] — очищает lastlog, utmp, wtmp.
7. wtmped — очищает wtmp.
8. wzap — очищает wtmp.
9. utmp — очищает utmp.
10. ucloak — очищает lastlog, utmp.
11. sysfog — добавляет поддельные записи в syslogd.
12. stealth — очищает utmp.
13. logwedit — очищает wtmp по номеру tty.
14. logutmpeditor — очищает utmp.
15. logcloak — очищает wtmp, utmp, lastlog.
16. lastlog — очищает lastlog.
17. wipe — очищает wtmp, lastlog, utmp.