Выявление и лечение вируса на Linux-сервере.

1655
7
0
8

Практический опыт системного администрирования. Обнаружение и устранение ботнета c Linux-сервера.

Возникла беда с сервером. Жалуются, мол, то доступен, то недоступен. Ок, смотрим - действительно, так и есть. Картина стандартная, похоже на конкуренцию за IP. Клиент говорит что у него вся локалка, доступ к интернетам падает с такой же периодичностью.

Грешу на конфликты IP-адресов и/или сетевого оборудования. Говорю клиенту чтобы напряг своих сетевиков искать траблу у себя в сети. Ищут.

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

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

Как вариант, для дальнейшего траблшутинга, предлагаю попробовать задать другой адрес для проблемного сервера. Не помогает - с любым адресом клиническая картина идентичная. Да, это исключает конфликт IP, но все же оставляет версию с неполадками сетевого оборудования. Пробуйте занатить изначальный IP на другой хост в локалке. Делают. Все хорошо, все работает.

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

Смотрю логи /var/log/auth.log - стандартная активность.
Смотрю /var/log/syslog. Вижу, что в момент последнего тестирования от vnstat валится eth0" higher than set maximum 100 Mbit.
Ерунда какая-то. Такое было и до изоляции сервера. Но сомнения перерастают в подозрения - ботнет?

Первым делом смотрим сетевые соединения.
Легче сказать, поскольку сервер под нагрузкой и видим слишком много сетевых соединений.

   
netstat -utapen|wc
  1. 1246 11308 149790
 

Правда среди них много TIME_WAIT
Что-ж, исключим их:

netstat -utapen|grep -v TIME_WAIT

Листинг сетевых соединений в linux

Набирается чуть более сотни стабильных соединений.
Тщательно изучаем список, и ничего не находим. Оно и логично, мы ведь изолировали сервер от глобальной сети.

По сетевым надо смотреть непосредственно в момент, когда наблюдается проблема. Но у нас такой возможности нет, поскольку для этого нужно ногами идти к серверу и глазами смотреть в его монитор (консоль). У нас есть только изолированный сервер и ssh-доступ через цепочку хостов резервного канала.

Смотрим процессы. Но ps -fe тоже не показывает ничего подозрительного.

Ладно. Надо искать в etc. Святая святых, так сказать.
Недолго думая, просто вываливаю find /etc/ в консоль и просматриваю длиннющий список в 2k строчек. Поскольку все эти файлы мы видели тысячи раз, незнакомое непотребство надеюсь обнаружить легко. Так и выходит:

Листинг файлов в etc

Подозрения подкрепляются уверенностью: скомпрометирован!
Ну-ка, ну-ка, с этого момента поподробней. Выдача гугла по запросу "shtkdjwxlk" девственно чиста, как и следовало ожидать. Это похоже на рандомно сгененерированное имя.

Смотрим что еще интересного там есть на эту тему:

   
find /etc/|grep shtkdjwxlk
  1. /etc/rc2.d/S90shtkdjwxlk
  2. /etc/rc1.d/S90shtkdjwxlk
  3. /etc/rc5.d/S90shtkdjwxlk
  4. /etc/rc4.d/S90shtkdjwxlk
  5. /etc/rc3.d/S90shtkdjwxlk
  6. /etc/init.d/shtkdjwxlk
 

Стандартный набор линков для init-скрипта в deb-ситеме. Негусто.

Взгляну-ка в инит-скрипт.

   
less /etc/init.d/shtkdjwxlk
  1. #!/bin/sh
  2. # chkconfig: 12345 90 90
  3. # description: shtkdjwxlk
  4. ### BEGIN INIT INFO
  5. # Provides: shtkdjwxlk
  6. # Required-Start:
  7. # Required-Stop:
  8. # Default-Start: 1 2 3 4 5
  9. # Default-Stop:
  10. # Short-Description: shtkdjwxlk
  11. ### END INIT INFO
  12. case $1 in
  13. start)
  14. /boot/shtkdjwxlk
  15. ;;
  16. stop)
  17. ;;
  18. *)
  19. /boot/shtkdjwxlk
  20. ;;
  21. esac
 

Так вот ты какое, творение сумрачных китайских гениев.

Посмотрим, что же это у нас тут такое.

   
file /boot/shtkdjwxlk
  1. /boot/shtkdjwxlk: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
 

Тоже не за что зацепиться.
Ладно, посмотрим когда же мы стали жертвой.

   
ls -lh /boot/shtkdjwxlk
  1. -rwx------ 1 root root 648K Mar 31 20:28 /boot/shtkdjwxlk
 

Да, все сходится, жалобы на недоступность с этого времени и появились.

Что ж, посмотрим что еще есть вкусного в etc:

