E-kirjade pommitamine on üks vanimaid küberrünnakute vorme. Selle olemuselt sarnaneb see tavalise DoS-rünnakuga, kuid erinevalt mitmest IP-aadressilt tulevatest päringute voogudest saadetakse serverisse suur hulk e-kirju, mis ühte postkasti tohututes kogustes siseneb, põhjustades selle koormuse oluliselt suurenemist. Selline rünnak võib muuta postkasti kasutamise võimatuks ja mõnikord isegi serveri täielikult krahhida. Sellise küberrünnaku pikaajaline ajalugu on toonud kaasa mitmeid positiivseid ja negatiivseid tagajärgi süsteemiadministraatoritele. Positiivseks on võimalik pidada e-kirjade pommitamise head tundmist ja lihtsate kaitsemeetodite olemasolu. Negatiivseks on aga suur hulk avalikult kättesaadavaid tarkvaralahendusi selliste rünnakute teostamiseks ja võimalus, et kurjategija suudab end peita.
Oluline omadus selle küberrünnaku puhul on see, et selle kaudu on praktiliselt võimatu kasumit teenida. Üks isik suunas pahatahtlikult rünnaku ühe e-posti kasti, mis tulemuseks oli, et inimene ei saanud oma e-posti normaalselt kasutada. Teine kurjategija häkkis kellegi ametlikku e-posti ja hakkas massiliselt saatma tuhandeid e-kirju, mille tõttu kas server kukkus kokku või hakkas nii aeglaselt töötama, et selle kasutamine muutus võimatuks. Ja mis edasi? Sellist küberkuritegu elavatesse rahadesse konvertida on peaaegu võimatu, seetõttu on meiliahvandamine tänapäeval üsna haruldane nähtus ning süsteemihaldurid ei pruugi infrastruktuuri projekteerimisel isegi meeles pidada vajadust kaitsta end selliste rünnakute eest.
Kuid kuigi meilivaatamine on endasuguste kaubanduslike mõjude poolest üsna mõttetu tegevus, on see sageli osa teistest keerulisematest ja mitmeastmelistest küberrünnakutest. Näiteks kui e-post on häkitud ja seda kasutatakse konto kaaperdamiseks mõnes avalikus teenuses, siis ründajad "pommitavad" ohvri postkasti mõttetute kirjadega, et kinnitusmeil kaoks nende voos ning jääks tähelepanuta. Samuti võib meilivaatamine olla ettevõtte majandusliku surve vorm. Nii võib intensiivne ettevõtte avaliku postkasti pommitamine, kuhu klienditaotlused tulevad, tõsiselt takistada nende töötlemist ja seega võib viia seadmete seiskumiseni, täitmata tellimusteni ja kaotatud maine ning saamata jäävate kasumiteni.
Seetõttu ei tohiks süsteemiadministraator unustada võimalust, et võib toimuda e-kirjade pommitamine, ning alati võtta vajalikud meetmed selle ohu eest kaitsmiseks. Arvestades, et seda saab teha juba posti infrastruktuuri loomise etapis ja et see ei nõua süsteemiadministraatorilt palju aega ega vaeva, ei jää objektiivseid põhjuseid, miks mitte kaitsta oma infrastruktuuri e-kirjade pommitamise eest. Vaatame, kuidas on Zimbra Collaboration Suite Open-Source Editionis ellu viidud kaitse selle küberrünnaku eest.
Zimbra põhineb Postfixil, mis on praegu üks usaldusväärsemaid ja funktsionaalsemaid avatud lähtekoodiga Mail Transfer Agent'e. Selle avatud olemuse peamine eelis on see, et see toetab laia valikut kolmandate osapoolte lahendusi funktsionaalsuse laiendamiseks. Eelkõige toetab Postfix täielikult cbpolicyd't — täiustatud tööriista, mis tagab postiserveri küberjulgeoleku. Lisaks rämpsposti kaitsmisele ja valge, musta ning halli nimekirja loomisele võimaldab cbpolicyd Zimbra administraatoril seadistada SPF-allkirja kontrolli ja kehtestada piirangud e-kirjade vastuvõtmiseks ja saatmiseks. Need võivad pakkuda tõhusat kaitset rämpspostiga ja phishing’u kirjade vastu ning kaitsta serverit ka meil-bombimise eest.
Esimene, mida süsteemiadministraatorilt nõutakse, on cbpolicyd mooduli aktiveerimine, mis on eelnevalt installitud Zimbra Collaboration Suite OSE MTA-serverisse. See toimub käsuga zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Seejärel tuleb aktiveerida veebiliides, et saaks mugavalt cbpolicyd hallata. Selleks on vajalik lubada ühendused veebipordil number 7780, luua sümboolne link käsu abil ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, ja seejärel redigeerida konfiguratsioonifaili käsu abil nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, kuhu tuleb kirja panna järgmised read:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";
Seejärel jääb üle vaid Zimbra ja Zimbra Apache teenuste taaskäivitamine käsudega zmcontrol restart ja zmapachectl restart. Pärast seda avaneb juurdepääs veebiliidesele aadressil :7780/webui/index.php. Peamine nüanss on see, et pääs sellele veebiliidesele ei ole praegu kaitstud ja et vältida kolmandate isikute ligipääsu, võite pärast igat sisenemist veebiliidesesse lihtsalt sulgeda ühendused pordil 7780.
Sisemiste võrgustikku lähtuvate e-kirjade voolu eest kaitsmiseks võimaldavad meilide saatmise kvoodid, mida saab seadistada cbpolicyd abil. Need kvoodid võimaldavad kehtestada piirangu selle kohta, kui palju e-kirju võib ühes ajaühikus ühe postkasti kaudu saata. Näiteks, kui teie ettevõtte juhid saadavad keskmiselt 60-80 e-kirja tunnis, siis võib väikese varuga neile seadistada kvoodi 100 e-kirja tunnis. Selle kvoodi täitmiseks peavad juhid saatma kõigepealt ühe e-kirja iga 36 sekundi järel. Ühest küljest on see piisav, et tööd teha, ja teisest küljest, sellise kvoodi korral ei saa kurjategijad, kes on saanud juurdepääsu teie ühe juhi meilile, korraldada meilibombardeerimist ega massilist spam-rünnakut ettevõtte vastu.
Selleks, et seada selline kvoot, tuleb veebiliideses luua uus kirjade saatmise piirangute poliitika ja määrata, et see kehtiks nii domeenisiseselt saadetud kirjadele kui ka välistele aadressidele saadetavatele kirjadele. Seda tehakse järgmiselt:
Pärast seda saab täpsemalt määrata kirjade saatmisega seotud piirangud, sealhulgas määrata ajavahemiku, pärast mille möödumist piirangud uuendatakse, samuti sõnumi, mida kasutaja saab, kui ta ületab oma limiidi. Pärast seda saab seada ka kirjade saatmise piiri. Piiri saab määrata nii sisenevate kirjade arvu kui ka edastatud andmete hulga põhjal. Samuti on erinevaid võimalusi kirjadega, mis saadetakse üle määratud piiri. Näiteks võib need kohe kustutada või jätta alles, et need saadetakse kohe pärast saatmise limiidi uuendamist. Teise võimaluse võib valida töötajate jaoks optimaalse e-kirjade saatmise piiri määramise ajal.
Lisaks e-kirjade saatmise piirangutele võimaldab cbpolicyd seada ka piirangu e-kirjade vastuvõtmiseks. Esmapilgul tundub selline piirang olevat suurepärane lahendus spämmibombardeeringu vastu, kuid tegelikult, isegi suurte piirangute seadmine võib teatud tingimustes tähendada, et oluline kiri ei jõua teieni. Seetõttu ei soovitata sisenevale postile mingeid piiranguid seadma. Siiski, kui otsustate riskida, tuleb sissetulevate sõnumite piirangute seadmisel olla äärmiselt ettevaatlik. Näiteks võite piirata usaldusväärsete partnerite poolt saadetud e-kirjade arvu, et juhtudel, kui nende postiserver on ohustatud, ei toimuks teie ettevõttele rämpsposti rünnakut.
Kaitsmiseks meilivoolu rünnakute eest peaks süsteemiadministraator rakendama targemat lahendust kui lihtsalt sissetuleva posti piiramise. Üks selline lahendus on hallide nimekirjade kasutamine. Nende tööpõhimõte seisneb selles, et kui tundmatu saatja proovib esmakordselt sõnumit saata, katkestatakse ühendus serveriga äkki, mis takistab kirja toimetamist. Siiski, kui ebausaldusväärne server üritab teatud aja jooksul sama kirja uuesti saata, ei katkestata ühendust ja see toimetatakse edukalt kohale.
Käesolevate toimingute mõte on see, et automaatsete mass-emailide saatmise programmid ei kontrolli tavaliselt, kas saadetud sõnum on õnnestunud, ega püüa seda teist korda saata, samas kui inimene kontrolliks kindlasti, kas tema kiri on õigesse aadressi läinud või mitte.
Halli nimekirju saab luua ka cbpolicyd veebiliideses. Selle toimimiseks on vajalik luua poliitika, mis hõlmab kõiki sisse tulevaid kirju, mis on adresseeritud meie serveri kasutajatele, ning seejärel luua selle poliitika alusel reegel hallitamise jaoks, kus saab seadistada intervalli, mille jooksul cbpolicyd ootab vastust tundmatult saatjalt. Tüüpiliselt on see 4-5 minutit. Samuti saab halli nimekirja seadistada nii, et kõik edastuskatsete edusammud ja ebaedud erinevatelt saatjatelt arvestatakse ning nende arvu põhjal tehakse otsus saatja automaatse lisamise kohta valge või mustasse nimekirja.
Tuletame teile meelde, et hallide nimekirjade kasutamine nõuab maksimaalset vastutustundlikkust. Parim on, kui selle tehnoloogia kasutamine käib käsikäes pideva valge ja musta nimekirjade haldamisega, et välistada tõeliselt oluliste kirjade kaotamine ettevõtte jaoks.
Samuti aitab SPF, DMARC ja DKIM kontrollide lisamine kaitsta meilibombimise eest. Sageli ei läbida meilibombimise käigus saadetud kirjad neid kontrolle. Kuidas seda teha, on käsitletud .
Seega on kaitsmine sellise ohu, nagu meilibombimine, üsna lihtne ning seda saab teha juba Zimbra infrastruktuuri ehitamise etapis teie ettevõtte jaoks. Oluline on siiski pidevalt jälgida, et sellisest kaitseks saadud kasud ei ületaks kunagi sellega kaasnevaid riske.
Allikas: habr.com
