centos7, exim, nginx, php, ssl

Postfix с виртуальными доменами, системой управления, веб-доступом

Thank you for reading this post, don't forget to subscribe!

1. Преднастройка системы

Общие настройки

Зада­ем пра­виль­ное имя сер­ве­ру — это важ­ный шаг, так как боль­шин­ство антис­пам систем выпол­ня­ют про­вер­ки, обра­ща­ясь к сер­ве­ру по име­ни в ожи­да­нии ответа.

vi /etc/hostname

relay.test.ru

* необ­хо­ди­мо ука­зать FQDN-имя, кото­рое будет доступ­но из гло­баль­ной сети. В дан­ном при­ме­ре ука­за­но relay.test.ru.

После вво­дим такую команду:

hostname relay.test.ru

Уста­нав­ли­ва­ем слу­жеб­ные паке­ты (они пона­до­бят­ся в про­цес­се настрой­ки сервера):

yum install ntpdate wget

* ntpdate для воз­мож­но­сти син­хро­ни­зи­ро­вать вре­мя на сер­ве­ре; wget — кли­ент для загруз­ки файлов.

Зада­ем вре­мен­ную зону (в дан­ном при­ме­ре мос­ков­ское время):

cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Син­хро­ни­зи­ру­ем время:

ntpdate ru.pool.ntp.org

Обнов­ля­ем систему:

yum update

Настройка безопасности

Зара­нее откры­ва­ем пор­ты на бранд­мау­э­ре с помо­щью firewalld:

firewall-cmd --permanent --add-port=25/tcp --add-port=80/tcp --add-port=110/tcp --add-port=143/tcp --add-port=443/tcp --add-port=465/tcp --add-port=587/tcp --add-port=993/tcp --add-port=995/tcp

firewall-cmd --reload

* где мы откро­ем сле­ду­ю­щие порты:

  • 25 — стан­дарт­ный SMTP через STARTTLS;
  • 80 — HTTP для пор­та­лов Postfixadmin и Roundcube;
  • 110 — стан­дарт­ный POP3 через STARTTLS;
  • 143 — стан­дарт­ный IMAP через STARTTLS;
  • 443 — защи­щен­ный HTTPS для пор­та­лов Postfixadmin и Roundcube;
  • 465 — защи­щен­ный SMTP через SSL/TLS;
  • 587 — защи­щен­ный SMTP через STARTTLS;
  • 993 — защи­щен­ный IMAP через SSL/TLS;
  • 995 — защи­щен­ный POP3 через SSL/TLS.

В CentOS так­же может исполь­зо­вать­ся ути­ли­та iptables — в таком слу­чае коман­ды будут следующие:

iptables -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 110 -j ACCEPT
iptables -A INPUT -p tcp --dport 143 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 465 -j ACCEPT
iptables -A INPUT -p tcp --dport 587 -j ACCEPT
iptables -A INPUT -p tcp --dport 993 -j ACCEPT
iptables -A INPUT -p tcp --dport 995 -j ACCEPT

После сохра­ня­ем пра­ви­ла любым из опи­сан­ных способов:

Способ 1. iptables-save

Сохра­ня­ем пра­ви­ла в файл:

iptables-save > /etc/iptables.rules

Откры­ва­ем настрой­ки сети:

vi /etc/network/interfaces

и добав­ля­ем строку:

pre-up iptables-restore < /etc/iptables.rules

Способ 2. iptables-persistent

Ста­вим пакет iptables-persistent:

apt-get install iptables-persistent

Для сохра­не­ния пра­вил вво­дим команду:

netfilter-persistent save

Способ 3. service iptables

Рабо­та­ет в ста­рых вер­си­ях Linux:

service iptables save

Или необ­хо­ди­ма уста­нов­ка пакета:

yum install iptables-services

apt-get install iptables-services

* пер­вая коман­да для CentOS, вто­рая — для Ubuntu.

В CentOS

В каче­стве штат­ной про­грам­мы управ­ле­ния бранд­мау­э­ром исполь­зу­ет­ся firewall-cmd.

Если необ­хо­ди­мо поль­зо­вать­ся iptables, уста­нав­ли­ва­ем пакет с утилитой:

yum install iptables-services

Отклю­ча­ем firewalld:

systemctl stop firewalld

systemctl disable firewalld 

Раз­ре­ша­ем и запус­ка­ем iptables:

systemctl enable iptables

systemctl start iptables

В Ubuntu

Для управ­ле­ния бранд­мау­э­ром теперь исполь­зу­ет­ся ufw.

Для рабо­ты с iptables, уста­нав­ли­ва­ем сле­ду­ю­щий пакет:

apt-get install iptables-persistent

Отклю­ча­ем ufw:

ufw disable

2. Настройка веб-сервера: NGINX + PHP + MariaDB

Систе­ма управ­ле­ния PostfixAdmin рабо­та­ет как веб-при­ло­же­ние, раз­ра­бо­тан­ное на PHP, а инфор­ма­цию хра­нит в базе дан­ных. В нашем при­ме­ре будет исполь­зо­вать­ся веб-сер­вер на NGINX, а база дан­ных — MariaDB.

Установка NGINX

Добав­ля­ем репо­зи­то­рий с нуж­ным пакетом:

vi /etc/yum.repos.d/nginx.repo

