E-posti pommirünnak on üks vanimaid küberrünnakute vorme. Selle olemuselt sarnaneb see tavalise DoS-rünnakuga, kuid selle asemel, et saata serverile laineid päringutest erinevatelt IP-aadressidelt, saadetakse ühele e-posti aadressile tohutul hulgal e-kirju, mistõttu selle koormus tõuseb märkimisväärselt. Selline rünnak võib viia olukorrani, kus e-posti kasti ei saa kasutada, ja mõnikord võib see isegi põhjustada kogu serveri kokkukukumise. Selliste küberrünnakute pikaajaline ajalugu on toonud kaasa mitmeid positiivseid ja negatiivseid tagajärgi süsteemiadministraatoritele. Positiivseteks teguriteks on e-posti pommirünnakute hea tundmine ja lihtsad viisid sellise rünnaku vastu kaitsmiseks. Negatiivseteks teguriteks on suur arv avalikult kergesti ligipääsetavaid tarkvaralahendusi selliste rünnakute teostamiseks ja võimalus ründajal end avastamise eest tõhusalt kaitsta.
Oluline joon selle küberrünnaku puhul on see, et seda on praktiliselt võimatu kasutada kasumi saamiseks. Olgu see, et küberkurjategija saatis ühele e-posti aadressile tohutu hulga e-kirju, olgu see, et ta takistas inimest normaalselt e-kirju kasutamast, olgu see, et ta murdis kellegi ettevõtte e-posti ning hakkas massiliselt saatma GALis tuhandeid e-kirju, mille tõttu server kas kukkus kokku või hakkas nii aeglaselt töötama, et selle kasutamine muutus võimatuks, ja mis siis edasi? Sellist küberkuritegu raha vastu konverteerida on peaaegu võimatu, seetõttu on e-posti pommirünnakud tänapäeval üsna haruldased ja süsteemiadministraatorid võivad infrastruktuuri projekteerimisel lihtsalt mitte meeles pidada vajadust kaitsta end selliste küberrünnakute eest.
Sellegipoolest, kuigi meil-bombing on iseenesest kaubanduslikult mõttetu tegevus, on see sageli osa teistest, keerukamatest ja mitmeastmelistest küberrünnakutest. Näiteks, kui postkasti häkitakse ja seda kasutatakse konto röövimiseks mõnes avalikus teenuses, pommitavad küberkurjategijad sageli ohvri postkasti mõttetute kirjadega, et kinnituskiri kaoks nende voos ja jääks märkamatuks. Lisaks võib meil-bombingut kasutada ka ettevõtte majandusliku surve vahendina. Näiteks, kui avalikku postkasti pommitatakse aktiivselt, kuhu klientidelt taotlused saadetakse, võib see oluliselt raskendada nende töötlust ja seetõttu põhjustada seadmete seiskumist, tellimuste täitmata jäämist, samuti mainekaotust ja saamata jäänud kasumit.
Just sellepärast ei tohiks süsteemiadministraator unustada meilibombingu tõenäosust ning alati võtta tarvitusele vajalikud meetmed selle ohu eest kaitsmiseks. Arvestades, et seda saab teha juba postisüsteemi ülesehitamise etapis, samuti et see ei nõua süsteemiadministraatorilt eriti palju aega ja vaeva, ei jää objektiivseid põhjuseid, miks oma infrastruktuuri meil-bombingu eest kaitsta, lihtsalt enam alles. Vaatame, kuidas on kaitse selle küberründe vastu rakendatud Zimbra Collaboration Suite Open-Source Editionis.
Zimbra aluseks on Postfix — üks usaldusväärsemaid ja funktsionaalsemaid avatud lähtekoodiga Mail Transfer Agent'e. Üks peamisi eeliseid selle avatud olemuse juures on see, et see toetab mitmesuguseid kolmandate osapoolte lahendusi funktsionaalsuse laiendamiseks. Eelkõige toetab Postfix täielikult cbpolicyd - täiustatud tööriista, mis tagab postiserveri küberturvalisuse. Lisaks spämmi kaitsele ja lubade, mustade ja hallide loendite loomisele, võimaldab cbpolicyd Zimbra administraatoril seadistada SPF-allkirjade kontrolli, samuti kehtestada piiranguid e-kirjade vastuvõtmiseks ja saatmiseks. Need võivad pakkuda usaldusväärset kaitset spämmi ja püügikirjade vastu ning kaitsta serverit meil-bombingu eest.
Esimene, mida süsteemiadministraatorilt nõutakse, on cbpolicyd mooduli aktiveerimine, mis on eelinstalleeritud Zimbra Collaboration Suite OSE MTA-serveris. See tehakse käsuga zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Järgmisena tuleb aktiveerida veebiliides, et saaksite mugavalt hallata cbpolicyd. Selleks on vajalik lubada ühendused veebipordil number 7780, luua sümboolne link käsuga ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, ja seejärel redigeerida seadistuste faili käsuga nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, kus tuleb märkida järgmised read:
$DB_DSN='sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb';
$DB_USER='root';
$DB_TABLE_PREFIX='';
Pärast seda jääb vaid taaskäivitada Zimbra ja Zimbra Apache teenused käsudega zmcontrol restart ja zmapachectl restart. Pärast seda on teil juurdepääs veebiliidesele aadressil :7780/webui/index.php. Peamine nüanss on see, et sisenemine sellesse veebiliidesesse ei ole hetkel kuidagi kaitstud ja et välistada sinna sisenemine kolmandate isikute poolt, võiks pärast igat sisenemist veebiliidesesse lihtsalt sulgeda ühendused pordil 7780.
Kaitseks sisemisest võrgust pärit e-kirjade voo eest on võimalik kasutada e-kirjade saatmise kvote, mida saab seadistada cbpolicyd abil. Need kvoted võimaldavad seada piirangu maksimaalsele kirjade arvule, mida võib ühest postkastist ühes ajavahemikus saata. Näiteks, kui teie ettevõtte juhid saadavad keskmiselt 60–80 e-kirja tunnis, siis võib, arvestades väikest varu, seada neile kvoodi 100 e-kirja tunnis. Selle kvoodi ammendamiseks peavad juhid saatma ühe kirje iga 36 sekundi tagant. Ühest küljest on see piisav, et tõhusalt töötada, kuid teiselt poolt, sellise kvoodi puhul ei saa pahatahtlikud isikud, kellel on juurdepääs mõne teie juhi meilile, korraldada meilibombingut või massilist spämmi rünnakut ettevõttes.
Selle kvoodi seadistamiseks tuleb veebiliideses luua uus e-kirjade saatmise piiramise poliitika ja märkida, et see kehtiks nii siseselt domeeni sees saadetud kirjadele kui ka välistele aadressidele saadetud kirjadele. See toimub järgmiselt:
Pärast seda on võimalik täpsemalt määrata piirangud, mis on seotud e-kirjade saatmisega, sealhulgas määrata ajavahemik, mille möödudes piirangud uuendatakse, samuti sõnum, mille saab kasutaja, kes oma piiri ületab. Seejärel on võimalik kehtestada ka e-kirjade saatmise piirang. Seda saab määrata kas väljuvate e-kirjade arvu või edastatava teabe mahu järgi. Samuti on võimalik nende e-kirjadega, mis saadetakse üle määratud piiri, käituda erinevalt. Näiteks võib neid kohe kustutada või säilitada, et need saadetaks kohe pärast saatmise piiri uuendamist. Teist varianti saab kasutada, kui töötajad püüavad leida optimaalse väärtuse e-kirjade saatmise piiriks.
Lisaks e-kirjade saatmise piirangutele võimaldab cbpolicyd seadistada piiranguid e-kirjade vastuvõtmiseks. See piirang näib esialgu olevat suurepärane lahendus kaitseks meili-bombardimise eest, kuid tegelikult võib selle määramine, isegi kui see on suur, tähendada, et teatud tingimustel võib oluline kiri teieni mitte jõuda. Just seetõttu ei ole soovitatav kehtestada mingeid piiranguid saabuvatele kirjadele. Siiski, kui otsustate riskida, tuleb saabuvate sõnumite piirangu seadistamisega läheneda eriti ettevaatlikult. Näiteks võib piirata usaldusväärsetelt partneritelt saabuvate e-kirjade arvu, et juhul, kui nende postiserver on kompromiteeritud, ei toimuks teie ettevõtte vastu ründe toimimist.
Selleks, et kaitsta end saabuvate sõnumite laviini eest meili-bombardimise ajal, peaks süsteemiadministraator rakendama midagi nutikamat kui lihtsalt sissetuleva posti piiramine. Üks võimalik lahendus on hallide nimekirjade kasutamine. Nende toimimise põhimõte seisneb selles, et ebausaldusväärse saatja esimese katse korral sõnumi edastamiseks katkestatakse ühendus serveriga järsult, mille tõttu e-kirja edastamine lõpeb ebaõnnestumisena. Kuid kui teatud aja jooksul püüab ebausaldusväärne server sama kirja uuesti saata, ei katkesta server ühendust ja selle edastamine toimub edukalt.
Kõigi nende tegevuste mõte on see, et automaatsete massiliste e-posti saatmise programmide puhul ei kontrollita tavaliselt saadetud sõnumi edastamise edukust ja ei üritata seda uuesti saata, samas kui inimene kindlasti kontrollib, kas tema kiri on saadetud õigele aadressile või mitte.
Hallide nimekirjade lubamine toimub ka veebiliidese cbpolicyd kaudu. Selle toimimiseks on vajalik luua poliitika, millega kaasnevad kõik sisenevad kirjad, mis on adresseeritud meie serveri kasutajatele, ja seejärel luua selle poliitika alusel Greylisting reegel, kus saab seadistada ajavahemiku, mille jooksul cbpolicyd ootab vastust tundmatult saatjalt. See on tavaliselt 4-5 minutit. Sellega saab halli nimekirja seadistada nii, et kõik edastamisürituste edukad ja ebaõnnestunud katsed erinevatelt saatjatelt arvestatakse ning nende arvu põhjal otsustatakse automaatselt lisada saatja valge- või musta nimekirja.
Tuletame meelde, et hallide nimekirjade kasutamisele tuleks läheneda maksimaalse vastutustunde ja tähelepanuga. Parim oleks, kui selle tehnoloogia kasutamine käiks käsikäes pideva valge ja musta nimekirjade pidamisega, et vältida tõeliselt oluliste kirjade kadumist ettevõtte jaoks.
Lisaks aitab kaitsta meilibombimise eest SPF, DMARC ja DKIM kontrollide lisamine. Tihti ei saa meilibombimise käigus saadetud kirjad neid kontrolle läbida. Kuidas seda teha, on juba räägitud. .
Seega on kaitsta end meilibombimise ohu eest üsna lihtne, ning seda saab teha juba Zimbra infrastruktuuri loomise etapil teie ettevõttes. Siiski on oluline pidevalt jälgida, et sellise kaitse kasutamine ei ületaks kunagi saadud eeliseid.
Allikas: habr.com
