Pozn.: Tento popis jsem psal k verzi 12.5.0-066. Právě se objevila verze 13.0 build 314, která je ovšem nevhodná na provozní nasazení (Limited Deployment).

Pozn.: Původně jsem se v článku věnoval pouze přijímané poště (Inbound Mail). Později jsem doplnil poznámky i pro odesílanou pošty (Outbound Mial).

Srovnání Symantec a Cisco

Když ze svého pohledu srovnám Symantec Messaging Gateway (SMG) a Cisco Email Security Virtual Appliance (ESA), tak mi přijde, že SMG má přehlednější rozhraní (třeba grafy jsou interaktivní a po najetí zobrazí informace o dané části) a konfigurace je mnohem více intuitivní. ESA možná nabízí více možností konfigurace, ale i jednoduché věci se nastavují zbytečně složitě. Důležitá je funkce Message Tracking, v ESA se mi lépe zadávají parametry hledání, ale výsledek se mi zdá přehlednější v SMG (ESA má detailnější log). ESA má opravdu velké množství reportů.

Zásadní je samozřejmě identifikace nevyžádané pošty a případně virů. V období, kdy Symantec Messaging Gateway fungoval, tak odfiltroval Spam velmi dobře, dá se říci, že nechodil vůbec žádný Spam. Bohužel pak najednou přestal filtrovat česky psaný Spam (ostatní jazyky pořád fungovaly dobře) a někteří uživatelé dostali i desítky zpráv denně. Téměř se nestávalo, aby jako Spam označil korektní zprávu (False Positive). Detekce virů příliš nefungovala, za týden našel jeden či dva viry, přitom lokální antiviry na stanicích uživatelů jich identifikovaly desítky v přijatých zprávách.

Testování Cisco Email Security Appliance jsem začal v době, kdy skrze SMG procházel Spam. Situace se okamžitě zlepšila a dá se říci, že identifikace Spamu je velmi dobrá (stejná jako u SMG v době jeho korektní funkce). Trochu horší je situace s False Positive, objevilo se několik jednotek případů, kdy byl běžný email označen jako Spam. Na detekci virů jsem testoval i modul Advanced Malware Protection (AMP), situace je o něco lepší než u SMG, ale celkově zatím nemohu hodnotit.

Dokumentace

• User Guide for AsyncOS
• Install and Upgrade Guides
• Cisco Email Security Virtual Appliance
• Cisco Email Security Appliance
• Cisco Content Security Virtual Appliance Installation Guide
• Cisco Email Security Appliances C195, C395, C695, and C695F Getting Started Guide
• Cisco Email Security Best Practices
• Cisco ESA Initial Setup Wizard
• Cisco ESA Initial Setup
• YouTube - Cisco Email Security Appliance - Basic Installation

Pro instalaci a konfiguraci jsou hlavní dva dokumenty:

• Cisco Content Security Virtual Appliance Installation Guide
• User Guide for AsyncOS 12.5 for Cisco Email Security Appliances

Pozn.: Jak to tak bývá, tak mi v řadě věcí přijde dokumentace zmatená, mnoho věcí postrádá hlubší vysvětlení, některé věci jsou popsány na více místech a pokaždé jinak a na řadě míst je vidět, že jde o aktualizaci starší dokumentace, kde se vše neopravilo (někde se ještě používá Ironport, SendBase web vs. Talos, apod.)

Principy a služby

Hlavní komponenty, které zpracovávají a filtrují poštu (pokud jsou pro danou zprávu zapnuté).

• SenderBase Reputation Service (SBR) je založena na blokování (odmítání) či omezování provozu podle připojující se adresy vzdáleného hosta. Služba vrací skóre pro každou IP adresu, které je založeno na pravděpodobnosti, že zaslaná zpráva bude Spam, ověřit můžeme na https://talosintelligence.com/
  • IP Reputation Filtering - reputace (pověst) domény odesílatele je určena službou Cisco SenderBase Reputation Service a udávána pomocí SenderBase Reputation Score (SBRS) od -10 do 10, určuje Talos
  • Sender Domain Reputation Filtering (SDR) - rozšíření IP reputace, shromažďuje další informace o doméně odesílatele a vrací verdikt od Talosu
