Китайская зараза

[Andrei]

Сделал вируталку с Debian 9, рутовый пароль был сгенерен pwgen-ом и на всякий случай положен в виде текстовика в home-каталог другого пользователя. Оставили виртуалку до утра, fail2ban думал поставить утром. Но с утра - загрузка проца:

top
top - 13:31:33 up 7 min,  1 user,  load average: 1.48, 1.20, 0.66
Tasks: 110 total,   1 running, 109 sleeping,   0 stopped,   0 zombie
%Cpu(s):  6.5 us, 20.5 sy,  0.0 ni, 41.2 id,  0.0 wa,  0.0 hi, 31.8 si,  0.0 st
KiB Mem :  8463984 total,  6299580 free,  1345092 used,   819312 buff/cache
KiB Swap:  2317308 total,  2317308 free,        0 used.  6870524 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  349 root      20   0   93024   2576    404 S 140.5  0.0   6:25.43 lcirauqola
    3 root      20   0       0      0      0 S  31.6  0.0   1:12.09 ksoftirqd/0
   28 root      20   0       0      0      0 S  18.3  0.0   0:38.09 ksoftirqd/3
   22 root      20   0       0      0      0 S   9.6  0.0   0:23.09 ksoftirqd/2

Ну и трафик тут же:

iftop -i eth0
interface: eth0
                    19.1Mb              38.1Mb              57.2Mb              76.3Mb        95.4Mb
mqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqq
188.xxx.xxx.xx                      <=> h118-184-158-103.pubyun.com          14.5Mb  8.41Mb  3.82Mb
188.xxx.xxx.xx                      <=> h118-184-158-103.pubyun.com          14.4Mb  8.40Mb  3.82Mb
188.xxx.xxx.xx                      <=> h118-184-158-103.pubyun.com          14.4Mb  8.35Mb  3.80Mb
188.xxx.xxx.xx                      <=> h118-184-158-103.pubyun.com          14.5Mb  8.35Mb  3.80Mb
188.xxx.xxx.xx                      <=> h118-184-158-103.pubyun.com          14.6Mb  8.34Mb  3.79Mb
188.xxx.xxx.xx                      <=> h118-184-158-103.pubyun.com          14.3Mb  8.34Mb  3.79Mb
188.xxx.xxx.xx                      <=> h118-184-158-103.pubyun.com          14.3Mb  8.30Mb  3.77Mb
188.xxx.xxx.xx                  <=> h118-184-158-103.pubyun.com          14.4Mb  8.26Mb  3.76Mb
188.xxx.xxx.xx                     <=> h118-184-158-103.pubyun.com          14.2Mb  8.13Mb  3.70Mb

Показания last не выявили подозрительных подключений по ssh, но :

cat auth.log | grep Accept

Oct 21 05:18:45 deb9lb sshd[5829]: Accepted password for root from 218.92.0.163 port 24517 ssh2
Oct 21 06:53:23 deb9lb sshd[6291]: Accepted password for root from 222.112.82.68 port 33548 ssh2

Лоханулся, виноват. :(

Рутовый пароль себе конечно вернул, fail2ban поставил, настроил. Как пароль утек - не понятно. В логах apache и т.п. ничего не находится. На виртуалку кроме меня и еще одного сотрудника не пускали, пока не понятны причины инцидента.

В итоге в top остались болтаться процессы с именами вида zjrysuhgxefeqy, ythovtgja, tvlnvndlywhdne и т.п. Нагрузку уже не создают ни на сеть, ни на проц, но надо ж эту заразу повывести.

Из симптоматики - в кроне:

 cat /etc/cron.hourly/endhwyldnvnlvt.sh
#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
cp "/bin/endhwyldnvnlvt" "/bin/twtfswvvzk"
"/bin/twtfswvvzk"

Ну и разумеется в /bin/ 

ls -l endhwyldnvnlvt*
-rwxr-xr-x 1 root root 562341 Oct 22 23:43 endhwyldnvnlvt
-rwxr-xr-x 1 root root    151 Oct 22 23:43 endhwyldnvnlvt.sh
[1]+  Done                    ls --color=auto -l endhwyldnvnlv

В /etc/init.d:

 ls -l /etc/init.d/endhwyldnvnlvt
-rwxr-xr-x 1 root root 358 Oct 22 23:43 /etc/init.d/endhwyldnvnlvt

 

 cat /etc/init.d/endhwyldnvnlvt
#!/bin/sh
# chkconfig: 12345 90 90
# description: endhwyldnvnlvt
### BEGIN INIT INFO
# Provides: endhwyldnvnlvt
# Required-Start:
# Required-Stop:
# Default-Start: 1 2 3 4 5
# Default-Stop:
# Short-Description: endhwyldnvnlvt
### END INIT INFO
case $1 in
start)
        "/bin/tvlnvndlywhdne"
  break
        ;;
