Skanna och testa POP3 och IMAP på Sophos Firewall

Sophos Firewall kan skanna e-post när klienter hämtar den via POP3, POP3S, IMAP och IMAPS. Det gäller både i MTA- och Legacy-läge; menysökvägen till den valfria POP-IMAP-policyn skiljer sig. En policy ensam räcker inte: först en matchande brandväggsregel leder e-posttrafiken genom proxyn och aktiverar de konfigurerade skannings- och TLS-inställningarna.

Det viktigaste acceptanstestet är därför inte en grön omkopplare, utan en verklig hämtning från den avsedda klienten till den avsedda e-postservern. Firewall Rule ID, använd port, certifikatkedja, förhandlad TLS-version och warren.log måste alla stämma överens med den planerade sökvägen.

⚠️ Utan Scan email content i brandväggsregeln som faktiskt matchar tillämpar SFOS inte POP/IMAP-inställningarna eller policyerna. En policy i sig ger inget skydd.

POP/IMAP-skanning i åtta steg

1. Dokumentera klientnätet, e-postservern, protokollen och de portar som faktiskt används.
2. Välj en enda pilotkälla och testa dess befintliga e-posthämtning.
3. Importera den CA som utfärdade e-postserverns certifikat under Certificates > Certificate authorities om den inte redan är betrodd.
4. Ange POP/S and IMAP/S settings och POP and IMAP TLS configuration under Email > General settings.
5. Skapa endast vid behov en POP-IMAP scan-policy för avsändare, mottagare eller meddelandeegenskaper: under Email > Policies and exceptions i MTA-läge eller under Email > Policies i Legacy-läge.
6. Skapa en snäv, loggad brandväggsregel för pilotklienten och e-postservern och aktivera de protokoll som behövs under Scan email content.
7. Verifiera hämtning, TLS-anslutning, Firewall Rule ID och warren.log med ett litet testmeddelande.
8. Lägg till fler klienter först efter positiva och negativa tester och dokumentera återställningsvägen.

Vad POP/IMAP-proxyn skyddar

POP3 och IMAP används för att hämta och hantera meddelanden i en brevlåda. De är inte SMTP, som transporterar meddelanden mellan avsändare, MTA och e-postserver. Guiden för MTA Mode förklarar därför MX, SMTP-routing, relay, spool och SMTP-karantän; den här guiden fokuserar på en klients e-posthämtning.

SFOS skiljer mellan okrypterade eller STARTTLS-uppgraderade portar och varianter som använder TLS från början:

• POP3: TCP 110, med valfri uppgradering till TLS via STARTTLS
• POP3S: TCP 995, TLS från anslutningens början
• IMAP: TCP 143, med valfri uppgradering till TLS via STARTTLS
• IMAPS: TCP 993, TLS från anslutningens början

Nya designer bör använda krypterade anslutningar för e-postklienter. Att välja ett protokoll i SFOS ändrar dock inte klientkonfigurationen. Om klienten använder en annan port eller kringgår den planerade regeln skyddas trafiken inte automatiskt av det valda standardalternativet.

POP/IMAP-skanning kräver en giltig Email Protection-licens. Den ersätter varken skyddet på e-postservern eller skanningen när ett meddelande anländer via SMTP. Särskilt för molnbaserade e-posttjänster måste det först klargöras om leverantören fortfarande tillåter konventionell POP/IMAP-hämtning och om en transparent proxy är kompatibel med leverantörens TLS- och autentiseringskrav.

Fastställ exempel och testgräns

En kontrollerad pilot förhindrar att en felaktig certifikat- eller regelkonfiguration påverkar alla e-postklienter samtidigt. Exemplet använder dokumentationsvärden:

• pilotklient 10.20.30.50 i zonen LAN
• e-postserver mail.example.net
• måladress 192.0.2.25
• använt protokoll IMAPS på TCP 993
• brandväggsregel Pilot_POP_IMAP_Scan

Ersätt 10.20.30.50, mail.example.net och 192.0.2.25 med de riktiga värdena. Måladressen tillhör dokumentationsintervallet TEST-NET och får inte användas som produktionsserveradress. Piloten bör använda en egen testbrevlåda och inte en administratörs enda konto.

Hämta ett meddelande före ändringen och notera den aktuella certifikatutfärdaren. Bevara också den befintliga brandväggsregeln, dess räknare och klientkonfigurationen. Då går det senare att skilja ett routing-, TLS-, proxyskannings- eller e-postserverproblem åt.

