What are we building?

By the end, a CrowdSec agent runs alongside your Traefik, reading along with the access logs, detecting suspicious behavior based on scenarios (port scans, path probing, known CVE exploitation, login brute force) and putting attacker IPs on a block list. A bouncer – here as a Traefik plugin – enforces these decisions: a banned IP only gets 403 Forbidden at every one of your apps. Tested with CrowdSec v1.7.8, the Traefik bouncer plugin v1.6.0 and Traefik v3.7.

This is how the parts interlock:

• Agent + Local API (LAPI): reads the logs, evaluates them against the scenarios and manages the active bans (“decisions”). That’s the container we set up.
• Bouncer: asks the LAPI on every request “is this IP banned?” and blocks if yes. The Traefik bouncer runs as a plugin directly in the reverse proxy – no additional container.
• Community blocklist: CrowdSec reports (anonymized) detected attacks to the central network and gets a blocklist fed by all users back in return. IPs that were already flagged as malicious elsewhere are then banned at your place from the start. That’s the “collaborative” in the title.

Prerequisites

• A running reverse proxy with Traefik (the proxy network and the resolver le come from there) with at least one app behind it.
• Fail2ban for SSH protection – CrowdSec handles the HTTP layer here, not SSH.
• Basic knowledge of Docker Compose and a hardened server with an active firewall.

Step by step

Step 1: Enable Traefik’s access logs

CrowdSec can only detect what it sees – and it sees attacks via Traefik’s access logs. They’re off by default. Open the compose.yaml of your Traefik (from the Traefik tutorial, folder ~/traefik) and add these three lines to the command block:

      - "--accesslog=true"
      - "--accesslog.filepath=/var/log/traefik/access.log"
      - "--accesslog.format=json"

The JSON format is important – the CrowdSec parsers expect it that way. So that both Traefik (writing) and CrowdSec (reading) can reach the same file, you put it on a fixed host path. Add to Traefik’s volumes block:

      - /var/log/traefik:/var/log/traefik

Create the directory on the host and restart Traefik:

sudo mkdir -p /var/log/traefik
cd ~/traefik && docker compose up -d

Call one of your apps once and check that lines arrive:

tail -n 2 /var/log/traefik/access.log

You should see JSON lines with "ClientHost", "RequestPath" and "DownstreamStatus". If the file stays empty, the path in the volume is wrong, or simply no request has come in yet.

Step 2: Set up the CrowdSec container

CrowdSec gets its own folder. First generate a bouncer key – the Traefik bouncer later authenticates with it at the LAPI:

mkdir -p ~/crowdsec && cd ~/crowdsec
openssl rand -hex 32

Copy the output; it’s used in two places shortly. Create the acquisition – it tells CrowdSec which file with which log type to read:

# ~/crowdsec/acquis.yaml
filenames:
  - /var/log/traefik/access.log
labels:
  type: traefik

Now the compose.yaml. Replace YOUR_BOUNCER_KEY with the generated key:

services:
  crowdsec:
    image: crowdsecurity/crowdsec:v1.7.8
    container_name: crowdsec
    environment:
      COLLECTIONS: "crowdsecurity/traefik"
      BOUNCER_KEY_TRAEFIK: "YOUR_BOUNCER_KEY"
      GID: "1000"
    volumes:
      - ./acquis.yaml:/etc/crowdsec/acquis.d/traefik.yaml:ro
      - /var/log/traefik:/var/log/traefik:ro
      - crowdsec-db:/var/lib/crowdsec/data/
      - crowdsec-config:/etc/crowdsec/
    networks: [proxy]
    restart: unless-stopped

volumes:
  crowdsec-db:
  crowdsec-config:

networks:
  proxy:
    external: true

What matters here:

• COLLECTIONS: crowdsecurity/traefik installs the matching collection of parsers and scenarios for Traefik logs on the first start (including the HTTP base scenarios).
• BOUNCER_KEY_TRAEFIK registers a bouncer named TRAEFIK with your key right at startup – that saves the detour via cscli bouncers add.
• GID: "1000" runs the CrowdSec process under this group. 1000 is the usual default for the first user; if Traefik runs as root, the access.log is usually world-readable and the GID doesn’t matter anyway. If it’s set more tightly, check with ls -l /var/log/traefik/access.log and enter the GID of the file’s group.
• The log is mounted read-only (:ro). CrowdSec is on the proxy network so the Traefik bouncer can reach the LAPI at crowdsec:8080 later.

Start the container and check that everything takes effect:

docker compose up -d
docker exec crowdsec cscli collections list

The Traefik collection and the HTTP scenarios should appear as enabled:

 crowdsecurity/base-http-scenarios    ✔️  enabled
 crowdsecurity/http-cve               ✔️  enabled
 crowdsecurity/traefik                ✔️  enabled

Check that the community blocklist is active – it costs nothing and is half the benefit of CrowdSec:

docker exec crowdsec cscli capi status

You can successfully interact with Central API (CAPI)
Sharing signals is enabled
Pulling community blocklist is enabled
Pulling blocklists from the console is enabled

Pulling community blocklist is enabled confirms that you receive the collective block list of the CrowdSec community – attackers that stood out elsewhere are already banned at your place before they even try.

Step 3: Add the Traefik bouncer

