Server publiceren via DNAT op Sophos Firewall

Met DNAT publiceert men een interne server via een publiek IP-adres of een publieke poort. De Sophos Firewall stuurt inkomend verkeer vervolgens door naar de interne doelserver. Typische voorbeelden zijn webservers, reverse proxies, VPN-gateways of andere diensten in een DMZ.

Voor de bredere hardening-context past de hub Sophos Firewall Hardening: best practices voor een veilige configuratie.

Dit artikel legt uit welke punten vóór en na een DNAT-regel moeten worden gecontroleerd en hoe de vrijgave zo strak mogelijk wordt beveiligd.

Plannen vóór publicatie

Voordat DNAT wordt uitgebracht, moet duidelijk zijn of de dienst echt publiek toegankelijk moet zijn en welke technische variant het beste geschikt is. Een goede planning voorkomt open poorten, dubbele NAT-regels en moeilijk te traceren retourpaden.

Vereisten

• Openbaar IP-adres of WAN-interface
• Interne server met vast IP-adres
• Bekende service en poort, bijvoorbeeld TCP 443
• Passende firewallregel
• Optioneel: IPS, Web Server Protection of Reverse Proxy, afhankelijk van de dienst

⚠️ DNAT publiceert een interne dienst naar buiten. Elke gepubliceerde dienst vergroot het aanvalsoppervlak. Publiceer alleen wat werkelijk nodig is. Bron, poort en doel moeten zo strak mogelijk worden begrensd.

Verduidelijk vooraf

Voordat de regel wordt aangemaakt, moeten deze vragen worden beantwoord:

• Welke publieke IP of welk WAN-interface wordt gebruikt?
• Welke externe poort moet toegankelijk zijn?
• Naar welk intern IP-adres wordt doorgestuurd?
• Blijft de port hetzelfde of wordt deze vertaald?
• Moet toegang overal vandaan worden toegestaan ​​of alleen vanaf bepaalde bronnetwerken?
• Moet er rekening worden gehouden met Source NAT of Reflexive NAT?
• Is er behoefte aan een loopback-regel voor interne clients die de openbare FQDN gebruiken?
• Wordt er slechts één interne server gepubliceerd of meerdere servers met load-balancing?
• Is er al een regel die dezelfde poort gebruikt?
• Bevindt de Sophos Firewall zich direct aan internet of achter een providerrouter?
• Moeten er aanvullende regels worden geopend in een Cloud Security Group?

Deze informatie voorkomt latere conflicten met bestaande NAT- of firewallregels.

Als de termen Original source, Original destination, Translated destination, Translated service, Loopback of Reflexive Rule nog steeds onduidelijk zijn, lees dan eerst NAT begrijpen op Sophos Firewall: SNAT, DNAT, MASQ, PAT. Deze pagina richt zich op de specifieke publicatie van een interne dienst.

DNAT, WAF, VPN of ZTNA?

Niet elke publiek toegankelijke dienst zou automatisch via DNAT gepubliceerd moeten worden. DNAT is technisch eenvoudig, maar ook heel direct: de firewall stuurt een poort door naar een interne bestemming. Of dit zinvol is, hangt af van de dienst, de bronnen en de behoefte aan bescherming.

• Niet-HTTP-service met duidelijk gedefinieerde bronnen: DNAT met strenge bronbeperking, logging en IPS.
• Openbare HTTP- of HTTPS-applicatie: controleer eerst Sophos Firewall WAF.
• Beheerderstoegang zoals SSH, RDP of interne beheerdersportal: Indien mogelijk VPN, ZTNA of fixed source IP in plaats van open DNAT.
• Toegang alleen voor enkele partners of locaties: Geef de voorkeur aan bron-IP, VPN of site-to-site-verbinding.
• Applicatie moet intern en extern toegankelijk zijn onder dezelfde naam: Controleer gesplitste DNS of opzettelijk geplande loopback-regel.

Voor klassieke webapplicaties is WAF vaak een beter startpunt omdat er rekening kan worden gehouden met hostnamen, certificaten, paden, webbeschermingsprofielen en optioneel authenticatie. DNAT mag alleen in uitzonderlijke gevallen worden gebruikt voor administratieve toegang. Als een interne dienst niet echt openbaar hoeft te zijn, zijn VPN of een ZTNA-architectuur meestal een schonere oplossing. De bestaande ZTNA-basisprincipes zijn beschikbaar in Sophos ZTNA instellen en Sophos ZTNA Gateway maken.

Als de firewall zich achter een router bevindt

