Publicera server via DNAT till Sophos Firewall

Med DNAT publicerar du en intern server via en offentlig IP-adress eller en offentlig port. Sophos Firewall vidarebefordrar sedan inkommande trafik till den interna målservern. Typiska exempel är webbservrar, omvända proxyservrar, VPN-gateways eller andra tjänster i en DMZ.

För det bredare hardening-sammanhanget passar hubben Sophos Firewall Hardening: best practices för säker konfiguration.

Artikeln förklarar vilka punkter du bör kontrollera före och efter en DNAT-regel och hur du säkrar releasen så nära som möjligt.

Planering innan publicering

Inför en DNAT release bör det stå klart om tjänsten verkligen behöver vara allmänt tillgänglig och vilken teknisk variant som är bäst lämpad. God planering förhindrar öppna portar, dubbletter av NAT regler och svåra att spåra returvägar.

Krav

• Offentlig IP-adress eller WAN-gränssnitt
• Intern server med fast IP-adress
• Känd tjänst och port, till exempel TCP 443
• Lämplig brandväggsregel
• Valfritt: IPS, webbserverskydd eller omvänd proxy beroende på tjänsten

⚠️ DNAT publicerar en intern tjänst till omvärlden. Varje publicerad tjänst ökar attackytan. Endast det som verkligen är nödvändigt ska publiceras. Källa, hamn och destination ska vara så smala som möjligt.

Förtydliga i förväg

Innan du ställer in kontrollsystemet bör du svara på dessa frågor:

• Vilket offentligt IP- eller WAN-gränssnitt används?
• Vilken extern port ska vara tillgänglig?
• Vilken intern IP vidarebefordras till?
• Förblir porten densamma eller är den översatt?
• Bör åtkomst tillåtas överallt eller endast från vissa källnätverk?
• Måste källan NAT eller Reflexive NAT beaktas?
• Finns det ett behov av en Loopback-regel för interna klienter som använder den offentliga FQDN?
• Kommer endast en intern server att publiceras eller flera servrar med Load Balancing?
• Finns det redan en regel som använder samma port?
• Finns Sophos Firewall direkt på Internet eller bakom en leverantörsrouter?
• Behöver ytterligare regler öppnas i en Cloud Security Group?

Denna information förhindrar senare konflikter med befintliga NAT eller brandväggsregler.

Om termerna Original source, Original destination, Translated destination, Translated service, Loopback eller Reflexive Rule fortfarande är oklara bör du först läsa NAT för att förstå Sophos Firewall: SNAT, DNAT, MASQ, PAT. Den här sidan fokuserar på den specifika publiceringen av en intern tjänst.

DNAT, WAF, VPN eller ZTNA?

Inte alla offentligt tillgängliga tjänster bör publiceras automatiskt via DNAT. DNAT är tekniskt enkelt, men också väldigt direkt: Brandväggen vidarebefordrar en port till en intern destination. Om detta är vettigt beror på tjänsten, källorna och behovet av skydd.

• Icke-HTTP-tjänst med tydligt definierade källor: DNAT med snäva källbegränsningar, loggning och IPS kan passa.
• Offentlig HTTP- eller HTTPS-applikation: Kontrollera först Sophos Firewall WAF.
• Admin’tcomst asm SSH, RDP eller intern administratörsportal: Det är möjligt att använda VPN, ZTNA eller nästan käll-IP är tillgänglig för öppen DNAT.
• Endast åtkomst för ett fåtal partners eller platser: Föredrar käll-IP, VPN eller plats-till-plats-anslutning.
• Applikationen bör vara tillgänglig internt och externt under samma namn: Kontrollera split DNS eller avsiktligt planerad Loopback regel.

För klassiska webbapplikationer är WAF ofta en bättre utgångspunkt eftersom värdnamn, certifikat, sökvägar, webbskyddsprofiler och eventuellt autentisering kan tas med i beräkningen. För administrativ åtkomst bör DNAT endast användas i undantagsfall. Om en intern tjänst egentligen inte behöver vara offentlig är VPN eller en ZTNA-arkitektur vanligtvis en renare lösning. De befintliga ZTNA grunderna finns i Hur man ställer in Sophos ZTNA och Skapa Sophos ZTNA gateway.

Om brandväggen ligger bakom en router