Now the part that enforces the bans. The bouncer is a Traefik plugin and consists of two additions to your Traefik: load the plugin and define a middleware that acts on all apps.

Load the plugin by adding to the command block of ~/traefik/compose.yaml:

      - "--experimental.plugins.bouncer.modulename=github.com/maxlerebourg/crowdsec-bouncer-traefik-plugin"
      - "--experimental.plugins.bouncer.version=v1.6.0"
      - "--entrypoints.websecure.http.middlewares=crowdsec@file"

The last line attaches the bouncer middleware globally to the websecure entrypoint – so every HTTPS request to every app runs through the bouncer, without you touching each app individually. You define the middleware itself via the file provider.

Create the middleware (path adapted to your existing file provider):

# ~/traefik/dynamic/crowdsec.yaml
http:
  middlewares:
    crowdsec:
      plugin:
        bouncer:
          enabled: true
          crowdsecMode: stream
          crowdsecLapiScheme: http
          crowdsecLapiHost: crowdsec:8080
          crowdsecLapiKey: "YOUR_BOUNCER_KEY"

crowdsecLapiKey is the same key as in step 2 – the bouncer identifies itself with it at the LAPI. With crowdsecMode: stream the bouncer pulls the block list completely in advance at a fixed interval and answers every request from the local cache – the mode recommended by the plugin, because it doesn’t load the LAPI on every request.

Make sure Traefik also sees the directory. If your existing file provider already uses a mounted dynamic directory, the new file is in it anyway – then there’s nothing to do here. If you create the directory anew, add it to Traefik’s volumes block:

      - ./dynamic:/etc/traefik/dynamic:ro

Restart Traefik so it downloads the plugin and loads the middleware:

cd ~/traefik && docker compose up -d
docker compose logs -f traefik

The log must show no ERR about the plugin or the middleware (Traefik v3 logs only errors at the default level – a quiet output is the good sign). Check from the CrowdSec side that the bouncer has connected:

docker exec crowdsec cscli bouncers list

 Name     IP Address  Valid  Last API pull         Type
 TRAEFIK  172.19.0.2  ✔️      2026-07-23T10:49:58Z  Crowdsec-Bouncer-Traefik-Plugin

A set Last API pull proves: the plugin talks to the LAPI.

Step 4: Arm it and test the ban

Call one of your apps – it should respond perfectly normally:

curl -s -o /dev/null -w "%{http_code}\n" https://YOUR_APP.YOUR_DOMAIN/

200

