An abuse notice is usually the first evidence that you are running part of a Linux DDoS botnet. It arrives from the upstream provider, it cites a timestamp and a destination IP you have never heard of, and it gives you a window (often 24 hours) to respond before the port is shut or the prefix null-routed. By then the box has been attacking somebody else for days.
Most writing on this subject is written from the malware analyst’s chair: a family name, a hash, a list of command-and-control (C2) strings. Useful for detection engineering, less useful at two in the morning when you have to decide whether to reboot the machine. What follows is written from the defender’s side, and it runs in both directions: how Linux hosts get recruited, how to tell whether one of yours already has been, and what that same class of botnet looks like when it is aimed at your own services.
How Linux hosts end up in a DDoS botnet
Recruitment is boring, which is precisely why it works. Four routes account for the overwhelming majority of compromises that end in an abuse notice.
The four routes that dominate
- Credential brute force against exposed SSH. Port 22 open to the world with password authentication still enabled, usually on a box nobody remembers building.
- Unauthenticated services bound to public interfaces. The Docker remote API listening on 0.0.0.0:2375 gives an attacker container creation with host mounts; Redis on 6379 without a password has been used for years to write authorised keys and cron entries.
- Remote code execution in management consoles. A Jenkins script console reachable from the internet is arbitrary Groovy execution as the Jenkins user, and that is before you count unpatched CI, monitoring and admin panels.
- Unpatched consumer and edge firmware. Routers, DVRs, cameras and small-business gateways running old Linux builds, with web interfaces that were never meant to face the public side.
Note what is missing from that list: clever exploits. Almost none of this requires a zero-day.
Why ‘IoT botnet’ and ‘Linux server botnet’ are often the same thing
When the Mirai source code was published openly in late 2016, it did not just give the world one botnet. It gave the world a build system. Mirai-derived loaders cross-compile the same payload for x86_64, ARM, MIPS, PowerPC and a tail of older embedded architectures, and the loader simply tries each binary until one runs. Families documented since, written in Go and in Lua rather than C, have kept the identical recruitment model and swapped the language. The practical consequence for an operator is that a fleet of Ubuntu VMs and a shelf of forgotten branch routers sit in the same target pool, scanned by the same scripts.
Node count tells you very little about attack size
Headlines count bots. Networks feel bandwidth. A domestic router in a congested estate might contribute a few megabits of usable uplink; a hijacked cloud instance in a tier-one data centre contributes gigabit-class egress and does not drop off when somebody unplugs the telly. A few thousand compromised VPS nodes can out-shoot a few hundred thousand home devices, which is why comparing botnets by population is close to meaningless now. Judge capacity, not headcount.
Mining first, DDoS on top
Recent Linux families stack their revenue. Crypto-mining provides a baseline income from every box, and DDoS capacity is rented out on top, which is where the market for a botnet for hire comes in: time-boxed attack access, sold by the hour, aimed at whoever has paid. The mining gives operators a reason to keep infections quiet and long-lived rather than burning them in a single attack. It also gives defenders a useful tell, because sustained CPU at odd hours is easier to spot than occasional packet floods.
Signs your Linux server has been conscripted
None of these is conclusive alone. Two or three together, and you should be treating the host as compromised rather than suspicious.
Traffic that does not match the workload
A database replica that suddenly talks to four hundred unrelated destinations is not doing database work. Look for sustained egress with no business explanation, raw socket use by processes that have no reason for it, and reports from the upstream that spoofed-source packets from your range are being dropped at their edge. Metered bandwidth bills are an underrated detector; finance noticing an overage has caught more than one botnet node.
Persistence in the usual places
Modern Linux bots do not rely on a single foothold. Expect unfamiliar systemd units, cron entries belonging to service accounts, modified init or rc scripts, binaries executing from /tmp or /dev/shm, and process names chosen to mimic kernel threads so they blend into ps output. Anything in square brackets that is not actually a kernel thread deserves a second look.
Command-and-control fingerprints
A long-lived connection to a single foreign IP on an odd high port, re-established within seconds of being killed, is the classic pattern. Plaintext control traffic is still common in Mirai derivatives, and hard-coded lookups to disposable domains show up clearly in resolver logs if you keep them.
Clues that arrive from outside
Abuse notices, sudden null-routing, your ranges appearing on blocklists, or a hosting customer complaining that their mail is bouncing. These are the slowest signals and the ones most organisations actually act on.
Confirming the infection without destroying the evidence
The instinct is to reboot. Resist it. Memory-resident loaders and deleted-but-running binaries frequently exist in exactly one place, and a reboot is how that copy stops existing.
Snapshot the volume first. Capture a few minutes of packet trace at the hypervisor or switch rather than on the host itself. Then work through the host in a defined order: established sessions and listening sockets with ss, process-to-binary mapping via /proc/[pid]/exe (which survives the binary being unlinked from disk), package verification against the distribution’s own database with rpm -V or debsums, and a diff against a known-good image if you hold one. Keep notes and timestamps as you go, because they may matter later to an insurer or to law enforcement.
Rebuild, do not clean
Here is the mistake that costs teams a week: killing the process, deleting the binary, declaring it fixed. Layered persistence means the payload is re-pulled within minutes by a cron entry nobody looked at, and the second failure usually happens out of hours. Rebuilding from a trusted image with rotated SSH keys, rotated service credentials and rotated API tokens is almost always faster than a cleanup that fails twice, and it is the only approach that resolves the question of what else the operator did while they had root.
Who to tell, and in what order
Upstream provider or colocation facility first, with the timestamps you have; they are the ones holding the null route. Your own abuse contact next, so inbound complaints land somewhere staffed. UK organisations should note that offences under the Computer Misuse Act 1990 cover unauthorised access and unauthorised acts impairing the operation of a computer, which is the frame under which booter and stresser operators have been prosecuted. Being an unwitting host is a very different position from operating the thing, and prompt, documented cooperation is what demonstrates the difference. The NCSC’s denial of service guidance sets out reporting expectations for organisations whose infrastructure is implicated.
What a Linux DDoS botnet does to a target across three surfaces
Assess your own exposure across three surfaces, not one. Teams that buy protection for a single surface tend to discover the gap during the incident.
Network and transport
SYN and ACK floods, UDP floods and TCP connection exhaustion. The failure mode is often not a full pipe but a full state table: firewalls, load balancers and intrusion-prevention appliances run out of connection slots long before the circuit saturates, which is why a 2Gbps attack sometimes takes down a 10Gbps site.
Application layer
HTTP request floods aimed at search, login, filter and basket endpoints: the pages that cost the most server work per request. Linux bots are well suited to this because generating valid HTTPS requests is cheap and the traffic looks like users. Volume is low. Damage is high.
Authoritative DNS, the layer nobody owns
Authoritative DNS is the surface most often left unmanaged, usually because it was configured once by someone who has since left. A botnet of modest size pointed at your name servers can make the brand unreachable while the web tier sits idle and perfectly healthy, and the monitoring dashboard stays green throughout. Ask who holds that contract before you need the answer. Reflection and amplification magnify the problem further: the March 2013 attacks against Spamhaus, widely reported at the time as peaking around 300Gbps, were generated through open DNS resolvers rather than by brute population, and the same technique is still available. Our own write-up on what actually works against DNS amplification goes further into that mechanism.
Compromised servers doing the attacking is not new either. The large WordPress brute-force campaign reported in April 2013 ran from hijacked hosting accounts rather than consumer devices, for the same reason operators prefer cloud nodes today: bandwidth.
Hardening a Linux fleet so it cannot be recruited
- Key-only SSH. Password authentication disabled, management interfaces off public IPs entirely, access through a bastion or VPN with multi-factor authentication.
- Inventory discipline. The compromised host is nearly always the one that was not on the list: a test box, a migration leftover, a contractor’s staging VM.
- Egress filtering and anti-spoofing at the edge. BCP 38-style source address validation, plus outbound rules that stop a compromised host from being commercially useful to an operator. This is the single control that most reduces your contribution to somebody else’s bad day.
- Container and orchestration hygiene. Never expose the Docker socket or remote API to the internet, authenticate every data store, default-deny outbound from workloads that have no reason to initiate connections.
- Detection you will actually run. NetFlow or sFlow baselines, alerts on outbound volume and new-connection counts rather than CPU alone, and file integrity monitoring scoped to systemd, cron and init paths.
If the botnet is pointed at you: what to line up in advance
Always-on versus on-demand mitigation is sold as an architecture choice. Treat it as a time-to-mitigate choice. Linux-driven HTTP floods ramp in seconds, and the clock that matters starts at the first malicious packet, not when an engineer acknowledges the alert. On-demand adds BGP diversion time, route propagation and, if you are switching by hostname, DNS TTL expiry on top. Those minutes rarely appear in the SLA. The mechanics of diversion and return paths are covered in more detail in this explanation of how cloud scrubbing services really work.
Questions worth putting to a provider before signing: how much scrubbing capacity sits in the region where your traffic actually lands, rather than the aggregate figure across every continent; whether application-layer inspection is included or priced separately; and whether your authoritative DNS sits inside the same protection or outside it. On the first point, the arithmetic behind how much scrubbing capacity you need matters more than the marketing number.
One contractual point catches operators out repeatedly. Inbound protection and outbound abuse live in different boxes. UK ISP-level DDoS protection is generally about volumetric junk traffic arriving at your circuit; if your own fleet starts attacking someone else, the response you get is an abuse ticket and a null route, not mitigation. The boundaries are worth reading properly, and where ISP-level cover stops is the short version.
Finally, write the runbook while nothing is on fire: who declares an incident, who speaks to the upstream, what gets logged for a later legal or insurance claim, and who has authority to spend. When you are ready to put numbers against downtime, the board-ready model for a DDoS protection business case is the next thing to read.
Frequently Asked Questions
What is a Linux DDoS botnet?
A Linux DDoS botnet is a collection of compromised Linux systems, from cloud VMs and physical servers to routers and cameras running embedded Linux, that an operator controls remotely and directs to flood a target with traffic. Many share code lineage with Mirai, whose source was published openly in late 2016 and cross-compiles for ARM, MIPS and standard server architectures alike.
How do attackers get into Linux servers in the first place?
Mostly through exposure rather than exploitation: SSH on port 22 with password authentication enabled, the Docker remote API bound to 0.0.0.0:2375, Redis on 6379 with no password, and management consoles such as Jenkins reachable from the public internet. Unpatched firmware on edge devices accounts for much of the rest.
How can I tell if my Linux server is part of a botnet?
Look for outbound traffic that does not match the workload, long-lived connections to a single foreign IP on an unusual high port, binaries running from /tmp or /dev/shm, and unfamiliar systemd units or cron entries. External signals count too: an abuse notice, sudden null-routing, blocklist entries or an unexplained bandwidth bill.
Should I clean an infected Linux host or rebuild it?
Rebuild, in almost every case. Current Linux families install self-healing persistence across several locations and re-pull payloads within minutes of being removed, so a cleanup commonly fails twice before anyone accepts it. Snapshot the volume and capture a packet trace first, then rebuild from a trusted image with rotated keys and credentials.
Does ISP DDoS protection cover outbound botnet traffic from my own servers?
Generally no. ISP-level products are written around volumetric traffic arriving at your circuit, and abuse originating from your own address space is handled under the acceptable use terms instead, which typically means an abuse notice and, if ignored, a null route. Egress filtering and anti-spoofing on your side of the edge are what stop the problem at source.