Этот протокол часто является мишенью перебора. Но к счастью есть решение. Инструмент Fail2ban позволяет блокировать доступ с IP адресов при большом количестве неверных логинов. Программа fail2ban может использоваться не только для SSH, она может защитить различные формы веб-аутентификации, FTP, и предотвратить DoS атаки на сервер. В этой статье мы рассмотрим как выполняется установка и настройка Fail2ban CentOS 7 поскольку эта операционная система часто используется для серверов.

УСТАНОВКА FAIL2BAN

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

 yum update && sudo yum install epel-release

Затем установка fail2ban centos 7:

 sudo yum install fail2ban

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

 sudo systemctl start fail2ban

НАСТРОЙКА FAIL2BAN CENTOS 7

Все конфигурационные файлы программы находятся в папке /etc/fail2ban. Вот основные файлы, которые мы будем использовать:

• fail2ban.conf — пример выполнения основных настроек программы;
• jail.conf — пример настройки запрещающих правил;
• jail.d — папка с конфигурационными файлами пользователя, для настройки правил запрета;
• action.d — файлы, в которых описываются действия, выполняемые при блокировке;
• filter.d — в этих файлах описываются способы разбора журналов программ для поиска неудачных попыток входа.

Никакие параметры в существующих файлах менять нельзя, они будут обновлены при обновлении программы, а значит что все ваши изменения будут стерты. Для установки своих настроек необходимо создать файл с таким же именем и расширением .local. Например, создаем файл для настройки jail.conf:

 cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

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

Блокировку можно настроить, с помощью различных параметров. Вот самые важные из них:

• ignoreip — задает список ip адресов, которые нужно исключить из алгоритмов Fail2ban. К ним не будут применяться ограничения, так что выбирайте их аккуратно. Диапазоны и IP адреса стоит разделить пробелом. Сюда можно добавить локальный ip, а также свой домашний адрес, чтобы у вас не возникло проблем при входе;
• bantime — указывает время, на которое клиенту буде закрыт доступ к серверу, если он не сможет авторизоваться, в секундах;
• maxretry — указывает количество попыток перед тем, как доступ будет заблокирован;
• findtime — время в секундах, на протяжении которого рассчитывается maxretry.

В нашем примере пользователь будет заблокирован на 600 секунд после 5-ти неудачных попыток:

По умолчанию, в CentOS все блокировки отключены, чтобы их включить замените значение строчки enabled на true. Но не рекомендуется так делать, потому что вам придется удалить из конфига все ненужные правила блокировки, иначе они вызовут ошибку запуска. Также можно включить обработку каждого приложения отдельно:

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

• banaction — этот параметр определяет файл конфигурации способа блокировки, который нужно использовать. Обычно указывает на файл в папке /etc/fail2ban/action.d/ в котором записаны команды для блокировки. По умолчанию применяется iptables;
• action — с помощью параметров action задаются ярлыки дополнительных действий, которые выполняется после banaction. Сценарию передается имя, порт, протокол, цель и сценарий.

НАСТРОЙКА EMAIL ОПОВЕЩЕНИЙ

Если вы хотите настроить оповещение о срабатывании блокировки Fail2ban по электронной почте, это тоже настраивается в разделе [DEFAULT]. Только необходимо чтобы на вашей машине был настроен почтовый сервер и он мог отправлять письма на внешний адрес. Иначе все письма будут доставлены к локальной учетной записи Linux.

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

• destemail — этот параметр задает адрес электронной почты, на который вы хотите получать сообщения. Значение по умолчанию root@localhost;
• mta — определяет почтовый агент, который будет использоваться для доставки почты. Если у вас настроен Sendmail, оставьте значение по умолчанию. Если же письма нужно доставлять на локальную машину поменяйте значение на mail.
• Также для локальной почты нужно заменить строчку action_mw на action_mwl:

Дальше для проверки почты можно посмотреть файл /var/mail/mail:

 cat /var/mail/mail

НАСТРОЙКА ОТДЕЛЬНЫХ ПРИЛОЖЕНИЙ

Сразу после настроек раздела по умолчанию вы увидите разделы, обозначенные вот так: [имя_приложения]. Рассмотрим основные используемые параметры:

• filter — указывает имя файла в каталоге /etc/fail2ban/filter.d/ Он сообщает программе как анализировать журнал сервиса и находить неудачные попытки входа;
• logpath — путь к лог файлу службы, куда она записывает неудачные попытки входа;

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

Например, для активации блокировки неверных входов SSH, приведите секцию [sshd] к такому виду:

enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

НАСТРОЙКА IPTABLES

Обычно, никаких дополнительных настроек для iptables не требуется. Но давайте рассмотрим конфигурационный файл, который отвечает за блокировку, чтобы вы понимали как все работает. Имя этого файла указано в параметре banaction. По умолчанию это iptables-multiport.conf:

 vi /etc/fail2ban/action.d/iptables-multiport.conf

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

actionstart = iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN # questionable usefulness
iptables -I <chain> -p <protocol> -m multiport --dports <port> -j fail2ban-<name>

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

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

Для разрушения цепочки используются такие правила:

actionstop = iptables -D <chain> -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
iptables -F fail2ban-<name>
iptables -X fail2ban-<name>

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

actionban = iptables -I fail2ban-<name> 1 -s <ip> -j DROP

Эта команда говорит, что необходимо отбрасывать все пакеты с этого ip адреса и уже не пытаться определить подлинность данных. Когда время блокировки вышло, она снимается такой командой:

actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP

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

sudo iptables -L

ЗАВЕРШЕНИЕ НАСТРОЙКИ

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

 sudo fail2ban-client -d

Если все правильно, перезагружаем сервис:

 sudo systemctl restart fail2ban

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

 sudo iptables -L

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

В этой статье мы рассмотрели как выполняется настройка fail2ban CentOS 7. Теперь вы можете настроить дополнительный уровень защиты для вашего сервера чтобы обезопасить его от взлома.

Сообщение Настройка FAIL2BAN в CENTOS появились сначала на Clip-Clap.

В этом руководстве мы расскажем о дистрибутивах ОС, которые программисты могут кастомизировать под себя.

Из статьи вы узнаете:

• Arch Linux
• Debian
• Raspbian
• Gentoo
• Ubuntu
• Fedora
• OpenSUSE
• CentOS
• Solus
• Puppy Linux

Arch Linux

Arch Linux предоставляет большой функционал для кастомизации во время установки. Это позволяет вам загружать и устанавливать нужные пакеты.

Этот дистрибутив не для новичков. Вы можете установить минимальный набор программ на машину, используя Arch Build System и Arch User Repository. Это снижает риск того, что какое-то приложение вмешается в ваш код.

Загрузить Arch Linux

Debian

Debian — один из самых старых и стабильных дистрибутивов Linux. Все программы, включенные в Debian, должны соответствовать стандартам бесплатного ПО Debian.

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

На сайте Debian есть много руководств, включая главу по программированию.
В ней рассказывается о том, как создать скрипт, скомпилировать его и с помощью
Autoconf разрешить скриптам компилироваться на других дистрибутивах Linux.

Загрузить Debian

Raspbian

Raspbian — дефолтная ОС, которая включена в Raspberry Pi. Так как Pi был разработан как образовательный инструмент, Raspbian — отличная ОС для тех, кто хочет начать писать код.

На сайте Raspberry Pi выложено много руководств о том, как использовать визуальный инструмент программирования Scratch. Его используют, чтобы создавать анимацию и игры. Есть также отличный раздел о том, как начать работать с Python.

Более молодые программисты могут начать изучать язык программирования для Minecraft Pi. Это мини-версия очень популярной игры в песочнице.

Загрузить Raspbian

Gentoo

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

У Gentoo есть своя вики, в которой вы найдете много полезной информации — включая Gentoo Handbook.

Загрузить Gentoo

Ubuntu

В отличие от голых дистрибутивов таких, как Arch Linux и Gentoo, Ubuntu — идеальная ОС для начинающих. У нее есть десктопный интерфейс, и она автоматически обновляется.

Ubuntu теперь поддерживает формат упаковки приложений snaps с помощью инструмента Snapcraft. Он позволяет писать приложения на языке программирования, который вам подходит, и упаковать их со всеми необходимыми зависимостями. За более подробной информацией заходите на портал Ubuntu Developer.

Загрузить Ubuntu

Fedora

Fedora — производный дистрибутив от Red Hat Linux. Кроме того, что его очень легко настраивать и устанавливать, у Fedora также есть отдельный Developer Portal. Нажмите на “Start a Project”, чтобы посмотреть руководства по программированию, командной строке, десктопным и мобильным приложениям.

Репозитории Fedora также включают Eclipse, полнофункциональную и мультиязычную внутреннюю среду разработки. Eclipse прежде всего известен Java, но он также подходит для разработки на C/C++ и PHP. Вы также можете расширять функционал Eclipse с помощью плагинов.

Загрузить Fedora

OpenSUSE

OpenSUSE — дистрибутив, специально разработанный для разработчиков ПО и системных администраторов. Его легко устанавливать и настраивать благодаря интегрированному инструменту YaST. Этот инструмент позволяет устанавливать все нужные программистам ‘-devel’ пакеты в один клик.

OpenSUSE поставляется предустановленным — в него включены все базовые инструменты, которые могут понадобиться программистам. Это текстовые редакторы Vim и Emacs, такие автоматизированные инструменты, как CMake и упаковывающие инструменты, как, например, RPM. ОС также включает OBS — инструмент, с помощью которого программисты создают ПО для разных дистрибутивов и платформ.

Загрузить OpenSUSE

CentOS

Как и Fedora, CentOS — бесплатный вариант коммерческой версии Linux Red Hat.
CentOS — очень стабильная система.

Репозиторий CentOS включает Developer Toolset, который предоставляет набор основных инструментов программирования.

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

Загрузить CentOS

Solus

Solus — дистрибутив Linux уникальный тем, что он основывается на модели контролируемого плавающего релиза. Это значит, что после того, как вы устанавливаете ОС, вы можете продолжать устанавливать отдельные обновления для нее вместо того, чтобы обновлять ОС полностью. Solus старается не устанавливать новейшие пакеты и ПО в стадии бета, чтобы поддерживать стабильность системы.

Solus поддерживает несколько редакторов и внутренних сред разработки, — такие, как Atom, Idea и Gnome Builder, а также Git GU и GitKraken. На сайте Solus говорится, что ОС поддерживает множество языков программирования — например, Go, Rust, PHP, Node.js и Ruby.

Загрузить Solus

Puppy Linux

Puppy Linux — очень легкий дистрибутив на Ubuntu или Slackware. Вся ОС весит около 330 МБ. Это значит, что она может полностью запускаться в RAM и устанавливаться на обычный жесткий диск. В нее входит минимальное количество пакетов, куда вы можете добавить свои — например, пакеты ‘devx’, в которые входят различные инструменты программирования.

В вики Puppy Linux подробно описываются языки программирования, которые поддерживает ОС. Один из примечательных языков — BaCon, который может превращать код, написанный на BASIC, в C. В вики также есть подборка инструкций о том, как писать скрипты Bash и начать писать на Python.

Загрузить Puppy Linux

Сообщение Лучшие дистрибутивы Linux для программистов появились сначала на Clip-Clap.

Введение

В нашем распоряжении будет следующий сервер для настройки шлюза:

# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)

Использовался образ minimal для установки CentOS 7. Если вы еще не выполнили установку, рекомендую воспользоваться моим материалом на эту тему. На сервере две сетевые карты eth0 и eth1:

• eth0 подключена к интернету
• eth1 подключена к локальной сети вместе с компьютерами

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

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

Предварительная настройка сервера

Любую настройку сервера я рекомендую начинать с обновления:

# yum -y update

После этого я устанавливаю mc, так как привык к нему и постоянно пользуюсь:

# yum -y install mc

Дальше отключаем selinux. Находим файл /etc/sysconfig/selinux и редактируем его:

# mcedit /etc/sysconfig/selinux

Приводим строку с соответствующим параметром к следующему виду:

SELINUX=disabled

Чтобы применить изменения, перезагружаем сервер:

# reboot

Более подробно о базовой настройке сервера CentOS 7 читайте отдельно. Мы же двигаемся дальше.

Теперь настроим сеть.

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

# systemctl stop NetworkManager.service
# systemctl disable NetworkManager.service

Теперь включаем классическую службу сети в CentOS 7:

# systemctl enable network.service

Настраиваем сетевые интерфейсы:

# mcedit /etc/sysconfig/network-scripts/ifcfg-eth0

HWADDR=00:15:5D:01:0F:06
TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
NAME="eth0"
UUID="4e65030c-da90-4fb8-bde4-028424fe3710"
ONBOOT="yes"

# mcedit /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
HWADDR=00:15:5d:01:0f:12
TYPE=Ethernet
ONBOOT=yes
IPADDR=192.168.10.1
NETMASK=255.255.255.0

Перезапускаем службу сети:

# systemctl restart network.service

Смотрим, что получилось:

# ip a

Вы настраивайте сеть в зависимости от своих условий. Если внешний адаптер получает настройки не по dhcp, как у меня, а в статике, то не забудьте настроить шлюз по-умолчанию и dns сервер. Как это сделать написано в моей статье о сетевых параметрах, ссылку на которую я приводил выше.Прежде чем двигаться дальше, убедитесь, что вы все верно настроили — на сервере работает интернет, компьютеры из локальной сети пингуют сервер по адресу на eth1.

Включаем маршрутизацию, firewall и nat

Чтобы сервер мог маршрутизировать пакеты между сетевыми адаптерами, необходимо выполнить следующую настройку. Находим файл /etc/sysctl.conf и вставляем туда строку:

# mcedit /etc/sysctl.conf
net.ipv4.ip_forward = 1

Чтобы заработала настройка, выполняем команду:

# sysctl -p

Теперь приступаем к самому главному — настройке фаерволла. Опять же отсылаю вас к своему материалу, где я очень подробно рассмотрел вопрос настройки iptables в CentOS 7. Там же приведен готовый скрипт для iptables. Так что выполняем все необходимые действия без пояснений.

Отключаем firewalld:

# systemctl stop firewalld
# systemctl disable firewalld

Устанавливаем службы iptables:

# yum -y install iptables-services

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

# Внешний интерфейс
export WAN=eth0
export WAN_IP=192.168.1.25
# Локальная сеть
export LAN1=eth1
export LAN1_IP_RANGE=192.168.10.1/24

Помещаем отредактированный скрипт в /etc/iptables.sh и делаем его исполняемым:

# chmod 0740 /etc/iptables.sh

Запускаем iptables:

# systemctl start iptables.service

Добавляем их в автозагрузку:

# systemctl enable iptables.service

Выполняем скрипт с правилами:

# /etc/iptables.sh

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

# iptables -L -v -n

Если у вас то же самое, значит вы все сделали правильно.

По сути наш шлюз уже готов и может обслуживать клиентов. Но не работает одна важна служба, без которой нормальной работы с интернетом не получится. Нам нужно настроить кэширущий dns сервер для клиентов локальной сети. Можно пойти по простому и очень простому пути. Простой путь это выполнить простейшую настройку dns сервера bind. Как это сделать у меня опять же подробно написано отдельно — настройка Bind 9 в CentOS 7. Рекомендую ознакомиться, там рассмотрены интересные нюансы настройки.

Очень простой путь это установить dnsmasq, который помимо dns сервера включает в себя еще и dhcp сервер, который нам может пригодиться.

Установка и настройка dnsmasq в CentOS 7

С большой долей вероятности dnsmasq у вас уже установлен. Проверить это можно следующей командой:

# rpm -qa | grep dnsmasq
dnsmasq-2.66-14.el7_1.x86_64

Если вывод такой же, значит пакет уже стоит. Если нет, то устанавливаем dnsmasq командой:

# yum -y install dnsmasq

Редактируем файл конфигурации /etc/dnsmasq.conf и приводим его к очень простому виду:

# mcedit /etc/dnsmasq.conf

domain-needed
bogus-priv
interface=eth1
dhcp-range=192.168.10.50,192.168.10.150,24h

Запускаем dnsmasq:

# systemctl start dnsmasq

Либо перезапускаем, если он был у вас запущен:

# systemctl restart dnsmasq

Добавляем dnsmasq в автозагрузку:

# systemctl enable dnsmasq

Я редактировал конфиг, когда у меня уже был установлен и запущен dnsmasq. И он то ли завис, то ли просто затупил, но я не мог его перезагрузить или остановить с помощью systemctl. Пришлось перезагрузить сервер. После этого все нормально заработало. Клиент на windows получил сетевые настройки. Информация об этом появилась в логе /var/log/messages. Я проверил на клиенте интернет, все было в порядке, он работал.

На этом настройка завершена, шлюзом под CentOS 7 можно пользоваться.

Анализ сетевой активности на шлюзе в linux

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

Она отсутствует в стандартном репозитории CentOS 7. Для ее установки необходимо подключить репозиторий epel:

# yum -y install epel-release

Устанавливаем iftop на CentOS 7:

# yum -y install iftop

Теперь мы можем смотреть загрузку сети на шлюзе в режиме реального времени. Чтобы увидеть сетевую активность, достаточно запустить iftop:

# iftop

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

# iftop -i eth1 -P

Теперь уже гораздо интереснее. Я еще добавил параметр -P, который отображает порты, по которым проходят соединения. Посмотрим, кто больше всех загружает канал интернета:

В моем случае это пользователь с ip 192.168.10.98, на котором я запустил проверку скорости интернета с серверов Яндекса.

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

Заключение

С помощью бесплатного дистрибутива Linux мы смогли за считанные минуты настроить шлюз для организации доступа в интернет компьютеров из локальной сети. У меня ушло минут 10 на настройку шлюза по этой инструкции. Если вы делаете это первый раз, то конечно у вас уйдет гораздо больше времени. Нужно будет разобраться в нюансах, к тому же я дал много ссылок на дополнительный материал.

Давайте разберемся в том, что мы сделали:

1. Выполнили предварительную настройку сервера, подготовили его к работе.
2. Включили маршрутизацию.
3. Настроили firewall.
4. Включили NAT.
5. Установили и настроили dnsmasq для организации служб dns и dhcp.
6. Проанализировали сетевую активность шлюза, узнали кто загружает канал интернета.

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

Сообщение Настройка шлюза на CentOS 7 появились сначала на Clip-Clap.

Введение — что такое vpn server?

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

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

OpenVPN — одна из реализаций технологии VPN с открытым исходным кодом, а значит бесплатная. С ее помощью можно объединять в единую сеть компьютеры в том числе и находящиеся за NAT, что очень удобно. Openvpn поддерживает все популярные на сегодняшний день операционные системы, в том числе и Windows.

Среди малого и среднего бизнеса сервер openvpn очень популярен благодаря своей бесплатности, кроссплатформенности, быстроте и гибкости настроек. Лично я предпочитаю именно его для объединения удаленных локальных сетей. Его же предпочитают использовать vpn-провайдеры для оказания своих услуг по организации анонимного серфинга в интернете.

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

Объединение офисов с помощью openvpn

У нас имеется офис с шлюзом CentOS 7, на который мы будем устанавливать openvpn сервер. И есть филиал с таким же шлюзом, где будет установлен openvpn client для подключения сети филиала к офису:

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

Наша задача в данном случае будет сводиться к тому, чтобы компьютеры PC1 и PC2 увидели друг друга и могли совместно использовать свои сетевые ресурсы в обе стороны. То есть как за сервером, так и за клиентом openvpn мы должны видеть сеть.

Хочу отметить, что конфигурация openvpn кроссплатформенная и отлично переносится с одной системы на другую, необходимо только пути проверить, так как в каждой системе они свои. Моя инструкция подойдет для настройки openvpn сервера на любой операционной системе, отличаться будут только специфичные для каждой системы команды установки и проверки, но сама суть настройки vpn будет такой же.

Данный материал я создавал на тестовом стенде, который специально собрал для написания статьи. Но все настройки взяты с реально работающих серверов, причем разных систем, в том числе и freebsd. Для практического применения нужно просто поменять IP адреса на свои. У меня на стенде 192.168.1.25 и 192.168.1.26 по сути внешние IP адреса, которые смотрят в интернет.

Где скачать openvpn

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

Сразу же прокомментирую по поводу portable версии openvpn. На текущий момент актуальной портированной версии openvpn не существует. Та версия, на которую я дал ссылку была выпущена 2014-03-26 и проект с тех пор закрыт. В некоторых случаях эта версия работает, но не всегда и не везде. Я специально по этому поводу почитал форум Community Openvpn и нашел там неутешительные ответы. Разработчики говорят, что portable версия openvpn не поддерживается и выпускать ее они даже не собираются. А жаль, это было бы удобно.

Для Linux систем дистрибутив проще всего получить в системных репозиториях и устанавливать с помощью стандартных установщиков пакетов.

Установка openvpn на CentOS 7