Now you test-ban an IP by hand and see whether the bouncer locks it out. Take your own public IP (curl -s https://ifconfig.me):

docker exec crowdsec cscli decisions add --ip YOUR_TEST_IP --duration 5m --reason "test"

After the wait, the banned IP only gets:

curl -s -o /dev/null -w "%{http_code}\n" https://YOUR_APP.YOUR_DOMAIN/

403

Lift the test ban again:

docker exec crowdsec cscli decisions delete --ip YOUR_TEST_IP

Step 5: Let it detect real attacks

The actual point: CrowdSec bans on its own, without you writing rules. As soon as a scanner probes your domain for paths (many 404 in a short time), the scenario crowdsecurity/http-probing kicks in. This is what a real, automatically detected ban looks like:

docker exec crowdsec cscli alerts list

 ID  value              reason                       country  as                      decisions
 4   Ip:109.250.21.197  crowdsecurity/http-probing   DE       8881 1&1 Versatel GmbH  ban:1

docker exec crowdsec cscli decisions list

 Source    Scope:Value        Reason                       Action  Country  AS
 crowdsec  Ip:109.250.21.197  crowdsecurity/http-probing   ban     DE       8881 1&1 Versatel GmbH

CrowdSec automatically enriches the ban with country and provider (AS). Besides the self-detected attacks, bans with the source lists:crowdsecurity/... appear here over time – that’s the community blocklist: IPs that already stood out negatively worldwide, you block before they hit you the first time.

Whoever prefers to see the bans graphically instead of in cscli tables enrolls the instance for free in the CrowdSec console (the enroll command is in “Maintenance & backups”). There the same decisions appear presented nicely:

The HTTP scenarios installed with the Traefik collection cover what real scanners try all day: probing non-existent paths (http-probing), searching for sensitive files and backdoors, path traversal and SQL injection/XSS probes, suspicious user agents of known scanners, as well as the exploitation of known CVEs (from the collection crowdsecurity/http-cve). Which scenarios are active is shown by docker exec crowdsec cscli scenarios list.

Whether CrowdSec reads your logs at all is shown by the metrics overview:

docker exec crowdsec cscli metrics

| Source                           | Lines read | Lines parsed |
| file:/var/log/traefik/access.log | 54         | 54           |

If it says Lines read: 0, no log is arriving – then back to step 1.

Step 6: Don’t lock yourself out

A false alarm against your own maintenance IP is annoying. Enter your fixed IP as trusted in the middleware – the bouncer then doesn’t even check it. Add to ~/traefik/dynamic/crowdsec.yaml under bouncer::

          clientTrustedIPs:
            - "YOUR_FIXED_IP/32"

If you did lock yourself out, one command lifts the ban immediately – and in an emergency you can always reach the server via the VNC console in the SCP:

docker exec crowdsec cscli decisions delete --ip YOUR_IP   # one IP
docker exec crowdsec cscli decisions delete --all           # all bans

When things go wrong

Maintenance & backups

• Keep scenarios current. CrowdSec’s strength is maintained detection rules – pull them regularly: docker exec crowdsec cscli hub update && docker exec crowdsec cscli hub upgrade. You bump the image (crowdsecurity/crowdsec) and the plugin version (v1.6.0) deliberately; read the release notes on major versions. CrowdSec develops briskly – a good candidate for regular version checks.

• Rotate the access log. Traefik’s /var/log/traefik/access.log otherwise grows unbounded. Set up a logrotate rule – mandatorily with copytruncate: this variant copies the file away and empties the original in place, instead of renaming it and creating a new one. Only this way does CrowdSec’s tail keep the file access (with rename/create it would lose the handle and read nothing anymore). Create /etc/logrotate.d/traefik:

  Ausgabe

  /var/log/traefik/access.log {
      daily
      rotate 7
      compress
      missingok
      notifempty
      copytruncate
  }

  After the truncate, CrowdSec reads on perfectly normally from the file that’s growing again – a restart of the container isn’t needed.

• fail2ban stays. Don’t remove fail2ban – it continues to protect your SSH access at the host level, while CrowdSec covers the web apps. Two tools, two responsibilities.

• Backups. What you must back up is above all your configuration: the folder ~/crowdsec (compose.yaml, acquis.yaml) and ~/traefik/dynamic/crowdsec.yaml with the bouncer key. Include them in your Restic backup. The block lists themselves are ephemeral and rebuild on their own – no backup needed.

• Optional: the CrowdSec dashboard. Whoever wants to see the attacks graphically enrolls the instance for free in the CrowdSec console (docker exec crowdsec cscli console enroll YOUR_ENROLL_KEY). The community blocklist runs without enrollment too.

• Integrate it into your monitoring. cscli metrics gives you numbers for the terminal; for continuous observation, CrowdSec provides a Prometheus endpoint (enable it in the config under prometheus:) that you can hang on your Grafana stack. Then you see bans by origin and scenario at a glance:

  

• Honest about the effort: After setup, CrowdSec runs largely on its own. Plan a hub upgrade and a look at cscli metrics and the container version once a month.

What are we building?

By the end, the security & setup overview of your Nextcloud shows no more warnings. Concretely, we build on the installation from part 1 and add: the missing HSTS security header via Traefik, a configured maintenance window, working email sending (for password resets and notifications), enforced two-factor authentication and brute-force protection that sees the real attacker IPs – the basis for Fail2ban.

Everything is tested against Nextcloud 34.0.1 behind Traefik v3.7 on Debian 13 with PHP 8.5. This is legwork, but exactly the legwork missing in 90% of all Nextcloud guides – and it makes the difference between “somehow online” and “properly operated”.

Prerequisites

• A running Nextcloud set up as in self-hosting Nextcloud (part 1): classic nextcloud image behind Traefik, with MariaDB, Redis and a cron sidecar. The container names from part 1 (nc-app, nc-db, nc-redis, nc-cron) and the Compose folder ~/nextcloud are the basis here.
• SSH access to the server and the command-line tool occ – we call it as in part 1 in the app container: docker exec -u www-data nc-app php occ <command>.
• A Traefik reverse proxy with the proxy network and the resolver le as in the tutorial reverse proxy with Traefik – we attach the security headers as a Traefik middleware.

docker exec -u www-data nc-app php occ status

Step by step

Step 1: Read the admin overview as a stock-take

Log in as administrator and open Administration settings → Overview. At the top is the “Security & setup warnings” section. Right after a standard installation it looks like this:

Nextcloud distinguishes three levels: yellow warnings (⚠, you should fix), blue notices (ℹ, usually optional) and silently passed checks. On our fresh instance there are three warnings and a few notices:

• ⚠ Maintenance window start is not set (step 2)
• ⚠ MIME-type migrations available (step 2)
• ⚠ HTTP headers – the Strict-Transport-Security header is missing (step 3)
• ℹ Email test – no mail server configured yet (step 4)
• ℹ Two-factor configuration – 2FA is available but not enforced (step 5)

You also get the same report on the command line – handy to check progress in between without clicking through the web interface:

docker exec -u www-data nc-app php occ setupchecks

The command outputs each check with ✓, ⚠ or ✗. We now work through exactly this list from top to bottom.

Step 2: Fix the two quick warnings

Two warnings are done with one command each.

Set the maintenance window. Nextcloud runs compute-intensive cleanup jobs once daily (previews, activities, calendar repeats). Without a defined time window they run at some point – even in the middle of the day. Set a start time when hardly anyone works. The value is a full hour in UTC; 1 sets the start to 01:00 UTC – the check afterwards reports the window from 1:00 to 7:00 UTC:

docker exec -u www-data nc-app php occ config:system:set maintenance_window_start --type=integer --value=1

To verify, the setup check afterwards confirms:

✓ Maintenance window start: Maintenance window to execute heavy background jobs is between 1:00 UTC and 7:00 UTC

Run MIME-type migrations. Occasionally Nextcloud learns new file types (e.g. for better icons and previews). This migration does not run automatically on updates because it can take a while on large instances. On a fresh cloud it’s done in seconds:

docker exec -u www-data nc-app php occ maintenance:repair --include-expensive

You see a list of repair steps performed (including Repair mime types). Afterwards the check reports Mimetype migrations available: None. Two fewer warnings.

Step 3: Set the HSTS security header via Traefik

The third warning is the most important: the Strict-Transport-Security header (HSTS) is missing. It instructs the browser to address this domain exclusively over HTTPS – even when someone types http:// or an attacker tries to redirect the connection. Without HSTS, a small time window for downgrade attacks stays open.

Because our Nextcloud sits behind Traefik, we set the header in the proxy, not in Nextcloud – that’s where it belongs, since Traefik terminates the TLS. In the compose.yaml of your Nextcloud (from part 1), add the middleware nc-secure and attach it to the router. Concretely, two places change in the labels block of nc-app.

First, extend the router line with nc-secure:

      - "traefik.http.routers.nc.middlewares=nc-dav,nc-secure"

Second, define the header middleware (right by the other nc-app labels):

      - "traefik.http.middlewares.nc-secure.headers.stsSeconds=15552000"
      - "traefik.http.middlewares.nc-secure.headers.stsIncludeSubdomains=true"

stsSeconds=15552000 is 180 days – the minimum value Nextcloud requires. Apply the change and reload only the app container:

docker compose up -d nc-app

After a few seconds, check from your own machine that the header is really delivered:

curl -sS -I https://cloud.YOUR_DOMAIN/ | grep -i strict-transport

You should see exactly this:

strict-transport-security: max-age=15552000; includeSubDomains

In the admin overview the HTTP-header warning thus turns green: “Your server is correctly configured to send security headers.” The remaining headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy …) Nextcloud delivers itself – only HSTS had to come from the proxy.

