Webdienste hinter reverse proxy

[David G.]

Hallo,

ich weiß, dass das Thema hier schon öfters angesprochen wurde. Idr um den iobroker von außen erreichbar zu machen.

Darauf zielt meine Frage aber nicht ab, dort nutze ich ausschließlich ein VPN.

Ist ein reverse proxy "genug" Absicherung um ein paar Docker Container ohne sensible Daten online zu stellen?

Also kein Passwortmanager oder nextcloud mit all meinen Daten.

Mit fail2bann oder crowdsec bin ich bisher gescheitert es ans Laufen zu bekommen in meinem Setup....

[OliverIO]

@david-g

ich kopiere dir mal meine docker-compose/stacks konfiguration für netcloud.
das alles läuft im hostmode
fail2ban verwaltet den firewall auf dem hostrechner
die konfiguration des proxys erfolgt rein nur durch die einträge in der dockercompose mit VIRTUAL_HOST
auch lets encrypt wird ebenso konfiguriert

• nginx-proxy ist der reverseproxy

• letsencrypt sorgt dafür, das regelmäßig das Zertifikat erneuert wird

• mysql ist für nextcloud zuständig

• nextcloud-app ist nextcloud selbst. hier hab ich mir allerdings ein eigenes dockerfile geschrieben, das das standard image mit ein paar plugins erweitert

• fail2ban sorg für zusätzliche absicherung das alle requests, die nicht zulässige requests senden dann für 1 Tag gebannt werden

• linklist ist ein webserver der nur intern abgerufen werden kann (da sammle ich alle links zu meinen internen diensten/admin-seiten/etc.)

• nginx-proxy ist der reverseproxy

• letsencrypt sorgt dafür, das regelmäßig das Zertifikat erneuert wird

• mysql ist für nextcloud zuständig

• nextcloud-app ist nextcloud selbst. hier hab ich mir allerdings ein eigenes dockerfile geschrieben, das das standard image mit ein paar plugins erweitert

• fail2ban sorg für zusätzliche absicherung das alle requests, die nicht zulässige requests senden dann für 1 Tag gebannt werden

• linklist ist ein webserver der nur intern abgerufen werden kann (da sammle ich alle links zu meinen internen diensten/admin-seiten/etc.)

version: '3'  

