Publicera en server via DNAT på Sophos Firewall

Med DNAT publiceras en intern server via en publik IP-adress eller port. Sophos Firewall vidarebefordrar sedan inkommande trafik till den interna målservern. Typiska exempel är webbservrar, reverse proxy-servrar, VPN-gateways och 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 vad som ska kontrolleras före och efter att en DNAT-regel skapas och hur publiceringen begränsas och säkras så långt som möjligt.

Planering innan publicering

Innan en tjänst publiceras via DNAT ska det vara klart om publik åtkomst verkligen behövs och vilken teknisk variant som passar bäst. God planering förhindrar onödigt öppna portar, dubbla NAT-regler och svårspårade 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 mot omvärlden. Varje publicerad tjänst ökar attackytan. Endast det som verkligen behövs ska publiceras. Källa, port och destination ska begränsas så långt som möjligt.

Förtydliga i förväg

Följande frågor ska besvaras innan regeln konfigureras:

• 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 Source 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.
• Administrativ åtkomst som SSH eller RDP: Använd Clientless SSL VPN för enskilda fasta mål, annars VPN, ZTNA eller en fast käll-IP i stället för öppen DNAT.
• Endast åtkomst för ett fåtal partners eller platser: Föredra käll-IP-begränsning, VPN eller en site-to-site-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 själv har den publika IP-adressen utan ligger bakom leverantörens NAT-router.

I det här fallet krävs två portvidarebefordringar:

1. På leverantörsroutern vidarebefordras den publika porten till Sophos Firewalls WAN-IP.
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.

Med en extra publik IPv4-adress i ett direkt anslutet WAN-segment kan den föregående ARP-upplösningen fortfarande saknas. Det separata förfarandet för att konfigurera Proxy ARP på Sophos Firewall passar endast när en capture bevisar förfrågan och brandväggens uteblivna svar; DNAT kräver inte detta manuella steg generellt.

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.

Konfigurera DNAT och 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 servrar:

• Server access assistant (DNAT): passar som ett snabbt standardalternativ för en enskild publicering. 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, särskilda källor eller en medveten regeldesign. Varje fält måste konfigureras och testas individuellt.

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 Internal server IP address väljs den interna servern eller anges en IP-adress.
5. Under WAN IP address väljs WAN-gränssnittet eller den publika IP-adressen.
6. Under Services väljs den interna tjänsten, till exempel HTTPS.
7. Under External source networks and devices anges de tillåtna källorna. Any passar bara när tjänsten verkligen måste vara nåbar från hela Internet.
8. Granska reglerna och spara med Save and finish.

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 att en loopback-regel ska skapas automatiskt måste ett brandväggsgränssnitt väljas som WAN-mål. Om en publik IP-adress anges i stället skapar guiden inte automatiskt samma loopback-logik. I många miljöer är Split DNS dessutom tydligare än 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å Original och Translated korrekt

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

Vid en normal DNAT-publicering bör Translated source (SNAT) vanligtvis ligga kvar på Original. Den interna servern ser då den verkliga externa käll-IP-adressen. Det är viktigt för serverloggar, rate limits, Fail2Ban-liknande skydd, applikationsloggar, WAF- eller reverse proxy-analys och senare incidentutredning.

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 förblir Original: Servern ser den verkliga externa IP-adressen. Returvägen måste då gå korrekt via brandväggen.
• Källan översätts med SNAT: Returvägen blir enklare att kontrollera. Servern ser då bara brandväggens eller SNAT-adressens IP, och den verkliga klient-IP-adressen 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.

Vid test ska det alltid kontrolleras vilken käll-IP-adress servern faktiskt ser. Om endast brandväggens IP-adress visas i stället för den externa klientens IP måste det vara tydligt dokumenterat om detta är avsiktligt.

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.

Ordningen är viktig: Vid inkommande trafik söker Sophos Firewall först efter den matchande DNAT-regeln och fastställer därmed den översatta destinationen. Därefter matchas brandväggsregeln. För Destination zone används zonen där den översatta destinationen finns. För Destination networks är däremot det ursprungliga målobjektet från DNAT-regeln fortfarande relevant.

Typisk tilldelning:

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

Ordningsföljden gäller även NAT-regler. Sophos kontrollerar dem uppifrån och ned och använder den första matchande regeln. En alltför generell NAT-regel högre upp kan därför hindra den specifika DNAT-regeln från att träffa.

Befintliga anslutningar behåller sin NAT-översättning även om NAT-regeln senare ändras. Testa därför med nya sessioner eller avsluta gamla anslutningar korrekt; annars kan resultatet fortfarande återspegla det tidigare tillståndet.

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äkerhet och driftsättning

En publicerad tjänst blir omedelbart en del av den publika attackytan. Därför ingår snävt begränsad åtkomst, loggning, säkerhetsprofiler och en tydlig rollback i driftsättningen.

Planera driftsättning och rollback