• Anti-Spam Scanning analyzuje obsah zpráv a detekuje spam a předpokládaný spam, může tyto zprávy ukládat do karantény
• Anti-Virus Scanning využívá Sophos nebo McAfee
• Advanced Malware Protection (File Reputation and Analysis Services) využívá reputační informace (pověst) z cloudu a analýzu chování (sandboxing) pro soubory v přílohách. Chrání proti Zero Day a cíleným souborovým útokům v přílohách emailů. Hodnocení přílohy se může změnit i dodatečně a pak je zaslán administrátorovi alert.
• Outbreak Filters je obrana proti novým virům pomocí vložení podezřelých zpráv do karantény, dokud nebude tradiční AntiVirus aktualizován

V praxi je majoritní většina nevyžádané pošty (více než 90%) odfiltrována pomocí špatné reputace. To funguje stejně u Symantecu jako u Cisco. Znamená to, že je odmítnuto již síťové spojení z určité IP adresy. Má to nevýhodu, že takové zprávy nenalezneme v logu, protože se vůbec nenavázalo SMTP spojení, takže neznáme odesílatele, příjemce, apod. Také tyto zprávy nenalezneme v karanténě.

Zpracování toku zpráv pomocí ESA se označuje jako Email Pipeline a má tři fáze:

• Receipt - příjem příchozího emailu, má nastavené limit a politiky příjmu (jestli může daná IP adresa odesílat zprávy, ověření adresy příjemce, apod.)
• Work Queue - pracovní fronta zpracovává příchozí a odchozí emaily, provádí filtrování, safelist/blocklist, kontroly Antivirtus a Antispam, Outbreak Filters a karanténa
• Delivery - doručení zpráv, opět se uplatňují limity a politiky, například se řeší nedoručitelné zprávy

Důležité funkce na příjmu zpráv (Receipt):

• Host Access Table (HAT) - určuje, kteří hosti (odesílatelé) se mohou připojit k listeneru a kteří jsou blokováni, skládá se ze Sender Groups, které seskupují odesílatele do skupin (můžeme vyjmenovat, zvolit externí zdroj nebo zařadit podle SenderBase Reputation Score), a přiřazených Mail Flow Policies, které určují chování
• Recipient Access Table (RAT) - pro příchozí emaily určuje seznam (domén) příjemců, pro které jsou přijímány zprávy, nemusíme zadávat pouze domény, ale i jednotlivé adresy a další varianty, které identifikují příjemce

Poznámky z instalace

Nasazoval jsem virtuální stroj (Virtual Appliance) na VMware ESXi. Provede se klasicky Deploy OVF Template.

Běžně se AntiSpam brána umisťuje do DMZ (Demilitarized Zone) a vyčištěnou komunikaci posílá na poštovní server ve vnitřní síti.

VM má vytvořeny 3 síťové adaptéry, které jsou interně nazvány Management, Data 1 a Data 2. Můžeme využít nasazení, kdy máme 2 datové adaptéry (každý musí mít adresu z jiného subnetu) a tedy jeden listener směrem do internetu a druhý na interní poštovní server. Nebo pouze jeden, přes který pošta přichází z internetu i odchází do vnitřní sítě (tedy zapojení do jednoho subnetu).

Pozn.: Dodatečně jsem zjistil, že je možná konfigurace, kdy se využije jeden síťový adaptér (Ethernet Port) a na něm se vytvoří více IP rozhraní (IP Interface), ty mohou mít adresy ze stejného rozsahu. Na každém pak můžeme vytvořit listener.

Varianta je přes datový interface přistupovat i ke správě (Management), v tom případě využijeme pouze jeden síťový adaptér. Ale v tomto případě nelze dokončit konfiguračního průvodce, pro něj musíme mít 2 adaptéry a dodatečně můžeme konfiguraci změnit.

Pozn.: Oddělená management síť nebo alespoň rozhraní mi přijde jako dobré řešení. Ale na ESA musí mít každý interface adresy z jiného subnetu, takže bychom museli mít opravdu oddělenou síť a pokud by tato byla i pro vnitřní prostředí, tak nám obchází firewall a narušuje bezpečnost.

Úvodní nastavení

