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

See Usage Limits for the request budgets, authentication requirements, and shared network limits.

Attack-Specific Protection

• WordPress/CMS attack blocking for common attack vectors (/wp-admin/, /wordpress/)

Bot Detection & Blocking

• User-Agent based detection blocking known malicious bots (semrus, AhrefsBot, MJ12bot, ZoominfoBot, DotBot, MauiBot)
• Outdated browser blocking according to the browser requirements
• 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.

SSH Brute-Force Protection

Failed SSH authentication and malformed HTTP requests can lead to temporary IP bans. See SSH connection limits for the authentication and session limits, and SSH Access for configuring the correct key.