Docker Portainer en IPTABLES

[ironheart]

Hi,

Daarstraks had ik een VPS draaien en daarop de boel dichtgezet met IPTABLES en enkel één host gewhitelist om de VPS te kunnen benaderen. Vervolgens heb ik docker geïnstalleerd en portainer. Ik was in de veronderstelling dat nog steeds enkel mijn gewhiteliste IP toegang had maar tot mijn verbazing had Portainer poort 9000 world wide opengezet. In de documentatie las ik dat hij 2 chains aanmaakt in IPTABLES. Om dit te voorkomen zou je hem kunnen binden aan een local adres en via vpn kunnen benaderen. Echter, dat wil ik eigenlijk niet. Ik wil hem enkel vanaf mijn gewhiteliste adres kunnen benaderen. Ik merkte ook op dat bij iedere reboot mijn opgeslagen wijzigen niet werden doorgevoerd (ondanks iptables persistent).

Wat zijn jullie ervaringen hiermee en wat is de way to go hierin? (let op, is enkel spielerij en ter lering voor mezelf dus geen productie environment).

[Hero of Time]

Als je wilt pielen en spelen, waarom dan een 'dure' VPS ipv zelf in een VM of oude hardware gebruiken? Dit in geval je een foutje maakt en er niet meer bij komt. Al zal je wellicht een console tot je beschikking hebben.

Hoe dan ook, kijk eens naar wat Portainer doet met iptables. Zou kunnen dat die zelf een restore doet en daarmee jouw regels weer wist. Dat is ook hoe het een extra chain toevoegt met eigen regels waar naar verwezen wordt in de hoofd chain waar het eerst doorheen gaat.

[ahbart]

Heeft docker geen setting dat er automatisch ufw rules worden aangemaakt voor de container?

[ironheart]

Arrghh!!!

Ik word gek!
Aangezien ik het niet voor elkaar krijg om een whitelist te implementeren via IPTABLES dacht ik dat het een goed idee was om een Reverse Proxy in te stellen. Zodoende NGINX Reversy Proxy opgetuigd maar ik krijg het voor the life of my niet werkend (bad gateway o.a.).

Ik heb een A record aangemaakt bij mijn DNS provider. Vervolgens een proxy host ingesteld met het subdomein, verwijzend naar het IP adres waar de service op draait (lokaal dus 172.18.0.3 en dan het poortnummer). Als ik nu navigeer naar subdomein.root.nl dan krijg ik pagina niet gevonden, terwijl als ik navigeer naar subdomen.root.nl:poortnummer van de service dan werkt het wel. Ik heb meerdere turtorials gevolgd waaronder deze https://www.youtube.com/watch?v=GarMdDTAZJo en dit lijkt me best duidelijk volgens mij. Kan weinig aan fout gaan. Hebben jullie suggesties wat ik mogelijk over het hoofd zie?

[Hero of Time]

Kijk eens met netstat of ss of er wel op het juiste IP geluisterd wordt met die poort. Daarna met iptables of het betreffende IP ook wordt toegestaan. Let ook op je container configuratie of de NAT binding is zoals je verwacht.

Daarna kan je met curl/wget testen of het lokaal op de machine werkt zoals je zou verwachten.

Het is precies dit soort rariteiten dat ik liever geen containers draai voor m'n applicaties. Netwerken zijn an sich al lastig genoeg en als er dan nog een laag tussen zit die er ook met z'n tengels aan gaat zitten zonder dat je het fatsoenlijk ziet, is het helemaal lastig troubleshooten.

[ironheart]

Haha, het ergste is dat ik je ook nog helemaal gelijk geef ook! Ik draai het liefst zo native mogelijk. Ik ga kijken of ik met je tips eruit kom anders wordt het morgen een herinstallatie en dan zonder docker.

[ironheart]

Even een iets betere uitleg:

Provider: A record subdomein.root.nl naar ip adres 1.2.3.4

