Abuse Notice: Your Server Is Attacking Other Hosts

Almost every abuse report we forward is the result of something the customer never intended. A server gets compromised through a weak SSH password, an outdated web application or an unauthenticated service left listening on a public port — and from that moment it is quietly working for someone else: scanning the internet, hammering other people's login pages, or joining a botnet. The traffic is real, it comes from your IP address, and the receiving networks report it to us.

None of that means you did anything wrong on purpose. It does mean the server needs to be cleaned before it can go back online. Work through the steps below in order — they are written so you can follow them even when SSH is already blocked.

What happens now

Handling depends on how severe the traffic is. Low-volume scanning usually gets a warning and a deadline; a live flood or a mail-spam source is null-routed or suspended immediately, because leaving it online risks the IP ranges every other customer shares.

Before you start

• Your client area login, and the root password for the VPS.
• Access to the VNC Console under Services → your VPS → Manage. Use it if SSH no longer answers.
• A note of what the server is supposed to run — you cannot spot a rogue process without knowing the normal ones.
• Somewhere to save evidence: process names, PIDs, file paths, log excerpts. You will need them for the ticket.

1Get in, and take a snapshot of the evidence

Log in over SSH if it still works, otherwise open the VNC console from your client area. Before you change anything, capture what the machine looks like right now — the moment you start killing processes, you lose the ability to prove what happened.

mkdir -p /root/abuse-evidence && cd /root/abuse-evidence

ps auxf                    > processes.txt
ss -tunap                  > sockets.txt
crontab -l                 > cron-root.txt 2>/dev/null
ls -la /tmp /var/tmp /dev/shm > tmp-dirs.txt
last -20                   > logins.txt
uptime; date

2Find the process that is sending the traffic

Attack tools rarely announce themselves. Look for a process burning CPU, holding hundreds of outbound connections, or running from a directory no legitimate service uses. ss is the fastest way in: a machine making thousands of short-lived connections to port 22 or 3389 across the internet is brute-forcing, full stop.

# Top CPU consumers
ps aux --sort=-%cpu | head -15

# Which processes hold outbound connections, and how many
ss -tnp state established | awk '{print $NF}' | sort | uniq -c | sort -rn | head

# Where does a suspicious PID actually live on disk?
ls -l /proc/<PID>/exe
cat /proc/<PID>/cmdline | tr '\0' ' '; echo
ls -l /proc/<PID>/cwd

# Live view of outbound flows (install if missing)
iftop -nNP    # or: nethogs

3Check the usual hiding places

World-writable directories are where dropped payloads land, because any compromised web process can write there. Persistence — the mechanism that brings the malware back after a reboot — almost always lives in cron, a systemd unit, or an SSH key that isn't yours.

# Dropped files, including hidden ones
ls -la /tmp /var/tmp /dev/shm
find /tmp /var/tmp /dev/shm -type f -executable 2>/dev/null

# Anything written in the last 3 days outside the usual places
find / -xdev -mtime -3 -type f \
     -not -path '/proc/*' -not -path '/sys/*' -not -path '/var/log/*' 2>/dev/null | head -50

# Scheduled jobs — check every user, not just root
crontab -l
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null; done
cat /etc/crontab; ls -la /etc/cron.*
systemctl list-timers --all

# Unexpected services and login keys
systemctl list-unit-files --state=enabled | grep -v '@'
cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys 2>/dev/null

# Accounts that can log in, and anyone with UID 0
awk -F: '$3==0 {print $1}' /etc/passwd
grep -vE '/(nologin|false)$' /etc/passwd

4Read the logs to find how they got in

This is the step people skip, and it is the one that stops the problem repeating. Cleaning the malware without finding the entry point means you will be back here in a fortnight. The two usual doors are SSH (a successful login you did not make) and a web application (a POST to a file that should not exist).

# Successful SSH logins — Debian/Ubuntu, then RHEL family
grep 'Accepted' /var/log/auth.log
grep 'Accepted' /var/log/secure