Поиск файлов в etc по дате и времени
Не смейтесь, пожалуйста, насчет моих команд-костылей. Да, я за 6 лет "ниасилил" ключи и опции find, а лезть в мануал мне лениво, да и время сейчас не самое подходящее :) Поэтому употребляю то, что просто поможет сейчас  find /etc/|xargs ls -lh|grep 'Mar 31 20:28'.

Видим, что кроме init-скрипта в то же время изменялось и добавлялось расписание cron.  Смотрим, что же у нас там в кроне.

   
less /etc/cron.hourly/cron.sh
  1. #!/bin/sh
  2. PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
  3. for i in `cat /proc/net/dev|grep :|awk -F: {'print $1'}`; do ifconfig $i up& done
  4. cp /lib/udev/udev /lib/udev/debug
  5. /lib/udev/debug
 

Ух-ты, как интересно. Вот и причина нашей беды с сетью. Это чудо постоянно передергивает интерфейсы, с периодичностью 3 раза в минуту.

Расписание вируса linux ddos в crontab

Посмотрим что нам засунули в /lib/.

   
file /lib/udev/udev
  1. /lib/udev/udev: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped

Да, скомпилировано тем же и там же, что и /boot/shtkdjwxlk . При сравнении по размеру видно что это копия одного и того же файла.

 

Инфа из крона, кстати,  помогает найти подробности о болячке. Гуглим кусок скрипта и находим несколько страниц об этом вирусе.

http://superuser.com/questions/863997/ddos-virus-infection-as-a-unix-service-on-a-debian-8-vm-webserver

И даже по-русски. http://dd-ip.ru/poleznye-stati/unix-system/posledstviya-ddos-ataki-pri-uyazvimom-bash/

Идем туда  и видим, что люди описывают точно такую же картину. Заодно там нам подсказывают как увидеть вирус в списке процессов.

ps -ej

Действительно, видно.

Вирус в листинге процессов linux
Любопытно, чем же это он там занимается.
Пустим в ход тяжелую артиллерию.

strace -p 23655

Просмотр системных вызовов процесса вируса linux ddos

Просмотр системных вызовов процесса вируса linux ddos 2

Просмотр системных вызовов процесса вируса linux ddos 3

Ага. Клонирует сам себя и уходит в sleep. Убиваем процесс, а он создает другой файл и запускает новый процесс. И все работает уже с другим именем, столь же затейливым - pocpyuytfy, например, или vktwvnzhcn.

Проверим другие места, в которых могли оказаться его файлы.

find /bin/|xargs ls -lh|grep 'Mar 31 20:28'
find /usr/|xargs ls -lh|grep 'Mar 31 20:28'
find /lib/|xargs ls -lh|grep 'Mar 31 20:28'

Все чисто.

Ну все, проблема выявлена, пора удалять вирус.

rm -f /lib/udev/udev
rm -f /boot/shtkdjwxlk
rm -f /etc/cron.hourly/cron.sh
find /etc/|grep shtkdjwxlk |xargs rm -f
vi /etc/crontab и удаляем строчку вида "*/3 * * * * root /etc/cron.hourly/cron.sh"

Меняем пароль.
passwd

Что-нибудь типа 0[etyysqg8l15!% - наверняка будет хорошо. И запомнить легко и пароль душевный.

Из истории на русском видели что вирус мог попасть через уязвимость в bash. Хотя у меня другая гипотеза его попадания туда, но об этом сейчас не буду.

Итак, проверяем:

env X="() { :;} ; echo vulnerable" bash -c "echo hello"
vulnerable
hello

Да, действительно, было дело. Тоже слышали про уязвимость ShellShock (http://www.securitylab.ru/vulnerability/458762.php ) , но до обновления баша на этом сервере видимо не дошли руки.

Что-ж.

apt-get install bash

env X="() { :;} ; echo vulnerable" bash -c "echo hello"
hello

Упаковал все найденные файлы в архив, забрал к себе для исследований. Пошел на https://www.virustotal.com и скормил файлик
shtkdjwxlk. Linux DDOS ему имя. От появления проблемы до полного устранения ушло примерно полдня.

Результат сканирования linux ddos

Как  видим, даже любимый хомячками "народный" антивирус Касперского не считает его вредоносным :) Что лишний раз  подтверждает: никакой антивирус не гарантирует безопасность и прежде всего нужно учиться пользоваться компьютером, о чем я и писал в статье.

Статья с исследованием этого вируса нашлась и на хабре: http://habrahabr.ru/post/248933/

Как оказалось, этот ботнет может жить где угодно - от винды до смартфонов. В том числе и на различных домашних (и не домашних)  роутерах.  Если заметите неладное с интернетом, если что-то "тормозит" - вероятно что где то в вашей сети живет ботнет и ваши устройства осуществляют DDOS-атаку под его управлением.

Что тут сказать. Пытливые китайские ребята заставляют быть бдительным! Бдите, друзья :)

p.s: Кстати, что то Юви слабенько сегодня шутит, я только под вечер заметил анаграммированные ники :)

Ad
Ad

Rate post

8

Comments

Login to comment