Op VPS met ip adres 1.2.3.4 docker & portainer draaien en nog wat andere services.

Portainer is te bereiken via http://1.2.3.4:9000 of via subdomein.root.nl:9000
Portainer draait lokaal (op de vps) op 172.18.0.3
Poort 9000 is gemapped naar intern 9000


Tevens ook Nginx proxy manager geinstalleerd.
Een Proxy host aangemaakt met subdomein.root.nl verwijzend naar 172.18.0.3:9000

That's it toch?

netstat -tulpn geeft inderdaad aan dat er wordt geluisterd naar poort 9000.

Ik doe het volgens mij goed, zo?

[Hero of Time]

Op m'n werk heb ik een container draaien via Podman. Eigenlijk was dat wel heel eenvoudig! De reden dat ik Podman gebruik, is omdat het standaard in de Debian repository aanwezig is en dus niet afhankelijk ben van externe repo's. Er zijn wel 'docker' packages, maar dat is docker.io, terwijl de gangbare Docker juist docker-ce is.
Extra reden is dat Podman rootless is, je hebt dus niet perse root rechten nodig om een container te draaien, het draait gewoon onder je eigen gebruiker. Het is ook daemon-less, er is geen standaard service die je containers beheert. Wel is er systemd integratie voor het draaien van je containers, waardoor je via 'systemctl --user status|stop|start <container>' je container beheert. En via podman-compose is het zelfs docker-compose compatible.
Security is de eerste gedachte bij Podman.

Het netwerk deel van Podman is niet heel speciaal vziw, het bind op een IP en poortnummer en zo wordt er een poort van de container op/via de host beschikbaar gemaakt. Dat is hoe elke container software z'n werk zou moeten doen. Geef je een IP adres op om op te binden, dan bind 'ie op dat adres, anders op alle beschikbare.

Als je in je container config opgeeft :9000 naar :9000 van container, dan is wat in de container op poort 9000 draait voor alles en iedereen bereikbaar via het adres van de host (tenzij je dit afschermt via een firewall).

Wanneer je container een eigen IP adres heeft, moet je goed opletten hoe dat nou precies gaat mbt routering. Want waarom is een container direct op poort 9000 bereikbaar als het ook nog een eigen IP adres heeft dat samen met de host een eigen netwerk vormt? De container zal intern een IP adres hebben, dat is logisch, maar afhankelijk van de netwerkstack dat je gebruikt hoeft die niet bereikbaar te zijn voor de host.

Zo kan ik virtualisatie even als voorbeeld erbij pakken. VirtualBox ken ik nog goed mbt netwerken. Het heeft NAT als optie en de host heeft geen flauw idee wat het netwerk voor de guest is. Sterker nog, elke guest heeft hetzelfde IP adres, namelijk 10.0.2.15. Via port forwarding kan je naar de guest, afhankelijk of de service het ook ondersteund (rdp bijvoorbeeld wel, shares niet).

Met containers werkt het op een vergelijkbare manier. De netwerkstack bepaald ook wat je mogelijkheden zijn.

Had ik al gezegd dat containers extra complexiteit leveren mbt netwerken? Als je niet begrijpt wat je mogelijkheden en beperkingen zijn, is het best lastig te krijgen wat je wilt.

[CH4OS]

ironheart schreef op vrijdag 9 augustus 2024 @ 21:59:
Even een iets betere uitleg:

Provider: A record subdomein.root.nl naar ip adres 1.2.3.4

Op VPS met ip adres 1.2.3.4 docker & portainer draaien en nog wat andere services.

Portainer is te bereiken via http://1.2.3.4:9000 of via subdomein.root.nl:9000
Portainer draait lokaal (op de vps) op 172.18.0.3
Poort 9000 is gemapped naar intern 9000


Tevens ook Nginx proxy manager geinstalleerd.
Een Proxy host aangemaakt met subdomein.root.nl verwijzend naar 172.18.0.3:9000

That's it toch?

netstat -tulpn geeft inderdaad aan dat er wordt geluisterd naar poort 9000.