[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

Уста­нав­ли­ва­ем nginx:

yum install nginx

Раз­ре­ша­ем авто­за­пуск сер­ви­са и запус­ка­ем его:

systemctl enable nginx

systemctl start nginx

Про­ве­ря­ем рабо­то­спо­соб­ность веб-сер­ве­ра, обра­тив­шись к нему в бра­у­зе­ре по IP-адре­су. Если видим заго­ло­вок «Welcome to nginx!», NGINX настро­ен верно.

PHP + PHP-FPM + NGINX

Уста­нав­ли­ва­ем php и php-fpm:

yum install php php-fpm

Настра­и­ва­ем NGINX:

vi /etc/nginx/conf.d/default.conf

[codesyntax lang="php"]

[/codesyntax]

* где /usr/share/nginx/html — ката­лог для раз­ме­ще­ния пор­та­ла управ­ле­ния Postfix.

Настра­и­ва­ем PHP-FPM:

vi /etc/php-fpm.d/www.conf

listen = /var/run/php-fpm/php5-fpm.sock

* здесь мы поме­ня­ли стро­ку 127.0.0.1:9000.

Запус­ка­ем сервисы:

systemctl enable php-fpm

systemctl start php-fpm

systemctl restart nginx

* если в про­цес­се пере­за­пус­ка nginx выско­чит ошиб­ка nginx: [emerg] a duplicate default server, необ­хо­ди­мо най­ти настрой­ку вир­ту­аль­но­го доме­на, в кото­рой так­же ука­за­на опция default_server — опцию нуж­но убрать. Или мож­но само­сто­я­тель­но настро­ить дру­гой вир­ту­аль­ный домен.

Для про­вер­ки, созда­ем индекс­ный файл в дирек­то­рии сай­та со сле­ду­ю­щим содержимым:

vi /usr/share/nginx/html/index.php

<?php phpinfo(); ?>

Откры­ва­ем сайт в бра­у­зе­ре по его IP-адре­су. На открыв­шей­ся стра­ни­це мы долж­ны уви­деть подроб­ную инфор­ма­цию по php.

MariaDB

Уста­нав­ли­ва­ем сер­вер баз дан­ных сле­ду­ю­щей командой:

yum install mariadb mariadb-server

Вклю­ча­ем авто­за­пуск сер­ви­са и запус­ка­ем его:

systemctl enable mariadb

systemctl start mariadb

Зада­ем пароль для поль­зо­ва­те­ля sql root:

mysqladmin -u root password

3. Установка и настройка PostfixAdmin

Уста­нав­ли­ва­ем репо­зи­то­рий epel:

yum install epel-release

Уста­нав­ли­ва­ем допол­ни­тель­ные ком­по­нен­ты для PHP:

yum install php-mysql php-mbstring php-imap

Для при­ме­не­ния уста­нов­лен­ных паке­тов, пере­за­пус­ка­ем обра­бот­чик скриптов:

systemctl restart php-fpm

Ска­чи­ва­ем PostfixAdmin:

wget https://sourceforge.net/projects/postfixadmin/files/latest/download -O postfixadmin.tar.gz

В дирек­то­рии сай­тов nginx созда­ем ката­лог для postfixadmin и рас­па­ко­вы­ва­ем в него архив:

mkdir /usr/share/nginx/html/postfixadmin

tar -C /usr/share/nginx/html/postfixadmin -xvf postfixadmin.tar.gz --strip-components 1

Созда­ем ката­лог templates_c внут­ри пап­ки пор­та­ла (без него не запу­стит­ся установка):

mkdir /usr/share/nginx/html/postfixadmin/templates_c

Зада­ем пра­ва на каталог:

chown -R apache:apache /usr/share/nginx/html/postfixadmin

* несмот­ря на то, что мы исполь­зу­ем веб-сер­вер nginx, php-fpm по умол­ча­нию, запус­ка­ет­ся от поль­зо­ва­те­ля apache.

Созда­ем базу дан­ных postfix и учет­ную запись в mariadb:

mysql -u root -p

CREATE DATABASE postfix DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

* где postfix — имя базы.

GRANT ALL ON postfix.* TO 'postfix'@'localhost' IDENTIFIED BY 'postfix123';

* где postfix — имя учет­ной запи­си; postfix123 — пароль; localhost раз­ре­ша­ет под­клю­че­ние толь­ко с локаль­но­го сервера.

Выхо­дим из команд­ной обо­лоч­ки MariaDB:

\q

Созда­ем кон­фи­гу­ра­ци­он­ный файл postfixadmin:

vi /usr/share/nginx/html/postfixadmin/config.local.php

* в преды­ду­щих вер­си­ях исполь­зо­вал­ся файл config.inc.php. В новых вер­си­ях его не реко­мен­ду­ет­ся пра­вить, а исполь­зо­вать config.local.php, кото­рый пере­опре­де­ля­ет настройки.

И редак­ти­ру­ем следующее:

[codesyntax lang="php"]

[/codesyntax]

 

* где configured гово­рит при­ло­же­нию, что адми­ни­стра­тор закон­чил его кон­фи­гу­ри­ро­ва­ние; default_language — исполь­зу­е­мый язык по умол­ча­нию; database_password — пароль для базы дан­ных, кото­рый мы зада­ли на преды­ду­щем шаге; emailcheck_resolve_domain — зада­ет необ­хо­ди­мость про­вер­ки доме­на при созда­нии ящи­ков и псевдонимов.

Запус­ка­ем бра­у­зер и вво­дим адрес http://<IP-адрес сервера>/postfixadmin/public/setup.php

Нач­нет­ся про­цесс про­вер­ки кон­фи­гу­ра­ции и уста­нов­ки пор­та­ла PostfixAdmin. После ее окон­ча­ния вво­дим два­жды пароль и гене­ри­ру­ем хэш:

После пере­за­груз­ки стра­ни­цы копи­ру­ем хэш:

Откры­ва­ем кон­фи­гу­ра­ци­он­ный файл:

vi /usr/share/nginx/html/postfixadmin/config.local.php

И добав­ля­ем строчку:

…
$CONF['setup_password'] = '7a8e14…c26';

* где '7a8e14…c26' — ско­пи­ро­ван­ный хэш.

После, на той же стра­ни­це, где пока­зан хэш, добав­ля­ем супер­поль­зо­ва­те­ля PostfixAdmin:

* где Setup password — пароль, кото­рый мы вве­ли на преды­ду­щей стра­ни­це; Пароль — новый пароль для созда­ва­е­мой учет­ной записи.

В ито­ге мы уви­дим следующее:

И пере­хо­дим в бра­у­зе­ре на стра­ни­цу http://<IP-адрес сервера>/postfixadmin/public/

Вво­дим логин и пароль для создан­но­го пользователя.

Гото­во.

4. Настройка Postfix

По умол­ча­нию, Postfix уже уста­нов­лен в CentOS 7. Но если встре­тит­ся сер­вер без него, выпол­ним уста­нов­ку про­стой командой:

yum install postfix

Созда­ем учет­ную запись, от кото­рой мы будем рабо­тать с ката­ло­гом вир­ту­аль­ных поч­то­вых ящиков:

groupadd -g 1024 vmail

useradd -d /home/mail -g 1024 -u 1024 vmail -m

* сна­ча­ла мы созда­ем груп­пу vmail и guid 1024, после — поль­зо­ва­те­ля vmail с uid 1024 и домаш­ней дирек­то­ри­ей /home/mail. Обра­ти­те вни­ма­ние, что в неко­то­рых систе­мах иден­ти­фи­ка­тор груп­пы и поль­зо­ва­те­ля 1024 может быть занят. В таком слу­чае необ­хо­ди­мо создать дру­гой, а в дан­ной инструк­ции ниже заме­нить все 1024 на альтернативный.

Теперь откры­ва­ем на редак­ти­ро­ва­ние кон­фи­гу­ра­ци­он­ный файл поч­то­во­го сервера:

vi /etc/postfix/main.cf

И редак­ти­ру­ем сле­ду­ю­щие строки:

myorigin = $mydomain

* дан­ная настрой­ка ука­зы­ва­ет, какой домен под­став­лять отпра­ви­те­лю, если он не ука­зан в заго­лов­ке FROM.

mydestination = localhost.$mydomain, localhost, localhost.localdomain

* ука­зы­ва­ем, для каких доме­нов при­ни­ма­ем вхо­дя­щую почту.

local_recipient_maps = unix:passwd.byname $alias_maps

* ука­зы­ва­ем, отку­да брать спи­сок локаль­ных пользователей.

mynetworks = 127.0.0.0/8

* раз­ре­ша­ем отправ­лять сооб­ще­ния локаль­но­му серверу.

alias_maps = hash:/etc/aliases

* ука­зы­ва­ем, отку­да брать спи­сок алиасов.

inet_interfaces = all

* необ­хо­ди­мо убе­дить­ся, что postfix будет слу­шать на всех необ­хо­ди­мых интер­фей­сах, в дан­ном слу­чае, на всех (all). Так­же мож­но задать вари­ан­ты loopback-only (127.0.0.1) или кон­крет­ный IP-адрес интерфейса.

inet_protocols = all

* дан­ный пара­метр задаст про­то­кол для рабо­ты postfix. В дан­ном при­ме­ре на всех (all). Так­же мож­но задать зна­че­ния ipv4 или ipv6.

Если имя сер­ве­ра отли­ча­ет­ся от име­ни, по кото­ро­му сер­вер будет заре­ги­стри­ро­ван в DNS, зада­ем опцию:

myhostname = mx01.test.ru

Теперь в конец кон­фи­гу­ра­ци­он­но­го фай­ла допи­шем следующее:

[codesyntax lang="php"]

[/codesyntax]

 

* где:

  • virtual_mailbox_base — базо­вый путь хра­не­ния поч­то­вых ящи­ков в систе­ме UNIX.
  • virtual_alias_maps — фор­мат и путь хра­не­ния али­а­сов для вир­ту­аль­ных пользователей.
  • virtual_mailbox_domains — фор­мат и путь хра­не­ния доме­нов вир­ту­аль­ных пользователей.
  • virtual_mailbox_maps — фор­мат и путь хра­не­ния поч­то­вых ящи­ков для вир­ту­аль­ных пользователей.
  • virtual_minimum_uid — с како­го номе­ра при­сва­и­вать иден­ти­фи­ка­то­ры пользователям.
  • virtual_uid_maps — иден­ти­фи­ка­тор поль­зо­ва­те­ля, от кото­ро­го запи­сы­ва­ют­ся сообщения.
  • virtual_gid_maps — иден­ти­фи­ка­тор груп­пы, от кото­рой запи­сы­ва­ют­ся сообщения.
  • virtual_transport — зада­ет достав­щи­ка сообщений.
  • dovecot_destination_recipient_limit — пере­да­ча сооб­ще­ний от Postfix в Dovecot выпол­ня­ет­ся по задан­но­му коли­че­ству (в нашем при­ме­ре, по 1 шт.).
  • smtpd_sasl_auth_enable — раз­ре­ша­ет sasl аутентификацию.
  • smtpd_sasl_exceptions_networks — исклю­че­ние сетей от исполь­зо­ва­ния шифрования.
  • smtpd_sasl_security_options — допол­ни­тель­ные опции настрой­ки sasl.
  • broken_sasl_auth_clients — эту опцию про­пи­сы­ва­ем для кли­ен­тов MS Outlook.
  • smtpd_sasl_type — ука­зы­ва­ет тип аутентификации.
  • smtpd_sasl_path — путь до вре­мен­ных фай­лов обме­на инфор­ма­ци­ей с Dovecot. Ука­зы­ва­ет­ся либо абсо­лют­ный путь, либо отно­си­тель­ный queue_directory (по умол­ча­нию /var/spool/postfix). Ито­го, пол­ный путь — /var/spool/postfix/private/auth.
  • smtpd_tls_cert_file — пол­ный путь до пуб­лич­но­го сертификата.
  • smtpd_tls_key_file — пол­ный путь до при­ват­но­го сертификата.
  • smtpd_use_tls — ука­зы­ва­ет кли­ен­там на нали­чие под­держ­ки TLS.
  • smtpd_tls_auth_only — исполь­зо­вать толь­ко TLS.
  • smtpd_helo_required — тре­бо­вать начи­нать сес­сию с приветствия.

Созда­ем файл с настрой­ка­ми обра­ще­ния к базе с алиасами:

vi /etc/postfix/mysql_virtual_alias_maps.cf

[codesyntax lang="php"]

[/codesyntax]

* где user и password — логин и пароль для под­клю­че­ния к MySQL; hosts — имя сер­ве­ра баз дан­ных (в нашем слу­чае, локаль­ный сер­вер); dbname — имя базы дан­ных; query — шаб­лон запро­са к данным.

Созда­ем файл с инструк­ци­ей полу­че­ния дан­ных по вир­ту­аль­ным доменам:

vi /etc/postfix/mysql_virtual_domains_maps.cf

[codesyntax lang="php"]

[/codesyntax]

И файл с поч­то­вы­ми ящиками:

vi /etc/postfix/mysql_virtual_mailbox_maps.cf

[codesyntax lang="php"]

[/codesyntax]

Откры­ва­ем файл master.cf и допи­сы­ва­ем в самый конец:

vi /etc/postfix/master.cf

[codesyntax lang="php"]

[/codesyntax]

* необ­хо­ди­мо убе­дить­ся, что в содер­жи­мом фай­ла нет дру­гих рас­ком­мен­ти­ро­ван­ных опций для submission, smtps и dovecot (по умол­ча­нию, их нет). В дан­ном слу­чае, мы настро­и­ли рабо­ту postfix на пор­тах 25, 465 и 587. В фай­ле master.cf мы настра­и­ва­ем рабо­ту вспо­мо­га­тель­ных сер­ви­сов для Postfix. Опи­са­ние каж­до­го сер­ви­са начи­на­ет­ся с новой стро­ки без отсту­па. Затем идут настрой­ки для сер­ви­са и пара­мет­ры запус­ка. Для при­ме­ра, рас­смот­рим первую добав­лен­ную строку —
submission   inet  n  -  n  -  -  smtpd:

  • submission — имя сер­ви­са. Воз­мож­но исполь­зо­ва­ние зара­нее опре­де­лен­ных в postfix служб или созда­ние сво­их. В дан­ном при­ме­ре submission для под­клю­че­ния MUA по пор­ту 587 при отправ­ке почты.
  • inet — тип обслу­жи­ва­ния. Воз­мож­ны вари­ан­ты inet (сокет TCP/IP), unix (пото­ко­вый сокет), unix-dgram (сокет дей­та­грам­мы), fifo (име­но­ван­ный канал оче­ре­ди), pass (пото­ко­вый сокет UNIX-домена).
  • пер­вый "n" — явля­ет­ся ли сер­вис част­ным и дол­жен быть огра­ни­чен­ным. Воз­мож­ны вари­ан­ты y или n. Для типа обслу­жи­ва­ния inet может быть толь­ко n.
  • пер­вый "-" — рабо­та­ет ли служ­ба с пра­ва­ми root. Воз­мож­ны вари­ан­ты y, n и -. Про­черк озна­ча­ет непри­ме­ни­мость дан­но­го пара­мет­ра к кон­крет­но­му сервису.
  • вто­рой "n" — долж­на ли служ­ба рабо­тать в окру­же­нии chroot. Воз­мож­ны вари­ан­ты y или n.
  • вто­рой "-" — через какое вре­мя в секун­дах про­бу­дить служ­бу, если она неактивна.
  • тре­тий "-" — мак­си­маль­ное коли­че­ство одно­вре­мен­но выпол­ня­е­мых про­цес­сов, кото­рые может запу­стить дан­ный сервис.
  • smtpd — выпол­ня­е­мая команда.

* после коман­ды идут аргу­мен­ты ее запус­ка. Они могут пере­опре­де­лять пара­мет­ры, задан­ные в main.cf. Каж­дый аргу­мент запи­сы­ва­ет­ся с новой стро­ки и начи­на­ет­ся с двух про­бе­лов. В дан­ном при­ме­ре мы исполь­зу­ем слу­ду­ю­щие аргументы:

  • smtpd_tls_security_level — зада­ет уро­вень без­опас­но­сти с при­ме­не­ни­ем TLS. В дан­ном при­ме­ре may гово­рит о воз­мож­но­сти его использования.
  • smtpd_sasl_auth_enable — раз­ре­ша­ет sasl аутентификацию.
  • smtpd_sasl_type — ука­зы­ва­ет тип аутентификации.
  • smtpd_sasl_path — путь до вре­мен­ных фай­лов обме­на инфор­ма­ци­ей с сер­ве­ром хра­не­ния почты (в нашем слу­чае Dovecot). Ука­зы­ва­ет­ся либо абсо­лют­ный путь, либо отно­си­тель­ный queue_directory.
  • smtpd_sasl_security_options — допол­ни­тель­ные опции настрой­ки sasl.
  • smtpd_sasl_local_domain — доба­вить домен для поль­зо­ва­те­лей, кото­рые про­хо­дят smtp-аутентификацию.
  • syslog_name — пре­фикс назва­ния служ­бы при зане­се­нии ее в систем­ный журнал.
  • smtpd_tls_wrappermode — запус­кать ли служ­бу в нестан­дарт­ном режи­ме (для под­держ­ки TLS).
  • smtpd_client_restrictions — настрой­ки огра­ни­че­ния кли­ент­ских соеди­не­ний. В дан­ном при­ме­ре раз­ре­шить толь­ко авторизованных.

Пере­за­пу­стим postfix:

systemctl restart postfix

5. Настройка Dovecot

Уста­нав­ли­ва­ем Dovecot с ком­по­нен­том для рабо­ты с СУБД:

yum install dovecot dovecot-mysql

Настра­и­ва­ем спо­соб хра­не­ния сообщений:

vi /etc/dovecot/conf.d/10-mail.conf

mail_location = maildir:/home/mail/%d/%u/

* в дан­ном при­ме­ре сооб­ще­ния будут хра­нить­ся в про­дви­ну­том фор­ма­те maildir в ката­ло­ге /home/mail/<почтовый домен>/<логин поль­зо­ва­те­ля>.

Настра­и­ва­ем слу­ша­те­ля для аутентификации:

vi /etc/dovecot/conf.d/10-master.conf

[codesyntax lang="php"]

[/codesyntax]

* в дан­ном при­ме­ре мы настра­и­ва­ем сер­вис для аутен­ти­фи­ка­ции и созда­ем два про­слу­ши­ва­те­ля: /var/spool/postfix/private/auth — для воз­мож­но­сти пост­фик­сом исполь­зо­вать авто­ри­за­цию через Dovecot (обра­ща­ем вни­ма­ние, что /var/spool/postfix/private/auth — это тот же private/auth, кото­рый был про­пи­сан нами в postfix); auth-userdb — сокет для авто­ри­за­ции через dovecot-lda. Опция mode зада­ет пра­ва на сокет, напри­мер, 666 поз­во­лит любо­му поль­зо­ва­те­лю к нему под­клю­чить­ся; user и group зада­ет поль­зо­ва­те­ля и груп­пу вла­дель­цев на сокет.

Настра­и­ва­ем аутен­ти­фи­ка­цию в Dovecot:

vi /etc/dovecot/conf.d/10-auth.conf

[codesyntax lang="php"]

[/codesyntax]

* в дан­ном слу­чае мы про­сто ком­мен­ти­ру­ем обыч­ную аутен­ти­фи­ка­цию и сни­ма­ем ком­мен­та­рий для исполь­зо­ва­ния sql-аутентификации.

Настра­и­ва­ем исполь­зо­ва­ние шифрования:

vi /etc/dovecot/conf.d/10-ssl.conf

[codesyntax lang="php"]

[/codesyntax]

* ssl = required ука­жет dovecot тре­бо­вать от кли­ен­тов исполь­зо­ва­ния шиф­ро­ва­ния; ssl_cert — путь до откры­то­го сер­ти­фи­ка­та (так­же нами ука­зы­вал­ся в postfix); ssl_key — путь к закры­то­му ключу.

Настро­им авто­ма­ти­че­ское созда­ние ката­ло­гов при пер­вом под­клю­че­нии поль­зо­ва­те­ля к ящику:

vi /etc/dovecot/conf.d/15-lda.conf

lda_mailbox_autocreate = yes

Настра­и­ва­ем под­клю­че­ние к нашей базе данных:

vi /etc/dovecot/conf.d/auth-sql.conf.ext

[codesyntax lang="php"]

[/codesyntax]

* в дан­ном при­ме­ре мы ука­за­ли на файл, в кото­ром будут нахо­дить­ся настрой­ки для полу­че­ния поль­зо­ва­те­лей и паро­лей из базы дан­ных. Дан­ная настрой­ка явля­ет­ся настрой­кой по умол­ча­нию и, в боль­шин­стве слу­ча­ев, ее не нуж­но менять без необ­хо­ди­мо­сти ука­зать свой путь.

Созда­ем файл с настрой­ка­ми рабо­ты с mysql:

vi /etc/dovecot/dovecot-sql.conf.ext

[codesyntax lang="php"]

[/codesyntax]

* в дан­ном при­ме­ре мы настро­и­ли запрос на полу­че­ние дан­ных из базы mysql (mariadb). password_query — запрос на полу­че­ние паро­ля из таб­ли­цы mailbox; user_query — запрос на полу­че­ние дан­ных поль­зо­ва­те­ля (домаш­няя поч­то­вая дирек­то­рия, иден­ти­фи­ка­тор 1024 (иден­ти­фи­ка­тор создан­но­го нами ранее поль­зо­ва­те­ля vmail).

И, напо­сле­док, настра­и­ва­ем интер­фейс, на кото­ром будет слу­шать dovecot:

vi /etc/dovecot/dovecot.conf

listen = *

* по умол­ча­нию, dovecot слу­ша­ет так­же на ipv6 (listen = *, ::). Если на сер­ве­ре не исполь­зу­ет­ся 6-я вер­сия про­то­ко­ла TCP/IP, в логах dovecot появят­ся ошибки:
master: Error: service(imap-login): listen(::, 143) failed: Address family not supported by protocol
master: Error: service(imap-login): listen(::, 993) failed: Address family not supported by protocol

Генерируем сертификаты безопасности

Созда­ем ката­лог, в кото­ром раз­ме­стим сертификаты:

mkdir -p /etc/ssl/mail

И сге­не­ри­ру­ем их сле­ду­ю­щей командой:

openssl req -new -x509 -days 1461 -nodes -out /etc/ssl/mail/public.pem -keyout /etc/ssl/mail/private.key -subj "/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=relay.test.ru"

* сер­ти­фи­кат сге­не­ри­ро­ван на 1461 день, клю­чи subj могут быть про­из­воль­ны­ми, CN необ­хо­ди­мо ука­зать в соот­вет­ствии с име­нем сер­ве­ра, по кото­ро­му мы будем под­клю­чать­ся к почте.
* если мы хотим исполь­зо­вать сер­ти­фи­кат, кото­рый будет про­хо­дить все про­вер­ки без­опас­но­сти, его нуж­но купить или запро­сить у Let's Encrypt. (РАССМОТРИМ ПОЛУЧЕНИЕ СЕРТИФИКАТА В САМОМ НИЗУ СТАТЬИ)

Запус­ка­ем dovecot:

systemctl enable dovecot
systemctl start dovecot

6. Создаем первый почтовый ящик и проверяем работу сервера

В бра­у­зе­ре вво­дим в адрес­ной стро­ке путь до Postfixadmin — http://<IP-адрес сервера>/postfixadmin/public/.

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

Пере­хо­дим в Спи­сок доме­нов - Новый домен:

Запол­ня­ем фор­мы и нажи­ма­ем по Доба­вить домен:

Теперь пере­хо­дим в Обзор - Создать ящик:

Вво­дим дан­ные ново­го поль­зо­ва­те­ля и нажи­ма­ем по Создать ящик:

Теперь мож­но под­клю­чить­ся к сер­ве­ру с помо­щью любой поч­то­вой про­грам­мы, напри­мер, Mozilla Thunderbird.

Пара­мет­ры для подключения:

  • Сер­вер: имя сер­ве­ра или его IP-адрес (не жела­тель­но, так как сер­ти­фи­кат выда­ет­ся по домен­но­му имени).
  • IMAP: 143 STARTTLS или 993 SSL/TLS
  • POP3: 110 STARTTLS или 995 SSL/TLS
  • SMTP: 25 STARTTLS или 465 SSL/TLS или 587 STARTTLS

* для кор­рект­ной рабо­ты сер­ве­ра на пор­тах 993, 995, 465 (SSL/TLS) необ­хо­дим пра­виль­ный сер­ти­фи­кат (для наше­го доме­на и выпу­щен­ный дове­рен­ным цен­тром сертификации).

7. Устанавливаем и настраиваем Roundcube Webmail

На офи­ци­аль­ном сай­те захо­дим на стра­ни­цу загруз­ки Roundcube. Смот­рим ссыл­ку на послед­нюю ста­биль­ную вер­сию про­дук­та (LTS):

Исполь­зу­ем ссыл­ку, что­бы загру­зить архив программы:

wget https://github.com/roundcube/roundcubemail/releases/download/1.1.12/roundcubemail-1.1.12-complete.tar.gz

Созда­ем ката­лог, где будут раз­ме­щать­ся фай­лы портала:

mkdir /usr/share/nginx/html/webmail

И рас­па­ко­вы­ва­ем ска­чан­ный архив:

tar -C /usr/share/nginx/html/webmail -xvf roundcubemail-*.tar.gz --strip-components 1

Копи­ру­ем шаб­лон конфига:

cp /usr/share/nginx/html/webmail/config/config.inc.php.sample /usr/share/nginx/html/webmail/config/config.inc.php

И откры­ва­ем его на редактирование:

vi /usr/share/nginx/html/webmail/config/config.inc.php

$config['db_dsnw'] = 'mysql://roundcube:roundcube123@localhost/roundcubemail';
$config['enable_installer'] = true;

* первую стро­ку мы редак­ти­ру­ем, а вто­рую добав­ля­ем. В пер­вой стро­ке roundcube:roundcube123 — логин и пароль для досту­па к базе дан­ных; localhost — сер­вер базы дан­ных; roundcubemail — имя базы дан­ных. Вто­рая стро­ка раз­ре­ша­ет уста­нов­ку портала.

Так­же допи­сы­ва­ем в кон­фи­гу­ра­ци­он­ный файл следующее:

[codesyntax lang="php"]

[/codesyntax]

* настрой­ка $config['create_default_folders'] = true созда­ет пап­ки по умол­ча­нию, если их нет:

  • Drafts — Черновики.
  • Junk — СПАМ.
  • Sent — Отправленные.
  • Trash — Корзина.

* Без дан­ной настрой­ки, если не созда­ва­лись пап­ки дру­гим кли­ен­том, веб-кли­ент будет выда­вать ошиб­ки при пере­се­ще­нии писем, напри­мер, при их удалении.

Зада­ем вла­дель­ца apache на пап­ку портала:

chown -R apache:apache /usr/share/nginx/html/webmail

Созда­ем в MariaDB базу для roundcubemail:

mysql -uroot -p

> CREATE DATABASE roundcubemail DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

> GRANT ALL PRIVILEGES ON roundcubemail.* TO roundcube@localhost IDENTIFIED BY 'roundcube123';

> quit

И загру­жа­ем в создан­ную базу данные:

mysql -uroot -p roundcubemail < /usr/share/nginx/html/webmail/SQL/mysql.initial.sql

Уста­нав­ли­ва­ем ком­по­нен­ты, необ­хо­ди­мые для рабо­ты Roundcube:

yum install php-pear php-mcrypt php-intl php-ldap php-pear-Net-SMTP php-pear-Net-IDNA2 php-pear-Mail-Mime

Настро­им php:

vi /etc/php.ini

date.timezone = "Europe/Moscow"

* в дан­ном при­ме­ре мы зада­ем мос­ков­ское время.

Пере­за­гру­жа­ем php-fpm:

systemctl restart php-fpm

Теперь откры­ва­ем бра­у­зер и пере­хо­дим по адре­су http://<IP-адрес сервера>/webmail/installer/. В самом низу нажи­ма­ем по кноп­ке Next. Если кноп­ка будет неак­тив­на, про­ве­ря­ем, что нет оши­бок (NOT OK).

На сле­ду­ю­щей стра­ни­це про­ве­ря­ем, что все пунк­ты нахо­дят­ся в состо­я­нии OK. Уста­нов­ка выполнена.

Откры­ва­ем кон­фи­гу­ра­ци­он­ный файл roundcube:

vi /usr/share/nginx/html/webmail/config/config.inc.php

Запре­ща­ем уста­нов­ку портала:

$config['enable_installer'] = false;

После уда­ля­ем пап­ку с уста­но­воч­ны­ми скриптами:

\rm -R /usr/share/nginx/html/webmail/installer

И захо­дим в бра­у­зе­ре по адре­су http://<IP-адрес сервера>/webmail/.

8. Защищаемся от вирусов

Анти­ви­рус тре­бу­ет мно­го ресур­сов. Будь­те гото­вы, что после его запус­ка сер­вер нач­нет рабо­тать мед­лен­нее и пона­до­бит­ся доба­вить ресурсы.

Установка и настройка ClamAV

Уста­нав­ли­ва­ем антивирус:

yum install clamav clamsmtp clamav-scanner-systemd clamav-update

Добав­ля­ем в postfix:

vi /etc/postfix/main.cf

content_filter = scan:[127.0.0.1]:10025
receive_override_options = no_address_mappings

* где content_filter ука­зы­ва­ет на при­ло­же­ние, кото­рое будет ска­ни­ро­вать сооб­ще­ния; receive_override_options поз­во­ля­ет уви­деть ори­ги­наль­ные email адре­са писем с вирусами.

Теперь редак­ти­ру­ем master.cf:

vi /etc/postfix/master.cf

Допи­сы­ва­ем следующее:

[codesyntax lang="php"]

[/codesyntax]

* итак, дан­ной настрой­кой мы созда­дим два вспо­мо­га­тель­ных сер­ви­са scan и 127.0.0.1:10026 (сер­вис без име­ни, он про­сто будет слу­шать на пор­ту 10026 — это порт по умол­ча­нию, на кото­рый отправ­ля­ет сооб­ще­ние анти­ви­рус­ная про­грам­ма clam после выпол­не­ния про­вер­ки). Так­же, мы исполь­зу­ем сле­ду­ю­щие опции:

  • smtp_send_xforward_command — пере­да­вать ли в ска­ни­ро­ва­ние сооб­ще­ние с исход­ны­ми име­нем кли­ен­та и IP-адре­сом. В дан­ном при­ме­ре, да.
  • smtp_enforce_tls — тре­бо­вать ли TLS.
  • content_filter — при­ло­же­ние для ска­ни­ро­ва­ния. В дан­ном при­ме­ре ска­ни­ро­ва­ние отключено.
  • receive_override_options пере­опре­де­ля­ет опции в main.cf. В нашем слу­чае, no_unknown_recipient_checks отклю­ча­ет попыт­ки выяс­нить, явля­ет­ся ли полу­ча­тель неиз­вест­ным; no_header_body_checks отклю­ча­ет про­вер­ки заго­лов­ков и тала писем.
  • пустые зна­че­ния для smtpd_helo_restrictions, smtpd_client_restrictions, smtpd_sender_restrictions отклю­ча­ют огра­ни­че­ния для дан­ных опций.
  • smtpd_recipient_restrictions — кон­тро­ли­ру­ет ответ Postfix на SMTP-коман­ду RCPT TO. Здесь мы раз­ре­ша­ем толь­ко соеди­не­ния от узлов, пере­чис­лен­ных в mynetworks.
  • mynetworks_style=host ука­зы­ва­ет postfix, что он дол­жен пере­сы­лать почту толь­ко с локаль­но­го компьютера.
  • smtpd_authorized_xforward_hosts ука­жет, какие уда­лен­ные кли­ен­ты могут исполь­зо­вать XFORWARD. В дан­ном слу­чае локаль­ный компьютер.

Кон­фи­гу­ри­ру­ем clamsmtpd:

vi /etc/clamsmtpd.conf

ClamAddress: /tmp/clamd.sock

* где ClamAddress ука­зы­ва­ем на путь к сокет­но­му фай­лу — он дол­жен сов­па­дать с путем к LocalSocket в кон­фи­гу­ра­ци­он­ном фай­ле для clamscan;

Редак­ти­ру­ем кон­фи­гу­ра­ци­он­ный файл для clamscan:

vi /etc/clamd.d/scan.conf

[codesyntax lang="php"]

[/codesyntax]

* где #Example — заком­мен­ти­ро­ван­ная Example, кото­рая не поз­во­лит запу­стить ска­нер, пока ее не уда­лить или заком­мен­ти­ро­вать;LocalSocket — путь до сокет­но­го фай­ла для вза­и­мо­дей­ствия с clamsmtp; User — поль­зо­ва­тель, от кото­ро­го будет запус­кать­ся clamd.

Обнов­ля­ем анти­ви­рус­ную базу:

freshclam

Теперь раз­ре­ша­ем запуск антивируса:

systemctl enable clamsmtpd
systemctl enable clamd@scan

Запус­ка­ем clamscan:

systemctl start clamd@scan

* запуск может занять неко­то­рое вре­мя. Если мы полу­чим ошиб­ку Job for clamd.service failed because timeout was exceeded, пере­хо­дим к ее решению.(оно ниже, пролистай)

И после запус­ка­ем clamsmtpd:

systemctl start clamsmtpd

И так­же пере­за­пус­ка­ем postfix:

systemctl restart postfix

Настройка обновлений антивируса

Для настрой­ки авто­ма­ти­че­ско­го обнов­ле­ния, редак­ти­ру­ем cron:

crontab -e

15 3 * * * /bin/freshclam

* в дан­ном при­ме­ре, каж­дый день в 03:15 будет запус­кать­ся про­цесс обнов­ле­ния clamav.

Проверка

Для про­вер­ки отправ­ля­ем сооб­ще­ние со сле­ду­ю­щим содержимым:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Пись­мо не долж­но дой­ти, а в логе долж­ны уви­дет строку:

Mar 22 15:50:03 mx01 postfix/smtp[6189]: B5BEDCAF3E0: to=<test01@test.local>, relay=127.0.0.1[127.0.0.1]:10025, delay=0.1, delays=0.01/0/0.04/0.04, dsn=2.0.0, status=sent (250 Virus Detected; Discarded Email)

9. Боремся со СПАМом

Проверка контента с помощью Spamassassin

Уста­нав­ли­ва­ем spamassassin:

yum install spamassassin

Редак­ти­ру­ем master.cf:

vi /etc/postfix/master.cf

Для smtp добав­ля­ем опцию фильтра:

[codesyntax lang="php"]

[/codesyntax]

* в дан­ном слу­чае мы доба­вим к сер­ви­су postfix smtp допол­ни­тель­ную опцию content_filter, кото­рая отве­ча­ет за запуск филь­тра­ции кон­тен­та; spamassassin ука­зы­ва­ет на имя сер­ви­са, кото­рый будет запус­кать­ся для фильтрации.

И доба­вить сам сер­вис для фильтра:

[codesyntax lang="php"]

[/codesyntax]

* spamassassin — добав­ля­е­мый сер­вис филь­тра­ции; /usr/bin/spamc — путь до испол­ня­е­мо­го фай­ла спа­мас­са­си­на; spamd — учет­ная запись, от кото­рой запуч­ка­ет­ся spamassassin.

Созда­ем учет­ную запись spamd:

useradd spamd

Обнов­ля­ем spamassassin:

sa-update --nogpg --verbose

Раз­ре­ша­ем его запуск и стар­ту­ем сервис:

systemctl enable spamassassin

systemctl start spamassassin

Пере­за­пус­ка­ем postfix:

systemctl restart postfix

Для авто­ма­ти­че­ско­го обнов­ле­ния доба­вим в cron следующее:

crontab -e

30 3 * * * /bin/sa-update

* обнов­ле­ние будет про­ис­хо­дить каж­дый день в 03:30.

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

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

В ито­ге долж­но прий­ти пись­мо с мет­кой в теме [SPAM], а в логах мы увидим:

… spamd: identified spam (999.0/5.0) for spamd:1025 in 0.2 seconds, 695 bytes.
… spamd: result: Y 999 - ALL_TRUSTED,GTUBE scantime=0.2,size=695,user=spamd,uid=1025,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=57254,mid=<20190328105822.3875FCAFD47@mx01.test.local>,autolearn=no autolearn_force=no

Исходящие письма

Мы настро­и­ли антис­пам фильтр для smtp-соеди­не­ния. В основ­ном, он будет отра­ба­ты­вать для вхо­дя­щей почты. Если нам необ­хо­ди­мо так­же про­ве­рять исхо­дя­щую почту, в master.cf добав­ля­ем content_filter для smtps и submission:

vi /etc/postfix/master.cf

[codesyntax lang="php"]

[/codesyntax]

Пере­за­пус­ка­ем postfix:

systemctl restart postfix

Пересылка СПАМа на другой ящик

Все пись­ма со спа­мом будут отправ­лять­ся в ящик поль­зо­ва­те­ля с помет­кой в теме [SPAM]. Если мы хотим пере­на­прав­лять все подоб­ные сооб­ще­ния на спе­ци­аль­ный ящик, то необ­хо­ди­мо настро­ить обра­бот­ку заго­лов­ков с пере­на­прав­ле­ни­ем сообщений.

Откры­ва­ем кон­фи­гу­ра­ци­он­ный файл Postfix:

vi /etc/postfix/main.cf

Про­ве­ря­ем нали­чие строки:

header_checks = regexp:/etc/postfix/header_checks

… и если ее нет, то добавляем.

Откры­ва­ем на редак­ти­ро­ва­ние файл:

vi /etc/postfix/header_checks

И добав­ля­ем строку:

/^SUBJECT:\s+\[SPAM\]/ REDIRECT spam@test.ru

Про­ве­рим, что мы все сде­ла­ли правильно:

postmap -q "SUBJECT: [SPAM]" regexp:/etc/postfix/header_checks

Мы долж­ны уви­деть что-то на подобие:

REDIRECT spam@test.ru

Пере­за­пус­ка­ем Postfix:

systemctl restart postfix

Антиспам средствами Postfix

В MTA Postfix встро­ен свой меха­низм про­вер­ки заго­лов­ков вхо­дя­щих сооб­ще­ний. Пра­ви­ла раз­ме­ща­ют­ся в 7 сек­ций, обра­бот­ка кото­рых выпол­ня­ет­ся в сле­ду­ю­щем порядке:

client -> helo -> sender -> relay -> recipient -> data -> end_of_data

Что­бы луч­ше понять прин­цип, мы долж­ны знать SMTP-коман­ды при выпол­не­нии отправ­ки почты. И так, поря­док, следующий:

  1. Соеди­не­ние с сервером.
  2. Коман­да HELO. При­вет­ствие, в кото­ром отпра­ви­тель назы­ва­ет свое имя, по кото­ро­му мож­но про­ве­рить, соот­вет­ству­ет ли оно пра­ви­лам име­но­ва­ния и сво­е­му IP-адресу.
  3. MAIL FROM — ука­зы­ва­ет адрес отпра­ви­те­ля. Выпол­ня­ет­ся для sender и relay.
  4. RCPT TO — кому отправ­ля­ем письмо.
  5. DATA — коман­да сооб­ща­ет о готов­но­сти отпра­вить пись­мо с заго­лов­ка­ми и текстом.
  6. END-OF-DATA — отправ­ка письма.

И так, для настрой­ки антис­па­ма в кон­фи­гу­ра­ци­он­ный файл main.cf добавляем:

vi /etc/postfix/main.cf

[codesyntax lang="php"]

[/codesyntax]

* где параметры:

  1. smtpd_client_restrictions — настрой­ки огра­ни­че­ний при осу­ществ­ле­нии кли­ент­ских соеди­не­ний с поч­то­вым сервером.
  2. smtpd_helo_restrictions — огра­ни­че­ния в кон­тек­сте кли­ент­ской коман­ды HELO.
  3. smtpd_sender_restrictions — огра­ни­че­ния будут при­ме­нять­ся во вре­мя выпол­не­ния кли­ент­ской коман­ды MAIL FROM.
  4. smtpd_relay_restrictions — огра­ни­че­ния пере­сыл­ки почты в кон­тек­сте кли­ент­ской коман­ды RCPT TO.
  5. smtpd_recipient_restrictions — огра­ни­че­ния в кон­тек­сте кли­ент­ской коман­ды RCPT TO после пере­сыл­ки (smtpd_relay_restrictions).
  6. smtpd_data_restrictions — огра­ни­че­ния будут при­ме­нять­ся во вре­мя выпол­не­ния коман­ды DATA.
  7. smtpd_end_of_data_restrictions — огра­ни­че­ния во вре­ся выпол­не­ния коман­ды END-OF-DATA.

… и зна­че­ния для них:

  • permit_mynetworks — раз­ре­ша­ет все адре­са, пере­чис­лен­ные в настрой­ке mynetworks.
  • permit_sasl_authenticated — раз­ре­ша­ет запро­сы всех успеш­но авто­ри­зо­ван­ных клиентов.
  • reject_unauth_pipelining — запре­ща­ет отправ­ку писем, кото­рые отправ­ля­ют­ся зара­нее (про­пус­кая пра­виль­ную цепоч­ку сес­сии SMTP).
  • reject_non_fqdn_sender — откло­нить соеди­не­ние, если адрес отпра­ви­те­ля ука­зан непра­виль­но (соглас­но RFC).
  • reject_unknown_sender_domain — запре­ща­ет запрос, если Postfix не явля­ет­ся конеч­ным пунк­том назна­че­ния для адре­са отпра­ви­те­ля, а домен MAIL FROM не име­ет 1) DNS-запи­си MX и DNS-запи­си A или 2) иска­жен­ной MX-запи­си, такой как запись с MX-име­нем хоста нуле­вой длины.
  • reject_non_fqdn_recipient — запре­тить соеди­не­ние, если адрес полу­ча­те­ля ука­зан непра­виль­но (соглас­но RFC).
  • reject_unauth_destination — откло­нить соеди­не­ние, если пись­мо не пере­сы­ла­ет­ся соглас­но пра­ви­лу relay_domains или сер­вер не явля­ет­ся адре­сом назна­че­ния. Дру­ги­ми сло­ва­ми, запре­ща­ет исполь­зо­ва­ние наше­го сер­ве­ра в каче­стве open relay.
  • reject_unknown_recipient_domain — откло­нить запрос, если Postfix не явля­ет­ся конеч­ным пунк­том назна­че­ния для доме­на полу­ча­те­ля, а домен RCPT TO не име­ет 1) DNS-запи­си MX и DNS-запи­си A или 2) невер­но сфор­ми­ро­ван­ной MX-запи­си, такой как запись с име­нем хоста MX нуле­вой длины.
  • reject_unverified_recipient — откло­нить запрос, если извест­но, что поч­та на адрес RCPT TO откло­ня­ет­ся или когда адрес полу­ча­те­ля не доступен. 
  • permit — раз­ре­ша­ет соеди­не­ние. Ста­вим в конец каж­до­го бло­ка огра­ни­че­ний (если огра­ни­че­ния не сра­бо­та­ли, то разрешаем).