services:

  nginx-proxy:
    image: jwilder/nginx-proxy:alpine
    labels:
      - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true"
    container_name: nextcloud-proxy
    networks:
      nextcloud_network:
   
    ports:
      - 80:80
      - 443:443
    volumes:
      - /home/iobroker/docker/volume/nextcloud/nginx/log:/var/log/nginx
      - /home/iobroker/docker/volume/nextcloud/nginx/vhost.d:/etc/nginx/vhost.d:rw
      - /home/iobroker/docker/volume/nextcloud/nginx/html:/usr/share/nginx/html:rw
      - /home/iobroker/docker/volume/nextcloud/nginx/certs:/etc/nginx/certs:ro
      - /home/iobroker/docker/volume/nextcloud/nginx/myconf/mynginx.conf:/etc/nginx/conf.d/my_proxy.conf:ro
      - /home/iobroker/docker/volume/nextcloud/nginx/myconf/nginx.tmpl:/app/nginx.tmpl:ro
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro

    restart: unless-stopped
  letsencrypt:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: nextcloud-letsencrypt
    depends_on:
      - nginx-proxy
    networks:
      - nextcloud_network
    volumes:
      - /home/iobroker/docker/volume/nextcloud/nginx/vhost.d:/etc/nginx/vhost.d:rw
      - /home/iobroker/docker/volume/nextcloud/nginx/html:/usr/share/nginx/html:rw
      - /home/iobroker/docker/volume/nextcloud/nginx/certs:/etc/nginx/certs:rw
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    restart: unless-stopped

  mysql:
    image: mariadb
    container_name: nextcloud-mysql
    networks:
      - nextcloud_network
    volumes:
      - /home/iobroker/docker/volume/nextcloud/mysql:/var/lib/mysql
      - /etc/localtime:/etc/localtime:ro
    environment:
      - MYSQL_ROOT_PASSWORD=mysql
      - MYSQL_PASSWORD=mysql
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
    restart: unless-stopped

  nextcloud-app:
    image: nextcloud-extended-oliver:23
    container_name: nextcloud-app
    networks:
      - nextcloud_network
    depends_on:
      - letsencrypt
      - nginx-proxy
      - mysql
    volumes:
      - /home/iobroker/docker/volume/nextcloud/app/html:/var/www/html
      - /home/iobroker/docker/volume/nextcloud/app/config:/var/www/html/config
      - /home/iobroker/docker/volume/nextcloud/app/custom_apps:/var/www/html/custom_apps
      - /home/iobroker/docker/volume/nextcloud/app/data:/var/www/html/data
      - /home/iobroker/docker/volume/nextcloud/app/themes:/var/www/html/themes
      - /etc/localtime:/etc/localtime:ro
    environment:
      - VIRTUAL_HOST=meinewebsite.example.org
      - LETSENCRYPT_HOST=meinewebsite.example.org
      - LETSENCRYPT_EMAIL=email@example.org
      - PHP_MEMORY_LIMIT=3000M      
    restart: unless-stopped
    
  fail2ban:
    container_name: fail2ban
    image: crazymax/fail2ban:latest
    restart: always
    network_mode: host
    security_opt:
      - no-new-privileges:true
    cap_add:
      - NET_ADMIN
      - NET_RAW
    volumes:
      - /var/log/docker:/var/log/docker
      - /home/iobroker/docker/volume/nextcloud/fail2ban/data:/data
      - /home/iobroker/docker/volume/nextcloud/fail2ban/jail.local:/etc/fail2ban/jail.local
      - /home/iobroker/docker/volume/nextcloud/nginx/log:/var/log/nginx
      - /home/iobroker/docker/volume/nextcloud/app/data/nextcloud.log:/var/log/nextcloud/nextcloud.log

    environment:
      - TZ=Europe/Berlin
      # - F2B_LOG_LEVEL=DEBUG
      - F2B_DB_PURGE_AGE=1d # Age at which bans should be purged from the database
      - F2B_IPTABLES_CHAIN=DOCKER-USER # Specifies the iptables chain to which the Fail2Ban rules should be added 
    
  linklist:
    image: nginx:alpine
    container_name: linklist
    networks:
      - nextcloud_network
    depends_on:
      - nginx-proxy
    volumes:
      - /home/olinuc/projects/linklist/output/:/usr/share/nginx/html:ro
      - /home/iobroker/docker/volume/linklist/nginx/conf.d/:/etc/nginx/conf.d:ro
      - /etc/localtime:/etc/localtime:ro

    environment:
      - VIRTUAL_HOST=links
    restart: unless-stopped

networks:
  nextcloud_network:

[David G.]

@oliverio sagte in Webdienste hinter reverse proxy:

fail2ban verwaltet den firewall auf dem hostrechner

Obwohl es im docker läuft?

Fail2ban ist deine einiger Schutz neben dem Reverse Proxy?
Der Hostmode lässt die Container ja in dein normales Netz?

Ich lege mir jeden Container einzeln mit einer docker compose in portainer an.

[OliverIO]

@david-g
ja
deswegen benötigt der container auch die administrativrechte
- NET_ADMIN
- NET_RAW
und
security_opt:
- no-new-privileges:true

https://github.com/crazy-max/docker-fail2ban
mit dem einen recht darf der container direkt mit dem netzwerktreiber interagieren
mit dem anderen darf er direkt das netzwerk lesen

Fail2ban ist deine einiger Schutz neben dem Reverse Proxy?

1. einmal sind nur die beiden ports 80 und 443 zugelassen und werden an den reverseproxy weitergeleitet
2. von aussen ist auch nur der nextcloud server sichtbar, alle anderen ports werden ja durch den reverseproxy abgelehnt und werden dann nach 3 fehlversuchen gebannt
3. fail2ban bearbeitet die firewall des host rechners um dann einzelne ip adressen nicht mehr durchzulassen
4. nextcloud ist software die auch dazu gedacht ist offen im internet zu laufen, daher sind dort die audits auch entsprechend hoch.
5. wenn jemand diese ganzen hürden überwindet, muss er noch in der lage sein code in den container hineinzubringen und ausführen zu lassen.
6. ich denke nicht das ich ein so hohes angriffsziel bin, das jemand den nerv hat diese ganzen hürden zu überwinden. ausschließen kann man es nicht. diese installation läuft jetzt seit 2021

