Возникла беда с сервером. Жалуются, мол, то доступен, то недоступен. Ок, смотрим - действительно, так и есть. Картина стандартная, похоже на конкуренцию за 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
Набирается чуть более сотни стабильных соединений.
Тщательно изучаем список, и ничего не находим. Оно и логично, мы ведь изолировали сервер от глобальной сети.
По сетевым надо смотреть непосредственно в момент, когда наблюдается проблема. Но у нас такой возможности нет, поскольку для этого нужно ногами идти к серверу и глазами смотреть в его монитор (консоль). У нас есть только изолированный сервер и ssh-доступ через цепочку хостов резервного канала.
Смотрим процессы. Но ps -fe тоже не показывает ничего подозрительного.
Ладно. Надо искать в etc. Святая святых, так сказать.
Недолго думая, просто вываливаю find /etc/ в консоль и просматриваю длиннющий список в 2k строчек. Поскольку все эти файлы мы видели тысячи раз, незнакомое непотребство надеюсь обнаружить легко. Так и выходит:
Подозрения подкрепляются уверенностью: скомпрометирован!
Ну-ка, ну-ка, с этого момента поподробней. Выдача гугла по запросу "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:
Не смейтесь, пожалуйста, насчет моих команд-костылей. Да, я за 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 раза в минуту.
Посмотрим что нам засунули в /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://dd-ip.ru/poleznye-stati/unix-system/posledstviya-ddos-ataki-pri-uyazvimom-bash/
Идем туда и видим, что люди описывают точно такую же картину. Заодно там нам подсказывают как увидеть вирус в списке процессов.
ps -ej
Действительно, видно.
Любопытно, чем же это он там занимается.
Пустим в ход тяжелую артиллерию.
strace -p 23655
Ага. Клонирует сам себя и уходит в 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 ему имя. От появления проблемы до полного устранения ушло примерно полдня.
Как видим, даже любимый хомячками "народный" антивирус Касперского не считает его вредоносным :) Что лишний раз подтверждает: никакой антивирус не гарантирует безопасность и прежде всего нужно учиться пользоваться компьютером, о чем я и писал в статье.
Статья с исследованием этого вируса нашлась и на хабре: http://habrahabr.ru/post/248933/
Как оказалось, этот ботнет может жить где угодно - от винды до смартфонов. В том числе и на различных домашних (и не домашних) роутерах. Если заметите неладное с интернетом, если что-то "тормозит" - вероятно что где то в вашей сети живет ботнет и ваши устройства осуществляют DDOS-атаку под его управлением.
Что тут сказать. Пытливые китайские ребята заставляют быть бдительным! Бдите, друзья :)
p.s: Кстати, что то Юви слабенько сегодня шутит, я только под вечер заметил анаграммированные ники :)