Теперь вернемся к нашей задаче. Я подразумеваю, что у вас уже есть установленный и настроенный сервер CentOS 7. Если еще нет, то можете воспользоваться моими материалами. В них раскрыты следующие темы:

• Подробное описание установки CentOS 7 с разбором всех этапов и параметров.
• Настройка CentOS 7 шаг за шагом — базовая конфигурация сервера.

Устанавливаем openvpn на оба наших сервера, которые являются шлюзами в своих сегментах сети. Первым делом подключаем репозиторий epel к centos 7:

# yum -y install epel-release

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

# yum -y install openvpn

Создание сертификатов

Для работы сервера openvpn необходимо создать соответствующие сертификаты. Для этого воспользуемся программой Easy-RSA, которая генерирует сертификаты с помощью утилиты openssl. Все работы в этом разделе выполняем только на centos-server.

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

# mkdir /etc/openvpn/keys

Устанавливаем архиватор zip:

# yum -y install unzip zip

Скачиваем и устанавливаем утилиту Easy-RSA:

# cd /etc/openvpn/keys
# wget https://github.com/OpenVPN/easy-rsa/archive/master.zip

Если получаете сообщение:

-bash: wget: command not found

То устанавливаете wget:

# yum -y install wget

Продолжаем:

# unzip master.zip
# cd /etc/openvpn/keys/easy-rsa-master/easyrsa3

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

# mv vars.example vars
# ./easyrsa init-pki
Note: using Easy-RSA configuration from: ./vars
init-pki complete; you may now create a CA or requests.
 Your newly created PKI dir is: /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki

Создайте удостоверяющий центр CA:

# ./easyrsa build-ca

Note: using Easy-RSA configuration from: ./vars
 Generating a 2048 bit RSA private key
 .+++
 .........................................................................+++
 writing new private key to '/etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/private/ca.key.GKwCGouHpy'
 Enter PEM pass phrase:
 Verifying - Enter PEM pass phrase:
 -----
 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 -----
 Common Name (eg: your user, host, or server name) [Easy-RSA CA]:serveradmin.ru
CA creation complete and you may now import and sign cert requests.
 Your new CA certificate file for publishing is at:
 /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/ca.crt

Не забудьте указанный пароль. Его нужно будет вводить каждый раз при создании нового сертификата openvpn.

Мы получили 2 ключа:

• /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/private/ca.key
• /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/ca.crt

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

Создаем запрос сертификата для сервера без пароля с помощью опции nopass, иначе придется вводить пароль с консоли при каждом запуске сервера:

# ./easyrsa gen-req server nopass

Note: using Easy-RSA configuration from: ./vars
 Generating a 2048 bit RSA private key
 ........................+++
 ..............................................................................................+++
 writing new private key to '/etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/private/server.key.vCUQuueIih'
 -----
 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 -----
 Common Name (eg: your user, host, or server name) [server]:
Keypair and certificate request completed. Your files are:
 req: /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/reqs/server.req
 key: /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/private/server.key

Подписываем запрос на получение сертификата у нашего CA:

# ./easyrsa sign-req server server

Note: using Easy-RSA configuration from: ./vars
You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 3650 days:

subject=
commonName = server
Type the word 'yes' to continue, or any other input to abort.
Confirm request details: yes
Using configuration from /etc/openvpn/keys/easy-rsa-master/easyrsa3/openssl-1.0.cnf
Enter pass phrase for /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName :PRINTABLE:'server'
Certificate is to be certified until Sep 10 00:31:21 2025 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated

Certificate created at: /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/issued/server.crt

В процессе работы скрипта вводим пароль от CA, который указывали раньше и отвечаем на вопрос yes. Мы получили подписанный удостоверяющим центром сертификат для сервера — /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/issued/server.crt

Нам еще пригодится ключ Диффи-Хелмана, генерируем его:

# ./easyrsa gen-dh

По завершению работы скрипта получаем файл dh сертификата — /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/dh.pem.

Копируем в папку /etc/openvpn все необходимые для работы openvpn сервера ключи:

# cp pki/ca.crt /etc/openvpn/ca.crt
# cp pki/dh.pem /etc/openvpn/dh.pem
# cp pki/issued/server.crt /etc/openvpn/server.crt
# cp pki/private/server.key /etc/openvpn/server.key

Создадим ключ для клиента openvpn:

# ./easyrsa gen-req client nopass
# ./easyrsa sign-req client client

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

•  /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/issued/client.crt
• /etc/openvpn/keys/easy-rsa-master/easyrsa3/pki/private/client.key

Клиенту, которым у нас является шлюз филиала нужно будет передать следующий набор файлов — client.crt, client.key, ca.crt.

Настройка openvpn на CentOS 7

Теперь приступаем к настройке. Создаем файл конфигурации openvpn:

# mcedit /etc/openvpn/server.conf

port 13555 # я предпочитаю использовать нестандартные порты для работы
proto udp # протокол может быт и tcp, если есть необходимость в этом
dev tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem

server 10.0.0.0 255.255.255.0 # подсеть для туннеля, может быть любой
route 192.168.20.0 255.255.255.0 # указываем подсеть, к которой будем обращаться через vpn
push "route 192.168.20.0 255.255.255.0" # передаем маршрут клиентам

ifconfig-pool-persist ipp.txt # файл с записями соответствий clinet - ip
client-to-client # позволяет клиентам openvpn подключаться друг к другу
client-config-dir /etc/openvpn/ccd # директория с индивидуальными настройками клиентов

keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

Создаем необходимые директории:

# mkdir /etc/openvpn/ccd && mkdir /var/log/openvpn

Создаем файл конфигурации клиента в папке, указанной в параметре client-config-dir :

mcedit /etc/openvpn/ccd/client

iroute 192.168.20.0 255.255.255.0

Здесь client — имя сертификата пользователя. Параметр iroute означает, что за подсеть 192.168.20.0/24 отвечает именно этот клиент. Если в openvpn не передать эту настройку, то сеть, находящуюся за клиентом будет не видно, при этом сам клиент будет видеть всю сеть, которую обслуживает сервер. Такой вариант подходит для подключения удаленных сотрудников.

Выбор устройства openvpn — TAP или TUN

Чуть подробнее остановлюсь на этом моменте. В моей конфигурации я использую tun интерфейс. В чем отличие tun от tap можно прочитать на википедии. Прокомментирую своими словами. Если вам нужно объединить две разные локальные сети в одну условно общую, но с разной адресацией, то вам нужен tun. То есть в нашем случае мы объединяем две сети 192.168.10.0/24 и 192.168.20.0/24 для взаимного совместного доступа.

Если же у вас стоит задача объединить 2 удаленные сети в единое адресное пространство, например сделать и в офисе и в филиале единую сеть 192.168.10.0/24, то тогда бы мы использовали tap интерфейс и указывали бы на компьютерах в обоих сетях не пересекающиеся адреса из одной подсети. В таком состоянии openvpn работает в режиме моста. По мне так удобнее первый вариант. Я еще не сталкивался с задачей, где бы мне нужен был tap. Вернемся к настройке.

Запускаем сервер:

# systemctl start openvpn@server

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

TCP/UDP: Socket bind failed on local address [undef]: Permission denied

Значит вам нужно либо правильно настроить, либо отключить SELinux. В данном материале я не хочу касаться настройки SELinux, поэтому просто отключаем его:

# mcedit /etc/sysconfig/selinux

меняем значение

SELINUX=disabled

Чтобы изменения вступили в силу, перезагружаемся:

# reboot

Пробуем снова запустить openvpn сервер:

# systemctl start openvpn@server

Проверяем, запустился или нет:

# netstat -tulnp | grep 13555

udp 0 0 0.0.0.0:13555 0.0.0.0:* 2472/openvpn

Отлично, запустился на указанном порту.

Добавляем сервер openvpn в автозагрузку:

# systemctl enable openvpn@server

ln -s '/usr/lib/systemd/system/openvpn@.service' '/etc/systemd/system/multi-user.target.wants/openvpn@server.service'

Теперь внимательно проверим корректность всех настроек на сервере. Сначала посмотрим информацию о сетевых интерфейсах:

Обращаем внимание на адреса туннеля vpn. Теперь проверяем статические маршруты:

Тут тоже все в порядке. Траффик из подсети филиала 192.168.20.0/24 будет маршрутизироваться в тоннель. С настройкой сервера закончили, идем теперь на клиент.

Настройка в CentOS 7 клиента openvpn

На centos-client отключаем SELinux, создаем в директории /etc/openvpn файл конфигурации client.conf:

# mcedit /etc/openvpn/client.conf

dev tun
proto udp
remote 192.168.1.25 13555
client
resolv-retry infinite
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
route 192.168.10.0 255.255.255.0
persist-key
persist-tun
comp-lzo
verb 3
status /var/log/openvpn/openvpn-status.log 1
status-version 3
log-append /var/log/openvpn/openvpn-client.log

Не забываем скопировать в /etc/openvpn сохраненные ранее ключи ca.crt, client.crt, client.key.

Обращаю внимание на параметр route в данном конфиге. Его можно здесь не указывать, сделав конфиг более унифицированным для множества клиентов. Вместо этого данную настройку можно передавать с сервера openvpn, указав в файле настроек клиента параметр push route следующим образом:

push "route 192.168.10.0 255.255.255.0"

Создаем каталог для логов:

# mkdir /var/log/openvpn

Запускаем openvpn client:

# systemctl start openvpn@client

Добавляем в автозагрузку:

# systemctl enable openvpn@client

Теперь смотрим картину настроек на клиенте:

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

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

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

net.ipv4.ip_forward = 1

в файл /etc/sysctl.conf и применить настройку:

# sysctl -p

Если у вас этого не сделано, то трафик между интерфейсами ходить не будет. Ниже мои конфиги iptables.

Centos-server:

#!/bin/bash
#
# Объявление переменных
export IPT="iptables"

# Интерфейс который смотрит в интернет
export WAN=eth0
export WAN_IP=192.168.1.25

# Локалка
export LAN=eth1
export LAN_IP_RANGE=192.168.10.0/24

# Очистка всех цепочек iptables
$IPT -F
$IPT -F -t nat
$IPT -F -t mangle
$IPT -X
$IPT -t nat -X
$IPT -t mangle -X

# Установим политики по умолчанию для трафика, не соответствующего ни одному из правил
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

# разрешаем трафик для loopback и локалки
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
$IPT -A INPUT -i $LAN -j ACCEPT
$IPT -A OUTPUT -o $LAN -j ACCEPT

# разрешаем пинги
$IPT -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
$IPT -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
$IPT -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
$IPT -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Разрешаем исходящие соединения самого сервера
$IPT -A OUTPUT -o $WAN -j ACCEPT

# Разрешаем OpenVPN
$IPT -A INPUT -i tun+ -j ACCEPT
$IPT -A OUTPUT -o tun+ -j ACCEPT
$IPT -A FORWARD -i tun+ -j ACCEPT
# Разрешаем доступ из внутренней сети в vpn
$IPT -A FORWARD -i $LAN -o tun+ -j ACCEPT

# Разрешаем доступ из внутренней сети наружу
$IPT -A FORWARD -i $LAN -o $WAN -j ACCEPT

# Маскарадинг
$IPT -t nat -A POSTROUTING -o tun0 -j MASQUERADE
$IPT -t nat -A POSTROUTING -o $WAN -s $LAN_IP_RANGE -j MASQUERADE

# Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении.
# Пропускать все уже инициированные соединения, а также дочерние от них
$IPT -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
# Пропускать новые, а так же уже инициированные и их дочерние соединения
$IPT -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
# Разрешить форвардинг для уже инициированных и их дочерних соединений
$IPT -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

# Включаем фрагментацию пакетов. Необходимо из за разных значений MTU
$IPT -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Отбрасывать все пакеты, которые не могут быть идентифицированы
# и поэтому не могут иметь определенного статуса.
$IPT -A INPUT -m state --state INVALID -j DROP
$IPT -A FORWARD -m state --state INVALID -j DROP

# Приводит к связыванию системных ресурсов, так что реальный
# обмен данными становится не возможным.
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPT -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP

# Открываем порт для ssh
$IPT -A INPUT -i $WAN -p tcp --dport 22 -j ACCEPT

# Открываем порт для openvpn
$IPT -A INPUT -i $WAN -p udp --dport 13555 -j ACCEPT

# Записываем правила
/sbin/iptables-save > /etc/sysconfig/iptables

В сentos-client настройки абсолютно такие же, кроме переменных WAN, LAN и LAN_IP_RANGE.

Подробнее о настройке iptables читайте в соответствующем материале.

Если ваш openvpn клиент не подключается, то в первую очередь проверяйте настройки firewall — входящие подключения к серверу и исходящие клиента. Обратите внимание на номер порта и тип (TCP или UDP) если вы их меняли. У меня были затупы, когда никак не мог разобраться, почему нет соединения. Оказывалось, что я менял порт c UDP на TCP, но по привычке на фаерволе оставлял UDP.

Теперь давайте проверим, как бегают пакеты в нашей vpn сети. Заходим на centos-client (192.168.20.1) и пингуем centos-server (192.168.10.1) и pc1 (192.168.10.50):

Заходим на pc2 (192.168.20.50) и пингуем centos-server и pc1:

Теперь в обратную сторону. Заходим на pc1 (192.168.10.50) и пингуем centos-client (192.168.20.1) и pc2 (192.168.20.50):

И напоследок пропингуем с vpn сервера подсеть клиента:

В завершение темы объединения удаленных офисов, проверим доступ к общим сетевым ресурсам. Расшарим папку на PC2 и зайдем на нее с PC1:

Все получилось. Мы реально объединили удаленные офисы в единую логическую сеть с помощью openvpn сервера.

Настройка openvpn client в windows

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

Первым делом идем на сервер и создаем для клиента сертификаты.

# cd /etc/openvpn/keys/easy-rsa-master/easyrsa3
# ./easyrsa gen-req user1 nopass
# ./easyrsa sign-req client user1

Процедура такая же, как и при создании первого сертификата клиента, который мы уже сгенерировали ранее. На выходе имеем два файла: user1.key и user1.crt. Добавляем сюда ключ ca.crt и передаем пользователю на компьютер.

Дальше создаем файл конфигурации для этого клиента:

# cd /etc/openvpn/ccd
# mcedit user1
push "route 192.168.10.0 255.255.255.0"
push "route 192.168.20.0 255.255.255.0"

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

Теперь нужно скачать openvpn client под нашу версию windows. Ссылки для скачивания я давал в самом начале статьи. Дальше выполняем установку клиента. Обращаю внимание, что запускать установщик нужно обязательно с правами администратора:

Приступаем к настройке клиента в windows. Для этого нам понадобится файл конфигурации. Можно взять уже готовый config, который мы создавали ранее и немного изменить его. Файл конфигурации openvpn клиента должен выглядеть вот так:

dev tun
proto udp
remote 192.168.1.25
port 13555
client
resolv-retry infinite
ca ca.crt
cert user1.crt
key user1.key
persist-key
persist-tun
comp-lzo

У нас нет задачи видеть сеть за клиентом, да и он скорее всего не будет являться шлюзом, поэтому параметра route в конфиге нет. Плюс убраны пути для логов — openvpn будет создавать их в папке по-умолчанию. Сохраняем конфигурацию под именем openvpn.ovpn в папку C:\Program Files\OpenVPN\config, туда же копируем файлы сертификатов и запускаем OpenVPN GUI от имени администратора!

Это важно, без прав администратора openvpn client для правильной маршрутизации не сможет прописать необходимые  маршруты.

Ищем серый мониторчик в трее, нажимаем правой кнопкой мыши на него и выбираем «Подключиться».

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

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

--connect "openvpn.ovpn"

Для этого выбираем ярлык на рабочем столе OpenVPN GUI, выбираем его и нажимаем правой кнопкой мыши, открываем «Свойства».  На вкладке «Ярлык» в поле «Объект» в самом конце дописываем указанные параметры. Вся строка должна выглядеть следующим образом:

"C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --connect "openvpn.ovpn"

Теперь при запуске ярлыка openvpn будет автоматически подключаться к серверу и устанавливать vpn соединение.

Мы подключились к корпоративной vpn сети, объединяющую 2 офиса. Давайте попробуем получить доступ к компьютерам внутри этой сети.  Пингуем все машины из нашей схемы:

Отлично, связь есть. Теперь попробуем зайти на сетевой ресурс, который мы создали ранее на компьютере сети филиала PC2:

Доступ есть, все в порядке.

Заключение

Теперь подведем итоги того, что мы сделали:

1. В первую очередь настроили сервер openvpn на CentOS 7. Для этого создали инфраструктуру для удостоверяющего центра СА, с помощью которого мы создаем сертификаты.
2. Затем с помощью этого центра сформировали сертификаты для сервера и клиента, в роли которых выступает головной офис компании и его филиал.
3. Потом мы настроили openvpn сервер в офисе компании и подключили к нему в качестве клиента сервер филиала. Проверили это соединение, взаимную доступность узлов обоих сетей.
4. В завершении сформировали сертификат для удаленного сотрудника и настроили ему подключение openvpn клиента в windows. Проверили доступность всех узлов обоих сетей.

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

Сообщение Настроить openvpn на CentOS 7 появились сначала на Clip-Clap.

Существует проверенная временем связка для прокси сервера — squid + sams. Я настраивал ее еще лет 8 назад на Freebsd. Недавно у меня появилась необходимость настроить что-то подобное на CentOS 7, и я с удивлением обнаружил, что ничего принципиально нового с тех пор не появилось. Никакой более удобной и информативной web панели к squid не придумали.

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

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

Добавление CentOS 7 в домен Windows

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

Я без проблем ввел компьютер в домен, прошел все проверки, но потом в squid напрочь отказывалась работать ntlm авторизация. Все на вид выглядело нормально, но не работало. Я несколько раз восстанавливал виртуалку и начинал все сначала, перечитав практически все, что смог найти по теме в рунете и буржунете. В какой-то момент все заработало. Я зафиксировал результат и несколько раз проверил последовательность действий и отточил ее до каждого шага. Проверил несколько раз на чистой системе. По крайней мере на момент написания статьи конфигурация на 100% рабочая, если аккуратно повторить все мои действия. Приступаем.

Сначала остановим и отключим firewalld:

# systemctl stop firewalld && systemctl disable firewalld

Это не значит, что его не надо настраивать. Сейчас другая тема статьи, для локализации проблем необходимо убрать все, что теоретически может мешать при неправильной настройке. Firewall нужно настраивать и у меня есть подробная инструкция по настройке iptables. Рекомендую с ней ознакомиться и аккуратно настроить iptables, когда все получится со squid.

Установим софт для добавления сервера в домен windows:

# yum -y install samba-winbind samba-winbind-clients pam_krb5 krb5-workstation ntp ntpdate

Для продолжения настройки вам необходимо знать следующие вещи — FQDN имя контроллера домена, его ip адрес и учетную запись с правами на ввод компьютера в домен.

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

# ntpdate winsrv.xs.local

Добавляем наш контроллер в список серверов для обновления в файле /etc/ntp.conf, запускаем ntp и добавляем в автозагрузку:

# systemctl enable ntpd
# systemctl start ntpd

Синхронизация времени с контроллером домена не является обязательным действием. Но в случае расхождения времени более чем на 5 минут, будут возникать проблемы, которые на первый взгляд будут неочевидными и решать их трудно. Поэтому на всякий случай процедуру лучше провести. Очень подробно о настройке времени в CentOS 7 рассказано отдельно.

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

# authconfig --enablekrb5 --krb5kdc=winsrv.xs.local --krb5adminserver=winsrv.xs.local --krb5realm=WINSRV.XS.LOCAL --enablewinbind --enablewinbindauth --smbsecurity=ads --smbrealm=XS.LOCAL --smbservers=winsrv.xs.local --smbworkgroup=XS --winbindtemplatehomedir=/home/%U --winbindtemplateshell=/bin/bash --enablemkhomedir --enablewinbindusedefaultdomain --update

Команда вся идет в одну строчку. Скопируйте ее сначала в текстовый файл и подредактируйте под свои параметры. Проверьте, что нигде не пропали и не добавились лишние пробелы, либо какие-то еще символы, тире должно быть двойным перед параметром. В данном случае:

• xs — название домена
• winsrv — имя контроллера домена
• winsrv.xs.local — полное имя домена

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

Job for winbind.service failed. See 'systemctl status winbind.service' and 'journalctl -xn' for details.
getsebool: SELinux is disabled

Это нормально. Обращаю внимание, что SELinux у меня отключен.

Теперь заводим машину в домен:

# net ads join -U administrator
Enter administrators's password:
Using short domain name -- XS
Joined 'PROXY' to dns domain 'xs.local'

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

Теперь нужно запустить и добавить в автозагрузку winbind:

# systemctl start winbind
# systemctl enable winbind

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

# wbinfo -t 
checking the trust secret for domain XS via RPC calls succeeded