DNAT fungerar även om Sophos Firewall inte direkt har den offentliga IP-adressen, utan ligger bakom en NAT router från leverantören.

I det här fallet behövs två omdirigeringar:

1. På leverantörsroutern vidarebefordras den offentliga porten till WAN IP:en för Sophos Firewall.
2. På Sophos Firewall vidarebefordras porten till den interna servern via DNAT.

Många leverantörsroutrar erbjuder klassisk portvidarebefordran eller en funktion som Exposed Host eller DMZ Host. Med en exponerad värdfunktion vidarebefordras ofta många eller alla inkommande portar till brandväggen. Detta kan vara praktiskt, men bör säkras medvetet eftersom den faktiska kontrollen då ligger helt hos Sophos Firewall.

Om det inte finns någon fast publik IP kan du använda DynDNS. Sophos Firewall kan ställa in Dynamic DNS så att ett DNS-namn alltid pekar på den aktuella publika IP-adressen. Det är fortfarande viktigt: Portvidarebefordran på leverantörens router måste peka på Sophos Firewall.

Samma princip gäller i molnmiljöer. Med Azure räcker inte regeln DNAT på enbart Sophos Firewall. Dessutom måste lämpliga Inkommande regler öppnas i Network Security Group, annars kommer trafiken inte att nå brandväggen alls.

DNAT och konfigurera brandväggsregeln

En serverpublikation består alltid av två delar: NAT-regeln översätter destinationen eller porten, brandväggsregeln tillåter och styr trafiken.

Server Access Assistant eller manuell DNAT regel?

Sophos Firewall erbjuder två sätt att publicera till servrar:

• Serveråtkomstassistent (DNAT): Passar som ett snabbt standardfodral för en enda version. Guiden skapar automatiskt flera regler och placerar dem överst i regelbasen.
• Manuell DNAT-regel: Passar mer komplexa miljöer med alias IP, PAT, Load Balancing, specialkällor eller avsiktlig regeldesign. Varje fält måste ställas in och testas själv.

Guiden kan vara till hjälp eftersom den inte bara skapar en inkommande DNAT-regel, utan beroende på valet skapar den också en Loopback-regel, en reflexiv SNAT-regel och lämplig brandväggsregel. Detta sparar tid, men är ingen ersättning för att kontrollera de skapade reglerna.

Använd Server Access Assistant

Guiden är den snabbaste vägen till en första publicering. Det är särskilt användbart när en enskild intern server måste vara tillgänglig via en WAN-adress och en tydlig tjänst.

Procedur:

1. Öppna Rules and policies > NAT rules.
2. Välj IPv4 eller IPv6.
3. Välj Add NAT rule > Server access assistant (DNAT). Alternativt kan du starta assistenten under Rules and policies > Firewall rules > Add firewall rule.
4. Under Intern server IP-adress välj den interna servern eller ange en IP-adress.
5. Under WAN IP-adress väljer du gränssnittet WAN eller den offentliga IP-adressen.
6. Under Tjänster väljer du den interna tjänsten, till exempel HTTPS.
7. Ställ in de tillåtna källorna under Externa källnätverk och enheter. Any är endast lämplig för offentliga tjänster om tjänsten verkligen behöver vara tillgänglig från hela Internet.
8. Kontrollera regler och spara med Spara och avsluta.

Guiden aktiverar de genererade reglerna direkt och placerar dem överst i NAT och brandväggsregeltabellerna. Det är just därför en granskning är nödvändig efter att du har sparat. En automatiskt genererad regel kan tekniskt sett fungera och fortfarande vara för bred, placerad för högt eller dåligt namngiven för drift.

För automatisk generering av loopback-regeln bör branden vara så kort som WAN-mål. Om en offentlig IP-adress skriven i stället, genererar guiden inte automatiskt samma loopback-logik. Jag skulle vilja säga Split DNS och Loopback NAT.

Efter att ha använt assistenten bör du alltid kontrollera:

• Är NAT och brandväggsregeln i rätt position?
• Är källan verkligen så smal som planerat eller är den fortfarande på Any?
• Skapades en Loopback-regel även om delad DNS skulle vara en renare lösning?
• Har en reflexiv regel skapats som inte behövs för utgående servertrafik?
• Matchar brandväggsregeln målzonen efter NAT och det publika målobjektet före NAT?

