Synology NAS lyssnar på port 80 och 443 - hur gör man för att stänga av det?

Permalänk
Medlem

Synology NAS lyssnar på port 80 och 443 - hur gör man för att stänga av det?

Synology NAS verkar vilja lyssna på port 80 och 443. Men hittar ingen som helst inställning för att inaktivera detta.
Det enda den verkar göra är att peka om till port 5000 och 5001.

Detta ställer till lite problem när jag vill köra tjänster som behöver dessa två portar (t.ex. som nu när jag tänkte köra Swag).

Någon med idéer kring hur jag kan få min Synology att sluta med detta otyg så att jag kan börja använda dessa portar till det jag vill istället?

Permalänk
Medlem
Skrivet av naaw:

Synology NAS verkar vilja lyssna på port 80 och 443. Men hittar ingen som helst inställning för att inaktivera detta.
Det enda den verkar göra är att peka om till port 5000 och 5001.

Detta ställer till lite problem när jag vill köra tjänster som behöver dessa två portar (t.ex. som nu när jag tänkte köra Swag).

Någon med idéer kring hur jag kan få min Synology att sluta med detta otyg så att jag kan börja använda dessa portar till det jag vill istället?

Du kan kika i den inbyggda brandväggen i Synology och neka access där.

Permalänk
Medlem
Skrivet av Kalasis:

Du kan kika i den inbyggda brandväggen i Synology och neka access där.

Den är inte aktiverad, så gissningvis har den ej heller något med det att göra.
Och det är inte "neka access" jag ska göra. Det är, som jag nämnde, få Synology att slut använda dessa två portar. Så att andra tjänster (t.ex docker container) kan använda dessa två portar. I mitt fall "swag".

Eller missförstod jag dig?

Permalänk
Medlem

Det är lite knepigt att byta systemets inbyggda konfig för 80 och 443.

Man kan köra följande om man vill.

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 synoservicecfg --restart nginx

Dock behöver detta köras varje gång man uppdaterar så det är lite opraktiskt.
Det jag gjorde var att istället sätta upp traefik framför docker på en egen IP-adress och lät den hantera vart trafiken skulle skickas internt.

Förtydligande av hur lösningen ser ut.
Permalänk
Medlem
Skrivet av Tespo:

Det är lite knepigt att byta systemets inbyggda konfig för 80 och 443.

Man kan köra följande om man vill.

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 synoservicecfg --restart nginx

Dock behöver detta köras varje gång man uppdaterar så det är lite opraktiskt.
Det jag gjorde var att istället sätta upp traefik framför docker på en egen IP-adress och lät den hantera vart trafiken skulle skickas internt.

när du säger "framför docker". menar du då att du satte upp traefik (i mitt fall swag) på egen hårdvara och då alltså inte på NASen alls.

Permalänk
Medlem
Skrivet av naaw:

när du säger "framför docker". menar du då att du satte upp traefik (i mitt fall swag) på egen hårdvara och då alltså inte på NASen alls.

Nja, kom på att min lösning är lite mer komplex än så.
Jag har port 443 på min router pekad på en annan intern port på NASen där traefik går och den skickar sedan trafiken baserat på namn till rätt docker-instans. Sen har jag en lokal DNS som pekar tjänsterna rätt även internt (dvs via routern).

Men jag har testat att peka om de interna nginx-portarna så det är en lösning som fungerar, det tråkiga var bara att man behövde peta på den om man uppdaterar DSM.

Det du kan göra är ju att lägga in ett script som körs vid boot som pekar om portarna enligt ovan.

Permalänk
Medlem
Skrivet av Tespo:

Nja, kom på att min lösning är lite mer komplex än så.
Jag har port 443 på min router pekad på en annan intern port på NASen där traefik går och den skickar sedan trafiken baserat på namn till rätt docker-instans. Sen har jag en lokal DNS som pekar tjänsterna rätt även internt (dvs via routern).

Men jag har testat att peka om de interna nginx-portarna så det är en lösning som fungerar, det tråkiga var bara att man behövde peta på den om man uppdaterar DSM.

