先说一个实话跟安全沾边的东西平时没人在意等真出事的时候基本都是大事。我之前接手过一台被矿机脚本打穿的 Ubuntu 服务器CPU 直接拉满跑业务的进程被 kill 一空。排查后才发现问题特别低级——22 端口裸奔、root 密码是八位纯字母、防火墙压根没开、系统补丁几个月没打。那台机器的遭遇其实代表了大多数中小业务的真实状态不是不想做安全而是不知道从哪里入手。安全加固不是装一个杀毒软件就完事它是一整套从账户、网络、系统配置到监控审计的操作体系。这篇文章我按照自己这几年运维 Ubuntu 服务器的实际操作习惯整理出 20 条加固方案按五个层面排好账户与登录入口、网络暴露面收敛、系统纵深防御、检测审计、备份与应急恢复。每条都给出可以直接抄的命令和配置适合刚入手第一台 Ubuntu 服务器的小白也适合想系统性梳理一遍安全基线的老手。1. 账户体系与登录入口先管住谁能进你的机器1.1 root 账户必须隐身后台第 1 条禁止 root 直接远程登录。Ubuntu 装完系统后sshd 默认配置里PermitRootLogin是prohibit-password意思是 root 可以通过密钥登录但如果你给 root 设置过密码也能用密码登录。很多人图省事装完系统直接就把 root 密码设成常用密码然后开始远程操作。攻击者拿到你的 IP第一件事就是用 root 加字典暴力破解一旦中招就是最高权限后面所有加固措施全白搭。在/etc/ssh/sshd_config里改这一行PermitRootLogin no如果你确实有必须在 root 下操作的场景可以考虑prohibit-password保留密钥登录但我的建议是直接改成no从根上断掉这条路径。改完后验证一下配置再重启服务sshd -t systemctl restart ssh这里有个排错经验要提醒sshd -t只能帮你检查语法不能保证你改完能连上。重启 sshd 之前一定要另开一个 SSH 会话测试避免把自己锁在门外。1.2 日常操作一律走 sudo 用户第 2 条创建一个普通用户加入 sudo 组日常所有操作都用这个用户。不要因为嫌麻烦就一直用 root。普通用户加 sudo 的好处不只是安全还有一个容易被忽略的点审计。用 root 操作日志里只显示 root用普通用户加 sudo/var/log/auth.log里能看到是谁在什么时间执行了特权命令出问题的时候可以定位到人。创建用户很简单adduser ops usermod -aG sudo opsadduser会自动创建家目录、设置密码比useradd顺手得多这也是 Ubuntu 系和 CentOS 系习惯上的差别。建议再顺手配一下 sudo 的密码有效期避免一次输入 sudo 密码后长时间免密执行sudo visudo在文件里加一行Defaults:ops timestamp_timeout5这个值表示 sudo 记住密码的时间是 5 分钟超时要重新输入。对共享运维账号来说这个配置很实用。1.3 SSH 登录改为密钥认证第 3 条在自己的电脑上生成 ed25519 密钥对把公钥放到服务器上然后关掉密码登录。这应该在 Ubuntu 服务器加固里优先级最高的一条没有之一。密码认证最大的问题不是密码强度不够而是它给了所有攻击者一个持续尝试的机会。密钥认证基于非对称加密私钥不出本地机器远程爆破基本行不通。本地生成密钥ssh-keygen -t ed25519 -a 100ed25519是目前 SSH 密钥里推荐的做法比 RSA 短安全性足够-a 100是 KDF 迭代次数数值越大私钥暴力破解越难。把公钥推上服务器ssh-copy-id opsyour_server_ip -p 22然后修改 sshd 配置PasswordAuthentication no ChallengeResponseAuthentication no UsePAM no改完重启 sshd确认密钥能正常登录之后再关闭密码。千万记住先开着密码验证用第二个 SSH 会话测试密钥登录成功后再关密码顺序反了就要跑机房了。1.4 密码口令策略与登录失败锁定第 4 条给系统用户设置密码复杂度和有效期同时加上登录失败锁定。/etc/login.defs里可以设置几项默认策略PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_MIN_LEN 12意思是密码最长使用 90 天必须改最短使用 7 天防止用户频繁改回旧密码最小长度 12 位。真正起作用的复杂度策略在 PAM 里安装 libpam-pwqualityapt install libpam-pwquality然后在/etc/pam.d/common-password里找到pam_pwquality.so那一行加上retry3 minlen12 ucredit-1 lcredit-1 dcredit-1 ocredit-1表示至少 12 位必须包含大写字母、小写字母、数字、特殊字符。登录失败锁定用 pam_faillock。在/etc/pam.d/common-auth文件最前面插入两段配置auth required pam_faillock.so preauth audit silent deny5 unlock_time300 auth [defaultdie] pam_faillock.so authfail audit deny5 unlock_time300再在/etc/pam.d/common-account最前面加一段account required pam_faillock.so意思是连续失败 5 次锁 300 秒。我建议把 root 排除在锁定之外防止攻击者故意把 root 锁掉导致运维进不去。在 preauth 那一行加even_deny_root你可能还要考虑 root 在 1.1 里已经禁止登录了锁不锁其实无所谓但稳妥起见还是在 failock 文件配置里排除PAM 配置改错了很容易导致所有登录失效一定是种常见翻车现场。我自己的习惯是永远保留一个已经登录的 SSH 会话改完配置不要马上测试新连接先把语法检查好再小范围验证。2. 网络暴露面收敛让扫描器扫完就想放弃2.1 变更 SSH 默认端口第 5 条把 SSH 从 22 端口挪走改成高位端口。这条和上面的密钥认证配合起来效果最好。改端口的主要目的不是为了防住真正的攻击者——他们用端口扫描器几秒钟就能发现新端口——而是为了减少大量无差别扫描器的噪音。我在生产环境统计过22 端口开放的机器一天能收到几千条Failed password日志改成高位端口后瞬间降到个位数。修改/etc/ssh/sshd_configPort 60231推荐用 1024 以上的高位端口避免和常见服务冲突。记得更新防火墙规则把新端口放行不然下一秒你就连不上服务器了。重要改完 SSH 端口后立刻用新端口连接测试确认通了再退出当前会话。这个操作和改密钥认证一样顺序一颠倒就会把自己锁在门外。2.2 UFW 默认拒绝所有入站流量第 6 条开启 UFW 防火墙默认策略设成拒绝入站。Ubuntu 自带的 UFW 是 iptables 的前端封装对不熟悉防火墙的人来说是最容易上手的选择。核心思路是白名单模式默认拒绝所有进来的连接只放行明确需要的端口。ufw default deny incoming ufw default allow outgoing ufw allow 60231/tcp ufw allow 80/tcp ufw allow 443/tcp ufw enable执行完可以看到规则列表。注意ufw enable之后要确认 SSH 端口已经放行否则当前连接会直接断掉。我习惯把 UFW 视为第一层过滤云平台的安全组是第二层。两道防火墙配置相同规则不冲突反而多一层保险。但要注意两层防火墙的规则可能会让你排查问题时产生混乱——连不上时先确认安全组再确认 UFW别绕圈。2.3 限制管理来源 IP第 7 条如果管理和运维入口的 IP 基本固定直接在防火墙层面对 SSH 做来源限制。比如办公室出口 IP 是203.0.113.10那就只允许这个 IP 访问 SSHufw allow from 203.0.113.10 to any port 60231 proto tcp这个配置比 fail2ban 更硬核IP 都不对根本摸不到你的 SSH 服务。但它的前提是你的 IP 真的固定如果家里宽带是动态 IP或者你经常出差换网络这个方案会让自己很难受。IP 来源限制建议结合云平台安全组来做。像阿里云、腾讯云、AWS 上直接在 VPC 安全组里只放行固定 IP 到 SSH 端口服务器本地的 UFW 都不用额外配置。2.4 业务服务和管理面分离第 8 条数据库、缓存、消息队列这类服务绝对不要绑定0.0.0.0。很多人装完 MySQL、Redis 之后直接默认配置启动服务监听了所有网卡接口。如果云平台安全组没挡住 3306、6379 端口Redis 未授权访问、MySQL 被爆破就是分分钟的事。检查本机服务监听情况ss -lntup看到类似0.0.0.0:3306的输出就要警惕。MySQL 建议在配置文件里改成bind-address 127.0.0.1如果业务需要远程访问数据库也建议通过内网网段访问比如 private 网络的 IP 是10.0.0.1就写bind-address 10.0.0.1不要把公网 IP 绑上去。Redis 更要注意生产环境最好加protected-mode yes和requirepass并且只 listen 127.0.0.1。很多挖矿木马最喜欢扫 Redis 端口因为它的协议简单未授权访问就等于直接拿 shell。这个场景我见过太多了代价最少的一次是业务挂了一整天管理员在那里刷防火墙规则。3. 系统纵深防御补上那些看着不大爆了就完了的洞3.1 开启自动安全更新第 9 条启用 unattended-upgrades只自动安装安全补丁。很多服务器被攻破攻击者利用的漏洞其实已经发布了官方补丁但服务器一两个月没更新。Ubuntu 的自动更新机制默认会在安装更新时重启服务但这会让线上业务出现不可控的中断所以我们要做的是只开启安全更新来源其他包更新继续手动控制。安装并配置apt update apt install unattended-upgrades dpkg-reconfigure --prioritylow unattended-upgrades运行完 dpkg-reconfigure 之后会自动启用查看配置文件确认cat /etc/apt/apt.conf.d/50unattended-upgrades重点关注这几行确保 security 相关的 origin 被取消注释originUbuntu,archivejammy-security;自动更新会在凌晨随机时间执行对业务影响很小。个人建议在这里把自动清理不需要的依赖也打开避免长期使用/var空间被撑爆。3.2 关键文件权限与 SUID 排查第 10 条检查系统关键文件权限重点排查 SUID/SGID 文件。先看几个最核心的文件权限是否正常ls -l /etc/shadow /etc/passwd /etc/sudoers正常情况应该是/etc/shadow-rw-r-----root shadow640/etc/passwd-rw-r--r--644/etc/sudoers-r--r-----root root440如果权限被改宽了第一时间通过 chmod 改回。接下来排查涉嫌提权的 SUID 文件find / -perm -4000 -type f 2/dev/nullSUID 位的意思是普通用户执行这个文件时会以文件属主的身份运行。这是 Linux 提权的经典路径攻击者拿到普通用户权限后如果发现系统里有不正常的 SUID 文件就能直接提权到 root。排查时把系统内置的/usr/bin/sudo、/usr/bin/passwd等放行其他不认识的特别是/tmp、/var/tmp、/home目录下的 SUID 文件大概率有问题直接删除或用chmod u-s去掉 SUID 位。3.3 内核参数与安全模块加固第 11 条调整内核参数禁用不安全的网络行为并开启 AppArmor 强制模式。编辑/etc/sysctl.conf追加以下内容# 禁用 IP 源路由 net.ipv4.conf.all.accept_source_route 0 net.ipv4.conf.default.accept_source_route 0 # 禁用 ICMP 重定向 net.ipv4.conf.all.accept_redirects 0 net.ipv4.conf.default.accept_redirects 0 # 禁用发送重定向 net.ipv4.conf.all.send_redirects 0 # 启用 TCP SYN cookies防 SYN 洪泛 net.ipv4.tcp_syncookies 1 # 启用地址空间布局随机化 kernel.randomize_va_space 2 # 限制 dmesg 查看内核日志只有 root 可以 kernel.dmesg_restrict 1保存后执行sysctl -p关于禁 ping很多人喜欢把icmp_echo_ignore_all改成 1 来隐藏服务器我一般不会这样做。因为内网监控系统需要 ping 探活而且禁 ping 对真正的攻击者没用反而给运维排查增加麻烦。Ubuntu 自带 AppArmor 而不是 SELinux确认它是开启状态aa-status如果看到一堆enforce模式的 profile 列表说明正常的。Ubuntu 桌面版上有很多 profile 可能是 complain 模式但服务器上尽量保持 enforce。3.4 恶意软件与 Rootkit 扫描第 12 条安装 rkhunter 和 chkrootkit定期扫描 Rootkit 和已知恶意软件。Rootkit 是入侵之后用于隐藏踪迹的工具一旦被种下普通的 ps、netstat 都看不到异常。扫描工具的原理是基于已知特征和行为模式比对不能做到 100% 检出但有比没有强太多。apt install rkhunter chkrootkit rkhunter --update rkhunter --check --skip-keypress chkrootkitrkhunter 第一次扫描会看到很多 WARNING新手经常在这里被吓到。其实很多是误报比如 SSH 配置文件的 hash 和默认值不一致。正确的做法是确认过这些告警后用下面的命令标记为已知状态rkhunter --propupd之后再跑扫描就只关注新增的告警了。3.5 关闭不必要的服务与端口第 13 条把用不上的系统服务停掉甚至 mask 掉缩小攻击面。很多服务器装完系统跑着一堆和业务无关的东西。比如avahi-daemonmDNS 广播、cups打印服务、postfix邮件服务这些在 Web 服务器上大概率没什么用。攻击者如果通过某个服务拿到了 shell这些多余服务很容易成为横向移动的跳板。先看当前运行的服务systemctl list-units --typeservice --staterunning对照业务清单把不认识或不需要的服务逐个确认。比如systemctl stop cups systemctl disable cups systemctl mask cupsdisable只是取消开机自启mask更彻底会把它和启动请求都符号链接到/dev/null任何依赖它启动的操作都会失败。对确定没用的服务我建议直接 mask。4. 检测与审计安全防线被突破后还能第一时间发现4.1 日志体系与日志滚动第 14 条让系统日志持久化存储并配置日志轮转防止日志把磁盘写满。Ubuntu 服务器默认用 systemd-journald 记日志但日志默认只存在内存里重启就没了。把日志持久化到磁盘mkdir -p /var/log/journal systemctl restart systemd-journald这样/var/log/journal目录会开始积累日志。同时配置 logrotate让日志按周期轮转cat /etc/logrotate.d/syslog EOF /var/log/auth.log /var/log/syslog /var/log/kern.log { weekly rotate 4 compress missingok notifempty } EOF这里配置的是每周轮转一次保留 4 份压缩存储。对业务日志量大的服务器建议把频率改成daily不然磁盘被日志打满业务响应也会跟着出问题。日志的价值在排查问题时才能体现。有一次线上服务半夜报错就是这个/var/log/syslog里留着完整的上下文我才快速定位到是某个依赖模块触发了 OOM。没有日志一切排查都是盲猜。4.2 SSH 登录审计与暴力破解封禁第 15 条重点监控 SSH 登录日志做到实时发现异常登录来源。系统日志里最值得关注的是/var/log/auth.log里面记录了所有登录尝试。最基本的统计命令grep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -nr这个命令会按 IP 统计失败的 SSH 登录次数排在最前面的就是要重点关注的攻击源。如果某个 IP 出现了几十次失败记录说明它在对你做暴力破解。真正的劳动力解放靠 fail2ban。安装配置apt install fail2ban创建/etc/fail2ban/jail.local[sshd] enabled true port 60231 filter sshd logpath /var/log/auth.log maxretry 5 findtime 600 bantime 3600配置含义10 分钟内失败 5 次封禁 1 小时。我建议 bantime 不要设太长万一你自己多次输错密码被 ban 了等太久会很烦躁。后期可以根据攻击频率逐步加大。4.3 文件完整性监控第 16 条用 AIDE 对系统关键目录做文件完整性基线定期比对。入侵者往往会修改系统二进制文件或配置文件来维持权限文件完整性监控可以发现这些改动。AIDE 的思路是先为指定目录生成一个哈希基线库之后每次比对当前状态和基线库是否一致。安装初始化apt install aide aideinit第一次会把/etc、/usr/sbin、/bin等目录的指纹生成到/var/lib/aide/aide.db后面的比对命令aide.wrapper --check输出里所有新增、删除、修改的文件都会列出来。这个工具最大的坑是误报——你自己正常改了配置文件下次比对也会报差异。所以每次做完合法变更记得重新生成基线aideinit -y -f如果你管了很多台机器文件完整性监控更适合用 centralized 方案每台机器装 agent日志汇总到管理端统一告警。单机用 AIDE 解决不了告警无人看的问题这个度自己把握。4.4 定期排查开放端口与监听进程第 17 条把检查监听端口固化成周期性动作比网络层加固更主动。安全加固不是为了防住所有人而是让自己对服务器状态有感知。我把每台服务器每个月执行一次端口排查写成脚本输出所有监听端口对应的进程名和预期清单对比ss -lntup重点关注两类没有经过 UFW 放行的监听端口。服务器上出现这种情况通常是某个服务自己改了配置或者被入侵者留了后门。对公网网卡不是 127.0.0.1 或内网 IP开放的高位端口。这经常是攻击者种的远控木马在监听某个随机端口等待回连指令。排查时可以把输出重定向到文件然后比对上一次的结果ss -lntup /tmp/ports_now.txt diff /tmp/ports_before.txt /tmp/ports_now.txt多出来的端口就是需要重点调查的对象。5. 备份与应急恢复加固的最后一块拼图没有备份就谈不上安全5.1 核心数据自动备份第 18 条数据库、配置目录、上传文件必须有自动化备份并且备份要存到其他位置。前面 17 条都是在降低被攻破的概率但没有任何系统能保证 100% 不被攻破。一旦被勒索病毒加密或者自己的误操作删除了数据备份就是最后的救命稻草。先写一个实用的备份脚本放到/usr/local/bin/backup.sh#!/bin/bash BACKUP_DIR/backup/$(date %F) mkdir -p $BACKUP_DIR mysqldump --single-transaction -u backup_user -ppassword mydb | gzip $BACKUP_DIR/mydb.sql.gz tar czf $BACKUP_DIR/etc.tar.gz /etc find /backup -type f -mtime 7 -delete加执行权限再写进 crontabcrontab -e 0 2 * * * /usr/local/bin/backup.sh每天凌晨 2 点执行。这里的重点是把备份文件放到不是同一台机器的地方我一般用 rsync 再同步到内网另一台存储或者用 restic 加密后推到 S3 兼容对象存储。如果数据很重要异地备份是必须的光备份在同一台机器的其他目录磁盘一坏全完。5.2 恢复演练光备份不恢复等于没备份第 19 条每个季度至少做一次备份恢复演练确保备份数据真的能派上用场。这句话估计大家都听过但真正做过恢复演练的团队少得可怜。很多团队备份了三年从没恢复过第一次恢复就发现备份文件损坏、加密密钥失效、恢复流程缺失关键步骤。恢复演练不需要在生产服务器上折腾。我通常在一台全新的虚拟机里模拟生产环境安装系统装上数据库和业务依赖然后把备份文件拉回来执行恢复gunzip -c mydb.sql.gz | mysql -u root mydb tar xzf etc.tar.gz -C /恢复完检查几个点数据库表数量、关键行数据、站点是否能正常响应。确认没问题后把恢复步骤更新到文档然后销毁演练机器。这个过程不需要很频繁但每季度一次是值得的否则紧急时刻你根本无法冷静地靠记忆恢复。5.3 安全巡检与加固基线固化第 20 条用自动化安全检查工具做定期巡检把加固配置固化成基线实现新机器一键套用。前面 19 条大多是装一次就完事但服务器的安全状态是会动态变化的新装的软件可能开了新端口新加的账户可能权限过大内核升级后 sysctl 配置可能被覆盖。所以加固方案必须有一个周期性巡检闭环。我推荐用一个成熟的审计工具 Lynisapt install lynis lynis audit system它会把系统层面的安全配置全部过一遍最后输出一个 hardening index 分数并列出每一条需要关注的项目。第一次跑完看到 scores 会很焦虑因为很多项都是建议性的要根据自己业务做取舍。核心思路是把合理的加固项固化成 Ansible playbook 或 shell 脚本对一套新环境几分钟就能完成基线配置。我自己在团队里维护了一个 baseline 脚本仓库把这个清单里涉及的账户配置、SSH 配置、UFW 规则、sysctl 参数、AIDE 初始化、日志持久化全部写成脚本。新机器上线先跑 baseline再过一轮代码评审出问题的概率大幅下降。另外提醒一句安全巡检发现的问题一定要进任务清单规定整改时限。没有闭环的巡检就是走个形式骗骗自己而已。最后再分享一点个人体会。安全加固这件事真正拉开差距的不是命令用得有多花哨而是你能不能坚持下去。我见过很多人的做法是服务器上线当天兴致勃勃加固一遍之后半年不管不问直到被入侵了再来翻旧账。其实从 20 条里挑出最影响安全的几条——禁用 root 密码登录、密钥认证、UFW 白名单、自动安全更新、定期备份——先把这五条做到位就能防住绝大多数攻击。剩下的属于锦上添花但长期运营下来别嫌麻烦该做的都得做。