ich habe auch schon mal honeypots laufen lassen. die angriffe sind in der regel gescriptet und greifen allgemeine lücken an (ssh, wordpress, etc). die meisten geben selbst schon nach dem ersten versuch auf.

[OliverIO]

@david-g sagte in Webdienste hinter reverse proxy:

Ich lege mir jeden Container einzeln mit einer docker compose in portainer an

ich habe das ebenso für die meisten dienste
aber mit docker-compose kannst du services schnüren mit zueinander gehörenden containern

mein haupt iobroker besteht aber schon aus 2 container 1xiobroker 1xredis

[David G.]

@oliverio

Dann probiere ich es mal für mich umzuformulieren.

• Ich kann fail2ban mit deinem Code (Teilausschnitt) installieren.
  Da es auf den Host zugreift, bekommt es jede Anfrage mit die nginx an eine interne IP des Hosts weiterleitet.

• Auf dem Host iptables installieren falls nicht vorhanden.

Als volumes für nginx und fail2ban sollte ja dann ```
home/iobroker/docker/volume/nextcloud/nginx/log:/var/log/nginx

(mit meinem Pfad) ausreichen

[OliverIO]

@david-g

ja
fail2ban läuft so,das es das access log des nginx mitliest,
daher ist als volume das auch im fail2ban sichtbar
und dann mit dem firewall des hosts spricht und regeln hinzufügt bzw nach einiger zeit auch wieder löscht.

ja fail2ban arbeitet mit iptables alternativ musst du schauen, aber bei mir funktioniert es mit iptables

hier eine kleine erklärung auf deutsch
https://wiki.ubuntuusers.de/fail2ban/ oder
https://github.com/fail2ban/fail2ban

welche pfade als volumes sinnvoll sind. lies das am besten in der dokumentation zum jeweiligen image nach. du findest die über die suche auf dockerhub

[BananaJoe]

@david-g du kannst zusätzlich die Webseite auch noch per Geo-IP-Blocking absichern.

Ich habe leider nur eine Anleitung für den Apache2,
die ist zwar für Ubuntu 20.04, hat neulich aber unter 24.04 noch genauso funktioniert:
https://znil.net/index.php?title=Apache2_Ubuntu_20.04_GeoIP_Blocking_einrichten

Ich nehme an für nginx wird es da auch Anleitungen geben.
Dann kannst du z.B. einstellen das eine Webseite nur aus Deutschland erreichbar ist.
Die "Angriffe" bzw. die Suche nach Lücken nimmt dann doch erheblich ab.

Je nach Umgebung mache ich das Geo-IP Blocking (oft auch Country-Blocking genannt) schon auf der Firewall bei der Portfreigabe.

Das kann ein Problem bei Lets Encrypt-Zertifikaten sein - wenn die USA geblockt ist kann er sich von dort auch keine Zertifikate holen. Das umgehe ich auf 2 Arten (je nach Bedarf)

• Ich bin bei IONOS und dort kann man per API auf die DNS-Einträge der Domänen zugreifen. Ich fordere Zertifikate dann per DNS-Challenge statt per http-Challenge ab.
• Ich erneuere das Zertifikat im Standalone-Modus. Dabei macht der certbot dann seinen eigenen Webserver auf. Per Pre und Post Paramater hält der dann den Apache solange an.

[David G.]

Ich habe es jetzt erfolgreich am laufen.

Fail2ban läuft lokal und der npm samt Webdiensten im Docker.

Denkt ihr es macht Sinn, das auf 2 VMs aufzuteilen? Falls warum auch immer die von außen zugängliche VM von außen kompromitiert wird.

Also
VM1 Fail2ban mit npm
VM2 mit Docker und den Webdiensten.