Pašto bombardavimas yra viena iš seniausių kibernetinių atakų rūšių. Savo esme jis primena įprastą DoS ataką, tik vietoj užklausų iš skirtingų IP adresų bangos į serverį siunčiama laiškų banga, kurios didžiuliais kiekiais atkeliauja į vieną iš el. pašto adresų, dėl ko apkraunama. ant jo žymiai padidėja. Tokia ataka gali lemti negalėjimą naudotis pašto dėžute, o kartais net ir viso serverio gedimą. Ilga šio tipo kibernetinių atakų istorija sistemos administratoriams sukėlė daugybę teigiamų ir neigiamų pasekmių. Teigiami veiksniai apima geras žinias apie pašto bombardavimą ir paprastų būdų apsisaugoti nuo tokio išpuolio prieinamumą. Neigiami veiksniai apima daugybę viešai prieinamų programinės įrangos sprendimų, skirtų tokio tipo atakoms vykdyti, ir galimybę užpuolikui patikimai apsisaugoti nuo aptikimo.
Svarbi šios kibernetinės atakos ypatybė yra ta, kad jos beveik neįmanoma panaudoti siekiant pelno. Na, užpuolikas išsiuntė el. laiškų bangą į vieną iš pašto dėžučių, gerai, jis neleido asmeniui normaliai naudotis el. paštu, na, užpuolikas įsilaužė į kažkieno įmonės el. paštą ir pradėjo masiškai siųsti tūkstančius laiškų visoje GAL, o tai yra kodėl serveris sudužo arba pradėjo lėtėti, todėl tapo neįmanoma juo naudotis, o kas toliau? Tokį elektroninį nusikaltimą paversti tikrais pinigais beveik neįmanoma, todėl tiesiog pašto bombardavimas šiuo metu yra gana retas reiškinys ir sistemų administratoriai kurdami infrastruktūrą gali tiesiog neprisiminti, kad reikia apsisaugoti nuo tokios kibernetinės atakos.
Tačiau, nors pats elektroninio pašto bombardavimas yra gana beprasmis pratimas komerciniu požiūriu, jis dažnai yra kitų, sudėtingesnių ir kelių etapų kibernetinių atakų dalis. Pavyzdžiui, įsilauždami į paštą ir naudodami jį kai kurių viešųjų paslaugų paskyrai užgrobti, užpuolikai dažnai „subombarduoja“ aukos pašto dėžutę beprasmėmis raidėmis, kad patvirtinimo laiškas pasimetų jų sraute ir liktų nepastebėtas. Pašto bombardavimas taip pat gali būti naudojamas kaip ekonominio spaudimo įmonei priemonė. Taigi, aktyvus įmonės viešosios pašto dėžutės bombardavimas, sulaukiantis klientų užklausų, gali rimtai apsunkinti darbą su jais ir dėl to gali atsirasti įrangos prastovos, neįvykdyti užsakymai, taip pat prarasta reputacija ir negautas pelnas.
Būtent todėl sistemos administratorius turėtų nepamiršti apie elektroninio pašto bombardavimo tikimybę ir visada imtis reikiamų priemonių apsisaugoti nuo šios grėsmės. Atsižvelgiant į tai, kad tai galima padaryti kuriant pašto infrastruktūrą, be to, tai užima labai mažai laiko ir darbo iš sistemos administratoriaus, tiesiog nėra objektyvių priežasčių, kodėl jūsų infrastruktūra neapsaugota nuo pašto bombardavimo. Pažiūrėkime, kaip apsauga nuo šios kibernetinės atakos įgyvendinama „Zimbra Collaboration Suite Open-Source Edition“.
„Zimbra“ yra pagrįsta „Postfix“, vienu patikimiausių ir funkcionaliausių atvirojo kodo pašto siuntimo agentų šiandien. Vienas iš pagrindinių jo atvirumo privalumų yra tai, kad jis palaiko daugybę trečiųjų šalių sprendimų, skirtų išplėsti funkcionalumą. Visų pirma, Postfix visiškai palaiko cbpolicyd – pažangią priemonę, užtikrinančią pašto serverio kibernetinį saugumą. Be apsaugos nuo brukalų ir baltųjų, juodųjų ir pilkųjų sąrašų kūrimo, cbpolicyd leidžia Zimbra administratoriui konfigūruoti SPF parašo tikrinimą, taip pat nustatyti apribojimus gauti ir siųsti el. laiškus ar duomenis. Jie gali užtikrinti patikimą apsaugą nuo šlamšto ir sukčiavimo el. laiškų ir apsaugoti serverį nuo elektroninio pašto bombardavimo.
Pirmas dalykas, kurio reikalaujama iš sistemos administratoriaus, yra suaktyvinti cbpolicyd modulį, kuris yra iš anksto įdiegtas Zimbra Collaboration Suite OSE infrastruktūros MTA serveryje. Tai atliekama naudojant komandą zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Po to turėsite suaktyvinti žiniatinklio sąsają, kad galėtumėte patogiai valdyti cbpolicyd. Norėdami tai padaryti, turite leisti prisijungti prie interneto prievado numeriu 7780, sukurti simbolinę nuorodą naudodami komandą ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, tada redaguokite nustatymų failą naudodami nano komandą /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, kur reikia parašyti šias eilutes:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="šaknis";
$DB_TABLE_PREFIX="";
Po to belieka iš naujo paleisti Zimbra ir Zimbra Apache paslaugas naudojant zmcontrol restart ir zmapachectl restart komandas. Po to turėsite prieigą prie žiniatinklio sąsajos adresu :7780/webui/index.php. Pagrindinis niuansas yra tas, kad įėjimas į šią žiniatinklio sąsają dar nėra niekaip apsaugotas ir kad į ją nepatektų pašaliniai asmenys, po kiekvieno įėjimo į žiniatinklio sąsają galite tiesiog uždaryti ryšius prie 7780 prievado.
Galite apsisaugoti nuo laiškų antplūdžio iš vidinio tinklo naudodami el. laiškų siuntimo kvotas, kurias galima nustatyti cbpolicyd dėka. Tokios kvotos leidžia nustatyti maksimalaus laiškų skaičiaus, kurį galima išsiųsti iš vienos pašto dėžutės per vieną laiko vienetą, limitą. Pavyzdžiui, jei jūsų verslo vadovai per valandą išsiunčia vidutiniškai 60–80 laiškų, tuomet galite nustatyti 100 laiškų per valandą kvotą, atsižvelgdami į nedidelę maržą. Kad pasiektų šią kvotą, vadovai turės išsiųsti vieną el. laišką kas 36 sekundes. Viena vertus, to pakanka, kad veiktų visapusiškai, kita vertus, turėdami tokią kvotą, užpuolikai, kurie gavo prieigą prie vieno iš jūsų vadovų pašto, nepradės pašto bombardavimo ar didžiulės šiukšlių atakos prieš įmonę.
Norint nustatyti tokią kvotą, žiniatinklio sąsajoje reikia sukurti naują el. laiškų siuntimo apribojimo politiką ir nurodyti, kad ji būtų taikoma tiek laiškams, siunčiamiems domeno viduje, tiek laiškams, siunčiamiems išoriniais adresais. Tai atliekama taip:
Po to galite išsamiau nurodyti apribojimus, susijusius su laiškų siuntimu, visų pirma nustatyti laiko intervalą, po kurio apribojimai bus atnaujinti, taip pat pranešimą, kurį gaus vartotojas, viršijęs savo limitą. Po to galite nustatyti laiškų siuntimo apribojimą. Jį galima nustatyti ir kaip siunčiamų laiškų skaičių, ir kaip perduodamos informacijos baitų skaičių. Tuo pačiu metu laiškai, siunčiami viršijant nustatytą limitą, turi būti tvarkomi skirtingai. Taigi, pavyzdžiui, galite tiesiog ištrinti juos iš karto arba galite išsaugoti, kad jie būtų išsiųsti iškart po to, kai atnaujinamas pranešimų siuntimo limitas. Antrasis variantas gali būti naudojamas nustatant optimalią darbuotojų el. laiškų siuntimo limito reikšmę.
Be laiškų siuntimo apribojimų, cbpolicyd leidžia nustatyti laiškų gavimo limitą. Toks apribojimas, iš pirmo žvilgsnio, yra puikus sprendimas apsisaugoti nuo pašto bombardavimo, tačiau iš tikrųjų tokios ribos nustatymas, net ir didelis, yra kupinas tuo, kad tam tikromis sąlygomis svarbus laiškas gali jūsų nepasiekti. Štai kodėl labai nerekomenduojama įjungti jokių gaunamų laiškų apribojimų. Tačiau jei vis tiek nuspręsite rizikuoti, į gaunamų pranešimų limito nustatymą turite atkreipti ypatingą dėmesį. Pavyzdžiui, galite apriboti gaunamų el. laiškų iš patikimų sandorio šalių skaičių, kad jei jų pašto serveris būtų pažeistas, jis nepradėtų jūsų įmonės šlamšto atakos.
Siekdamas apsisaugoti nuo gaunamų laiškų antplūdžio pašto bombardavimo metu, sistemos administratorius turėtų padaryti ką nors protingesnio nei tiesiog apriboti gaunamus laiškus. Šis sprendimas galėtų būti pilkųjų sąrašų naudojimas. Jų veikimo principas – pirmą kartą bandant pristatyti pranešimą iš nepatikimo siuntėjo, ryšys su serveriu staiga nutrūksta, todėl laiško pristatymas nepavyksta. Tačiau jei tam tikru laikotarpiu nepatikimas serveris bando dar kartą išsiųsti tą patį laišką, serveris neužtraukia ryšio ir jo pristatymas yra sėkmingas.
Visų šių veiksmų esmė ta, kad automatinio masinio laiškų siuntimo programos dažniausiai netikrina išsiųstos žinutės pristatymo sėkmės ir nebando jos išsiųsti antrą kartą, tuo tarpu žmogus tikrai įsitikins, ar jo laiškas buvo išsiųstas adresas ar ne.
Taip pat galite įjungti pilkąjį sąrašą cbpolicyd žiniatinklio sąsajoje. Kad viskas veiktų, reikia sukurti politiką, kuri apimtų visus gaunamus laiškus, adresuotus mūsų serverio vartotojams, o tada, remiantis šia politika, sukurti Greylisting taisyklę, kurioje galėsite sukonfigūruoti intervalą, per kurį cbpolicyd lauks už pakartotinį atsakymą iš nežinomo asmens siuntėjo. Paprastai tai yra 4-5 minutės. Tuo pačiu metu pilkuosius sąrašus galima sukonfigūruoti taip, kad būtų atsižvelgta į visus sėkmingus ir nesėkmingus bandymus pristatyti skirtingų siuntėjų laiškus ir pagal jų skaičių būtų priimtas sprendimas automatiškai įtraukti siuntėją į baltąjį arba juodąjį sąrašus.
Atkreipiame jūsų dėmesį į tai, kad pilkųjų sąrašų naudojimas turėtų būti atliekamas su didžiausia atsakomybe. Geriausia būtų, jei šios technologijos naudojimas vyktų kartu su nuolatiniu baltųjų ir juodųjų sąrašų tvarkymu, kad būtų išvengta galimybės prarasti įmonei tikrai svarbius el.
Be to, SPF, DMARC ir DKIM patikrų pridėjimas gali padėti apsisaugoti nuo elektroninio pašto bombardavimo. Dažnai laiškai, gauti per pašto bombardavimo procesą, tokių patikrinimų neatlaiko. Buvo aptarta, kaip tai padaryti .
Taigi apsisaugoti nuo tokios grėsmės kaip elektroninio pašto bombardavimas yra gana paprasta, ir tai galite padaryti net kurdami savo įmonės Zimbra infrastruktūrą. Tačiau svarbu nuolat užtikrinti, kad tokios apsaugos naudojimo rizika niekada neviršytų gaunamos naudos.
Šaltinis: www.habr.com