Förbered TLS och skanningsgränser

CA och certifikatvalidering

Lägg under Certificates > Certificate authorities till den CA som utfärdade e-postserverns certifikat om brandväggen inte redan litar på den. Filer från privata CA får endast komma från den egna PKI:n eller en annan verifierad källa. Importera certifikat på Sophos Firewall förklarar den allmänna importen och kontrollen av kedjan.

Välj därefter under Email > General settings > POP and IMAP TLS configuration den tidigare verifierade och importerade CA som utfärdade e-postserverns certifikat i TLS certificate. Låt Allow invalid certificate vara avstängt. Att stänga av valideringen reparerar inte en ogiltig, utgången eller ej betrodd motpart.

Markera kryssrutan Disable legacy TLS protocols för att enligt SFOS-hjälpen stänga av protokoll äldre än TLS 1.1. Alternativet bevisar inte att en konkret session använder TLS 1.2 eller TLS 1.3. Om säkerhetskravet är minst TLS 1.2 måste den förhandlade versionen kontrolleras i den verkliga klientsökvägen. Om den använda kombinationen inte kan uppfylla kravet ska utrullningen stoppas och en annan skyddsarkitektur utvärderas.

Eftersom brandväggen behandlar krypterad e-posttrafik för skanning kan en certifikatvarning bli synlig på klienten. Ignorera inte en ny varning. Kontrollera presenterat namn, utfärdare, kedja och klientens förtroende och åtgärda orsaken före en bred utrullning.

Meddelandestorlek och mottagarhuvuden

Under POP/S and IMAP/S settings anger Don’t scan emails greater than den största meddelandestorleken som ska skannas. För POP/IMAP betyder 0 inte obegränsat; enligt SFOS-hjälpen sätter det gränsen till 10,240 KB. Större meddelanden skannas inte. Gränsen måste passa typiska bilagor, tillgänglig prestanda och accepterad kvarstående risk.

Recipient headers hjälper SFOS att identifiera mottagare för POP/IMAP-policyer. Som standard använder brandväggen Delivered-To, Received och X-RCPT-TO. Lägg bara till ett annat meddelandehuvud om den verkliga e-postservern ställer in det tillförlitligt. Ett påhittat eller senare borttaget meddelandehuvud leder annars till policymatchningar som är svåra att förstå.

Skapa en valfri POP-IMAP-policy

Med en aktiv Email Protection-prenumeration tillämpar SFOS automatiskt standardpolicyn default-pop-av på POP3/S- och IMAP/S-trafik. Den tar bort virusinfekterade bilagor och ersätter meddelandetexten med en avisering. Ta hänsyn till denna automatiska grundpolicy vid tester och felsökning innan beteendet tillskrivs en egen policy.

En POP-IMAP-policy lägger till kriterier och varningar för användare. I MTA-läge är sökvägen Email > Policies and exceptions > Add policy > POP-IMAP scan; i Legacy-läge är den Email > Policies > Add policy > POP-IMAP scan. Ange först ett namn och avsändar- och mottagargrupper. Policyn kan därefter bland annat reagera på en spamklassificering, käll-IP eller nät, meddelandestorlek eller ett meddelandehuvud.

Välj grupper av e-postadresser eller domäner för avsändare och mottagare samt exakt matchning eller nyckelordsmatchning. Enskilda testadresser med exakt matchning ger en precist avgränsad pilot; domängrupper eller nyckelord kan utöka den avsedda omfattningen. Kontrollera den faktiska omfattningen med matchande och icke-matchande meddelanden utan att anta ytterligare regler för jokertecken eller skiftlägeskänslighet.

• Inbound email is: välj spam, probable spam, virus outbreak eller probable virus outbreak som klassificering.
• Source IP/network address: ange avsändarens IP-adress eller nätverksadress.
• Message size: ange en övre eller undre gräns för meddelandestorleken. Detta policykriterium ersätter inte den globala gränsen Don’t scan emails greater than.
• Message header: välj meddelandehuvudet; ange detaljerna för Other. Välj sedan exakt matchning eller nyckelordsmatchning och ange nyckelordsvärdet som ska jämföras.