Все в порядке. Теперь проверяем, может ли наш сервер получать списки пользователей и групп. Первая команда выводит список всех групп домена, вторая — всех пользователей:

# wbinfo -g
# wbinfo -u

Проверим авторизацию пользователя через winbind:

# wbinfo -a XS\\control%'pass'
plaintext password authentication succeeded
challenge/response password authentication succeeded

В данном случае control — имя пользователя домена, pass — его пароль. Успешная проверка выглядит так, как у меня.

Теперь запросим билетик кербероса:

# kinit administrator@XS.LOCAL

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

# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: administrator@XS.LOCAL

Valid starting Expires Service principal
12/04/2015 23:19:33 12/05/2015 09:19:33 krbtgt/XS.LOCAL@XS.LOCAL
renew until 12/11/2015 23:19:29

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

Настройка SQUID с ntlm авторизацией через домен

Дальше будет попроще. Если на предыдущем этапе вы все сделали правильно, то squid заработает без проблем. Устанавливаем его:

# yum -y install squid

Открываем файл конфигурации /etc/squid/squid.conf и добавляем в самое начала следующие параметры:

auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=XS
auth_param ntlm children 10
auth_param ntlm keep_alive off
acl auth proxy_auth REQUIRED

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

Дальше находим в конфиге строку:

http_access allow localnet

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

http_access allow auth

Разрешаем доступ только тем, кто прошел авторизацию. Запускаем squid и добавляем в автозагрузку:

# systemctl start squid
# systemctl enable squid

Все, можно идти проверять. Открываем браузер у какого-нибудь компьютера и указываем в качестве прокси ip адрес сервера, порт 3128. Пробуйте выйти в интернет.

Как понять, что все работает правильно:

1. Пользователя должно пустить в интернет.
2. В лог файле сквида должна быть информация об имени пользователя, который получает доступ. У меня это выглядит примерно вот так при открытии страницы яндекса:

# cat /var/log/squid/access.log | grep control

1449261311.346 9 10.1.4.189 TCP_MISS/304 438 GET http://yastatic.net/islands/_/S1-qWWyv85yFAtoHVvuxJXpOKA4.svg control HIER_DIRECT/178.154.131.217 -
 1449261311.351 11 10.1.4.189 TCP_MISS/200 622 GET http://yastatic.net/www/_/_/y/ljN5poHcx67T3HSZuHbvf2NNk.png control HIER_DIRECT/178.154.131.217 image/png
 1449261311.404 9 10.1.4.189 TCP_MISS/304 440 GET http://yastatic.net/morda-logo/i/disaster/metro11072015.png control HIER_DIRECT/178.154.131.217 -
 1449261311.488 97 10.1.4.189 TCP_MISS/302 355 GET http://kiks.yandex.ru/fu control HIER_DIRECT/213.180.204.143 -
 1449261311.507 9 10.1.4.189 TCP_MISS/304 341 GET http://kiks.yandex.ru/system/fc07.swf control HIER_DIRECT/213.180.204.143 -

В данном случае control — доменная учетная запись.

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

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

Установка и настройка sams2 в CentOS 7

И вот мы подошли  самому главному и трудному. Когда я решил написать статью на эту тему, я подозревал, что установить sams2 в CentOS 7 будет тяжело, но не думал, что настолько. Пришлось разбить работу на два этапа. Первый этап мы уже прошли, а со вторым мне пришлось поковыряться не один день, пока все не получилось так, как хотелось.

Трудности тут с тем, что проект sams2 давно заброшен, под CentOS 7 он вообще не планировался, готового пакета нет. Есть только старые пакеты для 6-й версии и исходники. Я буду собирать sams2 из исходников и очень аккуратно опишу все этапы, по которым прошел. Столкнулся с множеством ошибок, пришлось немного править исходники, чтобы собранные версии нормально работали. Потом с настройками много нюансов, которые нигде не описаны, пришлось ковыряться самому.

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

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

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

Приступаем к работе. Нам нужно настроить web сервер для работы интерфейса sams. Можно воспользоваться моей инструкцией, можно чем-то еще. Не обязательно ставить apache, можно настроить на nginx и php-fpm, либо на lighttpd. Я для простоты все сделаю на апаче. Останавливаться подробно не буду на каждом из этапов, все описание есть в первой ссылке абзаца. Привожу только команды.

Устанавливаем httpd:

# yum install -y httpd

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

# systemctl enable httpd
# systemctl start httpd

Устанавливаем php и некоторые модули:

yum install -y php
yum install -y php-mysql php-mbstring php-mcrypt php-devel php-xml php-gd

Устанавливаем mariadb

yum install -y mariadb mariadb-server mariadb-devel

Обращаю внимание на последний пакет. Без него установить sams2 не получится, хотя его наличие в списке необходимых пакетов не очевидно. Я сначала его не установил и при сборке самс не видел у меня установленного сервера mysql.

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

# systemctl enable mariadb.service
# systemctl start mariadb

Задаем пароль рута:

# /usr/bin/mysql_secure_installation

Подключаем репозиторий epel и устанавливаем phpmyadmin. Это не обязательно, но мне с ним удобнее:

# yum -y install epel-release
# yum -y install phpmyadmin

Все подготовительные работы сделаны. Убедитесь, что у вас нормально работает веб сервер и скрипты php. Я не буду на этом останавливаться. Так удобнее будет для вас. Если сейчас не проверить веб сервер, то потом, если у вас недостаточно опыта в работе, вы не поймете, что у вас не работает — сам самс или что-то другое. Лучше все подготовить и проверить по отдельности.

Скачиваем исходники sams2 в домашний каталог root. Все работы будут проделываться под этой учетной записью.

# yum -y install wget
# cd /root
# wget https://github.com/PavelVinogradov/sams2/archive/master.zip

Ставим unzip и распаковываем архив:

# yum -y install unzip
# unzip master.zip

Исходники программы лежат в папке /root/sams2-master. В ней ищем папку src и файл proxy.h. Его нужно будет отредактировать. Открываем редактором, ищем все строчки со значением enum и правим их:

# mcedit /root/sams2-master/src/proxy.h

Было так:

enum TrafficType

меняем на

enum TrafficType: long

И так все строчки с этим значением. Их должно быть 5 штук. Сохраняем файл и закрываем. Если не внести эти изменения и собрать исходники как есть, то sams2daemon будет падать с ошибкой:

kernel: sams2daemon[27541]: segfault at ffffffffffffffe8 ip 00007fc54880944b sp 00007ffc8da37d20 error 5 in libstdc++.so.6.0.19[7fc54874b000+e9000]

Это связано с тем, что CentOS 7 64-x битная система, а из этих исходников программа нормально собирается только на 32-х битных системах.

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

# yum -y install autoconf automake libtool pcre-devel libstdc++-devel gcc-c++

Переходим в каталог с исходниками и начинаем компиляцию:

# cd /root/sams2-master
# make -f Makefile.cvs

Запускаем скрипт автоматической конфигурации:

# sh ./configure

Он должен отработать без ошибок и в конце вывести полезную информацию:

Сохраните пути, они позже пригодятся во время настройки. Обратите внимание на подчеркнутые строки. Без первой строки не будет поддержки mysql, без второй не заработают списки запрета доступа. Убедитесь, что все в порядке с ними.

Выполняем установку sams2:

# make install

У меня она почему-то проходит с ошибкой:

Суть ошибки в этой строке:

chmod: cannot access '//usr/local/share/sams2/data': No such file or directory

Я не знаю, почему инсталлятор не может создать эту папку сам. Хотя проблема возможно просто в ошибке в исходниках, в пути почему-то стоят два слеша в начале. Я просто руками создал эту директорию и заново запустил установку:

# cd /usr/local/share/sams2/
# mkdir data
# cd /root/sams2-master
# make install

Установка прошла успешно. Добавляем директорию с web интерфейсом sams2 в httpd. Для этого идем в директорию с конфигурациями и рисуем следующий файл настроек для самса:

# mcedit /etc/httpd/conf.d/sams2.conf

Alias /sams2 /usr/local/share/sams2
<Directory /usr/local/share/sams2/>
 AddDefaultCharset UTF-8
 <IfModule mod_authz_core.c>
  <RequireAny>
   Require ip 10.1.3.0/24 10.1.4.0/24
  </RequireAny>
 </IfModule>
</Directory>

10.1.3.0/24 10.1.4.0/24 — подсети из которых будет доступ к web интерфейсу. Можете просто указать ip адрес администратора, если доступ будет нужен только с его компьютера.

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

# rm /etc/httpd/conf.modules.d/doc4sams2.conf
# rm /etc/httpd/conf.modules.d/sams2.conf

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

# systemctl restart httpd

Теперь если зайти по адресу htpp://ip-сервера/sams2 вы увидите сообщение:

Invalid query: Access denied for user 'apache'@'localhost' (using password: NO)

Это нормально. Пока так и должно быть.

Редактируем конфигурационный файл sams2.conf:

# mcedit /usr/local/etc/sams2.conf

DB_ENGINE=MySQL
DB_SERVER=localhost
SAMS_DB=sams2db
ODBC=0
PDO=0
ODBCSOURCE=sams_mysql
DB_USER=root
DB_PASSWORD=rootpass
SQUIDCACHEFILE=access.log
SQUIDROOTDIR=/etc/squid
SQUIDLOGDIR=/var/log/squid
SQUIDCACHEDIR=/var/spool/squid
WBINFOPATH=/usr/local
SAMSPATH=/usr/local
SQUIDPATH=/usr/sbin
SQUIDGUARDLOGPATH=/var/log
SQUIDGUARDDBPATH=/var/db/squidguard
RECODECOMMAND=iconv -f KOI8-R -t 866 %finp > %fout
REJIKPATH=/usr/local/rejik
SHUTDOWNCOMMAND=shutdown -h now
CACHENUM=1

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

Нажимаем Run setup program >> . И получаем сообщение об ошибке:

При этом в логе httpd следующая информация:

# cat /var/log/httpd/error_log

PHP Parse error: syntax error, unexpected '$configbuttom_7_log_2' (T_VARIABLE) in /usr/local/share/sams2/lang/lang.EN on line 1100, referer: http://10.1.4.14/sams2/index.php

Это очередной баг самс2. Чтобы его исправить, открываем на редактирование файл /usr/local/share/sams2/lang/lang.EN идем на строку 1100 и после нее убираем все пробелы перед последующими строками:

# mcedit /usr/local/share/sams2/lang/lang.EN

Делаем так:

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

Проходит проверка требований. У меня такие результаты:

Создаем базу данных. Убедитесь, что пользователя и базы данных для самс, которые вы будете указывать, у вас еще нет в mysql, иначе получите ошибку. Заполняете данные для root и для нового пользователя:

Установка прошла успешно:

Теперь нужно снова отредактировать файл sams2.conf и заменить пользователя mysql на только что созданного:

# mcedit /usr/local/etc/sams2.conf

Проверим работу веб интерфейса. Переходим снова по адресу http://ip-сервера/sams2. Мы должны увидеть окно авторизации. Нажимаем снизу на Авторизация администратора SAMS и вводим пользователя admin, пароль — qwerty. Открывается главное окно системы:

Теперь нам нужно запустить демон sams2daemon. Создадим скрипт запуска. Для этого идем в папку /root/sams2-master/redhat и редактируем файл init.d:

# mcedit /root/sams2-master/redhat/init.d

Находим там значение  __CONFDIR и меняем его на /usr/local/etc/, значение __PREFIX меняем на /usr/local/bin/. У вас должны получиться 2 измененные строки следующего вида, остальные оставляем как есть:

[ -f /usr/local/etc/sams2.conf ] || exit 0
DAEMON=/usr/local/bin/sams2daemon

Копируем скрипт запуска в папку /etc/init.d:

# cp /root/sams2-master/redhat/init.d /etc/init.d/sams2

Запускаем демон:

# /etc/init.d/sams2 start
Starting sams2 (via systemctl): [ OK ]

Если будут какие-то ошибки, то смотрите общий лог messages.

На этом установка sams2 закончена. Можно приступать к настройке. Здесь она может отличаться, в зависимости от того, что вы хотите получить. Добавим в sams пользователей из домена. Для этого заходим в веб интерфейс и идем в раздел Авторизация. Убираем все галочки, оставляем только NTLM и жмем Конфигурировать. Появляется новый подпункт NTLM. Заходим в него и нажимаем снизу на отвертку и ключ:

Заполняем настройки. В моем случае они выглядели вот так:

Если все правильно ввели, то при нажатии на кнопку Тестировать NTLM-подключение вы увидите список пользователей и групп домена.

Чтобы добавить пользователей домена в качестве пользователей самс, необходимо в разделе NTLM снизу нажать на кнопку с домиком и подписью Регистрация новых пользователей, входящих в домен Windows. Выбрать через контрол всех пользователей, которых хотите добавить и нажать Добавить.

Они появятся в списке пользователей:

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

Теперь нужно применить сделанные настройки. Для этого идем в раздел SQUID -> Proxy server и жмем снизу на вторую кнопку слева со стрелочками. Нажимаем на Реконфигурировать. В случае успеха увидите надпись:

На всякий случай можно проверить конфиг squid. Там должны появиться только что созданные acl. В моем случае появились следующие строки в конфигурации. Пошел проверять конфиг и обнаружил, что там ничего не появилось. Это связано с тем, что sams редактирует конфиг сквида, ориентируясь на комментарии с метками TAG:. В CentOS 7 после установки конфиг сквида очень сокращен, в нем почти нет комментариев, представлена минимальная конфигурация. Указанных меток там тоже нет, нам их нужно добавить самим. Добавляем в /etc/squid/squid.conf следующие комментарии с метками:

# TAG: acl

# TAG: url_rewrite_access

# TAG: url_rewrite_program

# TAG: url_rewrite_children

# TAG: delay_pools

# TAG: delay_class

# TAG: delay_access

# TAG: delay_parameters

# TAG: http_access

# TAG: http_access2

# TAG: icp_access

Обязательно пустая строка после каждой метки. Теперь заново перезапускаем squid через веб интерфейс самса. Должны появиться изменения в конфиге. У меня добавились следующие строки:

# TAG: acl
acl Sams2Time1 time MTWHFAS 23:00-23:59
acl Sams2Template1 proxy_auth admin51
acl Sams2Template1 proxy_auth control

# TAG: http_access
# Setup Sams2 HTTP Access here
http_access allow Sams2Template1 Sams2Time1

Обращаю внимание на параметр на acl Sams2Time1. По-умолчанию там указан временной интервал с 23:00 до 23:59. В соответствии с этими настройками доступ в интернет будет предоставлен только в это время. Подозреваю, что это ошибка автора, но мне пришлось потратить некоторое время, чтобы понять, почему правильная на первый взгляд конфигурация не работает. Если вам не нужен этот параметр, то уберите вообще временной интервал, либо исправьте его на 00:00-23:59.

Для корректной работы конфигурации необходимо убрать все остальные acl и http_access от предыдущей конфигурации squid, когда самс еще не был установлен.

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

# TAG: url_rewrite_access
acl Sams2Proxy dst your.ip.address
url_rewrite_access deny Sams2Proxy

Из-за значения your.ip.address сквид писал об ошибке конфигурации. Чтобы самс писал сюда нормальное значение в виде ip адреса сервера, необходимо изменить его настройки. Делается это в разделе SQUID -> Proxy server, снизу кнопочка с отверткой и ключом. Нажимаем на нее и изменяем снизу 2 настройки, указывая свой ip адрес:

Попутно на всякий случай проверьте остальные настройки. Я кое-что подредактировал под свои нужды. Сохраняете настройки и снова перезапускаете сквид через самс. Проверяем файл конфигурации squid.conf:

# cat squid.conf | grep Sams2Proxy
acl Sams2Proxy dst 10.1.4.14

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

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

Теперь добавим ограничение для доступа к некоторым сайтам. Для этого идем в раздел Запрет доступа по URL и создаем новый список. Я создал список social и добавил в него адрес социальных сетей для теста: vk.com и ok.ru:

Теперь нужно подключить этот список шаблону по-умолчанию. Идем в шаблон Default, заходим в редактирование и ставим галочку напротив списка social:

Сохраняем изменения шаблона и перезапускаем конфигурацию сквида. Идем к пользователям и проверяем запрет:

При попытке открыть запрещенный сайт, пользователь получит сообщение о запрете. Реализован этот функционал с помощью встроенного в самс редиректора. Никакие другие редиректоры в sams2 не работают. Но как по мне, так и этого достаточно. Что делать если у вас по какой-то причине не работает запрет доступа, как это было у меня?

В первую очередь надо проверить настройки прокси сервера в самс, там где мы указывали ip адрес сервера. Должен быть выбран редиректор встроенный в SAMS. Путь к каталогу, где лежат файлы запрета запроса у меня указан http://10.1.4.14/sams2:

Я не знаю, почему именно такой путь должен быть, я указал наугад, так как по-умолчанию там стоял вообще не существующий адрес. И у меня заработало. Некоторое время я проковырялся с этим параметром, потому что в настройках httpd разрешил доступ к алиасу /sams2 только с машины администратора. А при запрете адреса пользователя редиректит на этот же алиас, и если он не имеет к нему доступа, то просто получает ошибку соединения в браузере и не понятно, то ли сработал запрет, то ли сайт недоступен, то ли с интернетом какие-то проблемы. В общем, было неудобно.

Дальше у меня были проблемы с тем, что сам редиректор не запускался. Я сначала скомпилировал исходники без редактирования под 64 бита, и демон не стартовал. Проверить, запущен ли он можно просто по списку процессов. Если все в порядке, то должен быть запущен  sams2daemon и несколько sams2redir. Проверить можно просто:

# ps ax | grep sams
22721 ? S 0:01 /usr/local/bin/sams2daemon -l syslog
28498 ? S 0:00 (sams2redir)
28667 ? S 0:00 (sams2redir)
28860 pts/1 R+ 0:00 grep --color=auto sams

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

# /usr/local/bin/sams2redir

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

http://ya.ru 10.1.4.189 control - GET
http://ya.ru 10.1.4.189 control - GET

То есть вы вводите первую строку и редиректор тут же выводит точно такую же сам. А вот какая реакция должна быть на сайт под запретом:

http://vk.com 10.1.4.189 control - GET
http://10.1.4.14/sams2/blocked.php?action=urldenied&id=control 10.1.4.189 control -

Идет редирект на страничку blocked.php. Для разбора ситуации можно пойти в логи апача и посмотреть, что там есть на эту тему. Я так заметил, что у пользователей нет доступа к этому адресу, так как он был закрыт настройкой веб сервера. Отмечу еще для справки, что список заблокированных сайтов sams2 хранит в своей базе в таблице url. Возможно вам пригодится эта информация во время отладки.

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

Заключение

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

1. Сервер был введен в домен Windows для настройки авторизации доменных пользователей на прокси сервере.
2. Настроен прокси сервер squid для работы с доменными учетными записями.
3. Собран из исходников многофункциональный web интерфейс для управления squid — sams2 самой последней на текущий момент версии.

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

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

Сообщение Настройка прокси сервера на CentOS 7 (squid+AD+sams2) появились сначала на Clip-Clap.

Что такое Webmin

Webmin это web панель для администрирования unix сервера. Она кроссплатформенная, ставится на различные unix дистрибутивы. С помощью webmin можно выполнять практически все популярные административные действия на сервере, такие как:

• Настраивать сетевые подключения
• Добавлять пользователей
• Монтировать разделы
• Настраивать фаерволл
• Выключать или перезагружать сервер
• Обновлять пакеты

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

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

Я почти всегда использую webmin на почтовых серверах. Мне удобно анализировать и что-то искать в огромных почтовых логах с помощью модуля просмотра логов. Чего-то более простого и удобного мне не попадалось. К примеру, у вас есть лог за день на 100-300 мегабайт, в нем каждую секунду фиксируются десятки событий. У вас есть id письма. Можно ввести в строку поиска id письма и увидеть все строки лога, в которых оно фигурирует. Это очень удобно. Обычным поиском в такой ситуации не обойтись. Можно, конечно, грепать вывод cat, либо что-то еще придумывать, но это менее удобно. Особенно, если надо сопоставить значения из разных лог-файлов. Просто открываешь в двух окнах браузера разные логи и анализируешь.

Приступим к установке webmin. Статья подразумевает, что у вас уже установлена и настроена операционная система. Если это не так, то читайте про установку и настройку CentOS 7.

Установка Webmin на CentOS 7

Приступим к установке Webmin на сервер под упралвением СentOS 7. Процесс описан на официальном сайте в соответствущем разделе. Ничего сложного нет. Нужно добавить репозиторй webmin, а потом произвести установку самого пакета и зависимостей.

Добавляем репозиторий:

# mcedit /etc/yum.repos.d/webmin.repo