Ik doe het volgens mij goed, zo?

Als je er toch al een reverse proxy voor zet, hoef je de portforwardings naar buiten ook niet meer te doen, dan kun je mooi alles forceren via poort 80 of 443. Dat lijkt me allicht een stuk veiliger.

[ironheart]

Hero of Time schreef op vrijdag 9 augustus 2024 @ 22:12:
Op m'n werk heb ik een container draaien via Podman. Eigenlijk was dat wel heel eenvoudig! De reden dat ik Podman gebruik, is omdat het standaard in de Debian repository aanwezig is en dus niet afhankelijk ben van externe repo's. Er zijn wel 'docker' packages, maar dat is docker.io, terwijl de gangbare Docker juist docker-ce is.
Extra reden is dat Podman rootless is, je hebt dus niet perse root rechten nodig om een container te draaien, het draait gewoon onder je eigen gebruiker. Het is ook daemon-less, er is geen standaard service die je containers beheert. Wel is er systemd integratie voor het draaien van je containers, waardoor je via 'systemctl --user status|stop|start <container>' je container beheert. En via podman-compose is het zelfs docker-compose compatible.
Security is de eerste gedachte bij Podman.

Het netwerk deel van Podman is niet heel speciaal vziw, het bind op een IP en poortnummer en zo wordt er een poort van de container op/via de host beschikbaar gemaakt. Dat is hoe elke container software z'n werk zou moeten doen. Geef je een IP adres op om op te binden, dan bind 'ie op dat adres, anders op alle beschikbare.

Als je in je container config opgeeft :9000 naar :9000 van container, dan is wat in de container op poort 9000 draait voor alles en iedereen bereikbaar via het adres van de host (tenzij je dit afschermt via een firewall).

Wanneer je container een eigen IP adres heeft, moet je goed opletten hoe dat nou precies gaat mbt routering. Want waarom is een container direct op poort 9000 bereikbaar als het ook nog een eigen IP adres heeft dat samen met de host een eigen netwerk vormt? De container zal intern een IP adres hebben, dat is logisch, maar afhankelijk van de netwerkstack dat je gebruikt hoeft die niet bereikbaar te zijn voor de host.

Zo kan ik virtualisatie even als voorbeeld erbij pakken. VirtualBox ken ik nog goed mbt netwerken. Het heeft NAT als optie en de host heeft geen flauw idee wat het netwerk voor de guest is. Sterker nog, elke guest heeft hetzelfde IP adres, namelijk 10.0.2.15. Via port forwarding kan je naar de guest, afhankelijk of de service het ook ondersteund (rdp bijvoorbeeld wel, shares niet).

Met containers werkt het op een vergelijkbare manier. De netwerkstack bepaald ook wat je mogelijkheden zijn.

Had ik al gezegd dat containers extra complexiteit leveren mbt netwerken? Als je niet begrijpt wat je mogelijkheden en beperkingen zijn, is het best lastig te krijgen wat je wilt.

Podman klinkt leuk, logischer en praktischer. Ben ermee aan de slag gegaan maar ook hier gaat het niet van jewelste:



IPTABLES:


Maar helaas....




Ikzelf ben regel 6 van de INPUT CHAIN. Zit ik wel in de juiste CHAIN te werken?

[Hero of Time]

Ik heb weinig met iptables gewerkt om daar goed antwoord op te geven. Ik kan nog wel iets verduidelijken met wat ik met Podman heb gedaan. In een ander topic op dit forum werd StirlingPDF genoemd. De container staat op dockerhub en via docker-compose kan je die heel makkelijk draaien. Podman is docker-compose compatible met podman-compose. In het compose bestand heb ik de port forward op 127.0.0.1 gezet, zodat het op localhost bind.

Vervolgens heb ik een reverse proxy (dmv haproxy, maar nginx had ook gekund) ingericht voor o.a. https en laat ik als backend verwijzen naar 127.0.0.1:9000.

