Метка: почта

Поменять почтовый адрес root

Posted on by

Важной частью стабильной работы сервера является мониторинг событий на нём. Кроме специализированных утилит вроде logcheck и прочих автоматических анализаторов логов, есть более простые способы получаения важных событий. В частности, многие демоны и прикладные программы используют отправляют сообщения об ошибках и других важных событиях на почтовый адрес суперпользователя root@hostname самого сервера. В настроенном «из коробки» сервере эта почта складывается или в директорию в домашней директории пользователя или в файл /var/mail/$USER. В обоих случаях почта хранится локально, прочитать её можно вручную локально на сервере, что редко кто делает. Перенаправим эти сообщения на другой почтовый ящик, который регулярно проверяется и читается. Это можно сделать следующими основными способами.

/etc/aliases

Это глобальный способ для любого пользователя в системе. /etc/aliases содержит почтовые алиасы алиасы локальных пользователей. Добавляя/изменяя срочку

root: system@example.com, adm@mydomain.com

получаем перенаправление почты на соответствующие адреса. После изменения файла алиасов необходимо запустить newaliases для принятия изменений.

~/.forward

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

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

Удаляем в postfix лишние заголовки

Posted on by

Postfix — отличное типовое решение для корпоративного почтового сервера. Относительно легко ставится, хорошо интегрируется, доступно много всяких фич … что ещё нужно?

Безопасность. Если не конфигурировать явно, то postfix пропускает все заголовки, добавленные до него. Это могут быть:

  1. IP-адрес пользователя во внутренней сети, если он посылает сообщение с помощью клиента. Тогда в полученном письме увидим что-то вроде:

    Received: from [192.168.0.116] (broadband-xxx-xxx-xxx-xx.example.com [xxx.xxx.xxx.xxx])
    by srv.example.com (Postfix) with ESMTPSA id 7AE4D122165
    for ; Sun, 8 Jan 2017 19:13:57 +0000 (UTC)

    Таким образом раскрывается внутренняя структура сети, а если есть ещё и внутренний релей и он добавляет свои заголовки — то и он тоже попадает в заголовки. Ясно дело, что это нежелательно.
    Хорошее решение: срезать все заголовки Received из письма на конечном отправляющем сервере.
    Отдельно замечу, что некоторые из публичных почтовых сервисов тоже светят адрес отославшего письмо, что не всегда хорошо для его безопасности. Вообще, это отдельная тема, что лучше выбрать.

  2. Сообщения, раскрывающию внутреннюю стуктуру почтовика, если в связки используются антивирус/антиспам и подобные решения. Тогда появляется localhost:

    Received: from localhost (localhost [127.0.0.1])
    by srv.example.com (Postfix) with ESMTP id 6466E12216D
    for ; Sun, 8 Jan 2017 19:47:46 +0000 (UTC)

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

  3. User-Agent (почтовый клиент) пользователя:

    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
    Thunderbird/45.6.0

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

    User-Agent: Roundcube Webmail/1.2.3

    и сразу открывается ещё одна потенциально опасная точка входа.

  4. Разного рода автоматически добавляемые скриптами заголовки, например

    Received: by srv.example.com (Postfix, from userid 33)
    id 51C4212216F; Sun, 8 Jan 2017 20:07:31 +0000 (UTC)
    X-PHP-Originating-Script: 0:rcube.php

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

  5. Другие заголовки, которые я здесь не перечислил, но такие точно есть.

Далее →

Вырезание заголовков в exim4

Posted on by

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

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

Received: from srv12 ([10.0.0.12])
	by mymail.example.com with esmtp (Exim 4.84)
	(envelope-from )
	id 1cPEo3-0003N7-Jj
	for user@example.com; Thu, 05 Jan 2013 20:38:39 +0000

или следующее

x-originating-ip: [10.54.14.36]

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

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

X-PHP-Originating-Script: 0:myscript.php

Поэтому, также вырезаем заголовок X-PHP-Originating-Script.

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

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1

или

X-Mailer: Microsoft Outlook 14.0

Обычно, эта информация вполне безопасна. Информацию о клиенте оставляют многие публичные почтовые сервисы. Однако, её тоже не всегда имеет смысл раскрывать. Особенно, если это веб-клиент или внутренняя CRM. Таким образом, можно ещё срезать заголовок User-Agent.

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

system_filter = /etc/exim4/filter

А в самом /etc/exim4/filter прописать вырезаемые заголовки. Например:

headers remove X-PHP-Originating-Script
headers remove Received