För produktiva miljöer är en manuellt namngiven och avsiktligt placerad DNAT-regel ofta lättare att förstå. Guiden är bra för en snabbstart, men reglerna som skapas hör hemma i samma granskning som manuellt skapade regler.

Skapa DNAT regel

Ett typiskt manuellt DNAT-exempel publicerar TCP 443 externt till en intern webbserver i DMZ. Regeln översätter endast måladress och eventuellt målport. Detta ersätter inte en brandväggsregel.

Procedur:

1. Öppna Rules and policies > NAT rules.
2. Välj IPv4 eller IPv6.
3. Välj Add NAT rule > New NAT rule.
4. Ställ in Regelnamn för att tala, till exempel DNAT_WEB_DMZ_HTTPS.
5. Välj Regelposition så att specifika DNAT-regler kommer före allmänna regler.
6. Ställ in Originalkälla på tillåtna externa källor. Använd endast Any för avsiktligt offentliga tjänster.
7. Ställ in Original destination till värdobjektet WAN, den offentliga IP-adressen eller lämpligt WAN-gränssnitt.
8. Ställ in Originaltjänst till den externt tillgängliga tjänsten, till exempel HTTPS.
9. Ställ in Översatt destination (DNAT) till den interna servern eller servergruppen.
10. Lämna Översatt tjänst (PAT) till Original eller ställ in den interna målporten om portvidarebefordran är nödvändig.
11. Medvetet inställt Inkommande gränssnitt. För internetåtkomst är detta vanligtvis gränssnittet WAN; I speciella fall kan Any vara nödvändig.
12. Utgående gränssnitt vid DNAT på interna servrar bör normalt lämnas vid Any så att routing och målzon fungerar korrekt.
13. Loopback, reflexiv regel, lastbalansering och hälsokontroll aktiveras endast om de behövs för tekniska ändamål.
14. Spara och aktivera regeln.

Om endast ett fåtal externa käll-IP-adresser behöver nås, bör den ursprungliga källan inte vara Any, utan bör vara begränsad till dessa källor.

För produktionsutgåvor är ett värdobjekt för den offentliga IP-adressen vanligtvis renare än att direkt välja ett WAN-gränssnitt. Objektet förblir spårbart om gränssnitt, aliasadresser eller leverantörsdetaljer ändras senare.

Förstå originalet och korrekt översatt

För NAT-regler är skillnaden mellan Original och Översatt viktig.

• Original källa/destination/tjänst beskriver trafiken när den anländer till Sophos Firewall.
• Översatt källa/destination/tjänst beskriver trafiken när den lämnar Sophos Firewall efter översättning.

För en inkommande DNAT-regel betyder detta:

• Original destination är den offentliga IP-adressen eller WAN-adressen för brandväggen.
• Originaltjänst är den externa porten som klienten adresserar.
• Översatt destination (DNAT) är den interna servern.
• Översatt tjänst (PAT) är den interna porten på målservern om porten ska översättas.
• Översatt källa (SNAT) stannar oftast på Original med normala DNAT-regler.

Portvidarebefordran och PAT

Port forwarding är tekniskt sett en tjänsteöversättning. På Sophos Firewall används Översatt tjänst (PAT) för detta.

Exempel:

• Externt: TCP 20120
• Internt: TCP 22

Den externa klienten ansluter till port 20120, men Sophos Firewall vidarebefordrar internt till SSH port 22. Detta kan vara användbart, men det ersätter inte åtkomstbegränsningar. Att ändra den externa porten kan minska en del bakgrundsljud, men det gör inte en tjänst säker.

Viktigt: Protokollet måste förbli detsamma. TCP kan översättas till en annan TCP-port, UDP till en annan UDP-port. TCP till UDP är inte en giltig portöversättning.

När du publicerar HTTPS måste du också kontrollera om det finns konflikter med WebAdmin eller User Portal av Sophos Firewall. Som standard använder administratörskonsolen HTTPS-port 4444, User Portal använder HTTPS-port 443. Om det finns överlappningar måste brandväggens egna portar eller de publicerade tjänsterna vara tydligt separerade.

Planera medvetet käll-IP och returväg

