MS Exchange 2013. Пограничный сервер

Роль EDGE для Exchange 2013

Описание

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

Безопасность

Чёрные и белые списки серверов

Пожалуй, самый простой, но не самый надёжный способ обезопасить себя от писем с «левых» почтовых серверов. При получении письма проверяется, не присутствует ли IP отправителя в одном списков.
IP-адреса в списки можно добавлять вручную через powershell, также существуют сторонние сервисы, которые собирают информацию по доверенным и недоверенным IP-адресам.
Сначала IP ищется в вручную созданных списках и только затем в списках сторонних провайдеров

Чёрные списки
Если сервер в чёрных списках, письма отклоняются  с ошибкой SMTP 550, содержащей ответ с причиной отклонения письма.
Минус в том, что в списки случайно может попасть и нормальный почтовый сервер (например, неправильно сконфигурирован и действует как open-relay).
Поэтому хорошей практикой считается указать в ответной ошибке способ исключить себя из чёрного списка.
Также стоит осторожно подходить к выбору провайдера списков, чтобы случайно не заблокировать большинство нормальных отправителей (например, spam.dnsbl.sorbs.net не стоит выбирать)

Команда для просмотра действующего списка

 

Get-IPBlockListProvider

Белые списки
Если сервер доверенный, пропускаем

Команда для просмотра действующего списка

 

Get-IPAllowListProvider

SPF-записи

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

v= определяет используемую версию SPF. Далее следует перечисление механизмов верификации: в данном случае «a» разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для example.org; «mx» разрешает прием писем, если отправляющий узел указан в одной из MX-записей для example.org. Строка завершается «-all» — указанием того, что сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать. Также может использоваться «~all» — в этом случае письмо, не прошедшее верификацию, не должно быть отклонено, но может быть изучено более тщательно (SoftFail).

 

Просмотреть настройки SPF в Exchange 2013 можно следующей командой
Get-SenderIdConfig

Параметр отвечающий за то, как обрабатывать spf записи при получении писем с других доменов — SpoofedDomainAction

У него может быть 3 разных значения:
StampStatus — Помечает сообщение. Затем метаданные оцениваются агентом фильтра содержимого при вычислении уровня вероятности нежелательной почты. Кроме того, функция «репутация отправителя» использует метаданные сообщения при вычислении уровня репутации отправителя (SRL) сообщения.
Reject — Данное действие отклоняет сообщение и посылает ответ об ошибке 5XX SMTP  отправляющему серверу, который соответствует состоянию идентификации отправителя.
Delete — Данное действие удаляет сообщение без информирования отправляющего сервера об удалении. В действительности компьютеры с установленной ролью пограничного транспортного сервера посылают ложную SMTP-команду «OK» отправляющему серверу, а затем удаляет сообщение. Так как отправляющий сервер предполагает, что сообщение было доставлено, он не будет пытаться отправить сообщение в том же сеансе.

Цифровые подписи DKIM

Описание

Вместо традиционного IP-адреса, для определения отправителя сообщения DKIM добавляет в него цифровую подпись, связанную с именем домена организации. Подпись автоматически проверяется на стороне получателя, после чего, для определения репутации отправителя, применяются «белые списки» и «чёрные списки».
В технологии DomainKeys для аутентификации отправителей используются доменные имена. DomainKeys использует существующую систему доменных имен (DNS) для передачи открытых ключей шифрования.

Требования

  1. Поддержка DKIM почтовым сервером для подписывания отправляемой почты;
  2. Получение пары приватного и публичного ключа;
  3. Занесение в DNS домена необходимых записей о наличии поддержки DKIM.

Настройка DKIM в Exchange 2013

В Exchange 2013 нет нативной поддержки DKIM, однако на GitHub есть проект dkim-exchange, который активно развивается и поддерживает 2013 версию.
Настройка описана в статье на ХабраХабре. Также настройка подробна описана на сайте проекта

Icon

В DNS-зоне должны содержаться две txt-записи:
_domainkey.example.com. TXT «o=~;»
selector._domainkey.example.com. TXT «k=rsa; p={REPLACE_WITH_PUBLIC_KEY_CONTENT}»
Первая запись — это «policy record»
Вторая запись — «public key record»
Поле selector в 2й записи — это селектор DomainKeys. Данное поле позволяет привязать к одному домену несколько DKIM записей для разных нужд (например для разных почтовых серверов). Т.е. его значение может быть любым, совпадающим с значением на сервере. (Например, key1, key2… )
«o=-» means «all e-mails from this domain are signed», and «o=~» means «some e-mails from this domain are signed». Additional fields for test (t), responsible e-mail address (r), and notes (n) may also be included — for example «o=-; n=some notes».

Greylisting

Серые списки (англ. Greylisting) — способ автоматической блокировки спама, основанный на том, что «поведение» программного обеспечения, предназначенного для рассылки спама, отличается от поведения обычных серверов электронной почты. Если почтовый сервер получателя отказывается принять письмо и сообщает о «временной ошибке», сервер отправителя обязан позже повторить попытку. Спамерское программное обеспечение в таких случаях, обычно, не пытается этого делать. ru.wikipedia.org
Нативной поддержки такого функционала в Exchange нет, добавляется сторонним кодом на PowerShell.

Настройка соединителей

Чтобы посмотреть список соединителей, надо в Exchange Management Shell выполнить команду

Get-ReceiveConnector | fl

Чтобы посмотреть список разрешений на соединителе с отображенияем ExtendedRigths, выполняем (на примере соединителя Default internal receive connector EDGE и пользователя NT AUTHORITYAnonymous Logon)

Get-ReceiveConnector "Default internal receive connector EDGE" | Get-ADPermission -user "NT AUTHORITYAnonymous Logon" | ft identity,user,extendedrights,accessrights

Чтобы посмотреть разрешения всех пользователей на всех коннекторах:

Get-ReceiveConnector * | Get-ADPermission | ft identity,user,extendedrights,accessrights

Чтобы удалить неавторизованному пользователю возможность посылать сообщения от имени нашего домена, выполняем:

Get-ReceiveConnector "Default internal receive connector EDGE" | Remove-ADPermission -user "NT AUTHORITYAnonymous Logon" -ExtendedRigths "ms-exch-smtp-accept-authoritative-domain-sender"
 Список возможных разрешений можно посмотреть на Technet

Проблемы

Ошибка неправильной DKIM-подписи

При попытке делать массовые рассылки через php оказалось, что подпись становится некорректной, когда проверяется, например, на Яндексе или Gmail. Это связано с тем, что phpmailer по-умолчанию задавал параметр «Content-Transfer-Encoding: 8bit». Т.е. некоторые данные кодировались 8bit, отправлялось письмо, которое на EDGE подписывалось DKIM, а вот уже принимающий почтовый сервер не читал 8bit, а перекодировал эти данные под себя, из-за чего письмо менялось и dkim оказывался некорректным.
В RFC DKIM сказано, что сообщения всегда должно быть 7bit / quoted-printable encoding

В pommo: lib/phpmailer/class.phpmailer.php  —  public $Encding = ‘quoted-printable’

MS Exchange 2013. Пограничный сервер: 1 комментарий

  1. Хорошая статья для тех кто приступает к шагу "а как защититься от спама"! Понравилось то что описаны все основные инструменты, и после можно ознакомиться с ними подробней для дальнейшей реализации. Жаль что не встретил ее раньше, но все равно кое что почерпнул;)
    Правда edge у нас нету и реализуется пока что все на одном сервере(

Добавить комментарий

Ваш e-mail не будет опубликован.