| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
|
|
Поиск закладок Представьте себе одну из самых страшных ситуаций, которые могут возникнуть в любой компании: увольняется системный администратор. Не страшно? Тогда ухудшим ситуацию: увольняется обиженный системный администратор. Сгустим краски - увольняется злой обиженный системный администратор. Вы уверены, что он не захочет отомстить компании? Хорошо, если не нравится ситуация с администратором, пусть нас пригласят на восстановление компьютера, захваченного хакером. В общем, в этой статье я попробую рассказать о методике поиска "закладок". Наученный горьким опытом, сразу вынужден оговориться, что я никогда не оставлял закладки и прочие подобные гадости - это не в моем стиле, да и незачем мне это. А вот искать приходилось и не раз. К счастью, общий уровень взломщиков очень низок, как и уровень большинства администраторов. Первые обычно пользуются дырами, которые не закрыли соответствующими патчами вторые. Среди взломщиков я еще не видел ни одного хакера. Мудаков видел много. Очень много. Самый типичный вариант - откапывание какого-нить замшелого руткита и попытка его использования без понимания, что и как он делает. Итак, начинаем. Я взял самый страшный случай: с сервером точно что-то не так. Но останавливать его надолго нельзя. Отключать из сети - тоже. Все остальные случаи будут производными от этого. Заходим в систему и смотрим, что используется. Затем любым способом приносим в систему обновленные версии всех установленных пакетов. Если нет обновленных версий, приносим заново те, что сейчас стоят. Главное, что бы вы были уверены в чистоте этих пакетов. И как можно быстрее их все устанавливаем. В идеале - все одной командой (rpm -Uhv *). Обязательно обращаем внимание на сообщения менеджера пакетов (опция -v). Затем блокируем менеджер пакетов (к примеру, запустите на отдельной консоли rpm -qa|less). Теперь смотрим на результаты:
Как вы можете понять из вышеприведенного, я только что показал два варианта маскировки в системе: Первый - это когда взломщик сам или с помощью root-kit'а модифицировал системные программы так, что бы они не показывали определенные процессы в системе. Сделать это не так сложно, как кажется на первый взгляд: исходные тексты всех программ доступны без каких-либо проблем. Второй - это модификация системных скриптов для запуска своих программ. В показанном примере вы сможете увидеть, что при обновлении rpm увидел, что inittab отличается от того, который он ожидал увидеть. А раз отличается, то в нем что-то добавлено или убрано. Насколько опасны эти изменения - решать вам. Третий пункт необходим для уверенности в том, что в системе стоят чистые версии программ. Как и исходники самих программ, исходные тексты пакетов доступны без проблем. Взломщик вполне мог собрать свою версию пакета и установить его в системе как обновление. В итоге все системы контроля, основанные на подсчете контрольной суммы программ (к примеру, сам rpm) считали бы, что все в порядке. Плюс если в программах была какая-то уязвимость (к примеру, были древние ssh, named и apache), то после обновления она автоматически закроется и не даст взломщику совершить повторную атаку. Последний пункт - блокировкой менеджера пакетов мы создали себе маленькую гарантию того, что пока мы разбираемся в других местах, взломщик не "обновит" то, что ему надо. Теперь воспользуемся командой netstat и определим, какие сервисы какие порты слушают. Здесь должны присутствовать только те сервисы, которые должны. Всех лишних "слухачей" вам необходимо с помощью kill -9 отстрелить. Только не забудьте, что вызывать тот же netstat необходимо с полным путем. Почему? Вот маленький пример: [root@vpn root]# mkdir test [root@vpn root]# cd test [root@vpn test]# cat > bad_file #!/bin/bash ls $1|grep -v bad_file [root@vpn test]# chmod +x bad_file [root@vpn test]# ls -l total 1 -rwxr-xr-x 1 root root 35 Jul 8 15:40 bad_file [root@vpn test]# alias ls='/root/test/bad_file' [root@vpn test]# ls [root@vpn test]# ls -l total 1 Как видите, взломщик может просто поправить тот же bash_profile и сделав скрипты-заглушки для основных утилит, спокойно скрыть практически любые изменения в системе, при этом не трогая самих утилит. И никакой tripwire не обнаружит подмены, если только его не натравливать на каждый файл в файловой системе, что будет являться чистой воды идиотизмом. Итак, пример обнаружения и отстрела неизвестной программы: [root@vpn root]# /bin/netstat -npl|/bin/grep LIST tcp 0 0 172.16.0.250:139 0.0.0.0:* LISTEN 826/smbd tcp 0 0 172.16.0.250:80 0.0.0.0:* LISTEN 762/httpd tcp 0 0 0.0.0.0:65500 0.0.0.0:* LISTEN 809/init tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 705/sshd tcp 0 0 0.0.0.0:1723 0.0.0.0:* LISTEN 790/pptpd tcp 0 0 172.16.0.250:443 0.0.0.0:* LISTEN 762/httpd [root@vpn root]# /bin/kill -9 809 [root@vpn root]# /bin/netstat -npl|/bin/grep LIST tcp 0 0 172.16.0.250:139 0.0.0.0:* LISTEN 826/smbd tcp 0 0 172.16.0.250:80 0.0.0.0:* LISTEN 762/httpd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 705/sshd tcp 0 0 0.0.0.0:1723 0.0.0.0:* LISTEN 790/pptpd tcp 0 0 172.16.0.250:443 0.0.0.0:* LISTEN 762/httpd Тут я прибил неизвестный мне процесс init, которому зачем-то понадобилось слушать порт 65500. Тем более, что я знаю то, что init в системе может быть один и он должен иметь pid равный единице. Теперь воспользуемся командой ps и начнем планомерный поиск с последующим убиванием всех странных программ, работающих в системе. [root@vpn root]# /bin/ps -axf Внимательно рассмотрите полученное дерево процессов. Первое, на что вам следует обратить внимание - это на присутствие неизвестных вам процессов. Их следует немедленно убивать. Максимум, что вы можете позволить себе перед выполнением команды kill, так это узнать, откуда был запущен процесс. Но особо не доверяйте этой информации - ее можно изменить. Второе, на что следует обратить внимание - это на "двойников". Простой пример: 762 ? S 0:04 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY -DHAVE_AUT 13835 ? S 0:00 \_ /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY -DHAVE 13836 ? S 0:00 \_ /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY -DHAVE 13837 ? S 0:00 \_ /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY -DHAVE 13838 ? S 0:00 \_ /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY -DHAVE 13839 ? S 0:00 \_ /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY -DHAVE 890 ? S 1:03 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY -DHAVE_AUT Как видите, процесс, имеющий pid 890, резко выделяется среди себе подобных. Если система специально так не сконфигурирована, то в ней должен быть один корневой httpd. Все остальные должны быть потомками. А этот процесс и не потомок и не имеет их. Тем более, имеет такое несуразное с остальными процессами время выполнения. Однозначно троян. А ведь не попроси мы ps построить дерево (ключ -f), то могли бы и пропустить такой процесс. Следующий этап по очистке - это ревизия системных файлов или поиск входов для взломщика. Самым частым методом является заведение нового пользователя или добавление возможности входа для пользователя. Вот поглядим на такой маленький пример из /etc/passwd rpm:x:37:37::/var/lib/rpm:/bin/bash если в /etc/shadow rpm:!!:12064:0:99999:7::: на месте двух восклицательных знаков пустота или наоборот - куча символов, то поздравляю, вы нашли один из входов взломщика. Понятное дело, пользователя rpm я взял для примера. Не забудьте проверить конфигурационные файлы для xinet.d или inetd. Вот пример:
[root@vpn root]# cd /etc/xinetd.d
[root@vpn xinetd.d]# cat daytime
# default: off
# description: A daytime server. This is the tcp \
# version.
service daytime
{
disable = no
id = daytime-stream
socket_type = stream
protocol = tcp
user = root
wait = no
server = /usr/lib/.../hackit
server_args =
}
Хотя по идее это вы должны были увидеть еще на этапе проверки системы netstat'ом. Все. Если вы проделали эти шаги, вам осталось вычистить остатки от троянцев и прочего мусора и начать проводить ревизию, того, что осталось и как так получилось. Необходимо просмотреть все, вплоть до конфигурационных файлов crond. Самыми часто употребляемыми взломщиками способами скрыть свою деятельность в системе является чистка логов. Тут я вам ничем помочь не могу, если вы заранее не побеспокоились о передаче логов на отдельную машину. Как это сделать man syslog.conf Конечно, вышеприведенный текст не является полным описанием способов маскировки взломщика на компьютере и методов защиты от этого. Я, к примеру, не рассказал про логические бомбы (к примеру, завязанные на блокирование аккаунта какого-либо пользователя), не рассказал я так же про интеграцию трояна с почтовыми системами (к примеру, через smrsh) и прочие подобные фокусы. Ибо все это описать невозможно. А вот как защищаться более серьезно от всех этих безобразий, я специально писать не стану. Почему? Во-первых, я не ставил такой цели. Я это написал лишь для того, что бы обозначить пути, которыми пользуются взломщики. Во-вторых, я сознательно отсекаю долбоебиков. Кто не понял идеи, тот на этом и застопорится. (если бы вы знали, как меня задолбали пионеры, которые не умеют пользоваться поисковыми серверами и не умеют читать документацию. Причем "пионер" - это вовсе не возраст, а сознание человека) И в-третьих, надо что-то оставить на поживу тем, кто живет с этого. Если фокусник будет рассказывать все о своих фокусах, никому не будет интересно ... ;-) Viacheslav "multik" Kaloshin multik@multik.ru |
|
|
| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
|