A bare-metal DDoS test measures one number the cloud is built to hide from you: the exact rate at which a fixed machine stops serving, with nothing waiting behind it to take over.
A rented dedicated server, or your own hardware in someone else's rack, has no managed scrubbing edge in front of it and no autoscaler behind it. There is no elastic tier to absorb a spike, no platform WAF to shed an L7 flood, and no second machine that spins up in ninety seconds when the first one saturates. The capacity you provisioned is the capacity you have, and it is a hard constant.
That makes bare metal the honest floor of the whole environment set. Every cloud post in this series has a cushion somewhere: a managed edge that absorbs volume before your config is consulted, or an autoscaler that trades a traffic outage for a bandwidth bill. Bare metal has neither. When an attack finds the ceiling, the failure is abrupt, and the only levers are the ones you installed before the traffic arrived.
This is the bare-metal instance of structured DDoS testing. The methodology is the one that governs any environment. The contour is specific: no platform DDoS edge you operate, a machine whose kernel and network card are the real front line, and one thin volumetric defense that you do not own because you do not own the transit.
The worst-of-both-worlds shape, and why it is the point
It helps to place bare metal against its neighbors, because its shape is defined by what it lacks on each side.
A managed cloud gives you an edge and elasticity: the platform absorbs L3/L4 volume and scales compute out under load. A budget host like a single Droplet drops the elasticity but often keeps a free always-on L3/L4 floor. An on-premise deployment has no cloud edge either, but you own the network: your own BGP sessions, your own scrubbing contract, your own carrier relationships to divert traffic.
Bare metal sits in the gap between all three. No managed edge, like on-prem. No elasticity, like the budget host. But unlike on-prem, you are a single tenant in a provider's data center, so you do not own the transit and cannot run your own diversion. You get the absences of each neighbor without the compensating strength of any. That sounds like a weakness to apologize for. It is actually why the test is clarifying: with no cushion to blur the result, a bare-metal test reads the raw survivability of the machine itself.
At a glance: what a bare-metal DDoS test validates
| Bare-metal layer | What it is supposed to do | What the test actually verifies |
|---|---|---|
| Upstream transit / provider mitigation | Absorb or divert volumetric floods before they reach the rack | Whether the provider scrubs, null-routes, or does nothing, and at what apparent threshold your IP gets blackholed |
| NIC + kernel network stack | Receive and process packets | The packets-per-second ceiling, and which CPU core or queue saturates first, well below line-rate bandwidth |
| In-host mitigation (XDP/eBPF, kernel tuning) | Drop hostile packets cheaply, early | Whether driver-level filtering and multi-queue tuning actually move the ceiling, and by how much |
| Firewall / conntrack | Filter and track connections | Whether the connection-tracking table is the layer of first failure, and at what connection rate it fills |
| The L7 layer | (not provided by the platform) | Whether anything rate-limits, scores, or filters application requests |
| Compute (the single machine) | Serve the application | The offered rate at which goodput collapses, and that nothing scales out to recover |
The recurring theme: on bare metal there is no managed control to audit, so the test moves straight to behavior. Where is the hard ceiling, what sets it, and can the two levers you actually control, kernel tuning and upstream mitigation, move it before an attacker finds it.
The protection surface you are testing
Be precise about each layer before designing the test. On bare metal the layers are unusually concrete, because there is no managed service abstracting them away. You are testing a network card, a kernel, and whatever the provider does upstream, and little else stands between the attack and your process.
The upstream question: scrub, blackhole, or nothing
The first thing to establish is not on your machine at all. It is what your host or transit provider does when a volumetric flood arrives, because that is the only thing standing between a large attack and a rack that cannot absorb it.
There are three common answers, and they are very different for you. Some providers run scrubbing and will divert and clean traffic destined for your IP, returning the legitimate remainder. Some offer nothing and let the flood arrive at your port. And many, by default, protect the data center rather than your service: past a threshold they null-route your IP, dropping all traffic to it, hostile and legitimate alike.
That last behavior deserves to be named plainly, because it inverts the usual test result. A null-route is not mitigation from your point of view. It is a completed denial of service, executed by your own provider to stop your problem from becoming everyone else's in the shared facility. The attacker wanted your service unreachable; the blackhole delivers exactly that.
So the test's first job is to learn which of the three you have, and if it is the third, at what apparent volume the null-route triggers. Treat the threshold and the mechanism as published-doc and contract material to confirm before testing, and expect some of it to be deliberately vague. The durable finding is not a number the provider may not publish. It is knowing, before a real attack, whether your only volumetric defense is a service that keeps you online or a switch that takes you offline to protect the neighbors.
The NIC and the kernel: the ceiling is packets, not bandwidth
This is the layer that makes a bare-metal test different, and the single most common misreading of a dedicated server's capacity.
Operators think in bandwidth: a server with a 10 Gbps port is assumed to withstand something like 10 Gbps of attack. But a bare-metal machine almost never fails on bandwidth. It fails on packet rate. Receiving a packet costs CPU regardless of the packet's size: an interrupt, a trip through the driver, a software interrupt (softirq) to process it up the stack. A flood of tiny 64-byte SYN or UDP reflection packets can pin a core at a fraction of line-rate bandwidth, because the cost is in the count, not the volume.
Worse, by default that cost often lands on a single CPU core. If the NIC has one receive queue, or the queues are not spread across cores with receive-side scaling (RSS), every incoming packet's softirq runs on one core. That core hits 100 percent, ksoftirqd saturates, and the machine starts dropping packets, legitimate ones included, while a bandwidth graph looks calm and the other cores sit idle. You are down, and the dashboard everyone watches shows nothing wrong.
So the headline number on bare metal is not Gbps of capacity. It is packets per second to goodput collapse, and which core or queue gives way first. Those two figures characterize the machine's real DDoS ceiling, and no datasheet lists either.
In-host mitigation: the levers you actually control
Because there is no managed edge, the mitigation you own lives inside the machine, and bare metal gives you deeper access to it than a managed fleet ever would. This is the compensating strength worth leaning on.
The highest-leverage lever is XDP (eXpress Data Path), an eBPF hook that runs in the NIC driver at the earliest possible point, before the kernel allocates a socket buffer and before the packet reaches conntrack or netfilter. A packet dropped in XDP costs a tiny fraction of one that traverses the full stack, so an XDP drop program can raise the packet-rate ceiling by an order of magnitude, but only if the NIC driver supports native XDP rather than the slower generic mode, and only if the receive queues are set up for it.
Below that sit the classic kernel tunables that move the ceiling: multi-queue RSS (and RPS/XPS) to spread interrupt load across every core instead of one, larger NIC ring buffers (ethtool -G) to ride out microbursts, SYN cookies with a deep tcp_max_syn_backlog and somaxconn to survive a half-open flood, and conntrack sizing or a NOTRACK rule on the hot path so connection tracking is not the thing that fills first.
These are the bare-metal equivalent of a cloud origin lock: the concrete configuration the reader actually wants. The test's job is to measure whether they are in place and whether they move the number. A machine with defaults and a machine tuned for packet processing can differ by a factor of ten on the same hardware against the same flood, and the only way to know which one you are running is to send the traffic and watch the ceiling.
The missing L7 layer
Like the budget hosts, bare metal ships no managed web application firewall and no application-layer DDoS service. Nothing on the platform inspects an HTTP request.
The mechanics of that gap, why the single-node kernel becomes the layer of first failure, how an HTTP flood or a Slowloris-style slow attack lands directly on the process, and how to build the L7 layer the platform omits, are covered in full for the near-identical single-node shape in DigitalOcean DDoS testing. The short version is the same here: if an application-layer flood reaches the server, the only thing in its way is what you put there. A valid request to a valid port is invisible to any L3/L4 or packet-level filter, because from below the transport layer it looks like traffic, not an attack.
Many bare-metal deployments front the origin with a third-party CDN or scrubbing edge to supply both the L7 layer and a volumetric buffer. That is a sound pattern, and it changes what origin exposure means here, which is the next point.
Fixed capacity, and re-provisioning measured in days
A bare-metal server is one physical machine. Its kernel limits, the conntrack table, the accept queue depth, the ephemeral port range, cap concurrent work, and unlike an instance group there is nothing to scale out from under a flood. Once saturated it stays saturated until the attack stops or you intervene.
The part that has no cloud analog is the recovery path. In a cloud, "add capacity" is an API call and a warm pool. On bare metal, adding a machine means a provider has stock, a technician racks it, and the network is cabled and announced, a process measured in hours or days, not seconds. So the elastic fallback that every cloud post can quietly assume simply is not available mid-attack. The capacity to survive an attack has to exist before it starts. That single constraint is why bare-metal resilience is a design-time property, not a runtime reaction, and why the test's real audience is the architecture review, not the incident bridge.
What bare-metal DDoS testing actually surfaces
A useful test is organized around the gaps that recur on bare-metal estates. They follow from the shape above: no managed edge, one thin upstream defense you do not own, and a fixed machine whose network stack is the front line.
The packet-rate ceiling is the headline finding
On a platform with a managed edge, you test whether the edge engages. On bare metal there is no edge, so the first and most important number is the machine's own ceiling: at what offered packet rate does goodput for legitimate clients collapse, and which resource, a saturated core, a full conntrack table, an exhausted accept queue, gave way first.
The reason this leads is that it is both the most damaging finding and the most misunderstood. Teams provision against bandwidth and get surprised by packet rate; they watch a throughput graph and miss a single pinned core. A test that offers a rising rate of small packets and records the point where real requests start failing gives you the one figure a bare-metal deployment lives or dies by, and pairs it with the tuning question: does XDP and multi-queue RSS move that figure enough to matter.
The blackhole is a defense that defeats you
The second finding is the upstream one, and it is the finding teams least expect to be a problem: your provider's mitigation may be a mechanism that takes you offline.
When a volumetric flood exceeds the provider's tolerance for a single customer in a shared facility, the default action on many hosts is to null-route the targeted IP. From the provider's side that is correct, it protects the other tenants and the fabric. From your side it is indistinguishable from the attack succeeding. The test has to establish this behavior deliberately: does a volumetric profile against your IP get scrubbed and returned, or does it get your address blackholed, and if so, roughly where the line sits.
Knowing the answer changes your architecture, not a config. If the provider blackholes, then any IP that must stay reachable under volume belongs behind a scrubbing service or an anycast edge that can absorb the flood before it reaches the provider's threshold, because the provider will make the same decision every time. This is the point where a bare-metal deployment either accepts a hard volumetric limit or moves its front door somewhere with more headroom.
Which resource fails first, and whether it recovers
Beyond the raw ceiling, the valuable detail is the order of failure. A connection flood, a slow-read attack, or a burst of half-open connections stresses different limits than a packet flood: the conntrack table, the accept queue, the socket and file-descriptor limits, the TLS-handshake CPU. On a fixed machine these sit at different heights, and the lowest one is your true ceiling for that class.
The test's job is to find that order for each attack class and, crucially, to confirm whether the machine recovers on its own once the attack stops or stays wedged, needing a manual restart of a service or the box. A managed platform often recovers by shedding load to healthy capacity; a single bare-metal server has no healthy capacity to shed to, so a resource that does not self-clear, a conntrack table that stays full, a process stuck in a bad state, turns a timed attack into an outage that outlasts it. That distinction, self-healing versus stuck, is a bare-metal-specific test output worth capturing explicitly.
Origin exposure is the default state, not a leak
On a CDN-fronted setup, origin exposure is an accident: the origin is supposed to be hidden and a leak reveals it. On pure bare metal there is nothing to leak, because the machine's public IP is the origin and it is published in DNS by design. The front door is wide open because there is no other door.
That only becomes a finding when you add an edge. If you front the bare-metal origin with a CDN or scrubbing service for the L7 and volumetric protection the platform does not provide, then the whole benefit depends on one invariant: all traffic must arrive through that edge. The moment an attacker learns the raw IP, through historical DNS, a certificate transparency entry at crt.sh, a stale A record, or an address baked into a client, they connect straight to the machine and every edge control is bypassed. The full mechanics are in how attackers bypass CDN protection. The lock is the same shape as elsewhere: a host firewall that admits your application ports only from the edge provider's published ranges, plus an origin secret the edge presents and the application requires, so a direct connection to the raw IP is refused before it reaches your code. On bare metal that firewall is your own, running on the machine, which means it also costs the machine CPU to enforce, one more reason to drop unwanted packets as early as XDP allows.
Bare-metal authorization: two owners, not one
Authorization on bare metal has a structure worth stating, because it is different from both the cloud and the pure on-prem case.
In a managed cloud, the platform's acceptable-use policy gates your simulated attack. On pure on-prem, you own the gear and the transit, so the coordination is with your own carriers. Bare metal splits the difference: you control the operating system on the machine, but you are a tenant on infrastructure and transit you do not own, so the provider's acceptable-use policy governs what traffic you may generate, and their abuse systems watch for floods, including a self-test against your own server.
There is a specific hazard here. A convincing volumetric self-test can trip exactly the provider null-route described above, which both ends your test early and may draw automated action against your account, and because you are sharing the facility, an unscoped test can spill onto neighbors' infrastructure or a shared uplink. The durable instruction is procedural, because policies and contacts change: before any bare-metal DDoS test, read the provider's current acceptable-use and testing guidance, and coordinate the window with their support or network operations channel if your plan approaches volumes their systems would flag. Written authorization from the legal owner of the target is mandatory regardless of provider policy; the acceptable-use gate sits on top of that owner authorization, never in place of it. The same discipline of running the test without disrupting production applies in full, and applies to the shared facility as well as to your own service.
Designing the test: environment, scope, and measurement
The structure that keeps a bare-metal test informative and safe is the one that governs any production-adjacent test, with a bare-metal contour.
Environment selection
The strongest first target is a staging machine provisioned identically to production: the same server model and network card, the same kernel and tuning, the same firewall rules, and the same upstream provider so the mitigation behavior matches. On bare metal the hardware itself is part of the configuration under test, because the packet-rate ceiling depends on the NIC, the driver, and the core count, so a differently specced staging box gives a misleading number. Where identical hardware is impractical, record the differences and treat the staging ceiling as a lower bound to confirm.
Where a finding can only be confirmed in production, the provider's real null-route threshold, for instance, or the reachability of the machine around a third-party edge, a tightly scoped canary with explicit abort criteria does the job, coordinated with the provider so a genuine self-test does not read as an attack on the facility.
Scope as a bounding document
The scope names the exact resources: the machines and their public IPs, the hardware and NIC model, the kernel version and relevant tunables, the firewall rules, the upstream provider and its known mitigation behavior, and any third-party edge in front. It sets the vectors and maximum packet rates, the test windows, the kill switch, and the escalation path, including a provider contact for the case where a test approaches the null-route line.
On bare metal specifically, the scope should record the expected upstream behavior per target, because a scrub and a blackhole demand different abort criteria, and it should state the hardware baseline, since the whole point of the packet-rate finding is that it is specific to the machine under test.
Measurement per layer
Each layer gets a measured outcome. Upstream: whether a volumetric profile is scrubbed or null-routed, and the approximate threshold. NIC and kernel: the offered packet rate at which goodput collapses, which core or queue saturated first, and whether multi-queue tuning and XDP move that ceiling. Conntrack and firewall: the connection rate at which the table fills, and whether it is the first thing to give way. Compute: the offered rate at which legitimate goodput collapses for each attack class, and whether the machine self-recovers or stays wedged. Any third-party edge: whether the origin was reachable on its raw IP around it.
The deliverable is not "the server stayed up." It is a per-layer characterization: the packet-rate ceiling and its first-failing resource, the upstream provider's real behavior, the effect of tuning, and what a legitimate user experienced throughout. Folding those numbers into a defensible posture is the subject of DDoS resilience testing.
Mapping attack classes to bare-metal controls
A thorough test exercises each layer against the control meant to defend it, including the many layers where the platform provides nothing and the defense is entirely yours. The mechanics of each class are covered in DDoS attack vectors, and real adversaries rarely send one class at a time, which is the subject of multi-vector DDoS testing, where a simultaneous, adaptive delivery is the frontier of the discipline.
- L3/L4 volumetric (UDP reflection, ACK flood, carpet-bombing across a range) have no defender on the machine that can survive true volume; the only answer is upstream scrubbing or an absorbing edge, and the test confirms which of scrub, blackhole, or nothing your provider does.
- Packet-rate and connection-state floods (SYN flood, small-packet floods, TCP connection flood, slow-read, half-open) land on the NIC and kernel. This class reveals the packet-per-second ceiling, the saturating core, and the conntrack and accept-queue limits, all of which sit well below the bandwidth ceiling and are moved only by tuning and XDP.
- L7 application floods (HTTP floods, HTTP/2 abuse, slow attacks) have no managed defender on the platform. They complete valid handshakes, look legitimate to any packet filter, and land on the process directly, testing whatever L7 control you added or proving none exists.
- Application-logic abuse (credential stuffing under any rate limit, expensive search, cart abuse) is the hardest class anywhere, and on bare metal it is entirely an application-code and reverse-proxy concern. The platform offers nothing here by design.
Procurement note: subscription versus project engagement
One consideration sits at the procurement layer rather than the technical one. DDoS testing is engaged both as an ongoing subscription and as a discrete project.
The models suit different cadences. A bare-metal deployment that changes when hardware is refreshed, when a kernel or NIC driver is upgraded, when the machine moves to a new provider, or when a third-party edge is added in front, maps naturally onto project engagements: the test happens when the change happens, because on bare metal a hardware or kernel change moves the very ceiling the test measures. A continuously deploying estate may prefer a standing capability.
Neither is universally correct. Annual commitments can price out a team whose real need is a handful of well-scoped tests a year, a common shape for the cost-conscious teams that choose bare metal for its price-to-performance in the first place. Match the engagement model to the cadence the estate warrants, not the model a vendor leads with.
FAQ
What is bare-metal DDoS testing?
Controlled, authorized generation of attack-shaped traffic against a dedicated physical server, to verify how it behaves under pressure. It validates the specific machine and its surroundings: the packet-per-second ceiling and which resource fails first, whether the upstream provider scrubs or null-routes a volumetric flood, whether kernel tuning and XDP move the ceiling, and any application-layer defenses you added, rather than testing DDoS protection in general.
Why does a bare-metal server fail on packet rate instead of bandwidth?
Because processing a packet costs CPU regardless of its size. A flood of tiny packets generates a huge interrupt and softirq load, and if that load lands on a single core, which is the default without multi-queue receive-side scaling, the core saturates and the machine drops packets far below its rated bandwidth. Packets per second, not Gbps, is the number that describes a dedicated server's real ceiling.
Does a hosting provider protect a bare-metal server from DDoS?
It depends entirely on the provider, and the test's job is to find out which of three behaviors you have. Some run scrubbing and clean traffic to your IP; some do nothing and let the flood arrive; and many, by default, null-route the targeted IP past a threshold to protect the shared facility, which from your side is a completed outage. Confirm the behavior and the approximate threshold before you rely on it.
Can you defend a bare-metal server against DDoS without a cloud edge?
Partially, and bare metal gives you unusually deep tools to try. XDP and eBPF drop hostile packets in the NIC driver before they cost the full stack, and multi-queue RSS, larger ring buffers, SYN cookies, and conntrack tuning raise the packet-rate ceiling. But true volumetric attacks exceed any single machine, so for reliable availability under volume the front door still belongs behind upstream scrubbing or an absorbing edge.
What is the first thing to validate on a bare-metal deployment?
The packet-per-second rate at which legitimate goodput collapses, and which resource, a saturated core, a full conntrack table, an exhausted accept queue, gave way first. That single figure describes the machine's real DDoS ceiling. Then establish what your upstream provider does with a volumetric flood, because that determines whether the machine ever sees the largest attacks at all.
A machine, measured, not a platform, trusted
The durable knowledge from a bare-metal test separates cleanly from the perishable. Five years from now, a dedicated server will still fail on packet rate before bandwidth, a single core will still saturate first without multi-queue tuning, XDP will still be the cheapest place to drop a packet, and a fixed machine will still have nothing to scale out to when it fills. Those are properties of the hardware and the kernel, not of a vendor's roadmap.
What you have to keep re-verifying is everything that moves with the machine and its surroundings:
- where the packet-rate ceiling sits after a hardware refresh or a NIC driver upgrade
- whether your tuning survived the last kernel update, or quietly reverted to defaults
- which resource fails first, and whether the machine still self-recovers, as the workload's connection and TLS profile drifts
- what your current provider actually does with a volumetric flood, scrub or blackhole, since a move or a contract change can flip it
- whether a leaked origin IP still lets an attacker reach the raw machine around any edge you added
Most environments in this series hand you a control and ask whether you configured it correctly. Bare metal hands you a machine and asks a blunter question: how much can it take, and what happens at the exact packet where it can take no more. There is no managed edge to blur the answer and no autoscaler to postpone it, which is uncomfortable, and also the reason a bare-metal number is the most honest one you can get. A dedicated server is not a weaker place to run; it is an unforgiving one, and the only way to know its limit is to walk it up to that limit yourself, on a schedule you set, before an adversary walks it there on theirs.