Перейти к содержимому 
Я покажу вам, как Почтовый сервер TLS в Postfix и выбрать сильные наборы шифров, чтобы SMTP-соединения были надежно защищены. Основываясь на проверенных и испытанных параметрах для TLS 1.2/1.3, DANE, MTA-STS и современных пар ключей, я проведу вас шаг за шагом через конфигурацию, тестирование и настройку, чтобы ваши безопасность почты захватывает чисто.
Центральные пункты
- Постфикс Настройте безопасную конфигурацию: Активируйте TLS, ограничьте протоколы, настройте ведение журнала.
- Шифр определить приоритеты: ECDHE + GCM/CHACHA20, применение PFS, блокирование устаревших данных.
- Сертификаты сохранять чистоту: RSA+ECDSA, полная цепочка, сильные изгибы.
- DANE/MTA-STS использовать: Укрепление руководящих принципов и снижение рисков понижения рейтинга.
- Тесты и мониторинг: регулярно проверяйте журналы OpenSSL, сканера TLS, MTA.
SMTP через TLS: что на самом деле защищено
Я защищаю SMTP с помощью STARTTLS, чтобы передача электронной почты не происходила в виде обычного текста. Оппортунистический TLS через smtpd_tls_security_level = may гарантирует, что входящие соединения будут использовать шифрование, как только удаленная станция предложит его. Для исходящих соединений я использую smtp_tls_security_level = dane Проверки политики с поддержкой DNSSEC затрудняют атаки на понижение. Без TLS электронная почта может быть прочитана и подвергнута манипуляциям в пути, что особенно опасно для форм, заказов и учетных данных. При активном TLS значительно снижается риск подслушивания и MITM, а также повышается скорость доставки, поскольку крупные провайдеры положительно оценивают защищенные соединения.
Ключи, сертификаты и протоколы в Postfix
У меня готовы два сертификата: один RSA-сертификат и сертификат ECDSA, чтобы старые и новые MTA были оптимально связаны. Я задал четкие пути в Postfix, например smtpd_tls_cert_file для RSA и smtpd_tls_eccert_file для ECDSA, каждый с соответствующим ключом. Для чистой аутентификации я обращаю внимание на полную цепочку, CN/SAN, который точно соответствует хосту, и кривую, например secp384r1 для ключа ECDSA. Я строго деактивирую старые протоколы, т. е. SSLv2 и SSLv3, чтобы избежать принудительного понижения. Если вы взвешиваете тип сертификата, посмотрите на DV, OV или EV, чтобы вы выбрали правильный уровень уверенности.
Выбор шифра: Приоритеты для TLS 1.2/1.3
Я отдаю предпочтение наборам шифров с PFS, т.е. ECDHE перед DHE, и использовать GCM или CHACHA20-POLY1305. В TLS 1.3 стек освобождает вас от многих унаследованных проблем, в то время как TLS 1.2 по-прежнему требует четкого списка. Небезопасные или слабые комплекты, такие как RC4, Я удаляю 3DES, CAMELLIA, aNULL, eNULL. Для Postfix я использую smtpd_tls_ciphers = high и ограничительный tls_high_cipherlist, чтобы ни один устаревший алгоритм не проскочил. Если заглянуть глубже, то Руководство по шифровым наборам простая и понятная классификация без балласта.
| Версия TLS | Любимые наборы шифров | Статус | Подсказка |
|---|---|---|---|
| TLS 1.3 | TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 | активно | Выбор прочно вошел в протокол, больше никаких проблем с наследием. |
| TLS 1.2 | ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305 | активно | Приоритет - PFS, предпочтение - GCM/CHACHA. |
| Устаревшие | RC4, 3DES, CAMELLIA, AES128-SHA, aNULL/eNULL | заблокировано | Полностью деактивируйте в целях безопасности. |
Postfix: конкретные параметры для файла main.cf
Я задаю четкую конфигурацию, чтобы MTA безопасно разговаривал как с входящими, так и с исходящими сообщениями. Для эфемерного ECDH я использую smtpd_tls_eecdh_grade Я устанавливаю качество кривой и отключаю сжатие, чтобы избежать атак типа CRIME. Сильный файл DH с 4096 битами предотвращает слабые переговоры DHE. Я накладываю жесткие ограничения на протоколы и обеспечиваю высокое качество шифрования, отдавая предпочтение TLS 1.3. На начальном этапе умеренный уровень журнала помогает мне проверять рукопожатия без переполнения журнала.
Активация и политика #
smtpd_tls_security_level = may
smtp_tls_security_level = dane
Сертификаты # (примеры путей)
smtpd_tls_cert_file = /etc/ssl/certs/mail.example.de.cer
smtpd_tls_key_file = /etc/ssl/private/mail.example.de.key
smtpd_tls_eccert_file = /etc/ssl/certs/mail.example.de_ecc.cer
smtpd_tls_eckey_file = /etc/ssl/private/mail.example.de_ecc.key
Протоколы и шифры #
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = high
tls_high_cipherlist = !aNULL:!eNULL:!RC4:!3DES:!CAMELLIA:HIGH:@STRENGTH
tls_ssl_options = NO_COMPRESSION
smtpd_tls_eecdh_grade = ultra
Параметры ЦТ #
smtpd_tls_dh1024_param_file = /etc/postfix/dh_4096.pem
# DNSSEC/DANE (если доступно)
smtp_dns_support_level = dnssec
# Ведение журнала
smtpd_tls_loglevel = 1
Я сохраняю цепочку сертификатов полной, обращаю внимание на правильность прав для частный ключевые файлы и проверьте журналы после перезагрузки. Если TLS 1.2 требуется для устаревших партнеров, я строго придерживаюсь GCM/CHACHA и блокирую все остальное. Для TLS 1.3 я полагаюсь на стандарты стека и избегаю специальных путей, которые усложняют обслуживание. Сшивание OCSP играет роль в SMTP только в том случае, если его обеспечивает вышестоящий прокси, поэтому я проверяю его только для соответствующих настроек. После каждого изменения я проверяю OpenSSL, чтобы выявить побочные эффекты на ранней стадии и убедиться, что шифрование электронной почты последовательно.
Подлинность транспорта с помощью DANE, MTA-STS, SPF, DKIM и DMARC
Я сочетаю TLS с ДЭЙН, публикуя подписанные записи TLSA в соответствии с DNSSEC. Кроме того, я устанавливаю MTA-STS, чтобы удаленные клиенты знали, что мой хост требует TLS и какие MX им следует соблюдать. Для привязки идентификационных данных я подписываю исходящие сообщения с помощью DKIM и безопасную доставку доменов с помощью правил SPF. Наконец, DMARC определяет, как получатели должны реагировать на отклонения, что значительно усложняет подделку. Эти компоненты работают вместе: TLS защищает транспорт, а аутентификация укрепляет отправителя и заметно повышает скорость доставки.
Если производительность является узким местом, я оптимизирую возобновление сеанса, аппаратные возможности и само рукопожатие. Вы можете приступить к практическим приемам с помощью Ускорение рукопожатия TLS, чтобы уменьшить задержку при установлении соединения. Важно: я поддерживаю баланс между выбором шифра и возобновлением соединения, поскольку слабые компромиссы не окупаются с точки зрения безопасности. Быстрое согласование TLS дает значительную экономию, особенно при больших объемах почты. Этот способ Пропускная способность и безопасности в равновесии.
Тестирование, мониторинг и аудит
Я проверяю рукопожатия локально с помощью openssl и проверьте версию протокола, шифр и цепочку сертификатов. Команда openssl s_client -connect mail.example.de:25 -starttls smtp показывает мне в реальном времени, о чем ведет переговоры удаленный сервер. После изменения конфигурации я использую проверка постфикса и посмотрите конкретно на smtpd_tls_loglevel, для выявления моделей ошибок. Внешние сканеры TLS помогают классифицировать публичную видимость, особенно после смены сертификата. Регулярный цикл аудита защищает от постепенного ухудшения, например, если изменение библиотеки влияет на приоритеты шифров.
Частые ошибки в конфигурации и их быстрое устранение
Я часто встречаю устаревшие шифры, такие как AES128-SHA, которые все еще активны и предотвращают PFS. Здесь помогает строгая строка шифра и четкое блокирование LOW/MD5/RC4/3DES. Второй паттерн: отсутствие промежуточных сертификатов, из-за чего удаленные станции не могут проверить цепочку; я добавляю файл пакета и проверяю снова. На таких устройствах, как Synology, я устанавливаю профиль TLS на современный и удаляю устаревшие параметры, чтобы SMTP-сервер говорил на современном языке. В Microsoft Exchange я специально проверяю политики TLS 1.2/1.3, назначение сертификатов на коннектор и любые переопределения шифров в конфигурации хоста, чтобы Рукопожатие-Выбор правильный.
Предварительный просмотр: TLS 1.3, 0-RTT и Post-Quantum
Я предпочитаю TLS 1.3, поскольку рукопожатие короче, а старые опции опущены, что уменьшает площадь атаки. Выбор шифр Я не использую 0-RTT в контексте SMTP, поскольку атаки повторного воспроизведения несут ненужные риски. В будущем я слежу за гибридными постквантовыми процедурами, которые могут найти свое применение в почтовой среде, как только стандартизация и поддержка достигнут зрелости. При этом важно настроить политику и мониторинг таким образом, чтобы новые процедуры можно было интегрировать в дальнейшем без сбоев.
Производительность и скорость доставки с первого взгляда
Я измеряю Латентность рукопожатия TLS и оптимизировать кэши для повторного использования. Возобновление сеанса (билеты/идентификаторы) снижает вычислительную нагрузку и ускоряет повторные соединения между MTA. При отзыве сертификата я полагаюсь на стекируемую информацию на вышестоящем прокси-сервере, если она доступна, чтобы сэкономить дополнительные обращения. Крупные получатели положительно оценивают безопасный транспорт, что повышает скорость доставки, в то время как небезопасные пути увеличивают риск спама и отказов. Благодаря четкой политике TLS, надежным DNS-записям и чистой цепочке подписей я создаю надежную основу для Доставляемость.
Мой график настройки
Я начинаю с получения сертификата от надежного центра сертификации, генерирую ECDSA и RSA и храню оба сертификата на хосте в чистом виде. Затем я настраиваю main.cf с параметрами TLS, установите сильные шифры и деактивируйте старые протоколы. Добавляется свежий DH-файл с 4096 битами, затем следует перезагрузка и первые проверки OpenSSL. Затем я настраиваю DANE, добавляю MTA-STS и проверяю валидность SPF/DKIM/DMARC. Наконец, я запускаю тесты против внешних целей, проверяю журналы во время работы и планирую регулярные аудиты, чтобы Конфигурация остается надежным в долгосрочной перспективе.
Отсутствующие модули: Submission, SMTPS и SNI
Я защищаю не только порт 25, но и порт отправки (587) и, в качестве опции, порт SMTPS (465). Для отправки я применяю шифрование и аутентификацию, чтобы пароли пользователей никогда не отправлялись открытым текстом. В master.cf Я активирую службы и устанавливаю определенные переопределения:
Отправка # (порт 587) с STARTTLS и обязательством авторизации
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
# SMTPS (порт 465) в качестве режима обертки, если требуется
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
Если я обслуживаю несколько почтовых доменов на одном хосте с собственными сертификатами, я использую SNI. Я использую карту SNI, чтобы назначить соответствующий путь сертификата для каждого целевого узла и убедиться, что клиенты MUA также видят правильный сертификат. Так я обеспечиваю разделение клиентов с последовательной идентификацией TLS.
Политики для каждого домена: тонкий контроль
Помимо глобальной политики, я также управляю smtp_tls_policy_maps Исключения и ужесточения для каждого домена получателя. Это позволяет мне постепенно переносить устаревших партнеров или вводить особо строгие требования для конфиденциальных целей.
# main.cf
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# /etc/postfix/tls_policy (примеры записей)
example.org только для датчан
legacy.example.net may
secure.example.com secure
только для дана обеспечивает защиту DANE без зависимости от CA, безопасный требует наличия действительной цепочки ЦС и отказывается от доставки простого текста, май остается оппортунистическим. После изменений я строю карту с postmap и перезагрузите Postfix.
DANE и MTA-STS: конкретная реализация
Для ДЭЙН Я публикую записи TLSA в соответствии с DNSSEC. Я предпочитаю использовать DANE-EE (3 1 1), поскольку он позволяет привязываться к открытому ключу и облегчает смену сертификата с помощью того же ключа. Пример записи TLSA в соответствии с _25._tcp.mail.example.de выглядит следующим образом:
_25._tcp.mail.example.de. IN TLSA 3 1 1
Я генерирую хэш из сертификата ECDSA или RSA и обязательно поворачиваю его до истечения срока действия. Важно, чтобы зона DNS была подписана и чтобы цепочка делегирования была подтверждена без пробелов.
Для MTA-STS Я размещаю файл политики через HTTPS и добавляю запись TXT DNS. Таким образом, я указываю, что удаленные пиры используют TLS и принимаются только с определенным MX. Минималистичный файл политики:
версия: STSv1
режим: принудительный
mx: mail.example.de
max_age: 604800
В DNS добавляется запись TXT в разделе _mta-sts.example.de с текущей версией. По желанию я устанавливаю TLS-RPT через TXT под _smtp._tls.example.de получать отчеты о нарушениях политики. Эта телеметрия помогает мне распознавать сбои, понижение рейтинга и дефектные сертификаты на ранних стадиях.
Ужесточение протоколов, уточнение шифра
Я ужесточаю ограничения на протоколы и обеспечиваю предпочтение серверов. TLS 1.0/1.1 сегодня не нужен; я разрешаю TLS 1.2 и 1.3 только в глубине и на исходящей основе. Для TLS 1.2 я определяю явный положительный список, чтобы исключить смешанные запасы старых шифров:
# Дополнительное усиление (main.cf)
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# Явный список шифров TLS 1.2 (только PFS + AEAD)
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:!aNULL:!eNULL:!MD5:!RC4:!3DES:!CAMELLIA
# Использовать предпочтение сервера
tls_preempt_cipherlist = yes
Я слежу за тем, чтобы предпочтение отдавалось ECDHE, а DHE был лишь запасным вариантом. Я постоянно обновляю свой DH-файл; в TLS 1.3 он не играет роли, но он все еще полезен для редких действий DHE.
Возобновление сеансов и кэши
Чтобы ускорить работу, я активирую кэш сессий для клиента и сервера, чтобы сделать повторные соединения более благоприятными. Нагрузка на процессор и задержка заметно снижаются, особенно при высокой пропускной способности почты:
# Кэш сессий (main.cf)
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_connection_reuse = yes
Я слежу за количеством попаданий в журналы и убеждаюсь, что ни одно из них не является слишком коротким. время_жизни_билета в библиотеке TLS, чтобы замедлить возобновление. Важно: возобновление не должно ослаблять политику; я придерживаюсь тех же требований к шифру.
Сертифицированная компания: Ротация и обслуживание цепи
Я автоматизирую обновление и перезагрузку MTA, чтобы в работе не оставалось просроченных сертификатов. После каждого обновления я проверяю, все ли сертификаты листа и промежуточные сертификаты находятся в пакете. При двойной работе ECDSA/RSA я убеждаюсь, что обе пары вращаются, прежде чем массовое изменение вызовет проблемы у клиентов. Я проверяю путь SNI и отправку отдельно, поскольку MUA могут показывать другие ошибки, чем MTA.
Углубленное протоколирование и диагностика
При возникновении проблем я временно увеличиваю глубину журнала и использую бортовые инструменты для перекрестной проверки:
Целевое протоколирование # (main.cf)
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
С posttls-finger target.example.com Я проверяю, какую политику ожидает удаленный MTA и какие шифры/протоколы согласованы. Я использую postconf -n | grep tls, чтобы видеть только явно заданные параметры TLS; так я могу быстрее найти отклонения от значений по умолчанию. В журналах я ищу такие термины, как нет общего шифра, проверка сертификата не удалась или версия протокола, которые прямо указывают на несоответствие шифра, проблемы с цепочкой или слишком строгие/слабые ограничения протокола.
Обеспечение совместимости без ущерба для безопасности
Я осознанно планирую переходы: я постоянно нахожусь в курсе событий. май, чтобы избежать потери почты с устаревших серверов, но регистрировать доставку в виде обычного текста. Исходящая почта остается строгой (DANE/MTA-STS/secure) и использует smtp_tls_policy_maps для отдельных случаев. Если отдельные партнеры могут управлять только TLS 1.2 с AES-GCM, это приемлемо; я управляю всем, что ниже этого уровня, с помощью согласованных исключений с ограниченным временем выполнения, документирую их и включаю в планирование миграции. Это позволяет поддерживать общий уровень на высоком уровне, не блокируя бизнес-операции.
Стандартные настройки TLS в системе с первого взгляда
Обратите внимание, что Postfix использует системную библиотеку TLS. Обновления OpenSSL/LibreSSL могут изменить приоритеты шифров и поведение TLS 1.3. Поэтому после обновления системы я выборочно проверяю рукопожатия и сравниваю вывод postconf -n с моими целевыми значениями. Набор уровень_совместимости в Postfix помогает поддерживать стабильные значения по умолчанию, но я не полагаюсь на него слепо и документирую явные отклонения в main.cf/master.cf.
Краткий отчет для администраторов
Я хотел бы подчеркнуть, что сильные шифры с PFS, чистые сертификаты и четкие политики необходимы для SMTP решающий. TLS 1.3 избавляет вас от проблем, связанных со старыми версиями, в то время как TLS 1.2 требует дисциплинированного списка шифров. DANE и MTA-STS усиливают транспортный путь, SPF/DKIM/DMARC защищают идентификацию и отчетность. Регулярные тесты и анализ журналов показывают на ранних этапах, есть ли у изменений нежелательные побочные эффекты. С помощью этого руководства вы сможете настроить свой почтовый сервер так, чтобы он был безопасным, производительным и перспективным - без лишних затрат. Риски.