DNAT werkt ook als de Sophos Firewall niet direct het publieke IP-adres bezit, maar achter een NAT-router van de provider staat.

In dit geval zijn er twee omleidingen nodig:

1. Op de router van de provider wordt de openbare poort doorgestuurd naar het WAN IP van de Sophos Firewall.
2. Op de Sophos Firewall wordt de poort via DNAT doorgestuurd naar de interne server.

Veel providerrouters bieden klassieke port forwarding of een functie zoals Exposed Host of DMZ Host. Bij een Exposed-Host-functie worden vaak zeer veel of alle inkomende poorten naar de firewall doorgestuurd. Dat kan praktisch zijn, maar moet bewust worden beveiligd, omdat de eigenlijke controle dan volledig bij de Sophos Firewall ligt.

Als er geen vast publiek IP-adres is, kan DynDNS worden gebruikt. Sophos Firewall kan Dynamic DNS instellen zodat een DNS-naam altijd naar het actuele publieke IP wijst. Belangrijk blijft: de port forwarding op de providerrouter moet naar de Sophos Firewall wijzen.

In cloudomgevingen geldt hetzelfde principe. Bij Azure is de DNAT-regel op de Sophos Firewall alleen niet genoeg. Daarnaast moeten de passende Inbound rules in de Network Security Group worden geopend, anders bereikt het verkeer de firewall helemaal niet.

Configureer DNAT en firewallregel

Een serverpublicatie bestaat altijd uit twee delen: de NAT-regel vertaalt de bestemming of poort, de firewall-regel staat het verkeer toe en controleert het.

Servertoegangsassistent of handmatige DNAT-regel?

Sophos Firewall biedt twee manieren om servers te publiceren:

• Server access assistant (DNAT): past als snelle standaard voor één publicatie. De assistent maakt meerdere regels automatisch aan en plaatst ze bovenaan de regelbasis.
• Handmatige DNAT-regel: past voor complexere omgevingen met alias-IP, PAT, load balancing, speciale bronnen of bewust regeldesign. Elk veld moet zelf worden ingesteld en getest.

De assistent kan nuttig zijn omdat hij niet alleen een inkomende DNAT-regel maakt, maar afhankelijk van de selectie ook een loopback-regel, een reflexieve SNAT-regel en de passende firewallregel aanlegt. Dat bespaart tijd, maar vervangt de controle van de aangemaakte regels niet.

Server Access Assistant gebruiken

De assistent is de snelste weg naar een eerste publicatie. Hij is vooral nuttig wanneer één interne server via een WAN-adres en een duidelijke service bereikbaar moet worden.

Werkwijze:

1. Rules and policies > NAT rules openen.
2. IPv4 of IPv6 kiezen.
3. Add NAT rule > Server access assistant (DNAT) kiezen. Alternatief kan de assistent ook onder Rules and policies > Firewall rules > Add firewall rule worden gestart.
4. Onder Internal server IP address de interne server kiezen of een IP-adres invoeren.
5. Onder WAN IP address het WAN-interface of het publieke IP-adres kiezen.
6. Onder Services de interne dienst kiezen, bijvoorbeeld HTTPS.
7. Onder External source networks and devices de toegestane bronnen instellen. Voor publieke diensten is Any alleen passend als de dienst echt vanuit het hele internet bereikbaar moet zijn.
8. Regels controleren en met Save and finish opslaan.

De assistent activeert de aangemaakte regels direct en plaatst ze bovenaan de NAT- en firewallregeltabellen. Juist daarom hoort na het opslaan een review. Een automatisch aangemaakte regel kan technisch werken en toch te breed, te hoog geplaatst of voor beheer slecht benoemd zijn.

Voor een automatisch aangemaakte loopback-regel moet als WAN-doel een firewallinterface worden gekozen. Als in plaats daarvan een publiek IP-adres wordt ingevoerd, maakt de assistent niet automatisch dezelfde loopback-logica. In veel omgevingen is Split DNS hoe dan ook overzichtelijker dan Loopback NAT.

Controleer na gebruik van de assistent altijd:

• Staan de NAT- en firewallregels op de juiste positie?
• Is de bron echt zo smal als gepland of bevindt deze zich nog steeds op Any?
• Is er een loopback-regel gemaakt, ook al zou Split DNS een schonere oplossing zijn?
• Is er een reflexieve regel gemaakt die niet nodig is voor uitgaand serververkeer?
• Komt de firewallregel overeen met de doelzone na NAT en het openbare doelobject vóór NAT?

