How DDactic Tests Your Configuration, Not Just Your Vendor

Vendor selection is not protection. Having a contract with Cloudflare, Akamai, or AWS WAF means you have access to protection capabilities. Whether those capabilities are configured to protect your specific application is a separate question that requires active verification, not a review of your vendor's marketing materials or your own dashboard settings.

DDactic's configuration testing methodology is built on one principle: the only reliable test of a defense control is to simulate the attack it is supposed to stop and measure the outcome. Everything else is a proxy measurement that can be misleading. A rate limit rule that looks correct in the dashboard may not fire because the path expression does not match, the counting dimension is wrong, or the rule priority places it after an allow rule.

How DDactic Verifies Rate Limits

For each discovered endpoint with a rate limit claim (from configuration review or self-assessment), DDactic sends a calibrated request sequence: starting below the stated threshold, incrementing in steps, and recording the response code and any rate-limit headers at each step. A correctly configured rate limit returns 429 responses at or below the stated threshold. A misconfigured rule returns 200 at all tested rates. A rule that fires at the wrong threshold is documented with the observed vs. expected threshold delta.

This approach catches three common failure modes: rules applied to the wrong path (the rule was created for /api/login but the actual login path is /api/v2/auth/login), rules with the wrong counting dimension (IP-based rule does not fire when requests come from multiple IPs in the same /24), and rules that are in simulation mode (logging only) rather than enforcing mode.

How DDactic Verifies Origin Protection

Origin protection verification starts from the hypothesis that the origin IP is discoverable. DDactic searches certificate transparency logs, passive DNS history, SPF records, DNSBL entries, and any IPv4 ranges in the organization's ASN for IPs that respond on port 443 with a certificate matching the target domain. If a direct-access path exists, DDactic confirms it by making an HTTP request directly to the IP with the target's Host header. A 200 response confirms the origin is accessible without CDN protection.

How DDactic Verifies TLS and Connection Settings

TLS configuration testing goes beyond cipher suite enumeration. DDactic measures: TLS handshake timeout (by initiating a TLS negotiation and not completing it, measuring when the server closes the connection), idle connection timeout (by establishing a valid HTTPS connection and measuring when the server closes an idle connection), maximum connections per IP (by opening concurrent connections from a single test IP and measuring when new connections are refused), and TLS renegotiation acceptance (by sending a renegotiation request on an established connection).

How DDactic Verifies WAF Rules

WAF rule verification uses a set of known attack signatures against the target's endpoints, recording whether each triggers a block action. For DDoS-relevant WAF capabilities, the tests focus on: known bad User-Agent strings, malformed HTTP headers designed to bypass parser normalization, HTTP/2 stream multiplexing behavior, and content-type mismatch attacks (JSON body with form content-type). These are not full penetration test coverage -- they are the specific WAF behaviors most relevant to DDoS and automated abuse mitigation.

What Configuration Testing Produces

The output of configuration testing is a per-control verification table: control name, expected behavior, observed behavior, pass or fail, and remediation if failed. This is a factual record of what your defenses actually do, independent of what vendor documentation or your own configuration management says they should do. It is the answer to "do our defenses work?" rather than "did we buy the right product?"