Zou ik vervolgens met iptables gaan werken, dan hoef ik alleen met de standaard chains te werken ipv wat de container software zelf er allemaal nog bij spuugt. Want dat hoeft 't niet te doen en zou met z'n poten er vanaf moeten blijven.

Configureren van iptables is ook iets wat ik liever in een lokale VM test en daarna pas op het te beveiligen systeem doe. Foutje op de 'live' omgeving en ik kom er niet meer bij. En kan eenvoudig een extra bron opspinnen of erbij pakken om te testen en zien wat welke regel voor effect heeft.

[ironheart]

Ik zie middels een netstat -tulpen dat hij luistert op 0.0.0.0:80

Klopt dat wel?

Moet dat niet 127.0.0.1:80 zijn? Zo ja, hoe pas ik dat aan?

[Hero of Time]

Je hebt toch nginx draaien als reverse proxy? Die zou op poort 80 moeten draaien. Je container moet je zelf opgeven in z'n config welke poort je op de host wilt gebruiken naar wat er in de container maar draait (en dat kan een andere poort zijn).

[sjorsjuhmaniac]

Je maakt het jezelf wel wat lastig. Je leest ook de manual van de software die je installeert niet.

Als je met dockers aan de gang gaat is het wellicht beter Nginx ook als docker te draaien. In dat geval hoef je geen poorten meer te exposen behalve die voor nginx, en hang je de containers in hetzelfde docker-netwerk als Nginx. Daarnaast zijn er nginx packages die env variabelen van andere dockers checkt, hiermee kan je heel eenvoudig docker containers aan je nginx toevoegen zonder echt configuratie werk. Zie https://github.com/nginx-proxy/nginx-proxy

Anyway, het verschil tussen 0.0.0.0 en 127.0.0.1 is dat 127 ALLEEN vanuit de host bereikbaar is.
0 betekend dat de service niet op een specifiek ip gebonden is en op pakketjes met target-ip “whatever” reageert.

Je nginx moet dus op 0.0.0.0 of je externe publieke ip gebonden zijn om vanaf buiten beschikbaar te zijn.

[sjorsjuhmaniac]

ironheart schreef op zaterdag 10 augustus 2024 @ 16:11:
[...]


Podman klinkt leuk, logischer en praktischer. Ben ermee aan de slag gegaan maar ook hier gaat het niet van jewelste:

[Afbeelding]

IPTABLES:
[Afbeelding]

Maar helaas....

[Afbeelding]


Ikzelf ben regel 6 van de INPUT CHAIN. Zit ik wel in de juiste CHAIN te werken?

Zie hier de iptables proces flow, input lijkt me correct. Maar met mijn tip hierboven hoef je geen handmatige iptables configuratie meer te doen.

[ironheart]

Hero of Time schreef op zaterdag 10 augustus 2024 @ 18:57:
Je hebt toch nginx draaien als reverse proxy? Die zou op poort 80 moeten draaien. Je container moet je zelf opgeven in z'n config welke poort je op de host wilt gebruiken naar wat er in de container maar draait (en dat kan een andere poort zijn).

Die had ik draaien met docker maar na een fresh reinstall ben ik met podman op jouw advies aan de slag gegaan maar kan nog niet echt tutorial vinden om Nginx Proxy Manager te draaien. Of kan ik een yaml gebruiken van Docker in podman compose?

[ironheart]

sjorsjuhmaniac schreef op zaterdag 10 augustus 2024 @ 19:21:
Je maakt het jezelf wel wat lastig. Je leest ook de manual van de software die je installeert niet.

Als je met dockers aan de gang gaat is het wellicht beter Nginx ook als docker te draaien. In dat geval hoef je geen poorten meer te exposen behalve die voor nginx, en hang je de containers in hetzelfde docker-netwerk als Nginx. Daarnaast zijn er nginx packages die env variabelen van andere dockers checkt, hiermee kan je heel eenvoudig docker containers aan je nginx toevoegen zonder echt configuratie werk. Zie https://github.com/nginx-proxy/nginx-proxy

