Verification: a143cc29221c9be0

No match for argument php mysql centos 8

No match for argument php mysql centos 8

Содержание

Содержание

1. Подготовка системы

И так, данная инструкция написана под систему Linux Ubuntu Server. Предварительно, выполним следующие действия.

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

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

apt-get update && apt-get upgrade

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

hostnamectl set-hostname relay.dmosk.ru

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

Устанавливаем пакет для синхронизации времени:

apt-get install chrony

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

timedatectl set-timezone Europe/Moscow

* чтобы получить список всех возможных зон, вводим timedatectl list-timezones.

Разрешаем сервис для обновления времени:

systemctl enable chrony

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

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

iptables -I INPUT 1 -p tcp --match multiport --dports 25,110,143,465,587,993,995 -j ACCEPT

iptables -I INPUT 1 -p tcp --match multiport --dports 80,443 -j ACCEPT

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

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

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

apt-get install iptables-persistent

И выполняем команду:

netfilter-persistent save

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

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

Установка NGINX

Устанавливаем nginx командой:

apt-get install nginx

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

systemctl enable nginx

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

Приветствие NGINX — все настроено верно

PHP + PHP-FPM + NGINX

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

apt-get install php php-fpm

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

vi /etc/nginx/sites-enabled/default

В разделах http - server указываем, чтобы первым индексным файлом был index.php, а также добавляем настройку для обработки запросов php (location):

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        ...

        index index.php ...
        ...

        location ~ \.php$ {
            set $root_path /var/www/html;
            fastcgi_pass unix:/run/php/php7.4-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
            include fastcgi_params;
            fastcgi_param DOCUMENT_ROOT $root_path;
        }
}

* где /var/www/html — каталог для размещения данных nginx по умолчанию; /run/php/php7.4-fpm.sock — путь до сокет-файла php-fpm (обратите внимание, что точное значение зависит от используемой вервии php).

Разрешаем автозапуск php-fpm:

systemctl enable php7.4-fpm

* где php7.4-fpm зависит от используемой версии php, которую можно посмотреть командой php -v.

Перезапускаем nginx: 

systemctl restart nginx

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

vi /var/www/html/index.php

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

Результат отработки phpinfo

MariaDB

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

apt-get install mariadb-server

Включаем автозапуск сервиса баз данных:

systemctl enable mariadb

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

mysqladmin -u root password

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

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

apt-get install php-mysql php-mbstring php-imap

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

systemctl restart php7.4-fpm

Скачиваем PostfixAdmin:

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

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

mkdir /var/www/html/postfixadmin

tar -C /var/www/html/postfixadmin -xvf postfixadmin.tar.gz --strip-components 1

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

mkdir /var/www/html/postfixadmin/templates_c

* в противном случае, при попытке зайти в панель управления после ее установки мы получим ошибку ERROR: the templates_c directory doesn't exist or isn't writeable for the webserver.

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

chown -R www-data:www-data /var/www/html/postfixadmin

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

Создаем базу данных 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 /var/www/html/postfixadmin/config.local.php

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

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

$CONF['configured'] = true;
$CONF['default_language'] = 'ru';
$CONF['database_password'] = 'postfix123';
$CONF['emailcheck_resolve_domain']='NO';

?>

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

Запускаем браузер и вводим адрес http:///postfixadmin/public/setup.php — откроется страница для установки PostfixAdmin. 

Задаем дважды пароль установки и генерируем хэш, кликнув по Generate setup_password hash:

Вводим пароль для установки и генерируем хэш

После копируем хэш, который появится под кнопкой:

Так выглядит хэш PostfixAdmin

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

vi /var/www/html/postfixadmin/config.local.php

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

...
$CONF['setup_password'] = '$2y$10$D...R32';

* где '$2y$10$D...R32' — скопированный хэш.

Перезагружаем страницу http:///postfixadmin/public/setup.php — теперь у нас появится форма для ввода нашего пароля, созданного на предыдущем этапе. Вводим его и кликаем по Login with setup_password:

Форма для входа с паролем установки

Будет выполнена установка PostfixAdmin.

Если в процессе установки система выведет ошибки, необходимо самостоятельно с ними разобраться. Как правило, они могут сводиться к отсутствию необходимых пакетов, которых может не оказаться в системе по умолчанию.

После установки в нижней части страницы должна быть форма добавления суперпользователя — вводим данные:

Создаем суперпользователя PostfixAdmin

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

Установка завершена. Переходим в браузере на страницу http:///postfixadmin/public/login.php

Вводим логин и пароль для созданного пользователя. Мы должны войти в postfix.admin.

Однако, конкретно, в моем случае, пользователь не создавался при установке системы и необходимо было создать администратора вручную. Если это потребуется, в консоли сервера подключаемся к СУБД:

mysql -uroot -p

Переходим к использованию базы postfix:

> use postfix

Добавляем администратора запросом:

> INSERT INTO admin (`username`, `password`, `superadmin`, `active`) VALUES ('root@dmosk.ru', '$1$1b7ff416$/KKYqdyAd3viA3.PNu5hh/', '1', '1');

Выходим из sql-оболочки:

> quit

Теперь переходим на страницу http:///postfixadmin/public/login.php вводим логин root@dmosk.ru и пароль qwe12345 — мы должны оказаться в системе управления почтой. Первым делом, переходим в Список админов - Новый админ:

Переход к созданию нового администратора

Создаем своего пользователя. После чего, можно удалить того, что создали через командную строку.

4. Установка и настройка Postfix

Установка Postfix в Ubuntu выполняется командой:

apt-get install postfix postfix-mysql

* помимо самого postfix, мы также установим postfix-mysql для возможности работы с СУБД.

В процессе установки должно появиться окно «Postfix Configuration» — оставляем Internet Site:

В процессе установки в окне Postfix Configuration выбираем Internet Site

В следующем окне оставляем имя сервера и нажимаем Enter.

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

groupadd -g 1024 vmail

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

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

Если директория для почты ранее уже была создана, то необходимо задать в качестве владельца нашего созданного пользователя:

chown vmail:vmail /home/mail

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

vi /etc/postfix/main.cf

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

mydestination = localhost.$mydomain, localhost, localhost.localdomain
...
inet_protocols = ipv4
...
smtpd_tls_cert_file = /etc/ssl/mail/public.pem
smtpd_tls_key_file = /etc/ssl/mail/private.key

* где:

  • mydestination — указываем, для каких доменов принимаем входящую почту.
  • inet_protocols — данный параметр задаст протокол для работы postfix. В данном примере на ipv4 — если в нашей системе не используется IPv6, могут возникнуть проблемы при маршрутизации почты. Также можно задать значения all или ipv6.
  • smtpd_tls_cert_file — полный путь до публичного сертификата.
  • smtpd_tls_key_file — полный путь до приватного сертификата.

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

myhostname = mx01.dmosk.ru

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

virtual_mailbox_base = /home/mail
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 1024
virtual_uid_maps = static:1024
virtual_gid_maps = static:1024
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

smtp_use_tls = yes
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_helo_required = yes

* где:

  • 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.
  • smtp_use_tls — по возможности, использовать шифрованное соединение для подключение к другому серверу SMTP при отправке письма.
  • smtpd_use_tls — указывает клиентам на наличие поддержки TLS.
  • smtpd_tls_auth_only — использовать только TLS.
  • smtpd_helo_required — требовать начинать сессию с приветствия.

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

vi /etc/postfix/mysql_virtual_alias_maps.cf

user = postfix
password = postfix123
hosts = localhost
dbname = postfix
query = SELECT goto FROM alias WHERE address='%s' AND active = '1'

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

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

vi /etc/postfix/mysql_virtual_domains_maps.cf

user = postfix
password = postfix123
hosts = localhost
dbname = postfix
query = SELECT domain FROM domain WHERE domain='%u'

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

vi /etc/postfix/mysql_virtual_mailbox_maps.cf

user = postfix
password = postfix123
hosts = localhost
dbname = postfix
query = SELECT CONCAT(domain,'/',maildir) FROM mailbox WHERE username='%s' AND active = '1'

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

vi /etc/postfix/master.cf

submission   inet  n  -  n  -  -  smtpd
  -o smtpd_tls_security_level=may
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=/var/spool/postfix/private/auth
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_local_domain=$myhostname

smtps   inet  n  -  n  -  -  smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

dovecot   unix  -  n  n  -  -  pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}

* необходимо убедиться, что в содержимом файла нет других раскомментированных опций для 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. Возможны варианты yn и -. Прочерк означает неприменимость данного параметра к конкретному сервису.
  • второй "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 — настройки ограничения клиентских соединений. В данном примере разрешить только авторизованных.

Генерируем сертификаты безопасности. Для этого создаем каталог, в котором их разместим:

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.dmosk.ru"

* сертификат сгенерирован на 1461 день, ключи subj могут быть произвольными, CN необходимо указать в соответствии с именем сервера, по которому мы будем подключаться к почте.
* если мы хотим использовать сертификат, который будет проходить все проверки безопасности, его нужно купить или запросить у Let's Encrypt.

Разрешаем запуск postfix:

systemctl enable postfix

Перезапускаем его:

systemctl restart postfix

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

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

apt-get install dovecot-imapd dovecot-pop3d 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

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
    user = postfix
    group = postfix
  }
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
    group = vmail
  }
}

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

А также в этом файле добавим строки:

service stats {
    unix_listener stats-reader {
        user = vmail
        group = vmail
        mode = 0660
    }
    unix_listener stats-writer {
        user = vmail
        group = vmail
        mode = 0660
    }
}

* в противном случае, мы увидим в логе ошибку error net_connect_unix(/var/run/dovecot/stats-writer) failed permission denied, так как у пользователя vmail не будет прав.

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

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

#!include auth-system.conf.ext
!include auth-sql.conf.ext

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

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

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

ssl = required
ssl_cert = /ssl/mail/public.pem
ssl_key = /ssl/mail/private.key

* 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

passdb {
  …
  args = /etc/dovecot/dovecot-sql.conf.ext
}

userdb {
  …
  args = /etc/dovecot/dovecot-sql.conf.ext
}

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

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

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

В самый низ добавим: 

driver = mysql
connect = host=localhost dbname=postfix user=postfix password=postfix123
default_pass_scheme = MD5-CRYPT
password_query = SELECT password FROM mailbox WHERE username = '%u'
user_query = SELECT maildir, 1024 AS uid, 1024 AS gid FROM mailbox WHERE username = '%u'
user_query = SELECT CONCAT('/home/mail/',LCASE(`domain`),'/',LCASE(`maildir`)), 1024 AS uid, 1024 AS gid FROM mailbox WHERE username = '%u'

* в данном примере мы настроили запрос на получение данных из базы 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

Разрешаем запуск dovecot:

systemctl enable dovecot

Перезапускаем dovecot:

systemctl restart dovecot

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

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

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

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

Переходим к созданию нового домена

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

Заполняем форму для создания домена в PostfixAdmin

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

Создаем новый почтовый ящик через Postfixadmin

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

Заполняем данные для создания нового ящика

Теперь можно подключиться к серверу с помощью любой почтовой программы, например, 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. При необходимости, можно установить другой, например, WebMail Lite или несколько одновременно.

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

Скачиваем стабильную версию Roundcube

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

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

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

mkdir /var/www/html/webmail

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

tar -C /var/www/html/webmail -xvf roundcubemail-*.tar.gz --strip-components 1

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

cp /var/www/html/webmail/config/config.inc.php.sample /var/www/html/webmail/config/config.inc.php

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

vi /var/www/html/webmail/config/config.inc.php

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

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

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

