mail_badpass 本身不直接对接 soc，仅向本地 root 邮箱发送通知；需通过采集 auth.log/secure 中“incorrect password attempt”日志，经 syslog 或 filebeat 转发至 soc，并配置结构化告警规则实现闭环。
mail_badpass 是 sudoers 文件中一个默认启用的配置项，它会在用户输入错误 sudo 密码时，向 root 用户发送一封本地邮件。但这个机制本身不直接对接 SOC（安全运营中心），也不能自动转发到外部邮箱或 SIEM/SOC 平台。要实现“将特权尝试失败警报送至 SOC”，需将其作为日志源，再通过标准化日志采集与告警联动完成闭环。
确认 mail_badpass 已启用并生成日志
该选项本身不发外网邮件，而是调用系统 mail 命令投递到本地 root 邮箱（通常是 /var/mail/root 或 /var/spool/mail/root）。先验证是否生效：
- 检查 sudoers：运行
sudo grep mail_badpass /etc/sudoers /etc/sudoers.d/* 2>/dev/null，确认存在Defaults mail_badpass - 手动触发一次失败：切换普通用户，执行
sudo ls /root并输错密码，观察是否在/var/log/auth.log（Debian/Ubuntu）或/var/log/secure（RHEL/CentOS）中留下类似记录：May 23 07:15:22 server sudo: pam_warn(sudo:auth): function=[pam_sm_authenticate] flags=0x8000 service=[sudo] terminal=[pts/0] user=[alice] ruser=[<unknown>] rhost=[192.168.1.5] ...</unknown>
以及更关键的一行：May 23 07:15:22 server sudo: alice : 1 incorrect password attempt ; TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/bin/ls /root - 注意：mail_badpass 的邮件内容不会出现在 auth 日志里，但它依赖 PAM 模块记录失败行为——而这条失败记录才是 SOC 可采集的关键原始事件。
把失败日志接入 SOC 的标准路径
SOC 不读取本地邮箱，而是消费结构化日志流。需将 auth.log 或 secure 中的 sudo 失败条目实时转发：
- 使用 syslog 转发（推荐）：编辑
/etc/rsyslog.conf或新建/etc/rsyslog.d/20-sudo-fail.conf，添加：if $programname == 'sudo' and $msg contains 'incorrect password' then @soc-logger.example.com:514
（替换为你的 SOC 日志接收地址和端口） - 使用 Filebeat/Fluentd 等轻量采集器：配置其监控
/var/log/auth.log，用正则提取字段如user、rhost、timestamp、event_type=sudo_auth_fail，再输出至 SOC 支持的协议（Syslog、HTTP API、Kafka 等） - 确保日志格式含足够上下文：建议在 sudoers 中补充
Defaults log_output, logfile=/var/log/sudo.log（可选），但主日志仍以 auth.log/secure 为准，因其已被多数 SOC 接入方案预置解析规则。
在 SOC 中定义告警规则
日志到达 SOC 后，需配置匹配逻辑与响应动作：
- 规则条件示例（伪语法）：
source: "auth.log" AND message: "incorrect password attempt" AND program: "sudo" - 提取关键字段：
• 用户名 →user字段
• 源 IP → 从rhost=[...]或日志前缀 IP 提取
• 时间戳 → 标准 syslog 时间
• 命令意图 →COMMAND=...后内容 - 响应动作：
• 触发高优先级告警（标签：Privilege Escalation Attempt）
• 自动关联该 IP 近期 SSH 登录失败（Fail2ban 数据）、同用户其他异常行为
• 调用 SOAR 动作：自动封禁 IP、通知管理员、创建工单
为什么不能只靠 mail_badpass 发邮件给 SOC？
mail_badpass 本质是本地邮件队列机制，存在明显局限：
- 它只对 sudo 密码错误有效，不覆盖 su、ssh root 登录、PAM 其他模块失败等场景
- 邮件内容固定、无结构化字段，SOC 很难解析出 IP、用户、时间等关键情报
- 依赖本地 sendmail/postfix 配置，若未正确配置 SMTP，邮件根本不会发出；即使发出，也是明文文本，无法携带 JSON/CEF 格式供 SOC 解析
- 无重试、无确认、无审计追踪，失败静默，不可靠
