Defense & Protection Measures

We have witnessed the historic attacks on the Codeberg infrastructure, primarily through DDOS attacks (on the technical side) and user spam (on the moderation side). DDOS is hard to prevent in the first place, even with active support rails from the underlying cloud provider. It highly depends on the magnitude of the attack whether it will be classified as “DDOS” or just as “heavy traffic”.

We want to be frank and open here: we can’t say what will happen until the first attack has landed ;)

Note

We conducted load-tests before going live with CodeFloe, however, these are hard to compare to a real DDOS attack. Also simulating these in the dev environment is not a fair comparison as the resources there are substantially lower than in production.

In general, there are many ways one can attack a public service. We are trying our best to put practices in place that prevent unauthorized access, resource abuse and other known risk factors, such as SQL injection attacks and cross-site scripting (XSS) attacks. This goes in line with a clear and transparent RBAC-system for all satellite-services in place which can eventually have an influence on the primary instance and its data.

Multi-Layered Defense System

Following HAProxy’s bot protection guidelines, we have implemented a multi-layered defense system with the following measures:

Rate Limiting & Traffic Control

• General rate limiting per IP address: 10,000 requests per 30 minutes (~5.5 requests/second sustained)
• Per IP+URL rate limiting over a 24-hour window to prevent targeted resource abuse
• Path-specific rate limiting with different thresholds:
  • Static assets (/assets, /avatars): 4000 requests per 30 minutes
  • Large repositories (containing linux, bsd, kernel): 1200 requests per 30 minutes
  • Git operations (commit, branch, compare): 2000 requests per 30 minutes
• Error-based rate limiting blocking IPs with >10 error responses over 5 minutes
• Brute force protection: 10 POST requests to /login per 3 minutess

Attack-Specific Protection

• Brute force attack prevention for login endpoints (>10 POST requests to /login within 3 minutes)
• WordPress/CMS attack blocking for common attack vectors (/wp-admin/, /wordpress/)
• Bot persistence tracking that tags and continues blocking suspected bots until stick-table expiration

Bot Detection & Blocking

• User-Agent based detection blocking known malicious bots (semrus, AhrefsBot, MJ12bot, ZoominfoBot, DotBot, MauiBot)
• Outdated browser blocking preventing access from Chrome versions more than 10 major versions behind current
• IP-based blocking using curated lists from the Ultimate Hosts Blacklist project

Security Headers & Request Sanitization

• HSTS enforcement with 2-year max-age, subdomain inclusion, and preload directive
• Anti-clickjacking protection via X-Frame-Options
• MIME type sniffing prevention through X-Content-Type-Options
• Secure cookie enforcement with Secure and SameSite=Lax attributes
• Privacy protection including FLoC opt-out
• Request header sanitization removing client-provided IP headers to prevent spoofing

Allowlist for Good Bots

On top, we also have a dedicated allowlist for “good bots”. These are helpful to let projects be found by search engines and alikes. We are using a curated list from “AnTheMaker/GoodBots” for that.