För en normal DNAT-version bör Översatt källa (SNAT) mestadels förbli på Original. Då ser den interna servern den verkliga externa käll-IP:n. Detta är viktigt för serverloggar, hastighetsgränser, Fail2Ban-liknande skyddsmekanismer, applikationsloggar, WAF eller omvänd proxyutvärdering och senare incidentanalys.

SNAT till brandväggen eller en intern adress kan fortfarande vara nödvändig om returvägen annars inte går via Sophos Firewall. Detta är möjligt, till exempel om den publicerade servern använder en annan standardgateway, är i ett främmande routingsegment eller har en asymmetrisk routingsituation.

Beslutet bör fattas medvetet:

• Källan kvarstår Original: Servern ser den verkliga externa IP-adressen. För att göra detta måste returvägen löpa rent över brandväggen.
• Källan är översatt via SNAT: Returvägen är lättare att kontrollera. För detta ser servern bara brandväggen eller SNAT IP, och den verkliga klientens IP går förlorad i serverloggen.

Om en tjänst bara fungerar med SNAT, bör du inte hålla fast vid den direkt och bocka av ämnet. Det är bättre att först kontrollera om gatewayen, rutten, VLAN, serverns brandvägg eller routingdesign kan korrigeras. SNAT kan vara en legitim lösning, men gör senare analyser svårare.

När du testar bör du alltid kontrollera vilken käll-IP-server som faktiskt ser. I slutet av brandväggs-IP-visum är tillgängliga för extern klient-IP, endast de tydliga dokumenten är tillgängliga.

Kontrollera brandväggsregeln

En NAT-regel tillåter inte automatiskt trafik. Dessutom krävs en lämplig brandväggsregel.

Med DNAT är vyn i brandväggsregeln ovanlig eftersom brandväggen samtidigt måste känna till den ursprungliga åtkomsten utifrån och det översatta interna målet.

Den viktigaste tumregeln:

⚠️ För DNAT använder brandväggsregeln målzonen efter NAT, men målnätverket före NAT.

Processen är viktig: När trafik kommer, letar Sophos Firewall först efter den lämpliga DNAT-regeln och bestämmer därigenom det översatta målet. Brandväggsregeln matchas sedan. För Destinationszonen använder brandväggen zonen där den översatta destinationen finns. Det ursprungliga målobjektet från regeln DNAT förblir dock relevant för Destinationsnätverk.

Typiskt uppdrag:

• Källzon: Vanligtvis WAN om åtkomsten kommer från Internet.
• Källnätverk och enheter: Så begränsat som möjligt, till exempel enskilda IP-adresser, nätverk, länder eller grupper.
• Destinationszoner: Zon för den interna servern enligt DNAT, till exempel DMZ eller SERVER.
• Destinationsnätverk: Offentlig destinationsadress eller WAN värdobjekt från Original destination.
• Tjänster: Extern tjänst från Original service, d.v.s. porten som klienter kommer åt utifrån.
• Säkerhetsprofil: Beroende på tjänst, IPS, skanning av skadlig programvara, webbpolicy eller annan lämplig kontroll.
• Loggning: Aktivera för publicerade tjänster.

Utan en lämplig brandväggsregel avvisas trafik trots DNAT.

Den här punkten är en vanlig felkälla: Om den interna servern anges som destinationsnätverk trots att regeln förväntar sig det offentliga WAN-objektet matchar regeln inte. Den exakta logiken förklaras mer utförligt i artikeln NAT på Sophos Firewall förstå: SNAT, DNAT, MASQ, PAT.

Ordern gäller även NAT regler. Sophos kontrollerar NAT regler uppifrån och ned och använder den första matchningsregeln. En NAT-regel ovan som är för generell kan därför förhindra att den specifika DNAT-regeln träder i kraft.

Befintliga anslutningar behåller sin NAT-översättning, även om du senare ändrar regeln NAT. När du testar efter en förändring bör du därför skapa nya sessioner eller renodla gamla anslutningar, annars kan du fortfarande utvärdera ett gammalt tillstånd.

Avancerade NAT-alternativ

Dessa alternativ blir bara relevanta när interna klienter använder offentliga namn, retursökvägar måste översättas specifikt eller flera målservrar är inblandade.

Loopback, Reflexive och Linked NAT Rules

