Skip to main content

​
Detecting suspicious network spikes in Linux servers 🚨

Unusual network spikes often come from background activity you don’t expect. Hidden tasks or processes may quietly use your bandwidth, such as:
  • Rogue scripts: hidden or leftover commands constantly transferring data.
  • Crypto miners: unauthorized software using your server’s CPU and network for mining.
  • Misbehaving processes: normal services stuck in loops or retries, flooding the network.
Spotting these early helps you prevent wasted data, slow performance, and unexpected network costs. 📘 Related: Learn the difference between traffic and bandwidth in this EDIS Global guide.

​
1) Monitor live network activity

Start by checking which IPs or processes are using your network. Two lightweight tools are iftop and nload. Before running them, make sure you’re using the correct network interface.
It’s not always eth0 (it can be ens3, ens18, eno1, etc.).
You can find your active interface by running:
Then replace eth0 in the commands below with your interface name:
In iftop, compare source/destination addresses and traffic rates. The -n option keeps addresses numeric so you can match them with ss output. Check whether the busiest connections belong to expected activity; an unfamiliar address alone does not establish abuse.
Illustrative iftop output highlighting the busiest outgoing connection

Reconstructed example with fictional addresses and rates. The 2s, 10s and 40s columns are averaging windows.

If you want a simpler graph view:
Illustrative nload display comparing incoming and outgoing interface traffic

Reconstructed example. Compare incoming and outgoing rates; these totals do not identify a process.

​
2) Identify which process is behind the network usage

Once you spot unusual network activity, use ss (modern) or netstat (optional) to find the process behind the connections.
If you prefer netstat, install net-tools first:
In the example below, the peer 198.51.100.40 from the traffic view appears in a connection owned by PID 28799. The process name is shown as xray-linux-amd6; a process name can be truncated in this view.
Illustrative ss output highlighting a peer address and its owning PID 28799

Reconstructed, wrapped ss output with fictional addresses. Match the remote address, then note the PID.

ss identifies sockets and their processes; it does not measure their live traffic rates. VPN software such as Xray can legitimately open these connections. Use nethogs below to compare rates per process, and check the services you intended to run. See the ss manual.

​
3) Inspect the suspicious process

Now that you’ve identified the suspicious PID from ss or netstat, check what it actually is and where it’s running from.
💡 Replace 28799 with the PID of the process you found suspicious in the previous step. Compare the executable path and arguments with software you installed. A path under /tmp, /dev/shm, or /var/tmp deserves investigation, but its location alone does not prove a compromise.
Illustrative readlink and proc cmdline output for PID 28799

One process, two checks: executable location and launch arguments. This example is not a malware verdict.

​
4) Record evidence, then stop confirmed unwanted activity

A process name, an unfamiliar IP, or a path under /tmp is a reason to investigate, not proof of compromise. First establish what the process does and whether it belongs to software you installed. Record the PID, executable path, command line, start time, connections, and relevant logs before stopping the process. If you need to preserve its executable for analysis, do that while it still exists: /proc/PID/exe may be unavailable after the process exits. Do not execute a suspicious binary. See the Linux /proc/PID/exe reference. If you confirm the activity is unwanted:
  • Stop it through its application or service manager when possible. A supervisor may otherwise restart a killed process.
  • For a standalone process, sudo kill -TERM 28799 requests a normal shutdown. Replace the example PID with the one you have just verified. Check whether it exited before considering a forced stop.
  • Disable only the confirmed unwanted startup entry after preserving a copy for investigation.
Do not delete an Xray installation, cron job, or executable merely because it matches an example in this article. If the server is compromised, stopping one process is containment, not proof that the system is clean.

​
5) Check cron jobs and autostart entries

Many rogue scripts try to restart automatically after reboot using cron or startup files.
Inspect the following locations carefully:
Also check these common paths:
If you find a suspicious entry like this:
or something referencing temporary paths:
verify whether it belongs to an expected service. If it is confirmed unwanted, preserve a copy and remove or disable that specific startup entry. The Xray example can also be a legitimate VPN configuration. 💡 Tip: Legitimate cron jobs usually run system maintenance tasks (like backups or log rotations). Anything starting from /tmp, /dev/shm, or /var/tmp is highly suspicious.

​
6) Use nethogs for per-process network tracking

To continuously monitor which processes use the most network bandwidth:
You’ll see a live list of processes with sent and received rates. This is perfect for spotting anomalies before they grow.
Illustrative NetHogs output highlighting PID 28799 and its sent and received rates

Reconstructed example with fictional rates in KB/sec. A high rate identifies what to investigate, not whether it is malicious.

Compare the PID with the earlier ss output. Note the units: KB/sec is bytes per second, whereas iftop normally shows rates in bits per second. See the NetHogs project.

​
7) Check your overall network usage

If you suspect something has already used too much data, you can review your usage stats directly in your EDIS dashboard.
It shows total monthly usage, daily graphs, and refill times. 📘 Learn how EDIS Global measures network usage and refill cycles here.

​
8) Recover and prevent recurrence

For an application fault, fix its configuration or update it, then monitor whether traffic returns to the expected rate. If you confirm a compromise, preserve the evidence you need, contain the affected service, rotate exposed credentials from a trusted device, and plan a clean rebuild from known-good software and data. A reduced traffic graph does not establish that all unauthorized access has been removed. Review updates, exposed services, and SSH access controls. Firewall rules should target the traffic you actually intend to allow; UFW does not identify a malicious process by name. Changes such as noexec mounts are not a substitute for investigating how the activity began. For cumulative usage, refills, and the shared reserve, see Traffic statistics and Traffic Pool.
Last modified on September 30, 2026