Попытки взлома smtp и отсутствие IP в журналах
Разница между su и ssh в том, что последний действительно включает оболочку для входа, в то время как первый по умолчанию этого не делает - хотя он и создает новую интерактивную оболочку (см. ИНВОКАЦИЯ в начале man bash о значении интерактивной и login оболочек). Из man su:
Для обратной совместимости su по умолчанию не изменяет текущий каталог и устанавливает только переменные окружения. каталог и устанавливать только переменные окружения HOME и SHELL (плюс USER и LOGNAME, если целевой пользователь не root). Рекомендуется всегда использовать опцию --login (вместо ее сокращения -), чтобы избежать побочных эффектов, вызванных смешением окружений.
Итак, вы можете попробовать su --login и посмотреть, сделает ли это то, что вы хотите.
Я предполагаю, что вы используете графический интерфейс, поэтому вы не можете просто выйти и войти снова. Однако это может быть возможно в любом случае (в зависимости, я полагаю, от вашей системы init), просто запустив login с любого терминала, который вы используете. Если это сработает, вы увидите обычное приглашение login:, и после этого вы сможете exit, как в su.
Обычные службы SMTP сами по себе не обеспечивают аутентификацию. Аутентифицированный SMTP — это эвфемизм, так как обычно вам необходимо предварительно войти в систему через IMAP или POP, чтобы иметь возможность использовать службу SMTP.
Обычно порты IMAP, а чаще POP3, открытые для Интернета в целом, используются методом перебора -как простой способ найти слабые логин/пароли.
Однако в конфигурациях postfix+dovecot по умолчанию обычно saslauthdв целях аутентификации вызывается dovecot, который предоставляет услуги IMAP/POP3.
Таким образом, вы должны заглянуть в журналы dovecot, чтобы понять, что происходит, и посмотреть на нарушающие IP-адреса.
Я думаю, что dovecotжурналы находятся в /var/log/dovecot.logили что-то подобное (Я некоторое время не использовал CentOS ).
Если ведения журнала вам недостаточно, вы можете временно изменить dovecotконфигурации как:
Отредактируйте /etc/dovecot/conf.d/10-logging.confили /etc/dovecot/dovecot.confс помощью :
auth_verbose=yes
auth_debug=yes
verbose_ssl=yes
, а затемservice dovecote restart
Также в качестве совета, возможно, имеет смысл предоставлять эти услуги через TLS (pop3s 995/tcp и imap 993/tcp ), а не в простой форме. Это будет более безопасно, и вы получите гораздо меньше атак.
ПС. Пожалуйста, подтвердите мне имя файлов конфигурации и файлов журнала, которые у вас есть, чтобы отредактировать этот ответ.
Эта проблема является давней -постоянной ошибкой в cyrus -sasl, вызванной тем фактом, что код авторизации -pam на самом деле не обеспечивает способ передачи хост (или информацию о пользователе )для saslauthd. По идее, патч для исправления должен быть накатан на 2.2, но я ничего не вижу об этом в примечаниях к релизу 2.2.X. Хотя возможно, что это может быть перенесено в версию 2.1 (, возможно, для каждого -дистрибутива ), я не могу найти никаких доказательств того, что это действительно происходит в RedHat или Ubuntu.
За неимением какого-либо фактического решения вы можете рассмотреть решения, предложенные вhttps://unix.stackexchange.com/a/480005и https://unix.stackexchange.com/a/511997, в частности, повысить уровень журнала в sendmail, чтобы выявить IP-адрес неудачных входов в систему, или использовать «не выдал MAIL/EXPN». /VRFY/ETRN во время подключения» в качестве прокси-сервера для неудачных попыток.