Sophos Firewall erbjuder flera NAT-alternativ som lätt kan förväxlas:

• Loopback regel: Hjälper när interna klienter ska nå en intern server via den offentliga IP-adressen eller offentliga DNS-namnet.
• Reflexive-regel: Skapar en spegling av SNAT-regeln till en DNAT-regel så att returtrafik eller vissa motsatta riktningar översätts på lämpligt sätt.
• Länkad NAT-regel: Skapad från en brandväggsregel och är en länkad SNAT-regel. En länkad NAT-regel är inte samma sak som en inkommande DNAT-regel för en publicerad server.

För klassiska serverpublikationer är vanligtvis en oberoende DNAT-regel plus en lämplig brandväggsregel den tydligaste. Linked NAT Rules kan vara användbart om en brandväggsregel direkt kräver en speciell SNAT-översättning. Men i allmänna miljöer tenderar fristående, tydligt namngivna NAT-regler att förbli lättare att förstå och underhålla.

Viktigt: Loopback och reflexiva regler härleds från den ursprungliga DNAT-regeln. Om den ursprungliga DNAT-regeln senare ändras, bör man kontrollera de härledda reglerna separat. Annars kan det hända att den externa åtkomsten har justerats korrekt, men interna Loopback-åtkomster eller utgående servertrafik fortsätter att köras enligt den gamla logiken.

Detta är inte en kosmetisk detalj. Sophos skapar Loopback och reflexiva regler med hänvisning till namn och ID för den ursprungliga DNAT regeln, men efterföljande ändringar av den ursprungliga regeln uppdaterar inte automatiskt de härledda reglerna. Efter ändringar av den offentliga IP-adressen, målservern, tjänsten eller källorna bör dessa regler därför medvetet öppnas och jämföras.

Load Balancing och Health Check

Om flera interna servrar publiceras bakom en offentlig IP kan DNAT också användas för Load Balancing eller failover.

Möjliga metoder är till exempel:

• Round Robin
• Först vid liv
• slumpmässigt
• Sticky IP
• En-till-en

Om du vill att brandväggen ska upptäcka om en målserver är tillgänglig måste en Hälsokontroll konfigureras. Utan Health Check kan brandväggen även vidarebefordra trafik till en server som inte kan nås.

Säkring och gå-live

En publicerad tjänst är omedelbart en del av den offentliga attackytan. Det är därför nära åtkomst, loggning, säkerhetsprofiler och en tydlig rollback är en del av go-live.

Planera start och återställning

En DNAT-version bör behandlas som en liten produktionsändring. Så snart regeln är aktiv kan tjänsten nås från Internet. Därför bör det, innan start, vara klart vilken regel som kommer att aktiveras, hur åtkomst kommer att testas och hur man går tillbaka om det uppstår problem.

Kolla innan du sätter igång:

• Säkerhetskopiera den aktuella brandväggskonfigurationen eller åtminstone dokumentera de berörda NAT och brandväggsreglerna.
• Kontrollera befintliga NAT-regler för samma publika IP, extern port och WAN-gränssnitt.
• Matcha leverantörens router, molnsäkerhetsgrupp eller uppströms brandväggsregler med Sophos-konfigurationen.
• Överväg DNS-TTL när ett värdnamn pekar om till den publicerade adressen.
• Förbered en testkälla utanför din egen LAN, till exempel mobiltelefon, extern plats eller kontrollerat onlineporttest.
• Ange förväntade loggplatser: Log Viewer, NAT Rule ID, brandvägg Rule ID, Packet Capture och serverlogg.
• Definiera återställningskriterier, till exempel fel tjänst tillgänglig, servern svarar inte, certifikatfel, säkerhetsprofilen blockerar legitim trafik eller oväntad käll-IP på servern.

En enkel återställning innebär vanligtvis att den nya DNAT-regeln och den matchande brandväggsregeln inaktiveras. Om en gammal publikation har ersatts bör det framgå om den gamla regeln kan återaktiveras eller om leverantörsportvidarebefordran, DNS eller övervakning måste återställas först.

För kritiska tjänster bör du inte ändra flera saker samtidigt. Om DNS, leverantörsrouter, NAT-regel, brandväggsregel och serverkonfiguration justeras samtidigt, kommer ett fel att vara svårt att tillskriva senare. En kort process med tydliga steg är bättre: förbered, aktivera, testa externt, kontrollera loggar, kontrollera servrar, dokumentera resultat.

