Заражение вирусом DDoS (в качестве службы unix) на виртуальном веб-сервере Debian 8

14

Я поддерживаю (полностью обновленный) Wordpress для студенческой команды на виртуальной машине на сервисе okeanos в течение нескольких лет. Сегодня служба поддержки проинформировала меня о том, что я провожу DDoS-атаки, что, разумеется, не так (к этой службе подключены мои академические полномочия ..). После того, как они приостановили работу машины, и я воспламенил их почтовую систему, я попытался выяснить, что произошло.

Прежде всего, я запускаю, ps -ejчтобы проверить, что работает:

root@snf-25181:~# ps -ej
1545 1545 1545 ? 00:00:00 console-kit-dae
1618 1057 1057 ? 00:00:00 gdm-session-wor
1632 1632 1632 ? 00:01:40 rghuoywvrf
1767 1767 1767 ? 00:00:00 sshd
1769 1769 1769 ? 00:00:00 systemd
1770 1769 1769 ? 00:00:00 (sd-pam)
1775 1767 1767 ? 00:00:00 sshd
1776 1776 1776 pts/0 00:00:00 bash
1849 1849 1776 pts/0 00:00:00 su
1870 1870 1776 pts/0 00:00:00 bash
2246 0 0 ? 00:00:00 kworker/0:0
2797 839 839 ? 00:00:00 apache2
3158 3158 3158 ? 00:00:00 bvxktwwnsb
3162 3162 3162 ? 00:00:00 bvxktwwnsb
3163 3163 3163 ? 00:00:00 bvxktwwnsb
3164 3164 3164 ? 00:00:00 bvxktwwnsb
3165 3165 1776 pts/0 00:00:00 ps

Обратите внимание на bvxktwwnsb и rguoywvrf

Затем я сделал, ps auxчтобы получить услуги (опять же, хвост):

Debian-+  1629  0.0  0.0 178300  4444 ?        Sl   16:53   0:00 /usr/lib/dconf/dconf-service
root      1667  0.0  0.0  30744  4436 ?        Ss   16:53   0:00 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
root      1670  0.0  0.1 299588  9884 ?        Ssl  16:53   0:00 /usr/lib/packagekit/packagekitd
root      1674  0.0  0.1 1055004 6168 ?        Ssl  16:53   0:00 /usr/sbin/console-kit-daemon --no-daemon
www-data  1923  0.0  0.1 240964  8112 ?        S    16:53   0:00 /usr/sbin/apache2 -k start
pankgeo+  5656  0.0  0.0  27416  3424 ?        Ss   17:03   0:00 /lib/systemd/systemd --user
pankgeo+  5657  0.0  0.0 143108  2408 ?        S    17:03   0:00 (sd-pam)   
root      5893  0.0  0.1 102420  6428 ?        Ss   17:04   0:00 sshd: pankgeorg [priv]
pankgeo+  5904  0.1  0.0 102560  4128 ?        S    17:04   0:02 sshd: pankgeorg@pts/0
pankgeo+  5905  0.2  0.1  16816  6388 pts/0    Ss+  17:04   0:04 -bash      
root      7443  0.0  0.1 102420  6496 ?        Ss   17:07   0:00 sshd: pankgeorg [priv]
pankgeo+  7448  0.0  0.0 102552  4160 ?        S    17:07   0:00 sshd: pankgeorg@pts/1
pankgeo+  7449  0.0  0.1  16468  6228 pts/1    Ss+  17:07   0:01 -bash      
root     17351  0.0  0.0      0     0 ?        S    17:15   0:00 [kworker/0:0]
root     18446  0.0  0.0      0     0 ?        S    17:18   0:00 [kworker/0:2]
root     18488  0.1  0.0      0     0 ?        S    17:18   0:01 [kworker/1:1]
root     22680  1.5  0.0      0     0 ?        S    17:28   0:08 [kworker/1:0]
root     24173  0.0  0.1 102420  6416 ?        Ss   17:31   0:00 sshd: pankgeorg [priv]
pankgeo+ 24181  0.3  0.0 102420  3360 ?        S    17:31   0:01 sshd: pankgeorg@pts/2
pankgeo+ 24182  0.0  0.0  16480  6112 pts/2    Ss   17:31   0:00 -bash      
root     25316  2.3  0.0      0     0 ?        S    17:33   0:06 [kworker/1:2]
root     26777  0.0  0.0      0     0 ?        S    17:35   0:00 [kworker/0:1]
root     26778  0.0  0.0      0     0 ?        S    17:35   0:00 [kworker/0:3]
root     27300  0.0  0.0   1424  1040 ?        Ss   17:38   0:00 cat resolv.conf  #note                        
root     27306  0.0  0.0   1424  1036 ?        Ss   17:38   0:00 gnome-terminal   #from                     
root     27307  0.0  0.0   1424  1036 ?        Ss   17:38   0:00 ifconfig eth0    #here                    
root     27308  0.0  0.0   1424  1040 ?        Ss   17:38   0:00 id               #(DDOS?)         
root     27309  0.0  0.0   1424  1040 ?        Ss   17:38   0:00 ifconfig                        
pankgeo+ 27315  0.0  0.0  11136  2044 pts/2    R+   17:38   0:00 ps aux     