После этой доработки, количество заголовков заметно уменьшается и излишняя информация не раскрывается. Естественно, это происходит с сохранением DKIM-подписи (подписывает сервер), поскольку заголовки вырезаются до её формирования.

hubbed_hosts в exim4

Posted on by

Иногда настраиваемый сервер имеет FQDN имя, которое им обрабатываться не должно, но именоваться он должен именно так. В тривиальной настройке exim будет трактовать почту на этот домен локальной и складывать в /var/mail или подобную директорию для локальной почты. Чтобы домен и соответствующая почта не считалась локальной можно это явно прописать в /etc/exim4/hubbed_hosts, например

example.com:  mx.example.com

Типовая настройка DMARC

Posted on by

Что есть DMARC

DMARC это очередной механизм защиты от спама и от несанкционированной рассылки почты с домена. Этот механизм используется для:

  • Информирования почтового сервера получателя о наличии записей DKIM, SPF и их использовании. Частично эта же задача решается ADSP и самим SPF, однако DMARC позволяет охватить оба;
  • Рекомендации почтовому серверу получателя об обработке почты с невалидными DKIM и SPF;
  • Получения обратной связи от серверов получаетелей в формате RFC 5969 и RFC 5070, которые позволяют, в частности, узнать о несанкционированной рассылке с домена.

Как работает DMARC

В DNS-зоне домена создается TXT-запись _dmarc, в которой прописываются его параметры. При доставке почты с домена получающий почтовый сервер использует значения параметров этой записи для обработки полученного письма. Типичный пример записи строится следующим образом:

$ORIGIN example.com.
_dmarc     IN    TXT "tag_0=value_0;tag_1=value_1;...tag_N=value_N"

Текст состоит из пар «переменная=значение» с разделителем «;».

Основные параметры DMARC-записи

Параметров DMARC много и все их можно найти в официальной конфигурации. Ниже наиболее важные.

  • v=, версия. Этот параметр обязательный и должен быть первым со значением DMARC1.
  • p=, policy. Обязательный параметр, который должен быть на втором месте. Рекомендуемые действия MTA получателя для невалидной почты. Возможные значения: none — нет рекомендации почтовику; quarantine — предлагает считать получающему MTA почту с невалидными SPF и DKIM подозрительной и проводить дополнительные проверки; reject — рекомендует отклонять любую почту с невалидными SPF/DKIM.
  • sp=, policy для субдоменов. Опциональный параметр и имеет те же значения, что и p.
  • adkim=, опциональный параметр, в значении s (strict) требует совпадения домена в параметре d= DKIM и отправителя. В r (relaxed, по умолчанию) разрешает использование субдоменов. То есть, почта с user@sub.example.com будет валидной при adkim=r и невалидной при adkim=s.
  • aspf=, опциональный параметр, со значениями s (strict) и r (relaxed, по умолчанию) для SPF, требующий совпадения ответа команды MAIL FROM и заголовка From письма. r разрешает субдомены.
  • pct=, опциональный параметр, доля обрабатываемых DMARC писем. По умолчанию 100 (100 %), и может быть снижена для отладочных целей.
  • fo=, fail policy, опциональный с значением по умолчанию fo=0. В значении 0, отсылает обратный отчёт если все проверки невалидны (DKIM, SPF); в значении 1 — если какая-либо из проверок не валидна. Также возможны значения s и d, соответственно для отчетов по DKIM и SPF.
  • ri=, опциональный, время между отчетами. По умолчанию сутки, т.е. 86400 секунд.
  • rua=, опциональный, список почтовых адресов через запятую, на которые высылать агрегированные отчеты. Если адрес находится в том же домене, работает без дополнительных настроек.
  • ruf=, опциональный, список почтовых адресов через запятую, на которые высылать fail-отчеты (о невалидной почте). Если адрес находится в том же домене, работает без дополнительных настроек.

Типовые конфигурации записей DMARC

С домена отправляется почта, мягкий вариант

Мягкий вариант DMARC-записи не указывает какой-либо явной политики (policy) принимающему почтовому агенту (MTA), что делать с нелегитимной почтой. Принимающий почтовый сервер действует в соответствии со своими настройками и обычно такая почта достигает ящика отправителя. Пример записи, с получением обоих типов отчетов (aggregated & fail):

_dmarc   TXT "v=DMARC1;p=none;fo=1;rua=mailto:admin@example.com;ruf=mailto:admin@example.com"