* это более или менее мяг­кие пра­ви­ла. Их мож­но исполь­зо­вать пер­вое вре­мя, пока тести­ру­ем сервер.

Для уси­ле­ния защи­ты добавляем:

[codesyntax lang="php"]

[/codesyntax]

* где:

  • reject_unknown_client_hostname — про­ве­ря­ет нали­чие PRT-запи­си отпра­ви­те­ля и нали­чие рабо­чей А-запи­си в соот­вет­ствие PTR.
  • reject_invalid_helo_hostname — про­ве­ря­ет син­так­сис HELO-приветствия.
  • reject_non_fqdn_helo_hostname — тре­бу­ет пра­виль­но­го FQDN-име­ни во вре­мя HELO-приветствия.
  • reject_unknown_helo_hostname — запре­ща­ет пред­став­лять­ся име­на­ми, для кото­рых нет А-запи­си или MX.
  • reject_rbl_client — про­ве­ря­ет нали­чие отпра­ви­те­ля в чер­ных списках.

* более подроб­ное опи­са­ние опций для защи­ты мож­но най­ти на стра­ни­це postfix.org/postconf.5.html.

После вне­се­ния всех пра­вок, необ­хо­ди­ма пере­за­груз­ка Postfix:

systemctl restart postfix

10. Отправка почты наружу

