第2章操作系统基线（Linux）

2. 操作系统基线（Linux）：账号与口令策略、SSH安全配置、文件权限管理、日志审计配置

聊到Linux基线，我脑子里第一个蹦出来的词就是「裸奔」。很多团队拿到一台新服务器，SSH默认端口、root直接登录、密码永不过期……这哪是服务器，分明是给黑客留的后门。今天我把这块掰开揉碎了讲，全是实战里淌过的坑。

核心思路：Linux基线说白了就四件事——管住谁进来（账号口令）、锁死怎么进（SSH）、看好文件谁动过（权限）、留下证据（日志）。缺一个，安全就是纸糊的。

2.1 账号与口令策略

账号管理是基线的第一道门。我见过最离谱的案例，某公司服务器上躺着十几个离职员工的账号，密码还是「123456」。嗯，你不清理，黑客就帮你清理。

2.1.1 账号清理与最小权限

禁用或删除无用账号：userdel -r username，别手软。
检查UID为0的非root账号：awk -F: '($3 == 0) {print $1}' /etc/passwd。正常情况下只有root。
锁定长期不用的账号：usermod -L username。

我的习惯：每季度跑一次账号审计脚本，把超过90天未登录的账号自动锁定。别等人走了半年才发现他还能ssh进来。

2.1.2 口令复杂度与过期策略

口令策略别光靠嘴说，得写到系统配置里。修改 /etc/login.defs 和 /etc/pam.d/system-auth：

# /etc/login.defs 关键参数
PASS_MAX_DAYS   90      # 密码最长使用90天
PASS_MIN_DAYS   7       # 密码最短使用7天（防循环修改）
PASS_MIN_LEN    12      # 密码最小长度
PASS_WARN_AGE   7       # 过期前7天提醒

光改这个还不够。PAM模块才是硬约束：

# /etc/pam.d/system-auth 添加
password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
# 要求包含大小写、数字、特殊字符，长度不低于12位
minlen=12 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1

我曾经踩过的坑：有次只改了login.defs没动PAM，结果用户照样设「Password1!」这种弱口令。记住，PAM才是最终执行者，login.defs只是建议值。

2.2 SSH安全配置

SSH是Linux的命门。你想想看，全世界有多少扫描器在24小时扫22端口？我自己的蜜罐统计，一台公网服务器平均每小时被扫200多次。

2.2.1 核心加固项

编辑 /etc/ssh/sshd_config，以下配置我建议直接照抄：

# 端口改成高位端口，比如 10022
Port 10022

# 禁止root直接登录
PermitRootLogin no

# 仅允许密钥登录
PasswordAuthentication no
PubkeyAuthentication yes

# 限制登录用户白名单
AllowUsers opsadmin devadmin

# 空闲超时断开（300秒无操作）
ClientAliveInterval 300
ClientAliveCountMax 0

# 使用SSH协议版本2
Protocol 2

为什么改端口？虽然不能防住定向攻击，但能过滤掉99%的自动化扫描脚本。我管这叫「降低攻击面噪音」。

2.2.2 密钥管理与轮换

使用ED25519算法生成密钥对：ssh-keygen -t ed25519 -a 100。比RSA更安全、性能更好。
私钥设置密码保护（passphrase），别裸存。
每半年轮换一次密钥，旧密钥从 ~/.ssh/authorized_keys 中移除。

我个人习惯：在CI/CD流程里集成密钥审计脚本，自动检查authorized_keys中是否有过期或未知公钥。一旦发现，直接告警到钉钉群。

2.3 文件权限管理

文件权限这块，说白了就是「不该看的不让看，不该改的不让改」。Linux权限模型其实很清晰，但很多人栽在SUID和粘滞位上。

2.3.1 关键文件权限基线

文件/目录	建议权限	说明
/etc/passwd	644	所有用户可读，仅root可写
/etc/shadow	600 或 640	仅root可读写，禁止普通用户访问
/etc/ssh/sshd_config	600	仅root可读写
/var/log	750	仅root和adm组可访问
/tmp	1777	粘滞位，防互相删文件

2.3.2 SUID/SGID排查

SUID是权限管理的「定时炸弹」。一个设置了SUID的普通程序，运行时却拥有root权限。我建议定期扫描：

# 查找所有SUID文件
find / -perm -4000 -type f 2>/dev/null

# 查找所有SGID文件
find / -perm -2000 -type f 2>/dev/null

我曾经处理过的事故：某开发为了方便，给一个脚本设了SUID。结果被黑客利用提权，直接拿下root。从那以后，我要求所有SUID文件必须走审批流程，且数量控制在10个以内。

2.4 日志审计配置

日志是事后追溯的唯一凭证。没有日志，安全事件就是无头冤案。我常说一句话：「没日志 = 没发生」。

2.4.1 rsyslog核心配置

确保 /etc/rsyslog.conf 或 /etc/rsyslog.d/ 下包含以下关键日志：

# 认证日志（SSH登录、sudo操作）
auth,authpriv.*                 /var/log/auth.log

# 系统日志（内核、服务启停）
*.info;mail.none;authpriv.none;cron.none   /var/log/messages

# 计划任务日志
cron.*                          /var/log/cron.log

# 所有紧急事件同时发送到控制台
*.emerg                         :omusrmsg:*

2.4.2 日志轮转与保留策略

日志不能无限增长，否则磁盘会爆。配置 /etc/logrotate.conf：

/var/log/auth.log {
    weekly          # 每周轮转
    rotate 12       # 保留12周（约3个月）
    compress        # 压缩旧日志
    delaycompress   # 延迟一周压缩
    missingok       # 文件不存在不报错
    notifempty      # 空文件不轮转
}

我的建议：核心日志（auth.log、secure）至少保留180天。如果合规要求严，比如等保三级，得保留6个月以上。另外，日志一定要异地备份，别等服务器被删库了才后悔。

2.4.3 auditd审计框架

对于关键操作，rsyslog不够细。用auditd可以监控特定文件或系统调用：

# 安装auditd
yum install audit -y
systemctl enable auditd

# 监控/etc/shadow的写操作
auditctl -w /etc/shadow -p wa -k shadow_watch

# 查看审计日志
ausearch -k shadow_watch

实战经验：我曾在某次应急响应中，靠auditd日志精确还原了攻击者修改shadow文件的时间、进程ID和源IP。没有auditd，那案子根本破不了。

知识体系总览

下面这张图，是我梳理的Linux基线核心逻辑。你可以把它当成检查清单：

好了，Linux基线的四个核心模块就这些。说白了，每一条配置背后都是血淋淋的教训。别嫌麻烦，把这些落地了，你的服务器至少能挡住80%的常见攻击。

📚 课程目录

2. 操作系统基线（Linux）：账号与口令策略、SSH安全配置、文件权限管理、日志审计配置

2.1 账号与口令策略

2.1.1 账号清理与最小权限

2.1.2 口令复杂度与过期策略

2.2 SSH安全配置

2.2.1 核心加固项

2.2.2 密钥管理与轮换

2.3 文件权限管理

2.3.1 关键文件权限基线

2.3.2 SUID/SGID排查

2.4 日志审计配置

2.4.1 rsyslog核心配置

2.4.2 日志轮转与保留策略

2.4.3 auditd审计框架

知识体系总览