Zimbra dhe mbrojtja e serverit nga ngarkesat

Email ka bërë një vend të rëndësishëm si standard i komunikimit biznesor. Falë efikasitetit të tij ekonomik të lartë, si dhe disa karakteristikave që lidhen me citimin e tekstit dhe bashkëngjitjen e skedarëve, emaili është mënyra më e mirë për shkëmbimin e dokumenteve dhe komunikimin e sjellshëm në biznes. Këto karakteristika gjithashtu janë shkaku pse emaili është bërë kaq i popullarizuar nga spammerat. Si rezultat, sot emaili përbën një oqean të madh dhe të trazuar spam, në të cilin letra biznesore shfaqen vetëm ndonjëherë. Kjo është arsyeja pse një nga detyrat kryesore të administratorit të çdo serveri email është mbrojtja nga shpërndarjet e spamit. Le të shohim se çfarë mund të bëjmë me këtë në Zimbra Collaboration Suite Open-Source Edition.

Zimbra dhe mbrojtja e serverit nga ngarkesat

Pavarësisht se zgjidhja është falas, Zimbra OSE ofron shumë mjete tepër efikase për administratorin sistemor për të zgjidhur problemin e marrjes së emaileve të padëshiruara. Ne kemi shkruar tashmë për mjete si Amavis, SpamAssassin, ClamAV dhe cbpolicyd, të cilat lejojnë filtrimin e besueshëm të postës së ardhshme, duke eliminuar shpërndarjet e spamit, si dhe emailet e infektuara dhe phishing. Megjithatë, disavantazhi kryesor i tyre është se të gjitha ato punojnë me emailet që janë marrë tashmë dhe shpenzojnë burime sistemore për filtrimin e mesazheve të padobishme, të cilat gjithmonë mund të përdoren në një mënyrë shumë më të mirë. Por çfarë ndodh nëse ndërmarrja juaj është nën kërcënimin e një botneti të madh, i cili vazhdimisht mbush serverin tuaj email me aq shumë emaile plehrash sa që për filtrimin e tyre merr një pjesë të madhe të fuqisë server MTA?

Në teorinë, është e mundur të mbroheni nga kjo duke lidhur një shërbim të miratuar për filtrimin e postës së ardhshme, por në praktikë, ky metodë mbrojtjeje nuk i përshtatet çdo ndërmarrjeje, sepse në këtë rast do t'ju duhet të besoni në duar të tretë për përpunimin jo vetëm të spamit, por edhe të korrespondencës biznesore, gjë që nuk është gjithmonë e sigurt, dhe shpeshherë bie në kundërthënie me politikat e sigurisë së kompanisë. Për më tepër, shfaqen rreziqe lidhur me besueshmërinë e punës së filtrit të spamit në cloud. Një zgjidhje mund të jetë organizimi i mbrojtjes së serverit me forca të brendshme. Për këto qëllime, në Zimbra është integruar mjeti Postscreen, i cili ka për qëllim të mbrojë serverin email nga emailet që dërgohen nga botnetet, pa mbingarkuar serverin email.

Natyra e punës së Postscreen është se ky mjet skanon të gjitha kërkesat për lidhjen me emailin server dhe nuk lejon lidhjen me serverin për ata klientë që i duken të dyshimtë. Sipas statistikave, rreth 90% e spamit në botë dërgohet pikërisht nga botnetet, Postscreen shpesh përdoret si një masë mbrojtëse e parë për serverin email nga shpërndarjet e padëshiruara. Falë kësaj, serveri email mund të funksionojë në mënyrë të qëndrueshme pa mbingarkesë edhe në kushte të sulmeve të fuqishme me spam nga botnetet e mëdha.

