Jump to content
Калькуляторы

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

Сделал вируталку с 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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
48 minutes ago, vlad11 said:

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

 

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

 

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

Share this post


Link to post
Share on other sites
4 часа назад, Andrei сказал:

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites
7 часов назад, vlad11 сказал:

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

Exim-а нет.

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites
8 hours ago, alibek said:

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
7 hours ago, alibek said:

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

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

 

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

 

Share this post


Link to post
Share on other sites
В 23.10.2019 в 12:33, NewUse сказал:

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites
10 часов назад, vop сказал:

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

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

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

Share this post


Link to post
Share on other sites
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. Это самый простой и самый частый вариант, который не сильно зависит от дистрибутива и версии линукса.

 

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

Share this post


Link to post
Share on other sites
2 часа назад, vop сказал:

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

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

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

Share this post


Link to post
Share on other sites

Как дети.

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

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

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

Share this post


Link to post
Share on other sites
1 час назад, Ivan_83 сказал:

Цепляете

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

Share this post


Link to post
Share on other sites
1 hour ago, Ivan_83 said:

Как дети.

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

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

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

 

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

Share this post


Link to post
Share on other sites
9 часов назад, Andrei сказал:

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

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

Share this post


Link to post
Share on other sites
В 24.10.2019 в 12:26, alibek сказал:

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

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now