Anyway, het verschil tussen 0.0.0.0 en 127.0.0.1 is dat 127 ALLEEN vanuit de host bereikbaar is.
0 betekend dat de service niet op een specifiek ip gebonden is en op pakketjes met target-ip “whatever” reageert.

Je nginx moet dus op 0.0.0.0 of je externe publieke ip gebonden zijn om vanaf buiten beschikbaar te zijn.

Interessant.... dit moet ik even laten bezinken.

[ironheart]

sjorsjuhmaniac schreef op zaterdag 10 augustus 2024 @ 19:21:
Je maakt het jezelf wel wat lastig. Je leest ook de manual van de software die je installeert niet.

Als je met dockers aan de gang gaat is het wellicht beter Nginx ook als docker te draaien. In dat geval hoef je geen poorten meer te exposen behalve die voor nginx, en hang je de containers in hetzelfde docker-netwerk als Nginx. Daarnaast zijn er nginx packages die env variabelen van andere dockers checkt, hiermee kan je heel eenvoudig docker containers aan je nginx toevoegen zonder echt configuratie werk. Zie https://github.com/nginx-proxy/nginx-proxy

Anyway, het verschil tussen 0.0.0.0 en 127.0.0.1 is dat 127 ALLEEN vanuit de host bereikbaar is.
0 betekend dat de service niet op een specifiek ip gebonden is en op pakketjes met target-ip “whatever” reageert.

Je nginx moet dus op 0.0.0.0 of je externe publieke ip gebonden zijn om vanaf buiten beschikbaar te zijn.

Thanks!!!

Dit heeft ertoe geleidt dat het nu werkt ALS ik mijn iptables policy op de INPUT CHAIN op ACCEPT zet.
Top dus!!!!

Butt.... ik wil niet alles opzetten natuurlijk. Enkel port 80 openzetten op de INPUT chain vanaf een vast source adres werkt niet.
NETSTAT -TULPN | grep LISTEN geeft aan dat er wordt geluisterd op 0.0.0.0:80 en 81 o.a.
Waarom werkt dit dan niet?

[sjorsjuhmaniac]

wat je wilt is dat je standard policy DROP wordt. Daarna voeg regels toe met wat je wilt toestaan. Bv een INPUT ACCEPT voor port 80.

Pas op met dit soort changes, je sluit jezelf een buiten. Gebruik netjes de iptables-apply functie met een redelijke timeout. Lees de man pages van iptables-save.

ik heb geen idee waarom het niet werkt als je niet meer info deelt en meer debuged.
uiteraard kan iptables dit 'gewoon' dus het is een configuratie fout.

Pas wat je wilt toe in stapjes om te kijken waar het fout gaat.
Check eerst eens welk IP je eigen ssh sessie heeft. Dat ip kan je uit de ENV SSH_CLIENT vars halen op de cli. Dit moet dan ook het ip zijn wat je wel toestaat.

post anders je 'rules.v4' of v6 file eens in 'code' tags.

PS, je zal toch vrij snel naar HTTPS, poort 443 moeten switchen. Je gaat nu alles cleartext doen, dat is niet heel handig.

[Hero of Time]

ironheart schreef op zaterdag 10 augustus 2024 @ 19:52:
[...]

Die had ik draaien met docker maar na een fresh reinstall ben ik met podman op jouw advies aan de slag gegaan maar kan nog niet echt tutorial vinden om Nginx Proxy Manager te draaien. Of kan ik een yaml gebruiken van Docker in podman compose?

Podman was niet echt een advies, alleen wat ik zelf heb gedaan op werk voor een interne webapp. En zoals ik eerder al zei, Podman met Podman-compose is docker-compose compatible, dus die yaml kan je daar mee gebruiken.