$config['drafts_mbox'] = 'Drafts';
$config['junk_mbox'] = 'Junk';
$config['sent_mbox'] = 'Sent';
$config['trash_mbox'] = 'Trash';
$config['create_default_folders'] = true;

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

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

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

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

chown -R www-data:www-data /var/www/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

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

apt-get install php-pear php-intl php-ldap php-net-smtp php-gd php-imagick php-zip

В Ubuntu нет возможности установить компонент mcrypt из репозитория — для начала установим пакеты, необходимые для сборки его их исходников:

apt-get install php-dev libmcrypt-dev

Выполняем команды:

pecl channel-update pecl.php.net

pecl install mcrypt-1.0.4

Создадим файл с настройкой нового модуля:

vi /etc/php/7.4/fpm/conf.d/99-mcrypt.ini

extension=mcrypt.so

Настроим php:

vi /etc/php/7.4/fpm/php.ini

date.timezone = "Europe/Moscow"
...
post_max_size = 30M
...
upload_max_filesize = 30M

* в данном примере мы задаем московское время и возможность загружать файл размером в 30 Мб (это будет максимальным объемом вложений, которые можно отправлять через веб-интерфейс).

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

systemctl restart php7.4-fpm

Настроим nginx:

vi /etc/nginx/nginx.conf

Добавим строку в раздел http:

http {
    ...
    client_max_body_size 30M;
    ...

* данной настройкой мы также разрешим загрузку файлов размером 30 Мб.

Перезапустим nginx для применения настройки:

systemctl restart nginx

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

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

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

vi /var/www/html/webmail/config/config.inc.php

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

$config['enable_installer'] = false;

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

\rm -R /var/www/html/webmail/installer

И заходим в браузере по адресу http:///webmail/. Вводим в качестве логина адрес почты созданного пользователя и его пароль.

8. Защищаемся от вирусов и СПАМа

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

Установка и настройка Clamav + Amavisd

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

apt-get install amavisd-new clamav clamav-daemon spamassassin

Добавляем пользователя clamav в группу amavis:

usermod -a -G amavis clamav

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

vi /etc/amavis/conf.d/15-content_filter_mode

Снимаем комментарии для строк:

...
@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
...
@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);
...

* по умолчанию amavis не выполняем никаких проверок — для включения сканирования на вирусы снимаем комментарий с bypass_virus_checks_maps, а для сканирования на СПАМ — bypass_spam_checks_maps.

Затем открываем на редактирование:

vi /etc/amavis/conf.d/50-user

Добавим строки:

$allowed_header_tests{'multiple'} = 0;
$allowed_header_tests{'missing'} = 0;

* данные опции позволят программе Outlook без ошибок отправлять тестовое сообщение.

Разрешаем запуск антивируса и amavis:

systemctl enable clamav-daemon clamav-freshclam amavis

Перезапускаем сервисы:

systemctl restart amavis clamav-daemon clamav-freshclam

Настройка Postfix

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

vi /etc/postfix/main.cf

content_filter = scan:[127.0.0.1]:10024

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

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

vi /etc/postfix/master.cf

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

scan   unix  -  -  n  -  16  smtp
  -o smtp_send_xforward_command=yes
  -o smtp_enforce_tls=no

127.0.0.1:10025   inet  n  -  n  -  16  smtpd
  -o content_filter=
  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
  -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o mynetworks_style=host
  -o smtpd_authorized_xforward_hosts=127.0.0.0/8

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

  • 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_restrictionssmtpd_client_restrictionssmtpd_sender_restrictions отключают ограничения для данных опций.
  • smtpd_recipient_restrictions — контролирует ответ Postfix на SMTP-команду RCPT TO. Здесь мы разрешаем только соединения от узлов, перечисленных в mynetworks.
  • mynetworks_style=host указывает postfix, что он должен пересылать почту только с локального компьютера.
  • smtpd_authorized_xforward_hosts укажет, какие удаленные клиенты могут использовать XFORWARD. В данном случае локальный компьютер.

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

systemctl restart postfix

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

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

sa-update --nogpg --verbose

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

crontab -e

30 3 * * * /usr/bin/sa-update

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

Проверка

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

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

Большинство почтовых систем экранинуют вирусную последовательность и письмо нормально пройдет мимо нашего антивируса. Чтобы сделать корректный тест, необходимо отправить письмо SMTP-командами.

Письмо не должно дойти, а в логе (/var/log/maillog) мы увидим строку:

... amavis[17688]: (17688-04) Blocked INFECTED (Eicar-Signature) {DiscardedOutbound,Quarantined}, MYNETS LOCAL ...
... relay=127.0.0.1[127.0.0.1]:10024, delay=0.25, delays=0.19/0/0/0.06, dsn=2.7.0, status=sent (250 2.7.0 Ok, discarded, id=17688-04 - INFECTED: Eicar-Signature)

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

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

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

... amavis[17689]: (17689-04) Blocked SPAM {DiscardedOutbound,Quarantined}, MYNETS LOCAL ...
... status=sent (250 2.7.0 Ok, discarded, id=17689-04 - spam)

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

Все письма со спамом и вирусами будут перемещаться в карантин. Если мы хотим перенаправлять все подобные сообщения на специальный ящик, то необходимо настроить amavis.

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

vi /etc/amavis/conf.d/50-user

Добавляем такие опции:

$spam_quarantine_to = "spam\@dmosk.ru";
$virus_quarantine_to = "virus\@dmosk.ru";

* где $spam_quarantine_to указываем на адрес для перенаправления СПАМ-писем; $virus_quarantine_to — почта для писем с обнаруженными вирусами.

После перезагрузим amavis:

systemctl restart amavis

Пробуем отправить сообщения с тестовыми сигнатурами на СПАМ и вирус — письма должны быть перенаправлены на указанные адреса.

Антиспам средствами 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

Комментируем строку:

#smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

И добавляем:

smtpd_client_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_unauth_pipelining
        permit

smtpd_helo_restrictions =
        permit

smtpd_sender_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_non_fqdn_sender
        reject_unknown_sender_domain
        permit

smtpd_relay_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        defer_unauth_destination

smtpd_recipient_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_non_fqdn_recipient
        reject_unauth_destination
        reject_unknown_recipient_domain
        reject_unverified_recipient
        permit

smtpd_data_restrictions =
        permit

smtpd_end_of_data_restrictions =
        permit

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

  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 — разрешает соединение. Ставим в конец каждого блока ограничений (если ограничения не сработали, то разрешаем).

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

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

smtpd_recipient_restrictions =
        ...
        reject_unknown_client_hostname
        reject_invalid_helo_hostname
        reject_non_fqdn_helo_hostname
        reject_unknown_helo_hostname
        reject_rbl_client bl.spamcop.net
        reject_rbl_client cbl.abuseat.org
        reject_rbl_client dul.ru
        reject_rbl_client dnsbl.abuse.ch
        permit

* где:

  • 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

Обучение антиспама

Мы установили amavis, который проверяет почту на СПАМ средствами spamassassin. Последний без обучения, практически, бесполезен. Синтаксис команды для обучения следующий:

sa-learn --spam

sa-learn --ham 

Таким образом, первая команда укажет spamassassin какие письма являются нежелательными, а вторая — не несущими рекламный характер.

Хорошей практикой будет договориться с пользователями о ручном помещении нежелательной почты из входящих в папку СПАМ. Тогда мы сможем пройтись скриптом по всем ящикам на сервере и обучать антиспам. Например, такой командой:

