четверг, 12 марта 2015 г.

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:
example.org. IN TXT "v=spf1 +a +mx -all"
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 AUTHORITY\Anonymous Logon)

Get-ReceiveConnector "Default internal receive connector EDGE" | Get-ADPermission -user "NT AUTHORITY\Anonymous 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 AUTHORITY\Anonymous 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'

1 комментарий:

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

    ОтветитьУдалить