Автор: Ходин Илья А.. Дата публикации: 19 апреля 2018 . Категория: Блог.
После установки почтового сервера Zimbra может возникнуть проблема с приемом почты, для внутренних получателей т.е., письмо отправляется, но не доходит до абонента не доходит. Данная проблема решается следующим способом — заходим на наш сервер по SSH, логинимся по учеткой zimbra:
Не приходят входящие письма в Zimbra
Не приходят входящие письма в Zimbra
Добрый день уважаемые читатели блога pyatilistnik.org, сегодня хочу рассказать, очередной случай из своей повседневной жизни. Есть у меня почтовый сервер Zimbra, он работает как часы и никаких нареканий на него нет. В какой-то момент обращается ко мне сотрудник, с такой вот проблемой, у него есть почтовый ящик, с него получается отправлять письма, но не получается их принимать, и его почтовый клиент Microsoft Outlook не выдавал ошибок при отправке и получении почты. Давайте разбираться по какой причине, не приходят входящие письма в Zimbra.
Первым делом, я создал тестовое сообщение на yandex почте и отправил его сотруднику, письмо не пришло. Прежде чем заморачиваться с почтовыми логами я быстро рестартанул Zimbra. Эффекта это не дало. Далее я проверил, что у других сотрудников, почта работает, как нужно, это дало возможность сузить проблему до одного конкретного ящика.
Теперь чтобы понять что произошло нужно смотреть почтовые логи, по умолчанию они находятся в папке /var/log/maillog и zimbra.log
Я для удобства скачиваю себе через WinSCP лог-файлы для последующего изучения, но вы можете искать письма и без этого, прямо в консоли, я для начала создам символическую ссылку для своего удобства.
/opt/zimbra/libexec/zmmsgtrace -s microsoftexam
Я увижу все письма от microsoftexam за сегодня
Либо вот такой командой:
Обратите внимание, что есть еще файлы логи /var/log/mail
Я увидел, что письма доставлены, так как имеют статус 250 2.1.5 Delivery OK, но так же я обратил внимание на статус 250 2.6.0 Ok, message saved у почты, не входящий в этот домен.
Nov 21 09:45:24 mail zmconfigd[25932]: All configs fetched in 0.09 seconds
Nov 21 09:45:25 mail zmconfigd[25932]: Watchdog: service antivirus status is OK.
Nov 21 09:45:25 mail zmconfigd[25932]: All rewrite threads completed in 0.00 sec
Nov 21 09:45:25 mail zmconfigd[25932]: All restarts completed in 0.00 sec
Nov 21 09:45:26 mail postfix/smtpd[30656]: connect from forward106p.mail.yandex.net[77.88.28.109]
Nov 21 09:45:26 mail postfix/smtpd[30656]: Anonymous TLS connection established from forward106p.mail.yandex.net[77.88.28.109]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Nov 21 09:45:26 mail postfix/smtpd[30656]: A33AC101BACA8: client=forward106p.mail.yandex.net[77.88.28.109]
Nov 21 09:45:26 mail postfix/cleanup[28564]: A33AC101BACA8: message- >
Nov 21 09:45:26 mail postfix/qmgr[28292]: A33AC101BACA8: from= , size=1523, nrcpt=1 (queue active)
Nov 21 09:45:26 mail postfix/dkimmilter/smtpd[29661]: connect from localhost[127.0.0.1]
Nov 21 09:45:26 mail postfix/smtpd[30656]: disconnect from forward106p.mail.yandex.net[77.88.28.109]
Nov 21 09:45:26 mail postfix/dkimmilter/smtpd[29661]: Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Nov 21 09:45:26 mail postfix/dkimmilter/smtpd[29661]: A5D0B101BACAD: client=localhost[127.0.0.1]
Nov 21 09:45:26 mail postfix/cleanup[31985]: A5D0B101BACAD: message- >
Nov 21 09:45:26 mail opendkim[28019]: A5D0B101BACAD: no signing table match for ‘microsoftexam@yandex.ru’
Nov 21 09:45:26 mail postfix/qmgr[28292]: A5D0B101BACAD: from= , size=1736, nrcpt=1 (queue active)
Nov 21 09:45:26 mail postfix/smtp[29660]: A33AC101BACA8: to=
, relay=127.0.0.1[127.0.0.1]:10030, delay=0.06, delays=0.01/0/0/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as A5D0B101BACAD)
Nov 21 09:45:26 mail postfix/qmgr[28292]: A33AC101BACA8: removed
Nov 21 09:45:26 mail postfix/dkimmilter/smtpd[29661]: disconnect from localhost[127.0.0.1]
Nov 21 09:45:26 mail amavis[27959]: (27959-03) ESMTP:[127.0.0.1]:10032 /opt/zimbra/data/amavisd/tmp/amavis-20171121T094357-27959-cI4VXxL3: ->
Received: from mail.pyatilistnik.org ([127.0.0.1]) by localhost (mail.pyatilistnik.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP for
; Tue, 21 Nov 2017 09:45:26 +0300 (MSK)
Nov 21 09:45:26 mail amavis[27959]: (27959-03) Checking: P9OMZ8E9b4jL ORIGINATING_POST/MYNETS [127.0.0.1] ->
Nov 21 09:45:27 mail postfix/amavisd/smtpd[29665]: 2AD6B101BACA8: client=localhost[127.0.0.1]
Nov 21 09:45:27 mail postfix/cleanup[28564]: 2AD6B101BACA8: message- >
Nov 21 09:45:27 mail postfix/qmgr[28292]: 2AD6B101BACA8: from= , size=2447, nrcpt=1 (queue active)
Nov 21 09:45:27 mail postfix/amavisd/smtpd[29665]: disconnect from localhost[127.0.0.1]
Nov 21 09:45:27 mail amavis[27959]: (27959-03) P9OMZ8E9b4jL FWD from ->
, BODY=7BIT 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 2AD6B101BACA8
Nov 21 09:45:27 mail amavis[27959]: (27959-03) Passed CLEAN
, Queue-ID: A5D0B101BACAD, Message-ID: , mail_ > Nov 21 09:45:27 mail postfix/smtp[29663]: A5D0B101BACAD: to=
, relay=127.0.0.1[127.0.0.1]:10032, delay=0.51, delays=0.04/0/0/0.46, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 2AD6B101BACA8)
Nov 21 09:45:27 mail postfix/qmgr[28292]: A5D0B101BACAD: removed
Nov 21 09:45:27 mail postfix/smtpd[28950]: connect from mail.pyatilistnik.org[193.106.95.105]
Nov 21 09:45:27 mail postfix/smtpd[28950]: 4F6BB101BACAD: client=mail.pyatilistnik.org[193.106.95.105]
Nov 21 09:45:27 mail postfix/cleanup[31985]: 4F6BB101BACAD: message- >
Nov 21 09:45:27 mail postfix/qmgr[28292]: 4F6BB101BACAD: from=
, size=2806, nrcpt=1 (queue active)
Nov 21 09:45:27 mail postfix/smtpd[28950]: disconnect from mail.pyatilistnik.org[193.106.95.105]
Nov 21 09:45:27 mail postfix/dkimmilter/smtpd[29661]: connect from localhost[127.0.0.1]
Nov 21 09:45:27 mail postfix/lmtp[29746]: 2AD6B101BACA8: to=
, relay=mail.pyatilistnik.org[193.106.95.105]:7025, delay=0.16, delays=0/0/0.09/0.06, dsn=2.1.5, status=sent (250 2.1.5 Delivery OK)
Nov 21 09:45:27 mail postfix/qmgr[28292]: 2AD6B101BACA8: removed
Nov 21 09:45:27 mail postfix/dkimmilter/smtpd[29661]: Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Nov 21 09:45:27 mail postfix/dkimmilter/smtpd[29661]: 5197F101BACA8: client=localhost[127.0.0.1]
Nov 21 09:45:27 mail postfix/cleanup[28564]: 5197F101BACA8: message- >
Nov 21 09:45:27 mail opendkim[28019]: 5197F101BACA8: no signing table match for ‘microsoftexam@yandex.ru’
Nov 21 09:45:27 mail postfix/qmgr[28292]: 5197F101BACA8: from=
, size=3023, nrcpt=1 (queue active)
Nov 21 09:45:27 mail postfix/smtp[29660]: 4F6BB101BACAD: to= , relay=127.0.0.1[127.0.0.1]:10030, delay=0.05, delays=0/0/0/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5197F101BACA8)
Nov 21 09:45:27 mail postfix/dkimmilter/smtpd[29661]: disconnect from localhost[127.0.0.1]
Nov 21 09:45:27 mail postfix/qmgr[28292]: 4F6BB101BACAD: removed
Nov 21 09:45:27 mail amavis[27964]: (27964-03) ESMTP:[127.0.0.1]:10032 /opt/zimbra/data/amavisd/tmp/amavis-20171121T094355-27964-bem0MQso:
-> Received: from mail.pyatilistnik.org ([127.0.0.1]) by localhost (mail.pyatilistnik.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP for ; Tue, 21 Nov 2017 09:45:27 +0300 (MSK)
Nov 21 09:45:27 mail amavis[27964]: (27964-03) Checking: 0BKfkQciq2gk ORIGINATING_POST/MYNETS [127.0.0.1]
->
Nov 21 09:45:27 mail postfix/amavisd/smtpd[30666]: connect from localhost[127.0.0.1]
Nov 21 09:45:27 mail postfix/amavisd/smtpd[30666]: DD7AA101BACAD: client=localhost[127.0.0.1]
Nov 21 09:45:27 mail postfix/cleanup[31985]: DD7AA101BACAD: message- >
Nov 21 09:45:27 mail amavis[27964]: (27964-03) 0BKfkQciq2gk FWD from
-> , BODY=7BIT 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as DD7AA101BACAD
Nov 21 09:45:27 mail postfix/amavisd/smtpd[30666]: disconnect from localhost[127.0.0.1]
Nov 21 09:45:27 mail postfix/qmgr[28292]: DD7AA101BACAD: from=
, size=2991, nrcpt=1 (queue active)
Nov 21 09:45:27 mail amavis[27964]: (27964-03) Passed CLEAN
-> , Queue-ID: 5197F101BACA8, Message-ID: , mail_ > Nov 21 09:45:27 mail postfix/smtp[29663]: 5197F101BACA8: to= , relay=127.0.0.1[127.0.0.1]:10032, delay=0.58, delays=0.04/0/0/0.53, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as DD7AA101BACAD)
Nov 21 09:45:27 mail postfix/qmgr[28292]: 5197F101BACA8: removed
Nov 21 09:45:28 mail postfix/smtp[31982]: DD7AA101BACAD: to= , relay=relay.pyatilistnik.info[138.201.59.220]:25, delay=0.8, delays=0/0.01/0.32/0.47, dsn=2.6.0, status=sent (250 2.6.0 Ok, message saved >)
Nov 21 09:45:28 mail postfix/qmgr[28292]: DD7AA101BACAD: removed
Статус 250 2.6.0 Ok, message saved натолкнул меня на то, что та непонятная почта выступает в роли почты для перенаправления, я решил в этом убедиться и посмотреть логи в каталоге /opt/zimbra/log/mailbox.log, где я обнаружил строчку:
Теперь все стало на свои места. Заходим в веб-интерфейс нужного почтового ящика Zimbra, куда не приходят входящие письма. Переходим в "Настройки — Фильтры". Тут то и была проблема, у сотрудника был активный фильтр, который я отключил.
Фильтр был вот такого содержания и делался для переадресации на другой почтовый ящик. Фильтр, как оказалось был настроен не правильно. Как делать правильную переадресацию в Zimbra, читайте по ссылке слева.
После отключения фильтра все прекрасно заработало и входящие письма стали ходить.
Мейл-бомбинг является одной из наиболее старых разновидностей кибер-атак. По своей сути она напоминает обычную 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 для вашего предприятия. Однако важно постоянно следить за тем, чтобы риски от использования такой защиты никогда не превышали получаемые вами преимущества.
