Publicera server via DNAT på Sophos Firewall

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

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

Planering innan publicering

Innan DNAT släpps 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änst

⚠️ 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 publikt IP- eller WAN-gränssnitt används?
• Vilken extern port ska vara tillgänglig?
• Vilken intern IP vidarebefordras till?
• Förblir hamnen densamma eller är den översatt?
• Bör åtkomst tillåtas från överallt eller endast från vissa källnätverk?
• Behöver Source NAT eller Reflexive NAT beaktas?
• Finns det ett behov av en loopback-regel för interna klienter som använder det offentliga FQDN?
• Kommer bara en intern server att publiceras eller flera servrar med lastbalansering?
• Finns det redan en regel som använder samma port?
• Finns Sophos-brandväggen direkt på Internet eller bakom en router?
• Behöver ytterligare regler öppnas i en Cloud Security Group?

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

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

DNAT, WAF, VPN eller ZTNA?

Inte alla offentligt tillgängliga tjänster bör automatiskt publiceras 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äv källbegränsning, loggning och IPS.
• Offentlig HTTP- eller HTTPS-applikation: kontrollera först Sophos Firewall WAF.
• Adminåtkomst som SSH, RDP eller intern adminportal: Om möjligt, VPN, ZTNA eller fast käll-IP istället för öppen DNAT.
• Tillgång endast för ett fåtal partners eller platser: Föredrar käll-IP, VPN eller plats-till-plats-anslutning.
• Ansökan ska vara tillgänglig internt och externt under samma namn: Kontrollera delad 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. DNAT bör endast användas för administrativ åtkomst 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-brandväggen 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örens router vidarebefordras den offentliga porten till WAN IP-adressen för Sophos-brandväggen.
2. På Sophos brandvägg 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 noggrant säkras eftersom själva kontrollen då ligger helt hos Sophos brandvägg.

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

Samma princip gäller i molnmiljöer. Med Azure räcker inte DNAT-regeln på Sophos-brandväggen enbart. 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äggsregel

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åtkomstassistent (DNAT): snabb standardfodral för en enda release. skapar automatiskt flera regler och placerar dem överst i regelbasen.
• Manuell DNAT-regel: mer komplexa miljöer med alias IP, PAT, lastbalansering, speciella kä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.

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

• Är NAT- och brandväggsreglerna i rätt läge?
• Är källan verkligen så smal som planerat eller är den fortfarande på Any?
• Skapades en loopback-regel trots att Split DNS skulle vara en renare lösning?
• Skapades en reflexregel 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 DNAT-exempel:

• Originalkälla: Any eller definierade källnätverk
• Ursprunglig destination: WAN-IP eller WAN-gränssnitt
• Originalservice: HTTPS
• Översatt destination: intern server
• Översatt tjänst: oförändrad eller intern destinationsport

Procedur:

1. Öppna Regler och policyer.
2. Byt till området NAT-regler.
3. Välj Lägg till NAT-regel > Ny NAT-regel.
4. Definiera ursprunglig källa, destination och tjänst.
5. Ställ in Translated Destination till den interna servern.
6. Ställ eventuellt in Översatt tjänst.
7. Kontrollera medvetet det inkommande och utgående gränssnittet.
8. 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 produktionsandelar ä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

När det kommer till NAT-regler är skillnaden mellan Original och Översatt viktig.

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

För en inkommande DNAT-regel betyder detta:

• Originaldestination är brandväggens offentliga IP- eller WAN-adress.
• 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 vanligtvis på Original med normala DNAT-regler.

Portvidarebefordran och PAT

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

Exempel:

• Externt: TCP 20120
• Internt: TCP 22

Den externa klienten ansluter på port 20120, men Sophos-brandväggen vidarebefordrar internt på SSH-porten 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.

Om HTTPS publiceras måste du också kontrollera om det finns konflikter med WebAdmin eller användarportalen för Sophos-brandväggen. Som standard använder administratörskonsolen HTTPS-porten 4444, användarportalen använder HTTPS-porten 443. Om det finns överlappningar måste brandväggens egna portar eller de publicerade tjänsterna vara tydligt separerade.

Planera käll-IP och returväg medvetet

För en normal DNAT-utgivning 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 proxy-utvä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 genom Sophos brandvägg. 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 riktig extern IP. Returvägen måste löpa rent genom brandväggen.
• Källa är översatt via SNAT: Returvägen är lättare att kontrollera. Servern ser bara brandvägg eller SNAT IP, riktig klient-IP går förlorad i serverloggen.

