Mailové bombardování je jedním z nejstarších typů kybernetických útoků. V jádru to připomíná běžný DoS útok, ale místo vlny požadavků z různých IP adres je na server odeslána vlna e-mailů, které na jednu z e-mailových adres dorazí v obrovském množství, díky čemuž se zatížení se výrazně zvyšuje. Takový útok může vést k nemožnosti používat poštovní schránku a někdy i k výpadku celého serveru. Dlouhá historie tohoto typu kybernetických útoků vedla k řadě pozitivních i negativních důsledků pro systémové administrátory. Mezi pozitivní faktory patří dobrá znalost poštovního bombardování a dostupnost jednoduchých způsobů, jak se před takovým útokem chránit. Mezi negativní faktory patří velké množství veřejně dostupných softwarových řešení pro provádění takových typů útoků a schopnost útočníka spolehlivě se chránit před odhalením.
Důležitou vlastností tohoto kybernetického útoku je, že je téměř nemožné jej využít k zisku. No, útočník poslal vlnu e-mailů do jedné z poštovních schránek, no, nenechal toho člověka normálně používat e-mail, no, útočník se naboural do něčí firemní pošty a začal hromadně posílat tisíce dopisů po celé GAL, protože který server buď havaroval nebo se začal zpomalovat tak, že jej nebylo možné používat, a co potom? Převést takový kybernetický zločin na skutečné peníze je téměř nemožné, takže poštovní bombardování je nyní poměrně vzácným jevem a správci systému si při navrhování infrastruktury nemusí pamatovat nutnost ochrany před takovým kyberútokem.
I přes to, že samotné mailové bombardování je z komerčního hlediska spíše nesmyslnou činností, je však často nedílnou součástí jiných, složitějších a vícestupňových kybernetických útoků. Když například útočníci nabourají poštu a použijí ji k únosu účtu v některé veřejné službě, často „bombardují“ poštovní schránku oběti nesmyslnými dopisy, takže potvrzovací dopis se v jejich streamu ztratí a zůstane nepovšimnut. Poštovní bombardování lze také použít jako prostředek ekonomického tlaku na podnik. Například aktivní bombardování veřejné poštovní schránky podniku, která přijímá aplikace od zákazníků, může vážně ztížit práci s nimi a v důsledku toho může vést k prostojům zařízení, nevyřízeným objednávkám, ale i ztrátě reputace a ušlému zisku.
Proto by správce systému neměl zapomínat na možnost mailového bombardování a vždy přijmout nezbytná opatření k ochraně před touto hrozbou. Vzhledem k tomu, že to lze provést již ve fázi budování poštovní infrastruktury a také to, že to vyžaduje velmi málo času a úsilí ze strany správce systému, prostě neexistují žádné objektivní důvody, proč neposkytnout vaší infrastruktuře ochranu před poštovním bombardováním. Pojďme se podívat, jak je ochrana proti tomuto kybernetickému útoku implementována v Zimbra Collaboration Suite Open-Source Edition.
Zimbra je založena na Postfixu, jednom z nejspolehlivějších a nejfunkčnějších open source agentů pro přenos pošty v současnosti. A jednou z hlavních výhod jeho otevřenosti je, že podporuje širokou škálu řešení třetích stran pro rozšíření funkčnosti. Postfix zejména plně podporuje cbpolicyd, pokročilý nástroj pro kyberbezpečnost poštovního serveru. Kromě ochrany proti spamu a whitelistingu, blacklistingu a greylistingu umožňuje cbpolicyd správci Zimbry nastavit ověřování podpisu SPF a také nastavit limity pro přijímání a odesílání e-mailů nebo dat. Mohou poskytnout spolehlivou ochranu proti spamu a phishingovým e-mailům a také chránit server před e-mailovým bombardováním.
První věc, kterou správce systému vyžaduje, je aktivace modulu cbpolicyd, který je předinstalován v prostředí Zimbra Collaboration Suite OSE na infrastrukturním serveru MTA. To se provádí pomocí příkazu zmprov ms `zmhostname` + zimbraServiceEnabled cbpolicyd. Poté budete muset aktivovat webové rozhraní, abyste mohli pohodlně spravovat cbpolicyd. Chcete-li to provést, musíte povolit připojení na webovém portu číslo 7780, vytvořte symbolický odkaz pomocí příkazu ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webuia poté upravte soubor nastavení pomocí příkazu nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, kde je třeba napsat následující řádky:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";
Poté zbývá pouze restartovat služby Zimbra a Zimbra Apache pomocí příkazů zmcontrol restart a zmapachectl restart. Poté budete mít přístup k webovému rozhraní na adrese :7780/webui/index.php. Hlavní nuancí je, že vstup do tohoto webového rozhraní zatím není nijak chráněn, a aby se do něj nedostaly neoprávněné osoby, můžete po každém vstupu do webového rozhraní jednoduše uzavřít spojení na portu 7780.
Pro ochranu před záplavou emailů přicházejících z vnitřní sítě můžete využít kvóty pro zasílání emailů, které lze nastavit díky cbpolicyd. Takové kvóty umožňují nastavit limit na maximální počet dopisů, které lze odeslat z jedné poštovní schránky za jednotku času. Pokud například manažeři ve vaší firmě odesílají v průměru 60–80 e-mailů za hodinu, můžete nastavit kvótu 100 e-mailů za hodinu s malým prostorem. Aby manažeři vyčerpali tuto kvótu, budou muset každých 36 sekund odeslat jeden dopis. Na jedné straně to stačí k plnému fungování a na druhé straně s takovou kvótou útočníci, kteří získali přístup k poště jednoho z vašich manažerů, nezařídí poštovní bombardování nebo masivní spamový útok na podnik. .
Chcete-li nastavit takovou kvótu, musíte ve webovém rozhraní vytvořit novou zásadu omezení odesílání e-mailů a určit, že se vztahuje jak na e-maily odesílané v rámci domény, tak na e-maily odeslané na externí adresy. To se provádí následovně:
Poté bude možné blíže specifikovat omezení spojená s odesíláním dopisů, zejména nastavit časový interval, po kterém budou omezení aktualizována, a také zprávu, kterou uživatel, který překročil svůj limit, obdrží. Poté můžete nastavit samotné omezení odesílání dopisů. Lze jej nastavit jak jako počet odchozích zpráv, tak i jako počet bajtů přenášených informací. Zároveň s dopisy, které jsou odesílány nad stanovený limit, jednajte jinak. Můžete je tedy například jednoduše okamžitě smazat, nebo je můžete uložit tak, aby šly ihned po aktualizaci limitu pro odesílání zpráv. Druhou možnost lze využít při stanovení optimální hodnoty limitu zasílání emailů zaměstnancům.
Kromě limitů odesílání e-mailů vám cbpolicyd umožňuje nastavit limit pro přijímání e-mailů. Takový limit je na první pohled vynikajícím řešením pro ochranu před poštovním bombardováním, ale ve skutečnosti je stanovení takového limitu, i když je velké, zatíženo skutečností, že za určitých podmínek se k vám důležitý dopis nemusí dostat . Proto se důrazně nedoporučuje povolovat jakákoli omezení pro příchozí poštu. Pokud se však přesto rozhodnete riskovat, musíte k nastavení limitu příchozích zpráv přistupovat se zvláštní pozorností. Můžete například omezit počet příchozích e-mailů od důvěryhodných protistran, takže pokud bude jejich poštovní server kompromitován, nebude to spamovat vaši firmu.
Aby se ochránil před záplavou příchozích zpráv z poštovního bombardování, měl by správce systému udělat něco chytřejšího, než prosté omezení příchozí pošty. Takovým řešením by mohlo být použití šedých seznamů. Princip jejich fungování spočívá v tom, že při prvním pokusu o doručení zprávy od nespolehlivého odesílatele se náhle přeruší spojení se serverem, čímž se doručení zprávy nezdaří. Pokud se však nedůvěryhodný server pokusí odeslat stejný e-mail znovu během určité doby, server spojení nepřeruší a jeho doručení je úspěšné.
Smyslem všech těchto akcí je, že automatické hromadné e-mailové programy většinou nezkontrolují úspěšnost odeslané zprávy a nepokusí se ji odeslat podruhé, přičemž se dotyčný jistě ujistí, zda jeho dopis byl odeslán na adresu či nikoliv .
Greylisting můžete povolit i ve webovém rozhraní cbpolicyd. Aby vše fungovalo, musíte vytvořit politiku, která by zahrnovala všechny příchozí dopisy adresované uživatelům na našem serveru, a poté na základě této zásady vytvořit pravidlo Greylisting, kde můžete nakonfigurovat interval, během kterého bude cbpolicyd čekat pro druhou odpověď od neznámého odesílatele. Obvykle je to 4-5 minut. Šedé seznamy lze zároveň nakonfigurovat tak, aby byly zohledněny všechny úspěšné i neúspěšné pokusy o doručení dopisů od různých odesílatelů a na základě jejich počtu bylo rozhodnuto o automatickém přidání odesílatele na bílou nebo černou listinu.
Upozorňujeme na skutečnost, že k používání šedých seznamů je třeba přistupovat s maximální odpovědností. Nejlepší by bylo, kdyby používání této technologie šlo ruku v ruce s neustálým udržováním bílých a černých listin, aby se vyloučila možnost ztráty dopisů, které jsou pro podnik skutečně důležité.
Navíc přidání kontrol SPF, DMARC a DKIM může pomoci chránit před e-mailovým bombardováním. Často dopisy, které přicházejí v procesu poštovního bombardování, neprojdou takovými kontrolami. Jak to udělat, bylo vysvětleno .
Je tedy docela jednoduché se chránit před takovou hrozbou, jako je poštovní bombardování, a můžete to udělat i ve fázi budování infrastruktury Zimbra pro váš podnik. Je však důležité neustále zajistit, aby rizika používání takové ochrany nikdy nepřevýšila výhody, které získáte.
Zdroj: www.habr.com