Det du kan göra är ju att lägga in ett script som körs vid boot som pekar om portarna enligt ovan.

ok, tack för hjälpen!

blir troligtvis antingen egen hårdvara för reverse proxy eller som du säger att köra ett script vid start, så länge det inte finns risk att det strular i och med att docker containern kanske hinner starta innan scriptet har kört.

Permalänk
Medlem
Skrivet av Tespo:

Det är lite knepigt att byta systemets inbyggda konfig för 80 och 443.

Man kan köra följande om man vill.

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 synoservicecfg --restart nginx

Dock behöver detta köras varje gång man uppdaterar så det är lite opraktiskt.
Det jag gjorde var att istället sätta upp traefik framför docker på en egen IP-adress och lät den hantera vart trafiken skulle skickas internt.

jag körde detta med task scheduler i synology dsm nu (som root) och fick felmeddelandet:
/volume1/system/task scheduler output/Change ports 80 and 443/1653402550/script.log: line 2: synoservicecfg: command not found

Är du säker på att det är korrekt?

Hittade en post på reddit som nämnde att det nu är följande kommando för att starta om nginx:
sudo systemctl restart nginx

Permalänk
Medlem
Skrivet av naaw:

jag körde detta med task scheduler i synology dsm nu (som root) och fick felmeddelandet:
/volume1/system/task scheduler output/Change ports 80 and 443/1653402550/script.log: line 2: synoservicecfg: command not found

Är du säker på att det är korrekt?

Hittade en post på reddit som nämnde att det nu är följande kommando för att starta om nginx:
sudo systemctl restart nginx

Det var det när jag mekade med det men det har tydligen ändrats i senare versioner av DSM.
Sedan DSM 7.0 skall det tydligen istället vara

sudo systemctl restart nginx

Edit: Såg att du hittade det också.

Permalänk
Medlem
Skrivet av naaw:

Den är inte aktiverad, så gissningvis har den ej heller något med det att göra.
Och det är inte "neka access" jag ska göra. Det är, som jag nämnde, få Synology att slut använda dessa två portar. Så att andra tjänster (t.ex docker container) kan använda dessa två portar. I mitt fall "swag".

Eller missförstod jag dig?

Jag som är trött i huvudet. Ber om ursäkt.

Hittade lite matnyttigt här:

https://3os.org/infrastructure/synology/disable-dms-listening...

*Edit: såg att samma lösning redan tagits upp.

Permalänk
Medlem

Varför måste du köra på just port 80 och 443?

Med Docker kan du ju välja vilken port containern skall lyssna på så du kan lika gärna göra en Port Forward i routern från inkommande port 80 till port 8080 (eller 81 eller vad du nu vill) på din NAS och sedan i konfigurationen för din container ange port 8080 på utsidan och 80 på insidan.

Ett annat alternativ är att köra fast IP på containern med br0.

Visa signatur

Det finns bara två sorters hårddiskar: de som har gått sönder och de som skall gå sönder.

Permalänk
Medlem
Skrivet av Tespo:

Det var det när jag mekade med det men det har tydligen ändrats i senare versioner av DSM.
Sedan DSM 7.0 skall det tydligen istället vara

sudo systemctl restart nginx

Edit: Såg att du hittade det också.

Verkar som nasen fortfarande svarar på port 80 och 443. Kommer till till dsm när jag anger de portarna (vidarebefordras fortfarande till 5000 och 5001) Men får inga felmeddelande när jag kör kommandot. Och när jag försöker ställa in portarna 80 och 443 på containern så säger den att de redan används av något annat.

Skrivet av zarkov:

Varför måste du köra på just port 80 och 443?

Med Docker kan du ju välja vilken port containern skall lyssna på så du kan lika gärna göra en Port Forward i routern från inkommande port 80 till port 8080 (eller 81 eller vad du nu vill) på din NAS och sedan i konfigurationen för din container ange port 8080 på utsidan och 80 på insidan.

Ett annat alternativ är att köra fast IP på containern med br0.

