Мейл-бомбинг является одной из наиболее старых разновидностей кибер-атак. По своей сути она напоминает обычную DoS-атаку, только вместо волны запросов с разных ip-адресов, на сервер отправляется вал электронных писем, которые в огромных количествах приходят на один из почтовых адресов, за счет чего нагрузка на него значительно возрастает. Такая атака может привести к невозможности использовать почтовый ящик, а иногда даже способна привести к отказу всего сервера. Многолетняя история такого вида кибератак привела к ряду позитивных и негативных для системных администраторов последствий. К позитивным факторам можно отнести хорошую изученность мейл-бомбинга и наличие простых способов защититься от такой атаки. К негативным же факторам можно отнести большое количество общедоступных программных решений для проведения таких видов атак и возможность для злоумышленника надежно защититься от обнаружения.



Немаловажной особенностью данной кибератаки является то, что ее практически невозможно использовать для извлечения прибыли. Ну направил злоумышленник на один из почтовых ящиков вал электронных писем, ну не дал человеку нормально использовать электронную почту, ну взломал злоумышленник чью-нибудь корпоративную почту и начал массово рассылать по всему GAL тысячи писем, из-за чего сервер либо крашнулся, либо начал тормозить так, что пользоваться им стало невозможно, и что дальше? Конвертировать подобное киберпреступление в живые деньги почти невозможно, поэтому просто мейл-бомбинг в настоящее время является довольно редким явлением и системные администраторы при проектировании инфраструктуры могут просто не вспомнить о необходимости защиты от подобной кибератаки.

Тем не менее, несмотря на то, что сам по себе мейл-бомбинг является довольно бессмысленным с коммерческой точки зрения занятием, он часто является составной частью других, более сложных и многоступенчатых кибератак. Например, при взломе почты и использовании ее для угона аккаунта в каком-либо публичном сервисе, злоумышленники часто «бомбят» почтовый ящик жертвы не имеющими смысла письмами, чтобы письмо с подтверждением затерялось в их потоке и осталось незамеченным. Также мейл-бомбинг может использоваться как средство экономического давления на предприятие. Так, активная бомбардировка публичного почтового ящика предприятия, на который поступают заявки от клиентов, может серьезно затруднить работу с ними и, как следствие, может привести к простою оборудования, невыполненным заказам, а также потере репутации и упущенной выгоде.

Именно поэтому системному администратору не стоит забывать о вероятности проведения мейл-бомбинга и всегда предпринимать необходимые меры для защиты от этой угрозы. Если учесть то, что это можно сделать еще на этапе построения почтовой инфраструктуры, а также то, что это отнимает у системного администратора совсем немного времени и труда, объективных причин для того, чтобы не обеспечить свою инфраструктуру защитой от мейл-бомбинга, попросту не остается. Давайте же посмотрим на то, как реализована защита от данной кибератаки в 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 секунд. С одной стороны этого достаточно для того, чтобы полноценно работать, а с другой стороны, с такой квотой злоумышленники, получившие доступ к почте одного из ваших менеджеров не устроят мейл-бомбинг или массовую спам-атаку на предприятии.

Для того, чтобы установить подобную квоту, необходимо в веб-интерфейсе создать новую политику ограничения отправки писем и указать, чтобы она действовала как на письма отправленные внутри домена, так и на письма, действующие на внешние адреса. Делается это следующим образом:



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

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

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

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

Включить серые списки можно также в веб-интерфейсе cbpolicyd. Для того, чтобы все работало, необходимо создать политику, в которую попадали бы все входящие письма, адресованные пользователям на нашем сервере, а затем на основе этой политики создать правило Greylisting, где можно настроить интервал, во время которого cbpolicyd будет ожидать повторного ответа от незнакомого отправителя. Обычно он составляет 4-5 минут. При этом серые списки можно настроить так, чтобы все успешные и неуспешные попытки доставить письма от разных отправителей учитывались и на основании их количества принималось решение об автоматическом добавлении отправителя в белый или черный списки.

Обращаем ваше внимание на то, что к использованию серых списков стоит походить с максимальной ответственностью. Лучше всего будет, если использование этой технологии будет идти рука об руку с постоянным ведением белых и черных списков, чтобы исключить возможность потери действительно важных для предприятия писем.

Кроме того, защититься от мейл-бомбинга может помочь добавление проверок SPF, DMARC и DKIM. Зачастую письма, которые поступают в процессе мейл-бомбинга такие проверки не проходят. О том, как это сделать, рассказывалось в одной из наших предыдущих статей.

Таким образом, защититься от такой угрозы как мейл-бомбинг, довольно просто, и сделать это можно еще на этапе строительства инфраструктуры Zimbra для вашего предприятия. Однако важно постоянно следить за тем, чтобы риски от использования такой защиты никогда не превышали получаемые вами преимущества.