Заражение вирусом 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также бессмысленен, поскольку после перезапуска появляется новая (идентичная) версия исполняемого файла. После всей этой информации у меня есть два вопроса: Могу ли я узнать, КАК я заразился? Могу ли я избавиться от этого? Заранее спасибо!


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

Ответы:


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процесс.

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.