[Webmin]
name=Webmin Distribution Neutral
#baseurl=http://download.webmin.com/download/yum
mirrorlist=http://download.webmin.com/download/yum/mirrorlist
enabled=1

Импортируем GPG ключ:

# rpm --import http://www.webmin.com/jcameron-key.asc

Устанавливаем Webmin:

# yum install -y webmin

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

# chkconfig webmin on

Настройка Webmin

Заходим в web интерфейс webmin по ссылке https://192.168.56.10:10000, где 192.168.56.10 ip адрес сервера. Обязательно указывайте протокол https, без этого не зайти. Вводите логин и пароль root. Открывается главная страница webmin:

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

Если он будет в открытом доступе, то рекомендую хотя бы сменить стандартный порт на какой-то более высокий и непопулярный. Делается это в разделе Webmin -> Webmin configuration -> Ports and Addresses

Если будете заходить со статических адресов, то ограничьте доступ только этим адресам. Делается тут же, в соседней настройке IP Access Control. Рекомендую именно эту настройку. Открывать в мир webmin лично я бы не стал без особой надобности.

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

На этом все, с остальными возможностями и настройками можно самостоятельно разобраться, в вебмине ничего сложного нет.

Сообщение Установка и настройка удаленного доступа на CentOS 7 с помощью Webmin появились сначала на Clip-Clap.

Лично я столкнулся с этой проблемой на обновленном почтовом сервере, который я настроил на Centos 8. Я предполагал, что может возникнуть такая проблема и подстраховался параметрами postfix.

smtpd_tls_security_level = may
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtpd_tls_ciphers = low

Ожидал, что это позволит подключаться клиентам со старыми версиями TLS. А тем, кто совсем никак не может, оставил возможность подключаться по нешифрованному соединению. По факту некоторым не помогло. У клиентов были различные ошибки. Чаще всего это те, у кого сам tls устарел, но при этом запрещены нешифрованные подключения. Вот несколько вариантов ошибок.

TLS connect failed: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version;

14969:error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version:s3_pkt.c:1092:SSL alert number 70

warning: TLS library problem: error:1420918C:SSL routines:tls_early_post_process_client_hello:version too low:ssl/statem/statem_srvr.c:1655:

И все в таком духе. Сервер в активной работе. Таких клиентов хоть и не много было, но тем не менее несколько нашлось. Настройки postfix в части разрешенных протоколов tls не работали, так как они запрещены на уровне системы. Подробнее об этом написано в документации Red Hat.

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

# update-crypto-policies --set LEGACY
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

После этого надо перезапустить postfix и проверить с какого-нибудь другого сервера подключиться к целевому по протоколу tls 1.0, например вот так.

# openssl s_client -starttls smtp -connect mail.site.ru:25 -tls1

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

Если же вам не повезло настолько, что надо разрешить работу по протоколу ssl3, то я вам сочувствую Я не знаю, каким образом это можно сделать на современной системе. Наверное, придется самим собирать openssl из старых исходников и как-то ставить в систему. Задача не простая.

Сообщение Centos 8 и TLS 1.0 и 1.1 появились сначала на Clip-Clap.

Cистемные требования CentOS 7

7 июля 2014 года увидел свет релиз дистрибутива CentOS 7. Перед его установкой рекомендуется ознакомиться с системными требованиями. Подробно посмотреть полный список максимальных и минимальных системных требований можно на официальном wiki. Я же приведу только самые важные параметры:

Это официальные данные с сайта CentOS. У RHEL они такие же, я проверял. У меня лично на VDS благополучно все работает и с 512MB памяти, меньше не пробовал ставить, думаю и с 256 заведется.

Типы iso образов CentOS 7

Релиз CentOS содержал в себе несколько видов iso образов. Подробное описание каждого из них представлено в таблице:

Я обычно использую для установки либо minimal образ, либо netinstall.

Cкачать CentOS 7

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

1. Через torrent сеть
2. С ближайшего зеркала

Я в качестве такого зеркала предпочитаю использовать CentOS Yandex Mirror:

Напоминаю, что 32 bit или i386 редакции CentOS 7 не существует. Все дистрибутивы только x86_64, то есть 64 bit.

Загрузочная флешка для CentOS 7

Последнее время лично я практически не пользуюсь обычными CD, предпочитая им загрузочные флешки. Они удобнее, занимают меньше места, проще обновить дистрибутив на них. Но иногда приходится заморочиться для создания загрузочной флешки. Например, для создания загрузочной флешки CentOS 6 я раньше пользовался программой unetbootin, но с 7-й версией этот номер не прошел. Созданная в ней флешка не позволяет установить CentOS 7, так как сам инсталлятор в какой-то момент не видит источник установки на флешке.

Но на выручку пришла бесплатная программа Win32DiskImager. С ее помощью без проблем удается создать загрузочную флешку CentOS 7. Вот как это делается:

1. Скачиваем дистрибутив программы.
2. Скачиваем дистрибутив CentOS 7. Я для теста использовал версию Minimal.
3. Вставляем чистую флешку, запускаем программу и указываем настройки:
4. Нажимаем Write и ждем окончания записи.
5. Загрузочная флешка CentOS 7 готова.

Этого достаточно для создания флешки. Теперь ей можно пользоваться для установки операционной системы с флешки.

Установка CentOS 7 с флешки

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

Выбираем первый пункт: Install CentOS 7 и жмем enter. После загрузки инсталлера, нас встречает окно с выбором языка, который будет использоваться во время установки. Я всегда выбираю Еnglish, мне так привычнее:

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

CentOS 7 minimal

Если вы используете диск centos minimal iso, то увидите следующий экран:

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

1. Выбор часового пояса centos.
2. Выбор раскладки клавиатуры.
3. Поддержка каких языков будет осуществляться на сервере.
4. Откуда будет происходить установка. Так как у нас дистрибутив centos minimal, установка будет с локального iso.
5. Выбор пакетов для установки. В образе minimal доступен только минимальный набор софта.
6. Разбивка жесткого диска. Подробнее коснемся этого пункта, когда будем разбирать установку на raid.
7. Настройка сетевых интерфейсов.

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

Итак, нажимаем на DATE & TIME и настраиваем параметры времени:

1. Указываем регион.
2. Выбираем город.
3. Включаем при необходимости службу времени для синхронизации часов centos с внешними серверами.
   Это возможно сделать только если вы уже настроили сетевые параметры. Если нет, то вернитесь к этой настройке позже.
4. Выбираем список внешних серверов для синхронизации времени: 
5. Указываем формат, в котором будет отображаться текущее время.
6. При необходимости изменяем дату сервера.

После завершения настроек жмем сверху синюю кнопку Done.

Идем в следующую настройку — KEYBOARD LAYOUT:

1. Добавляем необходимые раскладки. Я добавил Russian.
2. Нажимаем Options и выбираем, как будет происходить переключение раскладок.
3. Тестируем раскладки и переключение. Если все в порядке, идем дальше.

Нажимаем LANGUAGE SUPPORT:

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

Теперь выполним сетевые настройки. Идем в раздел NETWORK & HOSTNAME. Включаем ползунок в положение ON и получаем автоматически настройки по dhcp:

1. Включение ползунка в положение ON активирует интерфейс, он получает настройки по dhcp.
2. Если вы хотите изменить эти настройки, нажимаете Configure.
3. Указываете hostname. Если забудете, то после установки этот параметр можно изменить.

Завершаем настройку нажатием на Done. Теперь можно вернуться в настройки часов и активировать Network Time.

Теперь перейдем в раздел INSTALLATION SOURCE. При установке centos minimal менять этот параметр нет необходимости. Там по-умолчанию установлен локальный источник, нам это подходит. Можно ничего не трогать:

В разделе SOFTWARE SELECTION при minimal установке тоже нечего выбрать, уже указан единственно возможный вариант:

Нам осталось рассмотреть последнюю обязательную настройку, без которой установка centos не начнется — INSTALLATION DESTINATION. Зайдя в нее вы увидите список подключенных к серверу дисков. В моем случае это один жесткий диск.

Если ваш диск определился правильно, выбираете его и нажимаете Done. Выскакивает окошко с предупреждением, что для установки системе понадобится примерно 1 Гб места на жестком диске, а на вашем жестком диске нет необходимого свободного места. Это происходит потому, что раньше на этом диске была установлена другая система и она занимала весь жесткий диск. Нам нужно удалить всю старую информацию для установки новой системы. Делаем это, нажимая Reclaim space:

Выбираем диск и удаляем все существующие разделы на нем — жмем сначала Delete all, а потом Reclaim space:

После этого установщик выберет весь диск в качестве диска для установки. После этого можно начать непосредственно установку centos, нажав кнопку Begin Installation.

Дальше рассмотрим вариант, когда вы выполняете установку с образа netinstall.

CentOS 7 netinstall

Установка Centos 7 с образа netinstall отличается от прочих только одним моментом. Во время подготовки к установке по сети в разделе INSTALLATION SOURCE вам вместо локального источника необходимо указать путь к образу, расположенному где-то в сети. Очевидно, что перед этим необходимо выполнить настройку сети и убедиться, что у компьютера есть доступ в интернет.

В качестве источника для установки я буду использовать упомянутое ранее зеркало яндекса. CentOS netinstall url —  https://mirror.yandex.ru/centos/7/os/x86_64/На скриншоте указан старый url. После череды обновлений он стал неактуален. Правильная ссылка выше в тексте.

Указываем путь и жмем Done. После проверки доступности источника, в разделе SOFTWARE SELECTION можно выбрать необходимый для установки набор софта:

Дальше можно начинать установку, указав все остальные параметры, которые мы рассмотрели выше.

CentOS 7 установка на raid

Теперь рассмотрим наиболее сложный вариант установки. Мы будем ставить CentOS 7 на программный рейд. Для примера возьмем 2 диска и raid 1. Все установки будут такие же, как мы рассмотрели ранее, кроме одной — INSTALLATION DESTINATION.

Подключаем 2 диска к системе, загружаемся с установочного диска и идем в раздел разбивки диска. Видим 2 жестких диска. Выбираем оба и отмечаем пункт I will configure partition:

Жмем Done. Открывается немного кривое окно управления разделами жесткого диска.

Здесь мы первым делом удаляем все существующие разделы:

И создаем свои новые, нажимая плюсик. Нам нужно создать 3 раздела: boot, swap и корень /. Размеры разделов выбирайте сами, исходя из своих потребностей и оперативной памяти на сервере. Для раздела boot достаточно 500Мб, для swap хватит объема оперативной памяти. Все остальное можно либо заполнить одним корневым разделом, либо создать несколько, если в этом есть необходимость. Device Type ставим RAID. Тип файловой системы выбирайте на свое усмотрение. Что лучше — xfs или ext4 зависит от конкретной ситуации. Считается, что xfs работает лучше с большими файлами, ext4 с кучей мелких. Это тема отдельного разговора. RAID Level указываем RAID1.

Должно получиться примерно так:

Нажимаем Done, когда закончим. В новом окне подтверждаем разбивку диска, нажимая Accept Сhanges:

Все остальные параметры выставляем как было рассказано выше. Теперь можно начинать установку CentOS 7 на программный raid, который мы только что создали.

Во время установки нужно указать пароль root, либо создать дополнительных пользователей. Пароль рекомендую установить, пользователей по необходимости.

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

# df -h
# cat /proc/mdstat

Посмотрим информацию о корневом массиве:

# mdadm -D /dev/md126

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

Я очень рекомендую использовать софтовый raid линукса mdadm в повседневной деятельности. Он намного надежнее, понятнее и стабильнее встроенных в материнскую плату контроллеров. Отдавать предпочтение аппаратному рейду следует только в том случае, если он действительно аппаратный, он имеет батарейку и он действительно увеличивает производительность сервера. Во всех остальных случаях рекомендую пользоваться mdadm.

Сообщение Установка CentOS 7 появились сначала на Clip-Clap.

Установка rsync на CentOS 6

Устанавливаем xinetd для автоматического запуска rsync:

# yum install -y xinetd

Устанавливаем непосредственно rsync:

# yum install -y rsync

Редактируем конфиг rsync для xinetd:

# mcedit /etc/xinetd.d/rsync

В конфиге находим строку disable = yesи меняем на no:

disable = no

Запускаем xinetd:

# /etc/init.d/xinetd start

И добавляем его в автозапуск:

# chkconfig xinetd on

Проверяем, слушает ли xinetd 873 порт rsync:

# netstat -lnpt | grep 873

tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 1431/xinetd

Все в порядке, можно приступать к настройке rsync.

Установка rsync на CentOS 7

Ставим rsync:

# yum install -y rsync

Добавляем в автозагрузку:

# systemctl enable rsyncd

ln -s '/usr/lib/systemd/system/rsyncd.service' '/etc/systemd/system/multi-user.target.wants/rsyncd.service'

Проверяем автозагрузку:

# systemctl list-unit-files --type service | grep rsyncd

rsyncd.service enabled

Запускаем rsync:

# systemctl start rsyncd

Проверяем, как запустился:

# netstat -tulpn | grep rsync

tcp        0      0 0.0.0.0:873             0.0.0.0:*               LISTEN      2782/rsync

Все в порядке, можно приступать к настройке rsync.

Установка rsync на Debian/Ubuntu

Устанавливаем rsync:

# apt-get install -y rsync

Правим конфиг:

# mcedit /etc/default/rsync

Находим строку RSYNC_ENABLE=falseи меняем на true:

RSYNC_ENABLE=true

Запускаем rsync:

# /etc/init.d/rsync start

[ ok ] Starting rsync daemon: rsync.

Проверяем, что работает:

# netstat -tulpn | grep rsync

tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 1767/rsync

Все в порядке, можно приступать к настройке rsync.

Настройка rsync

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

Получается у нас такая картинка:

Приступаем к реализации. В первую очередь настраиваем rsync на серверах источниках информации, с которых мы будем забирать данные для backup.

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

# mcedit /etc/rsyncd.conf

pid file = /var/run/rsyncd.pid
log file = /var/log/rsyncd.log
transfer logging = true
munge symlinks = yes

# папка источник для бэкапа
[data]
path = /data
uid = root
read only = yes
list = yes
comment = Data backup Dir
auth users = backup
secrets file = /etc/rsyncd.scrt

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

# mcedit /etc/rsyncd.scrt

backup:12345

где backup — имя пользователя, 12345 — пароль.
Делаем права на чтение только root, иначе rsync не запустится:

# chmod 0600 /etc/rsyncd.scrt

После настройки перезапускаем rsync.
На Centos 6:

# /etc/init.d/xinetd restart

На Centos 7:

systemctl restart rsyncd

На Debian/Ubuntu:

# /etc/init.d/rsync restart

Теперь идем на сервер приемник, в котором будут храниться архивные копии с серверов источников. Там создаем скрипт инкрементного бэкапа c использованием rsync:

# mcedit /root/bin/backup-server1.sh

#!/bin/bash
date
# Папка, куда будем складывать архивы
syst_dir=/backup/
# Имя сервера, который архивируем
srv_name=server1
# Адрес сервера, который архивируем
srv_ip=10.10.1.55
# Пользователь rsync на сервере, который архивируем
srv_user=backup
# Ресурс на сервере для бэкапа
srv_dir=data
echo "Start backup ${srv_name}"
# Создаем папку для инкрементных бэкапов
mkdir -p ${syst_dir}${srv_name}/increment/
# Запускаем непосредственно бэкап с параметрами
/usr/bin/rsync -a --delete --password-file=/etc/rsyncd.scrt ${srv_user}@${srv_ip}::${srv_dir} ${syst_dir}${srv_name}/current/ --backup --backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/
# Чистим папки с инкрементными архивами старше 30-ти дней
/usr/bin/find ${syst_dir}${srv_name}/increment/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;
date
echo "Finish backup ${srv_name}"

Делаем скрипт исполняемым:

# chmod 0744 /root/bin/backup-server1.sh

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

# mcedit /etc/rsyncd.scrt

12345

Делаем права на чтение только root, иначе rsync выдаст ошибку:
ERROR: password file must not be other-accessible
Исправляем это:

# chmod 0600 /etc/rsyncd.scrt

На этом все, теперь можно запускать скрипт и ожидать его выполнения. Осталось добавить его в cron:

# mcedit /etc/crontab

30 23 * * * root /root/bin/backup-server1.sh

Я обычно создаю несколько скриптов для каждого сервера отдельно. Потом объединяю их запуск в одном общем скрипте и уже его добавляю в cron. А потом по мере необходимости редактирую уже его, добавляю или удаляю сервера.

Ротация логов rsync

Мы указали в настройках ведение лога в файл /var/log/rsyncd.log. Необходимо настроить ротацию этого лога, чтобы он не рос до бесконечности. На больших файловых серверах он очень быстро вырастет до сотен мегабайт и более.

Для этого создаем в папке /etc/logrotate.d файл с конфигурацией ротации:

# mcedit /etc/logrotate.d/rsyncd

/var/log/rsyncd.log {
size=500k
compress
rotate 4
missingok
notifempty
}

С такими настройками ротация будет происходить каждый раз, когда файл лога превысит размер в 500 кб. Храниться будут 4 версии лог файла. Эти настройки вы можете сами поменять по своему усмотрению.

Пример бэкапа windows сервера с помощью rsync

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

Создаем на windows сервере сетевую шару с информацией. Создаем пользователя и добавляем его в доступ к этой папке. Этого пользователя мы будем использовать для подключения виндовой шары к linux серверу.

Монтируем шару с информацией, которую будем бэкапить:

# mount -t cifs //192.168.0.16/docs /mnt/docs -o user=backup,password=12345,iocharset=utf8,codepage=cp866

192.168.0.16 — адрес виндовой шары
backup и 12345 — пользователь и пароль виндовой машины с доступом к шаре docs.

Все, теперь папку /mnt/docs можно использовать в качестве приемника в нашем скрипте бэкапа с rsync. Если папка примонтирована непосредственно к серверу с бэкапами, то нужно на нем самом настроить конфиг rsyncd на примере серверов источников, запустить на нем rsyncd и в скрипте в качестве ip адреса сервера указывать 127.0.0.1.

Я в таких случаях создаю несколько скриптов: на монтирование шары, бэкап и размонтирование, объединяю их в один и запускаю последовательно. В итоге получается, что подключаем диск, делаем бэкап и отключаем его.

Сообщение Rsync настройка бэкапа на CentOS/Debian/Ubuntu появились сначала на Clip-Clap.

Я буду настраивать почтовый сервер на ОС linux, а точнее на CentOS 7. За основу будет взят postfix, который присутствует в этой системе из коробки. Инструкция получится универсальной, можно использовать и для других дистрибутивов. Все основные конфиги легко переносятся на разные системы, требуя минимальной правки, в основном путей.

Я напишу статью на самом что ни на есть реальном примере, без какой-либо правки доменов, ip и прочего, чтобы не ошибиться и показать максимально возможный реальный пример. У меня есть технический домен zeroxzed.ru. Я буду использовать его в своей работе. Почтовый сервер будет иметь имя mail.zeroxzed.ru. Всю теорию по подготовке dns к установке и настройке почтового сервера я рассказывал в предыдущей статье о почтовом сервере. Не хочу здесь повторяться. Уточню только список действий, которые вам нужно проделать c ДНС:

1. Создаем A запись в DNS — mail.zeroxzed.ru.
2. Добавляем или редактируем MX запись, указывая в качестве почтового сервера mail.zeroxzed.ru.
3. Просим провайдера прописать PTR для внешнего ip адреса, который будет использовать почтовый сервер. В качестве ptr записи просим установить имя нашего сервера — mail.zeroxzed.ru.

Я предпочитаю в качестве dns хостинга использовать сервера яндекса, даже если не прикрепляю его почту к домену. На картинке показан минимально необходимый набор записей, кроме PTR. Этими записями управляете не вы, а провайдер, который вам выдает ip. Пока с днс все. Позже мы вернемся к этому вопросу, когда будем добавлять dkim и spf записи. Но обо всем по порядку.

Подготовим систему centos к установке и настройке почтового сервера postfix. Если у вас еще нет готовой системы, то рекомендую воспользоваться моими статьями по установке и настройке centos. Отдельно потратьте время на настройку iptables. Я не буду касаться этого вопроса в данной статье, чтобы не раздувать ее второстепенными вещами. Удобнее, когда все по отдельности рассказано и описано с должной глубиной. Сваливать все в одну кучу не хочется.

По вступлению вроде все, основное рассказал. Приступим к настройке нашего почтового сервера.Сразу хочу сделать предупреждение. Настройка почтового сервера достаточно трудоемкий процесс, требует определенных навыков, знаний и понимания принципов работы используемых средств. Я не ставлю для себя цель расписать максимально подробно так, чтобы было понятно даже неподготовленному администратору linux. Вы должны быть так или иначе подготовлены, либо запаситесь терпением и разбирайтесь внимательно сами в нюансах. Эта статья на полный копипаст не подходит, что-то остается за кадром для самостоятельного выполнения. Иначе нельзя, получится очень большой и громоздкий материал.

