Postipommitamine on üks vanimaid küberrünnakute liike. Oma olemuselt meenutab see tavalist DoS rünnakut, kuid erinevatelt IP-aadressidelt päringute laine asemel saadetakse serverisse laine kirju, mis saabuvad tohututes kogustes ühele meiliaadressidest, mille tõttu koormus sellel suureneb oluliselt. Selline rünnak võib põhjustada postkasti kasutamise võimatuse ja mõnikord isegi kogu serveri rikke. Seda tüüpi küberrünnakute pikk ajalugu on süsteemiadministraatoritele toonud kaasa mitmeid positiivseid ja negatiivseid tagajärgi. Positiivsete tegurite hulka kuuluvad head teadmised postipommitamise kohta ja lihtsate viiside olemasolu sellise rünnaku eest kaitsmiseks. Negatiivsed tegurid hõlmavad suurt hulka avalikult kättesaadavaid tarkvaralahendusi seda tüüpi rünnakute läbiviimiseks ja ründaja võimalust end avastamise eest usaldusväärselt kaitsta.
Selle küberrünnaku oluline omadus on see, et seda on peaaegu võimatu kasumi saamiseks kasutada. Noh, ründaja saatis ühte postkasti laine e-kirju, noh, ta ei lasknud inimesel meili tavapäraselt kasutada, noh, ründaja tungis kellegi ettevõtte meilidesse ja hakkas massiliselt saatma tuhandeid kirju kogu GAL-is, kuna mille server kas jooksis kokku või hakkas aeglustuma nii, et selle kasutamine muutus võimatuks ja mis siis? Sellist küberkuritegevust on pea võimatu pärisrahaks konverteerida, mistõttu on postipommitamine praegu üsna haruldane juhtum ning süsteemiadministraatorid ei pruugi taristu projekteerimisel lihtsalt mäletada vajadust sellise küberrünnaku eest kaitsta.
Vaatamata sellele, et postipommitamine ise on aga kaubanduslikust seisukohast üsna mõttetu tegevus, on see sageli teiste, keerulisemate ja mitmeastmelisemate küberrünnakute lahutamatu osa. Näiteks posti häkkimisel ja mõne avaliku teenuse konto kaaperdamiseks kasutades ründajad sageli "pommitavad" ohvri postkasti mõttetute kirjadega, nii et kinnituskiri kaob nende voogu ja jääb märkamatuks. Postipommitamist saab kasutada ka ettevõtte majandusliku surve avaldamise vahendina. Näiteks võib klientidelt avaldusi vastu võtva ettevõtte avaliku postkasti aktiivne pommitamine tõsiselt takistada nendega töötamist ning selle tulemusena võib kaasa tuua seadmete seisakuid, täitmata tellimusi, aga ka maine kaotust ja saamata jäänud kasumit.
Seetõttu ei tohiks süsteemiadministraator unustada postipommitamise võimalust ja võtta alati kasutusele vajalikud meetmed selle ohu eest kaitsmiseks. Arvestades, et seda saab teha isegi meilitaristu ülesehitamise etapis ja ka seda, et see võtab süsteemiadministraatorilt väga vähe aega ja vaeva, pole lihtsalt objektiivseid põhjuseid, miks mitte pakkuda oma infrastruktuurile kaitset posti pommitamise eest. Vaatame, kuidas Zimbra Collaboration Suite'i avatud lähtekoodiga väljaandes kaitse selle küberrünnaku vastu on rakendatud.
Zimbra põhineb Postfixil, mis on hetkel üks kõige usaldusväärsemaid ja funktsionaalsemaid avatud lähtekoodiga meiliedastusagente. Ja selle avatuse üks peamisi eeliseid on see, et see toetab laia valikut kolmandate osapoolte lahendusi funktsionaalsuse laiendamiseks. Eelkõige toetab Postfix täielikult cbpolicydi, täiustatud meiliserveri küberturvalisuse utiliiti. Lisaks rämpsposti kaitsele ja valgesse nimekirja lisamisele, mustale ja hallile nimekirjale lisamisele võimaldab cbpolicyd Zimbra administraatoril seadistada SPF-allkirja kontrollimist ning seada piirangud meilide või andmete vastuvõtmisele ja saatmisele. Need võivad mõlemad pakkuda usaldusväärset kaitset rämpsposti ja andmepüügi e-kirjade eest ning kaitsta serverit e-kirjade pommitamise eest.
Esimene asi, mida süsteemiadministraatorilt nõutakse, on mooduli cbpolicyd aktiveerimine, mis on eelinstallitud Zimbra Collaboration Suite OSE-sse infrastruktuuri MTA serveris. Seda tehakse käsuga zmprov ms `zmhostname` + zimbraServiceEnabled cbpolicyd. Pärast seda peate veebiliidese aktiveerima, et saaksite cbpolicyd mugavalt hallata. Selleks peate lubama ühendused veebipordi numbriga 7780, looma sümboolse lingi käsuga ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webuija seejärel redigeerige seadete faili käsuga nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, kuhu peate kirjutama järgmised read:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="juur";
$DB_TABLE_PREFIX="";
Pärast seda jääb üle vaid taaskäivitada Zimbra ja Zimbra Apache teenused, kasutades käske zmcontrol restart ja zmapachectl restart. Pärast seda on teil juurdepääs veebiliidesele aadressil :7780/webui/index.php. Peamine nüanss on see, et selle veebiliidese sissepääs ei ole veel kuidagi kaitstud ja selleks, et kõrvalised isikud sinna ei satuks, saab pärast iga veebiliidese sisenemist pordi 7780 ühendused lihtsalt sulgeda.
Sisevõrgust tulevate kirjade tulva eest kaitsmiseks saab meilide saatmiseks kasutada kvoote, mida saab määrata tänu cbpolicydile. Sellised kvoodid võimaldavad seada piirangu ühest postkastist ühe ajaühiku jooksul saadetavate kirjade maksimaalsele arvule. Näiteks kui teie ettevõtte juhid saadavad keskmiselt 60–80 e-kirja tunnis, saate väikese vaba ruumiga määrata 100 meili tunnis. Selle kvoodi ammendamiseks peavad juhid saatma ühe kirja iga 36 sekundi järel. Ühest küljest piisab sellest täielikuks toimimiseks ja teisest küljest ei korralda sellise kvoodiga ründajad, kes on saanud juurdepääsu teie juhi meilidele, postipommi ega ulatuslikku rämpspostirünnakut ettevõttele. .
Sellise kvoodi määramiseks tuleb veebiliideses luua uus meili saatmise piirangu poliitika ja määrata, et see kehtib nii domeeni sees saadetavate kirjade kui ka välistele aadressidele saadetud kirjade kohta. Seda tehakse järgmiselt.
Pärast seda on võimalik täpsemalt täpsustada kirjade saatmisega seotud piiranguid, eelkõige määrata ajavahemik, mille möödudes piiranguid uuendatakse, samuti sõnumi, mille oma limiiti ületanud kasutaja saab. Pärast seda saate määrata kirjade saatmise piirangu. Seda saab määrata nii väljaminevate sõnumite arvuna kui ka edastatud teabe baitide arvuna. Samal ajal toimige kirjadega, mis on saadetud üle määratud limiidi, teisiti. Näiteks saate need lihtsalt kohe kustutada või salvestada nii, et need läheksid kohe pärast sõnumite saatmise limiidi värskendamist. Teist võimalust saab kasutada töötajatele e-kirjade saatmise piirangu optimaalse väärtuse määramisel.
Lisaks e-kirjade saatmise piirangutele võimaldab cbpolicyd määrata piirangu ka meilide vastuvõtmisele. Selline limiit on esmapilgul suurepärane lahendus postipommitamise eest kaitsmiseks, kuid tegelikult on sellise limiidi seadmine, isegi kui see on suur, täis tõsiasja, et teatud tingimustel ei pruugi oluline kiri teieni jõuda. . Seetõttu ei soovita sissetulevale kirjale piiranguid lubada. Kui aga otsustad siiski riskida, tuleb erilise tähelepanuga läheneda sissetulevate sõnumite limiidi seadmisele. Näiteks saate piirata usaldusväärsetelt osapooltelt saabuvate meilide arvu, et kui nende meiliserver on ohus, ei saadaks see teie ettevõtet rämpspostiks.
Et kaitsta sissetulevate kirjade tulva eest e-posti pommitamise eest, peaks süsteemiadministraator tegema midagi nutikamat kui lihtsalt sissetulevate kirjade piiramine. Selliseks lahenduseks võiks olla hallide nimekirjade kasutamine. Nende tööpõhimõte seisneb selles, et esimesel katsel ebausaldusväärselt saatjalt sõnum kohale toimetada katkeb järsult ühendus serveriga, mille tõttu sõnumi edastamine ebaõnnestub. Kui aga ebausaldusväärne server proovib teatud aja jooksul sama meili uuesti saata, ei katkesta server ühendust ja selle kohaletoimetamine õnnestub.
Kõigi nende toimingute mõte seisneb selles, et automaatsed hulgimeiliprogrammid tavaliselt ei kontrolli saadetud kirja õnnestumist ega ürita seda teist korda saata, samas kui inimene veendub kindlasti, kas tema kiri saadeti sellele aadressile või mitte. .
Halliloendi saate lubada ka cbpolicyd veebiliideses. Et kõik toimiks, tuleb luua poliitika, mis hõlmaks kõiki meie serveris olevatele kasutajatele adresseeritud sissetulevaid kirju ning seejärel selle reegli alusel koostada Greylistingi reegel, kus saab seadistada intervalli, mille jooksul cbpolicyd ootab. võõralt saatjalt teise vastuse saamiseks. Tavaliselt on see 4-5 minutit. Samas saab halle nimekirju seadistada nii, et kõik erinevatelt saatjatelt tulnud kirjade edukad ja ebaõnnestunud kirjade kohaletoimetamise katsed lähevad arvesse ning nende arvust lähtuvalt otsustatakse saatja automaatselt valgesse või musta nimekirja lisada.
Juhime teie tähelepanu asjaolule, et hallide nimekirjade kasutamisele tuleks suhtuda ülima vastutustundega. Kõige parem oleks, kui selle tehnoloogia kasutamine käiks käsikäes pideva valgete ja mustade nimekirjade hoidmisega, et välistada ettevõtte jaoks tõeliselt oluliste kirjade kadumine.
Lisaks aitab SPF-i, DMARC-i ja DKIM-i kontrollide lisamine kaitsta e-posti pommitamise eest. Sageli ei läbi posti pommitamise käigus saabuvad kirjad sellist kontrolli. Kuidas seda teha, selgitati .
Seega on üsna lihtne end kaitsta sellise ohu eest nagu postipommitamine ja saate seda teha isegi oma ettevõtte Zimbra infrastruktuuri ehitamise etapis. Siiski on oluline pidevalt tagada, et sellise kaitse kasutamisega kaasnevad riskid ei kaalu kunagi üles saadavat kasu.
Allikas: www.habr.com