Begränsa åtkomsten så nära som möjligt

Alla publicerade tjänster behöver inte vara tillgängliga från hela Internet. Om möjligt bör tillgången begränsas.

Användbara begränsningar:

• Tillåt endast IP-adresser med en källa.
• Tillåt endast kända FQDN-värdar om fjärrplatsen använder dynamiska IP-adresser.
• Endast vissa länder tillåter.
• Blockera uttryckligen vissa länder.
• Tillåt endast åtkomst via VPN.
• Använd och ZTNA-lösning är tillgänglig för direktpublicering.

För administrativa tjänster som SSH, RDP eller interna administratörsportaler är DNAT vanligtvis inte den bästa lösningen. Om åtkomsten inte behöver vara offentlig är VPN eller ZTNA nästan alltid ett bättre val.

Förbättra säkerheten

För publicerade tjänster bör du kontrollera:

• Är servern för närvarande patchad?
• Finns det ett alternativ för WAF eller omvänd proxy?
• Är IPS aktiv på brandväggsregeln?
• Är bara nödvändiga portar öppna?
• Loggas tjänsten?
• Finns det geo-IP, hot feed eller käll-IP-begränsningar?
• Är MFA möjligt om det är en portal?

För webbapplikationer kan Web Server Protection / WAF också vara vettigt istället för ren DNAT.

Bots och Threat Feeds

Offentliga portar som HTTP, HTTPS, SSH eller RDP är ständigt i fokus för bots. Så fort en port är tillgänglig på Internet ser du ofta snabbt anslutningsförsök, skanningar, inloggningsförsök eller utnyttjande av trafik i Log Viewer.

Detta betyder inte automatiskt att servern äventyras. Men det visar att tjänsten är en del av den offentliga attackytan. Vi rekommenderar därför att ytterligare säkra publicerade tjänster med IPS, loggning, smala källor och tredjeparts Threat Feeds.

Threat Feeds förser ständigt brandväggen med aktuella indikatorer på kompromiss, till exempel skadliga IP-adresser eller domäner. Detta gör att brandväggen kan blockera kända angripare, botnät eller skannrar innan de når den publicerade tjänsten.

Mehr dazu: Sophos Firewall Threat Feeds

testa

När du har sparat DNAT-regeln:

• Testa från ett externt nätverk, inte samma sak LAN
• Kontrollera endast den förväntade offentliga porten, skanna inte brett mot utländska adresser
• Log Viewer på brandvägg Rule ID, NAT Rule ID, kontrollera källa, originaldestination, översatt destination och status för tillåten eller avvisad
• Jämför Packet Capture med extern källa, offentlig destination och intern destination
• Kontrollera serverloggar
• Kontrollera synlig käll-IP på målsystemet

Om testet ska utföras från den interna LAN till den offentliga IP-adressen kan en extra hårnål NAT eller en intern DNS lösning behövas.

Testmatris för DNAT-versioner

Ett enda porttest räcker sällan för en produktiv DNAT-version. En liten testmatris som separerar tillåtna och oönskade vägar är bättre. Det betyder att du inte bara kan se om tjänsten är tillgänglig utan också om begränsningar, loggning och returvägar fungerar korrekt.

Användbara testkällor:

• Extern tillåten källa: Testa anslutning från mobiltelefon, extern plats eller partnernätverk för offentlig IP och extern port. Förväntade brandväggar Rule ID och NAT Rule ID måste visas i Log Viewer.
• Extern otillåten källa: Om utgåvan är begränsad till vissa källor bör ett test från en otillåten källa medvetet misslyckas. Annars är källbegränsningen för bred.
• Intern klient med internt DNS namn: Kontrollera om interna användare löser direkt till den interna serverns IP. Detta är ofta renare än Loopback NAT.
• Intern klient med offentlig FQDN: Testa bara om denna åtkomst verkligen behövs. Om det misslyckas, kontrollera först split DNS och lägg inte till Loopback NAT automatiskt.
• Målservern själv: Kontrollera serverlogg, lokal brandvägg, bunden tjänst, certifikat och synlig käll-IP. På så sätt kan du se om servern ser den verkliga externa IP-adressen eller en SNAT-adress.
• Övervakning eller extern Health Check: Verifiera att testet använder samma URL, port och källlogik som verklig övervakning.

