Перейти к содержимому
Калькуляторы

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

48 minutes ago, vlad11 said:

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Exim-а нет.

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8 hours ago, alibek said:

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

7 hours ago, alibek said:

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

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как дети.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Цепляете

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 hour ago, Ivan_83 said:

Как дети.

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.