你刚开了一台云服务器，默认只开了 SSH 22 端口、允许 root 密码登录、防火墙没启用——对攻击者来说，这几乎是一张"邀请函"。
互联网上每分钟都有大量僵尸网络在扫描 22 端口、尝试弱口令、撞库，一旦成功就植入挖矿木马、勒索病毒，甚至把你的服务器当"跳板"去攻击别人。
很多运维的安全策略停留在"改个 SSH 端口"“装个杀毒软件”，但这远远不够。
这篇文章，基于真实攻防视角，把SSH、用户权限、防火墙、审计监控四个维度的纵深防御一次讲透，并附一套Ubuntu 22.04 从零加固的完整流程——跟着做，你的服务器就"硬"起来了。
红线先行：本文所有加固与检测操作，只用于你拥有权限的服务器/自建环境——没授权，再小也是违法。
为什么你的服务器"上线即被攻击"？
一台公网服务器从开机那一刻起就进入"被扫描"状态。据多家威胁情报平台统计，暴露 22 端口的云主机，平均几分钟内就会收到第一次 SSH 暴力破解尝试。
攻击者通常用 Masscan、ZMap 批量扫端口，再用 Hydra、Medusa、Ncrack 加载弱口令字典撞库——字典里不仅有root/123456这种组合，还有大量历史泄露的"用户名+密码"对。更危险的是，他们会利用已知漏洞、错误的authorized_keys、未授权访问的 Redis/MongoDB/Docker API 作为入口，再通过 SSH 密钥、历史命令、云元数据服务做横向移动。
默认配置的风险，归纳起来就四类：
| 风险 | 具体表现 |
|---|---|
| ①入口暴露 | SSH 22 端口对全网开放，root 允许密码登录 |
| ②权限过大 | 所有人共享 root，服务账户可交互登录 |
| ③网络暴露 | 防火墙没启用，安全组放行全部端口 |
| ④审计缺失 | 没有日志监控，入侵后无法追溯 |
所以：安全加固不是"装一个软件"，而是围绕四个维度建纵深防御。
第一维度：SSH——入口即攻击面
SSH 是服务器最重要的管理通道，也是最大的攻击面。
为什么公钥认证比密码安全？
- 密码认证依赖"共享秘密"，容易被暴力破解、撞库
- 公钥认证基于非对称加密，私钥永不传输，安全性高得多
核心配置（写入/etc/ssh/sshd_config.d/99-hardening.conf）：
Protocol 2 PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes PermitEmptyPasswords no MaxAuthTries 3 LoginGraceTime 30 ClientAliveInterval 300 ClientAliveCountMax 2 AllowUsers ops deploy AllowGroups ssh-users KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com UseDNS no X11Forwarding no AllowAgentForwarding no AllowTcpForwarding no关键点解读：
PermitRootLogin no：禁止 root 直接登录，必须走普通用户+sudoPasswordAuthentication no：关闭密码登录，只留密钥（防暴力破解）AllowUsers/AllowGroups：白名单，只放行运维账号AllowTcpForwarding no：默认禁隧道；业务需要跳板时用Match块精细化放行：
Match User deploy AllowTcpForwarding yes PermitOpen db.internal:3306authorized_keys 还能"限能力"：
# 只允许来自指定IP + 只能执行指定命令 from="203.0.113.10" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... ops@example command="/usr/local/bin/backup.sh",no-port-forwarding,no-pty ssh-rsa AAAAB3... backup@exampleFail2ban 动态封禁：解析 SSH 日志，失败超阈值就封 IP。它不能替代密钥认证，但能大幅降低爆破成功率、减少日志噪音。日志在/var/log/auth.log（Ubuntu）或/var/log/secure（CentOS），也可用journalctl -u ssh。
安全验证顺序（避免把自己锁在门外）：
- 保留一个已登录的 SSH 会话不要退出
- 新开终端
sshd -t检查语法 →systemctl reload sshd - 确认新会话能登录，再关旧会话
- 用了
AllowUsers要确认自己在白名单内；云服务器提前在控制台 VNC 确认能登录
常见问题：改端口为什么还会被扫？
改端口只是"降噪"，针对性攻击仍能全端口扫到。真正的安全是：SSH 只对 VPN/公司出口 IP 开放，公网不暴露 22 端口。
第二维度：用户权限——最小化与职责分离
禁掉 root 远程登录后，必须建立普通运维用户，通过 sudo 精细授权，所有操作可审计、可追溯。
关键原则：
- 每个运维人员独立账号，禁止共享
- sudo 规则写
/etc/sudoers.d/，用visudo -cf校验 - 服务账户用
/usr/sbin/nologin，禁止交互登录 - 关键文件权限最小化：
/etc/shadow000/640、~/.ssh700、authorized_keys600 pam_faillock锁定多次失败账户- 限制
su到 root，只允许 wheel 组
sudo 规则示例（/etc/sudoers.d/ops）：
Defaults:ops env_reset, timestamp_timeout=5, log_input, log_output ops ALL=(ALL:ALL) ALL deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx %wheel ALL=(ALL:ALL) ALL解读：ops全权；deploy只能免密重启/查看 nginx（适合自动化部署）；log_input, log_output记录 sudo 会话输入输出，方便审计。改完必须visudo -cf /etc/sudoers校验。
PAM 账户锁定（Ubuntu 的/etc/pam.d/common-auth与common-account）：
auth required pam_faillock.so preauth silent deny=5 unlock_time=900 auth [success=1 default=ignore] pam_unix.so nullok auth [default=die] pam_faillock.so authfail deny=5 unlock_time=900 auth sufficient pam_faillock.so authsucc deny=5 unlock_time=900 account required pam_faillock.so文件权限与异常账户排查：
# 检查关键文件权限 stat -c "%a %n" /etc/shadow /etc/ssh/sshd_config # 查找 SUID/SGID 文件 find / -perm -4000 -o -perm -2000 -type f 2>/dev/null # 查找 UID 为 0 的账户（后门特征） awk -F: '($3 == 0) {print $1}' /etc/passwd # 查找可登录 shell 的账户 awk -F: '($7 !~ /(nologin|false)$/) {print $1, $7}' /etc/passwd # 查找空密码账户 awk -F: '($2 == "") {print $1}' /etc/shadow # 检查所有 authorized_keys find / -name authorized_keys -type f 2>/dev/null -exec cat {} \;发现 UID 0 的非 root 账户、空密码账户、陌生公钥——立即隔离主机、取证。
密码策略（chage+pam_pwquality）：密码最长 90 天、最短 1 天、到期前 7 天提醒；/etc/security/pwquality.conf设minlen=12、大小写+数字+符号混合。真正的安全仍应依赖密钥认证 + 多因素认证。
常见问题：禁了 root，自动化任务怎么办？
别重新开 root SSH。给自动化任务建专用账户，sudo 只授权特定命令 + 密钥用command=/from=限能力——即使密钥泄露，也拿不到完整 root shell。
第三维度：防火墙——默认拒绝与网络隔离
主机防火墙遵循**“默认拒绝入站，允许出站”，只开放必要端口，尽量限制源 IP。云环境有安全组 + 主机防火墙**两层，都要配。
一个关键坑：Docker 会直接操作 iptables 的 NAT 表，可能绕过 ufw 规则——容器映射端口会直接暴露，必须用DOCKER-USER链处理。
UFW 典型配置：
# 默认策略：拒绝入站，允许出站 sudo ufw default deny incoming sudo ufw default allow outgoing # SSH 限制源 IP（只放行公司网段） sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp # HTTP/HTTPS sudo ufw allow 80/tcp sudo ufw allow 443/tcp # 启用 sudo ufw enable sudo ufw status verbose避免把自己关在防火墙外（稳妥顺序）：
# 1. 先放行当前管理 IP sudo ufw allow from $(echo $SSH_CLIENT | awk '{print $1}') to any port 22 proto tcp # 2. 再设默认拒绝 sudo ufw default deny incoming sudo ufw default allow outgoing # 3. 最后启用 sudo ufw enableDocker 端口绕过处理（只允许特定网段访问容器 8080）：
sudo iptables -I DOCKER-USER -p tcp --dport 8080 ! -s 203.0.113.0/24 -j DROP # 保存规则（否则重启失效） sudo apt install iptables-persistent sudo netfilter-persistent save定期检查监听端口：ss -tulnp、lsof -i -P -n | grep LISTEN——只留必要服务。数据库、Redis、Docker API严禁直接暴露公网，走内网/VPN/SSH 隧道/反向代理。
安全组与主机防火墙是"与"关系：安全组拒绝的流量根本到不了主机；安全组允许但主机拒绝的也会被丢。两层都要放行必要流量。
第四维度：审计与持续监控
没有审计的加固是不完整的。
auditd 监控关键文件：
# 安装并启用 sudo apt install auditd audispd-plugins sudo systemctl enable --now auditd # 监控关键文件写入和属性变更 sudo auditctl -w /etc/passwd -p wa -k identity sudo auditctl -w /etc/shadow -p wa -k identity sudo auditctl -w /etc/sudoers -p wa -k sudoers sudo auditctl -w /etc/ssh/sshd_config -p wa -k sshd # 监控特权命令执行 sudo auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k rootcmd # 持久化：写入 /etc/audit/rules.d/hardening.rules 后 augenrules --load查询审计日志：
sudo ausearch -k identity -ts recent sudo aureport --summaryAIDE 文件完整性监控：为关键文件建哈希基线，之后aide --check发现非预期变更。首次初始化后把数据库存到只读介质或远程服务器，防攻击者篡改。
日常入侵排查清单：
ss -tulnp # 网络连接与监听端口 ps auxf # 异常进程 crontab -l && ls -la /etc/cron.* # 计划任务 last -a && lastb -a # 最近登录/失败登录 systemctl list-units --type=service --state=running lsmod # 内核模块发现异常优先隔离主机（断网或改安全组），保留现场再取证——不要直接重启，内存里的恶意进程和临时文件会丢。
集中日志（防"痕迹被清理"）：攻击者常rm -rf /var/log/*清痕。用 rsyslog 实时转发到远程日志服务器，或部署 Wazuh/ELK；关键日志加不可变属性chattr +a /var/log/auth.log（防删防改，配合 logrotatecopytruncate）。
auditd 性能：只监控关键文件写入和特权命令执行，开销很小；别监控所有execve，并按-k标签分类、配置日志轮转（max_log_file=50）。
实战：Ubuntu 22.04 从零加固完整流程
假设你已通过云控制台/初始密码登录，拥有 root 权限：
步骤1：更新系统 + 装基础工具
sudo apt update && sudo apt upgrade -y sudo apt install -y vim curl wget git ufw fail2ban auditd aide步骤2：创建运维用户 + 配 SSH 密钥
# 本地生成密钥 ssh-keygen -t ed25519 -a 100 -C "ops@example" # 上传公钥 ssh-copy-id -i ~/.ssh/id_ed25519.pub ops@server_ip # 服务器上建用户并加入 sudo 组 sudo adduser ops sudo usermod -aG sudo ops sudo mkdir -p /home/ops/.ssh && sudo chmod 700 /home/ops/.ssh sudo cp /root/.ssh/authorized_keys /home/ops/.ssh/authorized_keys sudo chown -R ops:ops /home/ops/.ssh && sudo chmod 600 /home/ops/.ssh/authorized_keys步骤3：修改 SSH 配置
sudo vim /etc/ssh/sshd_config.d/99-hardening.conf # 写入第一维度的配置 sudo sshd -t && sudo systemctl reload sshd # 校验语法 + 重载步骤4：配置 sudo 与 PAM
sudo visudo -f /etc/sudoers.d/ops # 写入第二维度的规则 # 配置 pam_faillock 账户锁定步骤5：启用防火墙
sudo ufw allow from $(echo $SSH_CLIENT | awk '{print $1}') to any port 22 proto tcp sudo ufw default deny incoming && sudo ufw default allow outgoing sudo ufw allow 80/tcp && sudo ufw allow 443/tcp sudo ufw enable步骤6：部署 Fail2ban
sudo systemctl enable --now fail2ban # 检查状态：fail2ban-client status sshd步骤7：配置审计与文件完整性
sudo auditctl -w /etc/passwd -p wa -k identity # 按第四维度加规则 sudo aideinit && sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db步骤8：收尾检查
ss -tulnp # 确认监听端口 sudo ufw status verbose # 确认防火墙 lastb -a | head # 看失败登录 sudo ausearch -k identity -ts recent # 看审计日志走完这 8 步，你的 Ubuntu 服务器就从"敞开的门"变成了"有门禁、有监控、有审计"的堡垒。
🎉恭喜你！Linux 安全加固"上手"达成
如果学到这里，你已经具备服务器安全加固的实战能力，可以从事：
- 安全运维工程师
- 系统安全工程师
- 运维/安全双技能岗位
薪资区间：8k-20k，而且"运维+安全"复合技能越来越抢手。
这条路，大概需要 1-2 个月的系统投入。
那么，你还想继续进阶吗？
Linux 服务器加固，是运维和网安的交集点：
需求刚性、上手快、转岗友好——但自学容易踩坑：改错 SSH 把自己锁在门外、防火墙规则写错放行全部端口、审计没配等于白加固。
如果你想系统学习网络安全、从服务器加固开始打牢基础：
- Linux 安全加固全体系课程（SSH→权限→防火墙→审计）
- 实操环境带练（授权环境，练到会）
- 入侵排查与应急专题（日志溯源、事件处置）
- 就业指导（安全运维岗，作品+简历+规划）
想系统学习网络安全、拿下服务器加固的，评论区扣"1"，或私信老师咨询课程详情。
特别声明
此教程为纯技术分享！本文目的绝不是为怀有不良动机的人提供技术支持！也不承担因为技术被滥用所产生的连带责任！本文所有加固、检测与排查操作，只允许在你拥有权限的服务器、自建环境或授权环境中进行，目的是唤醒大家对网络安全的重视，采取相应的安全措施，减少因网络安全带来的经济损失！