stop)
  break
        ;;
*)
        "/bin/tvlnvndlywhdne"
  break
        ;;
esac

Можно эту заразу как-то вывести или виртуалку в морг?

[vlad11]

Проще в морг.
P.S. наверное, доступ получили через exim.

[vop]

48 minutes ago, vlad11 said:

Проще в морг.
P.S. наверное, доступ получили через exim.

 

Проще переставить, если сервер новый.

 

PS А exim4 из коробки портами наружу не светит.

[taf_321]

4 часа назад, Andrei сказал:

Можно эту заразу как-то вывести или виртуалку в морг?

Однозначно в морг.

2 часа назад, vop сказал:

Проще переставить, если сервер новый.

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

[maxlapshin]

вывести руткит с сервера условно невозможно.

 

Если вам очень повезло, он не прошился в биос и вы сможете его вылечить переустановкой всего с нуля.

 

Пытаться пройтись по операционной системе каким-нибудь антивирусом, чтобы он вам удалил руткит — на это надеяться не стоит. Может поможет, а может руткит воткнулся в ядро и перехватывает половину системных вызовов и показывает вам неправильный ps и прочее.

[Andrei]

7 часов назад, vlad11 сказал:

наверное, доступ получили через exim.

Exim-а нет.

3 часа назад, taf_321 сказал:

Даже если сервер старый и заслуженный, то его тоже в морг.

Это виртуалка, на хост-системе ничего такого нет.

44 минуты назад, maxlapshin сказал:

Если вам очень повезло, он не прошился в биос и вы сможете его вылечить переустановкой всего с нуля.

Из виртуалки прошить биос?

[NewUse]

сносить виртуалку, если система с нуля поставленна, то перед сносом не плохо бы куда-нибудь отправить на анализ, видать какая-то дырка где-то есть... 9-ка вроде на поддержке ещё, вообще, очень странно... и очень тревожный симптом...

[Andrei]

rkhunter ничего интересного не нашел

System checks summary
=====================

File properties checks...
    Files checked: 143
    Suspect files: 0

Rootkit checks...
    Rootkits checked : 377
    Possible rootkits: 0

Applications checks...
    Applications checked: 4
    Suspect applications: 0

The system checks took: 14 minutes and 36 seconds

 

[alibek]

Качественный руткит обнаружить или убрать изнутри системы невозможно.

Поэтому запущенный в системе rkhunter или любой другой подобный инструмент или антивирус бесполезен.

Хоть какой-то смысл в подобных утилитах есть только при запуска их с LiveCD, но и то при условии, что известно, что искать.

Так что тоже присоединяюсь к совету все снести и переустановить.

Вирусы в BIOS лично я считаю за городские легенды. Еще ни разу видеть их не доводилось, да и на половине серверов запись в BIOS по умолчанию заблокирована.

[vop]

8 hours ago, alibek said:

Качественный руткит обнаружить или убрать изнутри системы невозможно.

 

Что-то вы совсем как-то пессимистично. :)  Любой руткит вывести можно. Только иногда очень сложно, и не каждый сможет. :) Поэтому порой, действительно, проще сервер переставить, сохранив данные.

 

PS А то прям ньюбов пугаете. :)

[alibek]

Проверить на какой-то конкретный руткит в ряде случаев можно. А обнаружить какой-то неизвестный нельзя. Все что детектор или антивирус может проверить, руткит может перехватить и подменить.

[vop]

7 hours ago, alibek said:

Проверить на какой-то конкретный руткит в ряде случаев можно. А обнаружить какой-то неизвестный нельзя. Все что детектор или антивирус может проверить, руткит может перехватить и подменить.

Ладно, пусть будет по вашему...  Просто намекну, что кроме антивирусов и детекторов есть голова, руки, аналитика. Но это не каждому под силу. Ну и проверить целостность системы не катастрофически сложно.  Для этого известность руткиту не особо нужна. Нужно понимание, что и как может он делать.

 

У себя я ловил руткит один раз лет 15 назад, если не раньше. Но коллекция из тех, которых пришлось выковыривать у страдальцев набралась средненькая.

 

[Andrei]

В 23.10.2019 в 12:33, NewUse сказал:

перед сносом не плохо бы куда-нибудь отправить на анализ, видать какая-то дырка где-то есть... 9-ка вроде на поддержке ещё, вообще, очень странно... и очень тревожный симптом...

Кто-то занимается таким анализом? Поискать на debian.org сообщества разработчиков?

[alibek]

Сегодня сам поймал какую-то инфекцию.

У меня есть один отдельный ПК на Windows XP. На нем минимум софта, только сетевые утилиты, я обычно использую его для настройки оборудования. XP SP3 с последними обновлениями, которые были выпущены, и с отключенным встроенным файрволом.

