Защита систем *nix от rootkit

В данной статье мы шаг за шагом расскажем, как установить и использовать программу chkrootkit, назначение которой — локальная проверка ОС семейства *nix (Unix, Linux и т. д.) на наличие руткита. Руткит (rootkit) — это пакет программ, используемых взломщиками (хакерами) для сокрытия следов своей активности и сбора информации (чаще всего паролей) как со взломанного компьютера, так и с других машин в той же локальной сети. Руткит способен выполнять и другие действия, набор функций зависит от конкретного пакета. Также мы приведём краткое описание такого руткита для иллюстрации. Надеемся, статья окажется полезной многим пользователям — от новичков до профессионалов.

Автором программа проверена на следующих системах: Linux 2.0.x, 2.2.x и 2.4.x; FreeBSD 2.2.x, 3.x, 4.x и 5.x; OpenBSD 2.x и 3.x; NetBSD 1.5.2; Solaris 2.5.1, 2.6 и 8.0; HP-UX 11; Tru64 и BSDI.

Вступление

Строго говоря, chkrootkit — это пакет программ, но для простоты в тексте мы будем использовать слово «программа». Будучи небольшой по объему (в сжатом виде около 35 Кб) и простой в использовании, на момент написания статьи chkrootkit являлась, пожалуй, самым популярным некоммерческим продуктом по выявлению руткитов. Программа распознает более 50 различных руткитов. Вот состав пакета:

chkrootkit — исполняемый shell скрипт, ищущий руткиты в системе по их характерным признакам (именам, расположению файлов, открытым портам и т. д.) и запускающий остальные программы;
ifpromisc.c — проверяет, не находится ли сетевая карта в так называемом promiscuous состоянии, в котором она принимает входящие данные, не предназначенные этому компьютеру, иными словами, подслушивает данные из сети;
chklastlog.c — контролирует удаление записей из файла lastlog — файла, содержащего информацию о входивших в систему пользователях;
chkwtmp.c — то же, что и chklastlog.c, но для файла wtmp;
check_wtmpx.c — то же, что и предыдущая, но для файла wtmpx в операционной системе Solaris;
chkproc.c — проверяет наличие троянов LKM (loadable kernel modules), загружаемых непосредственно в ядро операционной системы;
chkdirs.c — проверяет наличие скрытых каталогов как признак троянов LKM;
strings.c — ищет в файлах строки, состоящие из 4 или более читаемых символов.

Установка

Скачиваем архив программы (chkrootkit.tar.gz) с ее официального сайта. Есть и русское зеркало, его бесспорный плюс в том, что некоторая информация переведена, однако сам архив там обновляется с опозданием. Сразу оговоримся, что, хотя установить chkrootkit можно с правами обычного пользователя, запускать ее надо с правами root, поэтому далее предполагается, что вы работаете именно с этими правами.

Итак, распакуем скачанный архив:

[root@aluf root]# cd /путь_к_скачанному_файлу [root@aluf downloads]# tar zxvf chkrootkit.tar.gz [root@aluf downloads]# cd ./chkrootkit

После этого в созданной папке должны находиться перечисленные выше подпрограммы в виде исходного кода, и всё, что осталось сделать — это скомпилировать их с помощью стандартного компилятора gcc. Но если вы пользователь Red Hat, необходимо слегка подкорректировать исходники. Дело в том, что расположение нескольких файлов, необходимых для успешной компиляции chklastlog.c и chkwtmp.c, не соответствует тому, что указано в этих двух файлах, поэтому надо отредактировать их следующим образом:

В файле chklastlog.c с помощью любого текстового редактора заменяем строку

#define WTMP_FILENAME "/var/adm/wtmp"

на

#define WTMP_FILENAME "/var/log/wtmp"

Далее в этом же файле заменяем строку

#define LASTLOG_FILENAME "/var/adm/lastlog"

на

#define LASTLOG_FILENAME "/var/log/lastlog"

Сохраняем файл.

В файле chkwtmp.c заменяем строку

#define WTMP_FILENAME "/var/adm/wtmp"