Efter varje test bör du bara utvärdera ett fynd: Om trafiken kommer till Sophos Firewall gäller den förväntade NAT-regeln, den förväntade brandväggsregeln gäller, paketet når servern och ett svar returneras. Om flera saker ändras samtidigt är det annars svårt att identifiera nästa fel.

Ett rent DNAT-test jämför tre synvinklar:

• Extern klient: Anslutning till offentlig IP och extern port fungerar eller är avsiktligt blockerad.
• Sophos Firewall: Log Viewer visar den förväntade brandväggen Rule ID och NAT Rule ID.
• Intern server: Tjänsten ser förväntad käll-IP, svarar via rätt gateway och loggar åtkomsten.

Om endast ett av dessa perspektiv undersöks förblir typiska fel oupptäckta. Till exempel, ett framgångsrikt externt porttest säger ännu inte om loggning, IPS, källbegränsningar eller serverägare är korrekt dokumenterade.

Felsökning och drift

Efter go-live ska du inte bara kontrollera om tjänsten är tillgänglig. Viktigt är Log Viewer, NAT Rule ID, brandvägg Rule ID, serverloggar och regelbundna granskningar av gamla utgåvor.

Felsökning

Vanliga misstag:

• Brandväggsregel saknas
• Fel WAN IP vald
• Portvidarebefordran på leverantörens router saknas
• Azure Network Security Group blockerar porten
• Tjänsten körs inte internt
• Servergateway pekar inte på Sophos Firewall
• NAT-regeln är under en annan som träder i kraft i förväg
• Brandväggsregeln använder fel destinationsnätverk för DNAT
• Porten används redan av en annan tjänst
• Loopback saknas när interna klienter använder den offentliga FQDN
• Health Check saknas eller är felaktig när Load Balancing används
• Testning sker från det interna nätverket och inte externt
• Målservern svarar tillbaka via en annan gateway
• En säkerhetsprofil blockerar trafik men söks inte efter i rätt logg

Log Viewer är den viktigaste utgångspunkten för DNAT problem. Där kan du se om trafik anländer, vilken brandväggsregel och vilken NAT-regel som gäller och om trafiken är tillåten eller avvisad. Om träffen inte matchar förväntningarna gäller inte Sophos Firewall-regeln: kontrollera orsaker hjälper.

För djupare felsökning bör du inte bara titta på Sophos Firewall. Om Log Viewer tillåter trafik och Packet Capture visar att paket fortsätter till servern, är orsaken ofta på målsystemet: lokal brandvägg, felaktig standardgateway, tjänst obunden, certifikatproblem, program som lyssnar på en annan port eller uppströms omvänd proxy svarar inte som förväntat.

En snabb klassificering hjälper så att du inte letar på fel ställe:

• Ingen träff visas i Log Viewer: Trafiken når inte brandväggen eller så är fel WAN IP adresserad. Kontrollera leverantörens router, molnsäkerhetsgrupp, offentlig IP och Packet Capture till WAN.
• Brandvägg Rule ID matchar, NAT Rule ID saknas: NAT-regeln matchar inte eller är för låg. Kontrollera Original destination, Original service, Inkommande gränssnitt och NAT sekvens.
• NAT Rule ID matchar, tjänsten svarar inte: Destinationsservern eller returvägen är inte korrekt. Kontrollera serverns brandvägg, standardgateway, routing och Packet Capture mot servern.
• Det fungerar externt, men inte internt via FQDN: Split DNS eller Loopback saknas. Kontrollera intern DNS-upplösning och lägg bara till medvetet Loopback.
• Efter att ha ändrat guiden, fungerar bara en del felaktigt: Härledd Loopback eller reflexiv regel gäller inte längre. Kontrollera genererade NAT och brandväggsregler individuellt.

När Black Hole DNAT hjälper också

Om en tjänst medvetet behöver förbli allmänt tillgänglig, men vissa källor måste fångas upp innan den faktiska publiceringen, kan en DNAT-regel för svart hål ovanför den produktiva DNAT-regeln vara vettig. Detta fungerar till exempel för kända dåliga IP-listor, permanent oönskade länder eller återkommande skannerkällor.