Om en tjänst bara fungerar med SNAT, bör du inte bara hålla fast vid den och lämna ämnet bakom dig. Det är bättre att först kontrollera om gateway, rutt, VLAN, serverbrandvägg eller routingdesign kan korrigeras. SNAT kan vara en legitim lösning, men det gör senare analys svårare.

När du testar bör du alltid kontrollera vilken käll-IP servern faktiskt ser. Om endast brandväggs-IP visas istället för extern klient-IP, måste det tydligt dokumenteras 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 synen 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:

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

Typiskt uppdrag:

• Källzon: Mestadels WAN när åtkomst 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 av 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äkerhetsprofiler: 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 du anger den interna servern som målnätverk, trots att regeln förväntar sig det offentliga WAN-objektet, matchar regeln inte. Den exakta logiken förklaras mer i detalj i artikeln Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Beställningen gäller även NAT-regler. Sophos kontrollerar NAT-regler från topp till botten 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.

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 and Linked NAT-regler

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.
• Reflexiv regel: Skapar en speglande SNAT-regel till en DNAT-regel så att returtrafik eller vissa motsatta riktningar översätts på lämpligt sätt.
• Länkad NAT-regel: Skapat från en brandväggsregel och är en länkad SNAT-regel. En länkad NAT-regel är inte detsamma 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. Länkade NAT-regler kan vara användbara 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 extern åtkomst har justerats korrekt, men intern loopbackåtkomst eller utgående servertrafik fortsätter att köras enligt den gamla logiken.

Lastbalansering och hälsokontroll

När flera interna servrar publiceras bakom en offentlig IP kan DNAT även användas för lastbalansering 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 en hälsokontroll kan brandväggen även vidarebefordra trafik till en server som inte kan nås.

Säkring och sätt igång

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-frisättning bör behandlas som en liten produktionsförä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.

Kontrollera före go-live:

• 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, externa 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 ditt eget LAN, till exempel mobiltelefon, extern plats eller kontrollerat online-porttest.
• Ställ in förväntade loggplatser: Loggvisare, NAT-regel-ID, brandväggsregel-ID, paketinsamling och serverlogg.
• Definiera återställningskriterier, till exempel fel tjänst tillgänglig, servern svarar inte, certifikatfel, säkerhetsprofil 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 är ett fel 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 när den andra sidan använder dynamiska IP-adresser.
• Tillåt bara vissa länder.
• Blockera uttryckligen vissa länder.
• Tillåt endast åtkomst via VPN.
• Använd en ZTNA-lösning istället för direktpublicering.

DNAT är vanligtvis inte den bästa lösningen för administrativa tjänster som SSH, RDP eller interna administratörsportaler. 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, hotfeed 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 användbart istället för ren DNAT.

Botar och hotflöden

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 kan du ofta snabbt se anslutningsförsök, skanningar, inloggningsförsök eller utnyttja trafik i loggvisaren.

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 du dessutom säkrar publicerade tjänster med IPS, loggning, smala källor och hotflöden från tredje part.

Hotfeeds förser kontinuerligt 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: Sophos Firewall Threat Feeds

Testa

Efter att ha sparat DNAT-regeln:

• Testa från ett externt nätverk, inte från samma LAN
• Kontrollera endast den förväntade offentliga hamnen, skanna inte brett mot utländska adresser
• Kontrollera Log Viewer för brandväggsregel-ID och NAT-regel-ID
• Jämför paketfångning 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 det interna LAN:et till den publika IP:n kan även hårnåls-NAT eller en intern DNS-lösning vara nödvändig.

Testmatris för DNAT-publiceringar

Ett enda porttest räcker sällan för en DNAT-publicering i produktion. En liten testmatris är bättre eftersom den skiljer tillåtna och oönskade vägar åt. Då ser man inte bara om tjänsten är nåbar, utan även om begränsningar, loggning och returväg fungerar korrekt.

Användbara testkällor:

• Extern tillåten källa: testa anslutningen från mobilnät, extern plats eller partnernät till publik IP och extern port. Förväntad firewall rule ID och NAT rule ID måste visas i Log Viewer.
• Extern källa som inte är tillåten: 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 att interna användare slår upp direkt mot serverns interna IP. Det är ofta tydligare än loopback NAT.
• Intern klient med publik FQDN: testa endast om denna åtkomst verkligen behövs. Om det misslyckas, kontrollera split DNS först och lägg inte automatiskt till loopback NAT.
• Målservern själv: kontrollera serverlogg, lokal firewall, bunden tjänst, certifikat och synlig käll-IP. Då ser man om servern ser den riktiga externa IP-adressen eller en SNAT-adress.
• Övervakning eller extern health check: kontrollera att testet använder samma URL, port och källlogik som den riktiga övervakningen.

