Как бороться (найти и уничтожить) с руткитом на Linux-сервере (в моём случае, Ubuntu Server)?

Итак, ситуация, к сожалению, стандартна: я не беспокоился о защите сервера, и за это — его сломали. Всё справедливо, никаких претензий к фортуне. Но теперь встал вопрос о недопущении ошибок в будущем.


На VPS стоит Ubuntu Server 10.10 (фаерволл не был включен), когда с него начали брутфорсить кого попало, то моему хостеру посыпались абузы, а он дал мне сутки на то, чтобы я закрыл дыры и отчитался, иначе прибьют мой аккаунт. Хостер Hetzner.de — молодец, другие бы небось сразу бахнули аккаунт, а эти дали время на устранение брешей.


Дальше опишу действия, которые предпринял.


Прошу квалифицированных хабровчан подсказать:

  1. Что я делал после атаки ни так и чего из необходимого не сделал?
  2. Как же теперь искать руткита?
  3. Если есть какие-нибудь комплексные мануалы по базовой защите на русском или простом английском, то ткните в них, пожалуйста.


Свои IP я далее исказил, а IP плохих парней оставил неизменными (на случай, если кто-то будет гуглить спасение от них).

~# sockstat | grep 22<br/>
root sshd 1795 tcp4 79.47.35.666:22 96.156.140.666:54113 ESTABLISHED # моё<br/>
root sshd 17351 tcp4 *:22 *:* LISTEN<br/>
root sshd 17364 tcp4 79.47.35.666:22 2.2.44.3:51557 ESTABLISHED # чужое<br/>
root sshd 17365 tcp4 79.47.35.666:22 2.2.44.3:51557 ESTABLISHED # чужое<br/>
root sshd 18871 tcp4 79.47.35.666:22 96.156.140.666:57163 ESTABLISHED # моё



Попробовал посмотреть, кто вообще юзает ssh:

~# ps ax | grep ssh<br/>
 1795 ? Ss 0:02 sshd: root@pts/0<br/>
17351 ? Ss 0:00 /usr/sbin/sshd -D<br/>
18871 ? Ss 0:00 sshd: root@notty # это точно не моё<br/>
18886 ? Ss 0:00 /usr/lib/openssh/sftp-server<br/>
30370 ? Ss 0:00 sshd: root [priv]<br/>
30371 ? S 0:00 sshd: root [net]<br/>
30373 pts/0 S+ 0:00 grep --color=auto ssh



Бахнул процесс:

~# kill 18871


Врубил фаерволл, добавил правила:

~# ufw status<br/>
Status: active<br/>
<br/>
To Action From<br/>
-- ------ ----<br/>
Apache ALLOW Anywhere<br/>
Postfix ALLOW Anywhere<br/>
Anywhere ALLOW 97.157.140.172<br/>
Anywhere ALLOW 194.247.190.1<br/>
22 LIMIT Anywhere<br/>
21 LIMIT Anywhere<br/>
<br/>
22 DENY OUT Anywhere<br/>
21 DENY OUT Anywhere



И sockstat теперь говорит, что на IP 2.2.44.3 никто уже не лезет.


Пошёл искать кто и как приходил на сервер.

~# cat /var/log/auth.log | grep &quot;Accepted &quot;<br/>
...<br/>
Mar 13 23:23:22 ubuntuserver sshd[27438]: Accepted password for webmaster from 114.80.100.241 port 37966 ssh2<br/>
Mar 13 23:23:22 ubuntuserver sshd[27439]: Accepted password for webmaster from 114.80.100.241 port 47732 ssh2<br/>
...<br/>
Mar 15 07:39:58 ubuntuserver sshd[6320]: Accepted password for webmaster from 79.117.72.150 port 1217 ssh2<br/>
...



Был у меня такой юзер с доступом в консоль (юзер создавался давно, не исключено, что у него пароль был смешной или что пароль запалился у кого-то из сотрудников на локальном компе через вирус, ибо от ftp пароль такой же и его сохраняли в клиентах).


Но этот webmaster не был в sudoers. Получается, у меня какой-то руткит?


Установил rkhunter и chkrootkit


Первый нашёл такие подозрительности:

[14:57:13] Checking for hidden files and directories [ Warning ]<br/>
[14:57:13] Warning: Hidden directory found: /dev/.udev<br/>
[14:57:13] Warning: Hidden directory found: /dev/.initramfs<br/>
[14:57:13] Warning: Hidden file found: /dev/.blkid.tab: ASCII text<br/>
[14:57:13] Warning: Hidden file found: /dev/.blkid.tab.old: ASCII text



Но в интернетах bugs.launchpad.net/ubuntu/+source/rkhunter/+bug/86153 говорят, что это он зря ругается.