Для отправ­ки почты на дру­гие поч­то­вые сер­ве­ры необ­хо­ди­мо пра­виль­но скон­фи­гу­ри­ро­вать сер­вер, что­бы пись­ма не попа­да­ли в СПАМ. Что­бы это сде­лать, выпол­ня­ем инструк­ции ниже.

Настройки DNS для сервера

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

1. rDNS. Обрат­ная зона исполь­зу­ет­ся для про­вер­ки соот­вет­ствия име­ни сер­ве­ра в при­вет­ствии с име­нем, кото­рое воз­вра­ща­ет NS сер­вер при запро­се по PTR-записи.

И так, для созда­ния запи­си в обрат­ной зоне, необ­хо­ди­мо напи­сать пись­мо Интер­нет про­вай­де­ру, к сети кото­ро­го под­клю­чен сер­вер или хосте­ру, если поч­то­вый сер­вер настро­ен на VPS. IP-адрес наше­го сер­ве­ра дол­жен вести на имя, кото­рым при­вет­ству­ет­ся наш postfix — мож­но посмот­реть командой:

postconf -n smtpd_banner

Если мы полу­чим пустой ответ, то вводим:

postconf -n myhostname

2. А-запись. Так­же необ­хо­ди­мо, что­бы имя сер­ве­ра, кото­рым пред­став­ля­ет­ся поч­то­вый сер­вер раз­ре­ша­лось в IP-адрес.

