Network and attack protection

#Overview of the layers

All settings live in the Security group of Server Admin (port 2087, /admin); Cloudflare Tunnel is in the Domains group. The table shows where each protection runs.

On Docker and Railway the platform owns the network edge: port access is configured in the platform network settings, while the panel applies brute-force protection, IP blocks and rate limits. See Docker and Railway for details and pricing for the Pro edition.

#Firewall

Debian and Ubuntu servers use UFW; AlmaLinux, Rocky Linux and RHEL servers use firewalld. The installer configures the firewall by default (the --without-firewall option skips this step): incoming traffic is denied by default, outgoing traffic is allowed, and these ports are opened:

On the Firewall page you can list the rules and add Allow, Block, Reject or Limit rules for a port or a port range (e.g. 6000:6100), optionally restricted to a single source IP or CIDR range. Limit exists only on UFW, because firewalld has no per-IP connection limiting. On firewalld every change is applied to both the runtime and the permanent configuration, and it is rolled back if the permanent configuration fails validation.

#Lockout safeguards

• Before enabling the firewall, the panel allows the SSH, panel (2083, 2087) and web (80, 443) ports.
• The only rule that allows SSH cannot be deleted.
• When you change the SSH port, the new port is opened in the firewall first.

If you are locked out, run these as root on the server console; they work even while the panel is down. The first opens every port to your address, the second turns the firewall off.

$ sudo bipanel firewall allow-ip 203.0.113.7
$ sudo bipanel firewall off

#Fail2Ban and SSH hardening

The installer enables Fail2Ban for sshd, plus Postfix and Dovecot when mail is installed and Pure-FTPd when FTP is installed: 5 failures within 10 minutes lead to a 1-hour ban. The Firewall page lists the Fail2Ban jails and banned addresses, and you can lift a ban there. The SSH hardening section on the same page manages the SSH port, root login and password login. Settings are written to /etc/ssh/sshd_config.d/bipanel.conf and validated with sshd -t before they are applied.

#DDoS protection and rate limits

The DDoS Protection page offers three levels: Off, Normal (the default) and Under attack. Each level has its own thresholds, which you can change separately.

• Panel layer: an IP over the threshold gets a 429 response; an IP over twice the threshold is banned automatically.
• Web layer: site access logs are read every 10 seconds, and an IP over the per-minute threshold gets a 429 from Apache. Apache request read timeouts cut off slow-request (slowloris) attacks, and the timeouts are shorter at the Under attack level.
• Network layer (native server only): banned IPs are dropped in the kernel with nftables, and the new-connection rate per IP and concurrent connections on ports 80/443 are limited. Kernel settings against SYN floods are written to /etc/sysctl.d/90-bipanel-ddos.conf.

Private networks, the server's own IP, the Whitelist, the Security Center IP whitelist and Cloudflare edge servers are never banned, and IPs that signed in successfully as an administrator or reseller in the last 24 hours are not banned automatically. The Cloudflare real IP option (on by default) uses the real address of visitors behind Cloudflare for banning. With a Cloudflare API token configured, you can also have a level change switch your Cloudflare zones to Under Attack mode. To lift a ban while the panel is down:

$ sudo bipanel ddos unban 203.0.113.7

Volumetric (Gbps-scale) attacks have to be stopped before they reach the server. For that, serve your domains through Cloudflare or use your provider's network protection.

#CrowdSec alongside Fail2Ban

From the CrowdSec page you can install the CrowdSec agent and its nftables bouncer as a component (native server only). The agent reads site access logs, sshd, Postfix/Dovecot, Pure-FTPd and panel login logs, and each source can be switched on or off. The page shows active decisions, alert history, IP lookup, manual bans, the allowlist, hub collections and console enrollment.

There are two ways to run it with Fail2Ban: both side by side (the default), or Fail2Ban stopped with the same services left to CrowdSec. In the second case Fail2Ban is restarted automatically if the CrowdSec agent or bouncer stops. Optionally, bipanel's DDoS and panel brute-force bans are shared with CrowdSec as decisions, so the IP is dropped on every port. For sites behind Cloudflare, CrowdSec decisions can also be enforced in Apache against the real visitor IP with a 403 (not in OpenLiteSpeed mode). Console commands:

$ sudo bipanel crowdsec unban 203.0.113.7
$ sudo bipanel crowdsec pause
$ sudo bipanel crowdsec resume

#Country blocking

The country database is DB-IP IP to Country Lite, downloaded monthly. Server-wide rules on the Country Blocking page are enforced with nftables: each rule works in Block or Allow only mode and applies to All ports, Web (80, 443), Email, SSH, FTP or Panel. Private networks, the server IP, the whitelists, administrator IPs from the last 24 hours and the allowlist always get through. If you do not confirm new rules in the panel within 90 seconds, the previous rules are restored. In an emergency, the first command removes server-wide blocking at once and the second lifts the lock so the saved rules are applied again:

$ sudo bipanel geoip off
$ sudo bipanel geoip on

Pro: on the Country Blocking page of the user panel, account owners set a block or allow-only rule per domain, with a custom 403 page. The rule runs at Apache virtual host level, so .htaccess cannot override it, and Let's Encrypt validation always gets through. It is not enforced in OpenLiteSpeed mode.

#Attack detection (Pro)

Attack Detection derives per-IP and per-domain behaviour from site access logs and keeps a baseline for each domain. It detects CMS login brute force, vulnerability scanning, credential stuffing, form spam bots and sudden traffic spikes. The default response is to ban (60 minutes, score 70 or higher); when an IP is caught again within 7 days, its ban is multiplied by four each time, up to 7 days. Traffic spikes are only observed by default. Search engine crawlers are verified by reverse DNS and exempted. Bans go through the DDoS protection ban system. The Attack Detection page in the user panel shows detections for the account's own domains, read only. You can also turn the feature off with sudo bipanel attack-detection off.

#Cloudflare Tunnel (Pro)

Cloudflare Tunnel publishes sites through Cloudflare without opening inbound ports on the server, and it is available only on a native server installation. You connect a Cloudflare API token (permissions: Account → Cloudflare Tunnel → Edit, Zone → DNS → Edit, and Zone → Zone → Read recommended), create or select a tunnel, and choose Publish through tunnel per domain; the panel then manages the ingress rule and the proxied CNAME record. The cloudflared connector runs as a systemd service and must be able to connect out on port 7844 (TCP/UDP).

#IP blocking in the user panel

Account owners can block a single IP or a CIDR range on all their domains or on one domain from the IP Blocker page. For panel login brute-force protection and two-factor authentication see panel security; for the web application firewall and the security advisor see security tools.