Настройка почты в Astra Linux 1.5 ALD

Исходные данные и задачи

Необходимо настроить сервер электронной почты, работающий в рамках домена Astra Linux 1.5 SE. Исходные данные:

Настройка сети

Отключаем графический менеджер управления сетевыми подключениями wicd.

chkconfig wicd off

Прописываем настройки сети в файле /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet static
    address 192.168.0.1
    netmask 255.255.255.0
    gateway 192.168.0.1
    network 192.168.0.0
    broadcast 192.168.0.255
    dns-nameservers 192.168.0.1
    dns-search local.lan

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

service networking stop && service networking start

В документации к демону networking написано, что команда restart является устаревшей и работает не так, как ожидается.

Необходимо в файле /etc/hosts прописать соответствие FQDN сервера и его IP-адреса, а также задать hostname

127.0.0.1    localhost
192.168.0.1 server.local.net server

192.168.0.101 arm01.local.net arm01
192.168.0.102 arm02.local.net arm02
192.168.0.103 arm03.local.net arm03

В файле /etc/hostname меняем краткое имя компьютера server на полное server.local.net, а также изменяем текущее значение системной переменной:

echo server.local.net > /etc/hostname
hostname server.local.net

Инициализация домена

Действуем согласно официальной инструкции от РусБиТех:

ald-init init

Появится уведомление о том, что команда init уничтожит всю базу данных LDAP и Kerberos, будут остановлены и перезапущены службы, и упадет с неба большая звезда, горящая подобно светильнику, и падет на третью часть рек и на источники вод... Отвечаем утвердительно

Попросят ввести пароли для доступа к базе данных Kerberos и пароль администратора Astra Linux Directory. Лучше записать куда-нибудь, потому что понадобится ещё не раз.

Спустя какое-то время на экране появится сообщение:

Astra Linux Directory сконфигурирована.
Сервер ALD активен.
Клиент ALD включен.

Astra Linux Directory сервер успешно инициализирован.

Установка и настройка почтовых сервисов.

Необходимо установить три пакета:

Отдельно отмечу, что сразу же после установки нужно будет запустить конфигурирование exim4.

aptitude install exim4-daemon-heavy dovecot-imapd dovecot-gssapi -y
dpkg-reconfigure exim4-config

Процесс настройки exim4 не очень сложный, но нужно правильно ответить на несколько вопросов.

Теперь нужно удалить из каталога /var/mail файл с именем пользователя, созданного при установке системы (у меня обычно administrator).

rm /var/mail/administrator

Создадим сервисы ALD для работы с почтой:

ald-admin service-add imap/server.local.lan
ald-admin sgroup-svc-add imap/server.local.lan --sgroup=mac
ald-admin sgroup-svc-add imap/server.local.lan --sgroup=mail
ald-admin service-add smtp/server.local.lan
ald-admin sgroup-svc-add smtp/server.local.lan --sgroup=mac
ald-admin sgroup-svc-add smtp/server.local.lan --sgroup=mail
ald-client update-svc-keytab imap/server.local.lan --ktfile="/var/lib/dovecot/dovecot.keytab"
ald-client update-svc-keytab smtp/server.local.lan --ktfile="/var/lib/dovecot/dovecot.keytab"

Указывая имя сервиса, важно помнить, что после слеша указывается то же самое имя сервера, что и в файле /etc/hostname. Если даже в настройках Bind вы потом укажете, что mail.local.net и smtp.local.net являются всего лишь псевдонимами для server.local.net, почта работать не будет, потому что Kerberos очень строго проверяет этот параметр.

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

setfacl -m u:dovecot:x /var/lib/dovecot
setfacl -m u:dovecot:r /var/lib/dovecot/dovecot.keytab

Dovecot

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