Voor productieve omgevingen is een handmatig benoemde en opzettelijk geplaatste DNAT-regel vaak gemakkelijker te begrijpen. De wizard is goed voor een snelle start, maar de gemaakte regels horen in dezelfde review als handmatig gemaakte regels.

DNAT-regel maken

Een typisch handmatig DNAT-voorbeeld publiceert extern TCP 443 naar een interne webserver in de DMZ. De regel vertaalt alleen het doeladres en optioneel de doelpoort. Een firewallregel wordt daardoor niet vervangen.

Werkwijze:

1. Rules and policies > NAT rules openen.
2. IPv4 of IPv6 kiezen.
3. Add NAT rule > New NAT rule kiezen.
4. Rule name duidelijk instellen, bijvoorbeeld DNAT_WEB_DMZ_HTTPS.
5. Rule position zo kiezen dat specifieke DNAT-regels boven algemene regels staan.
6. Original source op toegestane externe bronnen zetten. Alleen bij bewust publieke diensten Any gebruiken.
7. Original destination op het WAN-hostobject, het publieke IP of het passende WAN-interface zetten.
8. Original service op de extern bereikbare service zetten, bijvoorbeeld HTTPS.
9. Translated destination (DNAT) op de interne server of servergroep zetten.
10. Translated service (PAT) op Original laten of de interne doelpoort instellen als Port Forwarding nodig is.
11. Inbound interface bewust instellen. Bij internettoegang is dat meestal het WAN-interface; bij speciale gevallen kan Any nodig zijn.
12. Outbound interface bij DNAT naar interne servers normaal op Any laten, zodat routing en doelzone netjes werken.
13. Loopback, reflexive rule, Load balancing en Health check alleen activeren als ze inhoudelijk nodig zijn.
14. Regel opslaan en activeren.

Als slechts enkele externe bron-IP-adressen moeten worden benaderd, mag de oorspronkelijke bron niet Any zijn, maar moet deze beperkt blijven tot deze bronnen.

Voor productieshares is een hostobject voor het openbare IP-adres doorgaans schoner dan het rechtstreeks selecteren van een WAN-interface. Het object blijft traceerbaar als interfaces, aliasadressen of providergegevens later veranderen.

Begrijp het origineel en correct vertaald

Als het om NAT-regels gaat, is het onderscheid tussen Origineel en Vertaald belangrijk.

• Originele bron / bestemming / service beschrijft het verkeer zoals het binnenkomt bij de Sophos Firewall.
• Vertaalde bron / bestemming / service beschrijft het verkeer zoals het na vertaling de Sophos Firewall verlaat.

Voor een inkomende DNAT-regel betekent dit:

• Oorspronkelijke bestemming is het openbare IP- of WAN-adres van de firewall.
• Originele service is de externe poort die de client adresseert.
• Vertaalde bestemming (DNAT) is de interne server.
• Vertaalde service (PAT) is de interne poort op de doelserver als de poort moet worden vertaald.
• Vertaalde bron (SNAT) blijft meestal op Origineel met normale DNAT-regels.

Port forwarding en PAT

Port forwarding is technisch gezien een servicevertaling. Op de Sophos Firewall wordt hiervoor Translated service (PAT) gebruikt.

Voorbeeld:

• Extern: TCP 20120
• Intern: TCP 22

De externe client maakt verbinding op poort 20120, maar de Sophos Firewall stuurt intern door naar SSH-poort 22. Dat kan zinvol zijn, maar vervangt geen toegangsbeperking. Een gewijzigde externe poort vermindert misschien wat achtergrondruis, maar maakt een dienst niet veilig.

Belangrijk: Het protocol moet hetzelfde blijven. TCP kan worden vertaald naar een andere TCP-poort, UDP naar een andere UDP-poort. TCP naar UDP is geen geldige poortvertaling.

Als HTTPS wordt gepubliceerd, moet ook worden gecontroleerd of er conflicten zijn met WebAdmin of User Portal van Sophos Firewall. Standaard gebruikt de adminconsole HTTPS-poort 4444, het User Portal HTTPS-poort 443. Bij overlappingen moeten de firewall-eigen poorten of de gepubliceerde diensten netjes worden gescheiden.

Plan bron-IP en retourpad bewust

Voor een normale DNAT-release moet Vertaalde bron (SNAT) meestal op Origineel blijven. Vervolgens ziet de interne server het echte externe bron-IP. Dit is belangrijk voor serverlogboeken, snelheidslimieten, Fail2Ban-achtige beveiligingsmechanismen, applicatielogboeken, WAF- of reverse proxy-evaluatie en latere incidentanalyse.

