刚接手服务器运维那几年我踩过最大的坑不是服务宕机不是性能瓶颈而是服务器被黑了我还不知道。直到有一天业务同学告诉我网站被植入挖矿脚本我才反应过来一个裸奔的Linux系统在公网上撑不过三分钟。从那时起我就把“Linux系统安全加固”当成了所有服务器上线的硬性前提而不是可选项。这篇文章想和你聊聊系统安全加固这件事。我会把这套方法论拆成15个关键配置从账号、SSH、防火墙、内核参数到日志审计一层层说清楚。面向的对象很简单刚入门Linux运维的新人被安全事件折磨过的工程师以及所有希望在业务上线前就把安全底子打牢的同行。读完你至少能获得一套可以直接落地执行的加固清单以及我在生产环境里反复试错后的经验教训。1. 内容整体设计与思路拆解1.1 安全加固的本质是纵深防御很多新手对安全加固有一个误区以为装了防火墙、改了SSH端口就算安全了。真实情况远没有那么简单。攻击者从踩点扫描到拿下服务器通常走的是“最薄的那一层”路线你的SSH配置再稳账号存在弱口令一样被打穿iptables规则再严运行的服务本身有漏洞一样被利用。所以我做加固方案设计时从来不用单点思维。整体思路是六个字纵深、减少、监控。纵深是指安全层次要足够多单层被突破后还有其他防线兜底。减少是指攻击面要尽量小不用的服务关掉、用不到的端口不监听、多余的账号一律删除。监控则是最后一道兜底手段任何绕过之前配置的攻击行为能在日志和告警里留下痕迹让你有机会在造成大损失之前发现并干预。前面两项是“筑墙”最后一项是“安摄像头”。根据我处理过的真实入侵案例绝大多数成功入侵都能追溯到这三项里至少一项没做到位。1.2 从“能用”到“加固”要经历三个状态服务器交付有几种状态刚装完的裸机状态业务能跑的可用状态以及安全上站得住脚的加固状态。很多团队常年停留在第二阶段只要能跑就万事大吉。第三阶段和第二阶段最大的区别在于所有的操作都遵循“最小化”原则。谁有权限、谁能登录、哪些端口对外开放、服务以什么身份运行全部按照业务实际需求精确匹配不存在任何“顺手”“暂时”“先这样”的临时配置。加固不是一次性的活动而是一个持续迭代的过程。新服务上线、新漏洞公开、业务架构调整每一个变化都可能引入新的风险点。我把加固设计成四个环节基线采集、规则下发、效果验证、沉淀归档。每个环节都有对应的工具和检查清单哪怕是三四台机器的小集群也走完整的流程这样后续出问题才知道当初改了什么、为什么改。1.3 15个关键配置全景清单在动手之前先把全文要讲的15个配置点列出来方便你对照自己当前的服务器情况逐项检查序号配置项核心作用危险等级未配置时1SSH密钥登录与禁用密码登录杜绝暴力破解与弱口令风险高2SSH端口修改与访问控制降低被扫描和攻击的概率中3修改SSH监听地址只允许内网/IP白名单访问高4账号与口令策略加固防止弱口令和僵尸账号高5sudo权限最小化收敛提权路径高6防火墙规则收紧只放行业务需要的端口高7关闭无用系统服务缩小攻击面中8系统补丁与软件更新修复已知漏洞高9日志审计与远程集中收集保留入侵痕迹与行为分析依据中10关键文件权限加固防止配置被篡改中11内核参数安全整治加固网络栈与系统层安全性中12防暴力破解工具部署对登录行为进行限速与封禁高13安全软件源与包签名校验防止从恶意源安装后门软件中14SELinux/AppArmor等强制访问控制限制进程越权高15异常文件与Rootkit扫描及时发现已入侵的痕迹中这张表就是本文的主线后面所有章节都是围绕其中每一项展开的。2. 核心细节解析与实操要点2.1 SSH远程访问是最容易失守的门公网服务器的22号端口平均每几十秒就会被扫描一次这不是夸张而是我在真实日志里看到的常态。SSH加固是整条防线里优先级最高的一项。第一步是改用密钥登录。用rsa或ed25519算法生成一对密钥把公钥放进~/.ssh/authorized_keys关闭密码认证。之前好多同事觉得麻烦坚持用密码登录结果某天日志里出现了几千条Login Failed记录这才意识到弱口令在自动化攻击面前形同虚设。第二步是修改监听端口。把Port从22改成一个不常用的高位端口。这一步不是为了真正做到隐蔽而是为了大幅减少扫描流量和日志噪音。配合防火墙做IP白名单限制效果更佳只有指定网段或IP能连到SSH端口其余来源直接被防火墙丢弃。第三步需要特别警惕改SSH配置前一定要在另一个会话里保持在线状态或者先测试新端口能连通。我见过太多因为改完SSH配置后语法错误导致远程登录彻底断开的案例一旦防火墙和SELinux也同时开着那基本可以准备去机房搬服务器了。实操建议修改/etc/ssh/sshd_config时先保留默认配置的备份再逐项修改。改完用sshd -t验证语法确认无误后systemctl reload sshd。注意reload不会断开当前连接但新的登录规则立即生效。生产环境建议先把新端口写入防火墙白名单再执行reload顺序反了可能导致公网IP直接被自己封死。2.2 账号口令策略是最容易被忽略的地基很多时候系统被入侵问题不是出在什么高级攻击手法上单纯就是服务器上有一个长期不用的账号密码还是最简单的那种。我处理过一次入侵溯源攻击者就是通过一个早期测试留下的账号进来的那个账号连登录shell都是bash还有sudo权限。账号层面的加固思路很直接清点所有本地用户禁用或删除与业务无关的账号。/etc/passwd里拥有shell并有home目录的账号逐一过一遍对不上的直接处理掉。系统账号如果是nologin还好最怕的是测试阶段随手创建的账号一直留到生产。口令策略也要设定好。/etc/login.defs里的PASS_MAX_DAYS、PASS_MIN_LEN等参数要按基线配置。密码轮换周期不要太短太短只会逼着用户把密码写在便利贴上也不要太长一般90天到180天之间比较现实。同时把pam_pwquality.so打开限制新密码不能继续用先前的密码避免“改了一圈又改回去”的情况。这里有一个很关键的细节修改密码策略只影响后续设置的密码已经在用的旧密码不会自动失效。要让策略立即生效需要结合chage命令强制用户在下次登录时修改密码特别是给新员工开账号、临时账号转正这类场景。2.3 防火墙规则要“默认拒绝”防火墙的默认策略有两种思路默认允许加黑名单默认拒绝加白名单。前一种适合开发测试环境出问题排查起来省事后一种才是生产环境该有的样子。我用iptables和firewalld都比较熟现在新系统基本都用firewalld了但底层原则是一样的。先把默认INPUT链策略设为DROP或者REJECT然后只放行明确需要的端口。当业务同学跟我说“能不能顺手开个端口”的时候一定要追问用途、来源IP和有效期没有明确来源限制的端口一律不在公网开放。这里要特别提醒的是配置防火墙的时候最好同时考虑IPv6。很多系统的IPv6防火墙默认策略与IPv4不一致甚至完全没有配置攻击者如果具备IPv6访问能力就相当于绕过了你精心设置的IPv4白名单。以firewalld为例我建议优先使用富规则来精确限制来源地址。比如只允许办公网访问SSH端口可以写成firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.0.0.0/8 port port10222 protocoltcp accept。比起直接放通整个端口这样写的好处是其他人的扫描直接在防火墙上被丢弃根本到不了SSH服务。2.4 内核参数与强制访问控制是最后的地基很多人把加固的重心放在应用层觉得内核参数是“高手才玩的东西”但其实有几个参数对防御效果的提升非常立竿见影。/etc/sysctl.conf里的关键配置比如net.ipv4.tcp_syncookies1这个参数用于防范SYN Flood攻击是应对DDoS初阶攻击的基础选项net.ipv4.conf.all.rp_filter1开启反向路径过滤能有效防止IP欺骗net.ipv4.icmp_echo_ignore_broadcasts1处理广播ping可能造成的放大攻击net.ipv4.ip_forward0如果你不是路由器一定确保它是关闭的。还有个经常被忽略的是隐藏内核指针和限制dmesg信息比如kernel.kptr_restrict1和kernel.dmesg_restrict1这些能降低普通用户获取内核敏感信息的能力对防御本地提权攻击有实际意义。关于SELinux说实话我在早期也嫌它麻烦经常直接setenforce 0关掉拉倒。后来深入研究才发现SELinux只要配置得当能在进程被攻破后拦住后续的越权访问阻止攻击者读不该读的文件、监听不该监听的高位端口。现在的系统服务对SELinux的支持已经极为成熟只有在某些自定义场景下才需要调整策略。AppArmor也是类似的思路选哪个取决于你用的发行版习惯但一定要在跑业务的机器上启用至少一种强制访问控制机制。2.5 日志是入侵溯源里唯一的侦探攻击者进入系统后总会留下或多或少的痕迹。有没有日志、日志在不在、保留多久直接决定你在攻击发生后是“一脸懵”还是“顺着痕迹回溯全路径”。一个基础却极其重要的配置是启用rsyslog或journald的持久化日志并确保核心日志文件有合理的大小和轮转策略。很多初始安装的系统journald默认只把日志写在内存里重启一次就没了。日志集中收集是我特别要推荐的进阶做法。把所有服务器的auth.log、syslog、nginx access log、应用日志统一推到一台日志服务器或对象存储里既防入侵者删日志又能用简单脚本做模式匹配第一时间发现扫描和暴力破解行为。之前有一次挖矿告警出来我靠集中日志在两小时里还原了攻击者的完整入侵链从扫描、爆破、上传工具到内网横向每一个动作都有记录。还有一个点容易被忽略日志本身的权限。auth.log、secure日志这些记录敏感登录信息的文件权限要收紧到600防止普通用户读取其他用户的登录痕迹。3. 实操过程与核心环节实现3.1 第一阶段环境准备与系统基线采集实战先从摸底开始。拿到一台新服务器后别急着配环境先做一套完整的基线采集。这一步的价值在于你知道自己正在处理什么状态后续改动也才有对照依据。我会依次执行下面这些命令# 查看操作系统版本 cat /etc/os-release # 查看内核版本和系统架构 uname -a # 列出所有本地用户及登录shell cat /etc/passwd | awk -F: $31000 {print $1, $3, $7} # 查看所有监听端口 ss -tlnp # 查看systemd服务列表 systemctl list-unit-files --typeservice --stateenabled # 检查开机启动项 systemctl list-unit-files | grep enabled # 查看已安装软件包数量 rpm -qa | wc -l # 或 dpkg -l | wc -l # 查看当前网络连接状态 ss -tunap采集结果至少要留存一份。我会把这些信息整理成一个文本文件放在加固文档目录里最后沉淀成该服务器的资产台账。这一步对后续问题回溯特别有用有时候排查问题查到头大回头看一眼基线信息很多疑问当场就清楚了。如果在采集过程中发现异常比如未知的监听端口、可疑的登录账号、没见过的进程先停下来确认清楚再继续加固。带着隐患做加固等于地基没打好就开始砌墙。3.2 第二阶段核心配置实施操作我会按照配置依赖关系分批操作。优先级最高的是SSH和账户因为它们直接影响我能用什么方式管理和访问这台机器。先做SSH加固。生成密钥对的时候我建议用ed25519算法它的密钥更短、安全性更强、兼容性也够好# 在本地机器而不是服务器上生成密钥对 ssh-keygen -t ed25519 -C yournameworkstation -f ~/.ssh/id_ed25519 # 使用ssh-copy-id把公钥传送到服务器首次仍用密码登录 ssh-copy-id -p 22 userserver_ip然后修改/etc/ssh/sshd_config# 修改端口为10222避开常规扫描 Port 10222 # 禁止root直接登录只允许通过普通用户sudo提权 PermitRootLogin no # 使用密钥登录关闭密码认证 PubkeyAuthentication yes PasswordAuthentication no # 允许空密码绝对不允许 PermitEmptyPasswords no # 限制登录会话空闲时间避免闲置连接被利用 ClientAliveInterval 300 ClientAliveCountMax 0 # 限制允许登录的用户列表 AllowUsers devops tom每次修改完成先执行sshd -t确认语法无误再reload还要在新的终端会话测试登录成功后才算完成。如果新会话登录失败赶紧用旧会话把配置改回去。接着做账户和sudo权限收紧。我的习惯是写一个加固脚本但一开始先在测试机上逐条执行验证确认没影响业务再合并进脚本。比如禁用多余的账号可以这样操作# 锁定目标账号 usermod -L username # 把shell改成nologin彻底禁止登录 usermod -s /sbin/nologin username # 如果确认账号完全无用直接删除 userdel -r usernamesudo权限需要特别小心一个常见的错误是user1 ALL(ALL) ALL这种写法等于把所有用户都变成了root。更合理的做法是按需分配命令级别的sudo例如让运维同学只能管理特定服务# 在/etc/sudoers.d/里新建配置文件不要直接改/etc/sudoers echo tom ALL(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx /etc/sudoers.d/tom chmod 440 /etc/sudoers.d/tom防火墙规则同样要按“默认拒绝”来设置# 默认策略改为拒绝 firewall-cmd --permanent --set-default-zonedrop # 放行修改后的SSH端口限制来源IP firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.0/24 port port10222 protocoltcp accept # 放行Web服务端口 firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps # 重新加载防火墙配置 firewall-cmd --reload # 确认当前配置 firewall-cmd --list-all这里我故意把SSH端口的放行命令放在reload之前并且限制来源IP这样一个万一自己只要还在许可网段内就不会因为误操作被拒之门外。3.3 第三阶段验证加固效果配置完成后验证环节必不可少。很多时候配置改得“看起来没问题”实际效果却和预期不一致只有经过验证才知道哪里漏了。我会分三层验证第一层端口与防火墙验证。ss -tlnp查看端口监听状态确认SSH在10222端口正常监听原有的22端口不再开放。用nmap从外部扫描这台机器确认公网能看到的开放端口只有预期的那几个。第二层登录验证。新开一个终端用密钥方式连接到10222端口确认能登录。然后换一个本地IP或者临时改回密码认证试一下确认密码登录确实被拒绝。root直接登录也要试一次应该被拒绝。第三层服务验证。Web等服务在加固后是否正常响应数据库应用连接是否有异常。很多加固操作会误伤正常业务比如SELinux开启后nginx读取不了文件目录防火墙策略导致内部服务互相访问失败。这些都要在验证环节提前暴露而不是等业务同学来反馈。3.4 第四阶段形成可用于复现的加固脚本单台机器手动操作没问题但如果是集群或者需要批量交付服务器手工操作既不现实也不可维护。我一般会把整套配置写成一个幂等的加固脚本放在Git仓库里做版本管理。脚本的核心设计逻辑是这样的每段操作都判断是否已经执行过已配置则跳过未配置则执行避免重复运行导致配置错乱。像sshd_config这种文件先备份再修改脚本开头自动生成带时间戳的备份目录。所有的端口、用户、IP白名单都抽成脚本顶部的变量换一套环境只需要改变量不需要改逻辑。脚本跑完之后自动输出一份审计报告列出每一项配置的当前状态和期望状态不一致的标红。这样不管给多少台机器做加固最终交付的质量都是可控的。这一步有个额外的价值加固知识从个人经验变成了团队资产。新人来了不用靠口口相传跑一遍脚本再对着Git仓库看注释就能理解整套加固逻辑。4. 常见问题与排查技巧实录4.1 改完SSH配置后无法远程连接这是运维新人翻车最多的地方我自己早期也干过这种事。修改sshd配置后reload之后发现无论如何都连不上服务器断网的感觉有多酸爽经历过的都懂。解决思路是这样的改任何SSH配置前先确保有一个不会断开的备用连接通道。可以是云厂商的VNC控制台也可以是机房的带外管理iDRAC/iLO没有这个备用通道打死都不要动sshd配置。如果不幸中招了通过备用通道登录后先看sshd服务是否正常systemctl status sshd # 如果服务失败执行下面的命令查看详细原因 sshd -tsshd -t会直接告诉你语法错误出在第几行这是最常见的失联原因。另外还有一种情况是防火墙没放行新端口服务虽然正常但数据包被防火墙丢弃了。这时候需要在备用通道里检查和调整防火墙规则。4.2 修改SSH端口后日志里还是有大量扫描有些朋友发现改了SSH端口后攻击扫描少了很多但还是隐约有一些探测痕迹。这是很正常的现象端口修改能做的只是降低被无差别扫描命中的概率并不等于隐身。针对这个情况我建议配合fail2ban这类工具做防暴力破解。fail2ban的原理很简单它会读取系统日志把短时间内多次认证失败的IP拉入黑名单在一段时间内禁止其连接。以fail2ban的SSH配置为例[sshd] enabled true port 10222 filter sshd logpath /var/log/secure maxretry 3 bantime 3600这里几个参数的含义maxretry3表示同一IP在检测周期内最多尝试3次失败登录超过就触发封禁bantime3600表示封禁时长是3600秒按自己环境的安全要求调整公网数据库业务建议甚至可以直接拉满到24小时。fail2ban部署后一个明显的效果是日志里的暴力破解记录会大幅下降同时SSH认证日志也干净了不少反而更容易发现真正的异常行为。4.3 加固后业务服务无法启动或访问异常这类问题往往出在“加固过度”和“配置顺序”上。最常见的是防火墙默认策略改成DROP后没有放行服务需要的端口业务端口从测试机能通但从外部被丢弃。另一个常见元凶是SELinux尤其当它从disabled切换到enforcing时之前不受限制的服务进程现在全被限制了nginx读不了web目录数据库连不了监听端口现象就会是服务可疑地起不来。排查方法很简单三步走先临时关掉防火墙或SELinux做对比试验确认问题是否由安全组件引入再用ausearch或sealert查看SELinux的告警日志看具体拦截了哪个进程的哪类操作最后针对性地放行或调整策略而不是直接关掉安全机制。如果你在加固过程中遇到服务异常又没有明确的报错先检查/var/log/messages、/var/log/secure、audit.log这几个日志文件绝大多数原因都能在里面找到线索。定位到具体拦节点后给服务进程配置对应的SELinux布尔值或者把需要对外开放的端口写入文件策略尽量避免直接关闭保护。4.4 加固效果速查与持续运营建议做完了所有配置最怕的是过几个月大家忘记了当初的设定或者业务迭代中有人为了图方便把某项加固给“优化”掉了。所以我习惯定期做一次安全基线核查把每一台服务器的状态和初始加固记录做对比。下面是我自用的一个速查表每隔一段时间就会跑一遍发现漂移及时纠正检查项期望状态检查命令SSH端口非22高位数ss -tlnp | grep ssh密码认证已禁用sshd -T | grep passwordauthenticationRoot远程登录已禁用sshd -T | grep permitrootlogin多余账号不存在awk -F: $30{print $1} /etc/passwd防火墙默认策略dropfirewall-cmd --statefirewall-cmd --get-default-zone密码策略满足基线cat /etc/login.defs | grep -E PASS_(MAXSELinux模式enforcinggetenforce系统补丁最新yum check-update或apt list --upgradablefail2ban运行状态正常运行systemctl status fail2ban异常登录记录无异常last -f /var/log/wtmp | head -50持续运营这件事比起一次性配置更能决定服务器的安全上限。我自己的习惯是每个月抽出一个周末对核心服务器做一轮快照和基线核查顺便更新一下fail2ban的拦截规则和系统补丁。平时多花一点时间真遇到攻击的时候就能少熬几个通宵。最后再分享一个小技巧加固完成后一定要把整个操作过程、改动的文件、当时的验证结果写成文档存档。这个文档不仅是项目交付的一部分更是你几个月后排查问题时最可靠的参照物。做过多少台服务器、改过哪些配置脑子里记得再清楚也不如白纸黑字的记录来得踏实。