Полное решение почтового сервера с виртуальными доменами и пользователями (Debian Etch, Postfix, Mysql, Dovecot, DSpam, ClamAV, Postgrey, RBL) - Страница 10

VII. Безопасная почта

В идеальном мире наши пользователи могли бы отправлять/получать электронную почту, когда бы они ни находились в сети, из любого места в мире. К сожалению, это невероятно небезопасно… пароли передаются в открытом виде через протоколы SMTP и IMAP, и это означает, что любой, кто захочет, может просто “подслушать” пароль.

Если вашим пользователям не нужен прямой доступ к почтовому решению, то не давайте его им! Нет смысла переживать о настройке безопасной почты, если всем вашим пользователям нужна только веб-почта! Просто сделайте их соединение с сервером веб-почты безопасным и убедитесь, что сервер веб-почты использует безопасное сетевое соединение при взаимодействии с вашими почтовыми серверами. Проблема решена! Если, с другой стороны, вашим пользователям действительно требуется возможность отправлять/получать почту через интернет без использования веб-почты, то это усложняет ситуацию. Не невозможно, просто сложно.

Итак, вот ваша проблема: SMTP и IMAP отправляют пароли в открытом виде. Вы можете заставить их отправлять пароли с использованием MD5, но базовый MD5 может быть взломан. Вы можете заставить их отправлять пароли с использованием MD5CRYPT, но тогда вам придется иметь дело с несколькими реализациями (не говоря уже о том, что не все почтовые клиенты поддерживают пароли MD5). Решение? TLS (Безопасность транспортного уровня). Мы собираемся настроить наше решение для поддержки зашифрованного соединения через интернет. Хотя мы могли бы модифицировать некоторые из наших существующих серверов для обработки этого, нет смысла усложнять их настройки. Мы просто запустим отдельный сервер для обработки всего этого: secure-mail.example.com

NOTE: В исходном сценарии у малого бизнеса было несколько статических IP-адресов. Поскольку это так, мы смогли запустить SMTP+TLS на порту 25, если у вас нет нескольких IP-адресов, то это невозможно. Причина проста: хотя IMAPS (безопасный IMAP) работает на другом порту (993), чем стандартный IMAP (143), SMTP+TLS работает на ТОМ ЖЕ порту, что и SMTP (25). Таким образом, использование брандмауэра для маршрутизации на основе портов позволяет вам запускать отдельные серверы IMAP и IMAPS, но ни один брандмауэр в мире не может маршрутизировать порт 25 на две разные машины. Даже с учетом всего этого, вы всегда можете запустить SMTP+TLS на нестандартном порту… черт возьми, это даже будет более безопасно.

Итак, с учетом всего этого, мы собираемся настроить безопасный почтовый сервер, который использует SMTP+TLS для отправки почты и IMAPS для ее получения.

A. SSL-сертификаты

Самая простая форма шифрования - это наличие простого самоподписанного сертификата на сервере. Это вызовет сообщение о предупреждении, когда клиенты впервые подключатся, но они должны иметь возможность сохранить его для дальнейшего использования. Это не совсем безопасно, так как любой может выполнить атаку “человек посередине”, если вы не сохраните сертификат.

Следующий уровень - использование серверного сертификата, подписанного удостоверяющим центром (CA), либо коммерческим, либо, возможно, внутренним CA компании. Таким образом, серверный сертификат будет доверенным, и если вы теперь получите предупреждение, это может означать, что что-то плохое происходит.

Последнее, но определенно не менее важное - это использование клиентских сертификатов для входа на сервер и использование серверного сертификата для аутентификации сервера для клиентов. Это довольно безопасно, но не поддерживается во всех почтовых клиентах. Thunderbird, среди прочих, поддерживает это.

1. Самоподписанный серверный сертификат

Сначала создайте директории, создайте закрытый ключ, а затем создайте сертификат.

# mkdir -p /etc/ssl/example.com/mailserver/  
# cd /etc/ssl/example.com/mailserver/  
# openssl genrsa 1024 > mail-key.pem  
# chmod 400 mail-key.pem  
# openssl req -new -x509 -nodes -sha1 -days 365 -key mail-key.pem > mail-cert.pem

Обратите внимание, что “Общее имя (например, ВАШЕ имя)” ДОЛЖНО совпадать с именем сервера, которое в данном случае - secure-mail.example.com

2. Сертификат, подписанный CA

Использование сертификата, подписанного реальным CA, ничем не отличается от использования самоподписанного. Это просто еще один шаг в создании пары ключей. Если у вашей компании есть собственный CA, то они должны выдать сертификат для почтового сервера. Поиск в Google по запросу “будь своим собственным CA” даст вам достаточно ответов, чтобы создать один самостоятельно, если у вас есть такая необходимость.