Denna teknik ersätter inte ren frisättning. Produktionsregeln DNAT måste fortfarande vara stram, loggning måste vara aktiv och den publicerade servern måste hållas uppdaterad. Black Hole DNAT är ett extra blocklager före en release, inte den faktiska säkerhetsarkitekturen.

Black Hole DNAT är särskilt användbar i dessa fall:

• Återkommande skannerkällor som träffar samma publicerade tjänst: Källorna kan upphöra att gälla innan den produktiva DNAT-regeln.
• Enskilda länder ska inte ha tillgång till portvidarebefordran: Blockregeln kan placeras ovanför den faktiska DNAT-regeln.
• En bibehållen dålig IP-grupp finns redan: Gruppen kan användas som Original source av regeln för svarta hål.
• En tjänst måste förbli offentlig, men bör ge mindre bottrafik: Den produktiva regeln behålls, oönskade källor fångas upp i förväg.

Black Hole DNAT är inte lämplig för lokala brandväggstjänster som WebAdmin, User Portal, VPN Portal eller SSH för själva brandväggen. Device Access och Local Service ACL undantagsregler ansvarar för detta. För webbservrar över WAF bör du först kontrollera WAF-regeln, blockerade länder, autentisering och WAF-loggar.

Ordningen är viktig: Black Hole DNAT-regeln måste ligga över den produktiva DNAT-regeln. Du bör sedan kontrollera i Log Viewer om blockerade källor verkligen uppfyller regeln för svarta hål och tillåtna källor fortsätter att använda den produktiva NAT och brandväggsregeln. Den exakta proceduren finns i Sophos Firewall: Blockera länder och skadliga IP-adresser.

Driftskontroll

DNAT regler bör kontrolleras regelbundet. Gamla utgåvor är en typisk säkerhetsrisk eftersom publicerade tjänster ofta förblir tillgängliga trots att applikationen för länge sedan har flyttats, ersatts eller bara behövs tillfälligt.

För produktiva DNAT-regler bör följande åtminstone dokumenteras:

• Syfte med release: Det måste senare framgå varför tjänsten överhuvudtaget är allmänt tillgänglig.
• Ansvarig person eller team: Utan ägare tas gamla releaser sällan bort.
• Offentlig IP och extern port: Underlättar granskning, övervakning och extern skanning.
• Intern målserver och målport: Viktigt för servermigreringar, Load Balancing och certifikatändringar.
• Förväntade källor: Hjälper till att avgöra om Any verkligen är nödvändigt.
• Skyddsåtgärder: IPS, WAF alternativ, MFA, Threat Feeds, loggning och patchstatus bör kunna spåras.
• Utgångsdatum eller granskningsdatum: Tillfälliga utgåvor behöver ett tydligt slut.

En meningsfull granskning består inte bara av att titta på regeln. Du bör kontrollera externt om bara de förväntade portarna är öppna, kontrollera i Log Viewer vilka källor som faktiskt kommer åt och kontrollera på målservern om applikationen fortfarande underhålls. Om tjänsten endast behövs internt eller för ett fåtal partners bör VPN, ZTNA, en käll-IP-begränsning eller en WAF-regel omvärderas.

När du tar bort gamla DNAT-regler bör du inte bara ta bort NAT-regeln. Brandväggsregler, värdobjekt, tjänsteobjekt, Loopback-regler, Reflexive-regler, DNS-poster, övervakningskontroller eller vidarebefordran av leverantörsport beror ofta på det. En kort avvecklingsprocess är bättre:

1. Kontrollera de senaste åtkomsterna i Log Viewer.
2. Låt lämplig person eller avdelning bekräfta att tjänsten inte längre behövs.
3. Avaktivera först regeln NAT och lämplig brandväggsregel.
4. Testa externt om porten är stängd.
5. Kontrollera övervakning och serverloggar för fel.
6. Först sedan rensa upp objekt, DNS-poster och leverantörsregler som inte längre krävs.

Om en release fortfarande krävs bör granskningen avslutas med ett konkret resultat: lämna den som den är, begränsa den mer snävt, flytta till WAF, flytta den förbi VPN/ZTNA eller granska den igen med ett utgångsdatum.

FAQ