Второй нашёл только это:
Checking `chkutmp'... The tty of the following user process(es) were not found in /var/run/utmp !



Но это были мои же рут-сессии, запущенные внутри screen.


И… получается, что в остальном всё чисто.


Как теперь искать руткит?
  • Вопрос задан
  • 10293 просмотра
Пригласить эксперта
Ответы на вопрос 10
@vilgeforce
Раздолбай и программист
Переставить систему с нуля. Это наиболее правильно для сервера.
Ответ написан
bagyr
@bagyr
> Но этот webmaster не был в sudoers. Получается, у меня какой-то руткит?
Ничего не получается, скорее всего какой-то эксплойт. Лучше накатить с нуля систему и любую не статику (php скрипты etc.) из бекапа. По-иному есть шанс что-то не найти.
Ответ написан
Комментировать
@iznakurnozh
1. Попробуйте для начала утилиту unhide для поиска спрятанного процесса (если таковой есть)
2. переустановите все пакеты. Вот скрипт:

#!/bin/bash

for pkg in `dpkg --get-selections|awk '{print $1}'| egrep -v '(dpkg|apt)'`; do apt-get install --reinstall -y $pkg; done

3. Используйте tripwire для контроля целостности файлов (на будущее)
Ответ написан
Комментировать
taliban
@taliban
php программист
Не жлобитесь, наймите дорогого админа, пусть он вам все сделает «мздато» и расскажет опосля что и как он сделал, и что и как нужно сделать Вам. Это единоразовая плата, в итоге если растянуть на время работы сервера это не будет дорого.
Ответ написан
Комментировать
@odmin4eg
я один раз встречался с руткитом, ркхантер его не находил, было года 4 назад, деталей не помню, он умело прятался от ТОП ps и ещё много чего, но святился исходящим соединением.
дальше по цепи этого соединия был найден «модуль ядра»… переустановка решила вопрос.

ещё также недавно у одного из знакомых был сайт на нулленым движке, не менявшийся лет 5 и вот через него мне загрузили файл (шелл) собрали «ирк клиента» и также зацеплись с к удалённому серверу. процесс работал от пользователя apache

Погасив многое я нашёл файл, который использовался апачем. простое ф3 по исполняемому файлу показало параметры соединения с ирк сервером, пошёл я туда и пообщался с админом того канала, ботов таких у него было большее 250.

всеми серверами он рулил прямо из канала, сказал что продаёт серваки спаммерам, сказал через что он ко мне попал, сказал что из малазии он. серваки продаёт от 5 до 100 баксов.

просил меня дать ему шелл только для «ИРКпрокси» ничего большего :))

имеет смысл поискать «пхп шелл» или подобные «штуки»

у меня была перловская картинка кстати, файл jpg внутри с пёрл скриптом по сборке ирк демона :))

опыта я тогда наполучался много :))
Ответ написан
Комментировать
pentarh
@pentarh
Я делаю в таком случае миграцию данных на промежуточный сервер, реинсталл текущего и миграцию обратно. Ну или просто на другой чистый сервер.

Линукс — сложная система. Каждый сисадмин желает знать где сидит руткит. Но таких мест слишком много. Что то упустил и весь многодневный труд на смарку. В перспективе реинсталл проще.
Ответ написан
Комментировать
shadowalone
@shadowalone
Странно вообще, что Вам об этом сообщил хостер после жалоб, а не Вы сами узнали.
Вот кстати, из-за скупости держателей серверов на нормальных админов такое и происходит, хотя для поддержания средненького сервера удаленно, вполне нормально иметь хотя б удаленного админа.
То есть получается что Вы не следили должным образом за сервером, ни как не мониторили его, не просматривали логи — так что ж Вы хотите то?
В идеале, поставить сервер с нуля, нанять человека для адекватной настройки защиты. Далее, либо самому подтягивать знания, либо оставить человека на зарплате, хотя б на начальное время.

Я не понимаю, как можно не отслеживать заходы по ssh — это раз. (хотяб logwatch что-ли прикрутили бы)
Не понимаю как можно оставлять ssh на стандартном порту и не блокировать количество попыток коннекта к нему с одного IP — это два.
И я совсем не понимаю, как можно нырять в океан не умея плавать — это три.
Ответ написан
skromnik
@skromnik
Если у вас ядро с поддержкой модулей, то есть вероятность еще и ядерных руткитов.
Переустановка сервера — самый простой и быстрый способ решить проблему.
Ответ написан
Комментировать
mikhanoid
@mikhanoid
Надо бы ещё настроить SSH, если по уму: отключите протокол версии 1, отключите вход для root, отключите авторизацию по паролю и оставьте только по ключам. Займитесь настройкой прав доступа: уберите всех пользователей из группы wheel (в идеале, вообще оставьте каждого пользователя в своей группе), удалите sudo.

Посмотреть за rootkit'ом, если он в ядро не пролез, можно при помощи утилиты lsof — в Linux сложно скрыть работу с какими-нибудь файлами, ищите всякие записи, вроде (deleted), может и повезёт. Но если взломщик получил root'а, то он, скорее всего засунул модуль в ядро, который способен скрываться, что достаточно просто и студенты делают за месяц, как бы, мощь Linux тут против него играет. От этого Вас спасёт только переустановка. И берегите root в дальнейшем, как зеницу ока.
Ответ написан
Комментировать
@vinnishtein
переставьте SSH демон, его бинарник могут заменить, и входить по паролю, но это не будет логироваться, и злоумышленник будет спокойно входить, хоть 10 раз пароль меняйте
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы