Find and Stop Abusive VPS on a Host Node: Outbound Attacks, Spam and Port Scans on KVM and Proxmox

On a host node, one customer's VPS can put the whole business at risk. A VPS that scans the internet, sends spam or takes part in DDoS attacks generates abuse complaints, gets your IPs listed on blacklists such as Spamhaus, and can lead to the entire IP block being filtered. This guide shows how to find the responsible VPS quickly on a KVM host (Proxmox VE or any Linux bridge setup), recognise the type of abuse, stop it without affecting other customers, and prevent the most common cases.

Typical Signs

• An abuse report from your provider or a blacklist operator naming one or more of your IPs.
• Outbound traffic or packets per second on the host far above normal, especially many small packets.
• The host's conntrack table filling up, or the host becoming slow without any VPS using much CPU.
• Mail from your IPs being rejected, or your IPs appearing on RBL lists (see IP blacklist checks).

Step 1: Find Which VPS Is Sending the Traffic

Each KVM VPS has its own tap interface on the host (in Proxmox VE tap101i0 for VM 101). On a tap interface the counters are seen from the host, so rx is what the VPS sends out and tx is what it receives.

# Packets and bytes each VPS sent in the last 10 seconds (rx on the tap = outbound from the VPS)
for t in /sys/class/net/tap*; do n=$(basename $t); echo "$n $(cat $t/statistics/rx_packets) $(cat $t/statistics/rx_bytes)"; done > /tmp/a
sleep 10
for t in /sys/class/net/tap*; do n=$(basename $t); echo "$n $(cat $t/statistics/rx_packets) $(cat $t/statistics/rx_bytes)"; done > /tmp/b
join /tmp/a /tmp/b | awk '{printf "%-12s %8d pps %8.1f Mbps\n", $1, ($4-$2)/10, ($5-$3)*8/10/1000000}' | sort -k2 -nr | head

# Live view of who talks to whom on the bridge
iftop -i vmbr0 -nNP

A VPS sending tens of thousands of packets per second with modest Mbps is usually flooding or scanning; a steady stream of connections to port 25 is usually spam.

Step 2: Identify the Type of Abuse

# Sample the traffic of one VPS (replace tap101i0)
tcpdump -ni tap101i0 -c 300 -w /root/evidence-vps101-$(date +%F-%H%M).pcap
tcpdump -nr /root/evidence-vps101-*.pcap | head -50

# Outgoing SMTP connections (spam)
tcpdump -ni tap101i0 'tcp dst port 25 and tcp[tcpflags] & tcp-syn != 0' -c 50

# Connections tracked for the VPS's IP (apt install conntrack)
conntrack -L -s 203.0.113.11 2>/dev/null | wc -l
conntrack -L -s 203.0.113.11 2>/dev/null | awk '{print $5}' | sort | uniq -c | sort -nr | head

Step 3: Stop the Abuse

Choose the mildest action that stops the problem, and escalate if it continues.

# Throttle the VPS immediately to about 8 Mbps (rate is in MB/s; keep the NIC's MAC from "qm config")
qm set 101 --net0 virtio=BC:24:11:AA:BB:CC,bridge=vmbr0,firewall=1,rate=1

# Block outbound SMTP for this VPS with the Proxmox firewall
cat >> /etc/pve/firewall/101.fw <<'EOF2'

[RULES]
OUT DROP -p tcp -dport 25 -log nolog
EOF2

# Pause the VPS (keeps memory state for investigation) or shut it down
qm suspend 101
qm shutdown 101

If the [RULES] section already exists in the file, add the rule there instead of appending a second section. Then tell the customer what you saw, with the evidence, and what they need to fix; a compromised VPS usually needs a reinstall and new passwords (see finding and removing malware on Linux).

Step 4: Answer the Abuse Report

Reply to the report promptly with the affected IP, the time you identified the source, the action taken (rate limited, port 25 blocked, VPS suspended) and that the customer has been contacted. Fast, clear replies are what keeps an IP block in good standing with upstream networks and blacklist operators.

Step 5: Prevent the Common Cases

• Block outbound port 25 by default for new VPS with a Proxmox security group, and open it only for customers who request it and whose mail setup you trust.
• Enable IP filtering so a VPS can only use its own addresses (see selling VPS from a Proxmox host node).
• Set sensible bandwidth and packet limits per plan, so one VPS cannot saturate the uplink.
• Monitor continuously: collect per-VPS traffic with vnStat on the tap interfaces or a tool such as Netdata, and alert on unusual packet rates.
• Know your customers: verify new sign-ups and watch for high-risk orders; most abuse comes from a small number of accounts.

# Datacenter-wide security group in /etc/pve/firewall/cluster.fw
[group no-smtp]
OUT DROP -p tcp -dport 25 -log nolog

# Use it in each VPS file, e.g. /etc/pve/firewall/101.fw
[RULES]
GROUP no-smtp

FAQ

The VPS is not using much bandwidth, but I still received a report

Scanning and brute-force attempts use very little bandwidth. Look at packet rates and connection counts (Step 1 and Step 2), not only Mbps.

How do I find the VPS if I only have an IP from the report?

Search your panel or the VM configurations: grep -r 203.0.113.11 /etc/pve/qemu-server/ /etc/pve/firewall/ shows which VM uses that IP.

What happens if abuse is not dealt with?

Repeated or unanswered abuse gets IPs blacklisted and can force your upstream provider to filter the affected addresses to protect its network. Acting quickly with the steps above and replying to the report with what you did keeps the impact limited to the VPS involved.

Still stuck after following these steps? Open a support ticket and the IMIDC 24/7 technical team will help. Include the host server IP, the affected IP addresses, the abuse report reference and the output of the commands above so we can pinpoint the issue faster.