Efter varje test bör endast ett fynd bedömas: når trafiken Sophos Firewall, matchar förväntad NAT-regel, matchar förväntad firewallregel, når paketet servern och kommer ett svar tillbaka? Om flera saker ändras samtidigt blir nästa fel mycket svårare att koppla till rätt orsak.

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

• Extern klient: Anslutning till offentlig IP och extern port fungerar eller är avsiktligt blockerad.
• Sophos brandvägg: Log Viewer visar det förväntade brandväggsregel-ID och NAT-regel-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. Ett lyckat externt porttest säger till exempel ännu inte om loggning, IPS, källrestriktioner eller serverägare är korrekt dokumenterade.

Felsökning och drift

Efter go-live ska du inte bara kontrollera om tjänsten är tillgänglig. Loggvisare, NAT-regel-ID, brandväggsregel-ID, serverloggar och regelbundna granskningar av gamla utgåvor är 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
• Servergatewayen pekar inte mot Sophos-brandväggen
• NAT-regeln är under en annan som träder i kraft i förväg
• Brandväggsregeln använder fel destinationsnätverk i DNAT
• Porten används redan av en annan tjänst
• Loopback saknas när interna klienter använder offentliga FQDN
• Hälsokontroll saknas eller är felaktig vid användning av lastbalansering
• 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 det kommer trafik, vilken brandväggsregel och vilken NAT-regel som gäller och om trafiken är tillåten eller avvisad. Om träffen inte stämmer överens med vad som förväntades, Sophos brandväggsregel gäller inte: kontrollera orsaker hjälper.

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

En snabb klassificering hjälper så att man inte felsöker på fel ställe:

• Ingen träff visas i Log Viewer: Trafiken når inte brandväggen eller fel WAN-IP används. Kontrollera leverantörsrouter, Cloud Security Group, offentlig IP och Packet Capture på WAN.
• Firewall Rule ID matchar, men NAT Rule ID saknas: NAT-regeln matchar inte eller ligger för långt ned i ordningen. Kontrollera Original destination, Original service, inkommande gränssnitt och NAT-ordning.
• NAT Rule ID matchar, men tjänsten svarar inte: Målservern eller returvägen är inte korrekt. Kontrollera serverbrandvä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 loopback medvetet.
• Efter en ändring i guiden beter sig bara en del fel: En genererad loopback- eller reflexive-regel passar inte längre. Kontrollera genererade NAT- och brandväggsregler var för sig.

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 avlyssnas före själva 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. Den produktiva DNAT-regeln 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ändbart i dessa fall:

• Återkommande skannerkällor träffade samma publicerade tjänst: Källorna kan komma till ingenting innan den produktiva DNAT-regeln.

• Enskilda länder ska inte ha tillgång till port forwarding: 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 i Black Hole Rule.

• En tjänst måste förbli offentlig, men bör uppnå 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 till själva brandväggen. Device Access och Local Service ACL-undantagsregler är ansvariga för detta. För webbservrar via 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 loggvisaren 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 Brandvägg: Blockera länder och skadliga IP-adresser.

Funktionskontroll

DNAT-reglerna bör ses över 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:| punkt | Varför det är viktigt |

• Syftet med utgivningen: Senare ska det stå klart varför tjänsten överhuvudtaget är allmänt tillgänglig
• Ansvarig person eller team: Utan ägare tas gamla aktier sällan bort
• Offentlig IP och extern port: Underlättar testning, övervakning och externa skanningar
• Intern målserver och målport: Viktigt för servermigreringar, lastbalansering 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, hotfeeds, loggning och patchstatus bör kunna spåras
• Sista 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 loggvisaren 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, reflexiva regler, DNS-poster, övervakningskontroller eller leverantörsportvidarebefordran är ofta kopplade till den. En kort avvecklingsprocess är bättre:

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

Om tillstånd fortfarande krävs, bör granskningen avslutas med en konkret slutsats: lämna den som den är, begränsa den mer snävt, byt till WAF, flytta den bakom VPN/ZTNA eller undersök om med ett utgångsdatum.

Vanliga frågor