Безусловно, мы не можем обойти стороной огромную аудиторию сисадминов, по своей или не своей воле выстроивших корпоративный ИТ‐ландшафт на базе продуктов всем известной корпорации Microsoft. Поэтому ниже мы рассмотрим настройку SPF‐ и DKIM‐записей для почтового сервера MS Exchange Server. Должен сказать, что все приведенные здесь настройки были мною протестированы на версии MS Exchange Server начиная с 2013, хотя и не исключены какие‐нибудь приколы с наиболее актуальным сегодня билдом MS Exchange Server 2019 (версия 15.2). Так что внимательно читай changelog’и и документацию ко всем используемым утилитам.
Установка Exchange DKIM Signer
Перед началом всех действий нам понадобится установить специальную утилиту Exchange DKIM Signer.
Для этого мы идем на страничку GitHub тулзы DKIM Signer и скачиваем оттуда файл с названием Source Code. Далее распаковываем загруженный ZIP‐архив в любую временную директорию на диске С:. Обязательно от име‐ ни администратора запускаем PowerShell‐скрипт Exchange Management Shell и переходим в распакованную папку.
Если возникнут ошибки, перед тем как запустить установочный скрипт
.\install.ps1, зададим политику выполнения PowerShell‐скриптов следующей командой:
Set‐ExecutionPolicy Unrestricted
Или еще вариант:
Set‐ExecutionPolicy RemoteSigned
Теперь наконец‐то запускаем сам скрипт установки .\install.ps1 и ждем завершения операции.
Для тех, кто не очень любит работать с консолью, есть вариант графической установки Exchange DKIM Signer. Для этого идем в репозиторий на GitHub и скачиваем там файл с именем Configuration.DkimSigner.zip. Рас‐ паковываем содержимое архива в произвольную папку на C:\ и запускаем из нее исполняемый файл Configuration.DkimSigner.exe, в открывшемся окне выбираем, какую версию будем устанавливать, жмем Install и ждем несколько секунд до завершения операции.
Конфигурирование агента Exchange DKIM Signer
Не закрывая предыдущее окно Exchange DKIM Signer, на вкладке Information нажимаем кнопку Configure.
В открывшемся окне выбираем Exchange DkimSigner и понижаем приоритет до самого низкого, в моем случае это значение 7. Такой приоритет означает, что почтовое сообщение будет обрабатываться этим агентом в последнюю очередь.
Далее переходим на вкладку DKIM Settings и переключаем алгоритм хеширования на RsaSha256. Активируем опции Body Canonicalization, а Header Canonicalization выставляем в значение Simple. Тут же, не закрывая окно, можно настроить заголовки почтовых сообщений, которые будут подписываться. Однако эта настройка для работы не критична, поэтому оставим все как есть по умолчанию.
После всех правок не забываем нажать кнопку Save configuration.
Переходим на вкладку Domain Settings, где удаляем предустановленные домены по умолчанию — example.com и example.org. Нажимаем на кнопку Add, вводим свои значения и заполняем основные поля. Поле Domain Name — это имя нашего почтового домена; например, для адресов типа [email protected] это поле примет значение company.com.
Поле Selector — это произвольная строка, которая добавляется к имени домена. С помощью поля Selector правильно идентифицируется public key в TXT‐записи на DNS‐сервере.
Если взять установленное нами значение из поля Selector и посмотреть на Email Headers отправляемых с сервера писем, то мы увидим тег s=, который имеет значение из поля Selector. Тег d= имеет значение, указывающее на наш почтовый домен. Таким образом сервер получателя понимает, какой именно public key на нашем DNS‐сервере нужно проверять.
На следующем шаге генерируем ключевую пару «открытый — закрытый ключ» (public key и private key). Private key будет храниться строго на сервере, и с его помощью будет подписываться вся исходящая почта. Нажимаем кнопку Generate Key и сохраняем *.xml‐файл в папку keys.
После всех этих действий на выходе должно получиться три файла в папке keys:
- mydomain.net.xml;
- mydomain.net.xml.pub — файл содержит public key, в будущем мы разместим его в TXT‐записи на нашем внешнем DNS‐сервере;
- mydomain.net.xml.pem — файл содержит private key.
После сохранения всех XML‐файлов не забываем нажать Save Domain, иначе изменения не сохранятся.
Далее Exchange DKIM Signer предлагает нам создать TXT‐запись на внешнем DNS‐сервере, который обслуживает наш почтовый домен.
Проверка работоспособности почтового сервера после кон- фигурирования Exchange DKIM Signer
Теперь мы отправим тестовые письма на известные почтовые домены, такие, к примеру, как gmail.com, и посмотрим, как они доходят. Можно воспользоваться сервисом MxToolBox, введя IP‐адрес нашего почтовика и проверив таким образом корректность DKIM‐ и SPF‐записей.
ЗАКЛЮЧЕНИЕ
Сегодня мы рассмотрели доступный каждому админу простой и не требующий заморочек набор штатных средств, помогающих усилить безопасность почтовых серверов под *NIX и серверы Microsoft. Грамотно сконфигурированные DKIM‐, SPF‐ и DMARC‐записи позволят по максимуму снизить поток спама, фейковых рассылок, писем с малварью и в целом хоть как‐то сократить нелегитимный трафик между почтовыми серверами в интернете. Конечно, предложенное решение — это не панацея от всех бед, но это еще один дополнительный барьер на пути злоумышленников, притом еще и бесплатный.
Если нужна помощь в обеспечении безопасности, обращайтесь [email protected]