sa-learn --spam /home/mail/dmosk.local/*/{.\&BCEEPwQwBDw-,.Spam,.Junk\ E-mail,.Junk}/cur

* в данном примере мы сказали spamassassin найти в каталогах пользователей папки Спам, Spam, Junk, Junk E-mail (данные каталоги являются типичными для помещения СПАМа) и провести обучение. 

Чтобы минимизировать количество ложных срабатываний, необходимо проводить обучение с ключом --ham. В нашем примере мы отправляем все нежелательные письма на ящик spam. В таком случае, необходимо вручную находить ложные срабатывания и переносить их в специальную папку, например Ham. Тогда команда для обучения будет такой:

sa-learn --ham /home/mail/dmosk.local/spam\@dmosk.local/.Ham/cur

Статистику обучения можно посмотреть командой:

sa-learn --dump magic

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

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

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

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

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

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

postconf -n smtpd_banner

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

postconf -n myhostname

Если и в этот вариант не вернет ответ, вводим:

hostname

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

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

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

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

  1. SPF.
  2. DMARC.
  3. DKIM

Для проверки корректности настройки сервера, воспользуемся ресурсами:

  • https://www.mail-tester.com
  • https://spamtest.smtp.bz

10. Настройка DKIM

Подпись писем не является обязательной, но помогает не попадать в СПАМ. DKIM настраивается для каждого домена, а также должна создаваться специальная запись в DNS. Рассмотрим создание и настройку DKIM в amavisd.

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

mkdir -p /var/lib/dkim

Генерируем последовательность для нашего домена:

amavisd-new genrsa /var/lib/dkim/dmosk.ru.pem 1024

* где dmosk.ru — домен, для которого мы сгенерируем подпись dkim.

Задаем права на созданный файл:

chown amavis:amavis /var/lib/dkim/*.pem

chmod 0400 /var/lib/dkim/*.pem

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

vi /etc/amavis/conf.d/20-debian_defaults

Редактируем запись:

#$inet_socket_port = 10024;
$inet_socket_port = [10024,10026];

* в данном примере мы закомментировали первую строку и раскомментировали вторую. Это укажет amavis, что он должен запускаться и работать на двух портах.

А также добавим:

$forward_method = 'smtp:[127.0.0.1]:10025';
$notify_method = $forward_method;
$interface_policy{'10026'} = 'ORIGINATING';
$policy_bank{'ORIGINATING'} = {
    originating => 1,
    smtpd_discard_ehlo_keywords => ['8BITMIME'],
    os_fingerprint_method => undef,
    bypass_banned_checks_maps => [1],
    bypass_header_checks_maps => [1],
    bypass_banned_checks_maps => [1],
    virus_admin_maps => ["virusalert\@$mydomain"],
};

Открываем файл:

vi /etc/amavis/conf.d/50-user

Добавляем записи:

$enable_dkim_verification = 1;
$enable_dkim_signing = 1;

dkim_key('dmosk.ru', "dkim", "/var/lib/dkim/dmosk.ru.pem");

@dkim_signature_options_bysender_maps = ( {
   "dmosk.ru" => { d => "dmosk.ru", a => 'rsa-sha256', ttl => 10*24*3600 },
});

* где dmosk.ru — домен, для которого мы настраиваем dkim; /var/lib/dkim/dmosk.ru.pem — путь до сгенерированного файла с последовательностью.

Перезапускаем amavis:

systemctl restart amavis

Посмотреть DKIM последовательность для нового домена можно командой:

amavisd-new showkeys

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

; key#1 1024 bits, i=dkim, d=dmosk.ru, /var/lib/dkim/dmosk.ru.pem
dkim._domainkey.dmosk.ru.        3600 TXT (
  "v=DKIM1; p="
  "MIGfMA0SDFqGSIb3DQEBAQUAA4GNADCBiQKBgQC44iOK+99mYBxsnIl1Co8n/Oeg"
  "4+x90sxqWzoGW42d/GCP4wiYqVqncc37a2S5Berv0OdoCGcmkDkKWh4CHhFD4blk"
  "x6eMYXsp1unAdo2mk/OVK7M2ApraIkh1jVbGBZrREVZYTE+uPOwtAbXEeRLG/Vz5"
  "zyQuIpwY2Nx3IgEMgwIDAQAB")

Теперь нам нужно на основе данного вывода создать в DNS запись TXT. В данном примере, нужно создать запись c именем dkim._domainkey в зоне dmosk.ru и значением "v=DKIM1; p=MIGfMA0SD...wIDAQAB".

Проверить корректность настройки DKIM можно командой:

amavisd-new testkeys

Переходим к настройке Postfix. Мы должны добавить отправку всех исходящих писем на проверку в amavis на порт 10026 и принимать обратно письма на порт 10027.

Открываем файл:

vi /etc/postfix/master.cf

Отредактируем submission и smtps, добавив content_filter:

smtp      inet  n       -       y       -       -       smtpd
  -o content_filter=scan:[127.0.0.1]:10026
  ...

submission   inet  n  -  n  -  -  smtpd
  -o content_filter=scan:[127.0.0.1]:10026
  ...

smtps   inet  n  -  n  -  -  smtpd
  -o content_filter=scan:[127.0.0.1]:10026
  ...

И добавим:

127.0.0.1:10027   inet  n  -  n  -  16  smtpd
  -o content_filter=
  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
  -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o mynetworks_style=host
  -o smtpd_authorized_xforward_hosts=127.0.0.0/8

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

systemctl restart postfix

Настраиваем Roundcube:

vi /var/www/html/webmail/config/config.inc.php

Находим строки:

$config['smtp_server'] = '';
...
$config['smtp_port'] = 25;

... и меняем ее на:

$config['smtp_server'] = 'tls://localhost';
...
$config['smtp_port'] = 587;

* в данном примере мы указали, что соединение для отправки почты должно быть защищенным. Это важно для нашей настройки DKIM.

Пробуем отправить письмо — в заголовках мы должны увидеть:

dkim=pass header.d=dmosk.ru 

11. Настройка квот

В PostfixAdmin у нас есть возможность задать квоты на почтовые ящики, но они работать не будут, так как о них ничего не знает Dovecot.

Процесс настройки не сложен и описан отдельно в статье Настройка квот в Dovecot + PostfixAdmin.

После применения квот мы сможем наблюдать в почтовом клиенте Roundcube информацию об оставшемся дисковом пространстве:

Информация о квоте в Roundcube

... или в Webmail Lite:

Информация о квоте в Webmail Lite

12. Автоматическая настройка почтовых клиентов

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

Подробнее процесс настройки описан в статье Настройка Autodiscover для своего почтового сервера.

13. Папки на русском в Outlook

По умолчанию, все почтовые клиенты, кроме Outlook распознают служебные папки IMAP:

  • Drafts — черновики.
  • Junk — СПАМ.
  • Sent — отправленные.
  • Trash — удаленные.

Данные каталоги переводятся на русский язык и корректно отображаются в клиенте. В Outlook эти папки отображаются как есть — на английском языке.

Для решения проблемы мы должны открыть файл:

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

Найти блок настроек namespace inbox. Для каждого из служебного каталога настроить следующее:

namespace inbox {
  ...
  mailbox Черновики {
    auto = subscribe
    special_use = \Drafts
  }
  mailbox Drafts {
    auto = no
    special_use = \Drafts
  }

  mailbox Спам {
    auto = subscribe
    special_use = \Junk
  }
  mailbox Junk {
    auto = no
    special_use = \Junk
  }
  mailbox Spam {
    auto = no
    special_use = \Junk
  }
  mailbox "Junk E-mail" {
    auto = no
    special_use = \Junk
  }

  mailbox Удаленные {
    auto = subscribe
    special_use = \Trash
  }
  mailbox Trash {
    auto = no
    special_use = \Trash
  }
  mailbox "Deleted Messages" {
    auto = no
    special_use = \Trash
  }

  mailbox Отправленные {
    auto = subscribe
    special_use = \Sent
  }
  mailbox Sent {
    auto = no
    special_use = \Sent
  }
  mailbox "Sent Messages" {
    auto = no
    special_use = \Sent
  }
  mailbox "Sent Items" {
    auto = no
    special_use = \Sent
  }
  ..
}

* и так, мы задали несколько вариантов служебных каталогов:

  • Черновики — на сервере могут быть папки Черновики и Drafts. По умолчанию отображается и создается Черновики.
  • Спам — на сервере Спам, Junk, Spam, Junk E-mail.
  • Удаленные — на сервере Удаленные, Trash, Deleted Messages.
  • Отправленные — на сервере Отправленные, Sent, Sent Messages, Sent Items.

Для применения настроек перезапускаем dovecot:

systemctl restart dovecot

14. Разное

Рассмотрим дополнительные настройки для нашего сервера.

Настройка ограничений

Также важно настроить некоторые ограничения, например:

  • максимальный размер вложения.
  • количество сообщений, которое можно отправить за определенный период времени.
  • настройка очереди (время хранения писем).
  • таймауты отправки.

Подробнее, информацию можно найти в статье Лимиты в Postfix.

Смена email адреса

Предположим, мы сделали ошибку в написании адреса электронной почты, но не хотим удалять учетную запись и создавать ее по новой. Рассмотрим смену email-адреса на примере sekretar@dmosk.ru -> secretar@dmosk.ru.

Нам нужно внести изменения в базу данных — для этого заходим в оболочку sql:

mysql -uroot -p

Вводим пароль, который создавали после установки СУБД.

Используем базу postfix:

> use postfix

Редактируем алиасы командой:

> UPDATE alias SET `address`='secretar@dmosk.ru', `goto`=REPLACE(`goto`, 'sekretar@dmosk.ru', 'secretar@dmosk.ru') WHERE `address`='sekretar@dmosk.ru';

Редактируем почтовый ящик:

> UPDATE mailbox SET `username`='secretar@dmosk.ru', `local_part`='secretar', `maildir`=REPLACE(`maildir`, '/sekretar/', '/secretar/') WHERE `username`='sekretar@dmosk.ru';

И квоту:

> UPDATE quota2 SET `username`='secretar@dmosk.ru' WHERE `username`='sekretar@dmosk.ru';

С базой данных закончили — выходим из sql:

> quit

Переходим в каталог с почтовыми ящиками пользователей для нашего домена:

cd /home/mail/dmosk.ru/

Перемещаем папку с почтой старого ящика в новый:

mv sekretar@dmosk.ru secretar@dmosk.ru

Проверяем работу через веб-интерфейс. Если используем почтовый клиент, меняем настройки для использования нового email-адреса.

1: Установка StrongSwan

Для начала мы установим StrongSwan. Это открытый демон IPSec, который можно использовать в качестве VPN-сервера. Также нужно установить компонент для создания инфраструктуры открытых ключей (PKI), для этого мы создадим свой центр сертификации.

Обновите индекс пакетов:

sudo apt update

Чтобы установить необходимые пакеты, введите:

sudo apt install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins

Дополнительный пакет libcharon-extauth-plugins позволяет разным клиентам авторизоваться по общему имени и паролю.

2: Создание центра сертификации

Для идентификации клиентов серверу IKEv2 нужны сертификаты. Поэтому пакет strongswan-pki поставляется с отдельной утилитой pki для генерирования центра сертификации и самих сертификатов сервера.

Для начала создайте каталоги для хранения всех этих компонентов. Структура каталогов совпадает с некоторыми каталогами в /etc/ipsec.d, куда мы позже переместим созданные нами файлы.

mkdir -p ~/pki/{cacerts,certs,private}

Заблокируйте доступ к этим файлам:

chmod 700 ~/pki

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

pki --gen --type rsa --size 4096 --outform pem > ~/pki/private/ca-key.pem

Теперь можно создать root ЦС и использовать ключ для подписи сертификата root:

pki --self --ca --lifetime 3650 --in ~/pki/private/ca-key.pem \
--type rsa --dn "CN=VPN root CA" --outform pem > ~/pki/cacerts/ca-cert.pem

Флаг –lifetime 3650 задает срок действия root-сертификата ЦС, в данном случае это 10 лет. Как правило, такой сертификат не меняется, в противном случае его придется повторно распространять между всеми серверами и клиентами, которые зависят от этого ЦС. Потому мы установили такой продолжительный срок действия для этого сертификата.

Вы можете изменить значение флага –dn (distinguished name) и указать свою страну, организацию и имя. В данном случае параметр CN (common name) – просто идентификатор, вы можете просто придумать его, он не должен совпадать с чем-либо в вашей инфраструктуре.

Теперь нужно создать сертификат для сервера VPN.

3: Генерирование сертификата для VPN-сервера

Создайте сертификат и ключ для сервера VPN, с помощью которого клиенты смогут проверить его подлинность.

Чтобы создать закрытый ключ, введите команду:

pki --gen --type rsa --size 4096 --outform pem > ~/pki/private/server-key.pem

Затем создайте сертификат для VPN-сервера и подпишите его с помощью ЦС, который вы создали в предыдущем разделе. Запустите следующий набор команд, предварительно указав в параметрах CN (Common Name) и SAN (Subject Alternate Name) ваше доменное имя или IP-адрес сервера.

pki --pub --in ~/pki/private/server-key.pem --type rsa \
| pki --issue --lifetime 1825 \
--cacert ~/pki/cacerts/ca-cert.pem \
--cakey ~/pki/private/ca-key.pem \
--dn "CN=server_domain_or_IP" --san server_domain_or_IP \
--flag serverAuth --flag ikeIntermediate --outform pem \
>  ~/pki/certs/server-cert.pem

Примечание: Если вы используете IP-адрес вместо домена, вам нужно указать несколько записей –san. Строку в предыдущем блоке команд, где вы указываете Distinguished Name (–dn …), необходимо дополнить такой записью:

--dn "CN=IP address --san @IP_address --san IP_address \

Эта дополнительная запись –san @IP_address нужна для тех клиентов, которые при проверке подлинности сертификата ищут и запись DNS, и запись IP-адреса сервера.

Параметр –flag serverAuth указывает, что сертификат будет явно использоваться для аутентификации сервера перед установкой зашифрованного туннеля. Параметр –flag ikeIntermediate используется для поддержки старых клиентов macOS.

Теперь, когда мы сгенерировали все файлы TLS/SSL, необходимые для StrongSwan, мы можем переместить их в правильное место, в каталог /etc/ipsec.d:

sudo cp -r ~/pki/* /etc/ipsec.d/

Теперь у вас есть сертификаты, которые защитят взаимодействие клиента и сервера. Кроме того, с их помощью клиенты смогут подтвердить подлинность VPN-сервера.

4: Настройка StrongSwan

У StrongSwan есть стандартный конфигурационный файл с примерами настроек. Прежде чем внести какие-либо изменения, создайте его резервную копию, чтобы иметь доступ к параметрам по умолчанию, если что-то пойдет не так.

sudo mv /etc/ipsec.conf{,.original}

Создайте новый файл:

sudo nano /etc/ipsec.conf

Примечание: В этом разделе по настройке серверной части VPN вы столкнетесь с параметрами, относящимися к левой и правой сторонам соединения (параметры left и right). В контексте IPSec VPN левая сторона по соглашению относится к локальной системе (в нашем случае к серверу). Правая сторона в этих настройках относится к удаленным клиентам, таким как телефоны и другие компьютеры.

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

Настройте регистрацию состояний демона (это пригодится при отладке и устранении неполадок) и разрешите резервные соединения. Добавьте эти строки в файл:

config setup
charondebug="ike 1, knl 1, cfg 0"
uniqueids=no

Затем нужно добавить конфигурации для VPN. Включите VPN-туннели IKEv2 и настройте автоматическую загрузку этого раздела конфигураций при запуске. Добавьте следующие строки в файл:

. . .
conn ikev2-vpn
auto=add
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes

Теперь настройте выявление нерабочих серверов.

. . .
conn ikev2-vpn
. . .
dpdaction=clear
dpddelay=300s
rekey=no

Затем мы настроим параметры IPSec левой – серверной – стороны. Все эти параметры гарантируют, что сервер сможет принимать подключения от клиентов и правильно идентифицироваться. Прежде чем поместить эти параметры в файл /etc/ipsec.conf, давайте посмотрим, что они делают и почему они используются:

  • left=%any: значение %any позволяет серверу использовать сетевой интерфейс, через который он принимает входящие соединения, для последующего взаимодействия с клиентами. Например, если вы подключаете клиента через частную сеть, сервер будет использовать внутренний IP-адрес, на который он будет получать трафик для остальной части соединения.
  • leftid=@server_domain_or_IP: эта опция определяет имя, которое сервер представляет клиентам. В сочетании со следующей опцией leftcert опция leftid гарантирует, что настроенное здесь имя сервера совпадает с Distinguished Name (DN), содержащимся в публичном сертификате.
  • leftcert=server-cert.pem: этот параметр определяет путь к публичному сертификату для сервера, который вы настроили в разделе 3. Без него сервер не сможет аутентифицировать себя с клиентами или завершить согласование настройки IKEv2.
  • leftsendcert=always: значение always гарантирует, что любой клиент, который подключается к серверу, всегда будет получать копию публичного сертификата сервера как часть начальной установки соединения.
  • leftsubnet=0.0.0.0/0: это последняя левая опция, она сообщает клиентам о подсетях, доступных на сервере. В этом случае значение 0.0.0.0/0 используется для представления всего набора IPv4-адресов, а это означает, что сервер по умолчанию позволяет клиентам отправлять весь свой трафик через VPN.

Теперь, когда вы знакомы с каждым из параметров левой стороны, добавьте их в файл:

. . .
conn ikev2-vpn
. . .
left=%any
leftid=@server_domain_or_IP
leftcert=server-cert.pem
leftsendcert=always
leftsubnet=0.0.0.0/0

Примечание: Если в параметре leftid в качестве ID вы хотите использовать домен VPN-сервера, добавьте после = символ @:

. . .
leftid=@vpn.example.com
. . .

Если вы хотите использовать IP, просто укажите его:

. . .
leftid=your_server_ip
. . .

Затем нужно настроить правую –клиентскую – сторону соединения IPSec. Каждый из последующих параметров сообщает серверу, как принимать соединения от клиентов, как клиенты должны проходить аутентификацию на сервере, а также задает диапазоны внутренних IP-адресов и DNS-серверы, которые будут использовать клиенты. Давайте рассмотрим эти параметры подробнее:

  • right=%any: значение %any для правой стороны соединения позволяет серверу принимать входящие соединения от любого удаленного клиента.
  • rightid=%any: эта опция гарантирует, что сервер не будет отклонять соединения от клиентов, которые предоставляют идентификационные данные, до установления зашифрованного туннеля.
  • rightauth=eap-mschapv2: этот параметр настраивает метод аутентификации, который будут использовать клиенты. Значение eap-mschapv2 используется здесь для широкой совместимости и для поддержки таких клиентов, как устройства Windows, macOS и Android.
  • rightsourceip=10.10.10.0/24 Этот параметр позволяет серверу присваивать клиентам внутренние IP-адреса из пула IP-адресов 10.10.10.0/24.
  • rightdns=8.8.8.8,8.8.4.4: эти IP-адреса являются общедоступными DNS преобразователями Google. Вы можете изменить это значение, если хотите использовать любые другие доступные преобразователи (другие публичные преобразователи, преобразователи VPN-сервера и так далее).
  • rightsendcert=never: этот параметр сообщает серверу, что для аутентификации клиентам не нужно отправлять сертификат.

Теперь, когда вы знакомы со всеми необходимыми опциями правой стороны, добавьте следующие строки в /etc/ipsec.conf:

. . .
conn ikev2-vpn
. . .
right=%any
rightid=%any
rightauth=eap-mschapv2
rightsourceip=10.10.10.0/24
rightdns=8.8.8.8,8.8.4.4
rightsendcert=never

Сервер StrongSwan должен запрашивать учётные данные пользователя при подключении клиента. Для этого добавьте:

. . .
conn ikev2-vpn
. . .
eap_identity=%identity

Затем добавьте следующие строки для поддержки клиентов Linux, Windows, macOS, iOS и Android. Эти строки определяют различные алгоритмы обмена ключами, хеширования, аутентификации и шифрования (обычно называемые наборами шифров), которые StrongSwan позволит использовать различным клиентам:

. . .
conn ikev2-vpn
. . .
ike=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
esp=chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1!

Список шифров следует разделить запятыми (например, chacha20poly1305-sha512-curve25519-prfsha512 – это первый набор, а aes256gcm16-sha384-prfsha384-ecp384 – второй, и между ними должна стоять запятая). Перечисленные здесь наборы шрифтов обеспечивают наиболее широкий диапазон совместимости для клиентов Windows, macOS, iOS, Android и Linux.

В результате конфигурационный файл будет выглядеть так:

config setup
charondebug="ike 1, knl 1, cfg 0"
uniqueids=no
conn ikev2-vpn
auto=add
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
dpdaction=clear
dpddelay=300s
rekey=no
left=%any
leftid=@server_domain_or_IP
leftcert=server-cert.pem
leftsendcert=always
leftsubnet=0.0.0.0/0
right=%any
rightid=%any
rightauth=eap-mschapv2
rightsourceip=10.10.10.0/24
rightdns=8.8.8.8,8.8.4.4
rightsendcert=never
eap_identity=%identity
ike=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
esp=chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1!

Сохраните и закройте файл.

5: Настройка аутентификации VPN

Сейчас VPN-сервер поддерживает соединения клиентов. Теперь нужно создать учётные данные, с помощью которых пользователи смогут проходить аутентификацию. Настройка аутентификации происходит в файле ipsec.secrets. В него нужно будет внести следующие поправки:

  • Указать, где StrongSwan сможет найти закрытый ключ к сертификату сервера, с помощью которого сервер будет выполнять аутентификацию.
  • Добавить список пользователей, которые могут подключаться к VPN.

Откройте файл:

sudo nano /etc/ipsec.secrets

Укажите путь к закрытому ключу:

: RSA "server-key.pem"

Затем укажите учётные данные пользователей. Сервер StrongSwan должен разрешать этим пользователям подключаться из любой точки.

your_username : EAP "your_password"

Примечание: Вместо your_username и your_password укажите свои учётные данные (имя пользователя и пароль).

Сохраните и закройте файл.

Теперь можно перезапустить сервис VPN, чтобы обновить параметры.

sudo systemctl restart strongswan-starter

6: Настойка брандмауэра и IP forwarding

Теперь нужно настроить брандмауэр для поддержки VPN-трафика.

Если вы включили UFW в мануале по начальной настройке, у вас уже есть базовые профили. Если вы не включили базовый брандмауэр ранее, сделайте это сейчас:

sudo ufw allow OpenSSH
sudo ufw enable

Затем добавьте правило для поддержки UDP трафика по стандартным портам IPSec, 500 и 4500:

sudo ufw allow 500,4500/udp

Теперь откройте конфигурационный файл UFW и добавьте политики нижнего уровня для маршрутизации и форвардинга пакетов IPSec. Но для начала нужно определить сетевые интерфейсы, по которым происходит доступ в интернет на данной машине. Для этого введите:

ip route show default

Открытый интерфейс указывается после слова dev (в нашем случае это eth0):

default via your_server_ip dev eth0 proto static

Теперь откройте файл /etc/ufw/before.rules. Правила, перечисленные в этом файле, добавляются к правилам брандмауэра перед базовыми правилами ввода и вывода. Они используются для настройки преобразования сетевых адресов (NAT), чтобы сервер мог правильно маршрутизировать соединения между клиентами и интернетом.

sudo nano /etc/ufw/before.rules

В начале файла (перед строкой *filter) укажите следующий блок конфигураций.

Вместо eth0 укажите имя вашего интерфейса, которое вы узнали с помощью команды ip route. Строки *nat создают правила, с помощью которых брандмауэр может правильно маршрутизировать и управлять трафиком между VPN-клиентами и Интернетом. Строки *mangle изменяют максимальный размер сегмента пакета, чтобы предупредить возможные проблемы с отдельными VPN клиентами.

*nat
-A POSTROUTING -s 10.10.10.0/24 -o eth0 -m policy --pol ipsec --dir out -j ACCEPT
-A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
COMMIT
*mangle
-A FORWARD --match policy --pol ipsec --dir in -s 10.10.10.0/24 -o eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
COMMIT
*filter
:ufw-before-input - [0:0] :ufw-before-output - [0:0] :ufw-before-forward - [0:0] :ufw-not-local - [0:0] . . .

После определений *filter и цепочек добавьте такие строки:

. . .
*filter
:ufw-before-input - [0:0] :ufw-before-output - [0:0] :ufw-before-forward - [0:0] :ufw-not-local - [0:0] -A ufw-before-forward --match policy --pol ipsec --dir in --proto esp -s 10.10.10.0/24 -j ACCEPT
-A ufw-before-forward --match policy --pol ipsec --dir out --proto esp -d 10.10.10.0/24 -j ACCEPT

Эти строки позволяют брандмауэру поддерживать форвардинг трафика ESP (Encapsulating Security Payload), благодаря чему клиенты VPN могут подключиться. ESP обеспечивает дополнительную защиту пакетов VPN при пересечении ненадежных сетей.

Сохраните и закройте файл.

Прежде чем перезапустить брандмауэр, нужно отредактировать настройки ядра, чтобы разрешить перенаправление между интерфейсами. Для этого отредактируйте файл /etc/ufw/sysctl.conf.

В файле нужно сделать следующее:

  • Включить пересылку пакетов IPv4.
  • Отключить Path MTU Discovery, чтобы предотвратить фрагментацию пакетов.
  • Отключить поддержку icmp-редиректов, чтобы предупредить атаки man-in-the-middle.

Откройте файл в редакторе:

sudo nano /etc/ufw/sysctl.conf

Чтобы включить форвардинг пакетов между интерфейсами, добавьте в конец файла строку:

. . .
net/ipv4/ip_forward=1

Чтобы заблокировать получение и отправку пакетов ICMP, добавьте в конец файла эти строки:

. . .
net/ipv4/conf/all/accept_redirects=0
net/ipv4/conf/all/send_redirects=0

Отключите обнаружение пути MTU, добавив эту строку в конец файла:

. . .
net/ipv4/ip_no_pmtu_disc=1

Сохраните и закройте файл.

Перезапустите брандмауэр:

sudo ufw disable
sudo ufw enable

Подтвердите операцию, нажав Y.

7: Тестирование VPN-соединений в Windows, iOS и macOS

Теперь всё готово к работе. Пора протестировать настройку. Сначала скопируйте root сертификат на клиентские устройства, которые будут подключаться к VPN. Проще всего для этого подключиться к серверу и запросить содержимое файла сертификата:

cat /etc/ipsec.d/cacerts/ca-cert.pem

Вы получите такой вывод:

-----BEGIN CERTIFICATE-----
MIIFNDCCAxygAwIBAgIIHCsidG5mXzgwDQYJKoZIhvcNAQEMBQAwODELMAkGA1UE
. . .
H2YUdz8XNHrJHvMQKWFpi0rlEcMs+MSXPFWE3Q7UbaZJ/h8wpSldSUbQRUlphExJ
dJ4PX+MUJO/vjG1/ie6Kh25xbBAc3qNq8siiJZDwrg6vjEK7eiZ1rA==
-----END CERTIFICATE-----

Скопируйте вывод на компьютер, включая строки —–BEGIN CERTIFICATE—– и —–END CERTIFICATE—–. Сохраните эти данные в файл с описательным именем (например, ca-cert.pem). Файл должен иметь расширение .pem.

В качестве альтернативы можно использовать SFTP.

Читайте также: Использование SFTP для безопасного обмена файлами с удаленным сервером

Скопировав сертификат на компьютер, вы можете подключиться к VPN.

Подключение в Windows

Есть несколько способов импортировать корневой сертификат и настроить Windows для подключения к VPN. Первый метод использует графические инструменты, а второй – команды PowerShell, которые можно изменить в соответствии с вашей конфигурацией VPN.

Примечание: Эти инструкции были протестированы на установках Windows 10 версий 1903 и 1909.

Настройка Windows с помощью графических инструментов

Импортируйте сертификат root:

  • Нажмите WINDOWS+R, чтобы открыть диалог Run, и введите mmc.exe, чтобы запустить консоль управления Windows.
  • Из меню File перейдите в Add or Remove Snap-in, выберите в списке Certificates и нажмите Add.
  • Чтобы к VPN мог подключиться любой пользователь, выберите Computer Account и нажмите Next.
  • Настройка выполняется на локальном компьютере, потому нужно выбрать Local Computer и нажать Finish.
  • В Console Root разверните Certificates (Local Computer) → Trusted Root Certification Authorities и выберите Certificates.
  • В меню Action выберите All Tasks и нажмите Import, чтобы вызвать мастер импортирования сертификатов. Нажмите Next.
  • В поле File to Import выберите файл сертификата, который вы скопировали ранее. Нажмите Next.
  • Убедитесь, что в Certificate Store выбрано Trusted Root Certification Authorities. Нажмите Next.
  • Нажмите Finish, чтобы импортировать сертификат.

Чтобы настроить VPN:

  • Запустите панель управления, перейдите в Network and Sharing Center.
  • Нажмите Set up a new connection or network и выберите Connect to a workplace.
  • Выберите Use my Internet connection (VPN).
  • Введите данные сервера VPN. Укажите домен или IP сервера в поле Internet address. В Destination name укажите описательное имя VPN-соединения. Нажмите Done.

Настройка Windows с помощью PowerShell

Чтобы импортировать сертификат корневого ЦС с помощью PowerShell, сначала откройте командную строку PowerShell с правами администратора. Для этого щелкните правой кнопкой мыши значок меню «Пуск» и выберите Windows PowerShell (Admin). Вы также можете открыть командную строку от имени администратора и ввести powershell.

Затем мы импортируем сертификат с помощью командлета Import-Certificate PowerShell. В следующей команде первый аргумент –CertStoreLocation импортирует сертификат в хранилище компьютера Trusted Root Certification Authorities, чтобы все программы и пользователи могли проверить сертификат сервера VPN. Аргумент -FilePath должен указывать на место, куда вы скопировали сертификат. В следующем примере указан путь C:\Users\8host\Documents\ca-cert.pem. Убедитесь, что вы указали в команде правильное расположение сертификата.

Import-Certificate `
-CertStoreLocation cert:\LocalMachine\Root\ `
-FilePath C:\users\8host\Documents\ca-cert.pem

Команда выведет примерно такой результат:

PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root
Thumbprint                                Subject
----------                                -------
DB00813B4087E9367861E8463A60CEA0ADC5F002  CN=VPN root CA

Чтобы настроить VPN с помощью PowerShell, выполните следующую команду. Укажите домен или IP-адрес своего сервера в строке -ServerAddress. Использованные здесь флаги позволяют правильно настроить Windows с соответствующими параметрами безопасности, установленными в /etc/ipsec.conf.

Add-VpnConnection -Name "VPN Connection" `
-ServerAddress "server_domain_or_IP" `
-TunnelType "IKEv2" `
-AuthenticationMethod "EAP" `
-EncryptionLevel "Maximum" `
-RememberCredential `

Если команда выполнена успешно, вывода на экране не будет. Чтобы убедиться, что VPN настроен правильно, используйте командлет Get-VPNConnection:

Get-VpnConnection -Name "VPN Connection"

Вы получите следующий результат:

Name                  : VPN Connection
ServerAddress         : your_server_ip
AllUserConnection     : False
Guid                  : {B055A1AB-175C-4028-B4A8-D34309A2B20E}
TunnelType            : Ikev2
AuthenticationMethod  : {Eap}
EncryptionLevel       : Maximum
L2tpIPsecAuth         :
UseWinlogonCredential : False
EapConfigXmlStream    : #document
ConnectionStatus      : Disconnected
RememberCredential    : True
SplitTunneling        : False
DnsSuffix             :
IdleDisconnectSeconds : 0

По умолчанию Windows выбирает более старые и более медленные алгоритмы. Запустите командлет Set-VpnConnectionIPsecConfiguration, чтобы обновить параметры шифрования, которые Windows будет использовать для обмена ключами IKEv2 и для шифрования пакетов:

Set-VpnConnectionIPsecConfiguration -Name "VPN Connection" `
-AuthenticationTransformConstants GCMAES256 `
-CipherTransformConstants GCMAES256 `
-DHGroup ECP384 `
-IntegrityCheckMethod SHA384 `
-PfsGroup ECP384 `
-EncryptionMethod GCMAES256

Примечание: Если вы хотите удалить VPN-соединение и перенастроить его с другими параметрами, вы можете запустить командлет Remove-VpnConnection.

Remove-VpnConnection -Name "VPN Connection" -Force

Флаг -Force пропустит запрос на подтверждение операции. Вы должны отключиться от VPN, чтобы удалить соединение с помощью этой команды.

Подключение к VPN

После того как вы импортировали сертификат и настроили VPN, ваше новое VPN-соединение появится в списке доступных сетей. Выберите VPN и нажмите Connect. Вам будет предложено ввести имя пользователя и пароль. Введите их, нажмите OK, и вы подключитесь к этой сети.

Подключение в macOS

Чтобы импортировать сертификат:

  • Дважды кликните по файлу сертификата. Появится окно Keychain Access с сообщением «Keychain Access is trying to modify the system keychain. Enter your password to allow this».
  • Введите пароль и нажмите Modify Keychain.
  • Дважды кликните по импортированному сертификату VPN. На экране появится окно свойств, где нужно выбрать уровень доверия. Установите Always Trust в IP Security (IPSec). Система снова запросит пароль.

Чтобы настроить VPN-соединение на устройстве macOS:

  • В System Preferences выберите Network. Нажмите кнопку с плюсом.
  • В появившемся окне в поле Interface укажите VPN, в VPN Type выберите IKEv2 и выберите имя соединения.
  • В полях Server и Remote ID укажите домен или IP сервера. Поле Local ID оставьте пустым.
  • В Authentication Settings выберите Username и введите имя и пароль своего пользователя VPN. Нажмите OK.
  • Нажмите Connect, чтобы подключиться к VPN.

Подключение в Ubuntu

Чтобы подключиться к VPN в Ubuntu, нужно настроить StrongSwan как сервис или же использовать команду каждый раз, когда вам нужно подключиться.

StrongSwan как сервис

Обновите индекс локальных пакетов:

sudo apt update

Установите StrongSwan:

sudo apt install strongswan libcharon-extra-plugins

Скопируйте сертификат ЦС в каталог /etc/ipsec.d/cacerts:

sudo cp /tmp/ca-cert.pem /etc/ipsec.d/cacerts

Отключите StrongSwan, чтобы VPN не включался автоматически.

sudo systemctl disable --now strongswan-starter

Затем откройте в редакторе этот файл:

sudo nano /etc/ipsec.conf

Укажите имя и пароль пользователя VPN в файле /etc/ipsec.secrets:

your_username : EAP "your_password"

Затем добавьте в файл такие конфигурации:

config setup
conn ikev2-rw
right=server_domain_or_IP
# This should match the `leftid` value on your server's configuration
rightid=server_domain_or_IP
rightsubnet=0.0.0.0/0
rightauth=pubkey
leftsourceip=%config
leftid=username
leftauth=eap-mschapv2
eap_identity=%identity
auto=start

Чтобы подключиться к VPN, введите:

sudo systemctl start strongswan-starter

Чтобы отключиться, введите:

sudo systemctl stop strongswan-starter

Простой клиент charon-cmd для одноразового подключения

Чтобы управлять StrongSwan как сервисом, вам необходимо выполнить следующие шаги.

Сначала обновите индекс локальных пакетов:

sudo apt update

Установите charon-cmd и связанные с ним пакеты:

sudo apt install strongswan libcharon-extra-plugins

Создайте копию сертификата ЦС в каталоге /etc/ipsec.d/cacerts, чтобы клиент мог проверить подлинность сервера.

sudo cp /tmp/ca-cert.pem /etc/ipsec.d/cacerts

Подключитесь к VPN с помощью charon-cmd, указав сертификат CA, домен или IP сервера VPN и имя пользователя:

sudo charon-cmd --cert ca-cert.pem --host vpn_domain_or_IP --identity your_username

По запросу ведите свой пароль. Чтобы закрыть соединение, нажмите CTRL+C.

Подключение в iOS

Чтобы настроить VPN-соединение на устройстве iOS:

  • Отправьте себе электронное письмо с сертификатом root.
  • Откройте письмо на устройстве iOS и нажмите на прикрепленный файл сертификата, нажмите Install и введите пароль. После завершения нажмите Done.
  • Откройте Settings → General → VPN и выберите Add VPN Configuration. На экране появится окно настройки VPN.
  • Нажмите Type и выберите IKEv2.
  • В поле Description укажите короткое имя VPN-соединения на свое усмотрение.
  • В полях Server и Remote ID укажите доменное имя или IP сервера. Поле Local ID можно оставить пустым.
  • Введите имя пользователя и пароль в разделе Authentication и нажмите Done.
  • Выберите только что созданное VPN-соединение, нажмите переключатель в верхней части страницы, и вы подключитесь.

Подключение в Android

Импортируйте сертификат:

  • Отправьте себе электронное письмо с сертификатом. Сохраните сертификат в папку загрузок.
  • Загрузите StrongSwan VPN клиент.
  •  Откройте приложение. В правом верхнем углу нажмите «more» (иконка с тремя точками) и выберите CA certificates.
  • Вправом верхнем углу снова нажмите «more» и выберите Import certificate.
  • Найдите нужный сертификат CA в папке загрузок и импортируйте его в приложение.

Чтобы настроить VPN-соединение:

  • В верхней панели приложения нажмите ADD VPN PROFILE.
  • В Server укажите домен или внешний IP-адрес сервера VPN.
  • Выберите IKEv2 EAP (Username/Password) как VPN Type.
  • Заполните Username Password.
  • Снимите флажок Select automatically в разделе CA certificate и кликните Select CA certificate. Откройте вкладку IMPORTED и выберите импортированный CA.
  • По желанию можно заполнить Profile name (optional) – укажите более описательное имя.

После этого кликните по созданному профилю в приложении StrongSwan.

Устранение неполадок

Если вы не можете импортировать сертификат, убедитесь, что он находится в файле с расширением .pem, а не .pem.txt.

Если у вас не получается подключиться к VPN, проверьте правильность доменного имени сервера или IP-адреса. Домен или IP должен совпадать со значением, указанным в параметре common name (CN) во время создания сертификата. Если они не совпадают, вы не сможете подключиться к VPN. К примеру, если в сертификате (в CN) вы указали vpn.example.com, вы должны использовать домен vpn.example.com при создании подключения к VPN.

Если вы указывали доменное имя, тогда также нужно проверить параметры VPN и убедиться, что в leftid перед доменом стоит символ @:

leftid=@vpn.example.com

Если же вы указывали IP, убедитесь, что символа @ перед адресом нет. Также убедитесь, что при создании файла server-cert.pem вы включили флаги –san @IP_address и –san IP_address

Цели статьи

  1. Подготовить из исходников все зависимости.
  2. Установить asterisk 16 из исходников.
  3. Запустить asterisk и убедиться в его работоспособности.

Данная статья является частью единого цикла статьей про сервер Centos.

Введение

Устанавливать Asterisk 16 на Centos 8 будем из исходников. Это не для того, чтобы показать олдскул и крутость самостоятельной сборки софта. Это вынужденная мера. Всегда, когда есть возможность установить из пакетов, лучше ей воспользоваться. Либо можно собрать свой пакет и ставить уже из него. Сборка софта из исходников крайняя мера, когда готового пакета просто не существует.

Я устанавливаю версию 16, хотя есть уже 17-я. Именно 16-я версия имеет статус LTS, то есть длительная поддержка. Если вам не нужны новые фичи промежуточных версий, рекомендую всегда ставить lts версии.

Для установки Asterisk 16 на свежую Centos 8 я не нашел репозитория, где бы были собраны все пакеты с зависимостями для быстрой и безпроблемной установки. Так что будем по старинке собирать все руками. Ничего сложного тут нет. Все примерно так же, как и в прошлых версиях. Каких-то новых сложностей или нюансов я не заметил.

Если у вас еще нет готового сервера, то рекомендую мои статьи по установке и настройке Centos.

Для отладки и тестирования работы voip я рекомендую сервис Zadarma. Плюс его в том, что после регистрации вы получите настройки пира для внутренней сети оператора. И внутри этой сети вы можете бесплатно звонить. Например, я одного пира регистрирую на sip клиенте смартфона и с него звоню на второй аккаунт, пир от которого настроен в астериске. Таким образом эмулирую внешний звонок. Удобно отлаживать различные конфигурации звонков, не требуя платного подключения.

Подготовка сервера

Первым делом надо отключить SELinux. Открываем файл /etc/sysconfig/selinux и меняем параметр.

# mcedit /etc/sysconfig/selinux
SELINUX=disabled

Для применения настройки нужно перезагрузиться, либо временно приостановить selinux.

# setenforce 0

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

# dnf install epel-release

Дальше идет мета пакет Development Tools со всем необходимым для сборки из исходников.

# dnf groupinstall "Development Tools"

Установка Development tools

И еще некоторые зависимости, которые будут нужны.

# dnf install git wget net-tools sqlite-devel psmisc ncurses-devel libtermcap-devel newt-devel libxml2-devel libtiff-devel gtk2-devel libtool libuuid-devel subversion kernel-devel kernel-devel-$(uname -r) crontabs cronie-anacron mariadb mariadb-server

Установка зависимостей asterisk 16

Настройте mysql сервер, задав пароль для root.

# systemctl start mariadb
# systemctl enable mariadb
# /usr/bin/mysql_secure_installation

На этом подготовка закончена.

Устанавливаем Jansson и pjsip

# cd ~
# git clone https://github.com/akheron/jansson.git
# cd jansson
# autoreconf -i
# ./configure --prefix=/usr/
# make && make install

Установка Jansson

# cd ~
# git clone https://github.com/pjsip/pjproject.git
# cd pjproject
# ./configure CFLAGS="-DNDEBUG -DPJ_HAS_IPV6=1" --prefix=/usr --libdir=/usr/lib64 --enable-shared --disable-video --disable-sound --disable-opencore-amr
# make dep && make && make install
# ldconfig

Установка pjsip

Все готово к установке непосредственно Astersik

Установка Asterisk 16

Я буду устанавливать LTS версию Asterisk 16. Советую для долгосрочного использования всегда использовать LTS версии. Они в целом стабильнее и дольше срок поддержки. Идем на страницу https://www.asterisk.org/downloads/asterisk/all-asterisk-versions и копируем ссылку на нужную версию. Загружаем ее на сервер.

# cd ~
# wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-16-current.tar.gz
# tar xfz asterisk-16-current.tar.gz
# cd asterisk-16*/
# contrib/scripts/install_prereq install
# contrib/scripts/get_mp3_source.sh