Po vytvoření VM potřebujeme provést základní konfiguraci. Pokud máme v dané síti DHCP, tak management interface dostane přidělenu IP adresu a můžeme přistoupit na web. Běžnější je, že si musíme přes konzoli nastavit základní síťové parametry.

Výchozí uživatel je admin a heslo ironport (Factory Default Username and Passphrase), pomocí něj se připojíme na CLI. Pomocí příkazu interfaceconfig nastavíme na interface IP adresu, masku, jméno, hostname, povolené služby (telnet, SSH, FTP, cluster, HTTP, HTTPS, AsyncOS API), certifikát. Pokud je třeba, tak také nakonfigurujeme bránu setgateway.

Aby se uplatnila nastavení, tak musíme použít commit.

Pozn.: Po přihlášení na CLI se zobrazuje doporučení spustit systemsetup, ale to nelze, dokud není nahrána licence.

Nahrání licence

Práce s licencemi je další nepohodlná oblast, jak již bývá u Cisco zvykem. V případě Symantecu dostaneme email s licenčním souborem, který nahrajeme přes webové rozhraní a je to. Cisco nám pošle mailem PDF (případně radši několik), kde najdeme Product Authorization Key (PAK) a PIN. Na webu http://www.cisco.com/go/license se musíme přihlásit svým účtem a projít složitým průvodcem Get Licenses From New PAK. Pro Virtual Appliance je zvláštní krok, kde se má zadat SN/Virtual Device Identifier, ale to nejde. Pro první licenci musíme nechat nevyplněno a vygeneruje se VLN. Po dokončení průvodce se dá na webu stáhnout licence, ale ta obsahovala prázdné XML. Musel jsem počkat na email, kde již přišel korektní soubor. Asi další chyba, že mi přišlo souborů 5, porovnáním jsem zjistil, že obsah je identický.

Důležité je, že když na ESA nahráváme licenci, tak přehraje (smaže) všechny předchozí. Pokud máme více licencí, tak musíme znovu projít průvodce, kde vybereme existující VLN. Nová licence se pak přidá k té původní a vygeneruje se společné XML.

Nahrání licence nelze přes web, ale musíme se připojit na CLI (třeba SSH). Zde použijeme příkaz loadlicense, volbu 1 a zkopírujeme obsah celého licenčního XML a vložíme do příkazové řádky. Na konci potvrdíme souhlas a zobrazí se informace o licenci. Ty si můžeme zobrazit také pomocí příkazů.

showlicense
featurekeys

Webový průvodce

Při prvním připojení na webové rozhraní se spustí System Setup Wizard (kdykoliv se dá spustit v menu System Administration - System Setup). V průvodci se provede základní nastavení celého systému. Všechny hodnoty můžeme dodatečně změnit či nastavit (jen je musíme nalézt).

V prvním kroku akceptujeme licenci. V druhém zadáváme hostname, NTP server a časovou zónu, musíme zadat nové admin heslo (Passphrase). Ve třetím síťové parametry, tedy bránu, DNS (buď servery nebo použití Root Hints), síťová rozhraní, kde musíme zadat management a alespoň jedno datové. Na každé rozhraní můžeme povolit, zda akceptuje příchozí poštu (incoming) nebo přes něj odchází pošta (relay email - outgoing). Pokud povolíme Accept Incoming Mail, tak zadáváme, pro jakou doménu přijímá poštu (Domain) a na jaký poštovní server ji předává (Destination - SMTP Route), pokud nezadáme, tak se použije DNS MX záznam. Domén můžeme zadat více, ale vše můžeme definovat dodatečně. V průvodci musíme definovat jedno rozhraní pro příjem pošty, jinak nemůžeme pokračovat.

V posledním kroku jsou bezpečnostní nastavení, kde povolujeme funkce pro AntiSpam a AntiVirus. Následuje shrnutí zadaných nastavení a poté se aplikují změny.

Základní konfigurace ESA

Velmi stručné body, co bychom mohli potřebovat nastavit. Vše je podrobně popsáno v User Guide for AsyncOS for Cisco Email Security Appliances (dokumentace je dlouhá, přesto by podle mne mohla být lepší).

