Mail bombing është një nga format më të vjetra të sulmeve kibernetike. Nga natyra, ajo ngjan me një sulm të zakonshëm DoS, vetëm se në vend të një vale kërkesash nga adresa të ndryshme IP, në server dërgohet një fluks e-mailesh, të cilat arrijnë në një adresë të vetme, duke shkaktuar kështu një ngarkesë të madhe. Ky sulm mund të çojë në pamundësinë e përdorimit të kutisë postare dhe ndonjëherë madje mund të çojë në dështimin e të gjithë serverit. Historia shumëvjeçare e këtij lloji sulmi kibernetik ka sjellë një sërë pasojash pozitive dhe negative për administratorët e sistemeve. Faktorët pozitivë përfshijnë studimin e mirë të mail bombing dhe ekzistencën e mënyrave të thjeshta për t'u mbrojtur nga ky sulm. Ndërsa faktorët negativë përfshijnë numrin e madh të zgjidhjeve softuerike publike për të kryer këto lloje sulmesh dhe mundësinë për një sulmues që të mbrohet nga nxjerrja në pah.
Një veçori e rëndësishme e këtij sulmi kibernetik është se është praktikisht e pamundur të përdoret për të nxjerrë fitim. Pra, nëse një sulmues dërgon një fluks e-mailesh në një nga kutitë postare, ai vetëm e pengon përdoruesin të përdorë normalisht e-mailin, ose nëse sulmuesi hackon ndonjë email korporate dhe fillon të dërgojë mijëra mesazhe në të gjithë GAL, duke shkaktuar që serveri të bjerë ose të ngadalësohet aq shumë sa të bëhet i pamundur për t'u përdorur, çfarë ndodh më pas? Të konvertohet një krim kibernetik i tillë në para të gjalla është pothuajse e pamundur, prandaj mail bombing në ditët e sotme është një fenomen mjaft i rrallë dhe administratorët e sistemeve, kur projektuan infrastrukturën, mund ta harrojnë nevojën për mbrojtje nga këtë lloj sulmi kibernetik.
Megjithatë, përkundër faktit se bombardimi i postës është një aktivitet relativisht i paarsyeshëm nga pikëpamja komerciale, ai shpesh është një pjesë përbërëse e sulmeve më të komplikuara dhe shumëfaza të kibernetikës. Për shembull, kur një llogari e postës vidhet dhe përdoret për të marrë në kontroll një llogari në ndonjë shërbim publik, sulmuesit shpesh "bombardojnë" kutinë postare të viktimës me letra pa kuptim, që letra e konfirmimit të humbasë në këtë fluks dhe të mbetet e pa vënë re. Gjithashtu, bombardimi i postës mund të përdoret si një mjet presioni ekonomik ndaj një kompanie. Kështu, bombardimi aktiv i një kuti postare publike të kompanisë, në të cilën mbërrijnë kërkesat nga klientët, mund të vështirësojë seriozisht punën me ta dhe, si pasojë, të çojë në ndalimin e pajisjeve, porosira të pa realizuara, si dhe humbje reputacioni dhe fitim të humbur.
Pikërisht për këtë arsye, një administrator sistemi nuk duhet ta harrojë mundësinë e një bombardimi të postës dhe gjithmonë të ndërmarrë masat e nevojshme për t'u mbrojtur nga kjo kërcënim. Nëse merret parasysh se kjo mund të bëhet që në fazën e ndërtimit të infrastrukturës së postës, si dhe se kjo merr shumë pak kohë dhe mundim nga administratori i sistemit, nuk mbeten arsye objektive për të mos e siguruar infrastrukturën e tij nga bombardimi i postës. Le të shohim se si realizohet mbrojtja nga ky sulm kibernetik në Zimbra Collaboration Suite Open-Source Edition.
Në themel të Zimbra qëndron Postfix - një nga Agjentët më të besueshëm dhe funksionalë të Transferimit të Postës me burim të hapur në këtë moment. Një nga avantazhet kryesore të hapjes së tij është që ai mbështet një gamë të ndryshme zgjidhjesh të jashtme për të zgjeruar funksionalitetin. Në veçanti, Postfix mbështet plotësisht cbpolicyd - një utilitar të avancuar për sigurinë kibernetike të serverit të postës. Përveç mbrojtjes nga spam dhe krijimit të listave të bardha, të zeza dhe gri, cbpolicyd lejon administratorin e Zimbra të konfigurojë verifikimin e nënshkrimit SPF, si dhe të vendosë kufizime për pranimin dhe dërgimin e mesazheve elektronike ose të dhënave. Ato mund të sigurojnë mbrojtje të besueshme nga spam dhe mesazhe të phishing, si dhe të mbrojnë serverin nga bombardimi i postës.
E para, që një administrator sistemi duhet të bëjë është aktivizimi i modulit cbpolicyd, i cili është i paravendosur në Zimbra Collaboration Suite OSE në serverin MTA të infrastrukturës. Kjo bëhet me komandën zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Pas kësaj, do të jetë e nevojshme të aktivizohet ndërfaqja web, për të pasur mundësi të menaxhohet mirë cbpolicyd. Për këtë, duhet të lejohet lidhja në portin web numër 7780, të krijohet një lidhje simbolike me komandën ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, dhe pastaj të redaktohet skedari i konfigurimeve me komandën nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, ku është e nevojshme të shkruhen rreshtat e mëposhtëm:
$DB_DSN='sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb';
$DB_USER='root';
$DB_TABLE_PREFIX='';
Pas kësaj, mbetet vetëm të rinisen shërbimet Zimbra dhe Zimbra Apache me komandat zmcontrol restart dhe zmapachectl restart. Pas kësaj, do të keni qasje në ndërfaqen web në adresën :7780/webui/index.php. Një detaj i rëndësishëm është se hyrja në këtë ndërfaqe web për momentin nuk është e mbrojtur dhe për të shmangur hyrjen e personave të paautorizuar, mund të mbyllet lidhja në portin 7780 pas çdo sesioni në ndërfaqen web.
Të mbrohemi nga fluksi i email-eve që vijnë nga rrjeti i brendshëm ndihmojnë kuotat për dërgimin e email-eve, të cilat mund të vendosen falë cbpolicyd. Të tilla kuota lejojnë caktimin e një kufiri për numrin maksimal të email-eve që mund të dërgohen nga një kuti postare në një njësi kohe. Për shembull, nëse menaxherët e kompanisë tuaj dërgojnë mesatarisht 60-80 email-e në orë, mund të caktoni një kuotë prej 100 email-eve në orë, duke marrë parasysh një rezervë të vogël. Për të shpenzuar një kuotë të tillë, menaxherët do të duhej të dërgonin një email çdo 36 sekonda. Nga njëra anë, kjo është e mjaftueshme për të punuar plotësisht, ndërsa nga ana tjetër, me një kuotë të tillë sulmuesit, nëse arrijnë në postën e një prej menaxherëve tuaj, nuk do të realizojnë mail-bombing ose një sulm masiv me spam në kompani.
Për të vendosur një kuotë të tillë, është e nevojshme në ndërfaqen web të krijoni një politikë të re kufizuese për dërgimin e email-eve dhe të specifikoni që ajo të veprojë si për email-et e dërguara brenda domenit ashtu edhe për email-et që dërgohen në adresa të jashtme. Kjo bëhet në këtë mënyrë:
Pas kësaj, do të jetë e mundur të specifikoni në mënyrë më të detajuar kufizimet lidhur me dërgimin e email-eve, konkretisht të vendosni një interval kohor, pas të cilit kufizimet do të përditësohen, si dhe mesazhin që do të marrë përdoruesi, në rast se kalon limitin e tij. Më pas, mund të vendosni dhe kufizimin për dërgimin e email-eve. Ky kufizim mund të vendoset si në formën e numrit të email-eve të dërguara, ashtu edhe në formën e sasisë së byte-ve të informacionit të dërguar. Në këtë rast, me email-et që dërgohen përtej limitit të caktuar, mund të trajtohet ndryshe. Për shembull, mund t'i fshini menjëherë, ose mund t'i ruani që të dërgohen menjëherë pas përditësimit të limitit për dërgimin e mesazheve. Opsioni i dytë mund të përdoret gjatë identifikimit të vlerës optimale të kufirit për dërgimin e email-eve nga punonjësit.
Përveç kufizimeve për dërgimin e email-eve, cbpolicyd lejon të konfigurohet një kufizim për pranimin e email-eve. Ky kufizim, në pamje të parë, duket si një zgjidhje e shkëlqyer për të mbrojtur nga bombardimi me email-e, megjithatë, në fakt, vendosja e një kufizimi të tillë, edhe nëse është i madh, mund të sjellë që në disa kushte të mos arrijnë email-e të rëndësishëm. Prandaj, të aktivizoni ndonjë kufizim për postën e ardhshme nuk rekomandohet aspak. Megjithatë, nëse keni vendosur të merrni këtë rrezik, duhet qasur me kujdes ndaj konfigurimit të kufizimit të mesazheve të ardhshme. Për shembull, mund të kufizoni numrin e email-eve të ardhshme nga kontraktorët e besuar, në mënyrë që, në rast se serveri i tyre i postës është kompromentuar, të mos kryhet një sulm spam ndaj kompanisë suaj.
Për të mbrojtur veten nga fluksi i email-eve të ardhshme në rast bombardimi me email-e, administratori i sistemit duhet të marrë masa më të zgjuara sesa thjesht kufizimi i postës së ardhshme. Një zgjidhje e tillë mund të jetë përdorimi i listave të mjegullta. Parimi i veprimit të tyre është se me përpjekjen e parë për të dërguar një mesazh nga një dërgues të pabesueshëm, lidhja me serverin ndërpritet papritur, duke shkaktuar që dërgimi i email-it të dështojë. Megjithatë, nëse brenda një periudhe të caktuar serveri i pabesueshëm përsëri përpiqet të dërgojë të njëjtin email, serveri nuk ndërpret lidhjen dhe dërgimi kalon me sukses.
Qëllimi i të gjitha këtyre veprimeve është se programet për dërgimin automatik të masës së email-eve zakonisht nuk kontrollojnë suksesin e dorëzimit të mesazhit të dërguar dhe nuk ndërmarrin përpjekje për ta dërguar atë përsëri, ndërsa një njeri me siguri do të sigurohet nëse është dërguar emaili i tij në adresën e duhur apo jo.
Mundësi për të aktivizuar listat e gjysmë përjashtimit është gjithashtu në ndërfaqen web të cbpolicyd. Për të bërë që gjithçka të funksionojë, është e nevojshme të krijoni një politikë, në të cilën do të përfshiheshin të gjitha email-et hyrëse të dërguara për përdoruesit në serverin tonë, dhe pastaj, në bazë të kësaj politike, të krijoni një rregull të Greylisting, ku mund të përcaktoni intervalin gjatë të cilit cbpolicyd do të presë një përgjigje të përsëritur nga dërguesi i panjohur. Zakonisht, ky interval është 4-5 minuta. Në të njëjtën kohë, listat e gjysmë përjashtimit mund të konfigurohen që të përfshijnë të gjitha përpjekjet e suksesshme dhe të pasuksesshme për të dorëzuar email-e nga dërgues të ndryshëm, dhe në bazë të numrit të tyre të merret një vendim për automatikisht të shtohet dërguesi në listat e bardha ose të zeza.
Vëmendje, kjo është se përdorimi i listave të gjysmë përjashtimit duhet të bëhet me përgjegjësi maksimale. Më së miri do të ishte nëse përdorimi i kësaj teknologjie do të shoqërohej nga mbajtja e vazhdueshme e listave të bardha dhe të zeza, për të shmangur mundësinë e humbjes së email-eve që janë të rëndësishme për ndërmarrjen.
Përveç kësaj, mbrojtja nga bombardimi i email-eve mund të ndihmojë në shtimin e kontrollëve SPF, DMARC dhe DKIM. Shpesh, email-et që vijnë gjatë bombardimit të email-eve nuk kalojnë këto kontrolla. Si ta bëni këtë, është trajtuar .
Kështu, mbrojtja nga një kërcënim si bombardimi i email-eve është mjaft e lehtë dhe mund të realizohet që në fazën e ndërtimit të infrastrukturës Zimbra për ndërmarrjen tuaj. Megjithatë, është e rëndësishme të monitoroni vazhdimisht që rreziqet nga përdorimi i kësaj mbrojtjeje të mos kalojnë kurrë përfitimet që merrni.
Burimi: habr.com