Этот вариант годится, когда почта потенциально может отправляться с серверов, не прописанных в SPF, или, если допускается отправка неподписанной DKIM почты.

С домена отправляется почта, строгий вариант

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

_dmarc   TXT "v=DMARC1;p=reject;sp=reject;pct=100;aspf=r;fo=1;rua=mailto:admin@example.com;ruf=mailto:admin@example.com"

С домена не отправляется почта вообще

На домене чаще не бывает почты, чем бывает. Такие «беспочтовые» домены лучше сразу настроить, чтобы сторонние сервисы воспринимали почту с них как спам. Ниже пример DMARC-записи в DNS, запрещающей отсылку почты с домена.

_dmarc   TXT "v=DMARC1; p=reject; sp=reject; pct=100; aspf=s"

Естественно, SPF-запись тоже должна быть настроена, в наиболее коротком виде:

@        TXT "v=spf1 -all"

Дополнительно

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

Настройка DKIM в exim4

Posted on by

Заставить exim4 подписывать исходящую почту совсем просто. Для этого в конфиг экзима /etc/exim4/exim4.conf.template дополняем следующими строками

#########################
## DKIM SETTINGS

DKIM_DOMAIN = ${lc:${domain:$h_from:}}
DKIM_FILE = /etc/mail/${lc:${domain:$h_from:}}.key
DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}}
DKIM_SELECTOR = m01

## DKIM SETTINGS END
########################

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

  • Создаем пару ключей с помощью openssl,
  • Прописываем открытый ключ в DNS,
  • Закрытый ключ помещаем в /etc/mail/domain_name.key (вместо domain_name имя домена) и меняем его права и владельца на 0640 и root:Debian-exim,
  • Перезагружаем exim4, отправляем тестовое письмо на адрес с включенной верификацией DKIM-подписи и убеждаемся, что все работает правильно.

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

DKIM_SELECTOR = ${extract{-1}{.}{DKIM_PRIVATE_KEY}}

Кроме настройки DKIM в exim полезно настроить обрезание определённых нежелательных заголовков в целях безопасности. Такими, например, могут быть имена формирующих письмо скриптов или IP-адреса отправителей письма (при отправке по SMTP с другой машины, которая может стоять во внутренней сети), которые раскрывают внутреннюю структуру системы. Для этого в тот же шаблон /etc/exim4/exim4.conf.template рядом с DKIM добавляем фильтр по заголовкам

system_filter = /etc/exim4/filter

Содержимое файла конфигурации фильтра /etc/exim4/filter может быть, например, таким

headers remove X-PHP-Originating-Script
headers remove Received

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

$ echo "This will go into the body of the mail." | mail -s "Hello world" -a "From: me@mydomain.com" myemail@example.com

PS: вышеприведенная конфигурация — Debian-based дистрибутивов. Для RedHat и других файлы конфигов могут быть немного другими.

Формирование DKIM ключей

Posted on by

При администрировании почтовых (да и не только почтовых, но и любых отсылающих почту) серверов время от времени требуется создавать DKIM ключи для почты. Эта, в целом несложная, процедура состоит из генерирования ключей, добавления открытого в DNS TXT-запись домена, а закрытого — в конфиг почтового сервера. Ниже по порядку.

Генерировать ключи удобно с помощью широкоиспользуемой утилиты openssl. Чтобы не делать это каждый раз руками, полезно написать скриптик

#!/bin/sh

if [ "$1" != "" ]; then
	openssl genrsa -out "$1.key" 2048
	openssl rsa -in "$1.key" -out "$1.pub" -pubout -outform PEM
	chmod o= "$1.key"
else
	echo "Usage: $0 domainname"
fi

вызывая который с параметром — доменным именем, для которого формируем ключи, получаем пару ключей: публичный (открытый) и приватный (закрытый). В приведенной конфигурации используется 2048-битный ключ, что несколько безопаснее и потому предпочтительнее.

Публичный ключ доступен всем через DNS. Для этого помещаем его в виде TXT-записи для настраиваемого домена с именем x._domainkey, где x — это селектор. Селектор выбирается произвольно и обычно он «привязан» к серверу. Содержимое записи — это сам публичный ключ и некоторые параметры перед ним. Общий формат записи в DNS:

x._domainkey.mydomain.com.   TXT "v=DKIM1; g=*; k=rsa; p=[PUBLIC_KEY]"

Если текст записи достаточно длинный (а 2048-битный таким является), то его лучше разбить на несколько строк. Например, в DNS-сервере bind9, запись будет выглядеть так:

x._domainkey.mydomain.com.	TXT ( "v=DKIM1; g=*; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqUkhw8hQQ4NfKAPkvrQqd04Ta2fyVTfrVdbud62HeSISpDzf1GWPGrN0ikqcTT+6DW5fRwOnGO0VkennMs7+d+WkpTJ6Y63ydrFaK/sa8HoESPBJHqrNfViQzlCt5ZCc4UZN1sLLoO3HukwvLRtM"
				"wKMzxIkavknl86PLcTebS3+ac7lWdPoqJbooHQglizs0YazLqQTLn/L6mqv1OgPCMU44seEp/CZilUchbLvHAsrfK8+AADGm+/U/5qt6/SC31ZN/BmAqtMMKvT8rMFw2qj43DPWSkn9ln5EsyUJhQiORNX3v+9rndZNuw2I90xXbuIflc30gLStXG1Jqg4IAXQIDAQAB" )

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

После добавления открытого ключа в DNS лучше проверить его рабочесть. Из шелла это делается так

$ host -t txt x._domainkey.mydomain.com

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

Приватный ключ добавляется в настройки почтового сервера, которые несколько различаются. Обычно приватные ключи хранятся в /etc/mail, причем для безопасности их права лучше сразу поменять на 0640 и изменить владельца так, чтобы ключ смог читать почтовый демон, но не пользователи системы.

Минимум в настройке почтовых серверов и рассылок

Posted on by

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

  • Убедитесь, что ваш почтовый сервер не open relay, т.е. не рассылает сообщения от неавторизованных пользователей. Проверьте сконфигурированный почтовый сервер на open relay в нескольких легко находимых в поисковиках сервисах.
  • В соответствии с RFC настройте обратный DNS (rDNS) для IP-адреса сервера и убедитесь, что возвращаемое доменное корректно разрешается и его A-запись — IP-адрес сервера. Иными словами доменное имя должно разрешаться в IP-адрес сервера, а IP-адрес — обратно разрешаться в то же доменное имя (FQDN). Именно это доменное имя должно возвращаться сервером в HELO/EHLO.
  • Настройте цифровую подпись DKIM. Её использование защитит вас от несанкционированной рассылки почты от вашего домена с серверов третьих лиц. По этой причине популярные почтовые сервисы используют её наличие при вычислении «спамовости» письма. После настройки DKIM, подпись следует проверить: в заголовках отосланных писем на серверах, проверяющих подпись, должна присутствовать запись dkim=pass.
  • Используйте антиспам и антивирусное ПО. В том числе и на исходящую почту. Если используете postfix, то на его сайте опубликован список поддерживаемого софта.
  • Настройте SPF. Целесообразность использования этой технологии иногда ставится под вопрос, поскольку она имеет недостаток: форвард с непрописанных серверов приведет к fail-результату по SPF. DKIM в этом смысле существенно более совершенная технология и в целом делает ненужным SPF. Тем не менее, в существующих реалиях её лучше использовать. Проверка, как и в случае с DKIM проста: в исходнике принятых с сервера писем должен быть результат spf=pass. SPF также имеет смысл включать на «непочтовых» доменах в виде "v=spf1 -all" для предотвращения отправки спама от этого домена.
  • Проверьте, что IP-адрес сервера не находится в черных списках, например этим тестом.

В случае почтовых рассылок обязательно необходимо проверить валидность заголовков письма. Например, если сообщение формируется как MIME multipart, убедитесь в правильном использовании Content-type для различных частей письма.

Проверка rar в amavis на почтовом сервере

Posted on by

Оказывается, стандартный unrar-free не распаковывает многоуровневые вложенные rar-архивы. Для того, чтобы такие архивы распаковывались и их содержимое проверялось необходимо включить «несвободную» unrar-библиотеку. Если конкретно, то изменить в конфиге amavis стоковую конфигурацию (которая находится в /etc/amavis/conf.d/01-debian:

#$unrar = ['rar', 'unrar']; #disabled (non-free, no security support)
$unrar = ['unrar-free'];

на свою:

$unrar = ['rar', 'unrar']; #disabled (non-free, no security support)
#$unrar = ['unrar-free'];

После этого амавис корректно открывает rar-архивы и можно запрещать неугодные разрешения файлов.

UPDATE:
Если закомментировать обе строки, то будет использоваться архиватор 7zip (который заранее, естественно, установить надо). Также его можно указать вручную. Это похоже наилучшее решение.