Tack för förslaget, ska kolla på det också. Tänkte att det kanske krävdes 443 för att fungera med SSL på reverse proxy utan krångel. Men ska testa under dagen.

Permalänk
Skrivet av naaw:

Tack för förslaget, ska kolla på det också. Tänkte att det kanske krävdes 443 för att fungera med SSL på reverse proxy utan krångel. Men ska testa under dagen.

Du behöver något som lyssnar på 443; om det nu är bara routern (med port forward) eller en reverse proxy. Webbtjänsten bakom kan lyssna på vad som helst bara den presenterar sig med ett namn som stämmer med certifikatet den visar upp.

Permalänk
Medlem

Som många redan nämnt. Men om du nu ska öppna utåt så är det bara att sätta din router att forwarda all 443 trafik till din nas på typ 4443. Så har jag löst det. Och det är inga problem med certifikatet. Så länge domänen matchar certet så är det lugnt.
Körde själv via detta sättet ett tag.

Men kör numera en reverse proxy på en raspberry pi istället då jag pekar alla min tjänster till interna IPs. Slipper således alla attacker mot min server som jag annars hade. Vill man nå det extern så släng upp en wireguard server och se till så dina enheter alltid är kopplad mot den. Kör själv på detta sättet och funkar klockrent.

Permalänk
Medlem
Skrivet av timerx:

Som många redan nämnt. Men om du nu ska öppna utåt så är det bara att sätta din router att forwarda all 443 trafik till din nas på typ 4443. Så har jag löst det. Och det är inga problem med certifikatet. Så länge domänen matchar certet så är det lugnt.
Körde själv via detta sättet ett tag.

Men kör numera en reverse proxy på en raspberry pi istället då jag pekar alla min tjänster till interna IPs. Slipper således alla attacker mot min server som jag annars hade. Vill man nå det extern så släng upp en wireguard server och se till så dina enheter alltid är kopplad mot den. Kör själv på detta sättet och funkar klockrent.

Ok, ja då är det nog något annat som spökar. För får "502 Bad Gateway" när jag försöker gå till "subdomain.mydomain.se".
båda containers ligger i ett user-defined bridge network. och 443 pekar mot 4434 i routern, och local port i container är 4434 och container port är 443. och containern har samma namn som anges i swags proxy-conf för den tjänsten (eftersom den använder hostname behöver det vara samma och också därför man använder user-defined bridge network)

Permalänk
Medlem
Skrivet av naaw:

Ok, ja då är det nog något annat som spökar. För får "502 Bad Gateway" när jag försöker gå till "subdomain.mydomain.se".
båda containers ligger i ett user-defined bridge network. och 443 pekar mot 4434 i routern, och local port i container är 4434 och container port är 443. och containern har samma namn som anges i swags proxy-conf för den tjänsten (eftersom den använder hostname behöver det vara samma och också därför man använder user-defined bridge network)

Det ska inte vara några problem alls tycker jag. Enda som skiljer sig från min setup är att jag kör mina containers i det bryggade nätet som är default i docker. Är det något som är galet med det igen definerade byggade nät kanske?

Permalänk
Medlem
Skrivet av timerx:

Det ska inte vara några problem alls tycker jag. Enda som skiljer sig från min setup är att jag kör mina containers i det bryggade nätet som är default i docker. Är det något som är galet med det igen definerade byggade nät kanske?

Nej inte vad jag kan se. Och båda containers kan pinga varandra (med hostname). och kan komma åt den container som ska köras reverse proxy mot om jag använder mig utav LAN IP, så den är fullt tillgänglig på nätverket så att säga..

dvs.
http://192.168.1.240:5055 - inga problem
https://sub.domain.se - 502 Bad Gateway
https://domain.se - funkar fint och jag kommer till "Swag info sidan" som visas när man inte har någon reverse proxy confad för den subdomänen/domänen för att visa att swag är installerat och fungerar fint.

Permalänk
Medlem

Jag gav upp på swag och testade nginx proxy manager istället. då fungerade allt fint direkt. så gissar att det var proxy-conf filen för just den tjänsten i swag som strulade.