Для это­го захо­дим в кон­соль управ­ле­ния зоной наше­го доме­на и созда­ем запись типа А для сопо­став­ле­ния име­ни сер­ве­ра с IP-адре­сом, на кото­ром слу­ша­ет запро­сы дан­ный сервер.

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

Для каж­до­го доме­на, для кото­ро­го будем отправ­лять почту созда­ем записи:

  1. SPF.
  2. DMARC.

Настройка DKIM

DKIM настра­и­ва­ет­ся на сер­ве­ре, а для каж­до­го доме­на созда­ет­ся спе­ци­аль­ная запись в DNS.

1. Установка OpenDKIM

Для нача­ла, уста­нав­ли­ва­ем пакет OpenDKIM. Он выпол­ня­ет опе­ра­ции шиф­ро­ва­ния заго­лов­ков для DKIM, а так­же содер­жит набор ути­лит для фор­ми­ро­ва­ния ключей.

Для его уста­нов­ки вво­дим следующее.

yum install opendkim opendkim-tools

2. Настройка OpenDKIM и Postfix

OpenDKIM

Пере­но­сим ста­рый кон­фи­гу­ра­ци­он­ный файл opendkim и созда­ем новый.

mv /etc/opendkim.conf /etc/backup.opendkim.conf

vi /etc/opendkim.conf