De dokumenterade åtgärderna är Accept och Prefix subject. Prefix subject levererar meddelandet och lägger till en upplysning i ämnesraden. Policyn är alltså inte en allmän karantän- eller blockeringsregel. Om None väljs som kriterium gäller åtgärden för alla meddelanden mellan angivna avsändare och mottagare. Granska omfattningen medvetet före sparandet.

Ett ofarligt pilotexempel använder de egna testadressgrupperna med exakt matchning och kriteriet Message header: Other, detaljer Subject, exakt matchning, nyckelordsvärdet Test email. Konfigurera Prefix subject med det fritt valda prefixet Pilot och spara policyn. För det matchande meddelandet förväntas ämnesraden ändras från Test email till Pilot: Test email. Ett andra meddelande mellan samma testadresser med ämnesraden Control email matchar inte huvudkriteriet och ska inte få detta prefix. Anpassa testadresser och prefix till den egna piloten; testa båda nya meddelandena via samma avsedda hämtningsväg. Andra aktiva policyer får inte förvränga jämförelsen.

För att ändra en befintlig POP-IMAP scan-policy öppnar du Email > Policies and exceptions i MTA-läge eller Email > Policies i Legacy-läge. Välj Edit för den aktuella policyn, ändra de inställningar som behövs och spara policyn. Kontrollera därefter e-posthämtningen och policyns effekt på nytt via den avsedda klientsökvägen.

Den extra policyn kan utelämnas i det första tekniska proxytestet. Då syns det tydligt om den grundläggande kedjan av TLS, brandväggsregel och skanning redan fungerar. Lägg endast till en policy när logik för avsändare, mottagare eller meddelandehuvud verkligen behövs.

XML-hierarki och begränsningar för automatisering

För automatisering heter policyobjektet POPIMAPScanningPolicy. Följande genomgång beskriver den dokumenterade strukturen för SFOS 22/23, inte en testad POST-begäran eller en som är färdig att skickas. Skydda åtkomsten till XML API förklarar säker åtkomst och hur XML-svar utvärderas. Skanningsalternativen i brandväggsregeln som faktiskt matchar krävs även när policyn hanteras via API.

Det dokumenterade exemplet skiljer mellan tre nivåer:

• POPIMAPScanningPolicy/Name anger den policy som ska hanteras. POPIMAPScanningPolicy/After/Name anger däremot den andra policy som den placeras efter i exemplet. Målnamnet och referensen för ordningen får inte förväxlas. Exemplet visar denna placeringsstruktur, men varken en allmän utvärderingsordning eller beteendet när referensen saknas eller när After utelämnas.
• Under POPIMAPScanningPolicy/EmailAddress finns SenderEmail, SenderAction, RecipientEmail och RecipientAction. Adressvärden och matchningsoperatorer hör alltså till den gemensamma överordnade noden EmailAddress, inte direkt under policyobjektet. Parameterbeskrivningen behandlar båda adressvärdena som enskilda strängar; gruppvalet i gränssnittet innebär inte att det finns en ytterligare XML-listnod.
• FilterCriteria, Action, To och MatchIs ligger i exemplet direkt under POPIMAPScanningPolicy, utanför EmailAddress och After. To innehåller här ämnesprefixet för prefixåtgärden, inte en mottagaradress. MatchIs beskriver, beroende på kriteriet, klassificeringen av inkommande e-post eller det värde i meddelandehuvudet som ska jämföras.

Parametertabellen markerar Name, SenderEmail, SenderAction, RecipientEmail, RecipientAction, FilterCriteria och Action som obligatoriska. Den anger för Name högst 255 tecken, för To högst 300 och för MatchIs högst 750 tecken. Dessa gränser beskriver fält, inte policyns tillåtna omfattning; adressvärdet Any som visas i exemplet är till exempel inte en lämplig utgångspunkt för en snävt avgränsad pilot.

Ytterligare kriteriespecifika parametrar är Address för käll-IP eller nät (array av strängar, flera värden), MessageSizeOperator med MessageSize (heltal) samt MessageHeaderString (högst 765 tecken) med MessageHeaderOperator för jämförelser av meddelandehuvuden. Parametertabellen anger dessa fält, men det visade exemplet för inkommande e-post innehåller dem inte. Det är därför inte en fullständig XML-mall för käll-IP-, storleks- eller huvudfilter; saknade överordnade noder, storleksenheter eller beroenden mellan obligatoriska fält härleds inte ur exemplet.

