www.SAMURAJ-cz.com 

02.05.2024 Zikmund Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Cisco Email Security - provozní správa a činnosti

Upraveno 14.01.2020 12:20 | vytvořeno 17.10.2019 11:55 | Samuraj - Petr Bouška |
Použití řešení Cisco Email Security (dříve Ironport) na filtrování nevyžádané pošty. Článek popisuje některé činnosti a nastavení z běžné provozní správy, tedy co děláme průběžně po úvodní implementaci. Primárně jde o to, jak identifikovat zablokované zprávy a nastavení výjimek, aby se některé zprávy doručily, i když jsou identifikovány jako Spam.

Kontroly

Kontrola aktuálnosti definic a dostupnosti online služeb

  • Security Services - IronPort Anti-Spam
  • Security Services - Services Overview
  • Security Services - IMS and Graymail
  • Security Services - Sophos
  • Security Services - Outbreak Filters
  • Security Services - SenderBase

Reporty

  • Monitor

ESA obsahuje velké množství reportů. Některé můžeme naplánovat a nechat si posílat na email Monitor - Scheduled Reports. Základní pohled máme na Dashboard. V menu Monitor se pak nachází reporty z různých oblastí, často vedou prolinky na detailnější report, případně se v horní části přepínají záložky.

Přidání akceptované domény

  • Mail Policies - Recipient Access Table (RAT)

Pokud máme novou doménu, pro kterou chceme přijímat poštu, tak ji musíme přidat do Recipient Access Table (RAT).

  • Network - SMTP Routes

Pokud máme definované směrování jednotlivých domén na interní poštovní server (třeba nevyužíváme hromadné All Other Domains), tak musíme vytvořit také záznam v SMTP Routes.

Fronta zpráv a vynucení odeslání

  • Monitor - Delivery status

Položka Active recipients znamená, že zprávy pro tuto doménu jsou ve frontě. Můžeme rozkliknout doménu a zvolit Retry Delivery.

Řešení nedoručených zpráv

Nejčastější oblast z praxe je hledání, proč některá zpráva nebyla doručena, a případně nastavení nějaké výjimky na AntiSpamu. ESA může zprávu odmítnout či zablokovat na různých službách a podle toho se liší i reakce.

  • IP Reputation - Host Access Table (HAT) - při navazování spojení na Listener se kontroluje zdrojová adresa pomocí HAT
  • Recipient Access Table (RAT) - kontrola adresy příjemce (nenalezl jsem v jaké chvíli se provádí)
  • Incoming Mail Policies - v rámci politiky probíhá řada kontrol (pokud jsou pro dané příjemce/odesílatele zapnuté)
    • Message Filters
    • Anti-Spam
    • Content Filters

V některých případech, například IP reputace, je odmítnuto příchozí spojení a standardně dostane odesílající server informaci, která je doručena odesílateli do mailu. Když je zpráva identifikována jako Spam, tak je dle politiky smazána nebo umístěna do karantény. Odesílatel žádnou informaci nedostane, příjemce pouze pokud používáme karanténu a zasíláme report.

Jako správce máme několik možností, jak hledat nedoručenou zprávu. Informace jsou v dalších kapitolách.

Sledování zpráv - Message Tracking

  • Monitor - Message Tracking

Tuto funkci musíme mít zapnutou. Pak můžeme zadat nějaké parametry hledané zprávy, primárně emailovou adresu odesílatele a časový interval. Zobrazí se nám nalezené položky, kde vidíme LAST STATE, který většinou říká, zda byla zpráva doručena cílovému poštovnímu serveru, anebo vložena do karantény. Případně můžeme kliknout na Show Details a zobrazí se okno s detailními logy.

Cisco Email Security - Message Tracking

Pokud se zpráva nenalezne, tak pravděpodobně bylo zablokováno již spojení ze zdrojové IP adresy a tudíž nemáme informace o detailech zprávy.

Kontrola reputace - odesílatel dostává chybu