SNAT naar de firewall of een intern adres kan toch nodig zijn als het retourpad anders niet via de Sophos Firewall loopt. Dat is bijvoorbeeld mogelijk wanneer de gepubliceerde server een andere default gateway gebruikt, in een vreemd routingsegment staat of er een asymmetrische routingsituatie bestaat.

De beslissing moet bewust worden genomen:

• Bron blijft Original: de server ziet het echte externe IP. Daarvoor moet het retourpad netjes via de firewall lopen.
• Bron wordt via SNAT vertaald: het retourpad is eenvoudiger te controleren. Daarvoor ziet de server alleen de firewall- of SNAT-IP en gaat de echte client-IP in het serverlog verloren.

Als een dienst alleen met SNAT werkt, moet men dat niet meteen accepteren en het onderwerp afsluiten. Beter is eerst te controleren of gateway, route, VLAN, serverfirewall of routingdesign kunnen worden gecorrigeerd. SNAT kan een legitieme workaround zijn, maar maakt latere analyses moeilijker.

Bij het testen moet je altijd controleren welk bron-IP de server daadwerkelijk ziet. Als alleen het firewall-IP verschijnt in plaats van het externe client-IP, moet duidelijk worden gedocumenteerd of dit opzettelijk is.

Controleer de firewallregel

Een NAT-regel alleen staat niet automatisch verkeer toe. Bovendien is een geschikte firewallregel vereist.

Bij DNAT is de weergave in de firewallregel ongebruikelijk omdat de firewall tegelijkertijd de oorspronkelijke toegang van buitenaf en het vertaalde interne doel moet kennen.

De belangrijkste vuistregel:

⚠️ Bij DNAT gebruikt de firewallregel de doelzone na NAT, maar het doelnetwerk vóór NAT.

De volgorde is belangrijk: bij inkomend verkeer zoekt Sophos Firewall eerst de passende DNAT-regel en bepaalt daardoor het vertaalde doel. Daarna wordt de firewallregel gematcht. Voor Destination zone gebruikt de firewall de zone waarin het vertaalde doel ligt. Voor Destination networks blijft echter het oorspronkelijke doelobject uit de DNAT-regel relevant.

Typische opdracht:

• Bronzone: Meestal WAN als de toegang via internet komt.

• Bronnetwerken en apparaten: Zo beperkt mogelijk, bijvoorbeeld individuele IP’s, netwerken, landen of groepen.

• Bestemmingszones: zone van de interne server na DNAT, bijvoorbeeld DMZ of SERVER.

• Bestemmingsnetwerken: Openbaar bestemmingsadres of WAN-hostobject van Original destination.

• Diensten: Externe service van Original service, d.w.z. de poort waartoe clients van buitenaf toegang hebben.

• Security Profile: afhankelijk van de dienst IPS, Malware Scan, Web Policy of andere passende controle.

• Logging: voor gepubliceerde diensten activeren.

Zonder een geschikte firewallregel wordt verkeer ondanks DNAT afgewezen.

Dit punt is een veelvoorkomende foutbron: als men de interne server als Destination network invoert, hoewel de regel het publieke WAN-object verwacht, matcht de regel niet. De exacte logica wordt uitvoeriger uitgelegd in het artikel NAT begrijpen op Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Ook bij NAT-regels geldt de volgorde. Sophos controleert NAT-regels van boven naar beneden en gebruikt de eerste passende regel. Een te algemene NAT-regel erboven kan daarom verhinderen dat de specifieke DNAT-regel grijpt.

Bestaande verbindingen behouden hun NAT-vertaling, ook wanneer de NAT-regel achteraf wordt gewijzigd. Voor tests na een wijziging moeten daarom nieuwe sessies worden opgezet of oude verbindingen netjes worden beëindigd, anders beoordeelt men mogelijk nog een oude toestand.

Geavanceerde NAT-opties

Deze opties worden alleen relevant als interne clients openbare namen gebruiken, retourpaden specifiek moeten worden vertaald of als er meerdere doelservers bij betrokken zijn.

Loopback, reflexieve en gekoppelde NAT-regels

Sophos Firewall biedt verschillende NAT-opties die gemakkelijk verward kunnen worden:

