Server publiceren via DNAT op Sophos Firewall

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

In het artikel wordt uitgelegd op welke punten u voor en na een DNAT-regel moet letten en hoe u de vrijgave zo goed mogelijk kunt beveiligen.

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 de buitenwereld. Elke gepubliceerde dienst vergroot het aanvalsoppervlak. Alleen wat echt nodig is, mag gepubliceerd worden. Bron, haven en bestemming moeten zo beperkt mogelijk zijn.

Verduidelijk vooraf

Voordat u het besturingssysteem instelt, moet u de volgende vragen beantwoorden:

• Welke publieke IP- of 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 op internet of achter een router van een provider?
• 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 over het publieke IP-adres beschikt, 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 zichtbare hostfunctie worden vaak veel of alle inkomende poorten doorgestuurd naar de firewall. Dit kan praktisch zijn, maar moet zorgvuldig worden beveiligd, omdat de daadwerkelijke controle dan volledig bij de Sophos-firewall ligt.

Als er geen vast openbaar IP-adres is, kunt u DynDNS gebruiken. Sophos Firewall kan Dynamic DNS zo instellen dat een DNS-naam altijd verwijst naar het huidige openbare IP-adres. Het is nog steeds belangrijk: de port forwarding op de router van de provider moet naar de Sophos-firewall verwijzen.

Hetzelfde principe geldt in cloudomgevingen. Met Azure is de DNAT-regel op de Sophos Firewall alleen niet voldoende. Bovendien moeten de juiste Inkomende regels worden geopend in de Netwerkbeveiligingsgroep, 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:

• ****Servertoegangsassistent (DNAT): snelle standaardkoffer voor een enkele uitgave. creëert automatisch meerdere regels en plaatst deze bovenaan de regelsbasis.
• HAndmatige DNAT-regel: complexere omgevingen met alias IP, PAT, load-balancing, speciale bronnen of doelbewust regelontwerp. Ieder veld dient u zelf in te stellen en te testen.

De wizard kan nuttig zijn omdat deze niet alleen een inkomende DNAT-regel creëert, maar afhankelijk van de selectie ook een loopback-regel, een reflexieve SNAT-regel en de juiste firewallregel creëert. Dit bespaart tijd, maar is geen vervanging voor het controleren van de gemaakte regels.

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 DNAT-voorbeeld:

• Originele bron: Any of gedefinieerde bronnetwerken
• Oorspronkelijke bestemming: WAN-IP of WAN-interface
• Originele dienst: HTTPS
• Vertaalde bestemming: interne server
• Vertaalde dienst: ongewijzigd of interne bestemmingspoort

Werkwijze:

1. Open Regels en beleid.
2. Ga naar het gebied NAT-regels.
3. Selecteer NAT-regel toevoegen > Nieuwe NAT-regel.
4. Definieer oorspronkelijke bron, bestemming en dienst.
5. Stel de Vertaalde bestemming in op de interne server.
6. Stel eventueel de Vertaalde service in.
7. Controleer bewust de inkomende en uitgaande interface.
8. Bewaar en activeer de regel.

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 op SSH-poort 22. Dit kan nuttig zijn, maar vervangt geen toegangsbeperkingen. Het wijzigen van de externe poort kan wat achtergrondgeluid verminderen, maar het maakt een dienst niet veiliger.

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 u ook controleren of er conflicten zijn met WebAdmin of User Portal van de Sophos Firewall. Standaard gebruikt de beheerdersconsole HTTPS-poort 4444, de gebruikersportal gebruikt HTTPS-poort 443. Als er overlappingen zijn, moeten de eigen poorten van de firewall of de gepubliceerde services duidelijk gescheiden zijn.

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 nog steeds nodig zijn als het retourpad anders niet door de Sophos-firewall gaat. Dit is bijvoorbeeld mogelijk als de gepubliceerde server een andere standaardgateway gebruikt, zich in een buitenlands routeringssegment bevindt of een asymmetrische routeringssituatie heeft.

De beslissing moet bewust worden genomen:

• Bron blijft Original: Server ziet echt extern IP Het retourpad moet netjes door de firewall lopen
• Bron wordt vertaald via SNAT: De terugreis is gemakkelijker te controleren Server ziet alleen firewall of SNAT IP, echte client-IP gaat verloren in serverlogboek

Als een dienst alleen met SNAT werkt, moet u er niet zomaar bij blijven en het onderwerp achterwege laten. Het is beter om eerst te controleren of het gateway-, route-, VLAN-, server-firewall- of routeringsontwerp gecorrigeerd kan worden. SNAT kan een legitieme oplossing zijn, maar maakt latere analyse 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:

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

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 door 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.

• Beveiligingsprofielen: Afhankelijk van de dienst, IPS, malwarescan, webbeleid of andere geschikte controle

• Loggen: Inschakelen voor gepubliceerde services

Zonder een geschikte firewallregel wordt verkeer ondanks DNAT afgewezen.

Dit punt is een veelvoorkomende bron van fouten: als u de interne server als doelnetwerk invoert, komt de regel niet overeen, ook al verwacht de regel het openbare WAN-object. De exacte logica wordt gedetailleerder uitgelegd in het artikel NAT begrijpen op Sophos Firewall: SNAT, DNAT, MASQ, PAT.