Устанавливаем на centos 8 пакет libedit-devel.

# dnf config-manager --set-enabled powertools
# dnf install libedit-devel

Собираем asterisk.

# ./configure --libdir=/usr/lib64
# make menuselect

Установка Asterisk 16 на Centos 8

Выбирайте необходимые модули и звуки, в зависимости от того, что вам нужно. Я в общем случае указываю:

  • Add-ons: format_mp3, res_config_mysql.
  • Core Sound Packages: русские звуки RU-WAV.
  • Music On Hold File Packages: звук WAV.
  • Extras Sound Packages: английский EN-WAV, русского к сожалению нет.

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

Продолжаем установку:

# make && make install && make samples && make config
# ldconfig

Создание пользователя asterisk и запуск

По-умолчанию, asterisk установлен от root и будет запускаться от него же. Я предлагаю для этого создать отдельного пользователя и запускать астериск от него. Для этого создаем пользователя и добавляем его в некоторые группы.

# groupadd asterisk
# useradd -r -d /var/lib/asterisk -g asterisk asterisk
# usermod -aG audio,dialout asterisk
# chown -R asterisk.asterisk /etc/asterisk /var/{lib,log,spool}/asterisk /usr/lib64/asterisk

Настраиваем Asterisk на запуск под этим пользователем. Для этого добавляем в конфиг /etc/sysconfig/asterisk параметры:

AST_USER="asterisk"
AST_GROUP="asterisk"

Теперь добавим примерно то же самое в сам конфиг астера /etc/asterisk/asterisk.conf.

runuser = asterisk
rungroup = asterisk

Пробуем запустить asterisk:

# systemctl start asterisk

Если нет сообщений об ошибке, скорее всего все в порядке. Проверяем статус службы.

# systemctl status asterisk

Запуск asterisk

Asterisk запустился, но есть небольшие ошибки.

radcli: rc_read_config: rc_read_config: can't open /etc/radiusclient-ng/radiusclient.conf: No such file or directory

Связаны с тем, что в конфигах неверно указан путь к radiusclient. Сейчас исправим это.

# sed -i 's";\[radius\]"\[radius\]"g' /etc/asterisk/cdr.conf
# sed -i 's";radiuscfg => /usr/local/etc/radiusclient-ng/radiusclient.conf"radiuscfg => /etc/radcli/radiusclient.conf"g' /etc/asterisk/cdr.conf
# sed -i 's";radiuscfg => /usr/local/etc/radiusclient-ng/radiusclient.conf"radiuscfg => /etc/radcli/radiusclient.conf"g' /etc/asterisk/cel.conf

Перезапускаем asterisk и убеждаемся, что ошибок нет. Проверим, все ли в порядке, зайдя в консоль:

# asterisk -r

Проверка работы

Если получили такой же вывод команды, значит все в порядке, астериск 16 установлен. Добавим его теперь в автозагрузку.

# systemctl enable asterisk

Видео

Для тех, у кого что-то не получается или не понятно, как сделать, записал видео по приведенной инструкции. Видео подтверждает, что материал актуален и если делать по нему, то все получится.

Настройка брандмауэра

Перед тем, как мы начнем настройку, убедимся, что для почтового сервера у нас открыты необходимые порты в брандмауэре. В зависимости от используемой системы управления netfilter команды будут отличаться.

Для Iptables

Как правило, Iptables используется для систем на базе Debian.

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

iptables -I INPUT 1 -p tcp --match multiport --dports 25,465,587 -j ACCEPT

iptables -I INPUT 1 -p tcp --match multiport --dports 110,143,993,995 -j ACCEPT

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

  • 25 — стандартный SMTP через STARTTLS;
  • 110 — стандартный POP3 через STARTTLS;
  • 143 — стандартный IMAP через STARTTLS;
  • 465 — защищенный SMTP через SSL/TLS;
  • 587 — защищенный SMTP через STARTTLS;
  • 993 — защищенный IMAP через SSL/TLS;
  • 995 — защищенный POP3 через SSL/TLS.

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

apt-get install iptables-persistent

И выполняем команду:

netfilter-persistent save

Firewalld

Firewalld, в основном, используется в системах на базе Red Hat.

Для открытия нужных нам портов вводим команды:

firewall-cmd --permanent --add-port=25/tcp --add-port=465/tcp --add-port=587/tcp

firewall-cmd --permanent --add-port=110/tcp --add-port=143/tcp --add-port=993/tcp --add-port=995/tcp

И применяем настройки:

firewall-cmd --reload

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

  • 25 — стандартный SMTP через STARTTLS;
  • 110 — стандартный POP3 через STARTTLS;
  • 143 — стандартный IMAP через STARTTLS;
  • 465 — защищенный SMTP через SSL/TLS;
  • 587 — защищенный SMTP через STARTTLS;
  • 993 — защищенный IMAP через SSL/TLS;
  • 995 — защищенный POP3 через SSL/TLS.

1. Настройка аутентификации на Postfix

Аутентификация на postfix будет выполняться методом dovecot. Для этого устанавливаем его. Заодно, устанавливаем и postfix (на случай, если его нет еще в системе). В зависимости от используемой операционной системы используем разные команды.

а) если используем Ubuntu / Debian:

apt-get update

apt-get install postfix dovecot-imapd dovecot-pop3d

б) если используем CentOS / Red Hat:

yum install postfix dovecot

После установки пакетов, разрешаем автозапуск dovecot и postfix:

systemctl enable postfix dovecot

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

vi /etc/postfix/main.cf

Добавляем строки (или меняем значения):

smtpd_sasl_type = dovecot
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_relay_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_unauth_destination

* где:

  • smtpd_sasl_type — тип плагина, который используется для SASL-аутентификации. Командой postconf -a мы можем получить список механизмов аутентификации, которые поддерживаются почтовой системой.
  • smtpd_sasl_auth_enable — разрешает или запрещает аутентификацию по механизму SASL.
  • smtpd_sasl_path — путь до файла для обмена аутентификационной информацией. Используется для взаимодействия нескольких систем — в нашем примере Postfix + Dovecot.
  • smtpd_relay_restrictions — правила разрешения и запрета использования MTA при пересылке. В нашем случае:
    • permit_mynetworks — разрешить отправку с компьютеров, чьи IP-адреса соответствуют настройке mynetworks.
    • permit_sasl_authenticated — разрешить отправку писем тем, кто прошел авторизацию.
    • reject_unauth_destination — запретить всем, кто не прошел проверку подлинности.

Проверяем корректность настройки:

postconf > /dev/null

Если команда не вернула ошибок, перезапускаем Postfix:

systemctl restart postfix

Переходим к настройке dovecot — открываем файл:

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

... и приводим опцию service auth к следующему виду:

service auth {
  ...
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
  ...
}

* если соответствующей секции unix_listener нет, то ее нужно создать. Обратите внимание, что для обмена аутентификационными данными мы применяем файл /var/spool/postfix/private/auth, который в конфигурационном файле postfix был указан, как private/auth.

Отключаем требование ssl для аутентификации (на текущем этапе нам это не нужно):

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

Проверяем, чтобы значение ssl не было required:

ssl = yes

* нас устроит оба варианта — yes или no.

