Zimbra и защита от мейл-бомбинга

Mail bombing is one of the oldest forms of cyber attacks. Essentially, it is similar to a regular DoS attack, but instead of a flood of requests from different IP addresses, a barrage of emails is sent to a single inbox, significantly increasing the load on it. This type of attack can lead to the mailbox becoming unusable and can even result in the server refusing to function. The long history of this type of cyber attack has led to several positive and negative consequences for system administrators. On the positive side, the well-studied nature of mail bombing and the existence of simple protective measures can be highlighted. On the negative side, there are many freely available software solutions for conducting such attacks and the possibility for attackers to effectively hide from detection.

An important feature of this cyber attack is that it is practically impossible to use for profit. An attacker may flood one of the mailboxes with a barrage of emails, disrupting the user's ability to use email conveniently. If an attacker hacks into someone’s corporate email and starts mass sending thousands of emails across the GAL, the server might crash or slow down to the point of becoming unusable. But then what? Converting such cybercrime into real money is nearly impossible, making mail bombing a relatively rare occurrence nowadays. Thus, system administrators might not even think about the need to protect against this type of cyber attack during infrastructure design.

Въпреки това, въпреки че мейл-бомбинга сам по себе си е доста безсмислено занятие от търговска гледна точка, той често е част от други, по-сложни и многоетапни кибератаки. Например, при хакерство на пощата и използването ѝ за уговаряне на акаунт в публичен сервиз, злонамерените лица често "бомбят" пощенската кутия на жертвата с безсмислени писма, за да затрият писмото с потвърждение в техния поток и то остане незабелязано. Също така, мейл-бомбинга може да се използва като средство за икономически натиск върху предприятие. Активната бомбардировка на публичната поща на предприятието, която получава заявки от клиенти, може сериозно да затрудни работата с тях и, като следствие, да доведе до престой на оборудването, неизпълнени поръчки, а също и загуба на репутация и нереализирана печалба.

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

В основата на Zimbra стои Postfix — един от най-надеждните и функционални Mail Transfer Agent с отворен код в момента. И едно от основните предимства на неговата отвореност е, че той поддържа най-разнообразни външни решения за разширяване на функционалността. В частност, 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="root";
$DB_TABLE_PREFIX="";

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

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

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

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

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

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

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

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

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

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

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

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