Это утро выдалось неожиданно насыщенным для нашей службы технической поддержки 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.

ПРЕВЕНТИВНЫЕ МЕРЫ

«Троянский конь» — это программа со скрытыми функциями. Выполняя на первый взгляд некоторые разрешенные действия, на самом деле она может удалять файлы, устанавливать вирусы или другого «троянского коня», создавать в системе люки для несанкционированного доступа и подавлять ее активность для сокрытия факта атаки. Вот несколько советов, которые помогут снизить риск «троянских» атак.

  1. Постоянно будьте в курсе новостей из мира информационной безопасности.
  2. Никогда не устанавливайте программы "вслепую", даже из "доверенных источников". Иногда такой источник сам может не подозревать о наличии "троянского коня". К примеру, NAI сообщало об обновлении к программе BIND, якобы устраняющем ошибку в системе безопасности. На самом деле обновление являлось "троянцем".
  3. Проверяйте контрольные суммы MD5 загруженных из Internet программ и программ из внешних источников.
  4. Никогда не открывайте вложения из писем, если вы не уверены в чистоте намерений их отправителя.
  5. С осторожностью относитесь ко всему, что запускается из браузера Internet. Апплеты Java, программы ActiveX и JavaScript могут устанавливать "троянцев".
  6. Старайтесь, по возможности, входить в систему с правами непривилегированного пользователя. Использование учетной записи суперпользователя для выполнения повседневных административных задач увеличивает вероятность поражения системы.

«Троянских коней» можно выявить с помощью систем обнаружения вторжений (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/

Поделитесь материалом с коллегами и друзьями