Step 4: Set up email sending

Without working mail sending, Nextcloud can send no password resets, no share notifications and no security warnings – and the “Email test” notice stays. We catch up on that.

Open Administration settings → Basic settings and scroll to the “Email server” section. Enter your mail provider’s credentials:

• Send mode: SMTP
• Encryption: SSL/TLS (port 465) or STARTTLS (port 587) – never unencrypted
• From address: e.g. cloud @ YOUR_DOMAIN
• Server address: host and port of your provider
• Authentication: enable and store username/password

At the top, under Personal information, enter an email address for your admin account (the test mail goes there). Then click “Send test email”. If the mail arrives, Nextcloud confirms it with a green message:

Step 5: Enforce two-factor authentication

A stolen password is the most common way accounts get taken over. A second factor (a time-based code from an authenticator app, TOTP) makes the password alone worthless. Nextcloud already brings the matching provider – we just have to enable it and make it mandatory.

First enable the TOTP app (it’s included):

docker exec -u www-data nc-app php occ app:enable twofactor_totp

Each user then sets up their second factor themselves – under Personal settings → Security → “TOTP (Authenticator app)”. On enabling, Nextcloud shows a QR code you scan with an app like Aegis, andOTP or Google Authenticator. Additionally, the app “Two-Factor Backup Codes” is recommended – the one-time codes save you if the phone is lost.

So that nobody “forgets” the safeguard, you enforce 2FA for the administrators. On the web you find that under Administration settings → Security → “Enforce two-factor authentication”, on the command line it works like this:

docker exec -u www-data nc-app php occ twofactorauth:enforce --on --group=admin

Step 6: Brute-force protection with real IPs – basis for Fail2ban

Nextcloud throttles failed logins out of the box: after several failed attempts it delays further requests from the same IP. But this protection stands and falls with Nextcloud seeing the real client IP – and not the internal IP of Traefik. That’s exactly what the TRUSTED_PROXIES setting from part 1 does.

Whether it works you see under Administration settings → Security in the “brute-force allow list” box (in the screenshot above). There stands your current, correctly recognized public IP:

Your current IP address is recognized as "YOUR_IP". This address is currently not throttled.

If a 172.x.x.x address from the Docker network appears there instead, TRUSTED_PROXIES isn’t taking effect – then the brute-force protection would lump all users together and, in doubt, ban Traefik itself. In that case, back to part 1, step 2/3.

Hard bans with Fail2ban. The built-in throttling only delays; whoever wants to really ban attackers combines Nextcloud with Fail2ban. Nextcloud logs every failed attempt in the JSON log – and thanks to TRUSTED_PROXIES with the real IP:

{"level":2,"time":"2026-07-18T08:14:05+00:00","remoteAddr":"203.0.113.47","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: USER (Remote IP: 203.0.113.47)"}

This log lives in the Nextcloud volume. You find the path on the host like this:

docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/var/www/html" }}{{ .Source }}{{ end }}{{ end }}' nc-app

Below it is the file data/nextcloud.log. At that you point a Fail2ban filter that matches on remoteAddr, plus a jail following the pattern from the Fail2ban tutorial. This way, after a few failed attempts, the attacker IP goes straight into the firewall – before the request even reaches Nextcloud.

Step 7: Check caching & PHP – the performance foundation

Finally, we make sure the performance basis is in place. Much of this part 1 already set up automatically via the REDIS_HOST variable – checking doesn’t hurt anyway, because this is exactly where a Nextcloud gets sluggish or snappy.

Nextcloud uses three cache roles. Check all three:

docker exec -u www-data nc-app php occ config:system:get memcache.local
docker exec -u www-data nc-app php occ config:system:get memcache.distributed
docker exec -u www-data nc-app php occ config:system:get memcache.locking

