Authelia mit internem NGINX Reverse Proxy von Synology

[update-freak]

Hi zusammen,

bin zuletzt auf EmulatorJS gestoßen: https://www.synology-forum.de/threa...-uebers-netzwerk-spielen.121289/#post-1129492
Leider gibt es keine Möglichkeit sich einzuloggen und damit den öffentlichen Zugang zu schützen, wenn ich es über Reverse Proxy verfügbar mache.

DIes soll mit Authelia (https://github.com/authelia/authelia) möglich sein.
Man liest oftmals Authelia in zusammenhang mit NGINX (oder auch SWAG oder Treafik).

Derzeit verwende ich den internen NGINX der in der Synology DSM bereits eingebaut ist.
Könnte ich diesen so weiterverwenden ohne einen neuen NGINX aufzusetzen?
(Würde dann auch nur die "https://emulatorjs.blabla.dynv6.net" sichern wollen. Die anderen Docker Container haben bereits eine Login-Seite integriert)

 

[alexhell]

Würde da nicht Basic Auth reichen? Muss nur dafür wirklich Authelia eingerichtet werden? Vor allem weiß ich nicht wie gut du das bei Synology integrieren kannst, damit es auch Updates übersteht.

 

[update-freak]

Was genau meinst du mit Basic Auth? Wenn das halt eine Seite mit Benutzer und Passwort vorschaltet reicht das natürlich

 

[alexhell]

Ach sorry.... Ich dachte Zugangsprofil beim Reverse Proxy wäre genau das.... Aber nee die unterstützen wohl mit der GUI nicht mal das. Irgendwie ein Armutszeugnis von Synology.
Basic Auth wäre einfach ein Prompt, dass Username und Passwort abfragt.
Aber hier wäre eine Anleitung wie man das mit SSH konfiguriert.

Ich persönlich würde eher dazu empfehlen einen anderen Reverse Proxy zu nutzen. Einen der mehr Funktionen direkt bereitstellt und wo man keine Bedenken haben muss, dass nach einem Update nix mehr läuft.

 

[plang.pl]

Ich würde da auch lieber auf einen 3rd Party Reverse Proxy setzen. Ich selbst habe da den nginx Proxy Manager im Einsatz. Der ist total einfach zu konfigurieren und hat eigentlich alles, was man braucht.

 

[update-freak]

Alles klar, danke euch.
Ich wollte nun gerade nach der Anleitung von Sempervideo NGINX einrichten: https://www.youtube.com/watch?v=0_lgbiw1TNs
bekomme jedoch nach der Bestätigung von "Deploy docker container" folgende Meldung:


Failure
Request failed with status code 500

Jemand eine Idee woran das liegen könnte?

 

[plang.pl]

Ja, das liegt daran, dass DSM standardmäßig schon Port 80 und 443 belegt. https://www.reddit.com/r/synology/comments/ahs3xh/prevent_dsm_listening_on_port_80443/

 

[update-freak]

vielen Dank für die Info.
Habe es mit dem Skript probiert.

sed -i -e 's/80/81/' -e 's/443/444/' /usr/syno/share/nginx/server.mustache /usr/syno/share/nginx/DSM.mustache /usr/syno/share/nginx/WWWService.mustache

systemctl restart nginx

Dann hab ich es nochmal erneut versucht wenn das Skript beim Hochfahren direkt gestartet wird.

Irgendwie hab ich den Eindruck dass noch der Port 443 belegt ist, wenn ich das richtig interpretiere.

 

[plang.pl]

Ja, da lauscht bei dir nach wie vor der nginx der DS. Ich hab das bei mir in einer virtuellen Maschine am Laufen und hab das nie getestet. Deshalb kann ich da nicht viel zu sagen.

 

[update-freak]

Gibt es noch eine andere Möglichkeit das umzubiegen oder hinzubekommen?

EDIT: das einzige was ich noch gefunden habe ist das hier: https://andyyang.co.uk/replace-synology-nas-reverse-proxy/

EDIT2: Würde die hier beschriebe Lösung https://andyyang.co.uk/replace-synology-nas-reverse-proxy/ auch mit Adguard Home gehen?

 

[plang.pl]

Ja klar, man kann das auch mit MACVLAN machen. Da hat aber per default der Container keinen Zugriff auf die DS und andersherum. Das ist ja weiter unten beschrieben, dass man da einen Workaround basteln muss. Das funktioniert auch, hatte ich schon mal im Einsatz. Aber ein weiterer Nachteil bleibt und lässt sich auch nicht umgehen: Für Container im MACVLAN greift die Firewall nicht. Und klar, das geht sowohl mit AdGuard, pi-hole und jedem anderen DNS-Server

 

[update-freak]

danke dir für die Erläuterung.
Dass die Firewall nicht geht, wäre dann für mich auch KO-Kritierium.

Ja, da lauscht bei dir nach wie vor der nginx der DS. Ich hab das bei mir in einer virtuellen Maschine am Laufen und hab das nie getestet. Deshalb kann ich da nicht viel zu sagen.

Dann werd ich mal weiter versuchen herauszufinden, warum das nginx trotzdem noch lauscht

 

[plang.pl]

Ich würde es so machen:
Eine schlanke Linux-VM im VMM aufsetzen und darauf alles laufen lassen. Da hast du deutliche Vorteile:
-aktuelle Docker-Version
-aktueller Linux-Kernel -> weniger Probleme mit Docker-Containern, die auf die neueste Linux-Version setzen
Als Distribution könntest du da entweder den Ubuntu-Server nehmen (ohne grafische Oberfläche; braucht sehr wenig Leistung) oder lubuntu (mit grafischer Oberfläche, braucht minimal mehr Ressourcen). Wenn da in der VM nur der nginx RP und AdGuard laufen soll (ich würde tatsächlich noch unbound einrichten), dann reicht dem Ding auch 1GB RAM. Hier müsstest du dich aber auch separat mit der Firewall beschäftigen und die auf dem Linux selbst einrichten mit iptables z.B.

 

[update-freak]

Top, besten Dank für den Tipp. Schau mir das mal an

Was ich noch gefunden habe:
Wenn ich in der Fritzbox den externen Port 443 auf z.B. 12345 intern (auf was nginx reverse proxy zeigt) weiterleiten, müsste es doch auch gehen. Aber wie verhält sich dann die Firewall?

(https://www.synology-forum.de/threa...ation-port-auf-1234-12345.120770/#post-999874)

 

[alexhell]

Dann muss der interne Trafik auch übers Internet laufen. Weil du musst ja über die Fritzbox gehe , damit der Port funktioniert. Daher wäre es besser, wenn es intern auch über 443 laufen könnte

 

[knilch]

Gibt es noch eine andere Möglichkeit das umzubiegen oder hinzubekommen?

EDIT: das einzige was ich noch gefunden habe ist das hier: https://andyyang.co.uk/replace-synology-nas-reverse-proxy/

EDIT2: Würde die hier beschriebe Lösung https://andyyang.co.uk/replace-synology-nas-reverse-proxy/ auch mit Adguard Home gehen?

Ich habs gelöst!

Synology NGINX belegt Port 80 und 443​

Sehr nervig, dass Synology diese Ports reserviert!
Im Standard werden diese vom NGINX, der als Paket fest installiert ist an das Webserver Packet weitergereicht. Sofern das nicht aktiv ist, leitet der NGINX auf die DSM-Seiten weiter (Port 5000 / 5001).

Port 80 und 443 frei machen​

Nach langer Suche bin ich hier fündig geworden!
Das Script habe ich angepasst und es wird nun alle 15 Minuten durch die Aufgabenplanung als root ausgeführt.

Hindernisse​

Tatsächlich kam es zunächst zu Problemen, nachdem der Port frei war und die Synology neu gestartet war: Obwohl der DSM NIGINX Port 443 nicht mehr belegt, wollte NGINX-PHP (Docker Container!) nicht starten, da Port 443 belegt sei. Nach viel Suche (siehe Helferlein unten!) war klar, dass der Docker Proxy, diesen Port belegt. Nur, dass die Container-IP zum Netzwerk Paperless-Service gehörte und auf der IP kein Container aktiv war. Vergeblich wurde tiefer gegraben – ohne die Ursache zu finden.
Schließlich blieb nur ein weiterer Neustart der Synology: Erfolg! 443 war frei – warum auch immer….

Helferlein​

hier einige Befehle, die bei Problemen helfen:

# zeigt Prozess an, der Port 443 blockiert

netstat -tulpn | grep 443

# Zeigt Prozess-Details zur PID 26710

ps -p 26710 -o pid,vsz=MEMORY -o user,group=GROUP -o comm,args=ARGS

Und hier mein Script ...
Achtung: die verwendete "Quell-Diskussion" ist irgendwann seltsam abgedriftet und meiner Meinung nach falsch abgebogen!

#! /bin/bash
# Script-source and discussion: https://gist.github.com/hjbotha/f64ef2e0cd1e8ba5ec526dcd6e937dd7

# Developed for DSM 6 - 7.0.1.;  worked with Update DSM 6.2 to 7.1
# run as root at boot through Control Panel -> Task Scheduler

# Ports to free - blocked by nginx on Synology
DEFAULT_HTTP_PORT=80
DEFAULT_HTTPS_PORT=443

# New ports to set instead
CUSTOM_HTTP_PORT=5080  # DO NOT USE 5000
CUSTOM_HTTPS_PORT=5443 # DO NOT USE 5001

# Backup-settings
BACKUP_DIR=/volume2/Backups/Settings/DSM-nginx
DELETE_OLD_BACKUPS=true
KEEP_BACKUP_DAYS=90

echo "Replacing port $DEFAULT_HTTP_PORT with $CUSTOM_HTTP_PORT"
echo -e "Replacing port $DEFAULT_HTTPS_PORT with $CUSTOM_HTTPS_PORT\n"

# Always backup...
BACKUP_DIR="$BACKUP_DIR/$(date +%Y%m%d-%H%M%S)"
echo "Backup Dir: "$BACKUP_DIR
mkdir -p "$BACKUP_DIR"
cp -r /usr/syno/share/nginx/* "$BACKUP_DIR"

if [ "$DELETE_OLD_BACKUPS" == "true" ]; then
  find "$BACKUP_DIR/" -type d -mtime +$KEEP_BACKUP_DAYS -exec rm -r {} \;
fi

# Replace ports as desired in mustache config files
sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)$DEFAULT_HTTP_PORT\([^0-9]\)/\1$CUSTOM_HTTP_PORT\2/" /usr/syno/share/nginx/*.mustache
sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)$DEFAULT_HTTPS_PORT\([^0-9]\)/\1$CUSTOM_HTTPS_PORT\2/" /usr/syno/share/nginx/*.mustache

# create changes.log
diff -r --exclude=changes.log /usr/syno/share/nginx/ "$BACKUP_DIR" > "$BACKUP_DIR/changes.log"

# remove backup if NO changes were made - else restart nginx
if [ $(stat -c%s "$BACKUP_DIR/changes.log") -eq 0 ]; then
    rm -f -r "$BACKUP_DIR"
    echo No changes detected, backup removed.
else
    echo "Made these changes:"
    cat "$BACKUP_DIR/changes.log"
    echo -e "\n[ ] Restarting Nginx..."
    if grep -q 'majorversion="7"' "/etc.defaults/VERSION"; then
        nginx -s reload
        echo "[✔] Nginx reloaded!"
    else
        if which synoservicecfg; then
            synoservicecfg --restart nginx
        else
            synosystemctl restart nginx
        fi
        echo "[✔] Nginx restarted!"
    fi
fi

 

[plang.pl]

Danke für die Info!
Vielleicht kann @update-freak das mal testen.

 

[update-freak]

@knilch Vielen Dank für das Skript.
D.h. du hast ausschließlich dein Skript in den Aufgaben ausgeführt und zweimal neu gestartet?
Sprich das Skript von hier https://www.reddit.com/r/synology/comments/ahs3xh/prevent_dsm_listening_on_port_80443/?rdt=35473 ist dann nicht mehr erforderlich. Muss ich vorher alle EInträge im internen Reverse Proxy entfernen oder funktionieren die dann nur nicht mehr und ich muss diese dann im "neuen" Reverse Proxy eintragen?

 

[knilch]

Hey update-freak,

nein, du brauchst nur das Script oben. Den Ursprung hierfür hab ich nur zu Dokumentationszwecken genannt.
den internen NGINX brauchst/solltest Du nicht anfassen - stört nicht und du möchtest vielleicht ja auch "zurück zu normal".

Bei mir ist es so eingerichtet:
Meine Scripte sind alle an einer Stelle gespeichert und werden in der Regel von der Aufgabenplanung zu bestimmten Zeiten aufgerufen. Sie liegen auf einer Freigabe, so dass ich als Admin bequem vom Windows-PC aus editieren (Notepad++) und debuggen (SSH) kann.

Das obige Script würde ich zunächst mal auf der DS an geeigneter Stelle speichern und anpassen (BACKUP_DIR).
Denk an die Zeilenumbrüche (also UNIX + UTF8).
Dann würde ich es manuell ausführen und die Ausgaben prüfen (auch im BACKUP_DIR).
Dann ein Neustart...

Technisch, OHNE Anpassungen, ist es so:

• Port 80 und 443 werden vom internen NGINX der DS belegt - selbst wenn kein Dienst angebunden ist, sind die Ports belegt und für andere Zwecke nicht nutzbar. Der interne NGINX kann NICHT entfernt werden. Alle eintreffenden Anfragen landen dort und werden durch die NGINX-Config, die du in DSM siehst, behandelt. Normalerweise ist das Paket "Webserver" als "Endziel" für diese http/https-Verbindungen vorgesehen.
• Der Zugriff auf DSM selbst ist außerdem über IP/Port möglich - dies solltest Du vor Umstellung testen und irgendwo speichern!

Technisch, MIT Anpassung durch das Script:

• Der interne NGINX lauscht weiter - jedoch auf den neu eingestellten Ports 5080 und 5443
  (siehe CUSTOM_HTTP_PORT und CUSTOM_HTTPS_PORT).
• Die Ports 80 und 443 an der DS sind nun frei !
  Auf denen kann ab jetzt dein eigener Proxy/NGINX lauschen.

Auswirkungen:

• Der Zugriff auf dein DSM funktioniert weiterhin über IP und Port.
• Die Proxy-Einstellungen des INTERNEN NGINX bleiben unberührt, sind jedoch "nutzlos", da keine Anfragen mehr bei ihm landen.
  Es liegt nun alleinig an dir, wie http/https-Verbindungen gehandelt werden.
• Du musst Dich selbst um HTTPS-Zertifikate kümmern (LetsEncrypt + Certbot oder Ähnliches).
• Wahrscheinlich funktionieren einige Standard-Dinge nicht mehr, z. B. QuickConnect (nutz ich nicht - keine Ahnung).

Empfehlung:
Ein eigener NGINX ist nur der Anfang. Es braucht noch einiges mehr, bis ein Dienst extern verfügbar ist: DNS, Port-Forwards, Firwall, Zertifikate/Renewals, NGINX-Config... Die Freiheiten durch einen eigenen NGINX bekommt man NICHT geschenkt. Du musst mit einem hohen Zeiteinsatz rechnen, bis alles eingerichtet ist und läuft!

 

[update-freak]

Wollte es mal wieder zurückstellen und bekomme nun bei der filestation und dem synology vm Manager folgende Meldung



Rest was im internen Reverse Proxy eingestellt war funktioniert. Muss ich da noch was an Einstellungen zurückstellen?