Много ошибок аутентификации PAM на моих журналах, предназначающихся для моего mailserver. Как я останавливаю его?
Я нуждаюсь в помощи, точно определяя некоторые ошибки в моем auth.log файл на моем сервере Ubuntu. Несколько недель назад я нашел множество попыток входа в систему к моему порту SSH (22) на auth.log, таким образом, я изменил свой порт SSH. Это было чисто в течение недели, и затем я нашел другой набор попыток входа в систему через другой порт.
Я получаю много дубликатов строк красного цвета (в изображении). Строки повторения следующие:
saslauthd[1140]: pam_unix(smtp:auth): check pass; user unknown
saslauthd[1140]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
saslauthd[1140]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
saslauthd[1140]: do_auth : auth failure: [user=roselia] [service=smtp] [realm=mail.mydomain.com] [mech=pam] [reason=PAM auth error]
Я могу сказать, что они пытаются войти в мой mailserver (так как область mail.mydomain.com), но я не могу сказать точно, что они пытаются сделать, так как я не знаю, каков PAM. Что такое PAM? И что я должен сделать для остановки этих подлинных попыток на моем mailserver (порт 25)?
Я также иногда добираюсь, немного КРОНА входит в систему мой auth.log это связано с PAM, и будет замечательно, если кто-то может сказать мне, что они означают также:
CRON[32236]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[32235]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[32236]: pam_unix(cron:session): session closed for user root
CRON[32235]: pam_unix(cron:session): session closed for user root
1 ответ
Во-первых, это весьма распространено для наблюдения на почтовых серверах. Каждый Почтовый сервер в Интернете видит их, если порт 25 выставляется сети. Даже почтовые шлюзы и почтовые серверы на моем рабочем месте поражены ими, причиной, что многие из этих попыток отфильтрованы и заблокировались, является IDS/IPS (Обнаружение Intrustion / Система Предотвращения) на границе сети, которая относится ко многим источникам OSINT (Аналитика С открытым исходным кодом) для создания основанного на репутации набора плохого дюйм/с, которые заблокированы. Некоторые из этих датчиков проходят, но они не успешны, когда они пробуют.
По всей вероятности, это не целенаправленная грубая сила против Вашего сервера, это - "сканеры и датчики Интернета" выполнение их вещи к каждому стоящему с Интернетом серверу SMTP. Это, вероятно, спам-роботы, пытающиеся зондировать для открытых реле, и если они не находят открытое реле, они, вероятно, зондируют, чтобы попытаться получить доступ к учетным записям для использования сервера SMTP в качестве почтового реле. Или это - сервисный сканер, пытающийся видеть, есть ли у Вас какие-либо 'слабые пароли' в игре, таким образом, они могут использовать их и затем использовать Ваш сервер для отправки их собственной почты через mailservers.
Пока Вы применяете другие методы безопасности сильных паролей, не предоставляя пользовательский доступ, если им не нужен он, и т.д., необходимо быть хороши пойти с точки зрения их, не ворвавшись сервер. Я был бы менее обеспокоен ошибками аутентификации и более соответствующий, если бы auths были успешны.
Дополнительный параметр безопасности состоит в том, чтобы настроить Fail2Ban, который будет работать для запрета пользователей, однако я должен все же получить это функционирование правильно и не имел времени для рытья в него, чтобы заставить fail2ban работать на мой почтовый сервер для автозапрещения дюйм/с, если они перестали работать автору слишком много раз). Шагайте слегка с этим, хотя, потому что это может также заблокировать Вас, если Вы не осторожны. (После того как у меня есть 'работа' конфигурация Fail2Ban, я совместно использую это как комментарий к этому ответу, но это было хитро, чтобы заставить это вести себя способ, которым я хочу это к),
Что касается cron:session записи в Вашем auth.log, это - просто примечание что система cron демон работает cron задачи от /etc/crontab, /etc/cron.{d,daily,hourly,monthly,weekly}/*, и root пользователь crontab на набор расписания для заданий крона как пользователь root (где crontabs установлены работать как root). Они обычно в порядке, при условии, что Вы на самом деле проверяете каждый crontab в соответствии с корневой учетной записью, чтобы удостовериться, что ничто 'плохо' не работает автоматически как root.