Ik had hetzelfde voor elkaar kunnen krijgen met Docker. De netwerkstacks zijn praktisch hetzelfde. Het verschil zit 'm in je eigen configuratie. Als je een compose yaml van het internet plukt en zonder nadenken verwacht dat het aan jouw wensen en eisen voldoet, dan doe je het verkeerd. Net zoals je niet zomaar random code moet uitvoeren zonder te begrijpen wat het doet, moet je ook niet random compose bestanden gaan starten.

[ironheart]

Ik had hetzelfde voor elkaar kunnen krijgen met Docker. De netwerkstacks zijn praktisch hetzelfde. Het verschil zit 'm in je eigen configuratie. Als je een compose yaml van het internet plukt en zonder nadenken verwacht dat het aan jouw wensen en eisen voldoet, dan doe je het verkeerd. Net zoals je niet zomaar random code moet uitvoeren zonder te begrijpen wat het doet, moet je ook niet random compose bestanden gaan starten.

Dat doe ik sowieso niet Wek ik die indruk dan? De enige compose die ik geplukt heb is van de installatie van Nginx Proxy Manager.

post anders je 'rules.v4' of v6 file eens in 'code' tags.

Ik heb nu de policy van de input even tijdelijk op ACCEPT gezet. Dan werkt het maar dat moet natuurlijk niet zo blijven.

code:

