«Ретрансляция неоткрытой почты» Postfix / Dovecot все равно ретранслируют; Неправильно настроен или сломан? Кроме того, заблокированным в настоящее время внешним пользователям тоже нужен доступ.
КРИТИЧЕСКОЕ ОБНОВЛЕНИЕ
Пока я работал над этим, спам не пересылался более одного дня, поэтому я оставил его включенным, и на ночь было ретранслировано ДВА письма! АКТ!
Вот они из моих команд Tail/grep (подробности ниже):
Итак, я снова выключил его. Дальнейшие обновления ниже.
Фон
У этого вопроса более длинная предыстория, а также два других вопроса, поскольку проблемный сервер уже давно установлен, и я ВООБЩЕ не буду вдаваться в него в этом вопросе, но как работающая система испортилась, и кое-что из того, что было сделано до сих пор,
Очень важно отметить , что в то время, когда взломщики спама убедили систему ретранслировать почту, мы ДУМАЛИ, что она настроена примерно так же, как и раньше, и сообщили, что это не открытая ретрансляция! ОДНАКО, как описано на той другой странице, несколько дней спустя система отправляла сотни тысяч спама!
Что касается других уже заданных вопросов, может можно найти здесь.первый спрашивал о том, как сделать так, чтобы реле не было открытым, то есть, коротко говоря, просто настроить следующим образом:
default_transport = error: This server is presently not sending email
(Разумеется, выберите свое сообщение — на самом деле оно не наше, но я из вежливости.)
Второй спрашивает: «Как мне узнать наверняка, что проблема исправлена, а если нет, то исправить это быстро?», и у него есть ответ, который может быть правильным, но я не чувствую, что могу ему доверять. Здесь речь идет не о тестировании сайта; вопрос касается взаимодействия между двумя пакетами, поскольку оно связано с использованием в качестве открытого ретранслятора, его закрытием и возвратом службы действительным пользователям, даже несмотря на то, что стандартные (хотя и простые/упрощенные) тесты (например, из
КОНЕЧНО, настройки безопасности postfix и dovecot взаимосвязаны, но мы используем эти два пакета в этой системе (конечно, обновляемые по мере необходимости) с конца 1990-х годов, я лично устанавливал их и поддерживал их на протяжении всех этих лет, обновляя, внося изменения и т. д. Но это не значит, что я слежу за всеми изменениями с течением времени и знаю, каковы все уязвимости и т. д. Например, до недавнего времени я не знал о раздвоении версии 2.1
Возможно, будет полезно узнать, что исходную установку пришлось пересобрать с нуля в конце января (менее месяца назад) до той же версии ОС, и что незадолго до этого она получила обновление, но еще не была перезагружена. Итак, на момент начала саги 19 января 2023 года мы работали со старыми настройками, и после восстановления мы случайно получили конфигурацию Dovecot по умолчанию и были озадачены, почему нам пришлось взломать ее настолько, чтобы получить наш Dovecot. использование подключения пользователей (в основном внешних) (хотя я даже не уверен, что это работало полностью до того, как нас достали спамеры).
Это хорошее место, чтобы отметить, что спамеры, похоже, взломали нас примерно через день после того, как мы взломали раздел аутентификации Dovecot, чтобы подключиться к нашим удаленным пользователям, что также произошло примерно через два дня после того, как система снова заработала, получая электронную почту. Мы удалили удаленных пользователей как можно скорее, чтобы остановить спам, и с тех пор действительные удаленные соединения никогда не работали, хотя мы думали, что их лучше настроить позже. КЛЮЧЕВАЯ ЦЕЛЬ сейчас — восстановить работоспособность соединений наших удаленных пользователей, БЕЗ повторного открытия реле! (Конечно, при условии, что в настоящее время это не открытое реле, но мы думали, что исправили это уже несколько раз, только для того, чтобы они вернулись!)
Текущие версии:
- Fedora Server v 37 с обновлениями примерно от 20 января 2023 г.
- Ядро 6.0.7-301.fc37.x86_64
- постфикс-3.7.3-1.fc37.x86_64
- голубятня-2.3.20-1.fc37.x86_64
Связанные, но вспомогательные вопросы
Хотя это и не является строго частью заявленных целей, я был слишком отвлечен, чтобы делать что-то большее, чем просто думать об этом: мне бы очень хотелось знать, как ограничить исходящие сообщения об ошибках, чтобы не отправлять никаких причин для отключения - локальные журналы достаточно, спасибо! Им не нужно знать, что «такого пользователя нет» и т. д., но полный почтовый ящик — это нормально. И я также хотел бы знать, как я могу навсегда заблокировать некоторые IP-адреса, просто на основании собственных наблюдений за IP-адресами, пытающимися взломать мою/нашу систему. Например, ни один IP-адрес, происходящий за пределами США, не имеет никакой достоверности при подключении в качестве пользователя, и на самом деле действительный список пользователей короткий (хотя я не знаю точных цифр и НЕ МОГУ знать точную информацию).
Текущая конфигурация
На уже процитированной странице вопросов кто-то сказал, что, по его мнению, это «украденные учетные данные», и поэтому
Прежде чем перечислять все ценности, стоит сказать, что на момент написания этой статьи НИ ОДИН из
Что касается того, что оба пакета говорят о конфигурации сейчас, я использовал:doveconf -n > file
Общее содержание составляет около 1404 строк! Конечно, слишком много, чтобы публиковать здесь. Только
Я просмотрел все это и выбрал то, что кажется здесь подходящим - если нужно больше, просто дайте мне знать. Первая основная конфигурация Postfix по порядку:
milter_default_action = accept
mydestination = $myhostname,
localhost.$mydomain,
localhost,
...60 more...
mynetworks = explicit list of IPs, no ranges
relay_domains = $mydestination,
...and most of the internal box IPs...
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
check_helo_access hash:/etc/postfix/helo_access,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unauth_destination,
check_sender_access hash:/etc/postfix/sender_access,
check_client_access hash:/etc/postfix/pop-before-smtp,
permit_mynetworks
smtpd_relay_restrictions = permit_mynetworks,
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
check_sender_access hash:/etc/postfix/sender_access,
check_client_access hash:/etc/postfix/pop-before-smtp,
permit_sasl_authenticated,
defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit_sasl_authenticated,
reject_unlisted_sender,
check_client_access hash:/etc/postfix/pop-before-smtp
smtpd_tls_security_level = may
Далее идет основная конфигурация. Просматривая его, я понял, что то, что редактируется человеком, легче переваривать! Кроме того, почти все было по умолчанию, и я удалил все, кроме
smtp inet n - n - - smtpd
submission inet n - n - - smtpd -o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes
policyd-spf unix - n n - 0 spawn user=policyd-spf
argv=/usr/libexec/postfix/policyd-spf
Затем,
passdb {
args = scheme=cram-md5 /somefile
driver = passwd-file
}
passdb {
args = /anEMPTYfile (not using it yet)
driver = passwd-file
master = yes
pass = yes
}
service auth - matches postfix
service imap-login {
inet_listener imaps {
port = 993
ssl = yes
}
}
service pop3-login {
inet_listener pop3s {
port = 995
ssl = yes
}
}
service submission-login {
inet_listener submission {
port = 587
}
}
ssl = required
certs, including our virtual domains, omitted
Сейчас я считаю, что наиболее вероятной проблемой является ПОРЯДОК разрешений и отклонений в Postfix.Вскоре я пройду через это (снова!) гораздо более тщательно.
Текущее тестирование и результаты
Конечно, следующим шагом будет заставить пользователей подключаться и следить за тем, не проходит ли еще спам. Что касается мониторинга спамеров, я использую:
watch -n 1 -p -b qshape
И:
tail -f /var/log/maillog | grep 'status=sent' | grep 'relay=' | grep -v 'relay=local'
Если есть способы получше, поделитесь! Тем временем:
Результаты тестирования:
Результат 1
Мы протестировали как внутренние, так и внешние действительные попытки пользователей, поскольку новая конфигурация отслеживания всего создает «гору» материалов. Однако, когда используется заведомо неправильный пароль, мы получаем четкое сообщение об этом, а когда используется правильный, мы не получаем НИКАКОГО подтверждения и голубятня
Кажется, это начинается со сказанного
Следующее связанное сообщение гласит:
Соединения не успешны. Продолжаем дальше...
Результат 2
Я заметил, что не было объявлено никакого userdb, и на данный момент, уже попытавшись вернуться ко всему старому дереву конфигурации, я решил, что это (пока) не нужно (потому что мы еще не создаем виртуальных пользователей, но надеемся, что в этом году), однако Dovecot явно не отклонял соединения с действительными паролями (как это происходит с заведомо неправильными паролями), поэтому я задавался вопросом, действительно ли они проходили, а затем не было пользовательского каталога или чего-то подобного. Итак, я попробовал это, используя пример синтаксиса.
Dovecot отказался перезапускаться, поэтому я удалил его, однако вы можете найти адаптированный мной шаблон здесь.
Результат 3
Как отмечено сейчас в самом верху, для акцента: поскольку сервер работал относительно без изменений в течение более суток и не видел никаких переадресаций, я решил довериться ему на ночь, и, вернувшись к компьютеру, я обнаружил, что ДВА прошли....Эти записи были выделены моей командой хвоста/grep для отслеживания журнала, отмеченной выше:
Feb 13 02:30:01 fs1 postfix/smtp[749779]: 1442CBE4C12: to=<info@s1.alexdf.ru>, relay=mail.s1.alexdf.ru[82.202.199.173]:25, delay=3.4, delays=0.03/0.06/2.4/0.84, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as A8D104D1D)
Feb 13 06:22:24 fs1 postfix/smtp[793411]: 8702BBE4C12: to=<info@s2.alexdf.ru>, relay=mail.s2.alexdf.ru[188.68.206.204]:25, delay=3, delays=0.03/0.06/2.2/0.8, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as DAD424D20)
Я мгновенно остановил Postfix и Dovecot. Я далеко не эксперт в такого рода анализе, но знаю, как запустить grep! Я предполагаю, что для первого я хочу сосредоточиться на 1442CBE4C12 и/или A8D104D1D, а на втором 8702BBE4C12 и/или DAD424D20. Анализ начинается...
Я получил только данные из журнала и ничего из очередей — они, очевидно, пусты. (И мне пришлось снова включить почту, чтобы проверить очереди, что меня удивило, поэтому я сначала отключил отправку!
Во-первых:
Feb 13 02:29:58 fs1 postfix/cleanup[749650]: 1442CBE4C12: message-id=<20230213102958.1442CBE4C12@mail.sciencetools.com>
Feb 13 02:29:58 fs1 postfix/bounce[749778]: 6248FBE48BE: sender non-delivery notification: 1442CBE4C12
Feb 13 02:29:58 fs1 postfix/qmgr[644284]: 1442CBE4C12: from=<>, size=49321, nrcpt=1 (queue active)
Feb 13 02:30:01 fs1 postfix/smtp[749779]: 1442CBE4C12: to=<info@s1.alexdf.ru>, relay=mail.s1.alexdf.ru[82.202.199.173]:25, delay=3.4, delays=0.03/0.06/2.4/0.84, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as A8D104D1D)
Feb 13 02:30:01 fs1 postfix/qmgr[644284]: 1442CBE4C12: removed
Второй:
Feb 13 06:22:21 fs1 postfix/cleanup[793292]: 8702BBE4C12: message-id=<20230213142221.8702BBE4C12@mail.sciencetools.com>
Feb 13 06:22:21 fs1 postfix/bounce[793410]: CFFC7BE41DA: sender non-delivery notification: 8702BBE4C12
Feb 13 06:22:21 fs1 postfix/qmgr[644284]: 8702BBE4C12: from=<>, size=49321, nrcpt=1 (queue active)
Feb 13 06:22:24 fs1 postfix/smtp[793411]: 8702BBE4C12: to=<info@s2.alexdf.ru>, relay=mail.s2.alexdf.ru[188.68.206.204]:25, delay=3, delays=0.03/0.06/2.2/0.8, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as DAD424D20)
Feb 13 06:22:24 fs1 postfix/qmgr[644284]: 8702BBE4C12: removed
Это не дало НИЧЕГО ПОЛЕЗНОГО для выяснения, КАК спамерам удалось это сделать!