Это утро выдалось неожиданно насыщенным для нашей службы технической поддержки UNIX: все клиенты, разместившие у нас свои серверы Web, как сговорившись, просили провести их перезагрузку, поскольку работа с серверами, как из командной строки, так и через интерфейс Web, шла катастрофически медленно. Перед выполнением перезагрузки мы решили установить причину неполадок. К несчастью, каждый раз при попытке зайти на любой сервер Linux через SSH, соединение разрывалось демоном SSH по тайм-ауту. Одновременно сетевой администратор наблюдал необычное увеличение трафика через некоторые порты коммутатора. Вскоре обнаружилось, что все проблемные серверы были подключены через вышеупомянутые порты коммутатора. Немедленно отключив эти порты, мы приступили к нашему расследованию.
После повторного включения портов нам удалось успешно зайти на серверы по SSH. Выполнив команды ps aux, top и df и не обнаружив ничего необычного, мы запустили nmap для просмотра открытых портов. Как правило, у наших клиентов открыты порты TCP с номерами 21, 25, 53, 80, 119, 443 и, иногда, 143. После запуска nmap мы обнаружили еще три любопытных порта и попробовали соединиться с каждым из них посредством команды telnet. С первыми двумя не было связано ничего предосудительного, а вот соединение с третьим открыло полный доступ с правами суперпользователя. После этого мы поняли, что серверы наших клиентов были взломаны.
Основная цель статьи состоит не в том, чтобы рассказать, как именно были взломаны серверы, а в том, чтобы показать, как взломщики пытались скрыть этот факт от нас и от наших клиентов. После проникновения в систему они внедрили в нее «троянского коня» для последующего удаленного входа. Более того, чтобы его присутствие в системе не было обнаружено, некоторые системные файлы оказались подменены: например, команда /bin/ps была изменена с целью сокрытия «троянских демонов».
Статья наглядно продемонстрирует всю важность принятия превентивных мер, а при наличии подозрений на присутствие в вашей системе «троянского коня» предоставит информацию для его обнаружения и устранения в ОС Linux.
ПРЕВЕНТИВНЫЕ МЕРЫ
«Троянский конь» — это программа со скрытыми функциями. Выполняя на первый взгляд некоторые разрешенные действия, на самом деле она может удалять файлы, устанавливать вирусы или другого «троянского коня», создавать в системе люки для несанкционированного доступа и подавлять ее активность для сокрытия факта атаки. Вот несколько советов, которые помогут снизить риск «троянских» атак.
- Постоянно будьте в курсе новостей из мира информационной безопасности.
- Никогда не устанавливайте программы "вслепую", даже из "доверенных источников". Иногда такой источник сам может не подозревать о наличии "троянского коня". К примеру, NAI сообщало об обновлении к программе BIND, якобы устраняющем ошибку в системе безопасности. На самом деле обновление являлось "троянцем".
- Проверяйте контрольные суммы MD5 загруженных из Internet программ и программ из внешних источников.
- Никогда не открывайте вложения из писем, если вы не уверены в чистоте намерений их отправителя.
- С осторожностью относитесь ко всему, что запускается из браузера Internet. Апплеты Java, программы ActiveX и JavaScript могут устанавливать "троянцев".
- Старайтесь, по возможности, входить в систему с правами непривилегированного пользователя. Использование учетной записи суперпользователя для выполнения повседневных административных задач увеличивает вероятность поражения системы.
«Троянских коней» можно выявить с помощью систем обнаружения вторжений (Intrusion Detection System, IDS). В рамках этой статьи у нас нет возможности вдаваться в детали функционирования IDS. Многие IDS, такие, как Snort, Prelude и NABOU, прекрасно документированы. IDS могут быть сконфигурированы на поиск необычного содержимого пакетов, входящих и исходящих из вашей сети, или опираться на информацию о уже существующих «троянских конях». Например:
alert tcp $EXTERNAL_NET 31790 -> $HOME_NET 31789 (msg:"P-1-SCAN trojan hack-a-tack probe"; content: "A"; depth: 1; reference: arachnids,314; flags: A+; classtype:attempted-recon; sid:614; rev:1;)
Это правило позволит обнаружить наличие «троянца» Hack?a?Tack, который внедряется в ПК с ОС Windows 95/98. Его серверная часть работает на зараженной машине Windows и называется expl32.exe. Он превращает машину Windows в сервер передачи файлов для поиска других «троянцев» и сбора основной информации о компьютере, а также используется для установки других «троянских коней» в систему. Правило сообщает о существовании зонда Hack?a?Tack при наличии соединения от машины вне сети (скорее всего, клиент) с порта TCP или UDP 31790 на машину внутри сети (вероятно, сервер) на порт 31789.
Tripwire — инструмент, отслеживающий изменения в системных файлах. Он наблюдает за ключевыми атрибутами файлов, не подлежащими изменениям, включая цифровую подпись, размер и ожидаемое изменение размера. Tripwire полезен только в качестве превентивной меры в том случае, если он установлен в систему до заражения «троянцем». Хотя принципы, по которым функционирует Tripwire, могут успешно применяться и при самостоятельном расследовании.
ОБНАРУЖЕНИЕ «ТРОЯНСКОГО КОНЯ»
Один из лучших способов обнаружения «троянского коня» на машине Linux — самостоятельное расследование. Оно может оказаться весьма трудоемким, но позволит избежать заражения в будущем. При возникновении подозрений на наличие «троянца» компьютер следует отключить от сети, дабы предотвратить дальнейшие разрушительные действия. Полезно создать архив из некоторых программ (например, ps, nmap, fuser, netstat, lsmod, rpm, find, md5sum, cp, mv, kill, chmod, chown и ls) и записать его на дискету или компакт-диск, чтобы при необходимости перенести на зараженную машину. Если у вас нет средств обнаружения вторжений, их следует создать с помощью исполняемых файлов с незараженного компьютера. Злоумышленники зачастую подменяют исполняемые файлы IDS измененными эквивалентами, так что не пользуйтесь этими инструментами до тех пор, пока не будете уверены в том, что они не подменены и не изменены. Убедитесь также, что исполняемые файлы на «чистой» машине той же версии, что и исполняемые файлы на зараженной, и только потом перенесите их в новый каталог, названный, например, /toolkit, на зараженной машине.
Я обычно начинаю с изучения вывода команды ps, поскольку она позволяет увидеть любой необычный процесс. Перед запуском команды ps исполняемый файл следует проверить посредством команды md5sum для сравнения контрольных сумм файла команды из вашего набора средств и файла команды, установленного в системе на момент заражения, например
$ /toolkit/md5sum /toolkit/ps /bin/ps
Это необходимо на случай, если взломщик изменил исполняемый файл команды ps. Результат вывода вышеописанной команды будет иметь приблизительно следующий вид:
ac0b58050deb21db1ed701277521320b
/toolkit/ps
ac0b58050deb21db1ed701277521320b
/bin/ps
Если контрольные суммы MD5 совпадают, то, скорее всего, исполняемый файл ps на машине не был заражен. Командой md5sum можно проверить все файлы из набора средств и сравнить их с контрольными суммами файлов, установленных в системе. Отметьте все контрольные суммы MD5, которые не совпадают между собой.
После проверки контрольной суммы MD5 для ps, эту команду можно запустить для просмотра выполняющихся процессов в системе. В случае совпадения сумм MD5 команды ps из вашего набора и команды ps, установленной в системе, просмотр можно провести путем запуска как вашей версии /toolkit/ps, так и версии /bin/ps из системы. Если контрольные суммы не совпадают, запускайте /toolkit/ps; в противном случае полученный список может не соответствовать действительности. К тому же если взломщик в самом деле подменил исполняемый файл ps, то его запуск может привести к еще большим разрушениям. Копию списка процессов сохраните в текстовый файл для последующего изучения, затем просмотрите список на наличие необычных процессов либо процессов, которые до этого не были запущены в явном виде.
Я сталкивался с ситуациями, когда «троянский конь» присутствовал в списке процессов, но оставался незамеченным на фоне других процессов. К примеру, в списке наряду с несколькими процессами httpd может присутствовать и похоже названный «троянский конь». В выводе ps ниже процессы с идентификаторами PID 16972, 16975, 17333, 17724, 17805, 18360 и 19290 являются действительными процессами httpd Web-сервера Apache. Но обратите внимание на процесс с идентификатором PID 32444. У него похожее имя, и его легко пропустить при беглом просмотре списка. Но при ближайшем рассмотрении этот процесс с именем http не является частью Web-сервера Apache и вполне может быть искомым «троянцем»:
NMAP
Предполагая, что «виновный» все еще не найден, перейдем к следующей программе — nmap. Сканирование зараженной машины на наличие всех открытых портов UDP и TCP позволяет обнаружить, какой порт использует «троянский конь». Это может быть сделано посредством следующей команды:
$ /toolkit/nmap -sU -sS -p 1-65535 localhost
Вот пример вывода:
Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
Любопытные порты на localhost.localdomain (127.0.0.1):
(131048 просканированных, но не показанных ниже портов находятся в состоянии «закрыт».)
Порт Состояние Сервис Unable to find nmap-services! Resorting to /etc/services 25/tcp open smtp 53/tcp open domain 53/udp open domain 80/tcp open http 110/tcp open pop3 111/tcp open sunrpc 111/udp open sunrpc 137/udp open netbios-ns 138/udp open netbios-dgm 139/tcp open netbios-ssn 143/tcp open imap 389/tcp open ldap 443/tcp open https 515/tcp open printer 617/tcp open unknown 5222/tcp open unknown 5269/tcp open unknown 8383/tcp open unknown 10000/udp open unknown 19635/tcp open unknown 35737/udp open unknown
Nmap пытается автоматически привязать номер порта к названию сервиса в соответствии с файлом /etc/services, но в случае отсутствия чего-либо похожего возвращает значение unknown. Если после проверки вывода nmap вам не удается припомнить, что какой-либо процесс должен прослушивать 5222, то это можно попробовать выяснить посредством команды fuser из вашего комплекта средств.
Для того чтобы определить, какой процесс обращается к порту с этим номером, выполните следующее:
$ /toolkit/fuser -vn tcp 5222
Результатом будет:
USER PID ACCESS COMMAND 5222/tcp jabber 1918 f.... jabberd jabber 1919 f.... jabberd
Отсюда видно, что данной службой являлся jabber.
Команду fuser можно запустить повторно, чтобы узнать, какой идентификатор процесса (PID) ассоциируется с подозрительным портом TCP 19635:
$ /toolkit/fuser -vn tcp 19635
выводом которой будет:
USER PID ACCESS COMMAND 19635/tcp root 32444 f.... http
Очевидно, что процесс под названием http выполняется с идентификатором 32444 и слушает порт 19635. Этот процесс не входит в состав Web-сервера Apache. Если он остался незамеченным прежде, значит, сейчас мы точно знаем, что запущенный на машине «троянский конь» маскируется под законные процессы httpd.
Итак, с портом 5222 работает сервер jabber. Возможно, что сервер jabber после атаки не остался тем же сервером jabber, что и до атаки. Созданный взломщиком «троянец» мог заменить действительный процесс jabberd на процесс с тем же именем для работы на том же порту. Для проверки целостности исполняемого файла jabberd можно использовать md5sum и сравнить результаты вычисления контрольной суммы файла на «чистой» машине и файла на зараженной. Прежде мы делали это для проверки целостности файлов в нашем наборе и файлов на зараженном сервере. Другой полезный способ (если двоичный файл является частью RPM) — запустить команду rpm с ключом verify. В случае удаления или изменения любого изначально включенного в пакет файла менеджер пакетов Red Hat (Red Hat Package Manager, RPM) сообщит об этом. Мы можем выполнить следующую команду для проверки двоичного файла jabberd при условии, что сервер jabber был установлен с использованием rpm:
$ rpm -verify jabberd-0.9-1.rpm
Если все файлы (включая двоичный файл jabberd) являются исходными и не заражены, тогда, скорее всего, эта команда не выдаст никаких результатов. Если же jabberd на самом деле содержит «троянского коня» либо был изменен другим способом, тогда команда rpm сообщит нечто похожее на:
S.5...T /usr/bin/jabberd
Rpm с ключом verify проверяет контрольную сумму MD5, размер файла и права доступа для каждого файла, устанавливаемого из пакета RPM. Приведенная выше строка показывает, что размер файла (S) изменился, контрольные суммы MD5 не совпадают (5) и время модификации иное (T). Помимо S, 5 и T в случае изменения других атрибутов файла появятся дополнительные символы.
Локальный просмотр сетевых соединений возможен с помощью программы netstat. Она применяется как в сочетании с nmap, так и вместо nmap. Для поиска пропавших или измененных файлов воспользуйтесь командой find. В зависимости от вашего стиля расследования можно обратиться и к другим программам, но, мне кажется, что с задачей обнаружения «троянского коня» вполне могут справиться несколько широко известных программ. Дополнительные программы в наборе, например mv, cp, chmod и chown, присутствуют просто для упрощения и экономии времени в случае, если исходные программы были изменены или удалены.
ДРУГИЕ ИНСТРУМЕНТЫ
Вышеописанные действия могут не привести к желаемым результатам. В таком случае придется «копнуть» несколько глубже. Возможно, взломщик установил «троянского коня», который пока не проявляет активности на вашей машине. Его запуск, к примеру, мог быть запланирован с помощью cron или at. Чтобы выяснить это, необходимо просмотреть все файлы конфигурации cron и at на предмет их посредничества в запуске необычных программ. Кроме того, желательно проверить сценарии в каталогах cron.daily, cron.hourly и cron.weekly. Известны случаи, когда «троянец» маскировался под сценарий программы logrotate.
Необходимо также убедиться в чистоте всех запущенных демонов. К примеру, процесс syslogd оказывается скомпрометирован, и вместо действительного демона на порту UDP 514 запущен «троянец». Следовательно, надо проверить, нет ли изменений во всех исполняемых файлах и демонах и сохраняют ли они свою целостность. Нередко это становится весьма трудоемким занятием, которое может и не стоить потраченного времени и денег.
Задачу можно облегчить за счет использования Red Hat Package Manager с ключом verify либо иных программ с открытым кодом от сторонних источников, предназначенных как для непосредственного обнаружения «троянца», так и в качестве дополнения к имеющемуся комплекту инструментальных средств. Один из таких инструментов, chkrootkit, может обнаружить люк в системе, установленный как часть «троянского коня». Chkrootkit ищет известные последовательности символов в зараженных файлах. Он умеет отыскивать таких «троянцев», как Ramen Worm, T0rn rootkit или Ambient?s Rootkit for Linux, и это только малая часть. Кроме того, выявляет сетевые интерфейсы со способностью приема всех пакетов (promiscuous mode). После установки chkrootkit его можно запустить командой:
$ chkrootkit
которая выдаст примерно следующее:
ROOTDIR is '/' Checking 'chfn'... Not vulnerable Checking 'chsh'... Not vulnerable Checking 'cron'... Not vulnerable Checking 'sshd'... Not vulnerable Checking 'du'... Not vulnerable Checking 'find'... Not vulnerable Checking 'fingerd'... Not vulnerable Checking 'su'... Not vulnerable Checking 'ifconfig'... Not vulnerable Checking 'inetd'... Not vulnerable Checking 'killall'... Not vulnerable Checking 'login'... Not vulnerable Checking 'ls'... Not vulnerable Checking 'netstat'... Not vulnerable Checking 'passwd'... Not vulnerable Checking 'pidof'... Not vulnerable Checking 'ps'... Not vulnerable Checking 'rshd'... Not vulnerable Checking 'syslogd'... Not vulnerable Checking 'tcpd'... Not vulnerable Checking 'top'... Not vulnerable Checking 'telnetd'... Not vulnerable Checking 'asp'... Not vulnerable Checking 'bindshell'... Not vulnerable Checking 'z2'... Nothing deleted Checking 'wted'... Nothing deleted Checking 'sniffer'... eth0 is not promisc vmnet1 is not promisc Checking 'aliens'... No suspect files Searching for sniffer's logs, it may take a while... Nothing found Searching for t0rn's default files and dirs... Nothing found Searching for Ambient's rootkit (ark) default files and dirs... Nothing found Searching for suspicious files and dirs, it may take a while... /usr/lib/linuxconf/install/gnome/.directory /usr/lib/linuxconf/install/gnome/.order /usr/lib/perl5/5.00503/i386-linux/.packlist /usr/lib/perl5/site_perl/5.005/ i386-linux/auto/MD5/.packlist /lib/modules/2.2.14-5.0/.rhkmvtag Searching for Ramen Worm files and dirs... Nothing found Checking 'lkm'... Nothing detected
ЗАРАЖЕНИЕ ЯДРА LINUX
Непосредственное внимание в статье уделено заражению системных файлов «троянским конем», но он может внедриться и непосредственно в ядро Linux. Одним из таких известных «троянцев» является KIS Trojan, который был разработан с целью автоматизации загрузки модуля ядра. Будучи загруженным, модуль пытался скрыть свое присутствие и прослушивал сеть, ожидая инструкций. Здесь не будут обсуждаться особенности KIS Trojan, но я упомяну о доступных предупредительных мерах. Прежде всего, это загружаемый модуль безопасности (loadable security module, lsm). Будучи загруженным, lsm не допускает загрузки или выгрузки любого другого модуля ядра. Другой инструмент — lcap. С помощью данной утилиты суперпользователь может отключать функции ядра, в том числе возможность загрузки и выгрузки модулей. Для поиска нескольких известных «троянских» модулей ядра можно использовать chkrootkit. Команда lsmod, бывшая частью chkrootkit, предоставляет список запущенных или загруженных модулей и приспособлена для обнаружения «троянца» путем анализа списка загруженных модулей. Помните, что необходимо проверить целостность lsmod перед его запуском.
Если вы не обнаружили ничего необычного среди названных модулей, то, возможно, поражены какие-нибудь известные модули. Перепишите имена всех загруженных модулей на лист бумаги и вручную удалите их по одному из ядра командой rmmod. Так как модули скомпилированы из кода на Си, то просмотреть их исходный код не удастся. В целостности модулей можно убедиться посредством md5sum и сравнения результата с контрольной суммой неповрежденного модуля. Убедитесь, что версии ядра на зараженной и «чистой» машине совпадают.
КОММЕРЧЕСКИЕ ИНСТРУМЕНТЫ
Коммерческие антивирусные и «антитроянские» программы выпускаются такими производителями, как Sophos, NAI, Norton и Trend. Они могут отыскать «троянского коня» и удалить его из системы, но гарантии обнаружения именно на вашей системе нет.
ВЫВОДЫ
Единственный надежный метод избавления машины Linux от «троянского коня», в случае если не было принято превентивных мер, — полная переустановка системы. Уничтожение существующих «троянцев» успешно выполняют коммерческие антивирусные программы. Впрочем, их можно найти и удалить вручную. Этот процесс весьма трудоемок и не дает гарантии того, что на машине больше не осталось «троянских коней». Для увеличения шансов на удачное обнаружение «троянского коня» я рекомендую применение проактивных мер. Среди взломщиков немало желающих опробовать новые и улучшенные методы взлома, и без подобающей защиты все может закончиться тем, что вам придется переустанавливать систему с нуля.
Все процедуры, описанные здесь, применялись на практике. Некоторые клиенты, серверы которых не имели защиты, отказались от переустановки системы, в этом случае ручные процедуры оказались весьма эффективными в процессе уничтожения «троянских коней».
Ричард Паредез — администратор UNIX финансового учреждения в центре Манхэттена. С ним можно связаться по адресу: rfp@chappy.com.
Ресурсы Internet:
http://www.royalty.nu/legends/Troy.html
http://www.tripwire.org/
http://www.chkrootkit.org/