Сегодня для проверки качества ПМ подал на него транспортный VLAN (от другого оператора) и статикой задал публичные IP-адреса.

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

Конечно на ПК был Acronis Startup Recovery Manager, поэтому восстановил его я быстро, но все равно был впечатлен скоростью заражения.

[Andrei]

Я тоже, как только создал новую виртуалку и дал ей публичный ip, сразу в логах увидел попытки перебора паролей по ssh. Поэтому первым делом /etc/host.allow и /etc/host.deny, потом fail2ban и только потом уже занялся основными задачами.

[vop]

По ipv6 идет бешенное "нападение" от китайских "друзей" (China Telecom) - перебор адресов случайным образом - а там поле для выбора адресов огромное. Как подключаешь /64 - поехали. reject list постепенно пополняется. :)

 

Кстати, паролями в ssh давно не пользуюсь. Только ключами.

[Andrei]

10 часов назад, vop сказал:

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

Пока зараженную виртуалку не выключил, послушал что за трафик и куда с нее сейчас идет.

Идут dns-запросы на 53 порт dns.google 8.8.8.8 на счет доменов типа k1.2018fly.com или p11.2017fly.com или p11.sb1024.net и т.п.. В ответ от гугла прилетает либо перечень ip, либо "No such name".

[vop]

27 minutes ago, Andrei said:

Пока зараженную виртуалку не выключил, послушал что за трафик и куда с нее сейчас идет.

Идут dns-запросы на 53 порт dns.google 8.8.8.8 на счет доменов типа k1.2018fly.com или p11.2017fly.com или p11.sb1024.net и т.п.. В ответ от гугла прилетает либо перечень ip, либо "No such name".

Многие заразы заливают /tmp  перловую молотилку (любого предназначения), запускают ее, и стирают на диске все следы. Расчет идет на то, что сервер работает долго без перезагрузок. Иногда можно найти в /proc ссылку exe на несуществующий файл в каталоге /tmp. Это самый простой и самый частый вариант, который не сильно зависит от дистрибутива и версии линукса.

 

В любом случае, надо искать эксплоит и "того", кто/что его применил.

[Andrei]

2 часа назад, vop сказал:

В любом случае, надо искать эксплоит

Из любопытства поковыряюсь. Так-то вчера уже сделал другую виртуалку и за сегодня все на нее накатил.

Эту, после удаления установленного мной софта, можно и отдать для опытов.

[Ivan_83]

Как дети.

Цепляете диск виртуалки к чистой системе и сверяете хэши файлов, ищите файлы которые не относятся ни к одному пакету.

В результате получите список всех файлов которые были зменены либо не относятся ни к одному из пакетов.

По крайней мере во фре это всё сделать можно почти на автомате, особенно тем кто обновляет систему с бинарников, а не как я компеляет всё с исходников.

[Andrei]

1 час назад, Ivan_83 сказал:

Цепляете

Я далеко не ребенок, но как это сделать не представляю. Да и не стОит оно того.

[vop]

1 hour ago, Ivan_83 said:

Как дети.

Цепляете диск виртуалки к чистой системе и сверяете хэши файлов, ищите файлы которые не относятся ни к одному пакету.

В результате получите список всех файлов которые были зменены либо не относятся ни к одному из пакетов.

По крайней мере во фре это всё сделать можно почти на автомате, особенно тем кто обновляет систему с бинарников, а не как я компеляет всё с исходников.

 

В deb-линуксах целостность проверяется по контрольным суммам файлов (например, при помощи debsums). Так находятся подмены всех этих ps, sshd и т.д. А подмены - это второй вариант заразы, который остается на диске и рассчитан на перегрузку системы.

[NewUse]

9 часов назад, Andrei сказал:

Кто-то занимается таким анализом? Поискать на debian.org сообщества разработчиков?

Вроде Касперский раньше принимал, ну и в сообщество тоже стоит...

[NiTr0]

В 24.10.2019 в 12:26, alibek сказал:

У меня есть один отдельный ПК на Windows XP. На нем минимум софта, только сетевые утилиты, я обычно использую его для настройки оборудования. XP SP3 с последними обновлениями, которые были выпущены, и с отключенным встроенным файрволом.

Сегодня для проверки качества ПМ подал на него транспортный VLAN (от другого оператора) и статикой задал публичные IP-адреса.

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

небось самба не отключена? так ничего удивительного, SMBv1 похож на штопаное-перештопаное резиновое изделие - сколько его ни штопали, а победить все дыры так и не смогли, причем обнаруживаемые дыры существовали во всех виндах NT начиная с NT4 (а возможно - и 9х + NT3.51 за компанию). потом правда майкрософт решил не писать уже в багрепортах EOL операционки :) собссно почему сейчас SMBv1 в десятке то ли отключен по дефолту и включается очень шершавым напильником, то ли вообще уже выпилен.