Protect / DDoS Protection
Mitigation across network floods, application-layer attacks and connection pressure, including the origin exposure most setups leave open.
TechSteps implements layered DDoS protection covering network floods, application-layer attacks and connection exhaustion, and closes the origin exposure that lets attackers bypass an edge provider entirely. Most setups that fail under attack are protecting the front door while leaving the origin IP reachable.
What this solves
Two things are usually wrong when a site goes down under attack. The first is that the protection covers only volumetric traffic, while the attack is a small number of expensive requests against a search endpoint or a login form. The second is that the origin server IP is discoverable, so the attacker skips the protection altogether.
Origin exposure is the more serious of the two and the more commonly overlooked. Historical DNS records, mail headers, certificate transparency logs and an unprotected subdomain all leak it routinely. Once an attacker has the origin address, an edge provider in front of the domain is decorative.
Effective protection means filtering at the edge, limiting at the application layer, and making the origin unreachable except from the edge.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
Whether the origin is reachable directly, what leaks it, and which endpoints are expensive. This determines whether existing protection is real or nominal.
Firewall rules restricting the origin to edge provider ranges. Without this everything else can be bypassed, so it is the highest-value change and usually the fastest.
Rate limits and WAF rules derived from real patterns. Limits set against imagined abuse block customers, which is a self-inflicted outage.
Edge filtering for volume, application rate limits for expensive endpoints, and server-level connection limits as a backstop. Any single layer will eventually be the wrong one.
A cached page served from the edge costs nothing to serve. Caching is a genuine DDoS control, not only a performance one.
Anomaly alerting, a written procedure, emergency rules ready to enable, and escalation contacts. During an attack is the wrong time to be reading provider documentation.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
The most common failure by a wide margin. Traffic sent directly to the origin bypasses every edge control. Historical DNS records and mail subdomains leak this constantly.
A few hundred requests per second against an uncached search endpoint can exhaust a server while never reaching a volumetric threshold. Application-layer attacks are cheap to run.
Legitimate bursts get blocked, customers complain, the limits are removed entirely, and the protection is gone.
The attack starts and people begin reading documentation. Response takes hours instead of minutes, and the decisions made under pressure are worse.
The evidence needed to tune protection is discarded because logging was local and the disk filled up.
Questions we actually get asked
Partly, and probably less than you think. Cloudflare handles volumetric attacks well. Two gaps remain on most setups: the origin server is still directly reachable, so an attacker who finds the IP bypasses Cloudflare entirely, and the default rules are generic rather than tuned to your expensive endpoints. Both are fixable in a short piece of work.
Usually without effort. Historical DNS records are archived by several public services. Email sent from the server exposes it in the headers. Certificate transparency logs list subdomains. A staging or mail subdomain often points straight at the origin. This is why we audit for leaks rather than assuming the address is private.
A network attack tries to saturate your bandwidth or connection capacity with volume. An application-layer attack sends requests that look legitimate but are expensive to serve, such as repeated uncached searches. The second is cheaper to run and defeats volumetric protection, which is why it needs separate controls.
Yes, and the outcome is much better when the groundwork exists. If we already know your environment, response is minutes. If we are meeting your infrastructure for the first time during an incident, we spend the first hour discovering it. Either way, call rather than email.
Properly configured, it usually makes it faster, because the same edge caching that reduces attack cost also serves legitimate visitors from a nearby location. Poorly configured, aggressive challenges add friction. The tuning is where the difference lies.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.