Обратите внимание на предметы [-4: -1]. Потом я нашел в Интернете о том, chkconfig --listчто я запускаю это, и это выскочило:

root@snf-25181:/home/pankgeorg# chkconfig --list
acdnfhruvx 0:off 1:off 2:off 3:off 4:off 5:off 6:off
flyymwddwn 0:off 1:off 2:off 3:off 4:off 5:off 6:off

От 1 до 5, onно я повернул их off. Затем я перезапустил и он изменил имя. Тогда я буду locateто acdnfhruvxи это вытянуло:

root@snf-25181:~# locate acdnfhruvx
/etc/init.d/acdnfhruvx
/etc/rc1.d/S01acdnfhruvx
/etc/rc2.d/S01acdnfhruvx
/etc/rc3.d/S01acdnfhruvx
/etc/rc4.d/S01acdnfhruvx
/etc/rc5.d/S01acdnfhruvx

Содержимое одного из них (они все одинаковые): root @ snf-25181: ~ # cat /etc/init.d/acdnfhruvx #! / Bin / sh

chkconfig: 12345 90 90
description: acdnfhruvx
BEGIN INIT INFO
Provides: acdnfhruvx
Required-Start:
Required-Stop:
Default-Start: 1 2 3 4 5
Default-Stop:
Short-Description: acdnfhruvx
END INIT INFO
case $1 in
start)
/bin/acdnfhruvx
;;
stop)
;;
*)
/bin/acdnfhruvx   
;;
esac    

Это было найдено после перезагрузки, поэтому /bin/acdnfhruvxнигде не было. Позже я нашел exes (в формате ELF) в /usr/bin(я думаю, что могу поделиться им, если среди вас есть смелый человек)

Обширный список команд, которые я видел, выполнял машину, не зная источника (из последовательных ps -ejs и ps auxes:

root     27755  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 ifconfig                        
root     27759  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 who                        
root     27760  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 echo "find"                        
root     27761  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 top                        
root     27762  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 id                        
root     27805  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 gnome-terminal                        
root     27809  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 ifconfig                        
root     27810  0.0  0.0   1424  1044 ?        Ss   17:40   0:00 sh                        
root     27811  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 sleep 1                        
root     27822  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 netstat -an                        
root     27826  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 top                        
root     27829  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 bash                        
root     27833  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 cd /etc                        
root     27834  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 whoami                        
root     27822  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 netstat -an                        
root     27826  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 top                        
root     27829  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 bash                        
root     27833  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 cd /etc                        
root     27834  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 whoami                        

pkillОн бессмысленен, поскольку он всегда разветвляется, удаляет файлы /etc/init.d/и /{usr/,}binтакже бессмысленен, поскольку после перезапуска появляется новая (идентичная) версия исполняемого файла. После всей этой информации у меня есть два вопроса: Могу ли я узнать, КАК я заразился? Могу ли я избавиться от этого? Заранее спасибо!

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

Ответы:

24

Мы перенесли подобную инфекцию на Suse, вероятно, через логин ssh brute force .

Шаги для очистки являются:

  1. Проверьте файл /etc/crontab. У вас, вероятно, есть запись для вызова вируса каждые 3 минуты

    */3 * * * * root /etc/cron.hourly/cron.sh
    

    Удалить эту строку.

  2. Определите родительский процесс вируса. В rguoywvrfвашем ps -ej. Другие процессы создаются и убиваются непрерывно.
  3. Останови, не убивай, kill -STOP 1632
  4. Уточните у другого, ps -ejчто живет только родитель, дети должны быстро умирать
  5. Теперь вы можете удалить файлы в /usr/binи /etc/init.d. Существуют варианты вируса, который также использует /bootили /bin. Используйте ls -lt | headдля поиска файлов, которые были недавно изменены.
  6. Проверьте сценарий в /etc/cron.hourly/cron.sh. На нашем сервере он вызывал еще одну копию вируса /lib/libgcc.so. Удалить оба файла.
  7. Теперь вы можете определенно убить rguoywvrfпроцесс.
Serxipc
источник
1
в /etc/rc6.d/ есть несколько плохих сценариев, они начинаются с K90
mazgalici
1
сделать, find / -name "*rguoywvrf*"чтобы найти другие файлы, заменив их rguoywvrfименем, которое вы назвали
Мохамед Хафез
1
Проверьте эту ссылку: garasiku.web.id/web/joomla/index.php/security/…
DarckBlezzer
3

Чтобы ответить на ваши вопросы:

  1. Без необходимых мер предосторожности (вне системного журнала сайта, IDS, мониторинга журнала и т. Д.) Вы, вероятно, никогда не узнаете, что произошло.
  2. Я бы согласился с Мэттом. Вы потратите время на запуск машины, которой никогда не будете доверять. На мой взгляд, лучшее решение - перенести данные с сайта и переделать машину.

Конечно, для чего это стоит, это только мое мнение. Хотя при переделке машины вы, конечно, можете принять необходимые меры предосторожности и в будущем лучше защитить себя.

Имонн Трэверс
источник
1

Это угроза, которая порождает множество проблем, потому что запускает DDOS-атаку и генерирует тысячи соединений с внешними серверами на порту 80, но я не намеренно или нет намеренно перезагружает ваше соединение до тех пор, пока маршрутизаторы / брандмауэры не замерзнут, если их нет. Правила атаки DDOS.

Теперь, как вы можете удалить эту угрозу?

  1. найдите свою угрозу, используйте

Centos / RedHat

ps -ely 

Debian

ps -ej

ты увидишь:

3158 3158 3158 ? 00:00:00 bvxktwwnsb
3162 3162 3162 ? 00:00:00 bvxktwwnsb
3163 3163 3163 ? 00:00:00 bvxktwwnsb
3164 3164 3164 ? 00:00:00 bvxktwwnsb

" bvxktwwnsb" ваша цель

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

    Телинит С

  2. после этого вам нужно удалить файлы, запускаемые при запуске

в Centos / Redhat процедура

Шаг а)

cd /etc/init.d          
ll -tr 

последняя команда упорядочивает ваши файлы в обратном порядке, вы увидите последние 1 или 2 файла в конце с именем like

acdnfhruvx
kmrkuwbrng
gqpjiestmf
bvxktwwnsb

вам нужно увидеть содержимое

cat /etc/init.d/gqpjiestmf

обычно вы увидите выполнение файла, расположенного в / bin или / usr / sbin с тем же именем

вам нужно удалить оба файла.

Шаг б)

cd /etc/
ll -tr 

проверьте, не был ли недавно изменен ваш файл crontab, посмотрите его содержимое, найдите строку

*/3 * * * * root /etc/cron.hourly/udev.sh

или

*/3 * * * * root /etc/cron.hourly/crontab.sh 

вам нужно отредактировать файл и удалить эту строку.

проверьте содержимое udev.shили, crontab.shи вы увидите что-то вроде этого

#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
cp /lib/libgcc4.so /lib/libgcc4.4.so
/lib/libgcc4.4.so

вам нужно удалить файл "libgcc4.4.so" или любой другой из упомянутых там (например, изменение разрешений также будет работать chmod a-x libgcc.so)

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

Для Debian / Ubuntu и родственников используйте:

locate bvxktwwnsb

и удалите файлы, найденные в / etc и / bin

надеюсь, это поможет многим людям.

Хорхе Аренас
источник
Ваш ответ может быть трудно прочитать, потому что он не выглядит правильно отформатированным. Если вам нужна помощь, в справочном центре можно получить дополнительную информацию о правильном форматировании сообщений.
bwDraco
0

Я нашел что-то !!!

ищите / etc / crontab

На моем сервере каждые 3 минуты есть cronjob для выполнения чего-либо:

*/3 * * * * root /etc/cron.hourly/cron.sh

cat 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/libgcc.so /lib/libgcc.so.bak
/lib/libgcc.so.bak

Мое решение:

  1. отключить разрешение (rwx 000) для: /etc/init.d/ {/ usr} / bin / /lib/libgcc.so
  2. удалить запись cronjob в / etc / crontab
  3. удалить скрипт cron в /etc/cron.hourly/cron.sh
  4. перезагрузите сервер

примечание: расположение файлов может отличаться

Энди Бобинский
источник
0

Дополнительный трюк, дополняющий решение Сергея. Остановка всех процессов может быть затруднена, так как эта вещь спамит сеть и процессор. Поэтому добавьте эту строку к вашей, /etc/crontabчтобы автоматически ОСТАНОВИТЬ все неприятные процессы (останавливает все процессы с 10 символами в имени каждые три минуты):

*/3 * * * * root pstree -ap | grep -E -- '-[a-z]{10},' | cut -d, -f2 | xargs kill -STOP 2>/dev/null

Это хорошо сделать после очистки, чтобы убедиться, что процесс не возвращается. Запустите его на некоторое время, пока не убедитесь, что ваша коробка чистая.

lzap
источник