Linux服务器安全加固实战：从SSH防护到SELinux的完整Checklist

1. 项目概述为什么我们需要一份“硬化清单”在运维和开发的圈子里Linux服务器的安全加固是个老生常谈却又常谈常新的话题。我见过太多刚上线的服务器默认配置下端口大开、弱密码横行活脱脱一个“网络裸奔”现场。也处理过不少被入侵后焦头烂额的案例溯源时发现攻击往往始于一个早已被公开的漏洞或一个极其简单的配置疏忽。所以当有人提起“linux-hardening-checklist”时我第一反应是这玩意儿太有必要了它不是什么高深莫测的黑科技而是一份能救命的、系统性的“体检报告”和“操作手册”。简单来说一个完整的Linux系统加固清单Checklist就是一套按优先级排序的、可重复执行的安全配置动作集合。它的核心价值在于“系统性”和“可操作性”。新手可以按图索骥避免遗漏关键步骤老手则可以将其作为审计基准确保环境的一致性。它解决的正是“安全配置碎片化”和“经验无法有效传承”的痛点。无论你是个人开发者管理着一台VPS还是企业的运维工程师负责成百上千台服务器这份清单都能帮你建立起基础的安全水位线把“低垂的果实”型风险先摘干净。2. 清单核心设计哲学与框架拆解一份好的加固清单绝不是命令的简单堆砌。它背后需要有清晰的设计逻辑。2.1 安全加固的“洋葱模型”思维我习惯用“洋葱模型”来理解系统加固。最外层是网络访问控制中间是服务与应用配置最内层是系统内核与用户权限。清单的设计也应遵循这个由外及内、层层递进的原则。外层防护网络与访问层这是第一道防线。包括防火墙规则iptables/nftables, firewalld、SSH安全配置、不必要的网络服务关闭等。目标是缩小攻击面让不该进来的流量连门都摸不到。中层加固服务与应用层系统跑起来的各种服务如Web服务器Nginx/Apache、数据库MySQL/PostgreSQL、应用运行时PHP/Python/Node.js。这一层的重点是遵循最小权限原则及时更新并针对特定服务进行安全配置优化。内核加固系统核心层这是系统的基石。涉及用户权限管理sudoers配置、用户组规划、文件系统权限、内核参数调优sysctl、审计日志配置auditd以及使用像SELinux或AppArmor这样的强制访问控制MAC框架。目标是即使攻击者突破了外层其行为也会受到严格限制和监控。2.2 清单的“动态性”与“场景化”一个常见的误区是把清单当作一成不变的“圣经”。实际上它必须是动态的。与威胁情报同步清单应包含定期更新软件包yum update/apt upgrade的项并关注CVE公告。对于关键业务可能需要订阅相关安全邮件列表。因“地”制宜一台面向公网的Web服务器和一台内部跳板机的加固侧重点完全不同。公网服务器要严防SSH爆破和Web漏洞而跳板机则要重点审计用户操作和会话管理。好的清单会提示你根据服务器角色Web, DB, Bastion Host等调整策略。自动化与合规对于大规模环境手动逐项检查是不现实的。清单中的每一项都应该考虑如何用自动化工具如Ansible, Puppet, Shell脚本来实现并能生成合规性报告。3. 实战演练一份可操作的加固清单核心条目解析下面我将结合多年经验拆解一份实战导向的加固清单核心部分。这不是一个简单的命令列表我会解释每个操作背后的“为什么”以及执行时的“注意点”。3.1 第一阶段初始访问与用户安全这是加固的第一步目标是管好“钥匙和门”。3.1.1 SSH服务加固SSH是Linux服务器的生命线也是最常被攻击的入口。修改默认端口将端口从22改为一个大于1024的非知名端口。这不能算真正的安全但能显著减少自动化脚本的扫描噪音。# /etc/ssh/sshd_config Port 2345注意改端口后务必确保防火墙规则同步更新并且自己别把自己关在外面。建议在修改并重启sshd服务后先用新端口开一个新会话测试确认成功后再关闭旧会话。禁止root直接登录永远不要允许root用户通过SSH直接登录。先以普通用户登录再通过su或sudo提权。PermitRootLogin no使用密钥认证禁用密码认证这是SSH安全最有效的一环。使用Ed25519或RSA 4096位密钥。PasswordAuthentication no PubkeyAuthentication yes实操心得生成密钥时为私钥设置一个强密码短语passphrase是很好的习惯即使私钥泄露也多一层保障。可以使用ssh-agent来管理带密码短语的密钥避免每次输入。使用强密码策略如果必须用密码通过PAM模块配置。编辑/etc/security/pwquality.conf或/etc/pam.d/common-password取决于发行版设置最小长度、复杂度要求大小写、数字、特殊字符和密码历史。限制用户和IP访问使用AllowUsers或AllowGroups限制可以登录的用户。结合防火墙可以进一步限制来源IP。AllowUsers alice bob192.168.1.0/243.1.2 用户与权限管理检查并锁定无用账户查看/etc/passwd对于像games、lp这些非登录系统账户使用usermod -L或passwd -l锁定其密码。更彻底的是将其shell设置为/sbin/nologin。配置sudo权限使用visudo命令编辑/etc/sudoers遵循最小权限原则。避免使用ALL(ALL) ALL这种宽泛授权。可以为特定用户组授权执行特定命令。# 示例允许admin组的用户无需密码重启网络服务 %admin ALL(ALL) NOPASSWD: /bin/systemctl restart networking设置正确的umask默认的umask决定了新建文件和目录的权限。为了安全普通用户的umask通常设为0077或0027组用户可读系统全局设置可在/etc/profile或/etc/bash.bashrc中配置。0027意味着新建文件权限为640所有者读写组只读目录为750。3.2 第二阶段网络与服务加固收紧系统的“对外接口”。3.2.1 防火墙配置无论你用iptables、nftables还是firewalld原则都是“默认拒绝按需放行”。基础策略INPUT链默认DROPFORWARD链默认DROP如果不是网关OUTPUT链默认ACCEPT。放行规则只开放必要的端口。例如Web服务器开放80/443SSH开放你自定义的端口。对于数据库如3306, 5432强烈建议仅监听内网IP或通过Unix Socket连接。# 使用firewalld的示例CentOS/RHEL/Rocky Linux firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps firewall-cmd --permanent --add-port2345/tcp # 你的SSH端口 firewall-cmd --reload使用Fail2ban这是一个极其有用的工具它监控系统日志如/var/log/secure当发现同一个IP在短时间内多次认证失败就自动将其IP加入防火墙黑名单一段时间。对于防护SSH、FTP、Web登录的爆破攻击效果显著。3.2.2 停用与禁用不必要的服务使用systemctl检查运行中的服务。systemctl list-units --typeservice --staterunning对于像bluetooth、cups打印服务除非需要这类明显不需要的服务直接禁用并停止。systemctl stop cups systemctl disable cups systemctl mask cups # mask可以防止被其他服务意外启动排查技巧用netstat -tulpn或ss -tulpn查看所有监听端口对应找出不必要的服务。3.3 第三阶段系统内核与文件安全深入到系统核心建立更深层的防御和监控。3.3.1 内核参数调优sysctl编辑/etc/sysctl.conf或/etc/sysctl.d/下的自定义文件以下是一些关键安全参数# 禁止IP转发除非是路由器/网关 net.ipv4.ip_forward 0 # 启用SYN Cookie防护SYN Flood攻击 net.ipv4.tcp_syncookies 1 # 忽略ICMP广播请求避免Smurf攻击 net.ipv4.icmp_echo_ignore_broadcasts 1 # 忽略伪造的ICMP重定向消息 net.ipv4.conf.all.accept_redirects 0 net.ipv6.conf.all.accept_redirects 0 # 禁止发送ICMP重定向消息除非是路由器 net.ipv4.conf.all.send_redirects 0 # 开启恶意ICMP错误消息保护 net.ipv4.icmp_ignore_bogus_error_responses 1 # 开启RFC1337防止TIME-WAIT状态套接字耗尽 net.ipv4.tcp_rfc1337 1 # 控制core文件生成避免敏感信息泄露 fs.suid_dumpable 0执行sysctl -p使配置生效。3.3.2 文件系统与权限审计查找SUID/SGID文件SUID/SGID位设置不当是提权的高发地。定期审计。find / -type f \( -perm -4000 -o -perm -2000 \) -exec ls -l {} \;对于非必要的SUID/SGID文件如/bin/ping可能需要但自定义脚本绝对不要用chmod u-s或chmod g-s移除特权位。检查全局可写文件全局可写目录是攻击者放置后门的好地方。find / -type f -perm -0002 -exec ls -l {} \; find / -type d -perm -0002 -exec ls -l {} \;使用文件完整性校验工具如AIDEAdvanced Intrusion Detection Environment或Tripwire。在系统干净时刚装好并加固后生成一个文件属性数据库之后定期运行检查报告哪些文件被篡改、增加或删除。这是检测入侵后痕迹的关键手段。3.3.3 启用审计系统auditdauditd是Linux内核的审计框架可以记录非常详细的事件用于事后溯源。关键审计规则监控文件访问、系统调用、用户命令等。# 监控/etc/passwd文件的写、属性更改 -w /etc/passwd -p wa -k identity # 监控/etc/shadow文件的所有访问敏感 -w /etc/shadow -p wa -k identity # 监控所有sudo提权命令 -a always,exit -F archb64 -S execve -C uid!euid -F euid0 -k sudo_log # 监控SSH配置更改 -w /etc/ssh/sshd_config -p wa -k sshd_config规则写在/etc/audit/rules.d/下的文件中。使用ausearch和aureport工具来查询和生成报告。3.4 第四阶段高级防护与入侵防范3.4.1 配置强制访问控制SELinux 或 AppArmor这是将安全从“ discretionary”自主决定提升到“mandatory”强制的关键一步。虽然学习曲线陡峭但值得投入。SELinuxRHEL/CentOS/Fedora系列默认核心模式有三种Enforcing强制、Permissive仅记录不阻止、Disabled关闭。永远不要直接Disabled这会导致策略混乱。先从Permissive模式开始使用audit2allow分析日志并生成自定义策略模块逐步过渡到Enforcing。# 查看状态 getenforce sestatus # 设置为Permissive setenforce 0 # 永久修改需编辑 /etc/selinux/configAppArmorDebian/Ubuntu/SUSE系列常用相对于SELinux其基于路径的配置方式可能更易理解。确保其处于活动状态并为关键应用如Nginx, MySQL加载了配置文件。sudo apparmor_status sudo systemctl enable apparmor踩坑实录最常遇到的问题是在Enforcing模式下服务启动失败。首先查看/var/log/audit/audit.logSELinux或/var/log/syslog/dmesgAppArmor中的拒绝信息然后根据提示调整策略而不是粗暴地关闭它。3.4.2 日志集中管理与监控本地日志容易被攻击者篡改或删除。将关键日志如auth.log,secure,audit.log实时发送到远程的、受保护的日志服务器如使用rsyslog或syslog-ng的转发功能。同时搭配像logwatch或logcheck这样的工具定期向你发送日志摘要报告便于发现异常。4. 自动化与持续化让清单“活”起来手动执行清单只能应付一时。真正的加固是持续的过程。4.1 使用配置管理工具用Ansible、SaltStack或Puppet等工具将你的加固清单代码化。例如一个Ansible Playbook可以轻松地完成以下工作统一修改所有服务器的SSH配置。部署并配置防火墙规则。安装和更新特定软件包。推送定制的sysctl配置文件。确保关键目录的权限正确。这样无论是初始化新服务器还是定期合规检查都能一键完成确保环境的一致性。4.2 漏洞扫描与合规检查将主动扫描纳入流程。使用Lynis这是一款优秀的开源安全审计工具它会运行数百项测试并给出详细的加固建议和风险评分其输出本身就是一份极佳的、针对你当前系统的定制化Checklist。lynis audit system使用OpenSCAP这是一个更偏向于合规性的框架它使用基于标准的如NIST, CIS Benchmark安全内容自动化协议SCAP来检查系统配置。你可以针对CIS Linux Benchmark生成合规报告。4.3 建立变更管理与回滚机制任何加固操作都可能带来风险比如改错配置导致服务不可用。因此在修改生产系统前在测试环境验证。对关键配置文件如sshd_config,sudoers进行备份。使用版本控制系统如Git管理你的配置脚本和清单。制定明确且测试过的回滚方案。5. 常见问题与排查技巧实录在实际操作中你肯定会遇到各种“坑”。这里记录几个高频问题问题1修改SSH配置后连接被拒绝。排查思路首先检查是否输错了端口号ssh -p 2345 userhost。在服务器上使用ss -tlnp | grep :2345查看sshd是否真的在监听新端口。检查防火墙是否放行了新端口firewall-cmd --list-all或iptables -L -n。查看SSH服务日志sudo journalctl -u sshd -f或tail -f /var/log/auth.log这里会有详细的连接失败原因比如“Permission denied (publickey)”或“Connection closed by ...”。避坑技巧永远在sshd_config中保留一个活动的SSH会话窗口或者使用类似tmux或screen的终端复用器。在重启sshd服务systemctl restart sshd后先在新窗口用新配置测试连接成功后再关闭旧窗口。问题2配置了sudo的NOPASSWD但执行命令时仍然要求密码。原因sudoers文件的语法非常严格顺序和格式错误都会导致规则不生效。另外后面的规则可能会覆盖前面的规则。排查使用sudo visudo -c检查语法。仔细检查用户名/组名是否正确ALL是否大写NOPASSWD标签的位置。一个常见的格式是username ALL(ALL) NOPASSWD: /full/path/to/command。问题3开启SELinux后Web服务器如Nginx无法访问网站文件。现象返回403错误Nginx错误日志显示“Permission denied”。解决这通常是文件上下文context不正确。使用ls -Z查看文件的安全上下文。Web内容通常需要httpd_sys_content_t类型。# 递归修改目录及内容的上下文 sudo chcon -R -t httpd_sys_content_t /var/www/html/ # 更持久的方法是使用semanage修改默认规则然后restorecon sudo semanage fcontext -a -t httpd_sys_content_t /var/www/html(/.*)? sudo restorecon -Rv /var/www/html问题4Fail2ban似乎没有生效日志里看不到被封禁的IP。排查检查Fail2ban服务状态systemctl status fail2ban。检查jail是否激活fail2ban-client status。检查具体的jail如sshd状态fail2ban-client status sshd。查看Fail2ban自己的日志tail -f /var/log/fail2ban.log。最关键的一步确认你的系统日志路径和日志格式与Fail2ban的jail配置通常在/etc/fail2ban/jail.local或/etc/fail2ban/jail.d/中定义的logpath和failregex匹配。不同发行版和SSH配置可能会影响日志格式。这份清单和指南是一个起点而非终点。Linux安全是一个涉及技术、流程和意识的综合工程。真正的精通是在理解了这些基础原则后能根据自己业务的特点持续迭代、监控和响应。我个人的习惯是每搭建或接管一台新服务器都会运行一遍自己的自动化加固脚本然后用Lynis做一次快速审计把分数刷到“绿色”区域以上心里才算有点底。安全没有银弹但扎实的基础工作能帮你挡住绝大部分漫无目的的自动化攻击和因疏忽导致的低级风险。