И при­во­дим его к сле­ду­ю­ще­му виду:

[codesyntax lang="php"]

[/codesyntax]

 

* все пара­мет­ры мож­но оста­вить, как в дан­ном при­ме­ре, за исклю­че­ни­ем Socket — мож­но ука­зать любой дру­гой порт, вме­сто 12301.

Созда­ем файл дове­рен­ных узлов. В него пока вой­дут имя локаль­но­го хоста (localhost) и его IP-адрес, кото­рые будут при­ня­ты, как дове­рен­ные и подписаны:

vi /etc/opendkim/TrustedHosts

И вно­сим следующее:

127.0.0.1
localhost

* в дан­ный файл мы зано­сим все IP-адре­са и сети поч­то­вых сер­ве­ров, кото­рые могут исполь­зо­вать наш сер­вер как поч­то­вый релей. Таким обра­зом, если в вашей систе­ме исполь­зу­ет­ся подоб­ная кон­фи­гу­ра­ция, в файл TrustedHosts мы долж­ны доба­вить адре­са дан­ных поч­то­вых серверов.

Откры­ва­ем файл /etc/default/opendkim:

vi /etc/default/opendkim

… его либо не долж­но быть, либо он дол­жен быть пустой, либо про­ве­ря­ем стро­ку с настрой­кой SOCKET и при­во­дим ее к виду:

SOCKET=inet:12301@localhost

Запус­ка­ем служ­бу opendkim.

systemctl enable opendkim
systemctl start opendkim

Postfix

Откры­ва­ем кон­фи­гу­ра­ци­он­ный файл.

vi /etc/postfix/main.cf

Добав­ля­ем или редактируем:

[codesyntax lang="php"]

[/codesyntax]

 

* если smtpd_milters и non_smtpd_milters при­сут­ству­ют в кон­фи­гу­ра­ци­он­ном фай­ле, то при­ве­ден­ные в дан­ном при­ме­ре зна­че­ния нуж­но допи­сать к имеющимся.
** 12301 — порт рабо­ты opendkim, кото­рый был задан в opendkim.conf.

Пере­за­пус­ка­ем Postfix:

service postfix restart

или:

systemctl restart postfix

3. Создание сертификата и настройка домена

Для созда­ния сер­ти­фи­ка­та мож­но вос­поль­зо­вать­ся бес­плат­ным онлайн инстру­мен­том на сай­те dkimcore.org. Одна­ко, в дан­ном при­ме­ре, мы вос­поль­зу­ем­ся opendkim-genkey и сфор­ми­ру­ем его само­сто­я­тель­но. Мы будем рабо­тать с доме­ном test.ru (Вам необ­хо­ди­мо его заме­нить своим).

И так, созда­ем ката­лог для раз­ме­ще­ния клю­чей домена:

mkdir -p /etc/opendkim/test.ru

И гене­ри­ру­ем их сле­ду­ю­щей командой:

opendkim-genkey -D /etc/opendkim/test.ru/ --domain test.ru --selector relay

* где test.ru — домен, с кото­ро­го будет отправ­лять­ся поч­та: relay — имя селек­то­ра (селек­тор — это стро­ко­вый иден­ти­фи­ка­тор, он может быть любым).

В пап­ке /etc/opendkim/test.ru долж­но появить­ся два фай­ла с рас­ши­ре­ни­я­ми .private и .txt. Пер­вый — закры­тый ключ (хра­ним его у себя на сер­ве­ре), вто­рой — гото­вая txt-запись для DNS.

Зада­ем груп­пу вла­дель­ца opendkim для создан­ных ключей:

chown :opendkim /etc/opendkim/test.ru/*

Если систе­ма выдаст ошиб­ку, что груп­пы opendkim не суще­ству­ет (chown: opendkim: illegal group name), необ­хо­ди­мо сна­ча­ла создать учет­ную запись.

Зада­ем пра­ва для груп­пы владельца:

chmod g+rw /etc/opendkim/test.ru/*

Созда­дим поль­зо­ва­те­ля opendkim.

useradd opendkim -m -s /sbin/nologin

После раз­ре­ша­ем чте­ние груп­пе владельцу:

chmod g+r /etc/opendkim/test.ru/*

Откры­ва­ем создан­ный нами ранее TrustedHosts:

vi /etc/opendkim/TrustedHosts

И доба­вим следующее:

…
*.test.ru

* где test.ru — поч­то­вый домен.

Созда­ем таб­ли­цу KeyTable. В ней хра­нит­ся спи­сок соот­вет­ствий меж­ду селек­то­ра­ми, доме­на­ми и фай­ла­ми с закры­ты­ми клю­ча­ми. Фор­мат записей:
<селектор>._domainkey.<домен> <домен>:<селектор>:<путь к закры­то­му ключу>

vi /etc/opendkim/KeyTable

И в соот­вет­ствии с фор­ма­том при­во­дим его к нуж­но­му виду:

relay._domainkey.test.ru test.ru:relay:/etc/opendkim/test.ru/relay.private

И напо­сле­док, созда­ем SigningTable. В дан­ной таб­ли­це хра­нят­ся соот­вет­ствия меж­ду опре­де­лен­ны­ми email-адре­са­ми и запи­ся­ми в KeyTable.

vi /etc/opendkim/SigningTable

И при­во­дим к тако­му виду:

*@test.ru relay._domainkey.test.ru

4. Настройка DNS

Смот­рим содер­жи­мое фай­ла txt, кото­рый был сфор­ми­ро­ван при гене­ри­ро­ва­нии сер­ти­фи­ка­та для домена:

cat /etc/opendkim/test.ru/relay.txt

* где test.ru — домен, для кото­ро­го про­из­во­ди­лась настройка.

И исполь­зуя дан­ное содер­жи­мое, в пане­ли управ­ле­ния нашим DNS созда­ем TXT-запись сле­ду­ю­ще­го формата:

relay._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqG…rhyaj8OcbwIDAQAB"

* где relay — назва­ние наше­го селек­то­ра MIGfMA0GCSqG…rhyaj8OcbwIDAQAB — сокра­щен­ная запись откры­то­го клю­ча (она длиннее).

Дополнительные необязательные записи

_domainkey IN TXT "o=~; r=postmaster@test.ru"

* где o=~ озна­ча­ет, что не все сооб­ще­ния под­пи­сы­ва­ют­ся для доме­на (o=- — гово­рит, что все пись­ма исполь­зу­ют DKIM).

_adsp._domainkey IN TXT "dkim=all"

* all запре­ща­ет при­ни­мать пись­ма от доме­на без циф­ро­вой под­пи­си. Дру­гие вари­ан­ты: discardable — бло­ки­ро­вать сооб­ще­ния на сто­роне полу­ча­те­ля, unknown — по умол­ча­нию (такую запись созда­вать не обязательно).

5. Проверка

Отправляем письмо

Отправ­ля­ем элек­трон­ное сооб­ще­ние на раз­лич­ные поч­то­вые систе­мы — mail.ru, gmail.com, yandex.ru.

Спо­со­бов отправ­ки несколь­ко, напри­мер, мож­но выпол­нить сле­ду­ю­щие команды.

yum install mailx

* дан­ная коман­да уста­но­вит ути­ли­ту для отправ­ки почты из команд­ной стро­ки, если ее нет. 

echo "Test DKIM" | mail -s "Testing DKIM" -S smtp="localhost:25" -S from="postmaster@test.ru" -S return-path="postmaster@test.ru" master@test.ru

* где postmaster@test.ru — поч­то­вый ящик, от кото­ро­го отправ­ля­ет­ся пись­мо (напом­ню, в дан­ном при­ме­ре под­пись созда­ет­ся для доме­на test.ru), master@test.ru — дол­жен быть Ваш адрес почты, на кото­рый при­дет письмо.

Вто­рой спо­соб — настро­ить поч­то­вый кли­ент, кото­рый будет отправ­лять почту через настро­ен­ный нами сервер.

Проверяем заголовки

Откры­ва­ем наше пись­мо и смот­рим заго­лов­ки (в mail.ru: Еще - Слу­жеб­ные заго­лов­ки).

Сре­ди них мы долж­ны уви­деть сле­ду­ю­щую строчку:

dkim=pass header.d=test.ru

Про­вер­ка доме­на на базе DKIM настро­е­на успешно.

Добавление новых записей dkim

Раз­бе­рем про­цесс добав­ле­ния допол­ни­тель­ных запи­сей dkim. Что­бы рабо­тать было удоб­нее и быст­рее, в кон­со­ли созда­дим пере­мен­ную, зна­че­ни­ем кото­рой дол­жен быть наш домен:

DKIM_DOMAIN=domain.zone

* где вме­сто domain.zone ста­вим наш домен.

Созда­ем ката­лог для раз­ме­ще­ния клю­чей домена:

mkdir -p /etc/opendkim/$DKIM_DOMAIN

Гене­ри­ру­ем ключ:

opendkim-genkey -D /etc/opendkim/$DKIM_DOMAIN/ --domain $DKIM_DOMAIN --selector relay

Зада­ем нуж­ные права:

chown :opendkim /etc/opendkim/$DKIM_DOMAIN/*

chmod g+rw /etc/opendkim/$DKIM_DOMAIN/*

Смот­рим содер­жи­мое фай­ла txt:

cat /etc/opendkim/$DKIM_DOMAIN/relay.txt

… и исполь­зуя дан­ное содер­жи­мое, в пане­ли управ­ле­ния нашим DNS созда­ем TXT-запись.

Добав­ля­ем соот­вет­ству­ю­щие настрой­ки в фай­лы TrustedHosts, KeyTable, SigningTable:

echo "*.$DKIM_DOMAIN" >> /etc/opendkim/TrustedHosts

echo "relay._domainkey.$DKIM_DOMAIN $DKIM_DOMAIN:relay:/etc/opendkim/$DKIM_DOMAIN/relay.private" >> /etc/opendkim/KeyTable

echo "*@$DKIM_DOMAIN relay._domainkey.$DKIM_DOMAIN" >> /etc/opendkim/SigningTable

Пере­за­пус­ка­ем службу.

systemctl reload opendkim

Гото­во.

Что дальше

Что­бы отправ­ка сооб­ще­ний ста­ла еще надеж­нее, сде­лай­те следующее:

  1. Убе­ди­тесь, что для доме­на отправ­ки суще­ству­ет пра­виль­ная запись SPF. Дан­ная запись про­пи­сы­ва­ет­ся как TXT-запись в систе­ме DNS и гово­рит, с каких поч­то­вых сер­ве­ров может быть отправ­ле­на поч­та для домена.
  2. Настрой­те DMARC. Это поли­ти­ки, кото­рые гово­рят поч­то­во­му сер­ве­ру, что нуж­но делать с пись­ма­ми. Тре­бу­ет настро­ен­ных SPF и DKIM.

Решение проблем

Боль­шин­ство труд­но­стей реша­ет­ся чте­ни­ем логов. Для opendkim они будут попа­дать в общий log-файл почты. Вклю­чить его непре­рыв­ный про­смотр мож­но сле­ду­ю­щей командой.

tail -f /var/log/maillog

Так­же, очень часто, про­бле­мы воз­ни­ка­ют из-за непра­виль­ной настрой­ки прав на клю­чи. Нуж­но иметь вви­ду, что неко­то­рые систе­мы, из сооб­ра­же­ний без­опас­но­сти, выда­ют ошиб­ку, если на фай­лы выда­ны слиш­ком широ­кие пра­ва на чте­ние. То есть, если раз­ре­шить читать фай­лы всем (chmod 644), систе­ма будет воз­вра­щать ошиб­ку. Если в логах видим «error loading key», ско­рее все­го, про­бле­ма с пра­ва­ми. Вни­ма­тель­но выпол­ни­те повтор­но реко­мен­да­ции 2-о пунк­та дан­ной инструкции.

Еще одно часто появ­ля­ю­ще­е­ся сооб­ще­ние — «opendkim no signing table match for». Оно гово­рит, что для доме­на, от кото­ро­го отправ­ля­ет­ся поч­та, нет соот­вет­ствий в фай­ле SigningTable. Либо была допу­ще­на опе­чат­ка, либо, на самом деле, для доме­на отправ­ки не нуж­но исполь­зо­вать DKIM.

 

Воз­мож­ные проблемы

1. Job for clamd.service failed because timeout was exceeded

Появ­ля­ет­ся при попыт­ке запу­стить служ­бу clamd.

При­чи­на: сер­вис стар­ту­ет так дол­го, что вре­мя, кото­рое отве­де­но на его запук заканчивается.

Реше­ние: уве­ли­чи­ва­ем вре­мя, в тече­ние кото­ро­го может стар­то­вать сер­вис. Для это­го откры­ва­ем файл настрой­ки юни­та systemd для clamd:

vi /usr/lib/systemd/system/clamd.service

В раз­дел [Service] добавляем:

[codesyntax lang="php"]

[/codesyntax]

Пере­чи­ты­ва­ем юнит:

systemctl daemon-reload

Сно­ва про­бу­ем запу­стить clamscan:

systemctl start clamd@scan

==============================================

Условия получения бесплатного сертификата от Let's Encrypt

Преж­де чем начать, необ­хо­ди­мо знать о неко­то­рых нюан­сах полу­че­ния сер­ти­фи­ка­та Let's Encrypt:

  • При запро­се выпол­ня­ет­ся про­вер­ка доме­на. Для это­го необходимо: 
    1. либо создать TXT-запись в DNS.
    2. либо под­нять веб-сер­вер, далее в его корне созда­ет­ся ката­лог .well-known, а в нем файл с про­из­воль­ным назва­ни­ем. После кор­не­вой центр отправ­ля­ет запрос сер­ве­ру на загруз­ку дан­но­го фай­ла и, в слу­чае успе­ха, выда­ет сер­ти­фи­ка­ты для ука­зан­но­го домен­но­го имени.
  • SSL-сер­ти­фи­кат выда­ет­ся на 90 дней, поэто­му необ­хо­ди­мо по рас­пи­са­нию запус­кать коман­ду на авто­ма­ти­че­ское про­дле­ние клю­ча. Когда про­хо­дит 60 дней после нача­ла исполь­зо­ва­ния ново­го сер­ти­фи­ка­та, центр Let's Encrypt может выдать новый.
  • Если выпол­нять запрос для доме­на 3 уров­ня и выше, он дол­жен прой­ти DNS про­вер­ку на всех уров­нях. Напри­мер, домен layer3.layer2.com дол­жен отве­чать на запро­сы как для layer3.layer2.com, так и для layer2.com.

Проверка домена

Как было ска­за­но выше, для полу­че­ния бес­плат­но­го сер­ти­фи­ка­та, Let's Encrypt дол­жен удо­сто­ве­рить­ся, что мы явля­ем­ся вла­дель­цем доме­на. Свое пра­во на его вла­де­ние мы можем под­твер­дить, создав спе­ци­аль­ную TXT-запись или настро­ив веб-сер­вис, кото­рый будет отве­чать на запросы.

При­мер про­сто­го кон­фи­гу­ра­ци­он­но­го фай­ла для NGINX:

[codesyntax lang="php"]

[/codesyntax]

* где test.ru — домен, для кото­ро­го рабо­та­ет сайт и для кото­ро­го мы будем запра­ши­вать сер­ти­фи­кат; /usr/share/nginx/html — путь по умол­ча­нию для nginx.

Если сер­вер уже исполь­зу­ет­ся для сай­та, в сек­цию server добавляем:

[codesyntax lang="php"]

[/codesyntax]

* дан­ны­ми строч­ка­ми мы гово­рим, что для всех запро­сов после /.well-known необ­хо­ди­мо отда­вать скрип­ты из ката­ло­га /usr/share/nginx/html; allow all предо­став­ля­ет доступ всем.

При необ­хо­ди­мо­сти выпол­нять про­вер­ку и исполь­зо­вать rewrite/return, добав­ля­ем что-то подобное:

[codesyntax lang="php"]

[/codesyntax]

После про­ве­ря­ем кон­фи­гу­ра­цию и пере­за­пус­ка­ем nginx:

nginx -t

service nginx reload

С помощью записи в DNS

Дан­ный метод про­ще,  но он поз­во­лит настро­ить авто­ма­ти­че­ское про­дле­ние сер­ти­фи­ка­та толь­ко для неко­то­рых DNS, для кото­рых есть отдель­ные certbot-пла­ги­ны. Поэто­му дан­ный спо­соб, в боль­шин­стве слу­ча­ев, будет удо­бен для про­ве­де­ния тестов.

У нас долж­на быть воз­мож­ность управ­ле­ния запи­ся­ми в DNS. На дан­ном эта­пе доста­точ­но про­сто зай­ти в панель управ­ле­ния DNS и перей­ти к эта­пу полу­че­ния сер­ти­фи­ка­та (ниже по тек­сту). Если домен новый и был толь­ко-что деле­ги­ро­ван на DNS, воз­мож­но, при­дет­ся подо­ждать, пока он не ста­нет досту­пен для всех сер­ве­ров DNS в гло­баль­ной сети.

Установка утилиты для получения сертификата

Certbot для Linux

а) на CentOS 8:

dnf --enablerepo=PowerTools install certbot

б) на CentOS 7:

yum install certbot

в) на Ubuntu 16.04 и выше:

apt-get install certbot

г) на CentOS 6 или Ubuntu 14.04:

Созда­дим ката­лог, в кото­ром будет хра­нить­ся ути­ли­та и пере­хо­дим в него:

mkdir /opt/certbot

cd /opt/certbot

Загру­жа­ем ути­ли­ту и раз­ре­ша­ем ее запуск:

wget https://dl.eff.org/certbot-auto

chmod a+x ./certbot-auto

Для удоб­ства, дела­ем симлинк:

ln -s /opt/certbot/certbot-auto /opt/certbot/certbot

* при пер­вом запус­ке certbot он авто­ма­ти­че­ски пред­ло­жит доуста­но­вить необ­хо­ди­мые зависимости.

Первое получение сертификата

1. Если мы под­твер­жда­ем пра­во на домен при помо­щи веб-сер­ве­ра, выпол­ня­ем такую команду:

certbot certonly --webroot --agree-tos --email postmaster@test.ru --webroot-path /usr/share/nginx/html/ -d test.ru -d www.test.ru

* на систе­мах CentOS 6 или Ubuntu 14.04 вме­сто certbot про­пи­сы­ва­ем пол­ный путь до уста­нов­лен­но­го паке­та — /opt/certbot/certbot.
* где для двух команд:

  • certonly — запрос ново­го сертификата;
  • manual — про­вер­ка доме­на вручную.
  • preferred-challenges — ука­зы­ва­ет метод про­вер­ки домена.
  • webroot — про­вер­ка будет выпол­нять­ся на осно­ве запро­са к кор­ню сайта;
  • agree-tos — даем согла­сие на лицен­зи­он­ное соглашение;
  • email — поч­то­вый адрес адми­ни­стра­то­ра домена;
  • webroot-path — ката­лог в систе­ме Linux, кото­рый явля­ет­ся кор­не­вым для сайта;
  • d — пере­чис­ле­ние доме­нов, для кото­рых запра­ши­ва­ем сертификат.

После успеш­но­го выпол­не­ния коман­ды, сер­ти­фи­ка­ты будут созда­ны в ката­ло­ге /etc/letsencrypt/archive/test.ru, а так­же сим­лин­ки на них в ката­ло­ге /etc/letsencrypt/live/test.ru. При настрой­ке при­ло­же­ний, сто­ит ука­зы­вать пути до сим­лин­ков, так как при обнов­ле­нии фай­лы в пер­вом ката­ло­ге будут менять­ся, во вто­ром — нет. Пуб­лич­ный ключ будет с име­нем cert.pem, а при­ват­ный — privkey.pem.

2. При под­твер­жде­нии пра­ва на домен с TXT-записью:

certbot certonly --manual --agree-tos --email postmaster@test.ru --preferred-challenges=dns -d test.ru -d www.test.ru

На запрос под­твер­жде­ния отве­ча­ем Y — систе­ма выдаст что-то на подобие:

Please deploy a DNS TXT record under the name
_acme-challenge.test.ru with the following value:

W2SC9b88y2j2oUjhxVgS7Bphph9g5PqhkBq9KiWkLTm

Once this is deployed,

* Дан­ное сооб­ще­ние гово­рит, что мы долж­ны создать TXT-запись _acme-challenge.test.ru со зна­че­ни­ем W2SC9b88y2j2oUjhxVgS7Bphph9g5PqhkBq9KiWkLTm.

Созда­ем соот­вет­ству­ю­щую запись в пане­ли управ­ле­ния DNS, и в кон­со­ли сер­ве­ра нажи­ма­ем Enter для про­дол­же­ния. Если, как в дан­ном при­ме­ре, мы запра­ши­ва­ем сер­ти­фи­кат для несколь­ких узлов, повто­ря­ем действия.

Автоматическое продление

Смот­рим пол­ный путь до скрип­та certbot:

which certbot

Откры­ва­ем на редак­ти­ро­ва­ние cron и добав­ля­ем следующее:

crontab -e

0 0 * * 1,4 /bin/certbot renew

* в дан­ном при­ме­ре про­вер­ка и про­дле­ние сер­ти­фи­ка­та будет выпол­нять­ся по поне­дель­ни­кам и чет­вер­гам (1,4) в 00:00. /bin/certbot — путь, кото­рый мне выда­ла коман­да which certbot.

Коман­да certbot renew про­ве­ря­ет для всех наших сер­ти­фи­ка­тов срок окон­ча­ния, и если оста­лось менее 30 дней, запра­ши­ва­ет новый, сохра­ня­ет его в ката­ло­ге /etc/letsencrypt/archive/<домен> и обнов­ля­ет симлинк.

Сто­ит иметь вви­ду, что мно­гие при­ло­же­ния, исполь­зу­ю­щие сер­ти­фи­кат, потре­бу­ют пере­за­пус­ка, что­бы пере­чи­тать его. Поэто­му хоро­шей иде­ей будет не про­сто обнов­лять сер­ти­фи­кат, но и пере­за­пус­кать сер­вис, кото­рый исполь­зу­ет сер­ти­фи­кат. Напри­мер, для NGINX:

0 0 * * 1,4 /bin/certbot renew && systemctl reload nginx

Wildcard

С мар­та 2018 года появи­лась воз­мож­ность полу­чить бес­плат­ный сер­ти­фи­кат на все под­до­ме­ны, напри­мер, mail.test.ru, test.test.ru, admin.test.ru (*.test.ru).

Особенности получения Wildcard от Let's Encrypt:

  1. Под­твер­дить пра­во исполь­зо­ва­ния доме­ном мож­но толь­ко с помо­щью DNS — таким обра­зом, затруд­ня­ет­ся про­цесс авто­ма­ти­че­ско­го про­дле­ния. Нуж­но исполь­зо­вать пла­ги­ны, кото­рые поз­во­ля­ют авто­ма­ти­че­ски созда­вать нуж­ную запись на DNS, но они доступ­ны дале­ко не для всех постав­щи­ков услуг DNS. В про­тив­ном слу­чае, обнов­лять Wildcard нуж­но вручную.
    Так­же, неко­то­рые пане­ли управ­ле­ния хостин­гом, напри­мер ISP Manager с вер­сии 5 могут управ­лять про­цес­сом полу­че­ния Wildcard от Let's Encrypt с воз­мож­но­стью авто­ма­ти­че­ско­го про­дле­ния (но необ­хо­ди­мо, что­бы домен обслу­жи­вал­ся на дан­ном хостинге).
  2. Вре­мя дей­ствия сер­ти­фи­ка­та так­же огра­ни­че­но 3 месяцами.

Certbot

Необ­хо­ди­мо, что­бы вер­сия ути­ли­ты certbot была 0.22.0 и выше. Про­ве­рить теку­щую вер­сию мож­но командой:

certbot --version

… если вер­сия ниже, обнов­ля­ем ее командами:

а) для CentOS / Red Hat:

yum update certbot

б) для Ubuntu / Debian:

apt-get install --only-upgrade certbot

Процесс получения

Про­цесс очень похож на про­цесс полу­че­ния сер­ти­фи­ка­та с под­твер­жде­ни­ем доме­на в DNS.

Вво­дим команду:

certbot certonly --manual --agree-tos --email master@test.ru --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenges=dns -d test.ru -d *.test.ru

* обра­тим вни­ма­ние на 2 дета­ли: 1) мы доба­ви­ли опцию server, что­бы ука­зать, на каком сер­ве­ре Let's Encrypt долж­на про­хо­дить про­вер­ка DNS; 2) мы полу­ча­ем сер­ти­фи­кат как для *.test.ru, так и само­го test.ru, так как пер­вое не вклю­ча­ет второго.

… систе­ма попро­сит создать TXT-запись в DNS, кото­рый обслу­жи­ва­ет наш домен:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.test.ru with the following value:

DN8ovKFJ0leLQV9ofZ81mYKxojwIaed5g6f0bXZCYiI

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

* в дан­ном при­ме­ре систе­ма попро­си­ла создать TXT-запись _acme-challenge.test.ru со зна­че­ни­ем DN8ovKFJ0leLQV9ofZ81mYKxojwIaed5g6f0bXZCYiI.

Захо­дим в панель управ­ле­ния DNS и созда­ем нуж­ную запись. Если у нас свой сер­вер DNS, напри­мер, bind, то стро­ка будет такой:

; TXT
_acme-challenge IN      TXT     DN8ovKFJ0leLQV9ofZ81mYKxojwIaed5g6f0bXZCYiI

Не торо­пим­ся нажи­мать Enter — после настрой­ки DNS нуж­но немно­го вре­ме­ни (пару минут), что­бы настрой­ка при­ме­ни­лась. Про­ве­рить появ­ле­ние запи­си мож­но коман­дой с рабо­че­го компьютера:

nslookup -type=txt _acme-challenge.test.ru 8.8.8.8

Как толь­ко видим, что настрой­ки при­ме­ни­лись, нажи­ма­ем Enter — если это наш пер­вый запрос Wildcard для дан­но­го доме­на, то систе­ма нас попро­сит создать еще одну запись — повто­ря­ем про­це­ду­ру, создав в DNS вто­рую запись TXT.

Если все сде­ла­ли пра­виль­но, то увидим:

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/test.ru/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/test.ru/privkey.pem
Your cert will expire on 2019-09-05. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
Donating to EFF:                    https://eff.org/donate-le

… сер­ти­фи­кат получен.