⚠️ De tillåtna värdena anges i parameterbeskrivningen delvis endast som oupplösta symboler, exempelvis $POPIMAP{SENDER_MATCHTYPE_CONTAINS}, $POPIMAP{RULETYPE_INBOUND_EMAIL} och $POPIMAP{POP_IMAP_ACTION_PREFIX_SUBJECT}. Dessa symboler är inte bekräftade literalvärden för en POST-begäran. Exemplet visar visserligen Contains, InboundEmailIs och Prefix Subject, men ger ingen fullständig mappning av alla konstanter. För MessageHeaderOperator anger standardvärdeskolumnen till och med GreaterThan, medan beskrivningen anger Contains/Equals. Lös inte denna motsägelse genom att gissa en operator och skicka varken UI-beteckningar eller symbolnamn som API-värden utan verifiering.

Så länge de konkreta värdena och den filterstruktur som behövs för den använda builden inte har klarlagts är konfiguration via det ovan beskrivna gränssnittet den säkra dokumenterade vägen. Säkra namn, ordning, adressomfattning, kriterium och åtgärd före en senare godkänd API-ändring; läs därefter det sparade tillståndet på nytt eller kontrollera det i gränssnittet och hämta det matchande och icke-matchande testmeddelandeparet igen. Referensen listar XML-statusvärdena 200, 500 och 502 för Add och Edit, men inga förklarande meddelanden. En lyckad HTTP-begäran bekräftar därför inte i sig vare sig den sparade policyn eller dess effekt. Här har inget skrivande API-anrop utförts på en appliance.

Skapa brandväggsregeln för e-posthämtning

Skapa regeln under Rules and policies > Firewall rules. I MTA-läge kan du även komplettera den automatiskt skapade MTA-brandväggsregeln; för en tydligt avgränsad pilot är en egen, snäv regel dock lättare att utvärdera. I Legacy-läge skapar du en ny brandväggsregel. Den bör endast innehålla det avsedda klientnätet eller pilothosten, e-postservermålet och de e-postportar som faktiskt behövs. En allmän regel från LAN till WAN med många säkerhetsfunktioner är svår att utvärdera under acceptanstestet.

Följande värden passar exemplet Pilot_POP_IMAP_Scan:

• Source zones: LAN
• Source networks and devices: host 10.20.30.50
• Destination zones: zonen för sökvägen till e-postservern, vanligtvis WAN för en extern server
• Destination networks: hostobjekt för 192.0.2.25 eller den verkliga e-postservern
• Services: IMAPS
• Log firewall traffic: aktiverat

Aktivera Scan IMAPS under Scan email content. Om miljön faktiskt använder fler protokoll väljs även Scan IMAP, Scan POP3 eller Scan POP3S. Add ports lägger till motsvarande tjänster; därefter måste de visas under Services i regeln.

Placera regeln ovanför en mer allmän regel som redan matchar samma klient och e-postserver. Efter sparandet är den faktiska Firewall Rule ID i Log Viewer avgörande, inte den förväntade positionen i regeltabellen. Konfigurera Sophos Firewall-regler säkert förklarar uppbyggnad, ordning och kontroll av Rule ID.

Testa hela sökvägen

Placera först ett litet, ofarligt meddelande i den privata testbrevlådan. Pilotklienten hämtar det via avsett FQDN och avsedd port. I Log Viewer måste käll-IP, mål-IP, tjänst, åtgärd och Firewall Rule ID överensstämma med den nya regeln. En räknarökning på en annan regel är ett stoppvillkor.

För att kontrollera certifikat och TLS kan exempelvis följande anslutningstester, som inte ändrar konfigurationen, köras från en klient i samma nät:

openssl s_client -connect mail.example.net:993 -servername mail.example.net
openssl s_client -connect mail.example.net:995 -servername mail.example.net
openssl s_client -starttls imap -connect mail.example.net:143 -servername mail.example.net
openssl s_client -starttls pop3 -connect mail.example.net:110 -servername mail.example.net

Testa endast de protokoll som e-postservern faktiskt erbjuder. Ersätt mail.example.net med det riktiga FQDN-namnet. Utdata bekräftar certifikat, kedja och TLS-parametrar, men inte en lyckad inloggning eller innehållsskanning. Avsluta den interaktiva anslutningen med Ctrl+C efter kontrollen.

