A levelező bombázás az egyik legrégebbi kibertámadási módszer. Lényegét tekintve hasonlít a hagyományos DoS támadáshoz, csupán annyiban különbözik, hogy egy sor különböző IP-címről érkező kérések helyett egy e-mail címre hatalmas mennyiségű elektronikus levél érkezik. Ezáltal jelentősen megnöveli a terhelést, ami megnehezíti a postaláda használatát, sőt, néha akár az egész szerver leállásához is vezethet. A levelező bombázás évtizedes története pozitív és negatív következményekhez egyaránt vezetett a rendszeradminisztrátorok számára. Pozitívumként említhető, hogy a levelező bombázás jól tanulmányozott, és egyszerű módszerek állnak rendelkezésre a védekezésre. Negatívumként viszont megemlíthető, hogy számos nyilvánosan elérhető szoftvermegoldás létezik az ilyen típusú támadások végrehajtására, és a támadónak lehetősége van alapos védelmet kialakítani az észlelés ellen.
A támadás fontos jellemzője, hogy gyakorlatilag lehetetlen profitot termelni vele. Ha a támadó egy e-mail fiókra hatalmas mennyiségű elektronikus levelet küld, vagy ha valaki ellopja egy vállalati e-mail fiókját és tömegesen küldözget ezer levelet a GAL-on, akkor a szerver vagy összeomlik, vagy elkezd lassan működni, így használhatatlanná válik - mi történik ezután? Az ilyen kibertámadások pénzre váltása szinte lehetetlen, ezért a levelező bombázás napjainkban viszonylag ritka jelenséggé vált, és a rendszeradminisztrátorok a hálózati infrastruktúra tervezésekor simán megfeledkezhetnek arról, hogy szükség van védelemre az ilyen típusú kibertámadások ellen.
Ennek ellenére, bár a levélbombázás önmagában kereskedelmi szempontból meglehetősen értelmetlen tevékenység, gyakran más, bonyolultabb és többlépcsős kiber támadások részeként használják. Például, amikor egy e-mail fiókot feltörnek és azt egy nyilvános szolgáltatás fiókjának elrablására használják, a támadók gyakran "bombázzák" az áldozat e-mail fiókját értelmetlen üzenetekkel, hogy a megerősítő e-mail elveszjen a folyamban, és észrevétlen maradjon. A levélbombázás olyan gazdasági nyomásgyakorlásra is használható, amely egy vállalat számára problémás lehet. Például, ha aktívan bombázzák a vállalat nyilvános e-mail fiókját, amelybe az ügyfelek kérelmei érkeznek, az komoly nehézségeket okozhat az üzletmenetben, ami következésképpen berendezések leállításához, be nem teljesített megrendelésekhez, valamint hírnév és haszonkieséshez vezethet.
Éppen ezért a rendszergazdának nem szabad elfelejtenie a levélbombázás valószínűségét, és mindig meg kell tennie a szükséges intézkedéseket ennek a fenyegetésnek a kivédésére. Figyelembe véve, hogy ezt még a levelezési infrastruktúra kiépítése során is meg lehet tenni, valamint azt, hogy ez a rendszergazdának többnyire nagyon kevés időt és munkát igényel, objektív okai nincsenek annak, hogy ne biztosítsa infrastruktúráját a levélbombázás védelme érdekében. Nézzük meg, hogyan hajtják végre a védelmet e kiber támadás ellen a Zimbra Collaboration Suite Open-Source Edition-ben.
A Zimbra alapja a Postfix, amely jelenleg az egyik legmegbízhatóbb és legfunkcionálisabb nyílt forráskódú levelezésátviteli ügynök. Ennek nyitottságának egyik legnagyobb előnye, hogy számos külső megoldást támogat a funkcionalitás bővítésére. Különösen a Postfix teljes mértékben támogatja a cbpolicyd-t, amely egy fejlett eszköz a levelezőszerver kibervédelmének érdekében. A spam elleni védelem mellett, valamint fehér, fekete és szürke listák létrehozása mellett a cbpolicyd lehetővé teszi a Zimbra rendszergazda számára, hogy beállítsa az SPF-aláírás ellenőrzését, illetve korlátozásokat állítson be az e-mailek fogadására és küldésére. Ezek nemcsak a spam és phishing e-mailek megbízható védelmét biztosíthatják, hanem megvédhetik a szervert a levélbombázástól.
Az első dolog, amire a rendszeradminisztrátornak szüksége lesz, a cbpolicyd modul aktiválása, amely előtelepítve található a Zimbra Collaboration Suite OSE MTA-szerverén. Ezt a zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd parancs segítségével hajtjuk végre. Ezután aktiválni kell a webes felületet, hogy kényelmesen kezelhessük a cbpolicyd-t. Ehhez engedélyezni kell a csatlakozást a 7780-as webporton, szimbolikus linket kell létrehozni a következő parancs segítségével ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, majd szerkeszteni kell a beállítási fájlt a nano parancs segítségével /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, ahol a következő sorokat kell megadni:
$DB_DSN=„sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb“;
$DB_USER=„root“;
$DB_TABLE_PREFIX=„“;
Ezután csak újra kell indítani a Zimbra és Zimbra Apache szolgáltatásokat a zmcontrol restart és a zmapachectl restart parancsokkal. Ezt követően elérheti a webes felületet a következő címen :7780/webui/index.php. A legfontosabb szempont, hogy a webes felületbe való belépés jelenleg egyáltalán nincs védve, ezért a külső személyek hozzáférésének elkerülése érdekében az egyes belépések után egyszerűen zárja le a 7780-as porton való kapcsolódásokat.
A belső hálózatból kiinduló levelek áramlásának megfékezésére lehetőséget adnak az elektronikus posta küldésére vonatkozó kvóták, amelyeket a cbpolicyd segítségével állíthatunk be. Ezek a kvóták lehetővé teszik a maximális levelek számának korlátozását, amelyet egy e-mail fiókból küldhetnek egy adott időegység alatt. Például, ha a vállalata menedzserei átlagosan 60–80 elektronikus levelet küldenek óránként, akkor egy kis tartalékkal számolva 100 levél/órás kvótát állíthatunk be nekik. Ahhoz, hogy kimerítsenek egy ilyen kvótát, a menedzsereknek 36 másodpercenként egy levelet kellene küldeniük. Egyrészt ez elegendő a teljes értékű munkához, másrészt ezzel a kvótával a rosszindulatú támadók, akik hozzáfértek az egyik menedzser e-mailjéhez, nem tudnak levelezési bombázást vagy tömeges spam támadást végezni a cégen.
A hasonló kvóta beállításához a webes felületen új e-mail küldési korlátozási politikát kell létrehozni, és meg kell határozni, hogy ez a házon belüli levelekre és a külső címekre is vonatkozzon. Ezt a következőképpen tehetjük:
Ezt követően részletesebben megadhatjuk a levélküldésre vonatkozó korlátozásokat, különösen beállíthatjuk az időintervallumot, amely után a korlátozások frissülnek, valamint azt az üzenetet, amelyet a felhasználó kap, ha túllépi a korlátait. Ezt követően a levélküldésre vonatkozó korlát is beállítható. Ez megadható mint az elküldött levelek számában, vagy az átvitt információ byte-jainak számában. A megadott határon túli levelek kezelését eltérően lehet végezni. Például azokat azonnal törölhetjük, de meg is tarthatjuk, hogy azonnal elküldésre kerüljenek a levélküldési limit frissítése után. A második opciót érdemes kihasználni a vállalkozások által alkalmazott optimális levéllimit meghatározásakor.
A levélküldési korlátozások mellett a cbpolicyd lehetővé teszi a levelek fogadási limitjének beállítását is. Ez a korlátozás első pillantásra kiváló megoldásnak tűnik a levélbombázás elleni védelemre, azonban a gyakorlatban egy ilyen limit beállítása, még ha nagy is, azt eredményezheti, hogy bizonyos körülmények között fontos üzenetek nem jutnak el hozzád. Ezért rendkívül nem ajánlott bármilyen korlátozást bevezetni a bejövő leveleknél. Ha azonban mégis úgy döntöttél, hogy kockáztat, a bejövő üzenetek limitjének beállításához különös figyelmet kell fordítani. Például korlátozhatod a megbízható partnerektől érkező bejövő levelek számát, hogy ha az ő levelezőszerverük kompromittálódik, ne folytathasson spam-támadást a vállalatodra.
A bejövő üzenetek áradata elleni védekezés érdekében levélbombázás esetén a rendszergazdának valami okosabb lépést kell tennie, mint a bejövő levelek egyszerű korlátozása. Ezt a problémát a szürke listák alkalmazásával lehet megoldani. A működési elvük az, hogy amikor egy megbízhatatlan feladótól próbálnak először üzenetet küldeni, a kapcsolat a szerverrel hirtelen megszakad, így a levél szállítása sikertelenül ér véget. Ha azonban egy meghatározott időszakon belül a megbízhatatlan szerver újra megpróbálja elküldeni ugyanazt az üzenetet, a szerver nem szakítja meg a kapcsolatot, és a levél sikeresen megérkezik.
Ennek a tevékenységsornak az a lényege, hogy az automatikus tömeges e-mail küldésre szolgáló programok általában nem ellenőrzik a küldött üzenet sikeres kézbesítését, és nem tesznek kísérletet az újraküldésre, míg egy ember biztosan meggyőződik arról, hogy a levele elküldésre került-e, vagy sem.
A szürke listák webes felületén, a cbpolicyd-ben is aktiválhatók. Ahhoz, hogy minden zökkenőmentesen működjön, létre kell hozni egy politikát, amely minden bejövő levelet magában foglal, amit a kiszolgálónk felhasználóinak küldenek, majd ezt a politikát alapul véve egy Szürke lista szabályt kell definiálni, ahol beállítható az az időintervallum, amely alatt a cbpolicyd várni fog a válaszra egy ismeretlen feladótól. Ez általában 4-5 percet vesz igénybe. Ezen felül a szürke listák úgy is beállíthatók, hogy minden sikeres és sikertelen levelezési kísérletet különböző feladóktól rögzítenek, és az ezek alapján hozott döntések automatikus fehér- vagy feketelistára helyezésről szólnak.
Felhívjuk figyelmét, hogy a szürke listák használatát a lehető legnagyobb felelősséggel kell végezni. A legjobban akkor járunk el, ha ennek a technológiának a használata párhuzamosan halad a fehér és fekete listák folyamatos vezetésével, hogy kizárjuk a valóban fontos üzleti levelek elvesztésének lehetőségét.
Ezen kívül a maily bombázás ellen védelmet nyújthat az SPF, DMARC és DKIM ellenőrzések hozzáadásával. Gyakran az ilyen maily bombázás során beérkező levelek nem teljesítik ezeket az ellenőrzéseket. Arról, hogy hogyan lehet ezt megtenni, már korábban esett szó. .
Így tehát a maily bombázás ellen védekezni viszonylag egyszerű, és ezt még a Zimbra infrastruktúra felépítésekor meg lehet tenni cége számára. Fontos azonban, hogy folyamatosan nyomon kövesse, hogy a védelem használatából eredő kockázatok soha ne haladják meg a megszerzett előnyöket.
Forrás: habr.com
