Layers of defense
Firewall - close what you do not serve
Default-deny inbound, allow only 80/443 and SSH. The smallest attack surface starts here.
Rate limiting - cap per client
limit_req in nginx smooths bursts and stops a single IP from flooding your app.
fail2ban - ban repeat offenders
Watches logs and bans IPs that brute-force, scan, or keep hitting limits.
App-level limits
Throttle login and password reset, add a captcha on sensitive forms, lock accounts after repeated failures.
Set it up in three steps
Close the doors with a firewall
sudo ufw default deny incoming
sudo ufw allow 80,443/tcp
sudo ufw limit 22/tcp # rate-limit SSH against brute force
sudo ufw enableRate-limit at the proxy
# nginx - strict on auth, looser elsewhere
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location /login { limit_req zone=login burst=3 nodelay; proxy_pass http://app; }Ban persistent offenders
# fail2ban watches auth/nginx logs and bans repeat IPs at the firewall.
sudo systemctl enable --now fail2ban
sudo fail2ban-client statusTier the limits by what hurts
Not every route deserves the same limit. Make authentication and anything that costs money or sends mail the strictest, APIs moderate, and static content loose. The aim is to stop credential-stuffing, scraping, and brute force without throttling real users - so start conservative, watch for false positives, and tighten the routes that actually get abused.
Generate the configs instead of hand-writing them: the rate-limit generator, UFW firewall generator, and fail2ban generator produce ready-to-use rules for each layer.
Security posture, kept consistent and recorded
Abuse protection only works if it is on, the same, on every host - and drift is how a forgotten box becomes the way in. On your own servers, Infraveil helps you apply firewall, rate-limit, and ban rules consistently across the infrastructure you run, watch that they stay in place, and record changes - so “we rate-limit login” is something you can verify, not assume.
Frequently asked questions
Do I still need upstream DDoS protection?
For production workloads, upstream provider, CDN, or scrubbing mitigation is strongly recommended. Keep origin firewalls, rate limits, fail2ban, and application throttles enabled because they address different abuse and bypass paths.
What should I rate-limit, and to what?
Tier by sensitivity: auth and password-reset strictest (a few attempts per minute per IP), APIs moderate, static loose. Stop credential-stuffing and scraping without throttling real users - start conservative and watch for false positives.
Rate limiting vs fail2ban - what is the difference?
Rate limiting caps request speed in real time at the proxy; fail2ban watches logs and bans an IP at the firewall after a pattern of bad behavior. Complementary - one slows abuse, the other removes persistent offenders.
Can this stop a DDoS?
It helps with application-layer abuse, brute force, scraping, and smaller per-client floods. Large distributed attacks that can saturate network capacity require upstream provider, CDN, or scrubbing mitigation. Origin hardening remains necessary as the complementary layer.
Client-side, no signup — they run in your browser.