En DNAT-publicering ska behandlas som en mindre produktionsändring. Så snart regeln är aktiv kan tjänsten bli nåbar från Internet. Före driftsättningen ska det därför vara dokumenterat vilken regel som aktiveras, hur åtkomsten testas och hur rollback genomförs vid problem.

Kontrollera före driftsättningen:

• 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 definierade käll-IP-adresser.
• Tillåt endast kända FQDN-värdar om fjärrplatsen använder dynamiska IP-adresser.
• Tillåt endast vissa länder.
• Blockera uttryckligen vissa länder.
• Tillåt endast åtkomst via VPN.
• Använd en ZTNA-lösning i stället för direkt publicering.

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.

Mer information finns i Sophos Firewall Threat Feeds.

Testa

När du har sparat DNAT-regeln:

• Testa från ett externt nätverk, inte från samma LAN.
• Kontrollera endast den förväntade publika porten och skanna inte brett mot främmande adresser.
• Kontrollera Firewall Rule ID, NAT Rule ID, källa, ursprunglig destination, översatt destination och status för tillåten eller nekad trafik i Log Viewer.
• 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-publiceringar

Ett enda porttest räcker sällan för en DNAT-publicering i produktion. En liten testmatris som skiljer tillåtna och oönskade vägar åt är bättre. Den visar inte bara om tjänsten är nåbar, utan också om begränsningar, loggning och returväg 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 publiceringen är begränsad till vissa källor ska ett test från en otillåten källa avsiktligt 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 driftsättningen räcker det inte att kontrollera om tjänsten är nåbar. Log Viewer, NAT Rule ID, Firewall Rule ID, serverloggar och regelbundna granskningar av äldre publiceringar är också viktiga.

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 vid DNAT-problem. Där syns om trafik anländer, vilken brandväggsregel och NAT-regel som träffar samt om trafiken tillåts eller nekas. Om träffen inte motsvarar förväntningarna hjälper Sophos Firewall-regeln träffar inte: kontrollera orsaker med den fortsatta avgränsningen.

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.

SMTP via DNAT efter uppgradering till SFOS 22

Om inkommande e-post efter en uppgradering till SFOS 22 sporadiskt försenas eller inte levereras alls kan NC-184583 vara orsaken. Sophos anger uttryckligen SFOS 22.0 GA Respin Build 411 som berörd version, men beskriver problemet mer allmänt för uppgraderingar till v22.x. MR1 och MR2 anges inte separat som vare sig berörda eller åtgärdade. Som enda fix anges SFOS 23.0 EAP0 Build 253 – en EAP-version som inte bör ses som en generell rekommendation för produktionssystem. Det finns ingen offentligt dokumenterad workaround; Sophos hänvisar till supporten.

Ett porttest av TCP 25 räcker inte vid detta felmönster. Flera kontrollerade verkliga meddelanden bör skickas och UTC-tid, avsändare, mottagare och Message-ID noteras. Därefter jämförs avsändarens kö eller bounce med kön och Transport Log på den interna e-postservern. Underlaget till supporten bör innehålla firmware-build, tidsstämplar, Rule IDs, fwlog.log, firewall_rule.log, nat_rule.log och e-postserverns loggar. Loggsökvägarna och hämtningen av Consolidated Troubleshooting Report beskrivs i Kontrollera tjänster och loggar i Sophos Firewall via CLI. I supportärendet bör NC-184583 anges uttryckligen.

Known Issue gäller den direkta DNAT-sökvägen till den interna e-postservern. I Sophos Firewall MTA Mode tar brandväggen själv emot meddelandet och vidarebefordrar det sedan. Sophos bekräftar dock varken att MTA Mode säkert inte påverkas av problemet eller att en övergång är den officiella workarounden.

När Black Hole DNAT också hjälper

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.

Tekniken ersätter inte en korrekt säkrad publicering. DNAT-regeln för produktion måste fortfarande vara snävt begränsad, loggning ska vara aktiv och den publicerade servern ska hållas uppdaterad. Black Hole DNAT lägger till ett blockeringslager framför publiceringen, men utgör inte själva 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 fångas upp före 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. Kontrollera sedan i Log Viewer att blockerade källor träffar Black Hole-regeln medan tillåtna källor fortfarande använder de produktiva NAT- och brandväggsreglerna. Den exakta proceduren finns i Sophos Firewall: Blockera länder och skadliga IP-adresser.

Driftskontroll

DNAT-regler ska granskas regelbundet. Gamla publiceringar är en vanlig säkerhetsrisk eftersom tjänster ofta förblir nåbara efter att applikationen har flyttats, ersatts eller inte längre behövs.

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

• Syfte med publiceringen: Dokumentationen ska visa varför tjänsten är publikt nåbar.
• Ansvarig person eller team: Utan ägare tas gamla publiceringar 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 publiceringar behöver ett tydligt slutdatum.

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 publiceringen fortfarande behövs ska granskningen avslutas med ett konkret resultat: behåll den oförändrad, begränsa den ytterligare, flytta den till WAF, placera den bakom VPN/ZTNA eller granska den igen före ett fastställt utgångsdatum.

FAQ