Защита от Zimbra и Mail Bombing

Бомбардирането по пощата е един от най-старите видове кибератаки. В основата си тя наподобява обикновена DoS атака, но вместо вълна от заявки от различни IP адреси, към сървъра се изпраща вълна от имейли, които пристигат в огромни количества на един от имейл адресите, поради което натоварването върху него се увеличава значително. Такава атака може да доведе до невъзможност за използване на пощенската кутия, а понякога дори да доведе до отказ на целия сървър. Дългата история на този вид кибератаки доведе до редица положителни и отрицателни последици за системните администратори. Положителните фактори включват доброто познаване на бомбардировките по пощата и наличието на прости начини да се защитите от такава атака. Отрицателните фактори включват голям брой публично достъпни софтуерни решения за извършване на такива видове атаки и способността на нападателя надеждно да се защити от откриване.

Важна характеристика на тази кибератака е, че е почти невъзможно да се използва за печалба. Добре, нападателят изпрати вълна от имейли до една от пощенските кутии, добре, той не позволи на човека да използва имейл нормално, добре, атакуващият хакна нечия корпоративна поща и започна масово да изпраща хиляди писма в целия GAL, поради който сървърът или се срина, или започна да се бави, така че стана невъзможно да се използва и после какво? Почти невъзможно е подобна киберпрестъпност да се превърне в реални пари, така че в момента бомбардирането на пощата е доста рядко и системните администратори може просто да не помнят необходимостта от защита срещу такава кибератака при проектирането на инфраструктура.

Но въпреки факта, че самото бомбардиране на пощата е доста безсмислена дейност от търговска гледна точка, то често е неразделна част от други, по-сложни и многоетапни кибератаки. Например, когато хакнат поща и я използват за отвличане на акаунт в някаква обществена услуга, нападателите често „бомбардират“ пощенската кутия на жертвата с безсмислени писма, така че писмото за потвърждение се губи в техния поток и остава незабелязано. Бомбардирането по пощата може да се използва и като средство за икономически натиск върху предприятието. По този начин активното бомбардиране на публичната пощенска кутия на предприятието, което получава заявления от клиенти, може сериозно да усложни работата с тях и в резултат на това да доведе до прекъсване на оборудването, неизпълнени поръчки, както и загуба на репутация и пропуснати ползи.

Ето защо системният администратор не трябва да забравя за възможността от бомбардиране на пощата и винаги да взема необходимите мерки за защита срещу тази заплаха. Като се има предвид, че това може да се направи дори на етапа на изграждане на пощенската инфраструктура и също така, че отнема много малко време и усилия от системния администратор, просто няма обективни причини да не осигурите на вашата инфраструктура защита от пощенски бомбардировки. Нека да разгледаме как защитата срещу тази кибератака е реализирана в Zimbra Collaboration Suite Open-Source Edition.

Zimbra е базиран на Postfix, един от най-надеждните и функционални агенти за прехвърляне на поща с отворен код в момента. И едно от основните предимства на неговата отвореност е, че поддържа голямо разнообразие от решения на трети страни за разширяване на функционалността. По-специално, Postfix поддържа напълно cbpolicyd, усъвършенствана помощна програма за киберсигурност на пощенския сървър. В допълнение към защитата срещу нежелана поща и белите списъци, черните списъци и сивите списъци, cbpolicyd позволява на администратора на Zimbra да настрои SPF проверка на подписа, както и да зададе ограничения за получаване и изпращане на имейли или данни. Те могат едновременно да осигурят надеждна защита срещу спам и фишинг имейли, както и да защитят сървъра от имейл бомбардировки.

Първото нещо, което се изисква от системния администратор, е активирането на модула cbpolicyd, който е предварително инсталиран в Zimbra Collaboration Suite OSE на инфраструктурния MTA сървър. Това се прави с помощта на командата zmprov ms `zmhostname` + zimbraServiceEnabled cbpolicyd. След това ще трябва да активирате уеб интерфейса, за да можете удобно да управлявате cbpolicyd. За да направите това, трябва да разрешите връзки на уеб порт номер 7780, създайте символна връзка с помощта на командата ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webuiи след това редактирайте файла с настройки с командата nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, където трябва да напишете следните редове:

$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="корен";
$DB_TABLE_PREFIX="";

След това остава само да рестартирате услугите Zimbra и Zimbra Apache, като използвате командите zmcontrol restart и zmapachectl restart. След това ще имате достъп до уеб интерфейса на example.com:7780/webui/index.php. Основният нюанс е, че входът към този уеб интерфейс все още не е защитен по никакъв начин и за да предотвратите проникването на неоторизирани лица в него, можете просто да затворите връзките на порт 7780 след всяко влизане в уеб интерфейса.

