Waarom is een reverse proxy (zoals ik begrijp, een poort op het externe IP-adres blootstellen) veiliger dan gewoon een poort op je router openen? Wat krijg je door je IP te verbergen, als een andere poort dicht is?
Waarom is VPN veiliger dan SSH openstellen? Ze hebben toch dezelfde beveiligingsmaatregelen, toch?
Waarom is VPN veiliger dan SSH openstellen? Ze hebben toch dezelfde beveiligingsmaatregelen, toch?
Ze hebben niet dezelfde beveiligingsmaatregelen. Ze kunnen dezelfde technologie gebruiken om de gegevens tijdens het transport te versleutelen, maar dat is slechts één onderdeel van de beveiliging van die protocollen.
SSH op een openbare poort openen kan veilig zijn, als je weet wat je doet. Maar het is een enkel punt van falen. Eén fout en je machine is nu van iemand anders. SSH in een VPN verpakken verbergt niet alleen het feit dat er SSH op je machine draait, maar voegt er ook een beveiligingslaag bovenop toe. Zelfs als je SSH gecompromitteerd is, heb je nog steeds VPN nodig om het te benaderen. Zelfs als je VPN gecompromitteerd is, heb je nog steeds de SSH-sleutel nodig om in te loggen.
Er is zoveel misinformatie in dit gesprek. Ik ben een beveiligingsprofessional met ervaring in pentesten en beveiligingsengineering.
Een reverse proxy voegt op zich geen beveiligingsvoordeel toe. Het is gewoon een service die een verzoek ontvangt en doorstuurt naar een andere interne service. Het hebben van een reverse proxy die verzoeken doorstuurt naar 10 services, of het direct openen van 10 poorten naar die services, heeft bijna geen invloed op de beveiliging. Als je een kwetsbare service blootstelt via een reverse proxy, is die nog steeds kwetsbaar en de proxy zal verzoeken naar die service sturen alsof die direct op zijn eigen poort werd blootgesteld. Het direct exposeren van veel homelab-diensten of via een reverse proxy is over het algemeen een slecht idee omdat het vaak kleine open source projecten zijn zonder sterke beveiligingspraktijken.
Reverse proxy’s kunnen wel helpen, bijvoorbeeld door extra authenticatie toe te voegen via dingen als Vouch proxy voor nginx, of alles via een webapplicatiefirewall zoals mod_security te sturen om je verkeer te screenen voordat het je services bereikt. In dat opzicht is het zinvol. Maar je zou alleen diensten moeten blootstellen waarvan je zeker weet dat ze veilig zijn.
VPN’s en SSH bieden in principe hetzelfde beveiligingsniveau. SSH kan zwak worden geconfigureerd met wachtwoorden en dat is slecht, maar bij gebruik met publieke sleutelauthenticatie zijn de beveiligingsverschillen minimaal (het zijn vooral functionele verschillen met verschillende functies, maar beide gebruiken sterke cryptografie voor de primaire authenticatiemechanismen).
Als je gebruikmaakt van gemeenschapsprojecten die niet de beste toepassing beveiliging bieden, is een VPN of proxy over het algemeen een veiligere manier om ze bloot te stellen. Dit voegt sterke authenticatie toe voordat het netwerkverkeer naar je potentieel onveilige services kan gaan. Maar er zijn nog steeds afwegingen: een VPN of SSH geeft verkeer toegang tot het hele netwerk onder een standaardinstelling, terwijl een reverse proxy alleen HTTP-verkeer op specifieke poorten of expliciet gedefinieerde services toestaat.
Voor de meeste persoonlijke gebruikssituaties zou ik VPN of SSH aanbevelen. Als je ook vrienden en familie wilt laten deelnemen, zou ik een nginx oauth-plugin gebruiken om je applicatie te beveiligen met Google-login of een andere IdP die je prettig vindt, zodat alleen geauthenticeerde personen toegang krijgen via SSO.
Een reverse proxy beëindigt meestal de TCP-sessie, en maakt een nieuwe verbinding naar de bestemming.
Een blootstelling op de router laat alle pakketten op die poort zonder filtering passeren.
Een voordeel van het beëindigen van de TCP-sessie in de proxy is dat verlies van pakketten na de proxy de proxy kan laten herverzenden, in plaats van alles terug te sturen naar de eindpunt. Je bent ook beschermd tegen ongeldige TCP-pakketten.
Een nadeel van het beëindigen van de TCP-sessie is dat de proxy geheugen gebruikt voor de TCP-buffers aan beide zijden.
Sommige speciale vormen van reverse proxies werken zelfs op het protocolniveau, zoals een HTTP reverse proxy, waarbij één inputstroom naar meerdere servers kan gaan.
Als je 20 verschillende webservers op je externe server wilt draaien… heb je dan 20 verschillende poorten 443?
Wat als je iemand anders’ site op magische wijze wilt laten lijken alsof het jouw site is?
Wat als je niet door hacking je webdashboard en inlogpagina’s tot in de oever wilt beveiligen, maar slechts toegang wilt beperken tot je vrienden en familie?
Dat is waarom je een reverse proxy gebruikt.
Ook je andere vraag, daar ga ik niet eens op in. 
Ik ben verrast dat niemand dit al heeft genoemd. Veel reverse proxies kunnen een WAF-module gebruiken die kwaadaardige communicatie inspecteert en laat vallen.
Je kunt het ook ontcijferen, in Snort inspecteren, doorsturen naar de backend… soort van diepgaande pakketinspectie.
reverse proxy
Gaat niet over beveiliging.
Gewoon een webserver die verantwoordelijk is voor je poort 80/443 en die alles doorstuurt naar andere webservers, meestal gebaseerd op de subdomeinnaam - fuck.voorbeeld.com of werk.voorbeeld.com
Waarom is VPN veiliger dan SSH openstellen? Ze hebben toch dezelfde beveiligingsmaatregelen, toch?
Nee, dat doen ze niet.
De beveiliging van SSH is zwakker dan die van een VPN. Kan heel sterk worden gemaakt, maar nooit zo sterk als een VPN dat niet eens reageert tijdens de verbinding, zoals WireGuard. Voor een hacker is een open UDP-verbinding met WireGuard gewoon een zwart gat van niets, net als een andere gesloten poort.
Een reverse proxy stelt je in staat om precies te controleren wat je gebruiker moet typen om toegang te krijgen tot een specifieke URL-poort combinatie.
Daarnaast laat een reverse proxy je toe om een URL naar een domein-poort socket combo te mappen.
Dit betekent dat de gebruiker het poortnummer niet zou moeten kunnen zien dat wordt gebruikt om de service te draaien, wat een beveiligingspraktijk is.
Gebruikers die het poortnummer weten, is over het algemeen niet goed.
Vervolgens, waarom VPN boven SSH?
Vriend, vraag je of je het apparaat direct via poortforwarding naar SSH moet sturen?
Een VPN fungeert als een tunnel, een extra laag/deur tussen het privé-netwerk en het openbare netwerk die het inkomende verkeer versleutelt via de VPN-server als toegangsroute.
Zonder poortforwarding kun je niet SSH’en naar het lokale netwerk vanaf het externe netwerk (behalve p2p tunneling natuurlijk), dus de vraag moet zijn:
“Wil je extra beveiliging of niet?”
Reverse proxy over open poort?
Nou, het gaat hier niet zo zeer om beveiliging. Het gaat meer om de mogelijkheid om mensen door te sturen naar specifieke poorten zonder dat je :PORT in het adres hoeft te zetten. Dus als je een webserver hebt met 5-6 verschillende websites, gebruiken ze elk verschillende poorten. In plaats van dat mensen de poort moeten invullen, regelt de reverse proxy dat.
VPN over exposing SSH?
Dit is een gemakkelijke. SSH openstellen betekent dat je inlogpagina van een service op internet blootstelt. Je kunt zeker vertrouwen op je gebruikersnaam/wachtwoord-combinatie. Maar er zijn ook manieren om dat te omzeilen, en oudere versies van SSH kunnen worden gekraakt of met een exploit worden omzeild. VPN’s hebben ook exploits, maar VPN is makkelijker te beschermen. En als je VPN is gekraakt, heeft de aanvaller niet een machine in je netwerk met beheerdersrechten om je aan te vallen. Ze moeten nog steeds inbreken in een machine. Dit is gewoon nog een extra laag om je te beschermen. Bovendien kan een VPN op elke poort worden gebruikt, wat een beetje beveiliging via het obscuriteitsprincipe biedt.
Samenvattend:
Waarom een condoom gebruiken in plaats van een plastic boodschappentas?
Nu dit koppelen aan een open SSH-kwetsbaarheid omdat mensen nooit updaten.
Wat krijg je door je huisadres niet op internet te zetten? Maar nog belangrijker, ik denk dat je totaal verkeerd begrijpt wat een reverse proxy is. Reverse proxies verbergen je IP niet, ze sturen eenvoudig verkeer door naar bepaalde locaties op basis van regels in hun configuratiebestanden.
Als je 3 sites host, dan is dat waarschijnlijk de enige manier.
Maar je gaming.AnApexBread.com kan wijzen naar je thuismachine. Creëert dat beveiligingsproblemen?
Als je 20 verschillende webservers op je externe server wilt draaien?….. heb je dan 20 verschillende poorten 443?
Daar weet je nog niet van, ik heb 20 ISPs! /s
Je andere vraag, daar ga ik niet eens op ingaan.
Het is zorgelijk hoe vaak het wordt genoemd. Objectief is het niet zo vaak, maar het is een beetje alsof je een mier vindt. Eén vinden betekent dat je veel meer problemen hebt dan slechts één mier.
Nou, mijn vraag ging meer over het gebruik in een homelab of privé-context, maar zeker, dit is een heel goed punt.
SSH kan ook op elke poort draaien. De rest is geldig.
Zou een simpele accountvergrendeling niet brute-force aanvallen of woordenboekaanvallen voorkomen?
Update alleen VPN-pakketten? 
Automatisch bijwerken is mogelijk.
Dat is objectief en feitelijk onwaar.
Ik denk dat je nog steeds niet begrijpt wat een reverse proxy is.
Een reverse proxy is niet inherent een aparte cloudserver.
De vorige poster heeft al uitgelegd dat het verkeer eenvoudig wordt doorgestuurd op basis van geconfigureerde regels. Het is eigenlijk heel gebruikelijk om een reverse proxy op je lokale apparaat/netwerk te hebben in plaats van te betalen voor een cloud VM. Het is niet dat dat ongebruikelijk is, het is een persoonlijke keuze.
De reverse proxy, op zich, stuurt enkel verkeer door. Je kunt het zo instellen dat het verkeer op heel veel manieren wordt doorgestuurd, inclusief naar volledig willekeurige eindpunten. Het beëindigt het verband bij zichzelf, dus is het de enige computer met externe poorten die naar haar worden doorgestuurd. Vervolgens, als je dat zo instelt, stuurt het het verkeer “door” via de proxy. service1.voorbeeld.voorbeeld wordt doorgestuurd naar 192.168.1.345:8080, terwijl je browser alleen service1.voorbeeld.voorbeeld toont. service2.voorbeeld.voorbeeld wordt doorgestuurd naar 192.168.1.175:8443, en je browser toont alleen service2.voorbeeld.voorbeeld. Daarnaast kunnen ze meestal automatisch SSL-certificaten genereren en beheren voor elke service (en worden ze hiervoor vaak gebruikt). Het vereist niet dat de reverse proxy buiten je netwerk bestaat. Je kunt een enkele webserver/VM gebruiken als reverse proxy voor al je services, en dat draait op dezelfde device (ik ga uit van enige virtualisatie of containerisatie).