Na webu https://www.talosintelligence.com/ zjistíme hodnocení domény nebo IP adresy.

Pokud má příchozí spojení (zdrojová IP adresa) špatnou reputaci, tak je standardně odmítnuto navázání spojení. Zpráva, kterou chtěl odesílatel poslat, se tak nedostane příjemci do karantény, ani nenajdeme jednoduše v logu. Odesílající poštovní server dostane chybu, kterou většinou doručí jako odpověď odesílateli.

mail.firma.cz: 554-mail.firma.cz 554 Your access to this mail system has been rejected due to the sending MTA's poor
 reputation. If you believe that this failure is in error, please con tact the intended recipient via alternate means.

V takovém případě můžeme ověřit, že odesílající adresa/doména má špatnou reputaci na webu Talos. Problém je, jak určit, z které IP adresy byla zpráva odeslána. Pro doménu odesílatele se můžeme podívat v DNS na MX záznam, to je ovšem primárně adresa pro příjem pošty pro danou doménu, odesílací adresa může být jiná. Pokud je v DNS textový SPF záznam, tak v něm najdeme adresu, z které by pošta měla odcházet.

Pokud na webu https://www.talosintelligence.com zadáme doménu, tak se nalezne i poštovní server dle MX záznamu. Pokud zadáme IP adresu, tak se vypisují IP adresy, které odesílají poštu, pro daný subnet.

Message Tracking - hledání odmítnutého spojení z dané IP adresy

Pokud jsme při Zapnutí logu sledování zpráv povolili ukládání informací o odmítnutých spojeních (Save tracking information for rejected connections), tak můžeme využít Message Tracking.

  • Monitor - Message Tracking
  • rozklikneme Advanced
  • zadáme IP adresu do Sender IP Address/Domain/Network Owner
  • a zvolíme Search rejected connections only
  • vybereme potřebný časový interval a spustíme Search

Pokud neukládáme odmítnutá spojení, tak se pořád můžeme podívat do logu, viz. další kapitola.

Prohlížení logů - hledání odmítnutého spojení z dané IP adresy

Pokud potřebujeme vidět přímo logy o zpracování pošty, tak si buď stáhneme textový soubor, nebo se připojíme na CLI (standardně pomocí SSH) a použijeme příkazy pro zobrazení.

Stažení log souboru

  • System Administration - Log Subscriptions
  • vybereme požadovaný log (nyní mail_logs) a klikneme na jméno ve sloupci Log Files
  • kliknutím na název souboru dle data zahájíme stahování přes web

Prohledávání logů v CLI

Výpis posledních deseti záznamů a všech aktuálních.

tail mail_logs

Prohledávání pomocí samotného příkazu grep a průvodce nebo zadáním příkazu s regulárním výrazem pro hledání. Jednoduše můžeme zadat nějaký čas (příkazem výše se podíváme, jak se ukládá), příklad 7. 10. 13:15 a libovolný další text.

grep -e "Mon Oct  7 13:15.*" mail_logs

Nastavení výjimek - Safe Senders, Whitelist

Pokud jsme identifikovali, kde je příchozí zpráva zablokována, tak můžeme nastavit výjimku, aby nedošlo k filtrování a zpráva byla příště doručena. Nejčastější je přidat odesílací IP adresu do HAT nebo odesílací email do politiky, která neprovádí AntiSpam kontrolu. Pokud používáme karanténu, tak si určité výjimky mohou nastavovat sami uživatelé. Případně můžeme špatně klasifikované zprávy reportovat do Cisco.

Níže je jen ukázka, jak nastavení výjimky na emailovou adresu či IP adresu, může vypadat jednoduše a intuitivně v provedení Symantec Messaging Gateway. Dále je stručně popsáno komplikované řešení Cisco.

Symantec Messaging Gateway - nastavení Safe Senders

Odesílací IP adresa

  • Mail Policies - HAT Overview - WHITELIST

