aanmeldingspagina onvelig

[bartman]

hallo

ik heb een bbox3v+ modem en heb de beveiliging op laag gezet want ik wens toegang tot een programmaatje dat in een docker omgeving draait op een pc thuis. wanneer ik nu op het werk in firefox ga naar mijn extern proximus ip adres (217.136 enz) met daarachter poortnummer 80 krijg ik het inlogscherm maar geeft firefox een waarschuwing dat wat ingevoerd wordt kan onderschept worden, er staat ook een slotje met een rode streep door. Zet ik https:// ervoor dan krijg ik geen verbinding? hoe kan ik dat toch beveiligen. het kan niet anders (denk ik) dan dat het via poort 80 gaat

[FullHD]

Als je er https voorzet, dan wordt er verbinding gemaakt met poort 443. Poort 80 dient voor onversleutelde HTTP communicatie, poort 443 voor versleutelde communicatie (HTTPS).

[bartman]

ok dus bij portforwarding voeg ik poort 443 toe aan het intern ipadres van de pc? nu staat er al een lijn met poort 80

[meon]

De poort alleen maakt geen beveiligde verbinding, wél SSL-certificaten en trust.

Behalve je container die jouw programmaatje draait zal je ook een NGINX of zo in Docker moeten draaien om aan SSL-offloading te doen.
Daarnaast zal je ook SSL-certificaten nodig hebben, welke je gratis via Let's Encrypt kan krijgen. Je moet je setup dan wel automatiseren.

Een tutorial gezocht:

[CCatalyst]

Daarnaast zal je ook SSL-certificaten nodig hebben, welke je gratis via Let's Encrypt kan krijgen. Je moet je setup dan wel automatiseren.

Let's Encrypt geeft geen certificaten uit voor IP adressen.

De gebruiker kan zelf een CA aanmaken, deze vertrouwen in zijn truststore, en dan via die CA zelf een 2-jarig certificaat uitgeven voor zijn IP adres zonder langs Let's Encrypt te moeten passeren, zonder zijn certificaat publiek gelogd te krijgen, en zonder elke 3 maanden te moeten hernieuwen.

Indien bereid een waarschuwingspagina te negeren (wat de encryptie niet teniet doet) kan de gebruiker ook een 10-jarig certificaat of zelfs langer uitgeven en dan is het weer een zorg minder.

[bartman]

Zal nog zien of ik er mee doorga want dat is al serieus boven mijn pet.

Verstuurd vanaf mijn SM-G973F met Tapatalk

[meon]

De gebruiker kan zelf een CA aanmaken, deze vertrouwen in zijn truststore, en dan via die CA zelf een 2-jarig certificaat

Als je dan toch die richting uit gaat kan je net zo goed gewoon een self-signed certificaat gebruiken.

Maar inderdaad, het is best wat werk.

[bartman]

kan iemand gemakkelijk uitgelegd eens vertellen op welke manier iemand hetgeen ik als inlog + wachtwoord intik kan onderscheppen? ik gok dat die persoon dan al op mijn extern ip adres moet vallen en dan ziet die ook dat aanmeldscherm? moet die dan eerst één of ander programmaatje op mijn pc zien geinstalleerd te krijgen via een bijlage aan een mail waarop ik dan zou klikken? op het werk zouden onze werkstations toch wel min of meer beveilgd moeten zijn...

[meon]

Realistisch gezien is dat voor elk netwerk-segement dat je niet zelf beheert.

Als je dit dus vanuit een hotelkamer doet via de lokale wifi kan dit zijn: Het hotel (via een package capture op de router), hun provider, een upstream-provider, jouw eigen provider, ... Die zien allemaal jouw wachtwoord in plain text voorbij razen in de HTTP-request.

Als je HTTPS-gebruikt passeert het nog steeds al die punten, maar wordt het berichtenverkeer geëncrypteerd met die certificaten en komt er dus enkel onleesbare ruis voorbij in zo'n package capture.

Als je enkel intern op je eigen netwerk inlogt via het interne IP kan enkel je eigen router dat wachtwoord "zien". Als je intern op jouw extern IP inlogt ziet nog steeds enkel jouw eigen router dit, want de verbinding hoeft niet jouw netwerksegment te verlaten.

[bartman]

Kan ik er van uitgaan dat al die providers toch geen slechte bedoelingen hebben en dat wachtwoord gaan stelen? Of ben ik te naïef?

Verstuurd vanaf mijn SM-G973F met Tapatalk

[CCatalyst]

Kan ik er van uitgaan dat al die providers toch geen slechte bedoelingen hebben en dat wachtwoord gaan stelen?

Uiteraard, alleen weet je niet waar die data tussen de providers nog allemaal passeert, ergens onderweg kan het dus nog opgevist worden.

Doch uiteraard moet je ook realistisch zijn, wie op dat niveau data kan opvissen is doorgaans niet op zoek naar het paswoord van een "programmaatje dat in een docker omgeving draait op een pc thuis". Zij kunnen veel interessantere gegevens dan dat vinden. Het is ook geen sinecure om in die massa data op een backbone te vinden wat men wil, men zal dus eerder gericht te werk gaan en zich concentreren op bepaalde datastromen waarbij verkeer van en naar residentiële IP's doorgaans al niet in aanmerking komt. Het is ook niet alsof jouw paswoord het enige paswoord is dat ze zouden tegenkomen, er worden nog steeds massa's paswoorden in clear-text over het net verstuurd waarvan >99% weinig of geen waarde heeft.

Het gebruik van encryptie is een best practice in dit scenario, maar als het niet gaat hou je best rekening met de andere best practices: paswoord niet hergebruiken ergens anders, maken dat ze vanaf dat docker programma niet in je netwerk kunnen raken, een backup hebben van het programma en de gegevens, enzomeer.

Een VPN kan ook een oplossing zijn voor encryptie als webcertificaten moeilijk te implementeren zijn.