Ubuntu服务器安全加固生产环境落地检查清单

Ubuntu服务器上线后默认配置离生产环境的安全要求差距很大，很多团队把精力放在应用层漏洞修复上，却忽略了系统底座本身的加固。实际攻防中，攻击者拿到一台未加固的Ubuntu主机后，往往几分钟内就能完成提权、横向移动和持久化驻留。下面这份清单不按教科书顺序罗列，而是按照真实入侵路径倒推，把每一项检查落到可执行的命令和判断标准上。

先看SSH登录方式。Ubuntu默认允许密码登录，这意味着只要公网IP暴露，暴力破解流量会持续不断。检查/etc/ssh/sshd_config中PasswordAuthentication是否为no，同时确认PubkeyAuthentication为yes。如果业务上必须保留密码登录，至少要把PermitRootLogin设为prohibit-password，并限制AllowUsers到具体运维账号。另一个容易被忽略的是空密码账户，执行awk -F: '($2==""){print $1}' /etc/shadow，输出必须为空。检查是否有UID为0的异常账户，执行awk -F: '($3==0){print $1}' /etc/passwd，正常只应出现root。sudo权限也要审计，grep -v '^#' /etc/sudoers | grep -v '^$'查看实际授权条目，避免某个普通用户被授予了NOPASSWD: ALL。

生产环境最怕的是内核漏洞被本地提权利用。执行uname -r确认当前内核版本，再执行apt list --upgradable 2>/dev/null | grep -i security查看待更新的安全补丁。很多运维担心升级内核需要重启，但安全补丁和普通功能更新可以分开处理，使用unattended-upgrades只自动安装security源。内核参数方面，检查/etc/sysctl.conf以及/etc/sysctl.d/下的配置是否包含：net.ipv4.conf.all.rp_filter=1开启反向路径过滤，net.ipv4.conf.all.accept_redirects=0关闭ICMP重定向，net.ipv4.conf.all.send_redirects=0禁止发送重定向，kernel.randomize_va_space=2保持地址空间随机化。这些参数能阻断相当一部分基于网络欺骗和内存布局预测的攻击。

Ubuntu默认使用ufw作为iptables前端，但很多服务器装完就忘了启用。执行ufw status verbose，如果显示inactive，说明当前所有服务端口都直接暴露。生产环境至少要执行ufw default deny incoming，ufw default allow outgoing，然后只放行必要端口，例如ufw allow 22/tcp、ufw allow 443/tcp。如果服务器上有Docker，注意Docker会直接操作iptables绕过ufw，这时需要在Docker daemon配置中设置"iptables": false，或者改用更细粒度的iptables规则管理容器流量。另外检查ss -tlnp查看所有监听端口，凡是监听0.0.0.0且业务不需要对外提供服务的进程，都要改成监听127.0.0.1或内网IP。

攻击者提权后通常会修改关键文件权限或植入SUID后门。检查所有SUID和SGID文件，执行find / -perm -4000 -o -perm -2000 -type f 2>/dev/null，对照基线确认每一个SUID程序都是系统正常组件。特别关注/bin、/sbin、/usr/bin、/usr/sbin下是否有近期被修改的SUID文件。对关键目录加挂载限制，/tmp、/var/tmp、/dev/shm建议在/etc/fstab中加上nosuid、nodev、noexec选项，防止攻击者在临时目录编译执行恶意程序。检查/var/log目录权限，确保非root用户无法删除或篡改日志，执行ls -ld /var/log确认属主为root且权限不超过755。另外检查/etc/passwd、/etc/shadow、/etc/group的权限，shadow文件必须是640或更严格，passwd文件不能有全局可写位。

没有日志的安全加固等于没有眼睛。检查rsyslog或systemd-journald是否正常运行，systemctl status rsyslog确认服务active。生产环境建议安装auditd并配置关键文件监控，例如对/etc/passwd、/etc/shadow、/etc/sudoers、/etc/ssh/sshd_config添加-w规则。安装并启用auditd后，执行auditctl -l查看已加载的规则列表。如果发现规则为空，说明审计系统没有真正生效。对于公网暴露的服务器，建议部署fail2ban，检查/etc/fail2ban/jail.local中是否针对sshd、nginx-limit-req等启用了封禁策略，执行fail2ban-client status sshd查看当前封禁数量。日志轮转也要检查，/etc/logrotate.d/下针对syslog、auth.log的配置是否保留了足够长的历史周期，避免攻击者通过刷日志淹没入侵痕迹。

Ubuntu默认安装会带一些不必要的服务，比如cups打印服务、avahi-daemon零配置网络服务。执行systemctl list-unit-files --state=enabled查看所有开机自启服务，凡是与业务无关的立即禁用。特别注意snapd服务，很多Ubuntu服务器版本默认启用snap，而snapd的自动更新机制和沙箱逃逸漏洞在历史上多次成为攻击入口。如果业务不依赖snap包，执行systemctl disable --now snapd.socket snapd.service。进程层面，定期执行ps aux --sort=-%mem查看高资源占用进程，结合lsof -p PID查看异常进程打开了哪些文件和网络连接。对于对外提供Web服务的机器，检查Web进程运行用户是否为www-data或专用低权限用户，禁止以root运行Nginx、Apache或业务应用。

Ubuntu默认启用AppArmor，但很多生产环境只停留在enforce部分系统profile。执行aa-status查看当前加载的策略和处于enforce模式的进程数量。如果输出中profiles数量很少，说明大部分服务没有受到强制访问控制保护。对于Nginx、MySQL等关键服务，检查/etc/apparmor.d/下是否有对应profile并且处于enforce模式。如果业务使用容器，AppArmor对容器运行时的保护同样重要，确认Docker启动参数中没有使用--privileged，且容器内进程的AppArmor profile没有被禁用。对于安全要求更高的场景，可以考虑将关键服务profile从complain模式切换到enforce模式，先观察日志再逐步收紧。

持久化驻留是入侵后期的关键动作，攻击者最常用的位置就是cron和systemd timer。检查/etc/crontab、/etc/cron.d/、/etc/cron.daily/、/etc/cron.hourly/以及各用户crontab，执行for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2>/dev/null; done列出所有用户级定时任务。任何包含随机字符串路径、base64编码命令、下载并执行远程脚本的任务都要重点排查。systemd timer同样不能忽略，执行systemctl list-timers --all查看所有定时触发单元。另外检查/etc/rc.local、/etc/profile.d/、/etc/bash.bashrc以及各用户.bashrc中是否被追加了可疑的export或命令执行语句。

手动逐项检查效率低且容易遗漏，生产环境应该把上述检查固化为脚本或使用开源基线工具。Ubuntu生态中常用的有Lynis，安装后执行lynis audit system，它会输出一份包含数百项检查的报告，重点关注Hardening index和Warning部分。另一个是CIS-CAT，基于CIS Ubuntu Benchmark进行合规性扫描，适合需要满足等保或行业合规要求的场景。无论使用哪种工具，核心是把检查结果纳入变更管理流程，每次系统变更后重新跑基线，确保安全状态不因日常运维操作而退化。对于检查中发现的高风险项，应建立修复优先级，涉及内核漏洞、弱口令、未授权访问的立即处理，配置类问题在下一个维护窗口内完成整改。

这份清单的重点不是一次性做完所有项，而是建立持续验证机制。Ubuntu安全加固的难点在于系统更新和业务变更会不断引入新的暴露面，只有把检查动作固化到日常运维中，才能让安全基线真正落地而不是停留在文档里。