Установка postfixadmin

Начнем с установки и настройки панели управления почтовым сервером postfix — postfixadmin. Без него начинать что-то делать неудобно, так как управлять пользователями, ящиками, алиасами будет нечем. По своей сути postfixadmin — набор php скриптов для управления записями в mysql базе данных, которую использует сервер postfix во время своей работы. Соответственно, для работы postfixadmin нам нужен web сервер. Подробно о настройке web сервера на centos читайте отдельно. Сейчас же мы быстро установим все необходимое. Привожу только команды, без комментариев. Все подробности по приведенной выше ссылке.

# yum install httpd php phpmyadmin mariadb mariadb-server php-imap

Этих пакетов со всеми зависимостями будет достаточно для установки всех необходимых компонентов веб сервера. Я специально ставлю phpmyadmin, с ним удобно работать с базой. В нашем случае все пользователи будут храниться в mysql, иногда может понадобиться туда заглянуть. Подробнее с установкой и настройкой phpmyadmin можете ознакомиться отдельно.

Запускаем httpd и mariadb и добавляем их в автозагрузку.

# systemctl start httpd
# systemctl enable httpd
# systemctl start mariadb
# systemctl enable mariadb

Задаем пароль root для mysql.

# /usr/bin/mysql_secure_installation

Проверяем работу web сервера. Заходим по ip адресу сервера — http://188.35.19.125/, а также проверяем работу phpmyadmin — http://188.35.19.125/phpmyadmin/. Его нужно настроить, об этом рассказано в статье, которую я привел чуть выше. По-умолчанию в phpmyadmin доступ закрыт. Если все сделали правильно, то увидите примерно следующее.

Сразу создадим тут пользователя postfix и одноименную базу данных. Запомните учетные данные, они нам далее понадобятся.

Веб сервер готов, продолжаем настройку почтового сервера. Скачиваем последнюю версию postfixadmin.

# cd /usr/src
# wget https://downloads.sourceforge.net/project/postfixadmin/postfixadmin/postfixadmin-3.0.2/postfixadmin-3.0.2.tar.gz

Скорее всего во время вашей установки версия postfixadmin изменится и ссылка может быть неактуальной. Но даже если она будет актуальна, возможно выйдет более новая версия. Проверьте ее по ссылке https://sourceforge.net/projects/postfixadmin/ и скачайте самую свежую версию.

Распаковываем архив и копируем в директорию веб сервера.

# tar -xvzf postfixadmin-*
# mv /usr/src/postfixadmin-3.0.2 /var/www/html/postfixadmin

Назначаем владельцем пользователя веб сервера:

# chown -R apache. /var/www/html/postfixadmin/

Дальше редактируем конфигурационный файл postfixadmin.

# mcedit /var/www/html/postfixadmin/config.inc.php

Приводим параметры к следующему виду:

$CONF['configured'] = true;
$CONF['default_language'] = 'ru';
$CONF['database_type'] = 'mysqli';
$CONF['database_host'] = 'localhost';
$CONF['database_user'] = 'postfix';
$CONF['database_password'] = '12345678';
$CONF['database_name'] = 'postfix';
$CONF['admin_email'] = 'root@zeroxzed.ru';
$CONF['encrypt'] = 'md5crypt';
$CONF['default_aliases'] = array (
 'abuse' => 'root',
 'hostmaster' => 'root',
 'postmaster' => 'root',
 'webmaster' => 'root'
);
$CONF['domain_path'] = 'YES';
$CONF['domain_in_mailbox'] = 'YES';

Обращаю внимание на выделенный параметр. Он указывает на то, в каком виде хранить пароли пользователей в базе данных. Конечно, хранить обычным текстом без шифрования это дурной тон и может быть опасно. Я указал хранение в шифрованном виде. Но если мы говорим о небольшой компании без публичного доступа к серверу, можно использовать нешифрованные пароли. Для этого указываем значение параметра cleartext. Я сам так часто делаю просто из соображений удобства. Объясню, в чем удобство.

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

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

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

Последние 2 параметра domain_path и domain_in_mailbox указывайте по своему усмотрению. В файле конфигурации в комментариях расписано, за что они отвечают и в чем отличие. Мне кажется, удобно хранить директории именно в таком виде, как я указал. Получится следующий путь до ящика, если у вас архив почты будет жить, к примеру, в директории /mnt/mail — /mnt/mail/zeroxzed.ru/root@zeroxzed.ru.

С параметрами разобрались. Сохраняем конфиг. Идем по адресу http://188.35.19.125/postfixadmin/setup.php и начинаем установку postfixadmin. Первым делом идет проверка всех необходимых для установки и работы компонентов. Для продолжения установки у вас должна быть такая картинка.

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

Добавляем полученную строку в файл конфигурации postfixadmin.

# mcedit /var/www/html/postfixadmin/config.inc.php

$CONF['setup_password'] = '67e46bdcc7aeb431f7af9a6d02f43352:30672e5a9deacaf505d32807b967caf9fd0c32ef';

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

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

Теперь нам нужно добавить домен в панель управления. Идем в раздел Список доменов -> Новый домен и добавляем свой домен.

При создании домена были добавлены стандартные алиасы, получателя для которых мы указали еще в конфиге — ящик root@zeroxzed.ru. Создание таких алиасов требование стандартов, но по факту, кроме спама, вы скорее всего ничего не будете получать по этим адресам. Так что их создание оставляйте на свое усмотрения. Я обычно их не делаю, так как ящик для этих алиасов все равно не читаю.

Далее создадим почтовый ящик администратора — root@zeroxzed.ru. Для этого идем в раздел Обзор -> Создать ящик и заполняем поля.

Непосредственно ящик на диске создан не будет, так как у нас еще не настроена почтовая система, но запись в базе данных появится. Это можно проверить через phpmyadmin.

Как мы видим, пароль указан в зашифрованном виде. На этом установку и настройку postfixadmin завершаем. Интерфейс для управления почтовым сервером мы подготовили. Теперь можно заняться непосредственно настройкой postfix.

Настройка postfix

Сердце нашего почтового сервера на linux — postfix. В дистрибутиве centos он уже установлен, можно сразу переходить к настройке. Рисуем следующий конфиг.

# mcedit /etc/postfix/main.cf

soft_bounce = no
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix

myhostname = mail.zeroxzed.ru
mydomain = zeroxzed.ru
myorigin = $myhostname

inet_interfaces = all
inet_protocols = ipv4

mydestination = localhost.$mydomain, localhost
unknown_local_recipient_reject_code = 550
mynetworks = 127.0.0.0/8

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

smtpd_banner = $myhostname ESMTP $mail_name

debug_peer_level = 2
# Строки с PATH и ddd должны быть с отступом в виде табуляции от начала строки
debugger_command =
         PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
         ddd $daemon_directory/$process_name $process_id & sleep 5

sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.10.1/samples
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES

relay_domains = mysql:/etc/postfix/mysql/relay_domains.cf
virtual_alias_maps = mysql:/etc/postfix/mysql/virtual_alias_maps.cf,
 mysql:/etc/postfix/mysql/virtual_alias_domain_maps.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql/virtual_mailbox_domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf

smtpd_discard_ehlo_keywords = etrn, silent-discard
smtpd_forbidden_commands = CONNECT GET POST
broken_sasl_auth_clients = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtp_always_send_ehlo = yes
disable_vrfy_command = yes

smtpd_helo_restrictions = permit_mynetworks,
 permit_sasl_authenticated,
 reject_non_fqdn_helo_hostname,
 reject_invalid_helo_hostname

smtpd_data_restrictions = permit_mynetworks,
 permit_sasl_authenticated,
 reject_unauth_pipelining,
 reject_multi_recipient_bounce,

smtpd_sender_restrictions = permit_mynetworks,
 permit_sasl_authenticated,
 reject_non_fqdn_sender,
 reject_unknown_sender_domain

smtpd_recipient_restrictions = reject_non_fqdn_recipient,
 reject_unknown_recipient_domain,
 reject_multi_recipient_bounce,
 permit_mynetworks,
 permit_sasl_authenticated,
 reject_unauth_destination,

smtp_tls_security_level = may
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtp_tls_session_cache_database = btree:$data_directory/smtp_tls_session_cache
smtpd_tls_key_file = /etc/postfix/certs/key.pem
smtpd_tls_cert_file = /etc/postfix/certs/cert.pem
tls_random_source = dev:/dev/urandom

# Ограничение максимального размера письма в байтах
message_size_limit = 20000000
smtpd_soft_error_limit = 10
smtpd_hard_error_limit = 15
smtpd_error_sleep_time = 20
anvil_rate_time_unit = 60s
smtpd_client_connection_count_limit = 20
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 30
smtpd_client_event_limit_exceptions = 127.0.0.0/8
smtpd_client_connection_limit_exceptions = 127.0.0.0/8

maximal_queue_lifetime = 1d
bounce_queue_lifetime = 1d

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/dovecot-auth

# Директория для хранения почты
virtual_mailbox_base = /mnt/mail
virtual_minimum_uid = 1000
virtual_uid_maps = static:1000
virtual_gid_maps = static:1000
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

sender_bcc_maps = hash:/etc/postfix/sender_bcc_maps
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc_maps

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

# mkdir /etc/postfix/mysql && cd /etc/postfix/mysql

# mcedit relay_domains.cf

hosts = localhost
user = postfix
password = 12345678
dbname = postfix
query = SELECT domain FROM domain WHERE domain='%s' and backupmx = '1'

# mcedit  virtual_alias_domain_maps.cf

hosts = localhost
user = postfix
password = 12345678
dbname = postfix
query = SELECT goto FROM alias,alias_domain WHERE alias_domain.alias_domain = '%d' and alias.address = CONCAT('%u', '@', alias_domain.target_domain) AND alias.active = 1

# mcedit virtual_alias_maps.cf

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

# mcedit virtual_mailbox_domains.cf

hosts = localhost
user = postfix
password = 12345678
dbname = postfix
query = SELECT domain FROM domain WHERE domain='%s' AND backupmx = '0' AND active = '1'

# mcedit virtual_mailbox_maps.cf

hosts = localhost
user = postfix
password = 12345678
dbname = postfix
query = SELECT maildir FROM mailbox WHERE username='%s' AND active = '1'

Редактируем файл /etc/postfix/master.cf. Нам надо добавить строки, касающиеся настройки Submission для того, чтобы почтовый сервер работал на 587 порту. Смартфоны очень часто при настройке используют этот порт по-умолчанию, где-то даже без возможности изменить эту настройку. Приводим секцию, отвечающую за эту работу к следующему виду.

submission inet n - n - - smtpd
 -o syslog_name=postfix/submission
 -o smtpd_tls_wrappermode=no
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
 -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination
 -o milter_macro_daemon_name=ORIGINATING

Обращаю внимание на пробел в начале строки, начиная со второй. Его надо обязательно оставить. Добавляем еще настройки для того, чтобы наш сервер поддерживал протокол SSL/TLS и слушал порт 465

smtps inet n - n - - smtpd
 -o syslog_name=postfix/smtps
 -o smtpd_tls_wrappermode=yes
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
 -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination
 -o milter_macro_daemon_name=ORIGINATING

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

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

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

Создаем директорию и сами сертификаты:

# mkdir /etc/postfix/certs
# openssl req -new -x509 -days 3650 -nodes -out /etc/postfix/certs/cert.pem -keyout /etc/postfix/certs/key.pem

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

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

# mcedit /etc/postfix/recipient_bcc_maps

@zeroxzed.ru all_in@zeroxzed.ru

# mcedit /etc/postfix/sender_bcc_maps

@zeroxzed.ru all_out@zeroxzed.ru

Создаем индексированные базы данных из этих файлов. Это нужно делать каждый раз, после изменения.

# postmap /etc/postfix/recipient_bcc_maps /etc/postfix/sender_bcc_maps

Теперь создайте два почтовых ящика all_in@zeroxzed.ru и all_out@zeroxzed.ru через postfixadmin.

Немного поясню по этим ящикам — для чего они нужны. Изначально я их делал, когда пользователи использовали протокол pop3 без сохранения писем на сервере. Это позволяло организовать бэкап всей переписки. Эти ящики очень быстро заполняются и занимают огромный объем, поэтому их обязательно надо чистить. Я просто скриптами регулярно собирал всю почту в архивы с именами в виде дат. Если нужно было какое-то письмо найти, то просто распаковывал нужный архив.

В случае с imap роль бэкапа отпадает, так как вся почта хранится на сервере. Но эти ящики все равно бывают полезны, когда пользователь, к примеру, удалил какое-то важное письмо и потом делает вид, что его и не было. Если это письмо пришло только сегодня и еще не успело улететь в бэкап, то кроме записи в логах об этом письме, вы не увидите само содержимое. А с такими ящиками все сразу будет понятно, и вопросы отпадут. Последнее применение — служба безопасности. Если у вас есть кто-то, кому положено читать всю переписку, то реализовать этот функционал можно таким простым способом.

Все основные настройки для postfix мы сделали. Некоторые из них завязаны на работу с dovecot, который мы еще не настроили. Поэтому больше postfix не трогаем, не перезапускаем. Идем настраивать dovecot — imap сервер нашей почтовой системы.

Настройка dovecot

Займемся настройкой dovecot — сервер доставки почты пользователю по протоколам pop3 и imap. Я не вижу причин использовать pop3. Он неудобен по сравнению с imap. Чаще всего pop3 отключаю вовсе. Но это уже на ваше усмотрение. Приведу пример с настройкой обоих протоколов. Помимо основного функционала по доставке почты, я настрою несколько полезных плагинов. Расскажу о них поподробнее:

• Sieve — выполняет фильтрацию почты по заданным правилам в момент локальной доставки на почтовом сервере. Удобство такого подхода в том, что вы один раз можете настроить правило сортировки, и оно будет работать во всех клиентах, которыми вы будете получать почту по imap. Правила создаются, хранятся и исполняются на самом сервере.
• Acl — позволяет пользователям расшаривать папки в своем почтовом ящике и предоставлять доступ к этим папкам другим пользователям. Не часто видел, чтобы этот функционал настраивали и использовали. Думаю, просто по незнанию. По мне так очень удобный и полезный функционал.

Часто вижу, что люди настраивают плагин quota, который позволяет ограничивать максимальный размер почтового ящика. Я лично в своей работе его не использую. Возможно, когда у тебя клиентов сотни и тысячи это имеет значение и надо обязательно настроить ограничение. Когда же ящиков меньше, нет смысла напрягать людей постоянной чисткой. Сейчас диски стоят не так дорого. Мне кажется, проще и дешевле увеличить место на сервере, нежели постоянно беспокоить пользователей необходимостью чистки ящика. Лучше ограничить максимальный размер письма, скажем 20-ю мегабайтами. Тогда сильно забить ящик даже при большом желании быстро не получится. А почта все-таки важный инструмент в работе. Мне кажется, ее лучше хранить как можно дольше.

Есть еще один полезный плагин expire, который позволяет удалять устаревшие письма в определенных папках. Например, удалять все письма старше 30-ти дней в корзине и папке со спамом. Но реально пользоваться им не получается по простой причине. Разные почтовые клиенты создают различные папки для корзины и спама. Thunderbird создает папки с латинскими именами trash и spam, outlook с русскими, которые на почтовом сервере преобразуются в кодировку UTF7, мобильные клиенты тоже используют разные имена папок. В итоге нет единообразия, плагин полноценно не работает.

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

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

# yum install dovecot dovecot-mysql dovecot-pigeonhole

Изначально конфиг dovecot разбит на отдельные сегменты и лежат в директории /etc/dovecot/conf.d. Каждый файл — отдельный функционал. Мне не нравится прыгать по файлам, поэтому я храню все в едином общем файле конфигурации /etc/dovecot/dovecot.conf. С ним мы и будем работать. Приводим его к следующему виду.

# mcedit /etc/dovecot/dovecot.conf

listen = * [::]

mail_plugins = mailbox_alias acl

protocols = imap pop3 sieve lmtp

mail_uid = 1000
mail_gid = 1000

first_valid_uid = 1000
last_valid_uid = 1000

log_path = /var/log/dovecot/main.log
info_log_path = /var/log/dovecot/info.log
debug_log_path = /var/log/dovecot/debug.log

ssl_protocols = !SSLv2 !SSLv3
ssl = required
verbose_ssl = no
ssl_cert = </etc/postfix/certs/cert.pem
ssl_key = </etc/postfix/certs/key.pem

ssl_cipher_list = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl_dh_parameters_length = 2048
ssl_prefer_server_ciphers = yes

disable_plaintext_auth = yes

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

auth_default_realm = zeroxzed.ru

auth_mechanisms = PLAIN LOGIN

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

unix_listener auth-userdb {
 user = vmail
 group = vmail
 mode = 0660
 }
}

service lmtp {
 unix_listener /var/spool/postfix/private/dovecot-lmtp {
 user = postfix
 group = postfix
 mode = 0600
 }

 inet_listener lmtp {
 address = 127.0.0.1
 port = 24
 }
}

userdb {
 args = /etc/dovecot/dovecot-mysql.conf
 driver = sql
 }

passdb {
 args = /etc/dovecot/dovecot-mysql.conf
 driver = sql
 }

auth_master_user_separator = *
 
plugin {
 auth_socket_path = /var/run/dovecot/auth-master

 acl = vfile
 acl_shared_dict = file:/mnt/mail/shared-folders/shared-mailboxes.db
 sieve = /mnt/mail/sieve/%u.sieve
 mailbox_alias_old = Sent
 mailbox_alias_new = Sent Messages
 mailbox_alias_old2 = Sent
 mailbox_alias_new2 = Sent Items
}

protocol lda {
 mail_plugins = $mail_plugins sieve
 auth_socket_path = /var/run/dovecot/auth-master
 deliver_log_format = mail from %f: msgid=%m %$
 log_path = /var/log/dovecot/lda-errors.log
 info_log_path = /var/log/dovecot/lda-deliver.log
 lda_mailbox_autocreate = yes
 lda_mailbox_autosubscribe = yes
 postmaster_address = root
}

protocol lmtp {
 info_log_path = /var/log/dovecot/lmtp.log
 mail_plugins = quota sieve
 postmaster_address = postmaster
 lmtp_save_to_detail_mailbox = yes
 recipient_delimiter = +
}

protocol imap {
 mail_plugins = $mail_plugins imap_acl
 imap_client_workarounds = tb-extra-mailbox-sep
 mail_max_userip_connections = 30
}

protocol pop3 {
 mail_plugins = $mail_plugins
 pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
 pop3_uidl_format = %08Xu%08Xv
 mail_max_userip_connections = 30
}

service imap-login {
 service_count = 1
 process_limit = 500
 }

service pop3-login {
 service_count = 1
 }

service managesieve-login {
 inet_listener sieve {
 port = 4190
 }
}

namespace {
 type = private
 separator = /
 prefix =
 inbox = yes

 mailbox Sent {
 auto = subscribe
 special_use = \Sent
 }
 mailbox "Sent Messages" {
 auto = no
 special_use = \Sent
 }
 mailbox "Sent Items" {
 auto = no
 special_use = \Sent
 }
 mailbox Drafts {
 auto = subscribe
 special_use = \Drafts
 }
 mailbox Trash {
 auto = subscribe
 special_use = \Trash
 }
 mailbox "Deleted Messages" {
 auto = no
 special_use = \Trash
 }
 mailbox Junk {
 auto = subscribe
 special_use = \Junk
 }
 mailbox Spam {
 auto = no
 special_use = \Junk
 }
 mailbox "Junk E-mail" {
 auto = no
 special_use = \Junk
 }
 mailbox Archive {
 auto = no
 special_use = \Archive
 }
 mailbox Archives {
 auto = no
 special_use = \Archive
 }
}

namespace {
 type = shared
 separator = /
 prefix = Shared/%%u/
 location = maildir:%%h:INDEX=%h/shared/%%u
 subscriptions = yes
 list = children
}

Создаем группу и пользователя с указанными в конфиге uid 1000.

# groupadd  -g 1000 vmail
# useradd -d /mnt/mail/ -g 1000 -u 1000 vmail
# chown vmail. /mnt/mail

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

# mcedit /etc/dovecot/dovecot-mysql.conf

driver = mysql
default_pass_scheme = CRYPT
connect = host=127.0.0.1 dbname=postfix user=postfix password=12345678
user_query = SELECT '/mnt/mail/%d/%u' as home, 'maildir:/mnt/mail/%d/%u' as mail, 1000 AS uid, 1000 AS gid, concat('*:bytes=', quota) AS quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
password_query = SELECT username as user, password, '/mnt/mail/%d/%u' as userdb_home, 'maildir:/mnt/mail/%d/%u' as userdb_mail, 1000 as userdb_uid, 1000 as userdb_gid, concat('*:bytes=', quota) AS userdb_quota_rule FROM mailbox WHERE username = '%u' AND active = '1'