Pozn.: Aby se uplatnila provedená změna nastavení, tak musíme vždy provést Commit Changes.

Pozn.: Pro pár akcí obsahuje ESA průvodce, který nás provede konfigurací. Nachází se v polovině stránky vpravo How-Tos.

Zapnutí logu sledování zpráv (Message Tracking)

• Security Services - Message Tracking

Logování pro sledování zpráv je na počátku vypnuté. Moc nechápu proč (jedině kvůli prostoru na disku, ale ten je také rozdělen zvláštně), jde o základní funkci, kterou asi vždy potřebujeme. Povolíme službu, standardně zvolíme Local Tracking, volitelně zapneme logování i pro odmítnutá spojení (abychom mohli jednoduše hledat zdrojové IP adresy, které podle reputace neprošly).

Můžeme zvýšit diskový prostor, který je přidělený pro sledování zprávy System Administration - Disk Management.

Aby se nám logoval předmět zpráv, tak to musíme zapnout System Administration - Log Subscriptions dole část Global Settings a Edit Settings.

Dokumentace uvádí, že aby se logovala jména příloh, tak je třeba vytvořit alespoň jeden proces, který skenuje tělo zprávy, jako je Message Filter nebo Content Filter.

Active Directory - LDAP

• System Administration - LDAP

Pro kontroly existujících příjemců (adres), zjišťování členů skupiny, přihlašování do karantény a další, musíme nastavit napojení na adresář. Ideálně použijeme LDAPS a autentizační účet pro čtení.

• Accept Query - slouží k validaci příjemců (Recipient Validation)
• Group Query - členství ve skupinách
• Spam Quarantine End-User Authentication Query - přihlašování do karantény, musí se zatrhnout Designate as the active query
• Spam Quarantine Alias Consolidation Query - když má uživatel více emailových adres, tak mu přijde z karantény společný email (funguje pouze na adresy přiřazené k jeho účtu)

Certifikáty a autority

• Network - Certificates

Můžeme spravovat důvěryhodné certifikační autority (CA) a nahrávat vlastní certifikáty, které následně nastavujeme pro HTTPS či šifrování SMTP.

Síťová rozhraní (Interfaces)

• Network - IP Interfaces

Můžeme měnit nastavení rozhraní (a vytvářet a odstraňovat), přiřazujeme Ethernet port, nastavujeme adresu, hostname (důležité, zobrazuje se při připojení na SMTP), přiřazený certifikát (vlastní nejprve nahrajeme), povolené služby na tomto rozhraní. Také můžeme na rozhraní povolit připojení uživatelů do karantény, volíme port a definujeme URL (to se posílá v emailech), měl by sedět certifikát.

ESA má několik portů (Ethernet Port). IP Interfaces jsou vázány na port, pokud jsou na jiném portu, tak musí mít IP adresu z jiného subnetu. Více IP Interfaces můžeme přiřadit na jeden port, pak mohou mít adresy ze stejného rozsahu. Více rozhraní nám umožní rozdělit služby, které poslouchají na různých IP adresách (a provozovat více stejných služeb na stejném portu, ale jiné IP adrese, například i SMTP pokud vytvoříme více Listenerů).

Listeners - příchozí SMTP služby

• Network - Listeners

Na síťovém rozhraní vytváříme Listeners (posluchače), které obsluhují příchozí SMTP spojení a zpracovávají poštu. Můžeme definovat parametry, které musí příchozí spojení nebo zprávy splňovat, aby byly přijaty. Můžeme vytvářet

• Public Listener, který zpracovává emailové zprávy z internetu, tedy přijímá spojení z mnoha hostů a směruje na omezený počet příjemců
• Private Listener, který přijímá zprávy z interních systémů (poštovního serveru), tedy omezeného počtu hostů a odesílá na mnoho příjemců v Internetu

Vazba je taková, že na fyzickém Ethernet interface (portu) vytváříme IP interface, který má přiřazenu IP adresu, a na něm Listener, který má přiřazen port (může jich být více s jiným portem).

Na Listeneru nastavujeme dvě důležité tabulky, které ovlivňují komunikaci se SMTP serverem. Jde o Host Access Table (HAT), kteří hosti (IP adresy odesílatelů) se mohou připojit, a Recipient Access Table (RAT), akceptované domény příjemců (obecně příjemci).

Na adaptéru také vybíráme LDAP query, které jsme definovali dříve v sekci LDAP. Hlavní je

• Accept Query - přijímané adresy (pokud příjemce v doméně neexistuje, tak ESA odmítne a nepředává na poštovní server), můžeme volit, zda se kontrola provádí během SMTP konverzace nebo během zpracování fronty (work queue)

Rozdělení Listeners pro příjem a odesílání pošty

Můžeme mít pouze jeden Listener (typu Public), pokud řešíme pouze příchozí poštu. I v případě, kdy řešíme také odchozí poštu, vystačíme s jedním Listenerem. Ale v HAT musíme přidat Sender Group RELAYLIST a k ní Mail Flow Policy RELAYED (s chováním Relay). Jednodušší je vytvořit druhý typu Listener Private, automaticky se nám vytvoří HAT a politiky.

Listener pro příchozí poštu má definovaný HAT, který přijímá vše (jsou definovány vyjímky, co se blokuje), a RAT, který přijímá zprávy pro lokální domény a vše ostatní odmítá. Listener pro odchozí poštu má HAT, která předává (relay) pro lokální domény (odesílající server) a blokuje vše ostatní, a nepoužívá RAT.

Když má ESA dva Listenery, tak má dvě IP adresy. Pak je důležité, která adresa slouží pro jakou službu, a kterou adresu ESA použije pro navazování odchozí komunikace. Na různých místech můžeme nastavit, který interface se má pro komunikaci použít (například pro LDAP provoz). Výchozí stav je auto.

Komunikace na Listenery je jasná, na Private se připojujeme z interních poštovních serverů pro odeslání zpráv mimo organizaci. Na Public přichází pošta z internetu (směřuje sem náš MX záznam). Zajímavé je, že podle logů, příchozí pošta (Public listener) odchází na interní servery z Private listeneru. Ale odchozí pošta, která přijde přes Private listener, přes tento i odchází do internetu.

HAT Mail Flow Policies

• Mail Policies - Mail Flow Policies

V Host Access Table (HAT) přiřazujeme k Sender Groups určitou definovanou Mail Flow Policies. Každá politika určuje základní chování, zda akceptuje či odmítá spojení, ale i řadu dalších parametrů pro spojení, SMTP, omezování poštovního toku, bezpečnost (zapnutí detekce Spam, virů, SPF, DKIM, šifrování, apod) a ověřování odesílatele. Pokud chceme nějaké nastavení provést globálně, tak můžeme upravit Default Policy Parameters, změny v jednotlivé politice mohou defaultní nastavení měnit.

V těchto politikách se nastavují i takové základní parametry, jako je maximální velikost přijímané zprávy (Max. Message Size) a maximální počet příjemců zprávy (Max. Recipients Per Message).

Poštovní server, kam se předávají zprávy - SMTP Routes

• Network - SMTP Routes

Pokud jsme v úvodním průvodci zadali doménu a k ní cíl (Destination), tak se nám zde vytvořil záznam. Pro jednotlivé domény můžeme mít různé poštovní servery. Většinou asi bude jeden, takže můžeme hromadně definovat, že se vše (Receiving Domain: All Other Domains) přeposílá na náš poštovní server (Destination Hosts), kterých může být více s různou prioritou. To se týká příchozích zpráv, které chceme předat na interní poštovní server. Pro odchozí poštu většinou chceme využít MX DNS záznamy, v tom případě musíme nechat prázdnou položku All Other Domains.

Zasílání upozornění

• System Administration - Alert

Rozdělení diskového prostoru

• System Administration - Disk Management

Nastavení času

• System Administration - Time Zone
• System Administration - Time Settings

Nastavení timeoutu na rozhraní web, ssh

• System Administration - Network Access

Advanced Malware Protection (AMP) - File Reputation

• Security Services - File Reputation and Analysis - Edit Global Settings

Zde můžeme nastavit některé parametry AMP, například jaké typy souborů se odesílají pro analýzu. Docela hodit se může nastavení portu (protokolu), který se používá pro připojení ke cloudové File Reputation Service. Defaultně je to připojení na port 32137, ale lze nastavi SSL (443). Rozklikneme Advanced Settings for File Reputation a zatrhneme Use SSL (Port 443) v sekci SSL Communication for File Reputation.

