Distributed Denial of Service (DDoS) attacks are the most common threat facing any public-facing VPS. Whether you run a small blog or a high-traffic streaming platform, you will eventually be targeted. This guide walks through a complete DDoS protection strategy for a Russia VPS, covering the difference between attack types, kernel-level hardening, Cloudflare integration, and when to upgrade to dedicated mitigation services.
1. Understanding DDoS Attack Types
DDoS attacks come in two main varieties: volumetric (Layer 3/4) and application-layer (Layer 7). Volumetric attacks overwhelm your network with sheer bandwidth — SYN floods, UDP floods, ICMP floods, amplification attacks. They are measured in Gbps and packets per second. Application-layer attacks overwhelm your application server with legitimate-looking requests — HTTP floods, slowloris, cache-busting attacks. They are measured in requests per second. The mitigation strategy differs significantly between the two. Volumetric attacks must be filtered upstream (at the network level), while application-layer attacks can be filtered at the application level with the right tools.
2. Layer 3/4 Protection: Provider-Level
Most Russia VPS providers include basic Layer 3/4 DDoS protection free with every plan. This typically covers attacks up to 20-100 Gbps and is implemented at the provider's edge router using flowspec rules or scrubbing centers. Check your provider's documentation for the exact capacity and whether higher-tier protection is available as a paid add-on. PrivateAlps offers 50 Gbps free, 200 Gbps as a paid add-on. SmartApe offers 20 Gbps free. Hostkey offers 200 Gbps free on Business+ tiers. If your provider's free protection is insufficient, either upgrade to a higher tier or add a Cloudflare proxy in front.
3. Cloudflare Integration
Cloudflare is the most accessible DDoS mitigation service for VPS operators. The free plan includes unmetered Layer 3/4 and Layer 7 protection, with attacks of 100+ Gbps routinely mitigated. To integrate Cloudflare: (1) sign up for a free account, (2) add your domain, (3) update your domain's nameservers to Cloudflare's, (4) configure DNS records pointing to your VPS IP with the orange cloud (proxied) enabled. Cloudflare will now proxy all traffic to your VPS, hiding your origin IP and filtering attacks. The free plan is sufficient for most users — the Pro plan ($20/month) adds Web Application Firewall, image optimization, and faster SSL.
4. Hiding Your Origin IP
If your origin VPS IP is publicly known, attackers can bypass Cloudflare and attack your VPS directly. To hide your origin IP: (1) never expose the IP in DNS records (always use Cloudflare's orange cloud), (2) check historical DNS records at SecurityTrails.com and request removal if your origin IP was ever exposed, (3) avoid sending email directly from your origin (use a transactional email service like SendGrid), (4) check that no subdomains leak the IP (e.g., direct.ftp.yourdomain.com). Once your origin IP is hidden, configure your VPS firewall to only accept HTTP/HTTPS traffic from Cloudflare's IP ranges, blocking all direct access.
5. Configuring the Firewall for Cloudflare-Only Access
Once your origin IP is hidden behind Cloudflare, restrict direct access to your VPS using `ufw` or `iptables`. First, fetch Cloudflare's IP ranges from their API: `curl https://www.cloudflare.com/ips-v4`. Then configure `ufw` to only allow HTTP/HTTPS from those IPs:
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
ufw allow from $ip to any port 80 proto tcp
ufw allow from $ip to any port 443 proto tcp
done
ufw deny 80/tcp
ufw deny 443/tcp
ufw allow 22/tcp # SSH (consider restricting to your IP)
ufw enable
This ensures only Cloudflare can reach your web server, making direct-to-origin DDoS attacks impossible. Keep SSH accessible from anywhere (or restrict to your IP) for emergency access.
6. Kernel-Level Hardening: SYN Flood Protection
SYN floods are a common Layer 4 attack where the attacker sends a flood of TCP SYN packets without completing the handshake, exhausting your server's connection tracking table. Linux has built-in SYN flood protection via `syncookies`. Enable it with: `echo 1 > /proc/sys/net/ipv4/tcp_syncookies`. Make it persistent by adding `net.ipv4.tcp_syncookies = 1` to `/etc/sysctl.conf` and running `sysctl -p`. Also increase the connection tracking table size: `echo "net.netfilter.nf_conntrack_max = 262144" >> /etc/sysctl.conf` and `sysctl -p`. These settings allow your server to handle much larger SYN floods without crashing.
7. Rate Limiting with Nginx
For Layer 7 attacks (HTTP floods), Nginx rate limiting is highly effective. Add to your `nginx.conf` http block:
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;
Then in your server block:
location / {
limit_req zone=general burst=20 nodelay;
limit_conn conn 10;
}
location /login {
limit_req zone=login burst=5 nodelay;
}
This limits each IP to 10 requests/second (with a burst of 20) for general traffic and 1 request/second for the login page. The `limit_conn` directive limits each IP to 10 concurrent connections. Excess requests return 503 (Service Unavailable). Tune the rates based on your legitimate traffic patterns.
8. Fail2Ban for Repeat Offenders
Fail2Ban monitors your server logs and bans IPs that show malicious behavior (failed logins, 404 scanning, excessive requests). Install with `apt install fail2ban` and configure `/etc/fail2ban/jail.local`:
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
[nginx-limit-req]
enabled = true
[nginx-botsearch]
enabled = true
[sshd]
enabled = true
This bans IPs for 1 hour after 5 failed attempts within 10 minutes. The `nginx-limit-req` jail parses Nginx's rate-limiting log and bans IPs that hit the rate limit repeatedly. The `nginx-botsearch` jail bans IPs that scan for common vulnerabilities. Fail2Ban is lightweight and effective against many types of automated attacks.
9. Application-Level Mitigation
For attacks that target specific application endpoints (e.g., expensive search queries, database-heavy pages), implement application-level mitigation. Cache aggressively with Redis or Varnish — a cache hit is essentially free, while a cache miss requires full processing. Implement query timeouts so a single slow request cannot tie up a worker. Use a job queue (Sidekiq, Celery, Bull) for expensive operations so they run asynchronously instead of blocking the request. Implement CAPTCHA on forms (hCaptcha is privacy-friendly and free) to filter bot submissions. Monitor application error rates and alert on spikes — a sudden error rate increase often indicates an attack in progress.
10. Monitoring and Alerting
Effective DDoS response requires real-time monitoring. Set up monitoring for: network bandwidth (if you see a 10x spike, you are likely under attack), CPU and memory usage (sustained 100% CPU during an attack will crash the server), request rate (track requests per second in Nginx logs), and error rate (5xx errors indicate the server is overwhelmed). Tools like Netdata, Prometheus + Grafana, or Datadog provide real-time dashboards. Configure alerts to notify you (via Slack, Telegram, SMS) when bandwidth exceeds 80% of capacity or error rate exceeds 5%. Early detection gives you time to enable Cloudflare "Under Attack" mode or scale up resources.
11. Cloudflare "Under Attack" Mode
When under active attack, enable Cloudflare's "Under Attack" mode. This presents a JavaScript challenge to every visitor, filtering out bots that cannot execute JavaScript (most Layer 7 attack tools). The challenge adds 5 seconds of latency for legitimate users but is highly effective at stopping attacks. Enable it from the Cloudflare dashboard: Security > Settings > Under Attack Mode > On. Disable it once the attack subsides (typically 1-6 hours). For attacks that bypass Under Attack mode, consider Cloudflare's "I'm Under Attack" rule with a custom challenge or rate limit.
12. When to Upgrade to Dedicated Mitigation
Cloudflare free is sufficient for most VPS operators, but some use cases require dedicated mitigation. If you face persistent large-scale attacks (>100 Gbps), if Cloudflare's free plan rate limits are too restrictive, if you need real-time attack analytics, or if you require custom mitigation rules, consider upgrading. Cloudflare Pro ($20/month) adds WAF and image optimization. Cloudflare Business ($200/month) adds custom SSL and 100% uptime SLA. Cloudflare Enterprise (custom pricing, typically $200+/month) adds dedicated support and unlimited mitigation. Alternatives to Cloudflare include Akamai, Imperva, Fastly, and Path.net. For most VPS operators, Cloudflare free is the right choice.
13. Testing Your DDoS Protection
Periodically test your DDoS protection to verify it works. Use a tool like `apachebench` (`ab -n 10000 -c 100 https://yourdomain.com/`) to simulate a moderate HTTP flood — your Nginx rate limiting should kick in and your server should remain responsive. Use `hping3` to simulate a SYN flood against a non-production server: `hping3 -S --flood -p 80 your-test-server.com`. Verify that `tcp_syncookies` keeps the server responsive. For larger-scale testing, use a service like Loader.io or RedBot. Do not test against production without prior planning — you may take your own site offline.
Conclusion
DDoS protection for a Russia VPS is a layered defense: provider-level Layer 3/4 mitigation, Cloudflare proxy for Layer 7, kernel-level hardening (SYN cookies, conntrack sizing), Nginx rate limiting, Fail2Ban for repeat offenders, application-level caching and timeouts, and real-time monitoring. The free tier of Cloudflare is sufficient for 95% of VPS operators — upgrade to Pro or Business only if you face persistent large-scale attacks. Test your protection periodically and have a response plan ready for when an attack arrives. With proper configuration, a Russia VPS can withstand attacks that would take an unprotected server offline in seconds.