A levélbombázás a kibertámadások egyik legrégebbi típusa. Lényegében egy szokásos DoS támadásra hasonlít, csak a különböző IP-címekről érkező kérések hulláma helyett levelek hulláma érkezik a szerverre, amelyek hatalmas mennyiségben érkeznek valamelyik email címre, ami miatt a terhelés rajta jelentősen megnő. Egy ilyen támadás a postafiók használatának képtelenségéhez vezethet, sőt néha a teljes szerver meghibásodásához is vezethet. Az ilyen típusú kibertámadások hosszú története számos pozitív és negatív következménnyel járt a rendszergazdák számára. A pozitív tényezők közé tartozik a levélbombázás jó ismerete és az ilyen támadások elleni védekezés egyszerű módjai. A negatív tényezők közé tartozik az ilyen típusú támadások végrehajtására szolgáló nyilvánosan elérhető szoftvermegoldások nagy száma, valamint az, hogy a támadó megbízhatóan megvédheti magát az észleléstől.
Ennek a kibertámadásnak fontos jellemzője, hogy szinte lehetetlen haszonszerzésre használni. Nos, a támadó e-mail-hullámot küldött az egyik postafiókba, nos, nem engedte, hogy az illető normálisan használhassa az e-maileket, nos, a támadó feltörte valakinek a vállalati e-mail-címét, és elkezdett tömegesen küldeni több ezer levelet a GAL-ban, ami miért omlott össze a szerver, vagy kezdett lelassulni úgy, hogy lehetetlenné vált a használata, és mi a következő lépés? Szinte lehetetlen egy ilyen kiberbűnözést valódi pénzre váltani, ezért az egyszerű levélbombázás jelenleg meglehetősen ritka jelenség, és a rendszergazdák az infrastruktúra tervezésekor egyszerűen nem emlékeznek arra, hogy védekezni kell egy ilyen kibertámadás ellen.
Bár maga az e-mail bombázás kereskedelmi szempontból meglehetősen értelmetlen gyakorlat, gyakran más, összetettebb és többlépcsős kibertámadások része. Például, amikor a leveleket feltörik, és valamilyen közszolgáltatásban fiókot lopnak el vele, a támadók gyakran értelmetlen levelekkel „lebombázzák” az áldozat postafiókját, így a megerősítő levél elveszik az adatfolyamban, és észrevétlen marad. A levélbombázást a vállalkozásokra nehezedő gazdasági nyomásgyakorlás eszközeként is lehet használni. Így az ügyfelektől érkező kéréseket fogadó vállalkozás nyilvános postafiókjának aktív bombázása súlyosan megnehezítheti a velük való munkát, és ennek eredményeként a berendezések leállását, teljesítetlen megrendeléseket, valamint hírnévvesztést és elmaradt nyereséget okozhat.
Éppen ezért a rendszergazdának nem szabad megfeledkeznie az e-mail-robbantások valószínűségéről, és mindig meg kell tennie a szükséges intézkedéseket e fenyegetés elleni védelem érdekében. Tekintettel arra, hogy ez megtehető a levelezési infrastruktúra kiépítésének szakaszában, és azt is, hogy ez nagyon kevés időt és munkát igényel a rendszergazdától, egyszerűen nincs objektív oka annak, hogy ne védje meg infrastruktúráját a levélbombázás ellen. Vessünk egy pillantást arra, hogy a Zimbra Collaboration Suite Open-Source Edition hogyan valósítja meg a kibertámadás elleni védelmet.
A Zimbra a Postfixen alapul, amely az egyik legmegbízhatóbb és legfunkcionálisabb nyílt forráskódú levéltovábbító ügynök. Nyitottságának egyik fő előnye, hogy számos külső féltől származó megoldást támogat a funkcionalitás bővítése érdekében. A Postfix teljes mértékben támogatja a cbpolicyd-t, a levelezőszerver kiberbiztonságát biztosító fejlett segédprogramot. A levélszemét elleni védelem és a fehérlisták, feketelisták és szürkelisták létrehozása mellett a cbpolicyd lehetővé teszi a Zimbra adminisztrátor számára, hogy konfigurálja az SPF aláírás-ellenőrzést, valamint korlátozásokat állítson be az e-mailek vagy adatok fogadására és küldésére. Mindkettő megbízható védelmet nyújthat a spam és az adathalász e-mailek ellen, és megvédheti a szervert az e-mailek bombázásától.
Az első dolog, amit a rendszeradminisztrátortól megkövetel, a cbpolicyd modul aktiválása, amely előre telepítve van a Zimbra Collaboration Suite OSE-ben az infrastruktúra MTA-kiszolgálón. Ez a zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd paranccsal történik. Ezt követően aktiválnia kell a webes felületet, hogy kényelmesen kezelhesse a cbpolicyd-t. Ehhez engedélyeznie kell a kapcsolatokat a 7780-as webporton, és létre kell hoznia egy szimbolikus hivatkozást a paranccsal ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, majd szerkessze a beállításfájlt a nano paranccsal /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, ahol a következő sorokat kell beírni:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="gyökér";
$DB_TABLE_PREFIX="";
Ezek után már csak a zmcontrol restart és zmapachectl restart parancsok segítségével kell újraindítani a Zimbra és Zimbra Apache szolgáltatásokat. Ezt követően hozzáférhet a webes felülethez a címen :7780/webui/index.php. A fő árnyalat az, hogy ennek a webes felületnek a bejárata még semmilyen módon nem védett, és annak érdekében, hogy megakadályozzuk az illetéktelen személyek belépését, egyszerűen lezárhatja a kapcsolatokat a 7780-as porton a webes felület minden egyes belépése után.
A belső hálózatról érkező e-mailek áradatától megvédheti magát a cbpolicyd-nek köszönhetően beállítható e-mail-küldési kvóták használatával. Az ilyen kvóták lehetővé teszik, hogy korlátozza az egy postafiókból egy időegység alatt elküldhető levelek maximális számát. Például, ha a cégvezetők átlagosan 60-80 e-mailt küldenek óránként, akkor egy kis árrés figyelembevételével óránként 100 e-mail-kvótát állíthat be. A kvóta eléréséhez a menedzsereknek 36 másodpercenként egy e-mailt kell küldeniük. Egyrészt ez elég a teljes működéshez, másrészt egy ilyen kvótával azok a támadók, akik hozzáfértek valamelyik menedzser leveleihez, nem indítanak levélbombázást vagy hatalmas spamtámadást a vállalat ellen.
Egy ilyen kvóta beállításához létre kell hozni egy új e-mail küldési korlátozási szabályzatot a webes felületen, és meg kell adni, hogy az mind a tartományon belül küldött levelekre, mind a külső címekre küldött levelekre vonatkozzon. Ez a következőképpen történik:
Ezt követően részletesebben megadhatja a levélküldéshez kapcsolódó korlátozásokat, különösen beállíthatja azt az időintervallumot, amely után a korlátozások frissítésre kerülnek, valamint azt az üzenetet, amelyet a korlátot túllépő felhasználó kap. Ezt követően beállíthatja a levélküldés korlátozását. Beállítható mind a kimenő levelek számaként, mind a továbbított információ bájtjaiként. Ugyanakkor másként kell kezelni azokat a leveleket, amelyeket a megjelölt limitet meghaladóan küldenek. Így például egyszerűen törölheti őket azonnal, vagy elmentheti őket, hogy az üzenetküldési korlát frissítése után azonnal elküldésre kerüljenek. A második lehetőség az alkalmazottak általi e-mail-küldési korlát optimális értékének meghatározásakor használható.
A levélküldésre vonatkozó korlátozások mellett a cbpolicyd lehetővé teszi a levelek fogadásának korlátozását. Egy ilyen korlátozás első pillantásra kiváló megoldás a levélbombázás elleni védelemre, de valójában egy ilyen, akár nagy határérték felállítása tele van azzal a ténnyel, hogy bizonyos feltételek mellett egy fontos levél nem jut el hozzád. Éppen ezért erősen nem ajánlott korlátozni a bejövő leveleket. Ha azonban mégis úgy dönt, hogy kockáztat, különös figyelemmel kell megközelítenie a bejövő üzenetek limitjének beállítását. Korlátozhatja például a megbízható partnerektől érkező e-mailek számát, hogy ha a levelezőszerverüket feltörik, az ne indítson spamtámadást az Ön vállalkozása ellen.
A bejövő üzenetek beáramlása elleni védelem érdekében a levélrobbanás során a rendszergazdának valami okosabbat kell tennie, mint egyszerűen korlátozni a bejövő leveleket. Ez a megoldás lehet a szürke listák használata. Működésük elve az, hogy a megbízhatatlan feladótól érkező üzenet kézbesítésének első kísérletekor hirtelen megszakad a kapcsolat a szerverrel, emiatt a levél kézbesítése meghiúsul. Ha azonban egy bizonyos időszakon belül egy nem megbízható kiszolgáló újra megpróbálja elküldeni ugyanazt a levelet, a szerver nem zárja le a kapcsolatot, és a kézbesítés sikeres lesz.
Mindezen műveletek lényege, hogy a tömeges e-mailek automatikus küldésére szolgáló programok általában nem ellenőrzik az elküldött üzenet kézbesítésének sikerességét, és nem kísérlik meg másodszor elküldeni, miközben az ember biztosan megbizonyosodik arról, hogy a levelét a címzettnek küldték-e el. a címet vagy sem.
A szürkelistázást a cbpolicyd webes felületén is engedélyezheti. Ahhoz, hogy minden működjön, létre kell hozni egy szabályzatot, amely tartalmazza a szerverünkön lévő felhasználóknak címzett összes bejövő levelet, majd ennek alapján létre kell hozni egy Greylisting szabályt, ahol beállíthatja, hogy a cbpolicyd mennyi idő alatt várjon. egy ismeretlen személy feladótól érkező ismételt válaszhoz. Általában 4-5 perc. Ugyanakkor a szürke listák úgy konfigurálhatók, hogy a különböző feladóktól érkező levelek kézbesítésére minden sikeres és sikertelen kísérletet figyelembe vegyenek, és számuk alapján döntsenek arról, hogy a feladó automatikusan felkerül a fehér vagy fekete listára.
Felhívjuk a figyelmet, hogy a szürke listák használata a legnagyobb felelősséggel történjen. Az lenne a legjobb, ha ennek a technológiának a használata kéz a kézben járna a fehér és fekete listák folyamatos karbantartásával, hogy elkerülhető legyen a vállalkozás számára valóban fontos e-mailek elvesztése.
Ezenkívül az SPF, DMARC és DKIM ellenőrzések hozzáadásával megvédheti magát az e-mailek bombázásától. A postai bombázás során érkező levelek gyakran nem mennek át az ilyen ellenőrzéseken. Ennek mikéntjét megvitatták .
Így meglehetősen egyszerű megvédeni magát egy olyan fenyegetéstől, mint az e-mail bombázás, és ezt még a Zimbra infrastruktúra kiépítésének szakaszában is megteheti vállalkozása számára. Fontos azonban folyamatosan gondoskodni arról, hogy az ilyen védelem használatának kockázata soha ne haladja meg a kapott előnyöket.
Forrás: will.com