What can so powerfully generate outbound traffic on a VPS under Ubuntu?

The cases lock container for hosting "suspicious outbound traffic". Reported that up to 42Гбит happens, although not quite understand how this is possible with 100mbps channel. This happens on a workstation running Ubuntu with LEMP; previously, every six months, and now the second time in a month. I once locked, provide the info, but what to do with it - can't figure out, because all IP addresses are familiar to me and understandable, are unable to suspect them. And processes — a common pool of server processes, as I thought (don't go into ICU.administration). Tell me how I can calculate that so generates outbound traffic?

Support strongly hints at malavar, and just throwing links to the simple rathunter. Well ran server, found nothing, changed just in case the root password, set fail2ban.. I do Not know just do not know in what direction to dig.

Those. info when you lock
TX pps - 7142524.46666667: 42611615 Container is stopped.
====================auxfS vzps-E 42611615====================
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
60373 0 0.0 0.0 0 0 ? S Jan12 0:00 [kthreadd/426116]
60374 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [khelper/4261161]
60375 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60376 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60377 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60378 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60379 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60380 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60381 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60382 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60383 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60384 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60385 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60386 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60387 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60388 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60389 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60390 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60391 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60392 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60393 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60394 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60395 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60396 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60397 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60398 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60399 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60400 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60401 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60402 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60403 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60404 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60405 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60406 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60407 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60408 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60409 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60410 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60411 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60412 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60413 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60414 0 0.0 0.0 0 0 ? S Jan12 0:00 \_ [rpciod/42611615]
60415 0 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
60656 0 0.0 0.0 80284 34496 ? Ss Jan12 2:08 \_ /lib/systemd/systemd-journald
0 0.0 0.0 60660 41688 572 ? Ss Jan12 0:00 \_ /lib/systemd/systemd-udevd
60865 0 0.0 0.0 20040 712 ? Ss Jan12 0:00 \_ /lib/systemd/systemd-logind
60866 0 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
60998 0 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
667301 33 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
61039 0 0.0 0.0 8136 177456 ? 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 virtual terminal tty2 Ss+ Jan12 0:00 \_ /sbin/agetty --noclear virtual terminal tty2 linux
61047 0 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
409519 0 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 4488 124612 ? S Jan15 7:24 | \_ nginx: worker process
107 10800 18.8 2.5 9915712 3373896 ? Ssl 07:34 43:50 \_ /usr/sbin/mysqld
April 4th 20 at 13:15
1 answer
April 4th 20 at 13:17
First check the backups. If not, bekapit all.

Then in iptables close all unnecessary ports.

Next, find out from support what IP and ports the traffic is. From the "technical info on lock", nothing is clear. That's 42 GB - also not clear.

Well, prepare a new "known-clean" server, customize everything according to Feng Shui, move backups there. If this is not an error support, the server the malware ie server is compromised and needs to be stopped.
So did, by the way.. it's just frustration more than a solution. The solution I tried to ask support, as you wrote (about the IP and ports):
Response support
You should pay attention to the TX pps - 8168337.59677419 in the notice.

pps is the number of packets per second. On a VPS servers have a limit on outbound traffic to 60k pps, because typically, applications do not generate traffic above this value and this is likely due to the presence of viruses or the parser to the service.

In this case the script monitoring takes the data from the statistics of the interfaces for a certain period, and checks whether more 60kpps per second passes through the interface. If so, you will be sent a notification of suspicious activity, and the service is blocked.

The number of packages is taken from the statistics of the interfaces, but it is impossible to determine exactly which process sent the largest number of packages and on what port.


Last time I was told that there was an attempted brute force ssh and supposedly the server, their answers flood the channel and caught the block. Carefully advised to put fail2ban.
The thought creeps in, and whether any scanner of ports/interfaces to make the server respond with a huge number of packages?

PS: analyze past logs with nginx, occasionally comes across such an entry:
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)"

I have all 400 unwanted response to give, but it seems that someone is sharpening his teeth on my server - sharon.Heidenreich commented on April 4th 20 at 13:20
Last time I was told that there was an attempted brute force ssh and supposedly the server, their answers flood the channel


Well, move SSH to another random port. Some 21729.

And packets on port 22 graphite: iptables -A INPUT-i eth1 -p tcp --dport 22 -j DROP - horacio commented on April 4th 20 at 13:23
+ you can have some fun with Directive TARPIT

+ fail2ban

ban the login password (brutforsery will quickly fall off) - horacio commented on April 4th 20 at 13:26
TX pps - 8168337.59677419

It is 100-megabyte channel? The average packet size is 12 bits?

But let us even assume that the channel is a Gigabit. 120 bit is clearly not TCP, so no SSH. - horacio commented on April 4th 20 at 13:29
@horacio, I've talked to support, this excerpt from the log — not about brute force SSH.
The response of the caliper about brute force
Included VPS, the network is unblocked. Found an anomaly with a large number of connections for ssh


Perhaps you are right with the ports. Thanks for the help :) - sharon.Heidenreich commented on April 4th 20 at 13:32

Find more questions by tags HostingUbuntu