Что может так мощно генерировать исходящий трафик на VPS под Ubuntu?

Question

[Александр]

Участились случаи блокировки контейнера хостингом за "подозрительный исходящий трафик". Сообщают, что вплоть до 42Гбит бывает, хотя не совсем понимаю, как такое возможно при канале 100mbps. Случается такое на рабочей машине под Ubuntu с LEMP; раньше раз в полгода, а сейчас второй раз за месяц. Мне после блокировки предоставляют инфу, но что с ней делать - не могу сообразить, ведь все IP адреса мне знакомы и понятны, не могу подозревать их. А процессы — обычный пул процессов на сервере, как мне показалось (не углубляюсь в сис.администрирование). Подскажите, как можно вычислить, что так генерирует исходящий трафик?

Поддержка всячески намекает на маловарь, и лишь кидает ссылки на простецкие рутхантеры. Ну пробежал по серверу, ничего не нашёл, сменил на всякий случай root-пароль, поставил fail2ban.. Не знаю, просто не понимаю, в какую сторону копать.

Тех. инфо при блокировке

TX pps - 7142524.46666667: Container 42611615 is stopped.
====================vzps auxfS -E 42611615====================
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
0 60373 0.0 0.0 0 0 ? S Jan12 0:00 [kthreadd/426116]
0 60374 0.0 0.0 0 0 ? S Jan12 0:00 \_ [khelper/4261161]
0 60375 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60376 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60377 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60378 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60379 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60380 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60381 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60382 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60383 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60384 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60385 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60386 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60387 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60388 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60389 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60390 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60391 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60392 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60393 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60394 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60395 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60396 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60397 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60398 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60399 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60400 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60401 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60402 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60403 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60404 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60405 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60406 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60407 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60408 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60409 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60410 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60411 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60412 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60413 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60414 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
0 60415 0.0 0.0 0 0 ? S Jan12 0:00 \_ [nfsiod/42611615]
0 60370 22.5 0.0 188992 2824 ? Ss Jan12 2839:10 init -z
0 60656 0.0 0.0 80284 34496 ? Ss Jan12 2:08 \_ /lib/systemd/systemd-journald
0 60660 0.0 0.0 41688 572 ? Ss Jan12 0:00 \_ /lib/systemd/systemd-udevd
0 60865 0.0 0.0 20040 712 ? Ss Jan12 0:00 \_ /lib/systemd/systemd-logind
0 60866 0.6 0.0 30172 512 ? Ss Jan12 80:56 \_ /usr/sbin/cron -f
104 60871 0.0 0.0 262476 1964 ? Ssl Jan12 0:46 \_ /usr/sbin/rsyslogd -n
108 60882 0.0 0.0 42832 844 ? Ss Jan12 0:00 \_ /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
0 60995 0.1 0.0 65456 944 ? Ss Jan12 14:11 \_ /usr/sbin/sshd -D
0 60998 48.3 0.0 459532 15960 ? Ss Jan12 6093:11 \_ /usr/sbin/apache2 -k start
33 597427 9.7 0.0 552864 46568 ? S 11:14 1:11 | \_ /usr/sbin/apache2 -k start
33 620541 8.9 0.0 552860 42828 ? R 11:15 1:00 | \_ /usr/sbin/apache2 -k start
33 658785 9.6 0.0 552100 41964 ? S 11:20 0:35 | \_ /usr/sbin/apache2 -k start
33 660615 10.5 0.0 548912 40180 ? S 11:21 0:36 | \_ /usr/sbin/apache2 -k start
33 664636 9.4 0.0 470400 34704 ? S 11:22 0:25 | \_ /usr/sbin/apache2 -k start
33 667003 12.6 0.0 475280 41520 ? S 11:23 0:29 | \_ /usr/sbin/apache2 -k start
33 667301 7.2 0.0 553100 42764 ? R 11:23 0:16 | \_ /usr/sbin/apache2 -k start
33 668225 7.8 0.0 473580 39080 ? S 11:23 0:15 | \_ /usr/sbin/apache2 -k start
33 695808 10.3 0.0 470520 33504 ? S 11:26 0:06 | \_ /usr/sbin/apache2 -k start
33 698178 7.2 0.0 469652 31128 ? S 11:26 0:01 | \_ /usr/sbin/apache2 -k start
0 61039 0.0 0.0 177456 8136 ? Ssl Jan12 0:00 \_ /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal
0 61045 0.0 0.0 12780 148 tty2 Ss+ Jan12 0:00 \_ /sbin/agetty --noclear tty2 linux
0 61047 0.0 0.0 16912 144 tty1 Ss+ Jan12 0:00 \_ /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt220
33 61083 0.0 0.0 19632 308 ? Ss Jan12 0:11 \_ /usr/bin/htcacheclean -d 120 -p /var/cache/apache2/mod_cache_disk -l 300M -n
33 637072 1.7 0.0 252780 26892 ? Sl Jan12 218:50 \_ amplify-agent
0 409075 3.7 0.0 338944 56572 ? Sl Jan12 463:35 \_ /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b
0 409519 0.0 0.0 123368 1960 ? S Jan15 0:00 \_ nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
33 409521 0.0 0.0 124904 4800 ? S Jan15 7:10 | \_ nginx: worker process
33 409522 0.0 0.0 124548 4420 ? S Jan15 6:50 | \_ nginx: worker process
33 409523 0.0 0.0 124552 4548 ? S Jan15 6:50 | \_ nginx: worker process
33 409524 0.0 0.0 124612 4488 ? S Jan15 7:24 | \_ nginx: worker process
107 10800 18.8 2.5 9915712 3373896 ? Ssl 07:34 43:50 \_ /usr/sbin/mysqld

Answer 1

[tester12]

Для начала проверьте бэкапы. Если их нет, бэкапьте всё.

Потом закройте в iptables все ненужные порты.

Далее выясните у техподдержки, на какие IP и порты идёт трафик. Из "тех. инфо при блокировке" ничего не понятно. Что за 42 Гбит - тоже не понятно.

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

Comments

[Александр]

Так и сделал, кстати.. Но это похоже на безысходность больше, чем на решение. Решение я пытался узнать у поддержки, как вы и писали (про IP и порты):

Ответ поддержки

Стоит обратить внимание на TX pps - 8168337.59677419 в уведомлении.

pps - это количество пакетов в секунду. На VPS-серверах установлено ограничение на исходящий трафик в 60k pps, т.к. как правило приложения не генерируют трафик выше этого значения и это скорее всего связано с наличие вирусов или парсеров на услуге.

В данном случае скрипт мониторинга берет данные из статистики интерфейсов за определенный промежуток и проверяет, не больше ли 60kpps в секунду проходит по интерфейсу. Если так, то вам отправляется уведомление о наличии подозрительной активности, а услуга блокируется.

Значение количества пакетов берется из статистики интерфейсов, но по ним нельзя определить какой именно процесс отправил наибольшие количество пакетов и по какому порту.

В прошлый раз мне сказали, что была попытка брутфорса ssh и, якобы, сервер своими ответами зафлудил канал и словил блок. Бережно посоветовали поставить fail2ban.
Закрадывается мысль, а может ли любой сканер портов/интерфейсов заставить отвечать сервер огромным количеством пакетов?

PS: анализировал мимо логи nginx, изредка попадается такая запись:

173.249.51.194 - - [21/Jan/2020:05:09:24 +0000] "GET / HTTP/1.0" 400 182 "-" "masscan/1.0 (https://github.com/robertdavidgraham/masscan)"

Я всем неугодным 400 ответ даю, но кажется, что кто-то точит зуб на мой сервер

[tester12]

В прошлый раз мне сказали, что была попытка брутфорса ssh и, якобы, сервер своими ответами зафлудил канал

Ну, перенесите SSH на другой, случайный порт. Какой-нибудь 21729.

А пакеты на порт 22 дропайте: iptables -A INPUT -i eth1 -p tcp --dport 22 -j DROP

[tester12]

+ можно позабавиться директивой TARPIT

+ fail2ban

+ запрет логина по паролю (брутфорсеры быстро отвалятся)

[tester12]

TX pps - 8168337.59677419

Это на 100-мегабитном канале? Средний размер пакета 12 бит?

Но допустим даже, что канал гигабитный. 120 бит - это явно не TCP, а значит не SSH.

[Александр]

tester12, Я трижды общался с поддержкой, данная выдержка из лога — не про брутфорс SSH.

Ответ суппорта про брутфорс

Включили VPS, сеть разблокировали. Обнаружили аномалию с большим количеством подключений для ssh

Пожалуй, вы правы с портами. Спасибо за помощь :)