Parimi i punĂ«s sĂ« Postscreen Ă«shtĂ« mjaft i thjeshtĂ«, ky mjet Ă«shtĂ« nĂ« gjendje tĂ« kryejĂ« njĂ« seri kontrollesh tĂ« thjeshta pĂ«r emailet e ardhshme para se t'i dĂ«rgojĂ« ato nĂ« serverin email ose nĂ« shĂ«rbime tĂ« tjera qĂ« zhvillojnĂ« kontroll mĂ« tĂ« thellĂ« dhe tĂ« detajuar pĂ«r emailet e ardhshme. Çdo kontroll, pĂ«rkatĂ«sisht, mund tĂ« kalojĂ« ose tĂ« mos kalojĂ«. Bazuar nĂ« rezultatet e çdo kontrolli, Postscreen mund tĂ« aplikojĂ« njĂ« nga tre veprimet sipas zgjedhjes sĂ« administratorit tĂ« Zimbra: Drop, Ignore ose Enforce. Veprimi Drop pranveron lidhjen me klientin nĂ« rast se kontrolli nuk kalon, veprimi Ignore lejon tĂ« injorohen rezultatet e kontrollit nĂ« marrjen e njĂ« vendimi pĂ«rfundimtar, por nĂ« tĂ« njĂ«jtĂ«n kohĂ« mbledh informacion dhe statistikĂ« nĂ« lidhje me kryerjen e kontrolleve, ndĂ«rsa veprimi Enforce lejon tĂ« merren parasysh rezultatet e kontrolleve tĂ« kryera nĂ« marrjen e njĂ« vendimi pĂ«rfundimtar, por vazhdon tĂ« kryejĂ« tĂ« gjitha provat qĂ« janĂ« planifikuar nga administratorĂ«t sistemor.

Parimi i thjeshtë i punës nuk do të thotë aspak lehtësinë e përdorimit dhe konfigurimin. Problemi është se Postscreen i konfiguruar gabim mund të bëhet shkaku për të cilin disa emaile të rëndësishme për ndërmarrjen nuk do të arrijnë tek marrësi. Kjo është arsyeja pse është e nevojshme të qasemi me kujdes ndaj konfigurimit të këtij instrumenti kaq të fuqishëm si Postscreen dhe ta testojmë vazhdimisht për sjelljen e tij në situata të ndryshme.

Postscreen në Zimbra është aktivizuar nga fillimi, por shumë mund të mos jenë të kënaqur me konfigurimin fillestar. Tani do të shqyrtojmë mundësinë më të sigurt dhe të ulur për rreziqe të konfigurimit të Postscreen. Thelbi i saj është se pas dështimit të ndonjë kontrolli, Postscreen nuk do të ndërpresë menjëherë lidhjen me klientin, por do të kryejë të gjitha verifikimet deri në fund, dhe në rast se këto verifikime dështojnë, do të japë një mesazh gabimi. Kjo do të lejojë njoftimin e një dërguesi të vërtetë për dështimin e dorëzimit të mesazhit, nëse Postscreen e percepton atë si spam. Kjo arrihet duke vendosur vlerën enforce në parametrat e kontrollit. Kjo vlerë lejon përfundimin e kontrollave të filluara deri në fund, pa ndërprerë lidhjen me klientin pas dështimit të parë, por pas përfundimit, të bllokohet gjithsesi mesazhi me spam, pa e dorëzuar atë në server.

Për të aktivizuar verifikimet e nevojshme, duhet të futni komandat e mëposhtme:

zmprov mcf zimbraMtaPostscreenDnsblSites ‘b.barracudacentral.org=127.0.0.2*7’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.[10;11]*8’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.[4..7]*6’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.3*4’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.2*3’

Kjo komandë lejon të shtoni një verifikim DNS për lidhjet e ardhshme nëpërmjet dy bazave më të njohura publike të spamit dhe të vlerësoni mesazhet në varësi të asaj në cilën nga bazat do të gjendet adresa e dërguesit. Sa më shumë 'yll' ndëshkues të ketë klienti, aq më i mundshëm është që ai të jetë një dërgues spami.

zmprov mcf zimbraMtaPostscreenDnsblAction enforce

Kjo komandë përcakton veprimin që kryhet pas rezultatet të verifikimit DNS. Në këtë rast, rezultati i verifikimit ruhet, ndërsa vetë mesazhi vazhdon të kalojë testet e tjera.