De volgorde is ook van toepassing op NAT-regels. Sophos controleert de NAT-regels van boven naar beneden en gebruikt de eerste overeenkomende regel. Een te algemene NAT-regel daarboven kan er dus voor zorgen dat de specifieke DNAT-regel niet van kracht wordt.

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.

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 u wilt dat de firewall detecteert of er een doelserver beschikbaar is, moet er een Health check worden geconfigureerd. Zonder een health check kan de firewall het verkeer ook doorsturen naar een server die niet bereikbaar is.

Hedging en go-live

Een gepubliceerde dienst maakt direct deel uit van het publieke aanvalsoppervlak. Daarom maken close access, logging, beveiligingsprofielen en een duidelijke rollback deel uit van 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.
• Stel de verwachte loglocaties in: Log Viewer, NAT Rule ID, Firewall Rule ID, Packet Capture en Server Log.
• 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.

Voor kritieke services moet u niet meerdere dingen tegelijk wijzigen. Als DNS, providerrouter, NAT-regel, firewallregel en serverconfiguratie tegelijkertijd worden aangepast, is een fout later moeilijk toe te schrijven. Beter is een kort proces met duidelijke stappen: voorbereiden, activeren, extern testen, logs controleren, servers controleren, resultaten 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 services moet u 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-, bedreigingsfeed- 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 bedreigingsfeeds

Openbare poorten zoals HTTP, HTTPS, SSH of RDP staan voortdurend in de focus van bots. Zodra een poort op internet toegankelijk is, kun je in de logviewer vaak snel verbindingspogingen, scans, inlogpogingen of misbruik van verkeer zien.

Dit betekent niet automatisch dat de server gecompromitteerd is. Maar het laat zien dat de dienst deel uitmaakt van het publieke aanvalsoppervlak. We raden daarom aan om gepubliceerde services bovendien te beveiligen met IPS, logboekregistratie, beperkte bronnen en bedreigingsfeeds van derden.

Bedreigingsfeeds voorzien de firewall voortdurend van actuele indicatoren van compromittering, bijvoorbeeld kwaadaardige IP-adressen of domeinen. Hierdoor kan de firewall bekende aanvallers, botnets of scanners blokkeren voordat ze de gepubliceerde service 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 Firewallregel-ID en NAT-regel-ID
• 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 Firewallregel-ID en NAT-regel-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 je niet alleen controleren of de dienst bereikbaar is. Logviewers, NAT-regel-ID, firewall-regel-ID, serverlogs en regelmatige beoordelingen van oude releases zijn belangrijk.

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
• De statuscontrole ontbreekt of is onjuist bij gebruik van taakverdeling
• 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 probleemoplossing moet je niet alleen naar de Sophos-firewall kijken. Als de logviewer verkeer toestaat en pakketregistratie laat zien dat pakketten doorgaan naar de server, ligt de oorzaak vaak bij het doelsysteem: lokale firewall, onjuiste standaardgateway, service niet gebonden, certificaatprobleem, toepassing die op een andere poort luistert of upstream 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:

• geval: Waarom het past
• 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. Apparaattoegang en Lokale Service ACL-uitzonderingsregels zijn hiervoor verantwoordelijk. Voor webservers via WAF dient u eerst de WAF-regel, geblokkeerde landen, authenticatie en WAF-logs te controleren.

De volgorde is belangrijk: de Black Hole DNAT-regel moet boven de productieve DNAT-regel staan. Controleer vervolgens in de logviewer of geblokkeerde bronnen daadwerkelijk aan de black hole-regel voldoen en toegestane bronnen de productieve NAT- en firewallregel blijven gebruiken. De exacte procedure kunt u vinden 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 in ieder geval het volgende worden gedocumenteerd:

• punt: Waarom het belangrijk is
• Doel van vrijgave: Later moet duidelijk worden waarom de dienst überhaupt publiek toegankelijk is
• Verantwoordelijke persoon of team: Zonder eigenaar worden oude aandelen zelden verwijderd
• Openbaar IP-adres en externe poort: Faciliteert testen, monitoring en externe scans
• Interne doelserver en doelpoort: Belangrijk voor servermigraties, taakverdeling en certificaatwijzigingen
• Verwachte bronnen: Helpt bepalen of Any echt nodig is
• Beschermende maatregelen: IPS, WAF-alternatief, MFA, bedreigingsfeeds, logging en patchstatus moeten traceerbaar zijn
• Vervaldatum of herzieningsdatum: Tijdelijke releases hebben een duidelijk einde nodig

Een zinvolle beoordeling bestaat niet alleen uit het kijken naar de regel. U dient extern te controleren of alleen de verwachte poorten open staan, in de logviewer te controleren welke bronnen daadwerkelijk worden benaderd en op de doelserver te controleren of de applicatie nog wordt onderhouden. Als de dienst alleen intern of voor een paar partners nodig is, moeten VPN, ZTNA, een bron-IP-beperking of een WAF-regel opnieuw worden geëvalueerd.

Wanneer u oude DNAT-regels verwijdert, moet u niet alleen de NAT-regel verwijderen. Firewallregels, hostobjecten, serviceobjecten, loopback-regels, reflexieve regels, DNS-vermeldingen, monitoringcontroles of port forwarding van providers zijn er vaak aan verbonden. Een kort ontmantelingsproces is beter:

1. Controleer de laatste toegangen in de logviewer.
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