Безопасность почтового сервера в первый день: что закрыть до того, как его найдут боты

Новый почтовый сервер начинают атаковать в первые часы после запуска. Либо вы закроете двери в первый день, либо их откроют за вас. Свой почтовый сервер — это контроль, которого нет в облаке, но и ответственность, которую облако раньше брало на себя. Безопасность почтового сервера начинается в первые часы после запуска: боты находят новый IP с открытым портом 25 быстрее, чем вы успеваете настроить DKIM. Ниже — список того, что нужно закрыть в первый день, чтобы свой сервер был надёжнее облачного, а не наоборот.

Свой сервер может быть надёжнее облака

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

На своём сервере всё это в ваших руках. Правильно настроенный сервер, где админ-панель открыта только из офиса, перебор паролей блокируется автоматически, а отправка ограничена, защищён лучше типичного облачного ящика с паролем «Компания2024». Но только если эти настройки сделаны.

Боты не ждут, пока вы освоитесь

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

Хорошая новость: защитить свой сервер лучше, чем защищён типичный облачный ящик, — реально, и это делается за день. Плохая: если этого не сделать, первый взломанный ящик отправит ваш IP во все чёрные списки, и вы будете винить в этом «свой сервер», а не свою беспечность. Список — ниже. Выполните его целиком.

1. Не открытый релей

Самая опасная ошибка почтового сервера — открытый релей: сервер принимает письма от кого угодно для кого угодно и пересылает их дальше. Такой сервер находят за часы и используют для спама, а его IP попадает во все чёрные списки. Готовые сборки — mailcow, iRedMail, Carbonio — по умолчанию релеем не являются, но после ручных правок конфигурации это нужно проверить.

# проверка открытого релея с внешней машины: сервер должен отказать
$ telnet mail.company.ru 25
EHLO test.example
MAIL FROM:<test@example.net>
RCPT TO:<someone@other-domain.example>
554 5.7.1 <someone@other-domain.example>: Relay access denied

Сервер должен принимать без авторизации только письма для своих доменов, а отправлять наружу — только после входа по логину и паролю на портах 587 или 465.

2. Только нужные порты

Почтовому серверу нужны порт 25 для приёма почты от других серверов, 587 и 465 для отправки сотрудниками, 993 для IMAP и 443 для веб-почты. POP3 и незашифрованный IMAP на 143 и 110 откройте только если они действительно нужны. Все остальные порты закройте межсетевым экраном, а SSH разрешите только с адресов офиса или через VPN.

# только нужные порты (пример для ufw)
ufw default deny incoming
ufw allow 25,465,587,993/tcp      # почта
ufw allow 80,443/tcp              # веб-почта и сертификаты
ufw allow from 198.51.100.0/24 to any port 22 proto tcp   # SSH только из офиса
ufw enable

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

Подробнее о базовой защите Linux-сервера — в статье «Защита Linux-сервера: 15 шагов».

3. Пароли только через шифрование

Сервер не должен принимать пароли по незашифрованному соединению. На портах 587 и 143 авторизация допустима только после STARTTLS, на 465 и 993 соединение зашифровано сразу. В Dovecot за это отвечает запрет авторизации открытым текстом без TLS, в Postfix — разрешение SASL-авторизации только на зашифрованном соединении. Сертификат — действующий, на имя сервера, с автоматическим продлением.

Отключите устаревшие версии протокола — SSLv3, TLS 1.0 и 1.1 — и слабые наборы шифров. Современные почтовые программы и телефоны работают с TLS 1.2 и 1.3; если какое-то старое устройство в офисе перестало подключаться, лучше заменить или перенастроить его, чем держать открытым слабое шифрование для всех.

4. Защита от перебора паролей

Через несколько часов после запуска в журналах появятся тысячи попыток входа с подбором паролей. Fail2ban читает журналы и блокирует IP после нескольких неудачных попыток: для SMTP-авторизации, IMAP, веб-почты, панели администратора и SSH. В iRedMail он ставится по умолчанию, в mailcow есть встроенный аналог — netfilter, в Carbonio его настраивают отдельно.

Проверьте, что блокировка реально срабатывает: несколько неверных входов с тестового адреса должны привести к его блокировке. Подробно о Fail2ban — в статье о защите от перебора паролей.

5. Пароли сотрудников

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

6. Панель администратора — не для всего интернета

Панель администратора — ключ ко всем ящикам компании. Закройте её от внешнего мира: доступ только из офисной сети или через VPN. Если это невозможно — двухфакторный вход для администратора обязательно, отдельная учётная запись для каждого администратора, без общей «admin» с паролем в чате. Отдельно проверьте, что служебные интерфейсы — статистика антиспама, консоли баз данных — тоже не торчат наружу.

Типовой список для Zimbra и Carbonio — в статье «Защита Zimbra: чек-лист из 16 пунктов».

7. Лимиты отправки

Даже с хорошими паролями когда-нибудь утечёт пароль одного сотрудника. Лимит писем в час на ящик превращает это из катастрофы в инцидент: вместо десятков тысяч спам-писем за ночь злоумышленник отправит сотню, а вы получите оповещение. Для обычного сотрудника достаточно десятков-сотен писем в час; для ящиков, с которых идут уведомления 1С, — больше, но тоже с потолком. Как это делается в mailcow — в статье о лимитах отправки.

8. Антиспам и вложения

Входящая почта — основной путь шифровальщиков в компанию. Антиспам с проверкой SPF, DKIM и DMARC входящих писем, антивирус для вложений и блокировка опасных типов файлов — исполняемых файлов, скриптов, офисных документов с макросами, а также архивов с ними внутри. Проверьте, что фильтр смотрит внутрь архивов: письмо с ZIP, в котором лежит EXE, должно отклоняться — мы разбирали это в статье о проверке EXE внутри ZIP.

9. Обновления

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

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

10. Резервные копии вне сервера

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

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

11. Журналы и оповещения

Безопасность без мониторинга — это надежда. Минимальный набор оповещений: всплеск неудачных входов, резкий рост очереди отправки, попадание IP в чёрный список, вход в панель администратора с нового адреса, заканчивающееся место на диске, истекающий сертификат. Журналы храните не только на самом сервере: злоумышленник первым делом чистит следы.

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

12. Правила пересылки

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

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

13. Домен защищён от подделки

Безопасность почты — это не только сервер, но и домен. Если у домена нет DMARC с жёсткой политикой, кто угодно может отправить письмо «от бухгалтерии» вашим клиентам, и часть получателей его примет. После того как отчёты DMARC подтвердили, что все легитимные источники почты проходят проверки, переведите политику на quarantine, затем на reject. Это одна строка в DNS, которая закрывает самый дешёвый вид мошенничества от вашего имени.

Подробно о проверках при переезде — в статье о доставляемости почты после переезда.

14. Учётные записи и доступы — под регулярным контролем

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

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

Если ящик всё-таки взломали

Порядок действий, который стоит записать заранее.

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

Первая неделя после запуска

Первую неделю журналы сервера стоит просматривать каждый день — не потому что что-то обязательно пойдёт не так, а чтобы понять, как выглядит нормальная работа. Сколько попыток перебора блокирует Fail2ban, сколько писем отклоняет антиспам, сколько уходит наружу. Через неделю у вас будет точка отсчёта, и любое отклонение — всплеск отправки ночью или вход из незнакомой страны — станет заметным сразу.

Мы для клиентов на обслуживании настраиваем эти показатели в системе мониторинга с оповещениями в мессенджер. Без мониторинга свой сервер теряет главное преимущество перед облаком — то, что вы видите происходящее.

Чек-лист первого дня

Всё, что нужно сделать до переключения MX.

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

Частые вопросы