на

#define WTMP_FILENAME "/var/log/wtmp"

Сохраняем файл.

Компилируем командой

[root@aluf chkrootkit-0.44]# make sense

Если не было сообщений об ошибках, то всё готово. Теперь, даём команду запустить все возможные проверки сразу:
[root@aluf chkrootkit-0.44]# ./chkrootkit

Чтобы отключить проверку файловых систем NFS, необходимо использовать опцию -n:

[root@aluf chkrootkit-0.44]# ./chkrootkit -n

В процессе проверки программа выдает сообщения следующего вида:

Checking 'ls'... not infected Checking 'lsof'... not infected Checking 'netstat'... not infected Checking 'passwd'... not infected Checking 'ps'... not infected Checking 'tcpdump'... not infected Checking 'aliens'... no suspect files ............ Сокращено......... Searching for HiDrootkit's default dir... nothing found Searching for t0rn's default files and dirs... nothing found Searching for suspicious files and dirs, it may take a while... .............Сокращено......... Checking 'sniffer'... eth0: not promisc and no PF_PACKET sockets eth1: not promisc and no PF_PACKET sockets Checking 'w55808'... not infected Checking 'wted'... nothing deleted [root@aluf chkrootkit-0.44]#

Краткое пояснение всем возможным сообщениям:

INFECTED: возможно, найден файл, модифицированный взломщиком;
not infected: проверка не нашла никаких известных признаков руткитов;
suspicious files found: найдены подозрительные файлы
not tested: проверка не была произведена по одной из следующих причин:
not found: проверяемый объект не найден;
vulnerable but disabled: обнаружена вредоносная программа, но она не запущена;
user Х deleted or never logged from lastlog!: имя пользователя находится в файле пользователей и паролей, но либо ни разу не использовалось для входа в систему, либо запись об этом удалена из файла lastlog;
user key deleted from lastlog!: запись о вхождении в систему была удалена.

Принцип работы

Программа пытается обнаружить изменения, произведённые взломщиком в системе, по характерным признакам, свойственным каждому руткиту. Однако, проверка может пропустить руткит, который не был известен автору chkrootkit на момент написания программы. Также довольно сложно обнаружить сильно изменённый руткит. Следовательно, никаких гарантий программа дать не может (коммерческие антивирусы их тоже в общем-то не дают), но деятельность взломщиков, пытающихся установить и использовать руткит в вашей системе, усложнит сильно. Например, программа ищет файлы, имеющие в начале имени точку (которые не видны по умолчанию при просмотре каталога командой ls) и находящиеся в неподходящих местах, вроде /usr/man. Такая проверка не связана с определённым руткитом. Другой пример — проверка сетевой карты, не принимает ли она чужие данные. Это также не привязано к определённому руткиту.

Важный момент. При проверках chkrootkit использует различные программы данной системы (такие как netstat, grep, awk, ps, ls и др.), поэтому логично предположить, что если данная система уже была взломана и руткит установлен, то доверять им не стоит (как будет показано в примере руткита ниже, грамотный руткит попытается заменить эти программы для скрытия следов). Желательно использовать программы, в которых вы уверены. Также было бы неплохо, чтобы они не находились в проверяемой системе. Путь к этим программам можно указать при запуске chkrootkit следующим образом:

root@aluf chkrootkit-0.44]# ./chkrootkit -p /путь_к_проверенным_программам

Еще лучше (особенно когда есть уверенность, что система была взломана) смонтировать жесткий диск со взломанной системой на другом компьютере, где есть chkrootkit, и запустить программу на проверенном компьютере с аргументом

[root@trusted_PC chkrootkit-0.44]# ./chkrootkit -r /путь_к_смонтированному_жесткому_диску

Можно записать в cron запуск программы автоматически в определённое время суток:

0 7 * * * root cd /путь_к_chkrootkit; ./chkrootkit | mail -s "chkrootkit output" root

В приведённом примере программа будет запускаться каждый день в 7.00 утра и результаты проверки будут высланы на почтовый адрес root.

Кто виноват? Что делать?