Expected:

\OC\Memcache\APCu
\OC\Memcache\Redis
\OC\Memcache\Redis

• Local cache (APCu): keeps frequently used data in the RAM of the PHP process – the most noticeable accelerator in everyday use.
• Distributed cache (Redis): shares cache data across processes, important once the app and cron containers interact.
• File locking (Redis): prevents two accesses from changing the same file simultaneously and corrupting it. The reason we built in Redis at all in part 1.

If the interplay fits, docker exec -u www-data nc-app php occ setupchecks reports the line ✓ Memcache: Configured. (Passed checks aren’t shown by the web overview – only warnings and notices appear there, which is why you check this via CLI.)

OPcache – PHP’s bytecode cache – is already sensibly preconfigured in the official nextcloud image (including opcache.interned_strings_buffer=32). So you don’t have to adjust anything here; the formerly notorious OPcache warning no longer appears at all with current images. You can check it if needed like this:

docker exec -u www-data nc-app php -i | grep opcache.interned_strings_buffer

With that, the overview is warning-free:

When things go wrong

Maintenance & backups

• Check the overview after every update. New Nextcloud versions bring new checks. After every upgrade take a look at Administration settings → Overview or run occ setupchecks – this way you catch new warnings early.
• Use the official security scan regularly. The Nextcloud Security Scan checks your domain from outside and assigns a grade. With HSTS and current versions, A/A+ is the realistic target; if the grade drops, an update is usually overdue.
• Keep an eye on second factors. Keep the backup codes separate from the phone. If a user loses their device, you remove their factor with occ twofactorauth:disable USER totp, after which they set it up anew.
• Clean up app passwords. Every connected client (desktop, phone) gets its own app password. Under Personal settings → Security you see all devices and can specifically revoke individual ones on loss.
• The hardening replaces no backup. All of this protects against foreign access, not against data loss. The consistent backup of a database dump and data directory stays mandatory – see the maintenance section in part 1 and backups with Restic. Honest about the effort: firmly plan the monthly update pass with a quick look at the overview – then your cloud stays green permanently.

What are we building?

By the end, Restic backs up your important data – app volumes, configurations, database dumps – end-to-end encrypted and deduplicated into a repository, ideally off-site (a second server or storage). You can restore individual files or whole snapshots at any time, automatically thin out old backups by a retention policy, and check integrity. Finally, everything runs automatically via a systemd timer and alerts you if a run fails to happen.

Tested with Restic 0.18 (the version from the Debian 13 package sources); upstream already has 0.19.x – how to update is in step 1. Restic always encrypts – there is no unencrypted repository.

Prerequisites

• A server (Debian 13) with the data you want to back up – e.g. the volumes and Compose files of your Docker apps.
• An off-site target for the backups. Restic speaks, among others:
  • SFTP – a second server or a storage box (easiest to start with),
  • S3-compatible – e.g. an object-storage bucket,
  • rclone – as a bridge to Backblaze B2, Google Drive and dozens more.
• Basic familiarity with the shell.

Step by step

Step 1: Install Restic

Restic is in the package sources and is updated with the system:

sudo apt update
sudo apt install -y restic

Check the version:

restic version

restic 0.18.0 compiled with go1.24.4 on linux/amd64

Step 2: Create the encrypted repository

A Restic repository is the encrypted storage location of your backups. It’s protected with a password – and this password does not belong in a script and not next to the repository. Put it in a file only root may read:

sudo install -d -m 700 /etc/restic
openssl rand -base64 32 | sudo tee /etc/restic/password > /dev/null
sudo chmod 600 /etc/restic/password

The openssl command generates a long random password and stores it under /etc/restic/password (the install command before it creates the directory, the chmod after it protects the file). Tell Restic via environment variables where the repository is and where the password is – here first an off-site target via SFTP:

export RESTIC_REPOSITORY="sftp:BACKUP_USER@YOUR_BACKUP_HOST:/backups/YOUR_SERVER"
export RESTIC_PASSWORD_FILE="/etc/restic/password"

Replace BACKUP_USER, YOUR_BACKUP_HOST and the path with your real target. If you want to practice locally first, use a folder instead: export RESTIC_REPOSITORY="/srv/restic-repo". The commands afterwards are identical – only the repository address differs.

You use other off-site targets via the same variable, only with a different prefix:

• S3-compatible: s3:https://ENDPOINT/BUCKET – plus the credentials as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the environment (or in the environment file from step 7).
• rclone: rclone:REMOTE:path – the bridge to Backblaze B2, Google Drive and many more, once you’ve set up the rclone remote.

No matter which backend: encryption, deduplication and all the following commands stay the same.

Now initialize the repository (the example output shows the local practice repository – with the SFTP target, your sftp: address appears there instead):

restic init

created restic repository d29613209a at /srv/restic-repo

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Step 3: The first backup

Back up the directory with your data. The --tag helps with filtering later:

restic backup /root/backup-demo --tag demo

no parent snapshot found, will read all files

Files:           3 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added to the repository: 2.002 MiB (2.001 MiB stored)

processed 3 files, 2.000 MiB in 0:00
snapshot f16c6ffd saved

On the second run, Restic’s strength shows: it only backs up the changes (deduplication). If a file changes and you back up again:

using parent snapshot f16c6ffd
Files:           0 new,     1 changed,     2 unmodified
Added to the repository: 1.820 KiB (1.121 KiB stored)
processed 3 files, 2.000 MiB in 0:00
snapshot 0bb5e679 saved

Instead of 2 MiB again, only 1.1 KiB land in the repository – just the changed part.

What belongs in the backup? For Docker apps that’s three things – recipe, payload, DB:

• Compose files (your “recipe”) and .env: small but indispensable for rebuilding the stack.
• Bind mounts (./data:/…) live directly in the project folder – you back those up right along. Named volumes you’ll find under /var/lib/docker/volumes/<name>/_data; include the path.
• Databases never as a live file – a backup mid-write is potentially unusable. Instead create a consistent dump (pg_dump/mariadb-dump) and back that up (see step 7).

You exclude the unnecessary:

restic backup /opt --tag apps --exclude='*.log' --exclude='**/cache/**'

Step 4: Restore

A backup is only as good as its restore. First list the snapshots:

restic snapshots

ID        Time                 Host                  Tags        Paths              Size
---------------------------------------------------------------------------------------------
f16c6ffd  2026-07-16 20:52:35  v2200000000000000000  demo        /root/backup-demo  2.000 MiB
0bb5e679  2026-07-16 20:52:36  v2200000000000000000  demo        /root/backup-demo  2.000 MiB
---------------------------------------------------------------------------------------------
2 snapshots

Restore a complete snapshot to a target directory (use latest for the newest or a specific ID):

restic restore latest --target /root/restore-test

restoring snapshot 0bb5e679 of [/root/backup-demo] ... to /root/restore-test
Summary: Restored 5 files/dirs (2.000 MiB) in 0:00

If you only need one file, there are two ways – restore that specific path:

restic restore latest --target /tmp/wiederher --include /root/backup-demo/config.yaml

… or stream the file directly to standard output, without any detour:

restic dump latest /root/backup-demo/config.yaml > /tmp/config.yaml

To browse, you can even mount the repository as a filesystem (restic mount /mnt/backup, requires FUSE) and copy out what you need in the file manager – handy when you no longer know which snapshot the version you’re looking for is in.

Step 5: Check integrity

check verifies that the repository’s structure is intact:

restic check

load indexes
check all packs
check snapshots, trees and blobs
[0:00] 100.00%  2 / 2 snapshots
no errors were found

That checks the metadata, but not the actual data. So regularly read part of the real data along with it – e.g. 10% per run, i.e. everything over the course of weeks:

restic check --read-data-subset=10%

Step 6: Prune with a retention policy

Without pruning, the repository grows forever. forget applies a retention policy, --prune frees the storage of the removed snapshots:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Applying Policy: keep 7 daily, 4 weekly, 6 monthly snapshots
keep 2 snapshots:
2 snapshots

This keeps the last 7 daily, 4 weekly and 6 monthly snapshots – a good default. The tiers interlock: fine resolution for the recent past (one per day), coarser the further back (one per week, then one per month). So, if in doubt, you can get close to the desired state without the repository growing unbounded. Older snapshots drop off automatically. --prune is the expensive part (it repacks data); on large repositories you often run it only once or twice a week, not on every backup.

Step 7: Automate everything (systemd timer)

A backup you have to start by hand is one you forget. Put the credentials in an environment file (so the service knows them):

# /etc/restic/restic.env
RESTIC_REPOSITORY=sftp:BACKUP_USER@YOUR_BACKUP_HOST:/backups/YOUR_SERVER
RESTIC_PASSWORD_FILE=/etc/restic/password

Then a wrapper script /usr/local/bin/restic-backup.sh – it first dumps the database (PostgreSQL example), backs up, prunes and finally reports success to Uptime Kuma (the push monitor as a “dead man’s switch”):

#!/usr/bin/env bash
set -euo pipefail
# 0) Ensure the target directory for the dump (otherwise the first run aborts)
mkdir -p /opt/dumps
# 1) Dump the database consistently (never back up the live DB file)
docker exec YOUR_DB_CONTAINER pg_dumpall -U postgres > /opt/dumps/db.sql
# 2) Backup
restic backup /opt/apps /opt/dumps --tag auto
# 3) Prune (retention)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
# 4) Report success to Uptime Kuma
curl -fsS "https://status.YOUR_DOMAIN/api/push/YOUR_TOKEN?status=up&msg=restic+OK" > /dev/null

sudo chmod 700 /usr/local/bin/restic-backup.sh

The service loads the environment file and runs the script – /etc/systemd/system/restic-backup.service:

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/restic.env
ExecStart=/usr/local/bin/restic-backup.sh

And the timer /etc/systemd/system/restic-backup.timer starts it nightly:

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true catches up a missed run (e.g. because the server was off at night) on the next start. Enable it:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer

Check with systemctl list-timers restic-backup.timer when the next run is due.

Step 8: Rehearse the worst case once

A backup you’ve never restored is just a hope. So deliberately run through a complete restore once – ideally on a different or freshly set-up server, so you also need the credentials (repository address and password) under real conditions:

export RESTIC_REPOSITORY="sftp:BACKUP_USER@YOUR_BACKUP_HOST:/backups/YOUR_SERVER"
export RESTIC_PASSWORD_FILE="/etc/restic/password"
restic snapshots
restic restore latest --target /tmp/dr-test