# Volume of failed attempts tells you if you were brute-forced
grep -c 'Failed password' /var/log/auth.log

# Web application entry points
tail -200 /var/log/nginx/error.log
tail -200 /var/log/apache2/error.log
grep -iE 'wget|curl|base64|eval\(|/tmp/' /var/log/nginx/access.log | tail -50

# Everything the system logged around the time of the report
journalctl --since '3 days ago' --no-pager | less

5Scan for malware and rootkits

Scanners catch the common, well-known payloads — which is most of them. Run them, but treat a clean result as weak evidence rather than proof: a kernel-level rootkit can hide from tools running on the same machine.

# ClamAV — Debian/Ubuntu
apt update && apt install -y clamav
freshclam
clamscan -ri --exclude-dir='^/(proc|sys|dev)' /

# Rootkit checks
apt install -y rkhunter chkrootkit
rkhunter --update && rkhunter --checkall --skip-keypress
chkrootkit

# Verify system binaries still match the packages that own them
debsums -c            # Debian/Ubuntu
rpm -Va | grep '^..5' # RHEL family

6Stop the traffic right now

Once you know what is running, cut it off. Kill the process, remove its persistence, then close the door behind it: rotate every credential the attacker could have read, and remove any SSH key you do not recognise. Changing the root password alone is not enough if a key is still authorised.

# Note the binary path BEFORE killing, then stop it
ls -l /proc/<PID>/exe
kill -9 <PID>

# Remove the persistence you found in step 3
crontab -e                       # delete the rogue line
systemctl disable --now <unit>   # and rm its unit file

# Rotate everything the attacker could read
passwd root
# ...and every database, application and API credential on the box

# Remove SSH keys you did not add
vi /root/.ssh/authorized_keys

# Default-deny inbound, keep only what you need
ufw default deny incoming
ufw allow OpenSSH
ufw enable

7The reliable fix: reinstall and restore clean

A rebuild takes minutes and removes all doubt. In your client area open Services → your VPS → Manage, choose Reinstall, pick your operating system and set a new, strong root password. The disk is wiped and you get a clean system on the same IP address.

Restoring is where people re-infect themselves. Bring back data — database dumps, uploaded media, configuration you wrote yourself — and reinstall applications from their official sources. Never restore a whole-disk image taken after the compromise, and never restore cron files, system binaries or a full /home without reading what is in it. If your only backup is from after the incident, treat every executable and every PHP file in it as suspect.

8Reply to us so we can restore the service

We reactivate on evidence, not on assurances. A reply that answers these four questions is normally processed within a few hours; “it's fixed now” on its own is not, because we have to pass something concrete back to the network that reported you.

• What was running? The process name and the path from /proc/<PID>/exe, or the scanner output.
• How did it get in? Brute-forced SSH, an outdated application, a leaked key — your best supported guess.
• What did you do? Cleaned and hardened, or reinstalled. Be specific.
• What stops it recurring? Key-only SSH, firewall rules, updates applied, credentials rotated.

Reply in the existing abuse ticket rather than opening a new one — it keeps the history in one place and gets to the right person immediately.

Who is responsible for what

Our standard VPS plans are unmanaged. We are responsible for the hardware, the network, the hypervisor and the tools in your client area — console, reinstall, reboot, backups. Everything from the operating system upward is yours: updates, application security, firewall rules, passwords and keys, and anything your users or your code do.

That line is also why abuse reports come to you rather than being fixed for you: we have no access to the inside of your server, by design. If you would rather not own that layer, our managed plans cover patching, hardening and incident response — and on a managed plan an abuse report is our job to resolve, not yours.

Harden the server so this does not happen again

Repeat reports and deliberate abuse

An isolated compromise, handled properly, has no lasting consequence for your account. Repeated substantiated reports on the same service do, and can end in termination — at that point the pattern is a security problem we cannot keep absorbing on shared IP space. Traffic that was clearly generated on purpose — running scanners, stress-test or “booter” services, credential-stuffing tooling — is a different matter entirely and is dealt with on the first report, under our Terms of Service.

Frequently asked questions