Ответ на первый вопрос (как руткиты попадают в систему и что там делают) потребует изложения всех известных на данный момент способов действия, используемых руткитами, что выходит за рамки этой статьи и, возможно, за рамки моей компетенции. Greg Hoglund, создавший и описавший первый руткит для Windows NT, например, сейчас пишет книгу, целиком посвящённую руткитам.

INFECTED — что делать? Сперва желательно убедиться, что это не ложная тревога. К примеру, как уже говорилось, программа производит проверки, не привязанные к определённому руткиту, такие как поиск скрытых от листинга файлов/каталогов (chkrootkit считает, что в /usr/man не должно быть каталогов, имя которых начинается с точки (скрытых). А что, если недавно установленная вами суперчиталка файлов помощи взяла да и поместила именно туда такой каталог для своих нужд? Проверка выдаст «suspicious files found» (найдены подозрительные файлы). К сожалению, чтобы уверенно сказать, ложная это тревога или нет, надо хорошо знать свою систему. Если нет уверенности (да и просто с любым вопросом по программе), можно обратиться в почтовую рассылку программы (на английском), подписаться на которую можно командой
echo "subscribe users ваш_адрес_электронной_почты" | mail majordomo@chkrootkit.org,

или просто послать «subscribe users ваш_адрес_электронной_почты» на адрес majordomo@chkrootkit.org.

Если же сомнений нет — руткит присутствует в системе — возможны два варианта: попытаться найти вручную все файлы, установленные/изменённые руткитом, либо удалить систему и установить по-новой из проверенного источника. Мнение профессионалов почти всегда однозначно — переустановить систему (предварительно сделав полную копию для внутреннего расследования инцидента), так как нельзя быть на 100% уверенным в такой системе даже после тщательной чистки. И если есть резервная копия всех необходимых данных взломанной системы, переустановка займет намного меньше времени, чем поиск следов руткита.

Лирическое отступление о руткитах

Хотя эта статья посвящена руткитам в системах семейства *nix, руткиты существуют и в ОС Windows, и неплохо себя в ней чувствуют, выполняя сходные функции. Cсылки на ресурсы (англоязычные) по руткитам для Windows приведены в конце статьи. Все руткиты для *nix можно разделить на два основных класса, назовём их условно «класс троечников» и «класс отличников». Первые, по сути — обычные программы, имеющие набор функций для сбора информации о системе, скрытия следов и т. д. (см. пример ниже). Главный принцип их действия — это заменить законные программы в системе (ps, ls, ssh, cron…) на свои, модифицированные так, что хозяин компьютера будет продолжать пользоваться системой, не замечая, что она взломана. Проблем у таких руткитов множество — изменённые программы легко обнаруживаются программами по наблюдению за целостностью файловой системы (классический Tripwire, AIDE, Samhain, integrit…). Не использовать подобный софт — непозволительная роскошь для системного администратора, по моему личному мнению. Тот же chkrootkit с ними борется успешно. Кроме того, исходный код определённого руткита, взятый из интернета, один, а устанавливать пытаются на разные системы, что чревато ошибками в работе руткита. Пример: вводит законный пользователь команду

netstat –an,

а вместо того чтобы скрыть всё подозрительное, она самоуничтожается, выдавая мусор на экран. Думаю, после пятого раза пользователь задумается — а в чем, собственно, дело?

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

В качестве иллюстрации приведем список программ, входящих в руткит lrk (Linux rootkit) версии 5 (последняя версия — 6). Этот руткит включает в себя 1520 файлов исходного кода, которые в распакованном виде занимают 13 Мб!

chfn — присваивает права root обычному локальному пользователю;
chsh — то же, при введении пароля, закодированного в рутките (по умолчанию satori, но легко меняется до компиляции);
crontab — загружает файл по расписанию;
du — см. ls;
find — см. ls;
fix — исправляет время и дату файла, чтобы скрыть его изменение;
ifconfig — скрывает метку PROMISC при прослушивании сети;
inetd — заменяет одноимённый сервис системы для обеспечения доступа;
killall — позволяет взломщику определить, какие процессы не могут быть остановлены командой killall;
linsniffer — сниффер (захват пакетов при прослушивании сети), особенно полезен при использовании протоколов ftp/imap/telnet;
login — позволяет войти в любой аккаунт, используя пароль руткита;
ls — сверяется со списком файлов и каталогов в файле ROOTKIT_FILES_FILE и скрывает их в общем листинге;
netstat — не показывает соединения/порты, перечисленные взломщиком в файле ROOTKIT_ADDRESS_FILE. Пример:
3 9000 — скрывает все соединения с портом 9000;
passwd — присваивает права root обычному локальному пользователю при введении пароля, закодированного в рутките;
pidof — см. ls, только файл скрываемых процессов ROOTKIT_PROCESS_FILE;
ps — также скрывает процессы;
rshd — выполняет удалённо команду с правами root;
sshd — соединиться со взломанным компьютером удалённо с шифрованием соединения;
syslogd — стирает все указанные в ROOTKIT_LOG_FILE строки из лог файлов;
tcpd — обеспечивает доступ с любого указанного в ROOTKIT_ADDRESS_FILE IP адреса, нейтрализуя настройки tcp wrappers;
top — то же, что и ps;
wted — редактор wtmp/utmp файлов, где записаны все данные о входе пользователя в систему;
z2 — стирает запись об определённом пользователе в файлах utmp/wtmp/lastlog.

Руткиты, принадлежащие другому классу, более опасны. Они внедряются в ядро системы и имеют доступ к её ресурсам, поэтому способны осуществить любую затею злоумышленника. Основной способ достичь этого — при помощи LKM (loadable kernel modules), модулей, загружаемых в ядро, изначально используемых для решения проблем совместимости аппаратных устройств в Linux (аналог Windows драйверов). Но, по большому счету, это те же программы с немного специфическим синтаксисом, и если такой модуль может обеспечивать обмен данных с каким-нибудь супер-дупер сенсором, точно так же он может записывать все нажатия клавиш и отправлять их по почте. Это серьёзная проблема, и в ядре версии 2.6.х при установке уже отменена поддержка LKM по умолчанию. Примером такого руткита является adore — имеет меньше функций, чем lrk, но выполняет их куда эффективнее: скрытие файлов, каталогов, процессов, соединений. Этот руткит удостоился отдельной программы по его обнаружению (chkrootkit, по заявлению автора, тоже способен его обнаружить, но это не всегда получается на практике) — Rkscan.

Заключение

Целью данной статьи, ориентированной, наверно, больше на начинающих пользователей Linux и подобных систем, было, с одной стороны, познакомить с практическим средством борьбы с руткитами, а с другой, показав, на что они способны — привлечь внимание к этой проблеме. Дело в том, что у системных администраторов часто наблюдается следующий подход (независимо от опыта): все их усилия направлены на предотвращение взлома системы (что есть хорошо — предотвратить проблему легче, чем решать) путем обновления программного обеспечения, с помощью файрволов, отключения ненужных сервисов, строгой политики наделения пользователей правами и т. д. Однако, при этом администраторы оказываются не готовы к тому, что система будет взломана, несмотря на вышепринятые меры. В то время как наиболее критичные уязвимости — это те аккаунты, которые были созданы, но не используются («guest», «administrator»). Подобрать пароль к таким аккаунтам — не самая сложная задача. Не все об этом знают, но, чтобы установить сниффер в систему, взломщику во многих случаях достаточно получить такой слабый аккаунт и ждать других паролей. Поэтому, мы бы не хотели, чтобы уважаемые читатели решили, что chkrootkit — некая панацея. Средств по обнаружению взломов системы предостаточно: бесплатных, платных, очень даже платных :). Дело в другом — как бы хорошо не были продуманы средства предотвращения проникновения в систему, такая возможность всегда остается, и коли так, то лучше уж быть готовыми к этому заранее.

Автор: Aluf
Взято с Ru.board

Для системного администратора

Категории

Archives

Последнее

Ссылки

Блоги

Meta