关键在于精准定位异常登录主体、时间、来源及方式，而非仅检查日志存在；须结合lastlog、journalctl筛选认证事件、faillog分析锁定账户，并关闭permitrootlogin和passwordauthentication等高危默认配置，强化ssh安全。
怎么快速发现系统里异常的登录行为
关键不是看日志有没有，而是看谁在什么时间、从哪台机器、用什么方式登进来。默认的 auth.log 或 secure 里混着大量正常信息，直接 grep 很容易漏掉横向移动痕迹。
实操建议：
- 优先查
lastlog -u username看每个用户最后登录时间，比翻日志快得多； - 用
journalctl -u sshd --since "2 hours ago" | grep -E "(Accepted|Failed|Invalid)"聚焦近期认证事件； - 注意
Failed password后紧跟着的Connection closed—— 这往往是暴力破解后断连，不是误输； - 如果启用了
PAM模块（如pam_faillock.so），要同步检查/var/log/faillog，它记录的是被锁账户而非单次失败。
SSH 服务必须关掉哪些默认配置才不算裸奔
默认 SSH 配置对生产环境就是高危状态，尤其 PermitRootLogin yes 和 PasswordAuthentication yes 这两项，等于把钥匙挂在门把手上。
实操建议：
- 禁用 root 远程登录：把
/etc/ssh/sshd_config中的PermitRootLogin改成no，不是without-password—— 后者仍允许密钥登录 root，风险没实质降低； - 强制密钥认证：设
PasswordAuthentication no，但改完必须先用另一终端验证新密钥能登进去，否则可能锁死； - 限制可登录用户：加
AllowUsers deploy@192.168.1.* alice@10.0.0.*，比靠防火墙更早拦截； - 别忽略
UsePAM yes的影响：它会让sshd绕过部分配置项（比如MaxAuthTries），若不用 PAM 认证链，建议设为no并自行配MaxAuthTries 3。
auditd 规则写不对，等于没开审计
很多人开了 auditd 却查不到关键操作，问题常出在规则粒度太粗或路径没覆盖符号链接目标。比如只监控 /etc/passwd，但攻击者用 ln -sf /tmp/hack /etc/passwd 再改，就完全绕过。
实操建议：
- 用
-w监控文件时，加-p wa（写 + 属性变更），否则改权限或属主不会触发； - 关键路径要用
-F path=显式指定，例如aureport -f -i | grep passwd查到实际访问路径后，再写规则，避免监控软链源而漏掉目标； - 慎用
-a always,exit -F arch=b64 -S execve全局抓命令执行——性能损耗大，且日志爆炸，应限定用户或目录，比如加-F uid>=1000； -
auditctl -s查当前规则是否生效，ausearch -m SYSCALL -ts recent测试规则是否真捕获到动作，别只信配置文件写了。
sudo 日志为什么总看不到真实执行命令
默认 sudo 只记“谁执行了 sudo”，不记“执行了什么命令”，尤其遇到 sudo su - 或 sudo bash 这种提权进 shell 的情况，后续所有操作都变成普通用户行为，审计链就断了。
实操建议：
- 在
/etc/sudoers里加Defaults log_output和Defaults iolog_dir=/var/log/sudo-io，开启命令输入输出记录； - 启用
Defaults syslog=local1并在/etc/rsyslog.conf中配local1.* /var/log/sudo.log，避免日志混进messages里难排查； - 禁止无限制的
ALL=(ALL) ALL，改用ALL=(root) /usr/bin/systemctl, /bin/journalctl这类白名单，减少提权后自由度； - 注意
sudo -i和sudo su -的区别：前者走sudoers日志，后者绕过——所以策略里要显式拒绝su命令本身。
真正难的不是加规则，是让每条审计日志都能反向定位到具体人、具体终端、具体时间点。比如 auditd 记了 execve，但没关 pty 日志，就不知道是谁在哪个 tmux pane 里敲的；sudo 记了命令，但没配 log_output，就不知道参数是不是带了 --no-pager 绕过审计。这些断点一多，加固就只剩心理安慰。