Создадим директорию и файлы для логов.

# mkdir /var/log/dovecot
# cd /var/log/dovecot && touch main.log info.log debug.log lda-errors.log lda-deliver.log lmtp.log
# chown -R vmail:dovecot /var/log/dovecot

Создаем пару служебных папок для плагинов sieve и acl.

# mkdir /mnt/mail/sieve && mkdir /mnt/mail/shared-folders
# chown -R vmail. /mnt/mail

И небольшой штрих в завершении настройки.

# chown vmail. /var/run/dovecot/auth-master

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

На этом основная настройка почтового сервера на базе postfix и dovecot завершена. Можно перезапускать службы и проверять работу системы.

# systemctl restart postfix
# systemctl start dovecot
# systemctl enable dovecot

Проверка работы почтового сервера

Самаый простой и быстрый способ проверить работу почтового сервера — отправить на него письмо. Я буду отправлять со своего почтового адреса zeroxzed@gmail.com на адрес root@zeroxzed.ru. Вот что должно быть в логе, если у вас все правильно настроено и почтовый сервер нормально работает.

# cat /var/log/maillog

Mar 10 21:56:27 mail postfix/smtpd[28075]: connect from mail-yw0-f172.google.com[209.85.161.172]
Mar 10 21:56:28 mail postfix/smtpd[28075]: Anonymous TLS connection established from mail-yw0-f172.google.com[209.85.161.172]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Mar 10 21:56:28 mail postfix/smtpd[28075]: D4263420BB7B: client=mail-yw0-f172.google.com[209.85.161.172]
Mar 10 21:56:29 mail postfix/cleanup[28086]: D4263420BB7B: message-id=<CAHWPLcOeqf6uNHRg34+wuppDUGPDLY=fp8s-E=o9fmxYMS48cQ@mail.gmail.com>
Mar 10 21:56:29 mail postfix/qmgr[28042]: D4263420BB7B: from=<zeroxzed@gmail.com>, size=2533, nrcpt=2 (queue active)
Mar 10 21:56:29 mail postfix/pipe[28089]: D4263420BB7B: to=<all_in@zeroxzed.ru>, relay=dovecot, delay=0.39, delays=0.33/0.02/0/0.05, dsn=2.0.0, status=sent (delivered via dovecot service)
Mar 10 21:56:29 mail postfix/pipe[28090]: D4263420BB7B: to=<root@zeroxzed.ru>, relay=dovecot, delay=0.4, delays=0.33/0.03/0/0.04, dsn=2.0.0, status=sent (delivered via dovecot service)
Mar 10 21:56:29 mail postfix/qmgr[28042]: D4263420BB7B: removed
Mar 10 21:56:29 mail postfix/smtpd[28075]: disconnect from mail-yw0-f172.google.com[209.85.161.172]

Пояснять тут нечего, по логу все понятно. Письмо было доставлено в указанный ящик и в общий ящик для сбора всей входящей почты. В директории /mnt/mail была создана директория с именем домена zeroxzed.ru, а в ней созданы 3 папки с именами ящиков:

• all_in@zeroxzed.ru
• all_out@zeroxzed.ru
• root@zeroxzed.ru

Директории с почтовыми ящиками создаются в момент получения первого письма в ящик. Непрочитанное письмо помещается в директорию /new в почтовом ящике. После прочтения переносится в /cur.

Попробуем теперь подключиться к почтовому ящику по imap, прочитать письмо и отправить ответ. Настроим любой почтовый клиент для проверки работы настроенного почтового сервера. Я для этих целей буду использовать Thunderbird. Из всех почтовых клиентов мне он нравится больше всего. В основном из-за его портированной версии. Указываем следующие настройки.

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

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

Я подключился к почтовому ящику и увидел тестовые письма. Отвечу на одно из них и посмотрю в логе, как прошла отправка. У меня еще раз выскочило окно с предупреждением о небезопасном сертификате. Еще раз добавляю его в исключения. Это нормально, сертификат проверяется во время получения почты в dovecot, а во время отправки в postfix. Так что нужны 2 подтверждения. Отправляю письмо еще раз и смотрю лог.

# cat /var/log/maillog

Mar 10 22:10:12 mail postfix/smtpd[28764]: connect from broadband-75-37-235-139.moscow.gw.ru[75.37.235.139]
Mar 10 22:10:12 mail postfix/smtpd[28764]: Anonymous TLS connection established from broadband-75-37-235-139.moscow.gw.ru[75.37.235.139]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Mar 10 22:10:12 mail postfix/smtpd[28764]: B24C2420BB70: client=broadband-75-37-235-139.moscow.gw.ru[75.37.235.139], sasl_method=PLAIN, sasl_username=root@zeroxzed.ru
Mar 10 22:10:12 mail postfix/cleanup[28779]: B24C2420BB70: message-id=<aaac96c3-197e-c6bd-4dfe-85d09bce216a@zeroxzed.ru>
Mar 10 22:10:12 mail postfix/qmgr[28042]: B24C2420BB70: from=<root@zeroxzed.ru>, size=955, nrcpt=2 (queue active)
Mar 10 22:10:12 mail postfix/smtpd[28764]: disconnect from broadband-75-37-235-139.moscow.gw.ru[75.37.235.139]
Mar 10 22:10:12 mail postfix/pipe[28784]: B24C2420BB70: to=<all_out@zeroxzed.ru>, relay=dovecot, delay=0.14, delays=0.07/0.01/0/0.06, dsn=2.0.0, status=sent (delivered via dovecot service)
Mar 10 22:10:13 mail postfix/smtp[28783]: B24C2420BB70: to=<zeroxzed@gmail.com>, relay=gmail-smtp-in.l.google.com[64.233.163.26]:25, delay=0.62, delays=0.07/0.01/0.28/0.26, dsn=2.0.0, status=sent (250 2.0.0 OK 1489173013 13si2106703ljv.3 - gsmtp)
Mar 10 22:10:13 mail postfix/qmgr[28042]: B24C2420BB70: removed

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

Расскажу, куда еще надо смотреть для отладки почтовой системы. Да и не только отладки, во время работы периодически придется разбираться, куда ушло то или иное письмо, кто и когда подключался к ящику. Разные ситуации бывают. В файле /var/log/dovecot/lda-deliver.log содержится информация обо всех пришедших письмах — когда, от кого и в какой ящик было положено.

Mar 10 22:25:29 lda(all_in@zeroxzed.ru): Info: mail from zeroxzed@gmail.com: msgid=<CAHWPLcNG=WMOoWW2Y_Lw4qn9+V4TOrbxZpwtA=O+CSEBaiwuBg@mail.gmail.com> saved mail to INBOX
Mar 10 22:25:29 lda(root@zeroxzed.ru): Info: mail from zeroxzed@gmail.com: msgid=<CAHWPLcNG=WMOoWW2Y_Lw4qn9+V4TOrbxZpwtA=O+CSEBaiwuBg@mail.gmail.com> saved mail to INBOX
Mar 10 22:25:49 lda(all_out@zeroxzed.ru): Info: mail from root@zeroxzed.ru: msgid=<75358e4d-7c8e-24c2-a21f-7ee0df2a4704@zeroxzed.ru> saved mail to INBOX

В /var/log/dovecot/info.log информация о подключениях к почтовым ящикам — кто, когда, откуда и каким способом авторизовывался на сервере.

Mar 10 22:10:20 imap-login: Info: Login: user=<root@zeroxzed.ru>, method=PLAIN, rip=75.37.235.139, lip=188.35.19.125, mpid=28790, TLS, session=<3tDeHGVKpQBNJeCL>
Mar 10 22:19:39 imap-login: Info: Login: user=<root@zeroxzed.ru>, method=PLAIN, rip=75.37.235.139, lip=188.35.19.125, mpid=29248, TLS, session=<7VY8PmVKbwBNJeCL>

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

На текущий момент сервер полностью работоспособен. В таком виде им без проблем можно пользоваться. Но функционал полностью не раскрыт. Использовать плагины sieve и acl через удаленные почтовые клиенты неудобно. Проще всего их настроить через web почту roundcube. Установим эту web панель на наш почтовый сервер.

Установка web интерфейса roundcube

Установим и настроим самый популярный web интерфейс для postfix — roundcube. Скачиваем исходники.

# cd /usr/src
# wget https://github.com/roundcube/roundcubemail/releases/download/1.2.9/roundcubemail-1.2.3-complete.tar.gz

Не забудьте проверить в момент установки, какая версия является самой свежей на текущий момент. Нет необходимости устанавливать устаревшую версию. Рекомендую ставить самую последнюю на момент настройки.

# yum install php-pear php-mcrypt php-intl php-ldap php-pear-Net-SMTP php-pear-Net-IDNA2 php-pear-Mail-Mime php-pear-Net-Sieve
# tar -xzvf roundcubemail-*
# mv roundcubemail-1.2.9 /var/www/html/webmail
# chown -R apache. /var/www/html/webmail

Переходим в браузер по следующей ссылке для установки roundcube — http://188.35.19.125/webmail/installer/. Вы увидите несколько незначительных замечаний. На них можно не обращать внимание, если установщик позволяет нажать кнопку NEXT. Единственное, рекомендую установить правильный часовой пояс в /etc/php.ini и перезапустить после этого httpd.

На следующем этапе нам надо указать настройки подключения к mysql базе. Предварительно ее следует создать через phpmyadmin. Я создал пользователя roundcube и такую же базу с полными правами пользователя на нее. Эти параметры указал в настройках.

Так же на этой странице нужно будет указать несколько параметров:

• smtp_server — пусто (ничего не пишем)
• language — ru_RU
• Выбираем плагины — managesieve, userinfo, acl. Остальные на свое усмотрение.

Жмем CREATE CONFIG. Должны увидеть сообщение:

The config file was saved successfully into RCMAIL_CONFIG_DIR directory of your Roundcube installation.

Жмем CONTINUE. Открывается страница с проверкой настроек. Тут проверять неудобно, можно этого не делать. Зайдем в почтовый ящик и там все проверим. Если что, конфиг потом все равно можно вручную отредактировать. Папку /var/www/html/webmail/installer удаляем. Заходим в почтовый ящик через roundcube — http://188.35.19.125/webmail/ Набирать нужно полное имя ящика и пароль. Если все сделали правильно, должны попасть в свой почтовый ящик.

Ну вот и все. Можно пользоваться web интерфейсом для почтового сервера. Рекомендую ее настроить, если есть необходимость. Тема качественная и добротная. Пользоваться удобно.

Дальше рассмотрим настройку и использование плагинов acl и sieve с помощью roundcube.

Настройка фильтра почты sieve

Sieve очень удобная штука, но вот хорошего интерфейса для управления через почтовый клиент я не знаю. Существует плагин для thunderbird, который так и называется sieve. Но лично мне он не понравился вообще, так как предлагает писать правила определенным кодом. Для этого надо знать синтаксис, тратить время. Можете сами на него посмотреть — https://github.com/thsmi/sieve.

К счастью, есть удобный способ писать правила фильтрации для sieve через roundcube. Там это реализовано отдельным плагином managesieve, который мы активировали во время установки. Для создания правила фильтрации, зайдите в свой почтовый ящик через roundcube. Переходите в раздел Настройки -> Фильтры и создавайте новое правило.

После этого письма будут обрабатываться правилом сразу после поступления в почтовый сервер, в независимости от вашего подключения к ящику. В папке /mnt/mail/sieve появилась запись с настроенным правилом. Можете познакомиться с синтаксисом написания правил. Он не сложный.

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

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

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

# mcedit /var/www/html/webmail/plugins/managesieve/config.inc.php

Изменяем там параметр:

$config['managesieve_vacation'] = 1;

После этого достаточно просто обновить веб интерфейс roundcube, и появятся новые настройки по адресу Настройки -> Отпуск

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

Общие папки по imap

Рассмотрим настройку необычного и полезного функционала в виде общих папок. С их помощью один пользователь почтового ящика может предоставить другому пользователю доступ к папке внутри своего почтового ящика. Где и как использовать этот функционал, каждый может придумать сам, в зависимости от своих потребностей. Мне кажется это удобным в том случае, когда создан какой-то общий ящик, на который только поступает информация и нет необходимости писать ответ от его имени. То есть по сути работает как обычный почтовый алиас. Но в случае с алиасом и несколькими почтовыми ящиками, письмо падает в каждый ящик. Если таких писем и получателей много, то идет большое дублирование одного и того же письма в рамках почтового сервера. Если сделать ящик и расшарить на нем папку, подключить ее всем пользователям, то дублирования почты не будет. Каждый сможет прочитать письмо, без необходимости его доставки в каждый конкретный ящик.

Настроим общую папку imap. Хотя настраивать нам, по сути, нечего. Мы уже все настроили ранее. Добавили соответствующие настройки в dovecot и активировали плагин acl в roundcube. Теперь нужно просто сделать папку и открыть ее для другого пользователя. Для этого идем в раздел Настройки -> Папки. Создаем там любую папку. В моем случае это папка с названием Общая.

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

• чтение
• запись
• удаление

Заходим в ящик, которому добавили общий доступ и проверяем.

Все в порядке, общая папка imap настроена и подключена. В папке /mnt/mail/shared-folders появился файл с настроенным выше правилом.

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

Настройка dkim и spf

Напишу своими словами как я понимаю работу dkim. С помощью dkim вся исходящая почта сервера подписывается электронной цифровой подписью, связанной с именем домена. Открытый ключ шифрования с помощью DNS публикуется в txt записи. Таким образом, удаленный сервер, при получении письма от вас, сравнивает цифровую подпись с опубликованным в dns открытым ключом вашего домена. Если все в порядке, то считает, что ваше письмо в самом деле пришло от вас, а не от мошенников. То есть с помощью этой технологии можно однозначно идентифицировать отправителя.

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

Для настройки dkim устанавливаем соответствующий пакет:

# yum install opendkim

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

# mkdir -p /etc/postfix/dkim && cd /etc/postfix/dkim

Генерируем ключи для домена:

# opendkim-genkey -D /etc/postfix/dkim/ -d zeroxzed.ru -s mail

На выходе получаете пару файлов — закрытый (приватный) и открытый ключ. Закрытый останется на сервере, открытый будет опубликован в dns. Переименуем их сразу, чтобы не путаться, если у вас будет несколько доменов. Ключи нужно будет делать для каждого домена.

# mv mail.private mail.zeroxzed.ru.private
# mv mail.txt mail.zeroxzed.ru.txt

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

# mcedit keytable

mail._domainkey.zeroxzed.ru zeroxzed.ru:mail:/etc/postfix/dkim/mail.zeroxzed.ru.private

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

# mcedit signingtable

*@zeroxzed.ru mail._domainkey.zeroxzed.ru

Выставляем права доступа на все файлы:

# chown root:opendkim *
# chmod u=rw,g=r,o= *

Рисуем конфиг службы.

# mcedit /etc/opendkim.conf

AutoRestart Yes
AutoRestartRate 10/1h
PidFile /var/run/opendkim/opendkim.pid
Mode sv
Syslog yes
SyslogSuccess yes
LogWhy yes
UserID opendkim:opendkim
Socket inet:8891@localhost
Umask 022
Canonicalization relaxed/relaxed
Selector default
MinimumKeyBits 1024
KeyFile /etc/postfix/dkim/mail.zeroxzed.ru.private
KeyTable /etc/postfix/dkim/keytable
SigningTable refile:/etc/postfix/dkim/signingtable

Добавляем в конфигурационный файл postfix в самый конец следующие параметры:

# mcedit /etc/postfix/main.cf

smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept
milter_protocol = 2

Перезапускаем postfix и dkim, последний добавляем в автозагрузку.

# systemctl restart postfix
# systemctl restart opendkim.service
# systemctl enable opendkim.service

Теперь нам надо добавить открытый ключ в dns. Идем в консоль управления dns и добавляем новую txt запись. Ее содержание берем из файла /etc/postfix/dkim/mail.zeroxzed.ru.txt

cat /etc/postfix/dkim/mail.zeroxzed.ru.txt

mail._domainkey IN TXT ( "v=DKIM1; k=rsa; "
 "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQClZX2xWRDISlVLF4b4pUiinY5N9WN7VXEHeyPw8smHTamXh35wJoh+j0+MIQDWG/KtdCcETeawTuypXbvtbneXniYR0iiv6kt754T2WXBjz7O/uHL+vK58LhJsm4TGyhUN6ZBit+w22jG92zdeybSZeU/g7hQdkaAAi0I+0nIkUwIDAQAB" ) ; – - – DKIM key mail for zeroxzed.ru

Убираем кавычки, лишние проблемы и вставляем. Должно получиться вот так:

Проверяю работу. Отправляю письмо на gmail и смотрю лог почтового сервера:

# cat /var/log/maillog

Mar 17 17:40:26 mail postfix/smtpd[22352]: connect from localhost[127.0.0.1]
Mar 17 17:40:26 mail postfix/smtpd[22352]: BB1794195584: client=localhost[127.0.0.1]
Mar 17 17:40:26 mail postfix/cleanup[22364]: BB1794195584: message-id=<baf63dcec016594d49f2d80f815e5d26@zeroxzed.ru>
Mar 17 17:40:26 mail opendkim[21744]: BB1794195584: DKIM-Signature field added (s=mail, d=zeroxzed.ru)
Mar 17 17:40:26 mail postfix/qmgr[21990]: BB1794195584: from=<root@zeroxzed.ru>, size=593, nrcpt=2 (queue active)
Mar 17 17:40:26 mail postfix/pipe[22369]: BB1794195584: to=<all_out@zeroxzed.ru>, relay=dovecot, delay=0.14, delays=0.11/0.02/0/0.02, dsn=2.0.0, status=sent (delivered via dovecot service)
Mar 17 17:40:26 mail postfix/smtpd[22352]: disconnect from localhost[127.0.0.1]
Mar 17 17:40:27 mail postfix/smtp[22370]: BB1794195584: to=<zeroxzed@gmail.com>, relay=gmail-smtp-in.l.google.com[64.233.163.26]:25, delay=0.84, delays=0.11/0.02/0.31/0.4, dsn=2.0.0, status=sent (250 2.0.0 OK 1489761627 185si4568435lfa.398 - gsmtp)

Все в порядке, электронная цифровая подпись установлена. Проверим, как гугл отреагировал на нашу подпись:

Тоже все в порядке. Подпись выполнена корректно, проверку прошла. Дополнительно, проверить корректность dkim записи в dns можно онлайн сервисом — http://dkimcore.org/c/keycheck.

Настроим еще одно средство для повышения доверия к нашей почте со стороны других серверов — spf. Расскажу опять своими словами для чего это нужно. Spf запись добавляется в виде txt записи в dns вашего домена. С помощью этой записи вы указываете, какие ip адреса имеют право отправлять почту от вашего имени. Если кто-то из спамеров будет использовать ваше имя домена при рассылке спама, он не пройдет проверку по spf и скорее всего будет идентифицирован как спам.

Можно указать конкретные ip адреса в записи, а можно сказать, чтобы ip адреса проверялись по спискам A и MX записей. У нас простой случай и только 1 сервер с одним ip, поэтому укажем конкретно этот ip адрес. Идем в панель управления dns и добавляем новую txt запись.

zeroxzed.ru. TXT v=spf1 ip4:188.35.19.125 ~all

Больше ничего делать не надо. Снова отправляем письмо на gmail и смотрим логи.

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

Дополнительный функционал почтового сервера postfix

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

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

1. Защиту от подбора паролей с помощью fail2ban.
2. Мониторинг почтового сервера postfix с помощью zabbix.
3. Сбор статистики с помощью pflogsumm или чего-то подобного.
4. Просмотр и анализ логов с помощью webmin.
5. Использование бесплатных сертификатов let’s encrypt.
6. Регулярную очистку служебных почтовых ящиков.
7. Бэкап всей почтовой базы.

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

1. lamav — известный антивирус. Считаю, что сейчас он не актуален, так как вирусов, от которых он способен защитить, я уже давно не видел. Сейчас вирусная эпидемия шифровальщиков. От них он не защищает.
2. Spamassasin — популярный бесплатный антиспам фильтр. Скажу честно, работал с ним очень мало и могу быть не объективен. Насколько я видел его настройку и работу — он требует к себе некоторого внимания, калибровки, особенно на начальном этапе. Мне обычно не хочется этим заниматься.
3. Graylist — эффективное средство борьбы со спамом. Я уже подробно его рассматривал, когда писал про iredmail, так что не буду повторяться. Скажу лишь, что режет спам очень эффективно и бесплатно, но есть существенные неудобства, которые по моему мнению не перекрывают плюсы. Поэтому я не использую.

