针对我的邮件服务器的日志中有很多 PAM 身份验证错误。我该如何阻止?

Joh*_*Doe 4 server ssh authentication pam

我需要帮助来确定auth.log我的 Ubuntu 服务器上文件中的一些错误。几周前,我发现 SSH 端口 (22) 的登录尝试过多auth.log,因此我更改了 SSH 端口。它干净了一个星期,然后我发现另一堆通过不同端口的登录尝试。

PAM 身份验证错误

我得到了很多重复的红色线条(在图像中)。重复的行如下:

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]
Run Code Online (Sandbox Code Playgroud)

我可以看出他们正在尝试登录我的邮件服务器(因为领域是mail.mydomain.com),但我无法确切地说出他们正在尝试做什么,因为我不知道 PAM 是什么。什么是 PAM?我应该怎么做才能阻止我的邮件服务器(端口 25)上的这些身份验证尝试?

我也偶尔会收到一些auth.log与 PAM 相关的CRON 日志,如果有人也能告诉我这些是什么意思,那就太好了:

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
Run Code Online (Sandbox Code Playgroud)

Tho*_*ard 9

首先,这在邮件服务器上并不少见。 如果端口 25 暴露给网络,则 Internet 上的每个邮件服务器都会看到这些。甚至我工作场所的邮件网关和邮件服务器也会受到这些攻击,其中许多尝试被过滤和阻止的原因是网络边界上的 IDS/IPS(入侵检测/预防系统),它涉及许多来源OSINT(开源情报)创建一组被阻止的基于信誉的坏 IP。其中一些探针通过了,但尝试时却没有成功。

很有可能,它不是针对您的服务器的有针对性的蛮力,而是“Internet 的扫描器和探测器”对每个面向 Internet 的 SMTP 服务器执行其操作。这些可能是垃圾邮件机器人试图探测开放中继,如果他们没有找到开放中继,他们可能会尝试尝试获取对帐户的访问权限,以便将 SMTP 服务器用作邮件中继。或者它是一个服务扫描器,试图查看您是否有任何“弱密码”,以便他们可以利用它们,然后利用您的服务器通过您的邮件服务器发送他们自己的邮件。

只要您遵循强密码的其他安全实践,除非用户需要,否则不授予用户访问权限等,就他们不闯入您的服务器而言,您应该很好。我不太关心身份验证失败,而更关心身份验证是否成功。

一个额外的安全选项是设置 Fail2Ban,它可以禁止用户,但是我还没有让它正常运行,也没有时间深入研究它以使我的邮件服务器在失败时自动禁止 IP授权太多次)。不过,请轻轻踩一下,因为如果您不小心,它也会阻止。(一旦我有了一个“工作”的 Fail2Ban 配置,我就会把它作为对这个答案的评论分享,但让它按照我想要的方式行事是很棘手的)


至于您的 中的cron:session条目auth.log,这只是一个说明,系统的cron守护程序正在运行cron来自/etc/crontab, 的任务/etc/cron.{d,daily,hourly,monthly,weekly}/*,并且root用户 crontab 根据为 cron 作业设置的计划以 root 用户身份运行(其中 crontabs 设置为运行为root)。这些通常是可以的,前提是您实际检查 root 帐户下的每个 crontab 以确保没有任何“坏”作为root.