Then compare samples with the original (diff, file hashes) and boot the app from the restored data as a test. Only once that works do you know your backup holds up in an emergency – and that you’ll remember the procedure when it really counts.

When things go wrong

Maintenance & backups

• Test restores regularly – that’s the single most important point. A backup you’ve never restored is not a backup but a hope. Schedule a test restore into an empty directory monthly.
• 3-2-1 rule: at least 3 copies, on 2 different media, of which 1 is off-site. Restic covers the off-site piece – but “off-site” really means a different provider/location, not the same data center.
• Monitor backups: without monitoring, you only notice a dead backup in an emergency. The push call from step 7 to Uptime Kuma raises the alarm when a run fails to happen.
• Check integrity: run restic check --read-data-subset regularly so silent bit rot is caught before you need the data.
• Password/key management: keep the repository password separate from the server. For individual clients you can assign additional passwords with restic key add without sharing the main password.

What are we building?

By the end, Fail2ban 1.1 on your Debian 13 monitors the SSH logins and, after too many failed attempts, bans the attacking IP for a defined time – via a firewall rule. Your own IP is on a whitelist so this never hits you. You can view bans, set them manually and lift them again.

Prerequisites

• A hardened server (key login) with an active firewall
• Your own public IP – find it e.g. via wieistmeineip.de or curl -s ifconfig.me from your local machine

Step by step

Before we configure, three terms that explain the whole tool:

• Filter – a pattern that detects a “failed login” in the log (for SSH, Fail2ban brings this ready-made).
• Jail – connects a filter with a log source and the rules “how often in what time frame”. The sshd jail monitors the SSH logins.
• Action – what happens when it’s exceeded: by default a firewall rule that blocks the IP for bantime.

In short: filter detects failed attempts → jail counts them → action bans. Everything you configure below is one of these three knobs.

Step 1: Install Fail2ban

sudo apt update
sudo apt install -y fail2ban

Check the version:

fail2ban-client --version

Fail2Ban v1.1.0

Step 2: Your own configuration in jail.local

Create the file:

sudo nano /etc/fail2ban/jail.local

[DEFAULT]
# How long the ban lasts
bantime = 1h
# Time window in which the failed attempts count
findtime = 10m
# This many failed attempts are allowed, then a ban
maxretry = 5
# Your own IP(s) – will NEVER be banned
ignoreip = 127.0.0.1/8 ::1 YOUR_OWN_IP

[sshd]
enabled = true

Line by line:

• bantime = 1h – ban duration. For stubborn cases, see the escalation in step 5.
• findtime + maxretry – “5 failed attempts within 10 minutes → ban”.
• ignoreip – the most important line: enter your own IP here so you don’t lock yourself out. If you have a changing IP at home, better use access via a fixed point (a VPN later) instead of a broad allowance.
• [sshd] enabled = true – activates the SSH jail.

Step 3: Start and enable the service

sudo systemctl enable --now fail2ban

enable --now starts the service immediately and ensures it runs again automatically after a reboot. Check that it runs cleanly:

sudo systemctl status fail2ban

You should see active (running). After every change to jail.local, reload the configuration with sudo systemctl reload fail2ban.

Step 4: Check the status

This is how you see which jails are active:

sudo fail2ban-client status