В качестве антиспама я предпочитаю коммерческое решение — Kaspersky Anti-Spam. Я знаю этот продукт уже лет 8. Он действительно отлично фильтрует спам. Ложных срабатываний вообще не припоминаю, 95% спама фильтрует, может больше. С ним вопрос спама отпадает вообще. Стоит он недорого, можно купить лицензию на меньшее количество ящиков, чем реально используется в системе. Этот вопрос никак не отслеживается и на качество работы не влияет. Но нужно понимать, что это уже нарушение лицензионного соглашения. Но можно всякие хитрости придумать, чтобы и фильтровать и не нарушать.

Борьба со спамом средствами postfix

Сначала хотел сразу все настройки postfix разместить в соответствующем разделе в едином конфиге, но потом передумал и решил все же вынести этот вопрос на отдельное рассмотрение. Возможно, не каждому захочется сразу в эту тему углубляться. Все, что рассказано выше, позволит настроить полноценный почтовый сервер, который будет успешно принимать почту и доставлять ее пользователям. Но в таком виде он будет принимать слишком много спама, но зато не будет проблем с тем, что от кого-то что-то не придет. Как ни крути, но все средства борьбы со спамом так или иначе несут накладные расходы в виде ложных срабатываний с той или иной вероятностью. Если вы решите не заморачиваться и купить Kaspersky Anti-Spam, можете этот раздел не читать. Он сам реализует все те проверки, что мы будем делать. Если же хотите своими силами бороться со спамом средствами postfix, то давайте дальше разбираться.

Я буду использовать штатные возможности postfix, позволяющие отсеять спам по тем или иным параметрам еще до получения письма. Это очень эффективный способ с точки зрения производительности. Благодаря этому, правильно настроенный на отсев спама postfix часто ставят перед exchange, чтобы снизить на него нагрузку. Сразу дам ссылки на официальную документацию с описанием параметров, которые я буду использовать:

1. smtpd_helo_restrictions
2. smtpd_sender_restrictions
3. smtpd_recipient_restrictions
4. smtpd_data_restrictions
5. smtpd_client_restrictions

Есть еще парочка — smtpd_etrn_restrictions и smtpd_end_of_data_restrictions, но я ими не пользуюсь.Обращаю внимание на то, что нужно очень аккуратно работать с настройками, о которых пойдет речь. Нужно четко понимать как, зачем и что вы делаете. Неверные настройки могут нарушить нормальное хождение почты. Нужно уметь анализировать лог файл почтового сервера и понимать, что там происходит.

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

#Описание списков исключений
smtpd_restriction_classes = white_client_ip,
                            black_client_ip,
                            block_dsl,
                            white_client,
                            white_helo,
                            black_client,
                            mx_access

# IP адреса, которые нужно пропускать всегда
white_client_ip		= check_client_access hash:/etc/postfix/lists/white_client_ip

# IP адреса, которые нужно блокировать всегда
black_client_ip		= check_client_access hash:/etc/postfix/lists/black_client_ip

# E-mail, которые нужно пропускать всегда
white_client		= check_sender_access hash:/etc/postfix/lists/white_client

# E-mail, которые нужно блокировать всегда
black_client		= check_sender_access hash:/etc/postfix/lists/black_client

# Неправильные значения HELO, которые мы тем не менее принимаем
white_helo = check_sender_access hash:/etc/postfix/lists/white_helo
# Правила для блокировки различных динамических ip.
block_dsl 		= check_client_access regexp:/etc/postfix/lists/block_dsl

# Список приватных сетей, которые не могут быть использованы в качестве IP для MX записей
mx_access		= check_sender_mx_access cidr:/etc/postfix/lists/mx_access

# Проверки на основе данных, переданных в HELO/EHLO hostname
smtpd_helo_restrictions =	permit_mynetworks,
		permit_sasl_authenticated,
		white_client_ip,
                white_helo,
		black_client_ip,
		block_dsl,
		# Отказываем серверам, у которых в HELO несуществующий или не FQDN адрес 
		reject_invalid_helo_hostname,
		reject_non_fqdn_helo_hostname,
		# Запрещаем приём писем от серверов, представляющихся адресом, для которого не существует A или MX записи.
		reject_unknown_helo_hostname

# Проверки клиентского компьютера или другого почтового сервера, который соединяется с сервером postfix для отправки письма
smtpd_client_restrictions = 	permit_mynetworks,
		permit_sasl_authenticated,
		# Отвергает запрос, когда клиент отправляет команды SMTP раньше времени, еще не зная, поддерживает ли Postfix конвейерную обработку команд ESMTP
		reject_unauth_pipelining,
		# Блокируем клиентов с адресами from, домены которых не имеют A/MX записей
		reject_unknown_address,
		reject_unknown_client_hostname

# Проверки исходящей или пересылаемой через нас почты на основе данных MAIL FROM
smtpd_sender_restrictions =	permit_mynetworks,
		permit_sasl_authenticated,
		white_client,
		black_client,
		# Запрет отправки писем, когда адрес MAIL FROM не совпадает с логином пользователя
		reject_authenticated_sender_login_mismatch,
		# Отклоняем письма от несуществующих доменов
		reject_unknown_sender_domain,
		# Отклоняем письма от доменов в не FQDN формате
		reject_non_fqdn_sender,
		# Отклонение писем с несуществующим адресом отправителя
		reject_unlisted_sender,
		reject_unauth_destination,
		# Отклонять сообщения от отправителей, ящики которых не существуют, использовать аккуратно
		#reject_unverified_sender,
		mx_access

# Правила приема почты нашим сервером на основе данных RCPT TO
smtpd_recipient_restrictions =  permit_mynetworks,
		permit_sasl_authenticated,
		# Отклоняет всю почту, что адресована не для наших доменов
		reject_unauth_destination,
		# Отклонение писем с несуществующим адресом получателя
		reject_unlisted_recipient,
		# Отклоняет сообщения на несуществующие домены
		reject_unknown_recipient_domain,
		# Отклоняет сообщения если получатель не в формате FQDN
		reject_non_fqdn_recipient,
		# Отклоняем прием от отправителя с пустым адресом письма, предназначенным нескольким получателям.
		reject_multi_recipient_bounce

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

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

• reject_invalid_helo_hostname и reject_unknown_helo_hostname — под эти правила иногда попадают почтовые серверы клиентов, которые не очень хорошо настроены. У них бывают неправильные адреса, кривые записи dns, отсутствие обратных зон и т.д. Их не много, но попадаются. Это не страшно, если вы регулярно следите за сервером. Отправитель получит сразу сообщение о том, что его письмо не дошло до вас. Если он как-то сообщит вам о проблеме, вы легко добавите его в белый список и все будет нормально. Если вам не хочется следить за сервером, лучше не указывайте эти ограничения. Но спам они отсекают не плохо. Сюда попадают все завирусованные компьютеры и сервера без нормальных настроек dns (а их чаще всего и нет).
• reject_unverified_sender — специально его закомментировал. Я тестировал этот параметр. В принципе, работает нормально, но есть, как обычно, нюансы. Поясню, что делает этот параметр. Когда вам кто-то шлет письмо, ваш сервер обращается к серверу отправителю и спрашивает его стандатрной командой, есть ли на сервере такой отправитель. Если удаленный сервер отвечает, что есть, то никаких проблем — письмо принимается. Если удаленный сервер не отвечает или говорит, что такого адресата нет — письмо отклоняем. Очевидно, что такие проверки создают дополнительную постоянную нагрузку. Это нужно учитывать. К тому же, у вас почтовый лог постоянно будет забит этими проверками, особенно, если вам приходит много спама. На каждое спамовое письмо будет идти проверка, а сервера отправителя скорее всего либо нет, либо он неправильный, либо не отвечает и т.д. Все это будет постоянно проверяться и фиксироваться. В общем, я не использую.

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

soft_bounce = yes

Когда он включен, все ответы сервера с кодами ошибок 5XX, заменяются на 4ХХ. То есть постоянная ошибка, которая сразу отклоняет письмо, заменяется на временную, которая предлагает повторить отправку позже. Таким образом, вы увидите работу всех ограничений, но письма не будут отклонены навсегда. Сервер отправителя через некоторое время снова придет к вам с новой попыткой доставки почты. Письмо безвозвратно не отклоняется. Вы можете проанализировать работу фильтра и решить, ставить его на постоянную работу или с ним что-то не так.

Создадим теперь файлы с белыми и черными списками.

cd /etc/postfix/lists && touch white_client_ip black_client_ip white_client black_client white_helo block_dsl mx_access

Ниже пример содержания этих файлов. Вы можете менять по своему усмотрению.

# cat white_client_ip
195.28.34.162 OK
141.197.4.160 OK

# cat black_client_ip
205.201.130.163 REJECT You IP are blacklisted!
198.2.129.162 REJECT You IP are blacklisted!

# cat white_client
# Принимать всю почту с домена яндекс
yandex.ru OK
# Разрешить конкретный ящик
spammer@mail.ru OK

# cat black_client
# Блокировать всю почту с домена mail.ru
mail.ru REJECT You domain are blacklisted!
# Блокировать конкретный ящик
spam@rambler.ru REJECT You e-mail are blacklisted!

# cat white_helo
# Могут попадаться вот такие адреса, которые не пройдут наши проверки
ka-s-ex01.itk.local     OK
exchange.elcom.local    OK

# cat block_dsl
/^dsl.*\..*\..*/i                               553 AUTO_DSL spam
/dsl.*\..*\..*/i                                553 AUTO_DSL1 spam
/[ax]dsl.*\..*\..*/i                            553 AUTO_XDSL spam
/client.*\..*\..*/i                             553 AUTO_CLIENT spam
/cable.*\..*\..*/i                              553 AUTO_CABLE spam
/pool.*\..*\..*/i                               553 AUTO_POOL spam
/dial.*\..*\..*/i                               553 AUTO_DIAL spam
/ppp.*\..*\..*/i                                553 AUTO_PPP spam
/dslam.*\..*\..*/i                              553 AUTO_DSLAM spam
/node.*\..*\..*/i                               553 AUTO_NODE spam
/([0-9]*-){3}[0-9]*(\..*){2,}/i                 553 SPAM_ip-add-rr-ess_networks
/([0-9]*\.){4}(.*\.){3,}.*/i                    553 SPAM_ip-add-rr-ess_networks
/.*\.pppool\..*/i                               553 SPAM_POOL
/[0-9]*-[0-9]*-[0-9]*-[0-9]*-tami\.tami\.pl/i   553 SPAM_POOL
/pool-[0-9]*-[0-9]*-[0-9]*-[0-9]*\..*/i         553 SPAM_POOL
/.*-[0-9]*-[0-9]*-[0-9]*-[0-9]*\.gtel.net.mx/i  553 SPAM_POOL
/dhcp.*\..*\..*/i                               553 SPAM_DHCP

# cat mx_access
127.0.0.1      DUNNO 
127.0.0.2      550 Domains not registered properly
0.0.0.0/8      REJECT Domain MX in broadcast network 
10.0.0.0/8     REJECT Domain MX in RFC 1918 private network 
127.0.0.0/8    REJECT Domain MX in loopback network 
169.254.0.0/16 REJECT Domain MX in link local network 
172.16.0.0/12  REJECT Domain MX in RFC 1918 private network 
192.0.2.0/24   REJECT Domain MX in TEST-NET network 
192.168.0.0/16 REJECT Domain MX in RFC 1918 private network 
224.0.0.0/4    REJECT Domain MX in class D multicast network 
240.0.0.0/5    REJECT Domain MX in class E reserved network 
248.0.0.0/5    REJECT Domain MX in reserved network

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

После редактирования файлов обязательно выполняем команду на перестроение базы данных. Я перестрою сразу все файлы:

cd /etc/postfix/lists && postmap white_client_ip black_client_ip white_client black_client white_helo block_dsl mx_access

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

zeroxzed.ru 554 Stop spam from my name

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

Приведу в завершении описания методов борьбы со спамом простой пример. Добавим в black_client почтовый адрес и отправим с него письмо.

# cat black_client
zeroxzed@gmail.com REJECT Your e-mail was banned!

# postmap black_client

Отправляем сообщение и проверяем почтовый лог.

# cat /var/log/maillog

Mar 20 02:21:34 mail postfix/smtpd[10816]: connect from mail-yw0-f177.google.com[209.85.161.177]
Mar 20 02:21:35 mail postfix/smtpd[10816]: Anonymous TLS connection established from mail-yw0-f177.google.com[209.85.161.177]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Mar 20 02:21:35 mail postfix/smtpd[10816]: NOQUEUE: reject: RCPT from mail-yw0-f177.google.com[209.85.161.177]: 554 5.7.1 <zeroxzed@gmail.com>: Sender address rejected: Your e-mail was banned!; from=<zeroxzed@gmail.com> to=<root@zeroxzed.ru> proto=ESMTP helo=
Mar 20 02:21:35 mail postfix/smtpd[10816]: disconnect from mail-yw0-f177.google.com[209.85.161.177]

Вот и результат. На этом по борьбе со спамом все.

Заключение

Проверить настроенный почтовый сервер можно с помощью онлайн сервиса https://www.mail-tester.com. Не факт, что получите максимальный бал, но все недочеты будут указаны. Критичное нужно исправить (например, если обратная зона неправильная), некритичное можно пропустить (если dkim, к примеру, не настраивали).

Кажется все написал, что знал по поводу почтового сервера на linux в небольших и средних организациях. У некоторых может возникнуть вопрос, а зачем свой почтовый сервер? Почему бы не воспользоваться средствами корпоративной почты, которую представляют популярные почтовые сервисы бесплатно? Я планирую написать по этому поводу отдельную заметку. У меня тоже есть определенный опыт на этот счет. И если некоторое время назад я считал, что свои почтовые серверы в небольших организациях уже не актуальны, то сейчас я так не думаю, поэтому и появилась эта статья.

Сообщение Настройка postfix + dovecot + mysql база + postfixadmin + roundcube + dkim на CentOS 7 появились сначала на Clip-Clap.

Введение

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

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

В Centos 7 используется пакетный менеджер yum, а в Centos 8 — dnf. При этом оставили символьную ссылку с yum на dnf, так что можно писать как первое название, так и второе. Для единообразия я везде буду использовать yum, а вас предупреждаю, просто чтобы вы понимали, почему я делаю именно так. Реально в CentOS 8 используется dnf, это другой, более современный пакетный менеджер, которые позволяет работать с разными версиями одного и того же софта. Для этого используются отдельные репозитории, которые появились для centos 8.

Начальная настройка CentOS

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

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

# yum update

Для удобства администрирования, я всегда устанавливаю Midnight Commander, или просто mc:

# yum install mc

И сразу же для него включаю подсветку синтаксиса всех файлов, которые не обозначены явно в файле /usr/share/mc/syntax/Syntax синтаксисом для sh и bash скриптов. Этот универсальный синтаксис нормально подходит для конфигурационных файлов, с которыми чаще всего приходится работать на сервере. Перезаписываем файл unknown.syntax. Именно этот шаблон будет применяться к .conf и .cf файлам, так как к ним явно не привязано никакого синтаксиса.

# cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntax

Дальше нам пригодятся сетевые утилиты. В зависимости от набора начальных пакетов, которые вы выбираете при установке системы, у вас будет тот или иной набор сетевых утилит. Вот список тех, к которым привык лично я — ifconfig, netstat, nslookup и некоторые другие. Если она вам нужны, так же как и мне, то предлагаю их установить отдельно, если они еще не стоят. Если вам они особо не нужны и вы ими не пользуетесь, то можете пропустить их установку. Проверим, что у нас имеется в системе на текущий момент

# ifconfig

Если увидите ответ:

-bash: ifconfig: command not found

Значит утилита не установлена. Вместо ifconfig в CentOS теперь утилита ip. Это относится не только к центос. Такая картина почти во всех популярных современных дистрибутивах Linux. Я с давних времен привык к ifconfig, хотя последнее время практически не пользуюсь. Мне всегда нравилось, что в различных дистрибутивах линукс все примерно одинаковое. С помощью ifconfig можно настроить сеть не только в linux, но и в freebsd. Это удобно. А когда в каждом дистрибутиве свой инструмент это не удобно. Хотя сейчас это уже не очень актуально, так как с Freebsd больше не работаю, а утилита ip есть во всех дистрибутивах linux. Тем не менее, если вам нужен ifconfig, то можете установить пакет net-tools, в который она входит:

# yum install net-tools

Чтобы у нас работали команды nslookup или, к примеру, host необходимо установить пакет bind-utils. Если этого не сделать, то на команду:

# nslookup

Будет вывод:

-bash: nslookup: command not found

Так что устанавливаем bind-utils:

# yum install bind-utils

Отключить SELinux

Отключаем SELinux. Его использование и настройка отдельный разговор. Сейчас я не буду этим заниматься. Так что отключаем:

# mcedit /etc/sysconfig/selinux

меняем значение

SELINUX=disabled

Чтобы изменения вступили в силу, можно перезагрузиться:

# reboot

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

# setenforce 0

Постоянно получаю очень много критики на тему отключения SELinux. Я знаю, как он работает, умею его настраивать. Это реально не очень сложно и освоить не трудно. Это мой осознанный выбор, хотя иногда я его настраиваю. Мой формат работы с системой таков, что SELinux мне чаще всего не нужен, поэтому я не трачу на него время и в базовой настройке centos отключаю. Безопасность системы — комплексная работа, особенно в современном мире web разработки, где правят бал микросервисы и контейнеры. SELinux нишевый инструмент, которые нужен не всегда и не везде. Поэтому в данном статье ему не место. Кому нужно, будет отдельно включать SELinux и настраивать.

Указываем сетевые параметры

Продолжаем базовую настройку centos после установки. Теперь произведем настройку сети, если по какой-то причине не сделали это во время установки, либо если вам надо их изменить. В общем случае, сеть в Centos настраивается с помощью NetworkManager и его консольной утилиты nmtui. Она идет в базовой устновке системы. Там простой и понятный графический интерфейс, так что рассказывать нечего. Я больше привык настраивать сеть через конфигурационные файлы network-scripts. В centos 7-й версии они есть из коробки, в 8-й версии их убрали. Чтобы воспользоваться ими для настройки сети, надо отдельно установить пакет network-scripts.

# yum install network-scripts

Теперь можно выполнить настройку сети. Для этого открываем файл /etc/sysconfig/network-scripts/ifcfg-eth0

# mcedit /etc/sysconfig/network-scripts/ifcfg-eth0

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

TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
NAME="eth0"
DEVICE="eth0"
ONBOOT="yes"

Для настройки статического ip адреса настройки будут следующие.

TYPE="Ethernet"
BOOTPROTO="none"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
NAME="eth0"
DEVICE="eth0"
ONBOOT="yes"
IPADDR=192.168.167.117
DNS1=192.168.167.113
PREFIX=28
GATEWAY=192.168.167.113

В поле IPADDR вводим свой адрес, в PREFIX маску сети, в GATEWAY шлюз, DNS адрес днс сервера. Сохраняем файл и перезапускаем сеть для применения настроек:

# systemctl restart network

Настраиваем firewall

Очень подробно вопрос настройки iptables в CentOS я рассмотрел отдельно. Сейчас мы быстро и просто настроим firewall. В CentOS 7 в качестве базового фаервола выступает iptables. По-умолчанию он запущен. Чтобы посмотреть текущие правила, нужно ввести команду:

# iptables -L -v -n

В Centos 8 вместо iptables используется nftables. Сразу скажу, что я с ним еще не разбирался и не знаю, буду ли. Реально, меня полностью устраивают iptables. Я ни разу не сталкивался с тем, что что-то не получалось или было невозможно настроить с их помощью. У меня написана куча конфигов к ним, настроены роли ansible с шаблонами правил. Я не понимаю, зачем мне все это переводить в nftables и какую выгоду я с этого получу. Поэтому пока я продолжаю использовать iptables.

Начиная с 7-й версии CentOS для настройки firewall разработан новый инструмент под названием firewalld и все управление производится через него. Он же используется и в Centos 8, только управляет при этом nftables, но сами правила для firewalld одинаковые в обоих версиях. Я не понял зачем в принципе придумали firewalld и не могу сказать, удобнее с ним стало или нет. По мне, так удобнее использовать одни и те же наработки по iptables. Мигрируя от сервера к серверу и от дистрибутива к дистрибутиву, я просто редактирую скрипт настроек фаервола либо шаблон ansible с правилами.

На тему отключения firewalld я тоже время от времени получаю критику, типа надо изучать новое и не цепляться за старое. Так вот, firewalld я изучил и пользуюсь относительно регулярно. Он долгое время использовался в Bitrixenv, с которым я работаю давно и плотно. Кстати, в последних версиях этого окружения bitrix отказался от firewalld. Удивился, когда это заметил. В связи с этим, firewalld мне приходится знать и использовать. И мне он нравится меньше, чем нативные правила в iptables и мои скрипты для управления ими.

