Project context
The setting
A WordPress environment was receiving repeated automated probe and scanning requests that coincided with unstable server resource use.
Challenge
The problem to solve
The work required distinguishing unwanted automated traffic from legitimate requests, reducing the abusive load, and checking that the mitigation did not interrupt normal use.
My role and scope
What I was responsible for
I analysed request patterns and server behaviour, configured the Cloudflare protection used for mitigation, and monitored CPU behaviour after the change.
Investigation and reasoning
- Reviewed suspicious request patterns and repeated scanning attempts
- Compared abusive script requests with server-resource spikes
- Checked the affected routes before applying filters
Approach and implementation
- Configured targeted Cloudflare protection
- Blocked the identified probing behaviour
- Monitored server CPU behaviour for 24 hours after mitigation
Technical Scope
Technical Scope & Verification
Factual records of infrastructure troubleshooting, security hardening, and operational scope completed.
The project record states that CPU usage remained stable during the 24-hour observation period after the identified probe traffic was blocked. It does not establish permanent protection from future traffic patterns.
- Observation window
- 24 hours
- Observed CPU state
- Stable
- Control layer
- Cloudflare
Evidence note
Request analysis and a 24-hour server monitoring record described in the existing project data. Raw logs are not included in the portfolio.
Constraints and lessons
What this work made clear
- Security rules should be tied to observed request behaviour
- Post-change monitoring is necessary to catch false positives and resource regressions