Pokud nám komunikace nefunguje, tak dostáváme chyby:

The File Reputation service is not reachable. 

Rozšířené konfigurace ESA

Některé vlastnosti, které se podle mne vyplatí na počátku nakonfigurovat.

Detekce marketingových a hromadných zpráv - Graymail

Průvodce konfigurací této vlastnosti se nachází v How-Tos. Jde o označování zpráv, které nejsou nevyžádaná pošta, ale přesto nejde o standardní email (mělo by jít o korektní službu, kde se člověk přihlásil k odběru). Cisco je označuje jako Graymail. Kategorie jsou Marketing, Social Network a Bulk.

Stručně jde o to povolit Graymail Detection v Security Services - IMS and Graymail. A nastavit politiku v Mail Policies - Incoming Mail Policies část Graymail, kde jednotlivé části zapneme, zvolíme doručit (Deliver) a přidat (Prepend) text.

Ověřování příchozích zpráv pomocí SPF (Sender Policy Framework)

Průvodce konfigurací se nachází v How-Tos, pro SPF, SIDR, DKIM a DMARC. Info Overview of SPF and SIDF Verification.

Konfigurace spočívá v zapnutí na Mail Policies - Mail Flow Policies, část Default Policy Parameters. V sekci Security Features se zapíná SPF/SIDF Verification.

Dále vytvoříme filtry obsahu Mail Policies - Incoming Content Filters, jeden či více, pokud chceme různě reagovat. Jako podmínku volíme SPF Verification a přiřazujeme výsledek kontroly. Jako akci můžeme zvolit modifikaci hlavičky Add/Edit Header a třeba na začátek předmětu (Header Name: Subject) přidáme text [SPF Fail]. Jiné možnosti jsou vložit do karantény či smazat (Drop).

Na závěr přiřadíme filtry k politice Mail Policies - Incoming Mail Policies část Content Filters.

Pro kontrolu, jaké filtry obsahu se použily, se můžeme podívat na report Monitor - Content Filters. Za určité období vidíme filtry, kde došlo ke shodě (byly použity) a kolikrát. Můžeme se proklikat až na jednotlivé zprávy v Monitor - Message Tracking (tam také můžeme filtrovat zprávy, kde byl použit určitý filtr obsahu). Jako nedostatek mi přijde, že v detailním logu zprávy není vidět událost, kterou filtr provedl (například změnil předmět zprávy).

Ověřování podpisu příchozích zpráv pomocí DKIM (DomainKeys Identified Mail)

Identicky jako SPF se nastavuje kontrola DKIM (a je možno i nastavit podepisování odchozích zpráv), průvodce se nachází v How-Tos. Info How to Verify Incoming Messages Using DKIM.

Konfigurace spočívá v zapnutí na Mail Policies - Mail Flow Policies, část Default Policy Parameters. V sekci Security Features se zapíná DKIM Verification. Můžeme vytvořit různé profily v Mail Policies - Verification Profiles.

Dále vytvoříme filtry obsahu Mail Policies - Incoming Content Filters, jeden či více, pokud chceme různě reagovat. Jako podmínku volíme DKIM Authentication a přiřazujeme výsledek kontroly. Jako akci můžeme zvolit modifikaci hlavičky Add/Edit Header a třeba na začátek předmětu (Header Name: Subject) přidáme text [DKIM Fail]. Jiné možnosti jsou vložit do karantény či smazat (Drop).

Na závěr přiřadíme filtry k politice Mail Policies - Incoming Mail Policies část Content Filters.

Podepisování odchozích zpráv pomocí DKIM (DomainKeys Identified Mail)