zmprov mcf zimbraMtaPostscreenGreetAction enforce

Duke qenë se në protokollin SMTP, pas lidhjes së drejtpërdrejtë, serveri fillon bisedën me klientin, dhe për rrjedhojë, Postscreen mund të dërgojë një përshëndetje tek klienti. Duke qenë se shumë klientë të spamit, pa pritur përfundimin e përshëndetjes, fillojnë të dërgojnë komanda, ato mund të identifikohen lehtësisht. Kjo komandë lejon të merret parasysh rezultati i kësaj verifikimi, por duke vazhduar të kryeni testet e tjera.

zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop

Në kuadër të kësaj verifikimi, Postscreen lejon filtrimin e lidhjeve që nuk vijnë nga klientët e postës. Duke qenë se ato nuk dërgojnë asnjë mesazh, mund të ndalohen pa asnjë shqetësim nga serveri.

zmprov mcf zimbraMtaPostscreenPipeliningAction enforce

Kjo verifikim bazohet në faktin se si për default, në protokollin SMTP klienti mund të dërgojë vetëm një komandë në një kohë dhe më pas të presë përgjigjen nga serveri për atë komandë. Megjithatë, shumë bot të spamit sillen ndryshe, duke dërguar një mori komandash pa pritur përgjigjen nga serveri. Kjo lejon identifikimin praktikisht pa gabime të një boti spam.

Në parim, këto verifikime do të mjaftojnë për Postscreen që të filtroni shumicën e botëve të spamit dhe të arrini një ulje të konsiderueshme të ngarkesës në serverin tuaj të postës. Në të njëjtën kohë, njerëzit e vërtetë do të marrin një mesazh që tregon se mesazhi i tyre nuk u dorëzua, gjë që ndihmon në uljen e rrezikut të humbjes së mesazheve të rëndësishme për shkak të konfigurimeve të Postscreen. Nëse kjo ndodh, mund të shtoni një dërgues të besueshëm në listën e bardhë të Postscreen. Për të krijuar lista të bardhë dhe të zezë për Postscreen, fillimisht duhet të krijoni një skedar. /opt/zimbra/conf/postfix/postscreen_wblist.

Në të do të shtojmë listën e adresave IP dhe subneteve të lejuara dhe të ndaluara në formatin CIDR. Për shembull, do të bllokojmë subnetin 121.144.169.*, por do të lejojmë lidhjen e vetëm adresës IP nga kjo subnet:

# Rules are evaluated in the order as specified.
# Blacklist 121.144.169.* except 121.144.169.196.
121.144.169.196/32 lejo
121.144.169.0/24 refuzo

VĂ«mendni rĂ«ndĂ«sinĂ« e rendit tĂ« shĂ«nimeve. Çështja Ă«shtĂ« se Postscreen do tĂ« skanojĂ« skedarin me listat e bardhĂ« dhe tĂ« zezĂ« deri nĂ« pĂ«rputhjen e parĂ«, dhe nĂ«se subneti i bllokuar ndodhet para adresĂ«s IP tĂ« lejuar, verifikimi thjesht nuk do tĂ« arrijĂ« nĂ« shĂ«nimin se kjo adresĂ« IP Ă«shtĂ« e shtuar nĂ« listĂ«n e bardhĂ« dhe lidhja me serverin nuk do tĂ« ndodhĂ«.

Pasi që skedari me listat e bardhë dhe të zezë është redaktuar dhe ruajtur, mund të aktivizoni verifikimin përkatës me komandat e mëposhtme:

zmprov mcf zimbraMtaPostscreenAccessList «permit_mynetworks, cidr:/opt/zimbra/conf/postfix/postscreen_wblist»
zmprov mcf zimbraMtaPostscreenBlacklistAction enforce

Tani Postscreen, përveç verifikimeve që ne kemi vendosur, gjithashtu do të konsultohet me skedarin e listave të bardhë dhe të zezë, gjë që do t'i lejojë administratorit të zgjidhë lehtësisht problemet me pamundësinë e lidhjes të dërgueseve të besueshëm.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster