- NL
|
41180
netweters
|
17756
gesprekken
|
|
19183
vragen
|
Onderwerpen die langer dan 6 maanden geen reactie krijgen, worden afgesloten. Heb je dezelfde vraag of wil je er toch meer informatie over?
Start dan een nieuw onderwerp op De Netweters. Hoe je dit kan doen, vind je hier
Opgelet! Denk eraan dat er in oude onderwerpen informatie kan staan die niet meer up to date is.
Ik neem aan dat je een https server aktief hebt op interne host 192.168.0.153
Extern zou die nu bereikbaar moeten zijn via https://[extern-ipv4-adres]:8443/
Let er bij de instellingen op dat je de port-forwarding regel aktief zet. Protocol is TCP of eventueel beide.
Eventueel even vanaf je PC de site https://www.watismijnip.be/ bezoeken om je externe/publieke IPv4 adres te verifieren.
De test dien je vanaf het internet te doen, niet vanaf een lokale PC. Het verkeer moet door de HGW gaan.
Eenmaal dat dit werkt is het aan te bevelen je interne PC een vast IP adres te geven (ergens in de reeks 192.168.0.10 - 192.168.0.99.
Nu ontvangt deze namelijk zijn adres via DHCP, en het is mogelijk dat deze eens een ander adres zal ontvangen.
Je kunt daarna ook ipv het externe/publieke IPv4 adres een naam toekennen, gebruikmakende van dyndns. Ik gebruik zelf de service van https://freedns.afraid.org/
Arnie | 
@Arnie zoals ik het lees draait de webserver op poort tcp 8443 en moet die ook van intern op die poort benaderd worden.
Vanaf extern (het internet) is het standaard https/443.
Het wordt trouwens aangeraden om zoveel mogelijk de standaard poorten te gebruiken op het internet, want niet-standaard poorten zoals tcp/8443 worden dikwijls uitgaand geblokkeerd, bijv op de firewall op het werk.
@Steven-E, ik ben akkoord, maar twijfel of dat wel de setup van de vraagsteller is.
Ik vermoed dat hij intern 443 gebruikt, extern 8443. Het kan natuurlijk ook andersom zijn.
Het zou eigenlijk makkelijker zijn zowel intern alsook extern 443 te gebruiken. Dat maakt het ook makkelijker wanneer je bijvoorbeeld vanaf een gsm wilt connecteren, die zich soms intern, soms extern bevind.
@Arnie schreef:@Steven-E, ik ben akkoord, maar twijfel of dat wel de setup van de vraagsteller is.
Ik vermoed dat hij intern 443 gebruikt, extern 8443. Het kan natuurlijk ook andersom zijn.
Het zou eigenlijk makkelijker zijn zowel intern alsook extern 443 te gebruiken. Dat maakt het ook makkelijker wanneer je bijvoorbeeld vanaf een gsm wilt connecteren, die zich soms intern, soms extern bevind.
Klopt. Alleen de vraagsteller zal het mysterie kunnen oplossen 😉
@NofanTasi schreef:
@Steven-E schreef:[...]
Het wordt trouwens aangeraden om zoveel mogelijk de standaard poorten te gebruiken op het internet, want niet-standaard poorten zoals tcp/8443 worden dikwijls uitgaand geblokkeerd, bijv op de firewall op het werk.
Interessant ... waar en door wie, bijvoorbeeld, wordt zulks zo aangeraden en zo uitgelegd?
Ik zal het voor je doen 😉
Op zich kan je je webserver perfect op gelijk welke poort laten draaien. En security-wise is het zelfs geen slechte keuze om iets anders te nemen dan TCP/443. Er wordt immers veel geportscanned op de "wel known ports".
Maar naar functionaliteit toe is het een slechte keuze. Heel veel corporate firewalls, en ook bijv firewalls in hotels/luchthavens/enz laten enkel verkeer toe op de gangbare poorten (TCP 80,443, UDP 53, ...). Als jij dan een publieke webserver gaat draaien op een alternatieve poort en je wil die voor heel de wereld toegankelijk hebben (bijv een webshop), dan sluit je een groot deel van je publiek uit, want je server is voor hen niet bereikbaar, omdat ze achter een firewall zitten die bijv. TCP/8443 niet doorlaat.
@NofanTasi schreef:
Dank voor uitleg. misschien raken we (door mijn schuld) off-topic.
Misschien wat off topic, maar wel interessant.
@NofanTasi schreef:
Maar het gaat hier, denk ik, om persoonlijk gebruik met server achter NAT.
Daar ga ik ook van uit, maar dan zit je nog soms met het issue dat soms uitgaande poorten geblokkeerd worden. Zie verder in dit antwoord.
@NofanTasi schreef:Ook, waarom zou een hotel of luchthaven, of zelfs een berdrijf, niet standaard poorten uitgaand (i.e. inkomend voor @nilsheyvaert) blokkeren? Is er een of ander voordeel? Sorry dit te vragen.
<knip>
Maar verbieden om op niet standaard poorten buiten te gaan lijkt me vreemd. Zelfs om op niet standaard poorten binnen te komen. Vooral omdat vele protocols in andere richting net zo'n niet standaard (meestal ietwat random, grote) poort kiezen en gebruiken.
Wel, wat dikwijls in bedrijven gedaan wordt, uit security overwegingen, is het toepassen van het "zero trust" principe. https://www.paloaltonetworks.com/cyberpedia/what-is-a-zero-trust-architecture
Dit wil zeggen dat je in eerste instantie alle verkeer wil kunnen zien en inspecteren.
Dit gaat ook gepaard met implementeren van een security policy volgens het "least privilege" principe (of ook wel positive enforcement model genoemd).
In het Nederlands: je wil enkel toelaten wat strict nodig is. En al de rest blokkeer je. En dit zowel voor inkomend als uitgaand verkeer. Dus laat je bijv uitgaande poort TCP 80, 443 en nog een paar andere poorten toe. Maar alle andere poorten zijn dan geblokkeerd door de "default deny" regel op de firewall. https://www.securityweek.com/addressing-cyberattacks-positive-enforcement-model
En dit kan je dan op de firewall nog verder doorgetrekken naar IP adressen, applicaties, AD gebruikersgroepen. Op een Palo Alto firewall, een "next generation firewall" die naast poorten ook de echte applicaties herkent, mede dankzij SSL decryptie, kan je bijv een policy maken:
Source IP: 192.168.1.0/24
Source User: Engineering people
Destination: ANY
Destination port: 443
Application: Google Maps, Facebook, ..
Action: allow
Enkel verkeer dat matcht op alle zaken gedefiniëerd in deze rule, zal doorgelaten worden.
Indien geen andere regels, dan val je op de default deny regel en wordt het verkeer dus geblokkeerd.
Veel bedrijven werken andersom: ze blokkeren bijv de courante bittorrent poorten (en andere zaken die ze niet willen op hun netwerk), en al de rest wordt toegelaten. Het mag duidelijk zijn dat deze werkwijze lang niet zo veilig is.
Ik kan hier uren over doorbomen (ik geef er les over 😉 ), maar neem van me aan dat deze manier van werken zeer veel wordt toegepast. Niet alleen bij bedrijven, maar ook bij heel veel gratis hotspots.
Zo draai ik mijn eigen VPN server ook op https/443, omdat die anders de helft van de tijd onbereikbaar is.
@NofanTasi "de helft van de tijd" is natuurlijk "bij wijze van spreken".
Ik denk dat jij en ik dikwijls in heel andere omgevingen vertoeven, en dus ook andere ervaringen hebben/problemen ondervinden. Ik zit beroepsmatig hele dagen middenin de security problematiek en ben misschien daarom ook niet de referentie.
It's ok to disagree, dus ik stel voor dat we de discussie eventueel offline houden, want het wordt idd nu wat veel off topic 😉
@nilsheyvaert schreef:Het is inderdaad zo dat ik intern 443 draai en buiten 8443 wil beschikbaar maken.
Dat is wat ik al vermoedde. Kijk dan zeker even naar mijn eerdere advies:
- Is de portforwarding correct ingesteld op mijn telenet? Gebruik je het juiste interne IP adres? Protocal TCP (of beide)? Is de regel "aktief"
- Controleer je externe / publieke IP-adres
- Test vanaf het internet via https://[extern-ip-addr]:8443/