Свое мнение не навязываю и убеждать никого не хочу. Делюсь в статье про настройку centos тем, что использую сам. А вы выбирайте тот инструмент, что вам больше подходит. Я привык управлять iptables через самописный скрипт, который переношу от сервера к серверу и редактирую под конкретные потребности. Этим скриптом я и поделюсь. Так что для начала остановим и отключим firewalld.Сразу хочу предупредить, что не имея доступа к консоли сервера, настраивать firewall плохая идея. Даже если вы очень хорошо понимаете что делаете и проделывали подобное много раз, все равно есть шанс остаться без доступа к серверу. Так что первым делом перед настройкой iptables проверяем доступ к консоли сервера.

# systemctl stop firewalld
# systemctl disable firewalld
rm '/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service'
rm '/etc/systemd/system/basic.target.wants/firewalld.service'

Установим утилиты для iptables:

# yum install iptables-services

Включим автозапуск iptables:

# systemctl enable iptables

Теперь создадим файл /etc/iptables.sh следующего содержания:

#!/bin/bash
#
# Объявление переменных
export IPT="iptables"

# Интерфейс который смотрит в интернет
export WAN=eth0
export WAN_IP=147.15.218.72

# Очистка всех цепочек iptables
$IPT -F
$IPT -F -t nat
$IPT -F -t mangle
$IPT -X
$IPT -t nat -X
$IPT -t mangle -X

# Установим политики по умолчанию для трафика, не соответствующего ни одному из правил
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

# разрешаем локальный траффик для loopback
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

# Разрешаем исходящие соединения самого сервера
$IPT -A OUTPUT -o $WAN -j ACCEPT

# Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении.
# Пропускать все уже инициированные соединения, а также дочерние от них
$IPT -A INPUT -p all -m state – state ESTABLISHED,RELATED -j ACCEPT
# Пропускать новые, а так же уже инициированные и их дочерние соединения
$IPT -A OUTPUT -p all -m state – state ESTABLISHED,RELATED -j ACCEPT
# Разрешить форвардинг для уже инициированных и их дочерних соединений
$IPT -A FORWARD -p all -m state – state ESTABLISHED,RELATED -j ACCEPT

# Включаем фрагментацию пакетов. Необходимо из за разных значений MTU
$IPT -I FORWARD -p tcp – tcp-flags SYN,RST SYN -j TCPMSS – clamp-mss-to-pmtu

# Отбрасывать все пакеты, которые не могут быть идентифицированы
# и поэтому не могут иметь определенного статуса.
$IPT -A INPUT -m state – state INVALID -j DROP
$IPT -A FORWARD -m state – state INVALID -j DROP

# Приводит к связыванию системных ресурсов, так что реальный
# обмен данными становится не возможным, обрубаем
$IPT -A INPUT -p tcp ! – syn -m state – state NEW -j DROP
$IPT -A OUTPUT -p tcp ! – syn -m state – state NEW -j DROP

# Рзрешаем пинги
$IPT -A INPUT -p icmp – icmp-type echo-reply -j ACCEPT
$IPT -A INPUT -p icmp – icmp-type destination-unreachable -j ACCEPT
$IPT -A INPUT -p icmp – icmp-type time-exceeded -j ACCEPT
$IPT -A INPUT -p icmp – icmp-type echo-request -j ACCEPT

# Открываем порт для ssh
$IPT -A INPUT -i $WAN -p tcp – dport 22 -j ACCEPT
# Открываем порт для http
$IPT -A INPUT -i $WAN -p tcp – dport 80 -j ACCEPT
# Открываем порт для https
$IPT -A INPUT -i $WAN -p tcp – dport 443 -j ACCEPT

# Логирование
# Все что не разрешено, но ломится отправим в цепочку undef

$IPT -N undef_in
$IPT -N undef_out
$IPT -N undef_fw
$IPT -A INPUT -j undef_in
$IPT -A OUTPUT -j undef_out
$IPT -A FORWARD -j undef_fw

# Логируем все из undef

$IPT -A undef_in -j LOG – log-level info – log-prefix " – IN – DROP "
$IPT -A undef_in -j DROP
$IPT -A undef_out -j LOG – log-level info – log-prefix " – OUT – DROP "
$IPT -A undef_out -j DROP
$IPT -A undef_fw -j LOG – log-level info – log-prefix " – FW – DROP "
$IPT -A undef_fw -j DROP

# Записываем правила
/sbin/iptables-save  > /etc/sysconfig/iptables

В принципе, добавить нечего, в файле даны все комментарии. В таком виде, логи всего заблокированного будут писаться в файл /var/log/messages и записей там будет очень много. Так что в обычной работе эти строки нужно закомментировать, и использовать только во время отладки. Более подробное описание правил и примеры настроек firewall смотрите в отдельной статье, ссылку на которую я уже приводил в самом начале раздела.

Делаем файл c правилами исполняемым и запускаем:

# chmod 0740 /etc/iptables.sh
# /etc/iptables.sh

Проверяем, применились ли правила:

# iptables -L -v -n

При каждом запуске файла с правилами iptables, все изменения записываются в файл /etc/sysconfig/iptables и применяются при загрузке системы.

Настройка SSH в CentOS

Продолжаем настраивать centos. Внесем некоторые изменения в работу ssh для небольшого увеличения безопасности. Хотя речь стоит вести больше не о безопасности, а об удобстве и эффективности. По-умолчанию, сервис ssh работает на 22 порту и если все оставить как есть, то мы получим огромное количество попыток авторизоваться. Боты сканят непрерывно интернет и подбирают пароли к ssh. Это не доставляет в реальности каких-то серьезных хлопот и тем не менее, подобные запросы забивают лог secure и трятят некоторые ресурсы сервера как миниум на установку соединения и рукопожатия (handshake).

Чтобы немного закрыть себя от сканов простых ботов, изменим порт, на котором работает ssh. Можно выбрать любой пятизначный номер, это не принципиально. От автоматического сканирования это защитит. Повесим демон ssh на 25333 порт. Для этого редактируем файл /etc/ssh/sshd_config.

# mcedit /etc/ssh/sshd_config

Раскомментируем строку Port 22 и заменим значение 22 на 25333.

Port 25333

Так же я обычно разрешаю подключаться по ssh пользователю root. Мне так удобнее. Проблем с этим у меня никогда не возникало. Если вы считаете, что это не безопасно, не трогайте эту настройку. Чтобы разрешить пользователю root подключаться по ssh, раскомментируйте строку

PermitRootLogin yes.

Сохраняем файл. Теперь обязательно изменяем настройки iptables, добавляем в разрешенные подключения вместо 22 порта 25333. Если этого не сделать, то после перезапуска sshd мы потеряем удаленный доступ к серверу. Итак, открываем /etc/iptables.sh и меняем в строке

$IPT -A INPUT -i $WAN -p tcp – dport 22 -j ACCEPT

22 на 25333 и исполняем файл. Наше текущее соединение не оборвется, так как оно уже установлено, но заново подключиться по ssh к 22 порту уже не получится.

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

# systemctl restart sshd

Кстати, если вы не отключили SELinux, то просто так не сможете сменить порт ssh. Получите ошибку при перезапуске.

SELinux is preventing /usr/sbin/sshd from name_bind access on the tcp_socket port 25333.

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

Проверяем какой порт слушает sshd:

# netstat -tulpn | grep sshd
tcp        0      0 0.0.0.0:25333           0.0.0.0:*               LISTEN      1799/sshd
tcp6       0      0 :::25333                :::*                    LISTEN      1799/sshd

Если вывод такой же как у меня, то все в порядке, теперь к ssh можно подключаться по 25333 порту.

Добавим еще одну небольшую настройку. Иногда, когда возникают проблемы с dns сервером, логин по ssh подвисает на 30-60 секунд. Вы просто ждете после ввода логина, когда появится возможность ввести пароль. Чтобы избежать этого замедления, укажем ssh не использовать dns в своей работе. Для этого в конфиге раскомментируем строку с параметром UseDNS и отключим его. По-умолчанию он включен.

UseDNS no

Для применения изменений нужно перезапустить ssh службу, как мы уже делали ранее. Настройку службы sshd в centos закончили, двигаемся дальше.

Настраиваем время

Узнать, какое время настроено на сервере centos можно с помощью команды date:

# date

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

# timedatectl set-timezone Europe/Moscow

По факту, эта утилита меняет символьную ссылку. Рассказываю, чтобы вы понимали, как реально меняется часовой пояс.

# ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

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

Теперь проверим статус службы по обновлению времени через интернет. Для этого можно использовать указанную выше команду timedatectl без параметров.

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

# yum install chrony

Запускаем chrony и добавляем в автозагрузку:

# systemctl start chronyd
# systemctl enable chronyd

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

# systemctl status chronyd

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

Добавление репозиториев

При настройке centos частенько нужен софт, которого нет в стандартной репе. Для инсталляции дополнительных пакетов необходимо подключить репозитории в CentOS. Наиболее популярный это EPEL. Раньше был rpmforge, но уже как несколько лет закрыт. Про него все позабыли. Подключаем репозиторий EPEL. С ним все просто, он добавляется из стандартной репы:

# yum install epel-release

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

# rpm -Uhv http://rpms.remirepo.net/enterprise/remi-release-7.rpm

Для Centos 8 remi пока не актуален, но думаю, что это временно. В принципе, мне этих двух репозиториев в centos обычно хватает в общем случае. Другие подключаются уже под конкретные нужды для установки различного софта.

Настройка хранения истории в bash_history

Двигаемся дальше по настройке системы centos на сервере. Полезным будет внести некоторые изменения в стандартный механизм сохранения истории команд. Он часто выручает, когда надо вспомнить одну из ранее введенных команд. Стандартные настройки имеют некоторые ограничения, которые неудобны. Вот их список:

1. По-умолчанию, сохраняются только последние 1000 команд. Если их будет больше, то более старые будут удаляться и заменяться новыми.
2. Не указаны даты выполнения команд, только их список в порядке выполнения.
3. Файл со списком команд обновляется после завершения сессии. При параллельных сессиях часть команд может быть утеряна.
4. Сохраняются абсолютно все команды, хотя в хранении некоторых нет никакого смысла.

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

# history

и увидеть пронумерованный список. Быстро найти конкретную команду, можно с помощью фильтрации только нужных строк, например вот так:

# history | grep yum

Так мы увидим все варианты запуска команды yum, которые хранятся в истории. Исправим перечисленные недостатки стандартных настроек хранения истории команд в CentOS. Для этого нужно отредактировать файл .bashrc, который находится в том же каталоге, что и файл с историей. Добавляем в него следующие строки:

export HISTSIZE=10000
export HISTTIMEFORMAT="%h %d %H:%M:%S "
PROMPT_COMMAND='history -a'
export HISTIGNORE="ls:ll:history:w:htop"

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

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

# source ~/.bashrc

По настройке хранения истории команд все. В файле .bashrc можно много чего настроить интересного. Я одно время увлекался и экспериментировал, но потом все забросил, так как не имеет смысла. Работая с серверами заказчиков я чаще всего вижу дефолтный bash, поэтому лучше привыкать и работать именно в нем. А отдельные настройки и украшательства это удел личных компьютеров и серверов. Не рабочих. Так что больше я ничего не настраивать по стандарту в centos сервере в этом плане.

Автоматическое обновление системы

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

Yum-cron

Для автоматической проверки обновлений в Centos 7 нам поможет утилита yum-cron. Ставится она традиционно через yum из стандартного репозитория.

# yum install yum-cron

После установки yum-cron создается автоматическое задание на выполнение утилиты в /etc/cron.daily и /etc/cron.hourly. По-умолчанию, утилита скачивает найденные обновления, но не применяет их. Вместо этого, администратору на локальный почтовый ящик root отправляется уведомление об обновлениях. Дальше вы уже в ручном режиме заходите и решаете, устанавливать обновления или нет в удобное для вас время. Мне такой режим работы видится наиболее удобным, поэтому я не меняю эти настройки.

Настраивать yum-cron можно через, конфигурационные файлы, которые находятся по адресу /etc/yum/yum-cron.conf и yum-cron-hourly.conf. Они неплохо прокомментированы, так что в подробных разъяснениях не нуждаются. Обращаю внимание на раздел [email], где можно указать параметры отправки сообщений. По-умолчанию стоит отправка почты через локальный хост. Можно тут изменить параметры и отправлять сообщения через сторонний почтовый сервер. Но вместо этого лично я предпочитаю глобально для всего сервера настроить пересылку локальной почты root на внешний почтовый ящик через авторизацию на другом smtp сервере.

Dnf-automatic

Как я уже говорил ранее, в Centos 8 используется другой пакетный менеджер — dnf. Настройка обновления пакетов там выполняется через утилиту dnf-automatic. Поставим ее и настроим.

# yum install dnf-automatic

Управлением запуском по расписанию занимается уже не cron, а systemd своим встроенным планировщиком. Посмотреть таймеры автоматического запуска можно командой:

# systemctl list-timers *dnf-*

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

# systemctl enable – now dnf-automatic.timer

Дефолтный таймер настроен на запуск dnf-automatic через час после загрузки сервера и ежедневное повторение. Конфиг таймера живет тут — /etc/systemd/system/multi-user.target.wants/dnf-automatic.timer.

Конфиг для dnf-automatic живет в /etc/dnf/automatic.conf. По-умолчанию он только скачивает обновления, но не применят их. Конфиг хорошо прокомментирован, так что можете его настроить так, как пожелаете. Отдельных пояснений не требуется. Настраивайте обновление пакетов системы на свое усмотрение. Как я уже сказал, автоматически только качаю их. Установку всегда держу под контролем с ручным управлением.

Отключаем флуд сообщений в /var/log/messages

Продолжая настройку centos, исправим одно небольшое неудобство. В дефолтной установке системы 7-й версии, весь ваш системный лог /var/log/messages через некоторое время работы сервера будет забит следующими записями.

Oct 16 14:01:01 xs-files systemd: Created slice user-0.slice.
Oct 16 14:01:01 xs-files systemd: Starting user-0.slice.
Oct 16 14:01:01 xs-files systemd: Started Session 14440 of user root.
Oct 16 14:01:01 xs-files systemd: Starting Session 14440 of user root.
Oct 16 14:01:01 xs-files systemd: Removed slice user-0.slice.
Oct 16 14:01:01 xs-files systemd: Stopping user-0.slice.
Oct 16 15:01:01 xs-files systemd: Created slice user-0.slice.
Oct 16 15:01:01 xs-files systemd: Starting user-0.slice.
Oct 16 15:01:01 xs-files systemd: Started Session 14441 of user root.
Oct 16 15:01:01 xs-files systemd: Starting Session 14441 of user root.
Oct 16 15:01:01 xs-files systemd: Started Session 14442 of user root.
Oct 16 15:01:01 xs-files systemd: Starting Session 14442 of user root.
Oct 16 15:01:01 xs-files systemd: Removed slice user-0.slice.
Oct 16 15:01:01 xs-files systemd: Stopping user-0.slice.
Oct 16 16:01:01 xs-files systemd: Created slice user-0.slice.
Oct 16 16:01:01 xs-files systemd: Starting user-0.slice.
Oct 16 16:01:01 xs-files systemd: Started Session 14443 of user root.
Oct 16 16:01:01 xs-files systemd: Starting Session 14443 of user root.
Oct 16 16:01:01 xs-files systemd: Removed slice user-0.slice.

В Centos 8 я их не заметил, поэтому там ничего делать не надо. Никакой практической пользы сообщения не несут, поэтому отключим их. Для этого создадим отдельное правило для rsyslog, где перечислим все шаблоны сообщений, которые будем вырезать. Разместим это правило в отдельном файле /etc/rsyslog.d/ignore-systemd-session-slice.conf.

# cd /etc/rsyslog.d && mcedit ignore-systemd-session-slice.conf

if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-" or $msg contains "Starting User Slice of" or $msg contains "Removed session" or $msg contains "Removed slice User Slice of" or $msg contains "Stopping User Slice of") then stop

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

# systemctl restart rsyslog

Необходимо понимать, что в данном случае мы отключаем флуд в лог файл только на локальном сервере. Если вы храните логи на удаленном syslog сервере, то данное правило нужно будет настраивать именно на нем.

Установка iftop, atop, htop, lsof на CentOS

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

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

# yum install iftop

И два интересных диспетчера задач, я чаще всего пользуюсь htop, но иногда пригодится и atop. Ставим оба, сами посмотрите, разберетесь, что вам больше нравится, подходит:

# yum install htop
# yum install atop

Вот как выглядит htop:

Для вывода информации о том, какие файлы используются теми или иными процессами, советую поставить утилиту lsof. Она скорее всего рано или поздно пригодится, когда будете диагностировать работу сервера.

# yum install lsof

Рекомендую еще установить несколько нужных и полезных программ, которые часто необходимы, но отсутствуют в минимальной установке — wget, bzip2, traceroute, gdisk.

# yum install wget bzip2 traceroute gdisk

На этом у меня все. Базовая настройка CentOS закончена, можно приступать к установке и настройке основного функционала.

Настройка системной почты

В завершение настройки сервера CentOS сделаем так, что бы почта, адресованная локальному root, отправлялась через внешний почтовый сервер на выбранный почтовый ящик. Если этого не сделать, то она будет локально складываться в файл /var/spool/mail/root. А там может быть важная и полезная информация. Настроим ее отправку в ящик системного администратора.

Здесь кратко только команды и быстрая настройка. Ставим необходимые пакеты:

# yum install mailx cyrus-sasl cyrus-sasl-lib cyrus-sasl-plain postfix

Рисуем примерно такой конфиг для postfix.

cat /etc/postfix/main.cf

## DEFAULT CONFIG BEGIN ######################
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
inet_interfaces = localhost
inet_protocols = all
unknown_local_recipient_reject_code = 550
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

debug_peer_level = 2
debugger_command =
         PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
         ddd $daemon_directory/$process_name $process_id & sleep 5

sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.10.1/samples
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
## DEFAULT CONFIG END ######################

# Имя сервера, которое выводит команда hostname
myhostname = centos-test.xs.local
# Здесь по логике нужно оставлять только домен, но в данном случае лучше оставить полное имя сервера, чтобы в поле отправитель 
# фигурировало полное имя сервера, так удобнее разбирать служебные сообщения
mydomain = centos-test.xs.local
mydestination = $myhostname
myorigin = $mydomain
# Адрес сервера, через который будем отправлять почту
relayhost = mailsrv.mymail.ru:25
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may

Создаем файл с информацией об имени пользователя и пароле для авторизации.

# mcedit /etc/postfix/sasl_passwd

mailsrv.mymail.ru:25 admin@mymail.ru:password

Создаем db файл.

# postmap /etc/postfix/sasl_passwd

Теперь можно перезапустить postfix и проверить работу.

# systemctl restart postfix

К стандартному алиасу для root в /etc/aliases, добавьте внешний адрес, куда будет дублироваться почта, адресованная root. Для этого редактируем указанный файл, изменяя последнюю строку.

Было:

#root: marc

Стало

root: root,admin@mymail.ru

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

# newaliases

Отправим письмо через консоль локальному руту:

# df -h | mail -s "Disk usage" root

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

relay=smtp.yandex.ru[77.88.21.158]:25, delay=0.25, delays=0/0/0.24/0.01, dsn=5.7.1, status=bounced (host smtp.yandex.ru[77.88.21.158] said: 553 5.7.1 Sender address rejected: not owned by auth user. (in reply to MAIL FROM command))

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

На этом настройка локальной почты закончена. Теперь все письма, адресованные локальному root, например, отчеты от cron, будут дублироваться на внешний почтовый ящик, причем с отправкой через полноценный почтовый сервер. Так что письма будут нормально доставляться, не попадая в спам (хотя не обязательно, есть еще эвристические фильтры).

Часто задаваемые вопросы по теме статьи (FAQ)

Почему вы используете скрипт для настройки iptables, вместо стандартного FirewallD?

Я работаю не только с серверами, где установлен firewalld. Правила для iptables более универсальные и применимы в любом linux дистрибутиве. Мне так просто удобно. Если вам удобнее работать с firewalld, то используйте его.Используете ли вы GIU в настройке и эксплуатации серверов?

Чаще всего нет. У меня давно налажен процесс настройки практически любого сервера. Я быстрее все делаю через консоль. Иногда использую Webmin из-за удобного просмотра логов сервисов, если они хранятся только на сервере. Если вам нужна консоль управления сервером, то я рекомендую попробовать Cockpit.Зачем вы отключаете SELinux? Неужели так трудно его настроить?

Я умею настраивать selinux и в некоторых статьях это показываю. Данный материал по общей, базовой настройке centos. В основном это для новичков, которых если сразу нагрузить еще и selinux, то будет тяжело. Если есть желание использовать selinux, его можно будет включить и настроить вместе с сервисом, который будет работать на сервере после предварительной настройки.Почему вы не используете sudo, а работаете в консоли под root?

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

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

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

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

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

Сообщение CentOS 7 и 8 настройка сервера после установки появились сначала на Clip-Clap.