Status
|- Number of jail:	1
`- Jail list:	sshd

And the details of the SSH jail:

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- Journal matches:	_SYSTEMD_UNIT=ssh.service + _COMM=sshd
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:

The Journal matches line confirms that Fail2ban reads the systemd journal. Currently banned rises as soon as someone gets it wrong too often.

Step 5: Manage bans – and escalate them

Manually unban an IP (e.g. when a colleague mistyped):

sudo fail2ban-client set sshd unbanip 203.0.113.45

Ban an IP immediately:

sudo fail2ban-client set sshd banip 203.0.113.45

Against especially stubborn attackers, an escalating ban time pays off: whoever comes back is banned for longer. Add to the [DEFAULT] block:

bantime.increment = true
bantime.maxtime = 1w

With that, Fail2ban doubles the ban time each time the same IP reoffends – up to a maximum of one week. After the change, sudo systemctl reload fail2ban.

When things go wrong

Maintenance & backups

• Keep an eye on bans: sudo fail2ban-client status sshd shows at any time how many IPs are currently banned. A look at the journal (journalctl -u fail2ban) shows the history.
• More jails: as soon as services with their own login are added (e.g. a web app), you can activate matching jails – following the same pattern as [sshd].
• Back up jail.local: your configuration is quickly restored but belongs in the backup of your server configuration.
• Outlook CrowdSec: Fail2ban protects your host based on your logs. The modern successor CrowdSec later adds collaborative intrusion prevention (shared block lists) to this – we build it in a dedicated recipe once the reverse proxy is up. To get started, Fail2ban is exactly right.

With that, the security foundation is complete: key login, two firewall layers (UFW + netcup firewall), automatic updates and active brute-force protection. Your server is now not just set up, but solidly secured.

What are we building?

In the netcup SCP we build a network firewall from composable policy templates: a base template (that every server needs), one for SSH, and one for web (HTTP/HTTPS). You assign these building blocks to your server as needed – a web server gets base + SSH + web, a server without a website only base + SSH. By the end, everything inbound is blocked except what you deliberately allow.

A netcup-specific detail makes the difference: for UDP the firewall works statelessly – which is why services like DNS and NTP need their own inbound rule, otherwise they suddenly get stuck. Why that is and how the base template solves it is shown in step 2.

Prerequisites

• A netcup server, e.g. your first VPS.
• Your SCP credentials (customer number + SCP password from the netcup welcome email – different from your SSH login).
• Clarity about your SSH port: the default is 22, and it stays that way when hardening SSH. If you changed it elsewhere, use your real port – otherwise you lock yourself out when activating.

Step by step

Step 1: Open Firewall Policies in the SCP

Log into the Server Control Panel and open the Firewall Policies menu item at the top. Here you create reusable rule sets (“policies”) – independent of the individual server. You only assign them later.

Step 2: Build the base template

Click Create firewall policy, give it the name Serverküche Base and, via Add rule, create these four rules – all INBOUND and ACCEPT:

Two things that make the difference here:

• DNS/NTP via the Src Port, not the destination port. Your server queries DNS/NTP (outbound); the reply comes back from port 53 or 123. Because UDP is stateless, you need this inbound rule – otherwise there’s no name resolution and no time synchronization, even though “everything else” seems to work.
• Never forget ICMPv6. Without Neighbor Discovery, IPv6 breaks completely. ICMP (v4) on top is useful for ping and path MTU discovery. netcup’s default policy “Ping allow” does already cover ICMP – it’s deliberately in the base template again so your foundation stays complete even if you ever remove the netcup defaults.

Step 3: Small building blocks for SSH and web

Instead of one big rule monolith, you create atomic templates that you freely combine. Create two more policies following the same pattern:

• Serverküche SSH – one rule: INBOUND, TCP, ACCEPT, destination port 22.
• Serverküche Web – two rules: INBOUND, TCP, ACCEPT, destination port 80 and 443.

The gain: the base rules appear only once, not duplicated in every policy. If a service is added later (e.g. a mail server or WireGuard), you build another small template for it and plug it in – without touching the existing ones.

Step 4: Assign templates to the server

Switch to Server → your server → “Firewall” tab and click Edit firewall policies. Move the appropriate ones from Available firewall policies to Selected: for a web server Serverküche Base + Serverküche SSH + Serverküche Web.

Confirm with Apply and then Save. Check that the “Firewall active” switch is turned on. The assigned rules now appear in the list – together with netcup’s default policies (more on those below).

Step 5: Ready-made templates for common services

Exactly following the pattern from step 3, here are ready-made templates for the most common self-hosting services. Each is its own small template, all rules are INBOUND and ACCEPT. Build only the ones you really need and plug them, as in step 4, into Serverküche Base + Serverküche SSH.

Mail server (mailcow & co.)

Two things that additionally belong to a mail server:

• Web UI and certificates: mailcow needs 80/443 for the web interface and the Let’s Encrypt retrieval – just assign the Serverküche Web template along with it.
• Enable outbound SMTP: a mail server must be able to deliver on port 25 outbound. netcup blocks that with the default policy “netcup Mail block” – you have to remove it on the server (see “When things go wrong”). And without a correct PTR/reverse-DNS entry your mails land in spam.

WireGuard VPN

51820 is the usual default – use the value from your ListenPort. Only this one inbound rule is needed; the replies to the clients go out outbound.

OpenVPN

The default is UDP 1194. The TCP rule only if you deliberately run OpenVPN over TCP (some additionally put it on TCP 443 to get through restrictive foreign networks) – otherwise leave it out.

Zabbix monitoring

Here it depends on the server’s role:

The Zabbix server additionally needs 80/443 for the web frontend (Serverküche Web). If you run active checks, the agent connects outbound to the server on 10051 – for that, no inbound rule is needed on the agent host.

Checkmk

In the default pull mode, the Checkmk server fetches the data actively – so it connects outbound to 6556 of the agents. Inbound, therefore, only the monitored host needs port 6556. The Checkmk server itself gets by with 80/443 (Serverküche Web); 8000 and 6557 only if you use push mode or distributed monitoring.

Coturn / TURN server (Nextcloud Talk, Matrix)

The large UDP relay range is the default – the actual audio/video streams run over it. You can narrow it in the coturn configuration (min-port/max-port) and then set the firewall rule to the same, smaller range.

Your own DNS server (AdGuard Home, Pi-hole, Unbound)

Careful, this is exactly the opposite direction to the base template: there Src 53 allows the replies to your own DNS queries; here Dst 53 allows the queries of foreign clients to your DNS server. Both exist side by side without problems.

Remote database access (emergency only)

When things go wrong

Maintenance & backups

• Test access after every change. Firewall rules are the classic way to lock yourself out. Keep a second session open, check a new connection, only then finish.
• New services = new template. If you later need another port (game server, WireGuard VPN over UDP, database), create a small template of your own and assign it additionally. The existing building blocks stay untouched.
• Mind the order. netcup evaluates the rules top to bottom; the first matching rule wins. For pure ACCEPT rules that doesn’t matter – but as soon as you use your own DROP rules, watch the order relative to the ACCEPTs.
• Know netcup’s default policies. “netcup Mail block” (outbound SMTP on ports 25/465/587 blocked) and “netcup Ping allow” are predefined. Via Restore default policies you can, in an emergency, get back to a known, working baseline if you locked yourself out with your own rules – together with the VNC console, your second safety net.