A university publishes its own attack schedule every summer, under the title "academic calendar".
Enrolment, module registration, exam weeks, results day and clearing are fixed dates, known months ahead to every student, every applicant and anyone else who cares to look. Each one is a moment when a few hours of unavailability costs somebody something that cannot be handed back later: a seat on a module, a timed paper, a place at the institution.
Universities are also unusual in one respect most organisations never face. A large share of the people who might flood them already live on the campus network.
DDoS testing for universities, briefly
DDoS testing for universities and colleges is an authorised exercise that measures how an institution's services, networks and upstream protections behave under denial-of-service load, timed and scoped against the academic year. It covers the first-come moments (registration, results, clearing), timed online assessment, the shared identity layer, attack traffic that originates inside student accommodation, and the research network paths that by design skip the enterprise firewall.
Readers new to the discipline will find the sector-neutral groundwork in our guide to DDoS testing. This page sticks to what changes when the target keeps a term calendar and houses its own users.
| Calendar moment | What cannot be redone | What a test has to show |
|---|---|---|
| Module registration opens | a seat taken by someone whose page loaded | the opening minute is served fairly, or queued |
| Timed online exam | an assessment window shared by hundreds of candidates | per-address limits leave an exam hall untouched |
| Results day and clearing | a place allocated while your phones and forms were down | admissions channels survive the August peak |
| Any teaching week | nothing dramatic, just a steady supply of grudges | floods from halls are seen and contained inside |
The calendar is public, and the attacks follow it
Most targets have to guess when an attacker will show up. A university can read it off its own website.
Attacks track term time
In 2018 Jisc, which runs the Janet network that connects UK universities and colleges, published an analysis of DDoS attacks against its members. The attacks clustered in term time and in the hours of the teaching day, and fell away sharply in the holidays.
Jisc's reading was that a good share of them came from inside the community, from students and staff rather than distant botnet operators. Cheap booter services put a flood within reach of anyone with a grievance and a payment card, and a deadline is a grievance.
The Rutgers case
The best-documented example is in the US. Between 2014 and 2016 Rutgers University suffered a series of DDoS attacks that took down its network and online services for days at a time, some of them reported to coincide with course registration and exam periods.
The attacker turned out to be a Rutgers student, Paras Jha, who pleaded guilty in 2017 and was later identified as one of the authors of the Mirai botnet. A university's most capable adversary may be sitting in one of its own lecture halls.
A test in the quiet window measures an empty campus
The obvious time to run a test is a vacation, when a mistake disturbs nobody. The trouble is that the vacation campus is not the campus under attack.
Halls are empty, the VLE is idle, the identity provider sees a fraction of its term-time logins. A test that passes in July against that baseline says little about a Monday in November with every student online.
In the test plan
Run vacation tests with the missing term-time load added back as synthetic traffic: logins, VLE page views and registration-system queries at the rates last term's monitoring recorded. Then schedule a smaller, tightly bounded test in term, outside exam and registration weeks, to check that the synthetic picture was right.
Keep the summer window honest too. Clearing falls inside it, so the safest month for a test is also an admissions peak.
First come, first served turns seconds into places
Course registration at many institutions opens at a fixed minute, and popular modules fill within it. The same is true of accommodation booking and, in the UK, of clearing places in August.
Registration is a flash crowd you scheduled
If 20,000 students can register and half of them try in the first ten minutes, the registration system sees 1,000 arrivals a minute against a normal day's handful. Every one of them is refreshing, and many open several tabs.
That is a capacity problem before anyone attacks it. An attacker who adds a modest L7 flood in the same ten minutes needs far less traffic than the system's daily peak would suggest, because the real peak was never daily.
Clearing runs on phones and one form
Results day and clearing concentrate admissions into a few days. Applicants phone, chat and fill in a form, and offers are made while places last.
An outage of a few hours on that form, or on the telephony behind the hotline, does not delay demand. It sends applicants to the next institution on their list, and the places they would have taken are filled elsewhere by the time the site is back.
A queue beats a crash, and fairness is the test
The usual fix for a first-come rush is a virtual waiting room. Its design and failure modes are covered in the e-commerce post, where a product drop has the same shape.
A university adds one requirement a shop can skip: order has to be defensible. When a module fills, a student who lost a seat to a page that hung will appeal, so the test should show who got in, in what order, and whether a flood changed that order.
In the test plan
Rehearse the opening minute in a staging copy at last year's arrival rate, then again with an L7 flood layered on top. Record the order of successful registrations against arrival time, and check that the waiting room, or whatever stands in for it, never lets late arrivals overtake early ones because their requests happened to land on a healthier node.
An exam hall is one public address
Online assessment has moved much of the exam season onto the VLE and a few specialist platforms, many of them hosted SaaS. Their protections were mostly designed for traffic from people at home.
Three hundred candidates behind one NAT
A sports hall set up for a 300-candidate online exam usually reaches the internet through the campus egress NAT. To a hosted platform, every candidate in the room is the same source address.
Per-IP rate limiting is a standard DDoS control on those platforms. It assumes one address roughly equals one user. In an exam hall that assumption is wrong by two orders of magnitude, at the most sensitive hour of the year.
The arithmetic
Suppose each candidate generates about four requests a minute: page loads, answer saves and the platform's own heartbeat. One student at home sends 4. A computer lab of 40 sends 160. The exam hall of 300 sends 1,200 from one address.
With an illustrative per-IP limit of 600 a minute, the lab is fine and the hall is throttled or challenged halfway through the paper. Nobody attacked anything. The same misfire appears on the far side of carrier-grade NAT, as the mobile backend post explains; the campus version is concentrated into a single room and a single hour.
Lockdown browsers make challenges worse
Exam halls often run a lockdown browser (Safe Exam Browser, Respondus LockDown Browser and similar) that restricts what the candidate's machine can do. A JavaScript challenge or CAPTCHA served by the platform's DDoS layer may not render or complete inside it.
So the control that a web user clicks through can leave an exam candidate looking at a blank page with the clock running.
In the test plan
Ask each assessment platform what its per-address limits are and whether your egress addresses can be allowlisted or given a higher limit. Then confirm it with a rehearsal, not a flood: a mock exam with real candidate numbers from the real hall, watching for throttling, challenges and lost saves. Spread exam halls across several egress addresses if the platform cannot raise the limit.
Some attackers already live on your network
A university with student accommodation is, in effect, a residential ISP for several thousand people. Their devices sit on networks that connect to the same campus core as registration, records and the student portal.
Inbound scrubbing never sees it
Upstream DDoS protection, whether from the national research network or a commercial scrubbing service, filters traffic entering the institution. A flood launched from a student room against an on-campus service never enters. It travels from the halls network across the campus core to its target without passing the upstream defence at all.
What stands in its way is internal: segmentation between the accommodation network and administrative systems, rate limits on internal routers, and whether anybody is watching east-west traffic volumes.
Outbound floods get the whole campus blocked
The other direction is worse in a subtle way. A student who floods a hosted service, the institution's own SaaS VLE or someone else's, does so from the campus egress address.
The platform's defence does exactly what it should and blocks or challenges that address. Every other student and member of staff behind it is cut off too, possibly in the middle of an exam on the same platform.
Know who is behind an address
Halls networks usually require authentication, so traffic can be traced to an account, but only if the NAT translation logs and the authentication records are kept and can be joined quickly. An incident in progress is not the time to discover that the NAT logs roll over every hour.
In the test plan
From a test port on the accommodation network, send a bounded flood at a test service on the administrative side and check three things: whether segmentation or internal limits contain it, whether anyone is alerted, and how long it takes to name the account behind the source. Separately, ask your hosted platforms what they do when one of your egress addresses misbehaves, and whether they will contact you before blocking it.
One login opens everything
Nearly every academic service sits behind a single identity provider: the VLE, email, library e-resources, the timetable, the exam platform, often the Wi-Fi.
The identity provider is the shared point of failure
A flood at the login page, or simply at the identity provider's hostname, takes out every one of those services at once, including the ones hosted by third parties with their own excellent protection. The hosted VLE is up, and nobody can sign in to it.
Test the identity provider's public endpoints as their own target, with the same calendar in mind. A login flood during an online exam is an exam outage, whatever the exam platform's own resilience.
Federations and eduroam belong to everyone
Universities also rely on shared sector infrastructure. Federated access (the UK Access Management Federation, InCommon in the US) routes logins between institutions and publishers, and eduroam carries Wi-Fi authentication from a visitor's local campus through national RADIUS proxies to their home institution.
These are shared by hundreds of institutions and are not yours to load. Test your own side of each: your identity provider and your own RADIUS servers, under the load your own campus generates. How RADIUS itself behaves at its outstanding-request ceiling is covered in the VPN testing post.
Research traffic is built to skip the firewall
Research universities run a second kind of network alongside the enterprise one, and it breaks the usual assumptions about where DDoS protection sits.
The Science DMZ
Large research data transfers (genomics, physics, climate models, telescope data) run at many gigabits a second for hours. Stateful firewalls and inline inspection devices struggle with flows like that, so a common design pattern, the Science DMZ popularised by ESnet, places data transfer nodes on a separate path off the border router, protected by router ACLs rather than by the enterprise firewall.
That design is deliberate and sound for its purpose. It also means the DDoS controls that protect the website are not on the path that protects the research data transfer nodes.
The NREN is your upstream
Most universities connect through a national research and education network: Janet in the UK, Internet2 and regional networks in the US, the national networks joined by GÉANT in Europe. Many NRENs offer DDoS mitigation to connected institutions, and Jisc provides one for organisations on Janet.
That makes the NREN the first party in any test plan. Find out what its mitigation covers, how it is triggered, whether it applies to research prefixes as well as enterprise ones, and how long diversion takes. Then tell it about the test, because its detection does not know your traffic is planned.
In the test plan
Test the Science DMZ path on its own terms: what the border ACLs drop, whether flow data from the border reaches anyone who would notice a flood aimed at a transfer node, and whether the NREN's mitigation can act on those prefixes. Pause transfers and tell their owners first. Shared instruments and live transfers with partner institutions stay out of scope.
Who signs off a campus test
A university is several organisations sharing one network, and a test needs more signatures than a company of the same size.
- IT services and the network team, who own the core, the halls network and the egress.
- The NREN, whose detection and mitigation sit upstream.
- Each hosted platform in scope, under its own testing policy. Many SaaS providers forbid load testing without written permission.
- The registry or exams office, who own the calendar and will veto anything near an assessment.
- Research groups whose transfer nodes, instruments or clusters share the border.
- Accommodation services, if halls ports are used as test sources.
Ceilings, abort criteria and who can stop the test belong in the plan, as described in testing without disrupting production. For institutions that want the decisions rehearsed before the traffic, a tabletop exercise set on results day is a cheap first step.
What a passing result looks like on a campus
- The registration opening minute, rehearsed at last year's rate plus a flood, keeps arrival order intact.
- A mock exam with a full hall behind one egress address finishes with no throttling, no challenges and no lost saves.
- A bounded flood from a halls test port is contained before it reaches administrative services, raises an alert, and is traced to an account within an agreed time.
- Every hosted platform in scope has told you, in writing, what it does when one of your addresses misbehaves.
- The identity provider holds up under term-time login load plus attack traffic.
- The NREN's mitigation is confirmed to cover the prefixes you care about, research ones included.
- Vacation results come with the synthetic baseline that made them representative.
FAQ
Why are universities hit so often by DDoS attacks?
Their busiest and most sensitive days are published in advance, they have large and changing user populations, and some attackers are their own students with a grievance and access to cheap booter services. Jisc's 2018 analysis of attacks on UK institutions found them clustered in term time, which fits that picture.
Do per-IP rate limits work on a campus network?
Poorly, wherever many users share a public address. An exam hall or residence network behind one egress NAT can exceed a limit set for a single household. Ask hosted platforms to raise limits or allowlist your egress addresses, and spread large exam sessions across several.
Does Janet protect UK universities from DDoS?
Jisc offers DDoS mitigation to organisations connected to Janet, which helps against floods arriving from outside. It cannot see attacks that start inside the institution, such as from student accommodation, so internal segmentation and monitoring still matter. Check what the service covers for your own prefixes.
Is permission needed before flooding a SaaS learning platform?
Only with the provider's permission. Most SaaS providers have a testing policy and forbid unannounced load or DDoS testing. A rehearsal with real candidate numbers is often more useful anyway, since the main risk is the platform's per-address limits misfiring on legitimate traffic.
When in the academic year should a university run a DDoS test?
The vacation is safest, but the result needs term-time load added back synthetically. Avoid registration, exam weeks and, in the UK, results day and clearing, which fall in the summer window. A short bounded check during a normal teaching week confirms the synthetic picture.
The threat model is printed in the prospectus
Most organisations have to imagine when they will be attacked. A university already knows, because it chose the dates, printed them and sent them to every applicant.
What it rarely does is read that calendar as a list of test cases. The opening minute of registration, the exam hall behind one address, the student flooding the network from the inside, the research path with no firewall on it: each is a known date or a known design, and each has a test that can be run months before it matters.