• Loopback-regel: helpt wanneer interne clients een interne server moeten bereiken via het openbare IP-adres of de openbare DNS-naam.
• Reflexieve regel: Creëert een spiegelende SNAT-regel naar een DNAT-regel, zodat retourverkeer of bepaalde tegengestelde richtingen op de juiste manier worden vertaald.
• Gekoppelde NAT-regel: gemaakt op basis van een firewallregel en is een gekoppelde SNAT-regel. Een gekoppelde NAT-regel is niet hetzelfde als een inkomende DNAT-regel voor een gepubliceerde server.

Voor klassieke serverpublicaties is een onafhankelijke DNAT-regel plus een geschikte firewallregel meestal het duidelijkst. Gekoppelde NAT-regels kunnen handig zijn als een firewallregel rechtstreeks een speciale SNAT-vertaling vereist. In algemene omgevingen blijven stand-alone, duidelijk benoemde NAT-regels echter gemakkelijker te begrijpen en te onderhouden.

Belangrijk: Loopback- en reflexieve regels zijn afgeleid van de oorspronkelijke DNAT-regel. Als de oorspronkelijke DNAT-regel later wordt gewijzigd, moet men de afgeleide regels afzonderlijk controleren. Anders kan het gebeuren dat de externe toegang wel goed is afgesteld, maar dat interne loopback-toegang of uitgaand serververkeer volgens de oude logica blijft verlopen.

Dit is geen cosmetisch detail. Sophos maakt loopback- en reflexieve regels met verwijzing naar naam en ID van de oorspronkelijke DNAT-regel, maar latere wijzigingen aan de oorspronkelijke regel werken de afgeleide regels niet automatisch bij. Na wijzigingen aan publiek IP, doelserver, service of bronnen moeten deze regels daarom bewust worden geopend en vergeleken.

Loadbalancing en statuscheck

Wanneer er meerdere interne servers achter een openbaar IP-adres worden gepubliceerd, kan DNAT ook worden gebruikt voor load-balancing of failover.

Mogelijke methoden zijn bijvoorbeeld:

• Ronde Robin
• Eerste levend
• Willekeurig
• Kleverig IP
• Eén-op-één

Als de firewall moet herkennen of een doelserver beschikbaar is, moet een Health check worden geconfigureerd. Zonder Health Check kan de firewall verkeer ook doorsturen naar een server die niet bereikbaar is.

Beveiliging en go-live

Een gepubliceerde dienst maakt direct deel uit van het publieke aanvalsoppervlak. Daarom horen strakke toegang, logging, Security Profiles en een duidelijke rollback bij de go-live.

Plan go-live en rollback

Een DNAT-release moet worden behandeld als een kleine productiewijziging. Zodra de regel actief is, is de dienst toegankelijk via internet. Daarom moet vóór de livegang duidelijk zijn welke regel wordt geactiveerd, hoe de toegang wordt getest en hoe terug te gaan als er problemen zijn.

Controleer vóór go-live:

• Maak een back-up van de huidige firewallconfiguratie of documenteer in ieder geval de getroffen NAT- en firewallregels.
• Controleer bestaande NAT-regels voor hetzelfde openbare IP-adres, externe poort en WAN-interface.
• Zorg ervoor dat de providerrouter, cloudbeveiligingsgroep of upstream firewallregels overeenkomen met de Sophos-configuratie.
• Overweeg DNS TTL wanneer een hostnaam opnieuw verwijst naar het gepubliceerde adres.
• Bereid een testbron voor buiten uw eigen LAN, bijvoorbeeld mobiele telefoon, externe locatie of gecontroleerde online poorttest.
• Verwachte logplaatsen vastleggen: Log Viewer, NAT Rule ID, Firewall Rule ID, Packet Capture en serverlog.
• Definieer terugdraaicriteria, bijvoorbeeld verkeerde service toegankelijk, server reageert niet, certificaatfout, beveiligingsprofiel blokkeert legitiem verkeer of onverwacht bron-IP op de server.

Een eenvoudige terugdraaiing houdt meestal in dat de nieuwe DNAT-regel en de bijbehorende firewallregel worden uitgeschakeld. Als een oude publicatie is vervangen, moet duidelijk zijn of de oude regel opnieuw kan worden geactiveerd of dat provider port forwarding, DNS of monitoring eerst opnieuw moet worden ingesteld.

Bij kritieke diensten moet men niet meerdere dingen tegelijk wijzigen. Als DNS, providerrouter, NAT-regel, firewallregel en serverconfiguratie tegelijk worden aangepast, is een fout later moeilijk toe te wijzen. Beter is een kort verloop met duidelijke stappen: voorbereiden, activeren, extern testen, logs controleren, server controleren, resultaat documenteren.