Upprepa därefter hämtningen med den verkliga e-postklienten. Använd warren.log för proxyanalysen; Log Viewer och Packet Capture visar dessutom regelmatchning och nätverkssökväg. Notera tidsstämpel, klient-IP, server-IP, port och testämne tillsammans. Sophos Firewall-tjänster och loggar beskriver loggfilen och säker åtkomst.

Hämtning, Firewall Rule ID, TLS-parametrar och korrelation med warren.log visar tillsammans den avsedda hämtnings- och TLS-vägen, inte antivirusets effektivitet. Om en egen Prefix subject-policy är konfigurerad ska även meddelandeparet ovan testas: Pilot: Test email för det matchande meddelandet och inget Pilot-prefix för Control email. Dokumentera de faktiskt levererade ämnesraderna; även ett korrekt prefix visar bara policyåtgärden, inte antivirusets effektivitet. Kontrollera grupper, matchningstyp, meddelandehuvuden och andra aktiva policyer vid avvikelser och testa båda meddelandena igen.

Sökvägstestet innehåller också ett negativt fall. För en pilothost som inte är tillåten eller en port som inte är vald ska den förväntade regelhanteringen fastställas i förväg och sedan faktisk Rule ID och skanningsalternativ kontrolleras. Korrigera en oavsiktligt bred andra skanningsregel; avsiktligt planerat alternativt skydd är inget fel. Testet kräver varken global avsaknad av skydd eller generell blockering. Om en särskilt förberedd testmotpart med ogiltig certifikatkedja finns tillgänglig ska anslutnings- eller hämtningsförsöket misslyckas på grund av valideringen av kedjan medan Allow invalid certificate är avstängt på brandväggen; skapa inte ett certifikatfel på produktionsmotparten för detta test.

Avgränsa fel efter symptom

Hämtningen fungerar, men proxyn skannar inte

Kontrollera först Firewall Rule ID. Om en högre eller mer allmän regel matchar ska ordning, källa, mål och tjänst korrigeras. Om den avsedda regeln matchar måste relevant Scan IMAP/IMAPS/POP3/POP3S-alternativ och port vara aktiva under Services. En POP-IMAP-policy ensam aktiverar inte proxyn.

E-postklienten rapporterar ett certifikatfel efter aktiveringen

Registrera presenterat FQDN, utfärdare, giltighet och fullständig kedja. Kontrollera sedan den CA som valts under POP and IMAP TLS configuration och klientens förtroende. Aktivera inte Allow invalid certificate som permanent lösning. Om det fortfarande är oklart vilket certifikat proxyn eller servern presenterar ska piloten återställas innan fler klienter påverkas.

STARTTLS fungerar, men POP3S eller IMAPS gör det inte

Kontrollera portar och anslutningssätt separat. POP3 på 110 och IMAP på 143 övergår till en krypterad session först med STARTTLS; POP3S på 995 och IMAPS på 993 börjar med TLS. E-postklient, serverlyssnare, brandväggstjänst och aktiverat skanningsalternativ måste använda samma variant.

Ett stort meddelande levereras men skannas inte

Jämför Don’t scan emails greater than med den faktiska meddelandestorleken. Även 0 begränsar POP/IMAP-skanningen till 10,240 KB. Höj inte gränsen blint för ett enstaka test utan att bedöma påverkan på prestanda och accepterad risk.

Prefixet i ämnesraden saknas

Kontrollera avsändar- och mottagargrupp, matchningstyp, kriterium och Recipient headers. Meddelandet kan ha skannats tekniskt även om den valfria policyn inte matchade. Utvärdera därför proxyfunktionen och policyåtgärden separat.

Drift och återställning

Lägg efter en lyckad pilot till fler klienter stegvis. Övervaka regelräknare, warren.log, TLS-fel och helpdeskärenden under utrullningen. Ändringar av e-postserverns certifikat, FQDN, port eller klientprofil ska därefter ingå i samma ändringsprocess, eftersom de förändrar den validerade sökvägen.

För återställning tas piloten först bort från den snäva regeln eller så stängs motsvarande skanningsalternativ av. Bekräfta därefter att den ursprungliga e-posthämtningen fungerar igen och att den förväntade tidigare regeln matchar. Ta endast bort en importerad CA eller global POP/IMAP-inställning om ingen annan tjänst använder den. Radera inte meddelanden, loggar eller certifikat som ett standardsteg vid återställning.

FAQ