--- title: "Выявление и лечение вируса на Linux-сервере." description: "Возникла беда с сервером. Жалуются, мол, то доступен, то недоступен. Ок, смотрим - действительно, та..." author: "dr_Motor" published: "2015-04-01T07:34:01+00:00" modified: "2015-04-01T07:37:23+00:00" locale: "ru" canonical_url: "https://yvision.kz/post/vyyavlenie-i-lechenie-virusa-na-linux-servere-487270" markdown_url: "https://yvision.kz/post/vyyavlenie-i-lechenie-virusa-na-linux-servere-487270/markdown" site_name: "Yvision.kz" --- # Выявление и лечение вируса на Linux-сервере. > Возникла беда с сервером. Жалуются, мол, то доступен, то недоступен. Ок, смотрим - действительно, та... Возникла беда с сервером. Жалуются, мол, то доступен, то недоступен. Ок, смотрим - действительно, так и есть. Картина стандартная, похоже на конкуренцию за IP. Клиент говорит что у него вся локалка, доступ к интернетам падает с такой же периодичностью. Грешу на конфликты IP-адресов и/или сетевого оборудования. Говорю клиенту чтобы напряг своих сетевиков искать траблу у себя в сети. Ищут. Через некоторое время они обнаружили, что после того как отрубают NAT от сервера - с локальной сетью становится все хорошо, интернеты работают и.т.д и.т.п. У меня нет версий, это похоже на коллизию в сети, ищите еще. На сервере нету ничего такого, что могло бы себя вести подобным образом. Еще и всю локальную сеть класть. Как вариант, для дальнейшего траблшутинга, предлагаю попробовать задать другой адрес для проблемного сервера. Не помогает - с любым адресом клиническая картина идентичная. Да, это исключает конфликт IP, но все же оставляет версию с неполадками сетевого оборудования. Пробуйте занатить изначальный IP на другой хост в локалке. Делают. Все хорошо, все работает. Вот теперь ко мне в душу закрадываются сомнения. Засучив рукава, погружаемся в консоль, подключившись к проблемному хосту через резервный канал связи. Смотрю логи */var/log/auth.log* - стандартная активность. Смотрю */var/log/syslog*. Вижу, что в момент последнего тестирования от vnstat валится eth0" higher than set maximum 100 Mbit. Ерунда какая-то. Такое было и до изоляции сервера. Но сомнения перерастают в подозрения - ботнет? Первым делом смотрим сетевые соединения. Легче сказать, поскольку сервер под нагрузкой и видим слишком много сетевых соединений.     netstat -utapen|wc - 1246 11308 149790   Правда среди них много *TIME_WAIT* Что-ж, исключим их: > netstat -utapen|grep -v TIME_WAIT ![Листинг сетевых соединений в linux](http://storage.yvision.kz/images/user/dr_motor/e93EZS0SJ92kK06xaZvKiROzKL4oK2.png) Набирается чуть более сотни стабильных соединений. Тщательно изучаем список, и ничего не находим. Оно и логично, мы ведь изолировали сервер от глобальной сети. По сетевым надо смотреть непосредственно в момент, когда наблюдается проблема. Но у нас такой возможности нет, поскольку для этого нужно ногами идти к серверу и глазами смотреть в его монитор (консоль). У нас есть только изолированный сервер и ssh-доступ через цепочку хостов резервного канала. Смотрим процессы. Но *ps -fe* тоже не показывает ничего подозрительного. Ладно. Надо искать в etc. Святая святых, так сказать. Недолго думая, просто вываливаю *find /etc/* в консоль и просматриваю длиннющий список в 2k строчек. Поскольку все эти файлы мы видели тысячи раз, незнакомое непотребство надеюсь обнаружить легко. Так и выходит: ![Листинг файлов в etc](http://storage.yvision.kz/images/user/dr_motor/b60nt0ch6WoSiyCBRL5wq8yJye71O8.png) Подозрения подкрепляются уверенностью: скомпрометирован! Ну-ка, ну-ка, с этого момента поподробней. Выдача гугла по запросу "*shtkdjwxlk*" девственно чиста, как и следовало ожидать. Это похоже на рандомно сгененерированное имя. Смотрим что еще интересного там есть на эту тему:     find /etc/|grep shtkdjwxlk - /etc/rc2.d/S90shtkdjwxlk - /etc/rc1.d/S90shtkdjwxlk - /etc/rc5.d/S90shtkdjwxlk - /etc/rc4.d/S90shtkdjwxlk - /etc/rc3.d/S90shtkdjwxlk - /etc/init.d/shtkdjwxlk   Стандартный набор линков для init-скрипта в deb-ситеме. Негусто. Взгляну-ка в инит-скрипт.     less /etc/init.d/shtkdjwxlk - #!/bin/sh - # chkconfig: 12345 90 90 - # description: shtkdjwxlk - ### BEGIN INIT INFO - # Provides: shtkdjwxlk - # Required-Start: - # Required-Stop: - # Default-Start: 1 2 3 4 5 - # Default-Stop: - # Short-Description: shtkdjwxlk - ### END INIT INFO - case $1 in - start) - /boot/shtkdjwxlk - ;; - stop) - ;; - *) - /boot/shtkdjwxlk - ;; - esac   Так вот ты какое, творение сумрачных китайских гениев. Посмотрим, что же это у нас тут такое.     file /boot/shtkdjwxlk - /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 - -rwx------ 1 root root 648K Mar 31 20:28 /boot/shtkdjwxlk   Да, все сходится, жалобы на недоступность с этого времени и появились. Что ж, посмотрим что еще есть вкусного в etc: ![Поиск файлов в etc по дате и времени](http://storage.yvision.kz/images/user/dr_motor/wN33WKPLtLO5B3ZesByjtorBddyumV.png) Не смейтесь, пожалуйста, насчет моих команд-костылей. Да, я за 6 лет "ниасилил" ключи и опции find, а лезть в мануал мне лениво, да и время сейчас не самое подходящее :) Поэтому употребляю то, что просто поможет сейчас *find /etc/|xargs ls -lh|grep 'Mar 31 20:28'.* Видим, что кроме init-скрипта в то же время изменялось и добавлялось расписание cron. Смотрим, что же у нас там в кроне.     less /etc/cron.hourly/cron.sh - #!/bin/sh - PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin - for i in `cat /proc/net/dev|grep :|awk -F: {'print $1'}`; do ifconfig $i up& done - cp /lib/udev/udev /lib/udev/debug - /lib/udev/debug   Ух-ты, как интересно. Вот и причина нашей беды с сетью. Это чудо постоянно передергивает интерфейсы, с периодичностью 3 раза в минуту. ![Расписание вируса linux ddos в crontab](http://storage.yvision.kz/images/user/dr_motor/3LS9v8Pz6IJcMEA6NF8oYULt5qWpYo.png) Посмотрим что нам засунули в */lib/.*     file /lib/udev/udev - /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://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/](http://dd-ip.ru/poleznye-stati/unix-system/posledstviya-ddos-ataki-pri-uyazvimom-bash/) Идем туда и видим, что люди описывают точно такую же картину. Заодно там нам подсказывают как увидеть вирус в списке процессов. > *ps -ej* Действительно, видно. ![Вирус в листинге процессов linux](http://storage.yvision.kz/images/user/dr_motor/qLoEoLneqd49dYfbx17Vv5te8VvEK9.png) Любопытно, чем же это он там занимается. Пустим в ход тяжелую артиллерию. > strace -p 23655 ![Просмотр системных вызовов процесса вируса linux ddos](http://storage.yvision.kz/images/user/dr_motor/p0gOgIE4d7pMelYVL9aIqdjyMeSro9.png) ![Просмотр системных вызовов процесса вируса linux ddos 2](http://storage.yvision.kz/images/user/dr_motor/nV0ylDKG7wlaW2OV8IlWFhnZ7nsHb4.png) ![Просмотр системных вызовов процесса вируса linux ddos 3](http://storage.yvision.kz/images/user/dr_motor/mA1235mKD2QhYyGYw89foHJvi85WR7.png) Ага. Клонирует сам себя и уходит в 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://storage.yvision.kz/images/user/dr_motor/83iX4f6EMNSPgUp2fheu91jan81q9U.png)](http://storage.yvision.kz/images/user/dr_motor/83iX4f6EMNSPgUp2fheu91jan81q9U.png) Как видим, даже любимый хомячками "народный" антивирус Касперского не считает его вредоносным :) Что лишний раз подтверждает: никакой антивирус не гарантирует безопасность и прежде всего нужно учиться пользоваться компьютером, о чем я и писал в [статье](http://inet-use.ru/publ/soft/windows_bez_antivirusa/3-1-0-95). Статья с исследованием этого вируса нашлась и на хабре: [http://habrahabr.ru/post/248933/](http://habrahabr.ru/post/248933/) Как оказалось, этот ботнет может жить где угодно - от винды до смартфонов. В том числе и на различных домашних (и не домашних) роутерах. Если заметите неладное с интернетом, если что-то "тормозит" - вероятно что где то в вашей сети живет ботнет и ваши устройства осуществляют DDOS-атаку под его управлением. Что тут сказать. Пытливые китайские ребята заставляют быть бдительным! Бдите, друзья :) *p.s: Кстати, что то Юви слабенько сегодня шутит, я только под вечер заметил анаграммированные ники :)* --- Source: [https://yvision.kz/post/vyyavlenie-i-lechenie-virusa-na-linux-servere-487270](https://yvision.kz/post/vyyavlenie-i-lechenie-virusa-na-linux-servere-487270)