Linux 服务安全加固实战

必须严格限制服务端口、禁用ssh密码登录、降权运行服务并实时监控日志。具体包括：仅开放必需端口，绑定127.0.0.1或配合防火墙；ssh强制密钥认证、禁用root密码登录；服务以非root用户运行；日志推送远程并用fail2ban联动防护。

服务端口只开必需的，别信“默认安全” linux 上跑的服务，只要端口暴露在公网或内网可访问范围内，就等于把钥匙挂在门把手上。很多运维习惯性装完 nginx、sshd、mysql 就直接启动，没关掉不需要的监听地址和端口。

• sshd 默认监听所有接口（0.0.0.0:22），如果服务器有公网 IP，又没配防火墙，暴力爆破日志每天几百条是常态
• mysql 默认绑定 127.0.0.1 是对的，但有人手动改 bind-address = 0.0.0.0 还忘了加 skip-networking 或防火墙规则
• redis 默认无密码、监听全网？那基本等于送数据库给扫到的人

实操建议：

• 用 ss -tlnp 或 netstat -tlnp 每次部署后立刻检查监听列表，重点关注非 127.0.0.1 的行
• 修改服务配置前先查文档确认绑定参数名：比如 nginx 是 listen 指令，postgresql 是 listen_addresses，redis 是 bind
• 配合 ufw 或 iptables 做二次过滤，别只依赖服务自身配置

SSH 登录必须禁用密码，强制密钥+必要限制PermitRootLogin yes + PasswordAuthentication yes 是生产环境最常见也最危险的组合。不是“我密码够长就没事”，而是攻击者根本不用猜——他们批量尝试 root + 弱口令，成功率远超你想象。

常见错误现象：

• 改了 /etc/ssh/sshd_config 但忘记 systemctl restart sshd，配置实际没生效
• 本地私钥权限是 -rw-rw-rw-，OpenSSH 拒绝加载，报错 Permissions are too open
• 同时开了 PubkeyAuthentication yes 和 PasswordAuthentication yes，等于密钥是锦上添花，密码仍是后门

实操建议：

• 新建普通用户 + sudo 权限，禁用 root 密码登录（PermitRootLogin prohibit-password 或 no）
• 生成密钥用 ssh-keygen -t ed25519，私钥存本地设为 chmod 600
• 加上 MaxAuthTries 3 和 ClientAliveInterval 300 减少暴力尝试窗口
• 测试新配置时，永远保留一个已登录的 root shell，别直接断开再连

服务进程不跑 root，能降权绝不硬扛 很多服务默认以 root 身份启动（比如早期 nginx 主进程、redis、甚至某些 Python Web 服务），一旦被利用，攻击者直接拿到最高权限。

为什么不能忍：“它自己会 drop 权限”？

• 不是所有服务都实现得靠谱，比如旧版 redis 在 daemonize yes 下仍可能残留 root 进程
• 即使主进程降权，子进程或临时文件创建路径不对，依然可能写入 /root 或覆盖系统文件
• 容器外部署时，systemd 的 User=/Group= 比服务内配置更可控

实操建议：

• 查服务文档确认是否支持非 root 运行：如 nginx 看 user 指令，postgresql 初始化必须指定 -U 用户
• 用 systemd 托管时，在 service 文件里明确写：User=www-data、Group=www-data、NoNewPrivileges=yes
• 检查进程真实 UID：ps aux | grep nginx 看 worker 进程是不是还挂着 root
• 静态文件目录（如 /var/www）权限设为 750，属主是服务用户，别整个 777 图省事

日志和失败登录必须实时盯，别等被黑了翻记录/var/log/auth.log 里每分钟几十条 Failed password for root from ... 不是“正常扫描”，是明确告诉你：有人正试图进来，而且你的防护可能漏了。

容易被忽略的点：

• rsyslog 默认不转发远程日志，所有日志都在本地磁盘，一旦服务器被控，日志可被清空
• fail2ban 规则没匹配到真实日志格式（比如用了 journalctl 输出而非 /var/log/auth.log），等于摆设
• sshd 的 LogLevel VERBOSE 开太多，日志爆炸；开太低（INFO）又看不到关键字段如源 IP、认证方式

实操建议：

• 把 auth.log 和 syslog 推到远程日志服务器（哪怕只是另一台内网小 VPS），用 rsyslog 的 action(type="omfwd" 配置
• fail2ban 启动后用 fail2ban-client status sshd 确认 jail 是否 running，再看 journalctl -u fail2ban 有没有解析失败报错
• 对高频失败 IP，与其靠 fail2ban 封，不如直接在 iptables 里 -j DROP 一批段（比如 116.255.224.0/19），减少内核层开销

该关的端口早关，该降的权限早降，该转的日志早转——这些动作本身不难，难的是每次上线新服务时都条件反射做一遍，而不是想着“下次再加固”。