Campus DDoS response: keep .edu sites up under flood

Tickets hit Slack before the graphs do. Admissions feels slow, the shared login queues, and someone wants every WAF rule flipped to block. Campus DDoS response is the first-hour playbook for .edu and agency sites: confirm edge vs origin, put traffic on the edge, use reversible wartime controls, inventory the VIP blast radius, open one status channel, and do not panic-promote. Count → promote still applies during recovery. Promote Copilot does not auto-block — you still click once. For the anonymized request-flood story — quiet edge, origin still burning — see /blog/request-flood-origin-bypass.

What the ops chair sees when the flood hits

The first signal is rarely a pretty dashboard. It is a ticket: the main .edu is slow, a departmental CMS will not load, registration POSTs hang, or the shared IdP login sits in a queue.

Edge counters can look fine while origin CPU, TLS handshakes, and 5xx climb. That split is the tell. A calm WAF console is not a healthy site if the load balancer is on fire.

Shared VIPs make the blast radius worse. Athletics, research, a forgotten FOIA portal, and the admissions hostname often sit on the same address. One flood, many owners, one thin web team.

Do not wait for a named incident report. Treat "the site is down" plus a quiet edge as origin-path work until you prove otherwise.

Anonymized request-flood story Higher education Government

First-hour checklist

Six reversible moves. Do them in order. Do not skip edge vs origin.

1. Confirm edge vs origin. Compare WAF/edge counters with load-balancer CPU, origin 5xx, and TLS failures. If the edge is quiet and the origin is not, assume origin IP bypass until you prove otherwise.

2. Put traffic on the edge. Public DNS must advertise the edge only — apex, www, admissions, permitting, departmental CMS. Remove leftover A/AAAA records that still publish the origin.

3. Apply reversible wartime controls. Geo, rate limits, and path blocks you can unwind later. Write down what you flipped so recovery is not a scavenger hunt.

4. Inventory the VIP blast radius. Which hostnames share the load balancer? A flood on one name can take the IdP, a citizen form, and a forgotten microsite with it.

5. Open one status channel. One thread, one owner, one sentence for comms. Stop the rumor Slack.

6. Do not panic-promote. Count-mode rules stay in count until evidence says promote. Promote Copilot explains Promote, Hold, or Needs allowlist. It does not auto-block. You still click once.

Hide origin IP behind a WAF What is WAF count mode?

Why origin IP exposure kills recovery

A quiet edge means nothing if attackers still punch the load balancer. Historical DNS, staging on the same VIP, vendor portals, and forgotten subdomains leak the origin IP. Attackers hit that address directly — often with your Host header — and the WAF never sees the flood.

Hide the origin IP behind the WAF and allowlist edge IPs only on origin listeners. An IP swap after a leak is obfuscation, not a fix — attackers rediscover the new address.

DNS cleanup without the allowlist is incomplete. The allowlist without DNS cleanup leaves accidental leaks. The durable operator pattern is both. The longer cut is Hide your origin IP behind a WAF. The first-person incident is the request-flood post.

Hide your origin IP behind a WAF (and allowlist edge IPs only)Request flood and origin bypass

Count → promote during recovery

Wartime controls (geo, rate, path) are temporary and reversible. Promoting managed rules from count to block is a different decision. Do not collapse them.

Abuse and legitimate peak traffic share the same shape during a flood: retries, odd User-Agents, stacked POSTs on admissions or permit forms. A panic promote turns students and citizens into the second outage.

Count-first still holds: rules start in count; after about 24 hours the dashboard shows what's safe to block — one click. During an active flood you may tighten wartime rate limits now, then promote managed rules only when the count window is evidence, not fear.

Promote Copilot recommends Promote, Hold, or Needs allowlist — evidence plus a short why. It does not auto-block — you still click once. Keep forms, auth, and IdP callbacks in count until the dashboard says otherwise.

What is WAF count mode? (and why you start there)WAF bot management for campus and agency sites

Status and comms

Pick one owner and one channel. Status is an ops function, not a committee. Faculty Slack, student government, and the press office should hear the same sentence.

Say what you know: which hostnames, whether the edge or the origin is the front, and what wartime control is on. Do not claim "we are blocking everything." That is how you promise a false-positive outage.

When the flood eases, publish the unwind: which wartime rules come off, which stay in count, and who owns the origin allowlist so the next wave does not walk around the edge.

Campus and agency estates already have the longer product pages — use those for the estate conversation after the incident, not during the first hour.

Managed WAF for higher education websites Managed WAF for university and college websites Managed WAF for government and public-sector websites

How ProtectMyWebsite fits

The WAF that tells you what's safe to block.

Rules start in count. After 24 hours, your dashboard shows what's safe to block — one click.

Promote Copilot explains Promote, Hold, or Needs allowlist. It does not auto-block. You still click once.

Self-serve is $150/site/mo with a 14-day trial. Larger campus or agency estates: Talk to sales — no Estate dollar amounts here.

We run the managed edge. You (or your host) still lock the origin so it accepts traffic from the edge's IP ranges only — so a flood cannot walk around a quiet console.

Talk to sales team See pricing

FAQ

What is campus DDoS response? The first-hour playbook when a flood hits a .edu or agency site: confirm edge vs origin, put traffic on the edge, apply reversible wartime controls, inventory the VIP blast radius, open one status channel, and do not panic-promote. Count → promote still applies during recovery.

How do I tell if the flood is hitting the edge or the origin? Compare edge counters with origin CPU, 5xx, and TLS failures. If the edge is quiet and the origin is not, assume origin IP bypass — attackers are hitting a leaked origin IP. See Hide your origin IP behind a WAF.

Why does a leaked origin IP kill recovery? The WAF never sees traffic aimed at the load-balancer address. You can tune the edge forever while the origin burns. Allowlist edge IPs only on origin listeners; an IP swap is obfuscation, not a fix.

Should I promote WAF rules during a flood? Wartime geo and rate limits can go on now if they are reversible. Do not panic-promote count-mode managed rules on forms or auth. After about 24 hours the dashboard shows what's safe to block — one click.

Does Promote Copilot auto-block during a flood? No. Copilot explains Promote, Hold, or Needs allowlist from count-window evidence. Promoting to block remains a human action. Origin allowlisting is a network control you (or your host) apply separately — it is not an AI deny.

Start here

ProtectMyWebsite is the managed WAF for campus and agency operators who need a flood playbook that does not panic-promote — and an origin lock-down so the next wave cannot walk around the edge.