Pokud nám odchozí pošta prochází přes ESA, tak můžeme zapnout DKIM podepisování zpráv. Nejprve potřebujeme soukromý klíč Mail Policies - Signing Keys. Můžeme jej zde vygenerovat nebo vložit v textové podobě. Následně si můžeme zobrazit veřejný klíč. Poté potřebujeme vytvořit doménový profil Mail Policies - Signing Profiles. Definujeme profil pro určitou doménu, jejíž zprávy chceme podepisovat, a zadáme parametry DKIMu. Zde také přiřazujeme klíč pro podpis. Na seznamu profilů si také můžeme nechat vygenerovat DNS záznam veřejného klíče. Po jeho vytvoření v DNS také můžeme provést test, zda jsou hodnoty správné.

Poslední krok je zapnutí podepisování na Mail Flow Policy pro odchozí poštu Mail Policies - Mail Flow Policies. Vybereme odchozí Listener a politiku RELAYED (případně Default Policy Parameters). V sekci Security Features zapneme DomainKeys/DKIM Signing.

Ověřování příchozích zpráv pomocí DMARC (Domain-based Message Authentication, Reporting and Conformance)

Nadstavba nad SPF a DKIM je DMARC, jehož kontrolu opět jednoduše nastavíme, průvodce se nachází v How-Tos. Info DMARC Verification.

Nejprve upravíme globální nastavení DMARC a Verification Profile v Mail Policies - DMARC. V profilu určujeme chování k různým situacím, kdy je DMARC politika nastavena na odmítnutí (Reject) nebo karanténu (Quarantine) a kontrola neprojde. Možnosti jsou nedělat nic, vložit do určité karantény (jde o Policy karanténu Monitor - Policy, Virus and Outbreak Quarantines) či odmítnout SMTP. A dále pokud dojde k chybě.

DMARC ověřování zapneme na Mail Policies - Mail Flow Policies, buď pro určitou politiku nebo spíše v části Default Policy Parameters. V sekci Security Features se zapíná DMARC Verification. Můžeme zvolit profil a zapnout odesílání denních agregovaných reportů (RUA). Adresu pro odesílání reportů můžeme nastavit v System Administration - Return Addresses.

Pro kontrolu a statistiky, jak probíhají DMARC kontroly, se můžeme podívat na report Monitor - DMARC Verification.

Sender Verification - kontrola platnosti odesílací domény

• Mail Policies - Mail Flow Policies - Default Policy Parameters

Cisco doporučuje zapnout, jako první krok ochrany proti falešným e-mailovým doménám, ověřování odesílací domény (Sender Verification). Podle domény v adrese odesílatele (Envelope Sender) se kontroluje, že existuje MX záznam a pro něj A záznam v DNS. Pokud neexistuje, tak je spojení odmítnuto. Nastavení je nejlépe v defaultní politice v části Sender Verification (Envelope Sender DNS Verification).

Využití karantény (Spam Quarantine)

• Monitor - Spam Quarantine

Jako bezpečnější, než identifikovaný Spam rovnou mazat, je využít jeho umístění do karantény, aby se mohlo kontrolovat False Positive. Info Chapter: Spam Quarantine.

Konfigurace karantény se provádí v Monitor - Spam Quarantine. Hlavní je povolení karantény a doba uložení zpráv. Můžeme také nechat zaslat do Cisco kopii zprávy, kterou z karantény uvolníme.

Většinou chceme, aby se uživatelé mohli podívat na zprávy, které byly do karantény umístěny, a případně je uvolnit z karantény. Proto musíme povolit End-User Quarantine Access. Autentizace vůči AD DS se provádí pomocí LDAPu. V nastavení System Administration - LDAP musíme vytvořit Spam Quarantine End-User Authentication Query (a musí být nastaveno jako aktivní dotaz). Na některém IP Interface musí být povolena karanténa a určen port pro přístup.

Další užitečná vlastnost, aby se uživatelé nemuseli do karantény stále připojovat, je poslat jim třeba jednou denně emailový report, pokud mají nějaké zprávy v karanténě. Povolíme Spam Notifications, zvolíme parametry reportu a jeho plánování. Můžeme také povolit Enable login without credentials for quarantine access.

Nakonec musíme určit, jaké zprávy se do karantény umisťují. To znamená upravit Mail Policies - Incoming Mail Policies, v části Anti-Spam zvolíme pro identifikovaný Spam akci Spam Quarantine.

Administrátor vidí veškeré zprávy v karanténě a může je filtrovat. Odkaz do karantény se nachází na několika místech nebo můžeme použít přímou adresu karantény, třeba Monitor - Spam Quarantine ve sloupci Messages je počet všech zpráv v karanténě a kliknutím se otevře nové okno karantény. Stejně tak se může administrátor podívat na obsah Safelists / Blocklists všech uživatelů. V pravém horním rohu menu Options a buď Safelists nebo Blocklists, vidíme, pro jakou adresu jsou nastaveny jaké výjimky.

Konfigurace politik - Incoming Mail Policies

• Mail Policies - Incoming Mail Policies

ESA používá Mail Policies pro vynucení pravidel na přijímané a odesílané zprávy. Zde se zaměříme na příjem pošty a tedy Incoming Mail Policies.

Můžeme vystačit pouze s jednou politikou - Default Policy, kde nastavíme společné chování pro všechny odesílatele i příjemce. Nebo vytvořit více politik, kde třeba pro skupinu uživatelů definujeme jiné chování (například místo umístění Spamu do karantény se zprávy rovnou mažou).
Každá politika má dané oblasti, které můžeme konfigurovat

• Anti-Spam - zapnutí, akce k identifikovanému Spamu a zprávám podezřelým jako Spam, hranice pro určení Spamu z bodování 1 - 100
• Anti-Virus - zapnutí, pouze sken vs. léčení, chování k šifrovaným či neskenovatelným zprávám, a pokud se nalezl virus
• Advanced Malware Protection (AMP) - zapnutí File Reputation a File Analysis, chování pro různé situace, můžeme nastavit, že zprávy, u kterých probíhá analýza, jsou umístěny do karantény (nejsou doručeny uživateli), v parametrech File Analysis Quarantine nastavujeme dobu, po které jsou zprávy uvolněny (a pak se kontroluje výsledek testu)
• Graymail - zapnutí (případně odhlášení), akce pro různé kategorie
• Content Filters - přiřazujeme filtry obsahu vytvořené v Incoming Content Filters
• Outbreak Filters - povolujeme umístění do karantény a parametry, případně modifikace zpráv

Když vytváříme politiku, tak jako první určujeme, na jaké uživatele se bude aplikovat. Může jít o všechny nebo určené příjemce či odesílatele. Adresy můžeme ručně vypsat nebo použít LDAP skupiny. Politiky se prochází od shora dolů a první, kde odpovídají podmínky (odesílatel a příjemce), se uplatní (First Match Wins), dále se nepokračuje.

Adresy se mohou zadávat nejen jako kompletní bouska@firma.cz, ale i části bouska@ nebo @firma.cz.

Na stránce se seznamem politik máme také vyhledávání podle emailové adresy, které nám ukáže, jaká politika se pro daného příjemce nebo odesílatele uplatní.

Message Filters

Message Filters skenují obsah zpráv, přílohy, apod. a podle definovaných podmínek identifikují zprávy a provádí následné akce. Mají přístup i k metadatům (jako příchozí listener, IP odesílatele, SBRS). Filtry se zapisují textově ve tvaru skriptu a využívají regulární výrazy. Základní formát je

jméno: 
if (podmínka) { 
 akce 
} 

Konfigurovat je můžeme jedině v příkazové řádce (CLI), kde filtr vytvoříme a textově vložíme.

Content Filters

• Mail Policies - Incoming Content Filters

Speciální variantou Message Filters jsou Incoming a Outgoing Content Filters. Využívají stejný skriptovací jazyk, ale pouze podmnožinu pravidel. Jde o taková pravidla, která slouží k identifikaci zprávy na základě obsahu. Můžeme je jednoduše definovat průvodcem ve webovém rozhraní (GUI).

Message Filters se aplikují jako první krok zpracování politik. Když se aplikuje akce, tak ovlivní všechny příjemce zprávy (aplikuje se na celou zprávu). Content Filters se aplikují jako poslední, poté co byla zpráva rozdělena na samostatné kopie podle Mail Policies (podle skupin příjemců).

Sender Domain Reputation (SDR) Filtering

• Security Services - Domain Reputation

V Message Filters nebo Content Filters můžeme použít Sender Domain Reputation pro filtrování zpráv. Ve výchozím stavu se SDR nepoužívá.