[root@core:~# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     6    --  *      *       145.xxx.xxx.xxx      217.xxx.xxx.xxx      /* TBG Eindhoven */ tcp dpt:22
10435  758K ACCEPT     0    --  *      *       0.0.0.0/0            217.xxx.xxx.xxx      ctstate RELATED,ESTABLISHED
    4   256 ACCEPT     6    --  *      *       77.1xxx.xxx.xxx        217.xxx.xxx.xxx      /* RFC Geldrop */ tcp dpt:22
    0     0 ACCEPT     6    --  *      *       62.xxx.xxx.xxx         217.xxx.xxx.xxx      /* RFC Eindhoven */ tcp dpt:22
  161 14484 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
22168   26M DOCKER-USER  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
22101   26M DOCKER-ISOLATION-STAGE-1  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
  897 1847K ACCEPT     0    --  *      br-e33431fa3b82  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
   56  3416 DOCKER     0    --  *      br-e33431fa3b82  0.0.0.0/0            0.0.0.0/0           
  851 1579K ACCEPT     0    --  br-e33431fa3b82 !br-e33431fa3b82  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     0    --  br-e33431fa3b82 br-e33431fa3b82  0.0.0.0/0            0.0.0.0/0           
10909 3799K ACCEPT     0    --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
  654 38308 DOCKER     0    --  *      docker0  0.0.0.0/0            0.0.0.0/0           
13127   26M ACCEPT     0    --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     0    --  docker0 docker0  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 13578 packets, 13M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
   54  3244 ACCEPT     6    --  !docker0 docker0  0.0.0.0/0            172.17.0.2           tcp dpt:9443
   84  5084 ACCEPT     6    --  !docker0 docker0  0.0.0.0/0            172.17.0.2           tcp dpt:9000
   26  1348 ACCEPT     6    --  !docker0 docker0  0.0.0.0/0            172.17.0.2           tcp dpt:8000
   79  4136 ACCEPT     6    --  !docker0 docker0  0.0.0.0/0            172.17.0.3           tcp dpt:443
  115  7688 ACCEPT     6    --  !docker0 docker0  0.0.0.0/0            172.17.0.3           tcp dpt:81
  296 16808 ACCEPT     6    --  !docker0 docker0  0.0.0.0/0            172.17.0.3           tcp dpt:80

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  865 1580K DOCKER-ISOLATION-STAGE-2  0    --  br-e33431fa3b82 !br-e33431fa3b82  0.0.0.0/0            0.0.0.0/0           
13127   26M DOCKER-ISOLATION-STAGE-2  0    --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0           
26494   33M RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       0    --  *      br-e33431fa3b82  0.0.0.0/0            0.0.0.0/0           
   14   840 DROP       0    --  *      docker0  0.0.0.0/0            0.0.0.0/0           
13978   28M RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination         
26458   33M RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0           
root@core:~#

[Shivs]

Ik zit volgens mij meerder stappen om uit te zoeken:

- Zorg dat je container draait en lokaal bereikbaar is (hint curl vanaf the VPS naar 127.0.0.1:poortnummertje)
- Zorg dat je een reverse proxy hebt die werkt (nginx werkt prima, let even op dat je de config vertelt op welke poort je container gemapt is en test weer lokaal)
- Zorg er voor dat alles van buitenaf benaderbaar is
- Sluit dingen af voor de wereld

Volgens mij heb je één werkend, twee twijfel ik over met de informatie die je hebt gegeven. Van buitenaf benaderbaar lijkt ook te werken, je moet alleen nog je iptables policy wat finetunen.

Kan je eens posten hoe je de container start en hoe je nginx config eruit ziet voor je reverse proxy?

[ironheart]

Hola,

Ik ben er deels uit!! Na wat hoofdpijn en uurtjes denkwerk. Wel een leuk leerproces.

Ben intussen overgestapt op podman en cockpit, heerlijk werkt dat.
Met Podman kan ik in de forward rules defineren wie toegang krijgt en hierdoor whitelisten. Op de één of andere reden lukt me dit niet via docker.

Ik doe dit nu zonde reverse proxy dus die moet ik nog installeren en testen en daarna.... is mijn projectje klaar denk ik.....

Heb nu changedetection draaien in een container en wellicht dat ik daar mijn dokuwiki erbij gooi om kosten te besparen (want is nu een andere vps).

Iemand ervaring overigens met de hosted versie van changedetection? Wat brengt voor voordelen ten opzichte van self hosted (los van de prijs welke overigens maar 3 euro scheelt ).

[drm]

Mijn ervaring is: blijf van iptables af als docker is geinstalleerd. Docker gebruikt zelf docker voor de routing van IP-verkeer tussen de containers onderling en het wordt heel snel ingewikkeld, ondoorzichtig en foutgevoelig als je daar je eigen rules aan toe wilt voegen.

Al met al is het op IP-niveau gewoon een kwestie van alleen poorten expliciet exposen die je ook daadwerkelijk wilt exposen. Gebruik dus (in principe) nooit 0.0.0.0, maar bind op 127.0.0.1 of de expliciete docker IP-adressen. Aangezien je NginX als reverse proxy gebruikt kun je daarin gewoon een IP check doen en op HTTP niveau de request denyen. Je hoeft daarmee dus niks op IP-niveau te regelen.

Zie https://nginx.org/en/docs/http/ngx_http_access_module.html

Iets in de trant van:

code:

location / {
    deny from all;
    allow from ....; # ip adressen
   
    proxy_pass http://your-internal-docker-service-ip:1234;
}

Wil je al het verkeer afschermen en er alleen maar lokaal bijkunnen zou ik een VPN zeker wel overwegen. Wireguard is echt heel simpel te installeren en je hoeft je er nooit meer mee af te vragen of er stiekem toch nog iets bereikbaar is van buitenaf wat je niet had gewild. Je zou zelfs uberhaupt het publieke IP-adres los kunnen koppelen van je VPS.

Tot slot bieden VPS-leveranciers vaak ook firewall-mogelijkheden buiten de VPS om, het loont ook de moeite dat even te checken.

[ Voor 31% gewijzigd door drm op 15-08-2024 17:15 ]

[Hero of Time]

Het via iptables doen is echter wel efficiënter, want het wordt dan al gelijk op kernel niveau tegen gehouden, ipv dat nginx het eerst moet verwerken en dan door de regel weer te droppen. Met een laag volume merk je het niet zo, maar als er meer verbindingen komen, zal je wel performance verschil gaan zien.

[ironheart]

Ik prefereer het liever zelf ook al direct aan de ‘gate’ in plaats van pas in het vliegtuig.