| Главная » Статьи » Mail » Zimbra |
0. Используемые порты. Zimbra активно использует различные сетевые порты как для внешних, так и для внутрисистемных подключений. Именно поэтому наиболее оптимальным для нее станет создание так называемого «Белого списка» в правилах брандмауэра. То есть администратор сперва запрещает любые подключения к каким-либо портам на сервере, а затем открывает лишь те, которые необходимы для нормальной работы сервера. И именно на этом этапе администратор сервера Zimbra неизменно сталкивается с вопросом о том, какие порты следует открыть, а какие лучше всего не трогать. Давайте посмотрим, какие порты и для чего использует Zimbra, чтобы вам было проще принимать решение о составлении собственного «белого списка» в брандмауэре. Для внешних подключений Zimbra может использовать до 12 портов, среди которых: 25 Порт для входящей почты в postfix Как уже было упомянуто, помимо внешних подключений, в Zimbra Collaboration Suite осуществляется и масса внутренних подключений, которые также происходят на различных портах. Поэтому при включении таких портов в «белый список» стоит следить за тем, чтобы возможность подключения к ним была только у локальных пользователей. 389 Порт для незащищенного подключения к LDAP Отметим, что если в случае, когда Zimbra работает только на одном сервере, можно обойтись минимальным набором открытых портов. Но если на вашем предприятии Zimbra установлена на несколько серверов, то вам придется открыть 14 портов с номерами 25, 80, 110, 143, 443, 465, 587, 993, 995, 3443, 5222, 5223, 7071, 9071. Такой набор открытых для подключения портов обеспечит нормальное взаимодействие между серверами. При этом администратору Zimbra всегда необходимо помнить, что, к примеру, открытый порт для доступа к LDAP, является серьезной угрозой для информационной безопасности предприятия. Часть поста: https://habr.com/company/zimbra/blog/427729/ 1. Веб-интерфейс, вход. По умолчанию вход через веб-интерфейс по https. Регуляция данного обстоятельства: zmtlsctl [mode] где mode = <http, https, both, mixed, redirect> Однако штатный proxy, который теперь (с версии 8.6, по-моему) обязателен к применению, имеет собственное мнение на этот счёт. Вот его комментарий на команду zmtlsctl redirect в свежеустановленной Zimbre: Error: When zimbraReverseProxyMailMode (on the proxy server) is https, the only valid settings for zimbraMailMode are both or https. 2. Нет доставки внешней почты. После установки и настройки всего и вся, у меня никак не хотела доставляться внешняя почта, лечится так: sudo su zimbra Источник: http://wiki.zimbra.com/wiki/Incoming_Mail_Problems 3. Веб-интерфейс, "ошибка сети". После увеличения количества пользователей Zimbra появились жалобы, что при входе в веб интерфейс появляется «Ошибка сети». Эта проблема связана с работой встроенного в Zimbra 8.0 и старше метода защиты от DoS Пользователи начали жаловаться, что периодически при попытке входа возникает «Ошибка сети». Анализ логов выявил следующее сообщение: 2016-04-12 09:22:30,489 INFO [qtp509886383-3765:http://127.0.0.1:80/service/soap/AuthRequest] [] misc - Access to IP 1.2.3.4 suspended, for repeated failed login. Выяснилось, что это срабатывает встроенная, начиная с версии 8.0 защита от DoS. Настройка осуществляется с помощью нескольких параметров: zimbraHttpDosFilterDelayMillis — задержка, которая применяется ко всем запросам выше лимита, прежде чем они будут рассмотрены. В миллисекундах. Возможны варианты в виде значения от -1,0,1 и более. Где -1 — отклонять запросы сразу. 0 — не выставлять задержку, 1 и более — задержка в мс. По-умолчанию -1. Решение проблемы кроется в подкручивании этих ручек до комфортных значений и последующего перезапуска mailbox сервиса (zmmailboxdctl restart) Однако, есть нюансы, если у Вас так называемая «Multi server» кофигурация, то есть несколько mailbox серверов за proxy. Что бы все это дело работало, необходимо для начала сделать так, что бы mailbox знали о реальных IP, с которых приходят запросы. По-умолчанию в логах отображается IP proxy. Для этого проверяю текущее значение параметра zimbraMailTrustedIP: После этого в логах будут реальные IP и политики DoS будут применяться к ним и все будет работать как задумано 4. Добавление адресной книги руками. Если вы ходите принудительно добавить пользователям GAL книгу, то можно воспользоваться следующим скриптом: #!/bin/bash zmprov -l gaa| while read USER; do zmmailbox -z -m $USER cm --view contact -F# "/Адресная книга предприятия" galsync@yourdomain.com /_zimbra; done где galsync@yourdomain.com аккаунт синхронизации, /_zimbra — имя раcшариваемой адресной книги. https://habr.com/post/134981/ Комментарий JStingo 5. Защита порта memcached. Особое внимание следует уделить внимание порту 11211, на котором работает memcached. Именно он задействован в популярной разновидности кибератак memcrashd. Fix для standalone-server: su - zimbra Инструкция здесь: https://wiki.zimbra.com/wiki/Blocking_Memcached_Attack 6. Блок определённого адреса. Заблокировать получение писем от определённого адреса - несложно. Путь №1 самый радикальный: ### создадим файл если его нет, или добавим строчку ### добавим в настройки Zimbra Postfix проверку smtpd_sender_restrictions ### можем подождать 1-2 минуты, пока zmconfigd применит настройку, либо перезапустить Postfix Источник: https://toster.ru/q/556845?utm_source=tm_habrahabr&utm_medium=tm_block&utm_campaign=questions_post 7. Запрет доставки наружу/снаружи aleksa106
14/03/2015 - 14:12 Вроде сделал все по инструкции...
Правила не появились... дописал "напрямую" в /opt/zimbra/postfix/conf/main.cf - рестартовал... правила остались, работают. Zimbra 8.0.6_1153... PS: после 5 пункта, необходимо перезагрузить сервер... zmcontrol restart для меня оказалось недостаточно. Правила подгрузились, все работает. Ура! Взято здесь: http://ossportal.org/forum/zimbra/1114 комментарий whyme
8. HowTo change SMTP Banner, HELO, EHLOGreetings for Zimbra andDisable X-Originating Sender on Zimbra v.8.0.9 1- Take Zimbra backup or VM snapshot before doing any changes 2- Enter the following command to change SMTP Banner: # su – zimbra $ zmlocalconfig -e postfix_smtpd_banner=”yourmailserver.yourdomain.com” 3- Then if you want to change HELO/EHLO names, enter: $ zmprov mcf zimbraMtaMyHostname yourmailserver.yourdomain.com 4- If you want to disable adding X-originating (Client’s internal-LAN IP) to email headers: $ zmprov mcf zimbraSmtpSendAddOriginatingIP FALSE 5- Then restart Zimbra Services: $ zmcontrol restart
1- Telnet to your mail server from Windows cmd or Unix GNU telnet client telnet yourmailserver.yourdomain.com 25 - It firewall allows you to access, doing telnet to port 25 should get your server to greet you with 220 yourmailserver.yourdomain.com 2- In telnet, type following to get HELO response > helo yourmailserver You should get: 250 yourmailserver.yourdomain.com 3- In telnet, type following to get EHLO response ehlo yourmail You should get: 250 yourmailserver.yourdomain.com Rest of EHLO lines according to yoru server config, such as MTA mail size, STARTLS Ref. http://support.commgate.net/index.php?/Knowledgebase/Article/View/229/4/How-to-change-SMTP-Banner,-HELO,EHLO-Greetings-for-Zimbra-and-Disable-X-Originating-Sender-on-Zimbra-v.8.0.9 Взято здесь: http://www.sznote.net/?p=1783 9. Некоторые ограничения отправки/ доставки # Получить действующие на МТА ограничения: [zimbra@mail ~]$ zmprov gacf | grep zimbraMtaRestriction # Запрет пересылки получателю, находящемуся в чужом домене: # Запрет для отправителя, отсутствующего в домене [zimbra@mail ~]$ zmprov mcf +zimbraMtaRestriction reject_sender_login_mismatch # Запрет для не валидного отправителя [zimbra@mail ~]$ zmprov mcf +zimbraMtaRestriction reject_unverified_sender # Запрет отправки несуществующему получателю [zimbra@mail ~]$ zmprov mcf +zimbraMtaRestriction reject_unlisted_recipient Другой вариант: Еще в Zimbra почтовом сервере есть возможность отправить письмо и в поле отправителя подставить любой адрес, сами понимаете это не хорошо. Исправляется это просто редактируем файл main.cf: smtpd_sender_restrictions = reject_sender_login_mismatch, reject_unverified_sender и в /etc/postfix/smtpd_sender_login_maps --- Zimbra: ошибка 504Если не отправляются письма, с сообщением:
host relay.somedomain.com[xx.xx.xx.xx] said: 504 Helo command rejected: need fully-qualified hostname (in reply to RCPT TO command) Значит проблема в том, как представляется postfix Zimbrы при соединении по SMTP. В строке «приветствия» указано краткое имя нашего почтового сервера. Делаем так:
Если не помогло делаем также так:
www.zimbra.com/forums/installation/17754-solved-howto-change-postfix-helo.html Увеличить максимальный размер письма до 42МБ su zimbra zmprov ms `zmhostname` zimbraFileUploadMaxSize 44040192 zmprov ms `zmhostname` zimbraMailContentMaxSize 44040192 zmprov mcf zimbraMtaMaxMessageSize 44040192 postfix reload https://wiki.zimbra.com/wiki/Configuring_maxmessagesize
| |
| Просмотров: 2712 | |
| Всего комментариев: 0 | |
Я предлагаю следующее... как можно заметить, у зимбры практически все правила реджектов проверяются на этапе smtpd_recipient_restrictions, на остальных этапах в основном проверяется домен назначения и прочее проверки, которые практически на 100% не требуют списка исключений. А куда вставляются правила при использовании zmprov mcf +zimbraMtaRestriction 'check_client_access lmdb:/opt/zimbra/conf/postfix_rbl_override вообще не понятно.
Делаем следующее, постараюсь поподробнее, у автора топика следующие правила настроенные через веб морду...
smtpd_recipient_restrictions = reject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unlisted_recipient, reject_invalid_helo_hostname, reject_non_fqdn_sender, reject_unknown_client_hostname, reject_unknown_sender_domain, reject_rbl_client .
reject_non_fqdn_recipient - ни разу не встречал нормальных серверов которые бы отправляли не в fqdn, не требует исключения.
permit_sasl_authenticated, permit_mynetworks - разрешаем доступ для авторизованных пользователей и доверенных сетей, не требует исключения.
reject_unlisted_recipient - если нет пользователя - то и пиьсмо для него нам не нужно, не требует списка исключений
reject_invalid_helo_hostname, reject_non_fqdn_sender, reject_unknown_client_hostname, reject_unknown_sender_domain, reject_rbl_client - в этих правилах необходим список исключений, для исключений rbl и просто неправильно настроенных серваков.
Т.е. надо запихнуть проверку исключений после reject_unlisted_recipient, но до reject_invalid_helo_hostname, чтобы проверки fqdn и проверки на несуществующих пользователей остались, а так же чтобы не блокировались доверенные сети и авторизованные пользователи если в списках исключений будут блокировки. При этом если в списке исключений стоит разрешение для ипа или домена, то он не будет проходить все проверки после reject_invalid_helo_hostname(включительно).
Помимо исключений RBL добавим еще пару плюшек... не помешает... Все операции от пользователя zimbra.
1) создаем /opt/zimbra/conf/sender_access - тут мы будем проверять адрес указанный в поле FROM письма, т.е. фильтрация будет применяться к адресу с которого вам пишут.
[collapse]
Формат следующий:
<домен или адрес> <TAB> <действие REJECT или OK> <TAB> <если запрет - сообщение об ошибке, не обязательно>
Пример:
=============================================
example.ru REJECT Not login in
numbclub.com REJECT Sender blocked by spam-filter
admin@comp.net REJECT Sender blocked by spam-filter
company.ru OK
=============================================
example.ru - это НАШ домен, т.е. тот который у вас зимбре после @, запрещено по следующей причине, в зимбре есть неприятная дыра, можно отправлять письма с нашего домена без авторизации и не из доверенных сетей, т.е. подделать адрес директора и написать например на адрес бухгалтера, бухгалтер даже не заметит... при этом permit_sasl_authenticated и permit_mynetworks стоящие выше в smtpd_recipient_restrictions, позволят авторизованным пользователям и пользователям из доверенных сетей без проблем отправлять письма на ваш домен, т.е. Reject тут только для тех, кто не авторизовался и для левых.
numbclub.com - это к примеру домен спаммера (кстати реальный домен спаммера), можно конечно добавлять в блэклист спаммассасина, но во-первых, спаммассасин жрет много ресурсов, лучше не загружать его лишней работой, во-вторых, если в письмах будут вирусы, письмо будет отклонено уже после smtp сессии антивирусом, соответственно в почтовой очереди появится письмо от MAILER DAEMON, которое будет висеть в очереди несколько дней с неудачными попытками доставки, т.к. спамеры письма не принимают
admin@comp.net - это если вы не хотите получать письма от определенного пользователя, а не от домена в целом.
company.ru OK - это как раз исключит днс проверки, RBL листов и прочее, т.е. если будет идти письма с этого адреса, никакие другие проверки кроме reject_non_fqdn_recipient и reject_unlisted_recipient произведены не будут. Хотим добавить в исключение адрес, пишем сюда с OK.
[/collapse]
2) создаем /opt/zimbra/conf/recipient_access - тут мы будем проверять кому пишут, т.е. фильтрация будет применяться к адресу на который пишут.
[collapse]
Формат следующий:
<ваш домен или адрес из вашего домена> <TAB> <REJECT> <TAB> <сообщение об ошибке, не обязательно>
Пример:
=============================================
all@example.ru REJECT Not login in
user@example.ru REJECT User is disabled
=============================================
all@example.ru - это к примеру адрес рассылки, т.е. если оправить письмо на all@example.ru, это сообщение придет всем вашим сотрудникам компании, в случае если необходимо использовать данный адрес только для внутренней переписки - напишите его в этот файлик. Знаю что можно запрещать и через интерфейс зимбры, в настройках списка рассылки, но в этом случае сервер письмо примет и вроде даже поместить в очередь для всех получателей (а если их 1000), напишет пару логов, лишняя работа, проще резать прямо тут.
Так же если списки рассылки используются для отправки сообщений клиентам, к примеру коммерсанты шлют новости по всем своим клиентам (внешние адреса), то в поле "кому" ваши клиенты увидят адрес вашего списка рассылки и некоторые из них обязательно что нибудь попытаются отправить на этот адрес. В случае если адрес рассылки указан в файле recipient_access, внешний отправитель получит ошибку Not login in. Если внешний доступ будет ограничен средствами зимбры внешний отправитель не получит ничего, что не очень хорошо, потому что он сможет подумать что письмо дошло - а значит письмо пропадет, если же никак не ограничить внешний доступ для списка рассылки, все клиенты которые присутствуют в списке рассылки получать письмо внешнего отправителя.
Внутренние пользователи смогут отправлять почту на данные адреса, см. permit_sasl_authenticated и permit_mynetworks выше.
user@example.ru - если надо заблокировать какого то внутреннего пользователя только от внешних писем, можно написать его тут, пользователь user@example.ru не будет получать внешнюю почту, но будет получать внутреннюю.
Можно создавать и правило с OK, но что то не могу придумать случаев когда это необходимо.
[/collapse]
3) создаем /opt/zimbra/conf/client_access - тут мы будем проверять IP отправителя, если sender_access по каким то причинам не подошло.
[collapse]
Формат следующий:
<IP отправителя,> <TAB> <REJECT или OK> <TAB> <если запрет - сообщение об ошибке, не обязательно>
Пример:
=============================================
XXX.XXX.XXX.XXX REJECT Sender blocked by spam-filter
YYY.YYY.YYY.YYY OK
=============================================
XXX.XXX.XXX.XXX - допустим в примере с sender_access, спам идет не только с numbclub.com, но и с других доменов, но ип у них одинаковый, вместо того чтобы указывать каждый домен по отдельности в sender_access, можно указать тут их общий ип.
YYY.YYY.YYY.YYY - это аналог permit_mynetworks, т.е. добавляя тут ип, вы можно сказать добавляете его в доверенную сеть, другое дело что через интерфейс зимбы добавить 1 ип нельзя, только через консоль, а тут пожайлуйста. Так же можно добавлять списки исключений для RBL, днс проверок. К примеру как случае в sender_access с сервера идут не только адреса с company.ru, но и с других, скажем он большой релей, и чтобы не добавлять все домены в sender_access, можно просто написать тут их общий ип. Я к примеру добавляю судя ип рабочей виртуальной машины, с которой тестирую почтовик через телнет ), чтобы она не проходила днс проверки (доверенная сеть у меня состоит только из 1 ого адреса, адреса самого сервера).
[/collapse]
4) выполняем
postmap /opt/zimbra/conf/sender_access
postmap /opt/zimbra/conf/client_access
postmap /opt/zimbra/conf/recipient_access
Каждый раз когда вы вносите изменения в любой файлик, делайте postmap, для того чтобы изменения применились, перезапускать постфикс или зимбру не надо
5) теперь нам надо впихнуть эти списки фильтрации в postfix, между reject_unlisted_recipient и reject_invalid_helo_hostname. Просто отредактировать /opt/zimbra/postfix/conf/main.cf не вариант, после перезапуска зимбры main.cf откатит все изменения.
Идем сюда /opt/zimbra/conf/zmconfigd/smtpd_recipient_restrictions.cf именно этот файлик отвечает за генерацию smtpd_recipient_restrictions в main.cf постфикса. Ищем там строку reject_unlisted_recipient, ведь именно после него нам и нужно вставить свои списки исключений... вставляем следующее с новой строчки (укажем на наши ранее созданные файлки)..
check_client_access lmdb:/opt/zimbra/conf/client_access
check_sender_access lmdb:/opt/zimbra/conf/sender_access
check_recipient_access lmdb:/opt/zimbra/conf/recipient_access
сохраняем, перезапускаем зимбру
zmcontrol restart
После перзапуска открываем /opt/zimbra/postfix/conf/main.cf , наши правила должны появиться между reject_unlisted_recipient и reject_invalid_helo_hostname , если появились - все ок, можно проверять.
Данный вариант настройки плох только в одном, после обновления зимбы нужно повторить п.5, т.е. настройки при обновлении затираются, но файлики остаются на месте, да и не так уж часто обновляется зимбра.
Так же данный способ точно подходит для 8.5, если у вас другая версия или вы дополнительно делали какие-то изменения в конфигурационных файлах зимбры вручную, не факт что заработает.
Заключение: Вышло на целую статью, потратил час, орфографические ошибки не проверял, если кто то захочет перепосить - я не против.
ссылка