Pro každý Listener definujeme pravidla, která určují vzdálené hosty (IP adresy odesílatelů), kteří mají povoleno se připojit. K tomu se využívá Host Access Table (HAT). Zde se standardně využívá SenderBase Reputation Service, takže pak jsou některé IP adresy blokovány podle reputace.

Pokud máme nějakého důvěryhodného odesílatele, ve stylu poštovního serveru, tak můžeme zadat jeho IP adresu do skupiny WHITELIST, kde se uplatňuje politika TRUSTED. Tito odesílatelé nejsou kontrolování ani pomocí IP reputace ani AntiSpam engine (ale Antivirová kontrola probíhá).

Cisco Email Security - HAT

Emailová adresa odesílatele

  • Mail Policies - Incoming Mail Policies

Pokud potřebujeme, aby zprávy z nějaké emailové adresy, nebyly označeny jako Spam (neproběhla jejich kontrola), tak je jediné řešení vytvořit speciální Incoming Mail Policy ve stylu Safe Sender Emails či Skip AntiSpam Scan. Vytvoříme politiku, kterou zařadíme na začátek seznamu. Do politiky přidáme uživatele - Add User, zde můžeme specifikovat příjemce i odesílatele pomocí přesné adresy či pouze domény. Na politice disablujeme funkci Anti-Spam, případně i další.

Cisco Email Security - Incoming Mail Policies Whitelist

Pozn.: Stejným způsobem můžeme definovat příjemce, kteří obdrží všechny zprávy (neprovádí se pro ně AntiSpam kontrola).

Emailová adresa příjemce

  • Mail Policies - Recipient Access Table (RAT)

Hlavní rozhodnutí, zda bude nějaká adresa přijata, se provádí pomocí Recipient Access Table (RAT). Zde můžeme nastavit celé domény či jednotlivé emailové adresy, a určit, zda jsou přijaty nebo odmítnuty. Případně nastavit Bypass Receiving Control. Pořád, když nastavíme adresu, aby se přijímala, tak probíhá AntiSpam kontrola.

Doména firma.cz obsáhne emailové adresy na této doméně, dále můžeme definovat všechny subdomény .firma.cz.

Výjimka ze Sender Domain Reputation

  • Security Services - Domain Reputation - Domain Exception List

Pokud používáme SDR, tak pro určité domény můžeme určit, aby neprobíhala kontrola.

Výjimky ze Sender Verification

  • Mail Policies - Exception Table

Pokud používáme Sender Verification, tak můžeme definovat výjimky.

Bezpeční odesílatelé per uživatel

  • Spam Quarantine - Options - Safelist

V karanténě si každý uživatel může spravovat svůj Safelist a Blocklist. Administrátor je může editovat pro všechny uživatele.

Reportování špatně klasifikovaných zpráv do Cisco

V nastavení karantény můžeme povolit, aby se při uvolnění zprávy z karantény (kdy je doručena uživateli), zaslala do Cisco pro analýzu. Ale hlavní řešení, když chceme informovat Cisco o špatné klasifikaci zprávy, je popsáno v Reporting Incorrectly Classified Messages to Cisco.

Znamená to se registrovat na Submission and Tracking Portal. Účet provážeme s naší appliance v System Administration - Email Submission and Tracking Portal Registration. Pak musíme registrovat svoje domény. Následně je možno využívat plugin do Outlooku, výše zmíněný portál nebo posílat zprávy v příloze na speciální adresy.

zobrazeno: 6451krát | Komentáře [0]

Autor:

Související články:

Elektronická pošta - email

Protokol SMTP a jeho vlastnosti. Ochrana elektronické pošty proti SPAMu a Phishingu. Šifrování pošty...

Microsoft Exchange

Jednou částí mé práce je administrace poštovního serveru od firmy Microsoft, tedy Exchange Serveru. Články začínají u verze 2003 a jak jde čas, tak pokračují dále.

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

Zatím tento záznam nikdo nekomentoval.

Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách