Как проверить почту и не принять шум за взлом

Три команды дадут первичную картину: `ss` или `lsof` покажут сетевые сокеты, `journalctl` с `grep` поможет разобрать события, а `mail` проверит отправку. Но они не докажут отсутствие CVE или взлома. Объясняю, что проверять дальше и как не принять обычный порт или фоновый шум за инцидент.

Что именно могут показать три команды

Три команды из этой статьи дают только первичную диагностику. lsof показывает сетевые сокеты и процессы на самом сервере, grep помогает найти выбранные строки в доступных журналах, а mail проверяет локальную попытку отправки. Ни одна из них не сверяет установленную сборку с бюллетенями безопасности, не доказывает отсутствие взлома и не заменяет проверку снаружи. Называть такой набор аудитом CVE — обещать лишнее. Уязвимость определяется сочетанием продукта, версии, пакетов поставщика и конфигурации, а в журнале далеко не всегда появляется её название.

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

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

Шаг 1. Посмотрите, кто слушает сеть

На Linux выполните sudo lsof -nP -i. Опция -i выбирает сетевые файлы; вывод может содержать и слушающие сокеты, и уже установленные соединения. Поэтому сам факт, что строка попала в результат, ещё не означает, что порт доступен из интернета. Чтобы увидеть только слушающие сокеты, в системах с ss удобнее выполнить sudo ss -lntup. В выводе сопоставьте адрес привязки, порт и имя процесса, затем сверяйте результат с ожидаемой схемой публикации сервисов.

Адрес 127.0.0.1 ограничивает прослушивание loopback-интерфейсом IPv4; 0.0.0.0 означает привязку ко всем локальным IPv4-интерфейсам. Аналогично, [::] обычно указывает на все IPv6-интерфейсы. Это описание привязки процесса, а не доказательство внешней доступности: соединение ещё могут фильтровать локальный firewall, сетевой экран провайдера или маршрутизация. Проверять нужно именно те интерфейсы и порты, которые должны обслуживать пользователей и другие почтовые узлы.

Порт 25 обычно используется для передачи SMTP между почтовыми серверами. Порты 110 и 143 связаны с POP3 и IMAP без implicit TLS, а защищённые варианты обычно используют 995 и 993; для отправки клиентами применяются submission-сервисы, в том числе 587 и 465. Это ориентиры, не универсальный список «опасных» портов: назначение задаёт конфигурация конкретной системы. Если процесс слушает на внешнем интерфейсе, спросите, должен ли он там быть, и проверьте правила доступа. Не выключайте сервис только из-за числа в колонке.

Шаг 2. Читайте журналы с контекстом

Найдите журналы именно вашей установки: в зависимости от дистрибутива и способа установки почты события могут идти в systemd journal, syslog или отдельные файлы. Для systemd можно начать с sudo journalctl -u postfix --since "24 hours ago" и отдельно проверить службу Dovecot, если она используется. Названия unit могут отличаться. Просмотр журнала требует прав и может раскрывать адреса, имена учётных записей и другие чувствительные данные; не публикуйте полный вывод в тикете или на стороннем сайте.

Ищите повторяющиеся отказы аутентификации, неожиданные успешные входы, изменения состояния служб и ошибки доставки. Например, sudo journalctl -u postfix --since "24 hours ago" | grep -Ei "warning|error|authentication|reject" отфильтрует часть строк, но не является детектором взлома. Текст сообщений различается между версиями, пакетами и конфигурациями. Слово error может означать обычный временный сбой, а тысячи отказов могут быть фоновым шумом интернета. Важны источник, временной интервал, частота и связь с успешными событиями.

Не ищите номер CVE как обязательную строку лога. Журнал обычно фиксирует действия приложения и сетевые ошибки, а не каталог уязвимостей. Для проверки конкретной CVE запишите продукт, точную версию пакета, источник сборки и включённые компоненты; затем сопоставьте их с уведомлением производителя или дистрибутива. Дистрибутивы могут переносить исправления в пакет, сохраняя прежнюю основную версию программы. Поэтому одна строка версии без данных о пакете не даёт надёжного вывода «уязвим» или «исправлен».

Шаг 3. Проверьте отправку и доставку

Если установлен локальный клиент mail, отправьте контрольное сообщение на принадлежащий вам тестовый ящик: printf "%s\n" "Проверка почтового узла" | mail -s "Тест доставки" адрес@example.net. Подставьте свой адрес и убедитесь, что он принимает тест. Эта команда зависит от наличия и настройки локального MTA; успешный запуск может означать лишь постановку письма в очередь. Проверьте очередь и журнал доставки, а затем подтвердите получение в целевом ящике. Не отправляйте тесты случайным получателям.

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

Для домена отдельно проверьте записи SPF, DKIM и DMARC в DNS и заголовки полученного тестового письма. SPF описывает разрешённые источники отправки, DKIM позволяет проверить подпись, а DMARC задаёт обработку сообщений, не прошедших выравнивание домена с SPF или DKIM. Неверная запись может ухудшить доставляемость или ослабить защиту от подделки, но это не доказывает, что злоумышленник уже отправлял письма. Сначала установите, какие сервисы отправляют почту от имени домена, и включите их в проверку.

Проверьте, не настроен ли сервер как открытый релей

Публичный SMTP на порту 25 нужен многим почтовым серверам и сам по себе не является уязвимостью. Риск возникает, если сервер принимает пересылку для произвольных внешних отправителей и получателей без предусмотренной авторизации или доверенной сети. Проверка локального списка портов этого не устанавливает. Тестируйте только свой узел и только безопасным способом: используйте документацию Postfix по relay access control, ограниченную тестовую конфигурацию и контролируемые адреса, не проводите массовую отправку и не проверяйте чужие серверы.

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

Не считайте внешний веб-тестер источником окончательного вердикта. Убедитесь, что тест относится к вашему домену и серверу, поймите, какие действия он выполняет, и сопоставьте результат с журналами. Открытая форма тестирования может попросить отправить письмо, но это проверяет доставку или DNS-настройки, а не все правила реле. Если есть сомнение, попросите специалиста проверить конфигурацию на стенде или в согласованное окно. Здесь цена ошибки — не абстрактная «уязвимость», а отказ почты или неконтролируемая пересылка.

Что делать при подозрительном результате

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

Для проверки обновлений получите сведения о пакете штатным менеджером вашей ОС и сверяйте их с бюллетенем поставщика и upstream-проектом. Учитывайте, что исправление могло быть перенесено в пакет без смены основной версии. После определения затронутого компонента применяйте поддерживаемое обновление по плану изменений, с резервной копией конфигурации и способом отката. Сам факт установленного Postfix или Dovecot не означает ни безопасности, ни уязвимости; значение имеют точная сборка, поддерживаемость платформы, параметры и доступность сервиса.

Короткий итог такой: ss или lsof отвечают, что слушает локально; журналы показывают зарегистрированные события; тестовое письмо проверяет отдельный маршрут доставки. Затем нужны проверка внешней доступности, оценка relay policy, сверка патчей и анализ аутентификации домена. Это уже последовательность проверок, а не магическая команда. И да, зелёный вывод одной утилиты не является сертификатом безопасности — у терминала нет такой лицензии.

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