!include_try /usr/share/dovecot/protocols.d/*.protocol
protocols = imap
listen = 192.168.0.1
dict {}
!include conf.d/*.conf
!include_try local.conf

disable_plaintext_auth = yes
auth_mechanisms = gssapi
auth_gssapi_hostname = server.local.lan
auth_krb5_keytab = /var/lib/dovecot/dovecot.keytab
!include auth-system.conf.ext

Я не могу в настройку SSL. Отключаем:

ssl = no
ssl_cert = </etc/dovecot/dovecot.pem
ssl_key = </dovecot/private/dovecot.pem

Маленькая настройка для корректной работы с почтой - добавляем в файле /etc/dovecot/conf.d/10-master.conf в секцию service auth:

# ...
service auth {
  unix_listener auth-client {
    mode = 0600
    user = Debian-exim
  }
  # ...
}

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

namespace inbox {
  mailbox Drafts {
    special_use = \Drafts
    auto = subscribe
  }
  mailbox Junk {
    special_use = \Junk
  }
  mailbox Trash {
    special_use = \Trash
    auto = subscribe
  }
  mailbox Sent {
    special_use = \Sent
    auto = subscribe
  }
}

Расположение каталогов внутри /var/mail/%username% можно изменить, сделав более удобным, если в /etc/dovecot/conf.d/10-mail.conf немного изменить параметр mail_location:

mail_location = maildir:/var/mail/%u:LAYOUT=fs

Exim4

Теперь нужно сделать пару дополнительных настроек Exim4.

dovecot_gssapi:
  driver = dovecot
  public_name = GSSAPI
  server_socket = /var/run/dovecot/auth-client
  server_set_id = $auth1 # В конце цифра один, а не маленькая эль

Файл /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt очень большой, поэтому не привожу его полностью. В самом начале нужно добавить в секцию acl_check_rcpt 4 строки, чтобы выглядело примерно так:

acl_check_rcpt:
  deny
    message = "Auth required"
    hosts = *:+relay_from_hosts
    !authenticated = *
  accept:
    hosts = :
    control = dkim_disable_verify
# и так далее

Проверка работоспособности

Заходим от имени пользователя ALD. Запускаем Thunderbird и создаем новую учетную запись. В параметрах IMAP- и SMTP-серверов пишем одно и то же - server.local.net. При нажатии кнопки "Проверка параметров" параметры авторизации должны измениться на Kerberos/GSSAPI. Сохраняем, перезапускаем почтовый клиент. После второго запуска должно загрузиться дерево папок с сервера. Пишем письмо сами себе, если пришло - все хорошо. Если нет - очень внимательно проверяем содержимое всех конфигурационных файлов. Я сам потерял три дня из-за того, что в одном месте пропустил всего одну строку.

Запуск Python-Web-приложений в Astra Linux

В Astra Linux до версии 1.6 не было иного способа нормального запуска Web-приложений, написанных на Python, кроме mod_python. В настоящее время самый популярный способ - WSGI, однако, в сертифицированных версиях Astra Linux SE (1.4, 1.5) есть только указанный выше модуль для Apache. Безусловно, есть и третий способ - запуск приложения в отладочном режиме через вот эту команду:

python manage.py runserver

Надо ли объяснять, что делать так не нужно?

Итак, задачи, решение которых я предлагаю в этой статье:

• Настройка Apache для работы в рамках ALD (Astra Linux Domain)
• Настройка виртуального хоста для Django-приложения
• Авторизация в приложении Django через ALD/Kerberos

Настройка ALD и Apache

Установка необходимых модулей Apache.

Устанавливаем два модуля Apache (считаем, что Apache уже установлен на сервере).

apt-get install libapache2-auth-mod-kerb libapache2-mod-python

Включаем эти модули и перезапускаем WEB-сервер:

a2dismod auth_pam
a2enmod python
a2enmod auth_kerb

Настройка ALD.

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

Создадим принципала в ALD и добавим его в группу mac

ald-admin service-add HTTP/server.domain.lan
ald-admin sgroup-svc-add HTTP/server.domain.lan --sgroup=mac

Теперь создадим файл ключа Kerberos и дадим права на него пользователю www-data.

KEYTAB="/etc/apache2/keytab"
ald-client update-svc-keytab HTTP/server.domain.lan --ktfile=$KEYTAB
chown www:data $KEYTAB
chmod 644 $KEYTAB

Теперь можно перезапустить WEB-сервер:

service apache2 restart

Создание виртуального хоста Apache.

Подготовительные операции выполнены, на клиентах Firefox настроен на использование GSS API для авторизации (about:config, потом в параметр network.negotiate-auth.delegation-uris вписываем http://,https://). Самое время создать виртуальный хост для нашего Django-проекта, лежащего в каталоге /var/www/site/.

<VirtualHost *:80>
    ServerName   server.domain.lan
    ServerAdmin  useradmin@domain.lan
    DocumentRoot /var/www/site

    AddDefaultCharset utf-8

    <Directory "/var/www/site/”>
        Options -Indexes FollowSymLinks -MultiViews
        AllowOverride None

        AuthType       Kerberos
        KrbAuthRealms  DOMAIN.LAN
        KrbServiceName HTTP/server.domain.lan
        Krb5Keytab     /etc/apache2/keytab
        KrbMethodNegotiate on
        KrbMethodK5Passwd off
        KrbSaveCredentials on
        require valid-user

        Order deny,allow
        Allow from all
    </Directory>

    <Location "/">
        SetHandler    python-program
        PythonHandler django.core.handlers.modpython
        SetEnv        DJANGO_SETTINGS_MODULE site.settings
        PythonOption  diango.root /var/www/site
        PythonPath    "['/var/www/site/',] + sys.path"
        PythonAutoReload On
    </Location>

    <Location "/media/”>
        SetHandler None
    </Location>

    <Location "/static/">
        SetHandler None
    </Location>

    <LocationMatch "\.(jpg|gif|png)$">
        SetHandler None
    </Location>

    ErrorLog /var/www/site/log/error.log
    LogLevel warn
    SetEnfIf Request_URI "\.jpg$|\.gif$|\.css$|\.js" is_static
    CustomLog /var/www/site/log/access.log combined env=!is_static # Убрать лишнее из логов доступа, например, статику
</VirtualHost>

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

a2ensite astra-django-project
service apache2 reload

Побочные эффекты

Возможно, у меня руки кривые, или я чего-то не знаю, но есть некоторые факты, которым я не нахожу другого объяснения, например, откусывание заголовков HTTP сервером Apache. Допустим, у нас есть вот такой код:

# -*- coding: utf-8 -*-

u"""Виды для обработки данных абонентов."""

from django.shortcuts import get_object_or_404
from django.views.generic import View

from abonent.models import Abonent
from rest.responses import JsonResponse

from .serializers import AbonentSimpleSerializer


class AbonentRootView(View):

    def get(self, request):
        u"""
        Именно здесь происходит сериализация модели в JSON.

        Возвращаемый объект - JsonResponse.
        """
        
        root_abonent = Abonent.objects.filter(parent=None)[0]
        serializer = AbonentSimpleSerializer()

        response = JsonResponse({
            "items": [
                serializer.serialize(root_abonent),
            ],
            "total": 1
        })

        # Тут задаем заголовки, чтобы библиотека dgrid могла с ними работать
        # Не надо смотреть на цифры, они сейчас не имеют значения (просто пример)
        response["Content-Range"] = "items: 1-1/1"

        return response

Не суть важно, как происходит сериализация (сериализатор возвращает словарь), важно то, что происходит в строке, где устанавливается заголовок ответа Content-Range. Если запустить отладочный сервер, то в заголовках ответа мы его увидим. Если выполнять этот же код с помощью Apache, т. е. так, как я выше написал, заголовок будет просто выброшен. Как это лечить в Astra Linux 1.4, я не знаю. Но, например, при использовании библиотеки DStore использовать свойство useRangeHeaders будет нельзя. Т. е. и DGrid тоже работать не будет, нужно помимо свойства items передавать ещё и total. Не такая уж большая проблема, но под определение подводного камня подходит хорошо.

Цели

• Настройка основного сервера DNS для маленькой локальной сети
• Сервер должен быть безопасным
• Сервер должен хранить настройки для конфигурации данной сети
• Сервер должен обслуживать доменную зону home.net с адресами в подсети 192.168.0/24

Как обычно, если не указано иное, команды выполняются от имени пользователя root.

Исходные данные

Установка сервера

apt-get install bind9 -y

Сервер установлен, но установка сделана не безопасным способом. Нужно выполнить несколько дополнительных действий, описанных подробнее в Debian Wiki - Bind.

Будем запускать сервер в изолированном окружении:

mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/named}
mknod /var/bind9/chroot/dev/null c 1 3
mknod /var/bind9/chroot/dev/random c 1 8
chmod 660 /var/bind9/chroot/dev/{null,random}
mv /etc/bind /var/bind9/chroot/etc
ln -s /var/bind9/chroot/etc/bind /etc/bind
chown bind:bind /var/bind9/chroot/etc/bind/rndc.key
chmod 775 /var/bind9/chroot/var/{cache/bind,run/named}
chgrp bind /var/bind9/chroot/var/{cache/bind,run/named}

Теперь нужно изменить расположение PIDFILE. Для этого в файле /etc/init.d/bind9 нужно переопределить переменную PIDFILE.

PIDFILE=/var/bind9/chroot/var/run/named/named.pid

Чтобы сервер понимал, что его запускают в изолированном окружении, нужно изменить параметры его запуска, внеся небольшие коррективы в файл /etc/default/bind9

OPTIONS="-u bind -t /var/bind9/chroot"

Перенастроим логирование rsyslog

echo "\$AddUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-chroot.conf

Настройка опций сервера

Безопасность

Основные настройки сервера хранятся в файле /etc/bind/named.conf.options (на самом деле сейчас это всего лишь символическая ссылка, но на суть дела это не влияет). Добавим пару параметров для пущей безопасности в разделе options:

options {
    ...
    version none; // Скроем версию bind
    allow-query {
        192.168.0/24; // Отвечать будем только на запросы, приходящие из внутренней сети
    };
    ...
}

Включение в конфигурацию новой доменной зоны

В файле /etc/bind/named.conf.default-zones добавим указание на файлы прямой и обратной зоны, чтобы сервер мог обслуживать локальную сеть:

...
zone "home.net" in { // Локальная сеть
    type master;
    file "/etc/bind/db.home.net";    // В этом файле будут адреса прямой зоны
};

zone "0.168.192.in-addr.arpa" {      // Так описывается обратная зона, т. е. первые три октета
                                     // записываются в обратном порядке и добавляется .in-addr.arpa
    type master;
    file "/etc/bind/db.0.168.192";   // В этом файле будут адреса обратной зоны
};

Прямая доменная зона

Ниже просто приведу содержимое файла /etc/bind/db.home.net.

$TTL 3h
@   IN SOA dc.home.net. administrator.home.net. (
; Вместо @ будет подставлено автоматически имя зоны из файла /etc/bind/named.conf.default-zones
    2017092701 ; Это число нужно менять каждый раз при изменении этого файла
               ; Очень удобно взять текущее число и добавить ещё пару цифр для указания ревизии
    3h         ;
    1h         ;
    1w         ;
    1h
)

      IN NS dc.home.net. ; Указываем имя основного DNS-сервера, обслуживающего зону
                         ; Наличие пробела или табуляции в начале строки и точки
                         ; после .net обязательно

dc    IN A  192.168.0.1  ; IP-адрес сервера имен
imap  IN CNAME dc        ; Указываем, что наш DNS-сервер так же отзывается на imap.home.net
smtp  IN CNAME dc        ; и smtp.home.net

arm01 IN A 192.168.0.101
arm02 IN A 192.168.0.102
arm03 IN A 192.168.0.103
arm04 IN A 192.168.0.104
arm05 IN A 192.168.0.105
arm06 IN A 192.168.0.106
arm07 IN A 192.168.0.107
arm08 IN A 192.168.0.108
arm09 IN A 192.168.0.109
arm10 IN A 192.168.0.110

Обратная зона

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

$TTL 3h
@   IN SOA dc.home.net. administrator.home.net. (
    2017092701 ; Это число тоже нужно менять
    3h         ;
    1h         ;
    1w         ;
    1h
)

      IN NS dc.home.net.

1   IN PTR dc.home.net. ; Наш сервер

101 IN PTR arm01.home.net.
102 IN PTR arm02.home.net.
103 IN PTR arm03.home.net.
104 IN PTR arm04.home.net.
105 IN PTR arm05.home.net.
106 IN PTR arm06.home.net.
107 IN PTR arm07.home.net.
108 IN PTR arm08.home.net.
109 IN PTR arm09.home.net.
110 IN PTR arm10.home.net.

Запуск сервера и проверка работоспособности

Если всё сделано правильно, точки расставлены и IP-адреса указаны верно, можно попробовать запустить наш сервер:

service bind9 start

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

host arm01.home.net
host 192.168.0.9

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

named-checkconf /etc/bind/named.conf
named-checkzone home.net /etc/bind/db.home.net
named-checkzone 192.168.0 /etc/bind/db.0.168.192

Данные утилиты из состава пакета bind9utils укажут на ошибки в конфигурационных файлах.

Клиенты

Существует несколько способов настроить обращение к DNS-серверу на клиентских машинах. По скольку речь идет об операционной системе для социальной группы 'siloviki', выбор инструментальных средств невелик - wicd, /etc/network/interfaces и /etc/resolv.conf.

Первый способ отметаем сразу же, поскольку с wicd довольно много проблем. Не буду останавливаться на них подробно, но обычно первое, что приходится делать на свежеустановленной системе - убрать его из автозагрузки:

service wicd stop
chkconfig wicd off

Можно указать DNS-сервер в настройках сетевых интерфейсов, однако, в этом случае их нужно прописывать для каждого сетевого интерфейса, а я не люблю повторяться. В связи с этим просто откорректируем файл /etc/resolv.conf на клиентских машинах:

domain home.net
search home.net
nameserver 192.168.0.1

Работа в ненулевых мандатных режимах

В данном дистрибутиве реализована мандатная модель разграничения доступа, в том числе к сетевым сервисам. Чтобы обеспечить корректную работу демона named в режимах с мандатной меткой, отличной от нулевой, нужно добавить всего одну строчку в файл /etc/parsec/privsock.conf:

/usr/sbin/named

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

Пусть компьютеры будут находиться в сети с адресами 192.168.0.XXX, где вместо XXX - число от 1 до 254.

Настройка осуществляется путем правки файла /etc/network/interfaces. Каждый сетевой интерфейс (сетевая карта, хотя это не совсем точное название) настраивается отдельно. Настройки для сервера выглядят так:

auto lo eth0

iface lo inet loopback

iface eth0 inet static
    address 192.168.0.1
    netmask 255.255.255.0
    gateway 192.168.0.1         # В качестве шлюза - наш сервер с IP=1
    network 192.168.0.0         # Указываем сеть, это обязательно для работы в составе ALD
    broadcast 192.168.0.255     # Сервер ALD начиная с Astra 1.5 выводит ошибку, если не видит
                                # этого параметра в настройках сети.
    dns-nameservers 192.168.0.1 # Тут через пробел можно перечислить ВСЕ DNS-серверы сети
    dns-search DOMAIN.NET       # Имя домена ALD

Первая строчка auto lo eth0 указывает, какие интерфейсы должны быть запущены при загрузке ОС. Отмечу, что локальная петля lo должна присутствовать там в любом случае.

Пропустим описание локальной петли и сразу перейдем к сетевому интерфейсу.

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

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

service wicd stop
chkconfig wicd off
rm /etc/xdg/autostart/fly-admin-wicd.desktop
service networking restart

Если на одной сетевой карте по каким-то причинам нужно иметь 2 или более IP-адресов, настройки делаются следующим образом:

auto lo
iface lo inet loopback # Кстати, удалять интерфейс локальной петли не стоит,
                       # некоторые службы от этого сходят с ума и начинают
                       # выдавать весьма странные ошибки

auto eth0:0
allow-hotplug eth0:0
iface eth0:0 inet static
    address 192.168.0.1
    netmask 255.255.255.0
    network 192.168.0.0
    gateway 192.168.0.1
    broadcast 192.168.0.255
    dns-nameservers 192.168.0.1 192.168.0.2
    dns-search DOMAIN.NET

auto eth0:1
allow-hotplug eth0:1
iface eth0:1 inet static
    address 10.2.12.54      # Адрес, маска и все остальные параметры в этой
    netmask 255.255.255.128 # секции были придуманы за 20 секунд, поэтому
    network 10.2.12.0       # не ручаюсь за правильность заполнения. Гуглите
    gateway 10.2.12.1       # маску подсети для этого случая самостоятельно.
    broadcast 10.2.12.255
    dns-nameservers 8.8.8.8
    dns-search GOOGLE.RU

Посмотреть настройку сети в Debian более подробно можно на официальной Wiki-странице или её несколько устаревшей русской версии