За да се предпазите от потопа от имейли, идващи от вътрешната мрежа, можете да използвате квоти за изпращане на имейли, които могат да бъдат зададени благодарение на cbpolicyd. Такива квоти ви позволяват да зададете ограничение за максималния брой писма, които могат да бъдат изпратени от една пощенска кутия за една единица време. Например, ако мениджърите във вашия бизнес изпращат средно 60-80 имейла на час, можете да зададете квота от 100 имейла на час с малко пространство. За да се изчерпи тази квота, мениджърите ще трябва да изпращат по едно писмо на всеки 36 секунди. От една страна, това е достатъчно, за да работи напълно, а от друга страна, с такава квота, нападателите, които са получили достъп до пощата на един от вашите мениджъри, няма да организират пощенски бомбардировки или масивна спам атака срещу предприятието .

За да зададете такава квота, трябва да създадете нова политика за ограничаване на изпращането на имейли в уеб интерфейса и да посочите, че тя се прилага както за имейли, изпратени в домейна, така и за имейли, изпратени до външни адреси. Това се прави по следния начин:

След това ще бъде възможно да се уточнят по-подробно ограниченията, свързани с изпращането на имейли, по-специално да се зададе интервалът от време, след който ограниченията ще се актуализират, както и съобщението, което потребителят, който е надвишил лимита си, ще получи. След това можете да зададете самото ограничение за изпращане на писма. Може да се задава както като брой изходящи съобщения, така и като брой байтове предадена информация. В същото време, с писма, които се изпращат над определения лимит, действайте по различен начин. Така например можете просто да ги изтриете веднага или можете да ги запазите, така че да изчезнат веднага след актуализиране на лимита за изпращане на съобщения. Втората опция може да се използва при определяне на оптималната стойност за лимита за изпращане на имейли до служители.

В допълнение към ограниченията за изпращане на имейли, cbpolicyd ви позволява да зададете лимит за получаване на имейли. Такъв лимит на пръв поглед е отлично решение за защита срещу бомбардиране на пощата, но всъщност определянето на такова ограничение, дори и да е голямо, е изпълнено с факта, че при определени условия важно писмо може да не стигне до вас. Ето защо е силно обезкуражено разрешаването на ограничения за входяща поща. Въпреки това, ако все пак решите да рискувате, трябва да подходите с особено внимание към настройката на лимита за входящи съобщения. Например, можете да ограничите броя на входящите имейли от доверени контрагенти, така че ако техният пощенски сървър е компрометиран, той да не изпраща спам към вашия бизнес.

За да се предпази от порой от входящи съобщения от пощенски бомбардировки, системният администратор трябва да направи нещо по-умно от простото ограничаване на входящата поща. Такова решение може да бъде използването на сиви списъци. Принципът на действието им е, че при първия опит за доставка на съобщение от ненадежден подател, връзката със сървъра се прекъсва рязко, поради което доставката на съобщението се проваля. Въпреки това, ако ненадежден сървър се опита да изпрати същия имейл отново в рамките на определен период от време, сървърът не прекъсва връзката и доставката му е успешна.

Смисълът на всички тези действия е, че автоматичните масови имейл програми обикновено не проверяват успеха на изпратеното съобщение и не се опитват да го изпратят втори път, докато човекът със сигурност ще се увери дали писмото му е изпратено на адреса или не .

Можете също да активирате сив списък в уеб интерфейса на cbpolicyd. За да работи всичко, трябва да създадете политика, която да включва всички входящи писма, адресирани до потребителите на нашия сървър, и след това, въз основа на тази политика, да създадете правило за сив списък, където можете да конфигурирате интервала, през който cbpolicyd ще чака за втори отговор от непознат подател. Обикновено това е 4-5 минути. В същото време сивите списъци могат да бъдат конфигурирани така, че да се вземат предвид всички успешни и неуспешни опити за доставка на писма от различни податели и въз основа на техния брой да се вземе решение за автоматично добавяне на подателя към белите или черните списъци.

Обръщаме внимание на факта, че към използването на сиви списъци трябва да се подхожда с най-голяма отговорност. Най-добре би било използването на тази технология да върви ръка за ръка с постоянното поддържане на бели и черни списъци, за да се изключи възможността от загуба на наистина важни за предприятието писма.

Освен това, добавянето на SPF, DMARC и DKIM проверки може да помогне за защита срещу бомбардиране по имейл. Често писмата, които идват в процеса на бомбардиране на пощата, не преминават такива проверки. Беше обяснено как да направите това в една от предишните ни статии.

По този начин е доста лесно да се предпазите от такава заплаха като бомбардиране на поща и можете да направите това дори на етапа на изграждане на инфраструктурата на Zimbra за вашето предприятие. Въпреки това е важно постоянно да гарантирате, че рисковете от използването на такава защита никога не надвишават ползите, които получавате.

Източник: www.habr.com