Beperk de toegang zo goed mogelijk

Niet elke gepubliceerde dienst hoeft vanaf het hele internet toegankelijk te zijn. Indien mogelijk moet de toegang worden beperkt.

Nuttige beperkingen:

• Sta alleen IP-adressen van één bron toe.
• Sta alleen bekende FQDN-hosts toe als de andere partij dynamische IP’s gebruikt.
• Sta alleen bepaalde landen toe.
• Bepaalde landen expliciet blokkeren.
• Sta alleen toegang toe via VPN.
• Gebruik een ZTNA-oplossing in plaats van directe publicatie.

DNAT is meestal niet de beste oplossing voor administratieve diensten zoals SSH, RDP of interne adminportals. Als de toegang niet openbaar hoeft te zijn, is VPN of ZTNA bijna altijd een betere keuze.

Verbeter de beveiliging

Voor gepubliceerde diensten moet men het volgende controleren:

• Is de server momenteel gepatcht?
• Is er een WAF- of reverse proxy-optie?
• Is IPS actief op de firewallregel?
• Staan alleen noodzakelijke poorten open?
• Is de dienst geregistreerd?
• Zijn er Geo-IP-, Threat-Feed- of bron-IP-beperkingen?
• Is MFA mogelijk als het een portal is?

Voor webapplicaties kan Web Server Protection / WAF ook nuttig zijn in plaats van pure DNAT.

Bots en Threat Feeds

Publieke poorten zoals HTTP, HTTPS, SSH of RDP staan permanent in de focus van bots. Zodra een poort op internet bereikbaar is, ziet men in Log Viewer vaak snel verbindingspogingen, scans, loginpogingen of exploitverkeer.

Dat betekent niet automatisch dat de server gecompromitteerd is. Het toont wel dat de dienst deel uitmaakt van het publieke aanvalsoppervlak. Daarom raden we aan gepubliceerde diensten aanvullend met IPS, logging, strakke bronnen en Third-Party Threat Feeds te beveiligen.

Threat Feeds voorzien de firewall doorlopend van actuele Indicators of Compromise, bijvoorbeeld kwaadaardige IP-adressen of domeinen. Daardoor kan de firewall bekende aanvallers, botnets of scanners blokkeren voordat ze de gepubliceerde dienst bereiken.

Meer: Sophos Firewall-dreigingsfeeds

Testen

Na het opslaan van de DNAT-regel:

• Test vanaf een extern netwerk, niet vanaf hetzelfde LAN
• Controleer alleen de verwachte openbare poort, scan niet breed op buitenlandse adressen
• Controleer Log Viewer op Firewall Rule ID, NAT Rule ID, Source, Original Destination, vertaald doel en toegestane of verworpen status
• Vergelijk pakketopname met externe bron, openbare bestemming en interne bestemming
• Controleer serverlogboeken
• Beheer zichtbare bron-IP op het doelsysteem

Als de test van het interne LAN naar het publieke IP moet worden uitgevoerd, kan ook hairpin NAT of een interne DNS-oplossing nodig zijn.

Testmatrix voor DNAT-publicaties

Een enkele poorttest is zelden genoeg voor een DNAT-publicatie in productie. Beter is een kleine testmatrix die toegestane en ongewenste paden van elkaar scheidt. Zo zie je niet alleen of de dienst bereikbaar is, maar ook of beperkingen, logging en retourpad correct werken.

Zinvolle testbronnen:

• Externe toegestane bron: test de verbinding vanaf mobiel internet, een externe locatie of partnernetwerk naar het publieke IP-adres en de externe poort. In Log Viewer moeten de verwachte firewall rule ID en NAT rule ID verschijnen.
• Externe niet-toegestane bron: als de publicatie tot bepaalde bronnen beperkt is, moet een test vanaf een niet-toegestane bron bewust mislukken. Anders is de bronbeperking te breed.
• Interne client met interne DNS-naam: controleer of interne gebruikers direct naar het interne server-IP oplossen. Dit is vaak netter dan loopback NAT.
• Interne client met publieke FQDN: test dit alleen als deze toegang echt nodig is. Als het mislukt, controleer eerst split DNS en voeg loopback NAT niet automatisch toe.
• Doelserver zelf: controleer serverlog, lokale firewall, gebonden service, certificaat en zichtbaar bron-IP. Zo zie je of de server het echte externe IP of een SNAT-adres ziet.
• Monitoring of externe health check: controleer of de test dezelfde URL, poort en bronlogica gebruikt als de echte monitoring.

Na elke test beoordeel je maar één bevinding: komt het verkeer aan op Sophos Firewall, matcht de verwachte NAT-regel, matcht de verwachte firewallregel, bereikt het pakket de server en komt er antwoord terug? Als meerdere zaken tegelijk worden aangepast, wordt de volgende fout veel moeilijker toe te wijzen.

Een schone DNAT-test vergelijkt drie gezichtspunten:

• Externe klant: Verbinding met openbaar IP-adres en externe poort werkt of wordt opzettelijk geblokkeerd.
• Sophos Firewall: Log Viewer toont de verwachte Firewall Rule ID en NAT Rule ID.
• Interne server: Service ziet het verwachte bron-IP, reageert via de juiste gateway en logt de toegang.

Als slechts één van deze perspectieven wordt onderzocht, blijven typische fouten onopgemerkt. Een succesvolle externe poorttest zegt bijvoorbeeld nog niet of logging, IPS, bronbeperkingen of servereigenaren goed gedocumenteerd zijn.

Probleemoplossing en bewerkingen

Na de go-live moet niet alleen worden gecontroleerd of de dienst bereikbaar is. Belangrijk zijn Log Viewer, NAT Rule ID, Firewall Rule ID, serverlogs en regelmatige reviews van oude vrijgaven.

Problemen oplossen

Veel voorkomende fouten:

• Firewallregel ontbreekt
• verkeerde WAN IP geselecteerd
• Port forwarding op de router van de provider ontbreekt
• Azure Network Security Group blokkeert de poort
• Service draait niet intern
• Servergateway verwijst niet naar de Sophos Firewall
• De NAT-regel valt onder een andere regel die vooraf van kracht wordt
• Firewallregel gebruikt het verkeerde bestemmingsnetwerk in DNAT
• Poort is al in gebruik door een andere dienst
• Loopback ontbreekt wanneer interne clients openbare FQDN gebruiken
• Health Check ontbreekt of is onjuist als Load Balancing wordt gebruikt
• Het testen vindt plaats vanuit het interne netwerk en niet extern
• De doelserver reageert terug via een andere gateway
• Een beveiligingsprofiel blokkeert het verkeer, maar wordt niet opgezocht in de juiste log

De Log Viewer is het belangrijkste startpunt voor DNAT-problemen. Daar kun je zien of er verkeer binnenkomt, welke firewallregel en welke NAT-regel van toepassing zijn en of het verkeer wordt toegestaan ​​of geweigerd. Als de treffer niet overeenkomt met wat werd verwacht, kan Sophos Firewallregel is niet van toepassing: controleer oorzaken helpen.

Voor diepere troubleshooting moet men niet alleen naar de Sophos Firewall kijken. Als Log Viewer het verkeer toestaat en Packet Capture toont dat pakketten naar de server doorgaan, ligt de oorzaak vaak op het doelsysteem: lokale firewall, verkeerde default gateway, dienst niet gebonden, certificaatprobleem, applicatie luistert op een andere poort of een voorgeschakelde reverse proxy reageert niet zoals verwacht.

Een snelle classificatie helpt zodat men niet op de verkeerde plek zoekt:

• Er verschijnt geen hit in Log Viewer: Verkeer bereikt de firewall niet of het verkeerde WAN-IP wordt aangesproken. Controleer providerrouter, Cloud Security Group, publiek IP-adres en Packet Capture op WAN.
• Firewall Rule ID komt overeen, NAT Rule ID ontbreekt: De NAT-regel matcht niet of staat te laag in de volgorde. Controleer Original destination, Original service, inkomende interface en NAT-volgorde.
• NAT Rule ID komt overeen, de service reageert niet: De doelserver of het retourpad klopt niet. Controleer serverfirewall, standaardgateway, routing en Packet Capture richting de server.
• Extern werkt het, maar intern niet via FQDN: Split DNS of loopback ontbreekt. Controleer interne DNS-resolutie en voeg loopback alleen bewust toe.
• Na een wijziging in de wizard gedraagt slechts een deel zich verkeerd: Een afgeleide loopback- of reflexive-regel past niet meer. Controleer de gegenereerde NAT- en firewallregels afzonderlijk.

Wanneer Black Hole DNAT ook helpt

Als een dienst bewust openbaar toegankelijk moet blijven, maar bepaalde bronnen vóór de daadwerkelijke publicatie moeten worden onderschept, kan een zwart gat DNAT-regel boven de productieve DNAT-regel zinvol zijn. Dit werkt bijvoorbeeld voor bekende slechte IP-lijsten, permanent ongewenste landen of terugkerende scannerbronnen.

Deze techniek vervangt geen schone vrijgave. De productieve DNAT-regel moet nog steeds strak zijn, logging moet actief zijn en de gepubliceerde server moet up-to-date worden gehouden. Black Hole DNAT is een extra bloklaag vóór een release, niet de daadwerkelijke beveiligingsarchitectuur.

Black Hole DNAT is vooral nuttig in deze gevallen:

• Terugkerende scannerbronnen raken dezelfde gepubliceerde service: De bronnen kunnen vóór de productieve DNAT-regel op niets uitlopen
• Individuele landen mogen geen toegang hebben tot port forwarding: De blokkeerregel kan boven de eigenlijke DNAT-regel worden geplaatst
• Er bestaat al een onderhouden slechte IP-groep: De groep kan worden gebruikt als Original source van de Black Hole Rule
• Een dienst moet openbaar blijven, maar moet minder botverkeer opleveren: De productieve regel blijft behouden, ongewenste bronnen worden vooraf onderschept

Black Hole DNAT is niet geschikt voor lokale firewalldiensten zoals WebAdmin, User Portal, VPN Portal of SSH naar de firewall zelf. Daarvoor zijn Device Access en Local Service ACL exception rules verantwoordelijk. Voor webservers via WAF moeten eerst de WAF-regel, Blocked countries, Authentication en WAF-logs worden gecontroleerd.

De volgorde is belangrijk: de Black-Hole-DNAT-regel moet boven de productieve DNAT-regel staan. Daarna moet men in Log Viewer controleren of geblokkeerde bronnen werkelijk de Black-Hole-regel raken en toegestane bronnen nog steeds de productieve NAT- en firewallregel gebruiken. De exacte procedure staat in Sophos Firewall: landen en kwaadaardige IP’s blokkeren.

Operationele controle

DNAT-regels moeten regelmatig worden herzien. Oude releases vormen een typisch beveiligingsrisico omdat gepubliceerde diensten vaak toegankelijk blijven, ook al is de applicatie al lang geleden verplaatst, vervangen of slechts tijdelijk nodig.

Voor productieve DNAT-regels moet minimaal zijn gedocumenteerd:

• Doel van vrijgave: Later moet duidelijk worden waarom de dienst überhaupt publiek toegankelijk is
• Verantwoordelijke persoon of team: Zonder owner worden oude vrijgaven zelden verwijderd
• Openbaar IP-adres en externe poort: Faciliteert testen, monitoring en externe scans
• Interne doelserver en doelpoort: belangrijk bij servermigraties, Load Balancing en certificaatwissels
• Verwachte bronnen: Helpt bepalen of Any echt nodig is
• Beschermingsmaatregelen: IPS, WAF-alternatief, MFA, Threat Feeds, logging en patchstatus moeten traceerbaar zijn
• Vervaldatum of herzieningsdatum: Tijdelijke releases hebben een duidelijk einde nodig

Een zinvolle review bestaat niet alleen uit een blik op de regel. Men moet extern controleren of alleen de verwachte poorten open zijn, in Log Viewer nagaan welke bronnen werkelijk toegang zoeken en op de doelserver controleren of de applicatie nog wordt onderhouden. Als de dienst alleen intern of voor enkele partners nodig is, moeten VPN, ZTNA, een bron-IP-beperking of een WAF-regel opnieuw worden beoordeeld.

Bij het verwijderen van oude DNAT-regels moet men niet alleen de NAT-regel verwijderen. Vaak hangen firewallregels, hostobjecten, serviceobjecten, Loopback Rules, Reflexive Rules, DNS-records, monitoringchecks of provider-portforwardings eraan. Beter is een korte decommission-procedure:

1. Laatste toegangen in Log Viewer controleren.
2. Laat de verantwoordelijke persoon of afdeling bevestigen dat de service niet langer nodig is.
3. Deactiveer eerst de NAT-regel en de bijbehorende firewallregel.
4. Test extern of de poort gesloten is.
5. Controleer de monitoring- en serverlogboeken op fouten.
6. Ruim daarna pas objecten, DNS-vermeldingen en providerregels op die niet langer nodig zijn.

Als er nog steeds toestemming nodig is, moet de beoordeling eindigen met een concrete conclusie: laat het zoals het is, beperk het nauwer, schakel over naar WAF, verplaats het achter VPN/ZTNA, of heronderzoek met een vervaldatum.

Veelgestelde vragen