Настройки аутентификации приводим к следующему виду:

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

auth_mechanisms = plain login

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

В этом же файле проверяем, что снят комментарий со следующей строки:

!include auth-system.conf.ext

Проверяем корректность настройки dovecot:

doveconf > /dev/null

Если команда ничего не вернула, перезапускаем сервис:

systemctl restart dovecot

В качестве логина и пароля можно использовать любую системную учетную запись. Создадим ее для теста:

useradd smtptest

passwd smtptest

Мы настроили простую аутентификацию на сервере SMTP. Для проверки можно воспользоваться любым почтовым клиентом. Пример настройки thunderbird:

Пример настройки почтового клиента Mozilla Thunderbird

Пробуем отправить письмо. Отправка должна потребовать ввода логина и пароль — используем аутентификационные данные для записи, созданной выше.

Мы завершили настройку аутнтификации на postfix при отправке письма. Добавим проверку данных через LDAP.

2. Подключение LDAP

И так, наш сервер требует ввода логина и пароля от системных учетных записей для отправки писем. Теперь сделаем так, чтобы эти учетные записи брались из LDAP (на примере Active Directory).

В службе каталогов нам нужна учетная запись со стандартными правами — ее мы будем использовать для подключения к LDAP. Создаем служебную учетную запись, например, postfix в корневом контейнере Users. Таким образом, в моем примере, это будет запись cn=postfix,cn=Users,dc=dmosk,dc=local (в домене dmosk.local).

Теперь возвращаемся на наш сервер. Если у нас Debian/Ubuntu, необходимо установить пакет dovecot-ldap:

apt-get install dovecot-ldap

Открываем файл:

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

* в системах deb файл уже будет создан и в нем будут приведены примеры настройки; в системах RPM файл будет создан новый файл.

Добавляем в него следующее:

hosts            = dmosk.local
ldap_version     = 3
auth_bind        = yes
dn               = cn=postfix,cn=Users,dc=dmosk,dc=local
dnpass           = ldap-password-for-postfix
base             = ou=Пользователи,dc=dmosk,dc=local
scope            = subtree
deref            = never

pass_filter = (&(objectCategory=Person)(sAMAccountName=%n))
user_filter = (&(objectCategory=Person)(sAMAccountName=%n))

* где:

  • hosts — имя нашего сервера ldap (в моем примере указан домен, так как по нему у меня разрешается кластер LDAP).
  • ldap_version — версия ldap. Как правило, третья.
  • auth_bind — указываем, нужно ли выполнять аутентификацию при связывании с LDAP.
  • dn — учетная запись для прохождения авторизации при связывании со службой каталогов.
  • dnpass — пароль от записи для прохождения авторизации.
  • base — базовый контейнер, в котором мы ищем наших пользователей. Нельзя использовать поиск на уровне домена. Внимательнее проверяем путь на предмет использования контейнеров (CN) или организационных юнитов (OU).
  • scope — указывает на каком уровне нужно искать пользователей:
    • subtree — во всех вложенных контейнерах.
    • onelevel — во всех вложенных контейнерах, но на один уровень.
    • base — только в контейнере, который указан в base.
  • deref — параметр означает использование поиска по разыменованным псевдонимам. К сожалению, не нашел подробного описания. Обычно, не используется.
  • pass_filter — фильтр для поиска паролей пользователей. Его формат зависит от используемой реализации LDAP. В нашем примере это Active Directory.
  • user_filter — фильтр для поиска учетных записей пользователей. Формат зависит от того, какую реализацию для LDAP мы используем.

Не знаю причину, но если для base указать корневой путь к домену, например, dc=dmosk,dc=local, наша связка не будет работать, а система вернет ошибку ... failed: Operations error.

Открываем файл:

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

Комментируем строку для использования аутентификации по системных учетных записям и снимаем комментарий для аутентификации в ldap. Получим следующий результат:

#!include auth-system.conf.ext
...
!include auth-ldap.conf.ext

Проверяем корректность настройки dovecot:

doveconf > /dev/null

И перезапускаем его:

systemctl restart dovecot

Возвращаемся к настроенному почтовому клиенту и меняем параметры для авторизации с smtptest на учетную запись из домена, например, master@dmosk.local. Проверяем отправку письма — системы должна запросить пароль и отправить письмо при успешной проверке пользователя.

Можно переходить к настройке почтовых ящиков для пользователей из LDAP.

3. Виртуальные пользователи LDAP

Для получения почты нам осталось настроить виртуальные ящики, информация о которых хранится в LDAP. Для этого выполним настройку Postfix и Dovecot.

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

groupadd -g 1024 vmail

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

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

Создаем домашнюю директорию для пользователя:

mkdir /home/mail

Задаем в качестве владельца нашего созданного пользователя:

chown vmail:vmail /home/mail

Мы будем хранить всю почту пользователей в каталоге /home/mail.

Для систем на базе Debian (Ubuntu) нужно также установить postfix-ldap:

apt-get install postfix-ldap

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

vi /etc/postfix/main.cf

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

virtual_transport = dovecot
virtual_minimum_uid = 1024
virtual_uid_maps = static:1024
virtual_gid_maps = static:1024
virtual_mailbox_base = /home/mail
virtual_mailbox_domains = dmosk.local dmosk.ru
virtual_alias_maps = ldap:/etc/postfix/ldap_virtual_alias_maps.cf
virtual_mailbox_maps = ldap:/etc/postfix/ldap_virtual_mailbox_maps.cf

* где:

  • virtual_transport — указывает куда дальше должна передаваться полученная почта для обработки. В нашем примере, после постфикса она отправится в dovecot.
  • virtual_minimum_uid — с какого номера присваивать идентификаторы пользователям.
  • virtual_uid_maps — от какого идентификатора пользователя будет работать доставка сообщений. В нашем примере это 1024, который присвоен пользователю vmail.
  • virtual_gid_maps — идентификатор группы пользователя для доставки сообщений — 1024 (vmail).
  • virtual_mailbox_base — каталог, где будут храниться почтовые ящики пользователей и сами письма.
  • virtual_mailbox_domains — домены, для которых наш сервер будет принимать почту. Если их несколько, перечисляем через пробел.
  • virtual_alias_maps — путь хранения алиасов для виртуальных пользователей, а также формат хранения — в нашем случае ldap.
  • virtual_mailbox_maps — формат и путь хранения почтовых ящиков для виртуальных пользователей.

В нашем конфиге создано 2 карты для получения данных из AD — ldap_virtual_alias_maps.cf и ldap_virtual_mailbox_maps.cf. Создаем эти файлы с описанием того, как нужно извлекать данные.

Создаем файл для получения алиасов:

vi /etc/postfix/ldap_virtual_alias_maps.cf

version = 3
server_host = ldap://dmosk.local/
search_base = ou=Пользователи,dc=dmosk,dc=local
query_filter = (&(objectClass=person)(mail=%s))
result_attribute = mail
scope = sub
bind = yes
bind_dn = cn=postfix,cn=Users,dc=dmosk,dc=local
bind_pw = dmosk.ru135

Создаем файл для получения почтовых ящиков: 

vi /etc/postfix/ldap_virtual_mailbox_maps.cf

version = 3
server_host = ldap://dmosk.local/
search_base = ou=Пользователи,dc=dmosk,dc=local
query_filter = (&(objectClass=person)(mail=%s))
result_filter = %s
result_attribute = mail
special_result_attribute = member
scope = sub
bind = yes
bind_dn = cn=postfix,cn=Users,dc=dmosk,dc=local
bind_pw = dmosk.ru135

* где для обоих файлов:

  • version — версия ldap. Как правило, третья.
  • server_host — имя нашего сервера ldap (в моем примере указан домен, так как по нему у меня разрешается кластер LDAP).
  • search_base — базовый контейнер, в котором мы ищем наших пользователей.
  • query_filter — фильтр для поиска учетных записей пользователей. Формат зависит от того, какую реализацию для LDAP мы используем.
  • result_filter — (или result_format) формат для вывода найденных результатов. Рассмотрим возможные варианты для master@dmosk.local:
    • %s — возвращает результат как есть, то есть, master@dmosk.local.
    • %u — упускает домен, то есть, master.
    • %d — возвращает доменную часть, то есть, dmosk.local.
  • result_attribute — атрибут LDAP, который должен читать postfix. В реализации от Microsoft это mail.
  • special_result_attribute — результат может содержать группу, по которой необходимо провести рекурсивный поиск. В этом случае Postfix будет выполнять данную рекурсию для атрибута member.
  • scope — глубина поиска. Как и рассмотренная выше scope для dovecot, имеет 3 возможные значения:
    • sub — во всех вложенных контейнерах.
    • base — только в контейнере, который указан в base.
    • one — во всех вложенных контейнерах, но на один уровень.
  • bind — указываем, нужно ли выполнять аутентификацию при связывании с LDAP.
  • bind_dn — учетная запись для прохождения авторизации при связывании со службой каталогов.
  • bind_pw — пароль от записи для прохождения авторизации.

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

vi /etc/postfix/master.cf

Добавляем строки:

submission   inet  n  -  n  -  -  smtpd
  -o smtpd_tls_security_level=may
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=/var/spool/postfix/private/auth
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_local_domain=$myhostname

smtps   inet  n  -  n  -  -  smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

dovecot   unix  -  n  n  -  -  pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
  #flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver -d ${recipient}

* необходимо убедиться, что в содержимом файла нет других раскомментированных опций для 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. Возможны варианты yn и -. Прочерк означает неприменимость данного параметра к конкретному сервису.
  • второй "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 — настройки ограничения клиентских соединений. В данном примере разрешить только авторизованных.

Обтатите внимание на dovecot — в моем примере идут 2 строки с опциями: первая для систем Debian, вторая закомментирована, и она для Red Hat. Вам необходимо оставить комментарий для нужно системы, вторую строку можно закомментировать или удалить.

Проверяем корректность настроек Postfix:

postconf > /dev/null

Если ошибок нет, перезапускаем его:

systemctl restart postfix

Переходим к настройке Dovecot. Открываем файл:

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

Находим опцию mail_location и приводим ее к виду:

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

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

Открываем файл:

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

Ранее мы уже настраивали раздел service auth — допишем в него еще одну настройку:

service auth {
  ...
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
    group = vmail
  }
}

* auth-userdb — сокет для авторизации через dovecot-lda. Опция mode задает права на сокет, например, 666 позволит любому пользователю к нему подключиться; user и group задает пользователя и группу владельцев на сокет.
* обратите внимание, что unix_listener auth-userdb уже существует в открытом файле, поэтому нам нужно либо его привести к данному виду, либо закомментировать то, что было и вставить новый вариант.

Также добавим строки:

service stats {
    unix_listener stats-reader {
        user = vmail
        group = vmail
        mode = 0660
    }
    unix_listener stats-writer {
        user = vmail
        group = vmail
        mode = 0660
    }
}

* в противном случае, мы можем увидеть в логе ошибку error net_connect_unix(/var/run/dovecot/stats-writer) failed permission denied, так как у пользователя vmail не будет прав.

Идем далее — открываем файл:

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

lda_mailbox_autocreate = yes

* данной опцией мы разрешаем автоматически создавать каталоги для почтовых ящиков.

Наконец, открываем ранее настраиваемый нами файл:

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

... и добавляем: 

user_attrs = \
    =uid=1024, \
    =gid=1024

* в данном примере мы возвращаем для найденного в LDAP пользователя атрибут с идентификатором созданного пользователя vmail. Это нужно, чтобы у нас не возникло проблем с доступом к каталогу почтовых ящиков.

Проверяем корректность настройка dovecot:

doveconf > /dev/null

И перезапустим его:

systemctl restart dovecot

Пробуем отправить письмо пользователю LDAP. Почтовый сервер должен принять письмо, а в каталоге /home/mail создать папку с доменом и email пользователя.

1: Общая безопасность

Давайте рассмотрим начальные конфигурации повышения безопасности, которые позволят вам улучшить общую защиту SSH-клиента.

Резервное копирование конфигураций

Многие конфигурации безопасности клиента OpenSSH реализуются в глобальном конфигурационном файле клиента OpenSSH, /etc/ssh/ssh_config. Кроме того, некоторые конфигурации могут быть записаны в локальный конфигурационный файл SSH вашего пользователя, ~/.ssh/config.

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

sudo cp /etc/ssh/ssh_config /etc/ssh/ssh_config.bak

cp ~/.ssh/config ~/.ssh/config.bak

Это позволит сохранить резервную копию файлов в их стандартном расположении, но с расширением .bak.

Обратите внимание, ваш локальный конфигурационный файл SSH (~/.ssh/config) может не существовать, если вы не использовали его раньше. Если это так, то его можно спокойно проигнорировать.

Базовые параметры безопасности

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

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

sudo nano /etc/ssh/ssh_config

Примечание: Конфигурационный файл клиента OpenSSH включает в себя множество параметров по умолчанию. В зависимости от существующей настройки клиента некоторые из рекомендуемых параметров безопасности могут быть уже установлены.

При редактировании конфигурации некоторые параметры могут по умолчанию быть закомментированы с помощью диеза (#) в начале строки. Чтобы отредактировать эти параметры или включить закомментированную опцию, вам нужно раскомментировать их, удалив диез.

Во-первых, нужно отключить поддержку X11-forwarding по SSH, установив следующие параметры:

ForwardX11 no

ForwardX11Trusted no

X11-forwarding позволяет отображать удаленные графические приложения через SSH-соединение, однако на практике это редко используется. Отключив этот параметр, вы можете предотвратить попытки потенциально вредоносных и взломанных серверов перенаправить сессию X11 вашему клиенту, что в некоторых случаях позволяет обходить привилегии файловой системы или отслеживать локальные нажатия клавиш.

Затем мы рассмотрим возможность отключения SSH-туннелирования. SSH-туннелирование широко используется в работе, поэтому вам, возможно, придется оставить его включенным. Однако если вы не пользуетесь этой функцией, вы можете спокойно отключить ее в качестве дополнительной меры безопасности:

Tunnel no

Также стоит подумать об отключении переадресации агента SSH, если она вам не нужна, и тогда серверы не будут запрашивать локальный SSH агент для аутентификации последующих SSH-соединений:

ForwardAgent no

В большинстве случаев при подключении к серверам SSH-клиент использует парольную аутентификацию или аутентификацию по открытым ключам. Однако клиент OpenSSH также поддерживает другие методы аутентификации, и некоторые из которых включены по умолчанию. Если они не используются, их можно отключить, чтобы уменьшить поверхность потенциальной атаки:

GSSAPIAuthentication no

HostbasedAuthentication no

Если вы хотите узнать больше о дополнительных методах аутентификации, доступных в SSH, вы можете обратиться к следующим ресурсам:

  • Аутентификация GSSAPI
  • Аутентификация на основе хоста

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

# SendEnv

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

StrictHostKeyChecking ask

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

При первом подключении к новому серверу ваш SSH-клиент спросит вас, хотите ли вы принять ключ хоста и сохранить его в файле ~/.ssh/known_hosts. Очень важно проверить ключ хоста, прежде чем принимать его. Обычно эта процедура подразумевает отправку запроса администратору сервера или просмотр документации сервиса (в случае GitHub, GitLab и других подобных сервисов).

Сохраните изменения и выйдите из файла.

Мы настроили общие параметры безопасности, и теперь следует проверить синтаксис новой конфигурации, запустив SSH в тестовом режиме:

ssh -G .

Вы можете заменить символ точки в команде любым именем хоста, если вам нужно протестировать его настройки в блоках Match или Host.

Если конфигурации имеют допустимый синтаксис, команда выведет на экран параметры, которые будут применяться к этому конкретному соединению. В случае ошибки на экране появится описание проблемы.

Вам не нужно перезапускать системные сервисы, чтобы новая конфигурация вступила в силу, хотя вам придется повторно установить текущие сеансы SSH, если вы хотите, чтобы они унаследовали новые настройки.

Настройка общей безопасности клиента OpenSSH завершена. Давайте теперь посмотрим, какие шифры доступны для использования в SSH-соединениях.

2: Отключение слабых шифров OpenSSH

Сейчас мы изучим наборы шифров, доступные на вашем SSH-клиенте, и отключим поддержку устаревших шифров.

Для начала откроем глобальный конфигурационный файл в текстовом редакторе:

sudo nano /etc/ssh/ssh_config

Закомментируйте стандартную конфигурацию Ciphers, добавив в начало строки символ диеза.

Затем поместите в начало файла следующее:

Ciphers -arcfour*,-*cbc

Эта строка отключит устаревшие шифры Arcfour, а также все шифры, использующие Cipher Block Chaining (CBC), которые больше не рекомендуется использовать.

Если позже вам будет необходимо подключиться к системам, которые поддерживают только эти устаревшие шифры, вы можете явно включить требуемые шифры для определенных хостов с помощью блока Match. К примеру, чтобы включить шифр 3des-cbc для определенного хоста, можно использовать следующую настройку:

Match host legacy-server.your-domain

  Ciphers +3des-cbc

Сохраните изменения и выйдите из файла.

Сейчас, как и в разделе 1, вы можете снова протестировать новую конфигурацию клиента SSH, чтобы проверить наличие ошибок:

ssh -G .

Если вы добавили блок Match, чтобы включить устаревшие шифры для определенного хоста, вы можете также проверить эту конфигурацию во время теста, указав адрес нужного вам хоста:

ssh -G legacy-server.your-domain

Мы отключили все слабые или устаревшие шифры. Теперь пора проверить права доступа к файлам, которые использует ваш SSH-клиент.

3: Защита конфигурационных файлов и закрытых ключей

На этом этапе мы заблокируем доступ к конфигурациям и закрытым ключам клиента SSH, чтобы предотвратить случайные и намеренные вредоносные изменения или утечку закрытых ключей. Это особенно полезно при использовании одного общего клиентского устройства несколькими пользователями.

По умолчанию в новой установке Ubuntu конфигурационные файлы клиента OpenSSH настроены таким образом, что каждый пользователь может редактировать только свой собственный локальный файл (~/.ssh/config), а для редактирования общесистемной конфигурации (/etc/ssh/ssh_config) требуются права sudo или администратора.

Однако в некоторых случаях – особенно в системах, которые существуют в течение длительного времени, – эти привилегии могли быть случайно изменены или скорректированы, поэтому лучше всего перенастроить их, чтобы убедиться, что конфигурации в безопасности.

Начать можно с проверки текущего состояния привилегий для общесистемного конфигурационного файла клиента OpenSSH. Это делается с помощью команды stat, которую вы можете использовать для отображения статуса файлов или объектов файловой системы:

stat -c "%a %A %U:%G" /etc/ssh/ssh_config

Аргумент -c определяет формат вывода.

Примечание: В некоторых операционных системах, таких как macOS, нужно использовать параметр -f, а не -c.

В этом случае опция %A %a %U:%G выведет привилегии файла в восьмеричном и удобочитаемом формате, а также пользователя и группу, которым принадлежит этот файл.

Вывод будет примерно таким:

644 -rw-r--r-- root:root

В нашем случае установлены правильные привилегии, файл полностью принадлежит пользователю root, и только root имеет права на его изменение.

Читайте также: Привилегии в Linux: что это и как с ними работать

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

sudo chown root:root /etc/ssh/ssh_config

sudo chmod 644 /etc/ssh/ssh_config

Если вы теперь повторите команду stat, которую мы использовали ранее, вы увидите, что общесистемный файл конфигурации имеет правильные привилегии.

Проверка закрытых ключей

Затем вы можете повторить эту проверку для своего локального конфигурационного файла SSH-клиента, если он у вас есть:

stat -c "%a %A %U:%G" ~/.ssh/config

Вы увидите примерно следующее:

644 -rw--r--r-- user:user

Если привилегии вашего локального файла отличаются, вы должны сбросить их с помощью этих команд, как и ранее:

chown user:user ~/.ssh/config

chmod 644 ~/.ssh/config

Затем вы можете проверить привилегии каждого из закрытых ключей SSH, которые хранятся в вашем каталоге ~/.ssh, поскольку эти файлы должны быть доступны только вам и никаким другим пользователям в системе.

Начните с проверки текущих привилегий и прав собственности для каждого закрытого ключа:

stat -c "%a %A %U:%G" ~/.ssh/id_rsa

Вы должны получить такой результат:

600 -rw------- user:user

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

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

chown user:user ~/.ssh/id_rsa

chmod 600 ~/.ssh/id_rsa

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

4: Ограничение исходящего трафика с помощью списка разрешенных хостов

В последнем разделе этого мануала мы настроим список разрешений (allowlist), который ограничит хосты, к которым может подключаться ваш SSH-клиент. Это особенно полезно для многопользовательских систем, а также для инсталляционных серверов.

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

Если вы хотите ограничить исходящие соединения на сетевом уровне, вы должны использовать для этого брандмауэр. Данная тема выходит за рамки нашего руководства.

Читайте также: Основы UFW: общие правила и команды фаервола

Однако если вы хотите настроить несколько дополнительных средств защиты от сбоев, этот уровень безопасности может быть вам полезен.

Он работает на основе правил подстановки, которые хранятся в конфигурации вашего SSH-клиента, и обнуляет маршрутизацию всех исходящих подключений, кроме определенных адресов или хостов.

Следовательно, если вы когда-либо допустите ошибку в адресе сервера или попытаетесь подключиться к серверу, к которому не должны подключаться, запрос будет немедленно сброшен, что даст вам возможность обнаружить свою ошибку исправить ее.

Вы можете применить это либо на системном уровне (/etc/ssh/ssh_config), либо локально (~/.ssh/config). В этом примере мы будем использовать локальный конфигурационный файл.

Откройте или создайте файл, если он еще не существует:

nano ~/.ssh/config

В конец файла добавьте следующий блок, подставив в него список ваших доверенных IP-адресов и имен хостов:

Match host !203.0.113.1,!192.0.2.1,!server1.your-domain,!github.com,*

  Hostname localhost

Вы должны поставить перед IP-адресами или именами хостов восклицательный знак (!). Все элементы в списке нужно указывать через запятую. Последним элементом списка должна быть одна звездочка (*) без восклицательного знака.

Если на вашем компьютере также запущен SSH-сервер, вы можете использовать другое имя хоста вместо localhost, поскольку это приведет к отправке нулевых соединений на ваш локальный SSH-сервер. Вы можете указать любое имя хоста с нулевым маршрутом, например null, do-not-use или disallowed-server.

Сохраните и закройте файл после внесения изменений.

Теперь вы можете проверить, работает ли наша новая конфигурация. Для этого с помощью SSH-клиента мы попытаемся подключиться к запрещенному адресу или хосту:

ssh disallowed.your-domain

Если конфигурация работает правильно, вы сразу получите сообщение об ошибке:

Cannot connect to localhost: connection refused

Но если вы попробуете подключиться к доверенному адресу или хосту, подключение будет успешно установлено.

Только что мы успешно внедрили дополнительные средства безопасности, чтобы защититься от ошибок, связанных с человеческим фактором.