Зараження вірусом DDoS (як послуга unix) на веб-сервері Debian 8 VM

Я підтримую (повністю оновлений) Wordpress для студентської команди на сервісі Virtual Machine on ~ okeanos протягом декількох років. Сьогодні служба технічної допомоги повідомила мене про те, що я здійснюю DDoS-атаки, що, звичайно, я не є (ця служба пов'язана з моїми академічними даними ..). Після того, як вони зупинили машину, і я розпалив їх поштову систему, я спробував з’ясувати, що сталося.

Перш за все, я запускаю a, 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                        

pkilling є безглуздим, оскільки він завжди розщедрить, видаляє файли з, /etc/init.d/а /{usr/,}binтакож безглуздо, оскільки після перезапуску з'являється нова (однакова) версія виконуваного файлу. Після всієї цієї інформації у мене є два питання: Чи можу я дізнатися, ЯК Я заразився? Чи можу я позбутися цього? Заздалегідь спасибі!

Ми страждали подібною інфекцією на Suse, ймовірно, через sh 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. Без необхідних запобіжних заходів (поза syslog сайту, IDS, моніторинг журналу тощо) ви, ймовірно, ніколи не дізнаєтесь, що сталося.
2. Я мав би погодитися з Меттом. Ви вкладете час, щоб запустити машину, якій ви ніколи не будете довіряти. На мою думку, найкращим рішенням є переміщення даних із сайту та повторна переробка машини.

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

це загроза, яка створює безліч проблем, оскільки запускаємо 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" - ваша мета

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

   telinit S

3. після цього потрібно видалити файли, запущені при запуску

в 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

сподіваюся, що це допоможе багатьом людям.

Я щось знайшов !!!

шукати / etc / crontab

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

*/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. перезавантажте сервер

Примітка: розташування файлів може відрізнятися

Додатковий трюк, що доповнює рішення Сергія. Зупинення всіх процесів може бути важким, оскільки ця річ спамує мережу та процесор. Тому додайте цей рядок у свій, /etc/crontabщоб автоматично зупиняти всі неприємні процеси (зупиняє всі процеси з іменем 10 символів кожні три хвилини):

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

Це добре робити після очищення, щоб переконатися, що процес не повернеться. Запускайте його деякий час, поки ви не переконаєтесь, що ваш ящик чистий.