上周帮一位朋友处理了一台测试服务器的异常告警登录日志拉到一半我就关了屏幕——短短两个小时里密码嗅探请求刷出来六百多条失败记录IP来自好几个国家和地区。这台机器上其实没有值钱数据但它因为开着默认的22端口、允许root直接密码登录成了公网上一个任人敲门的靶子。处理完之后他问我Linux服务器安全到底应该先从哪儿下手这其实就是我今天想认真梳理的问题。这里说的“Linux系统安全加固”不是某个厂商的安全套件也不是买一套商业软件就完事而是把一台默认状态下的Linux服务器通过配置、权限、网络规则、审计手段逐步收敛到“能被攻破的概率尽可能低、被攻破之后能及时发现”的状态。这篇文章不会啰嗦一大堆理论名词我打算按自己实际做加固的顺序把最关键的五大策略拆开讲清楚动手前的基线摸底、SSH远程入口收敛、账户与权限最小化、网络层拦截与自动封禁、以及审计日志和内核层面的兜底。每一块都有可以直接抄走的命令、配置文件和验证方法适合刚接触服务器运维的初学者也可以作为老手做配置自查时的一份清单。1. 加固前先摸底三分钟看清你的攻击面有些同学一上来就急着改SSH配置、加防火墙规则结果改到一半把业务端口给拦了或者把某个关键用户锁死了。所以我坚持的第一步永远是摸底——先搞清楚这台机器到底暴露了什么再决定动哪里。不摸底就加固跟闭着眼拆弹没什么区别。1.1 为什么先摸底而不是直接上策略默认安装的Linux发行版通常处于一个“半开放”状态系统自带的网络服务没有做限制防火墙规则基本是空的SSH允许密码登录root账户可以直接远程登录。这些都不是“错误”而是为了初始安装方便而留下的宽松默认值。问题是宽松默认值在公网环境下就是给攻击者铺路。摸底的目的有两个第一是列出所有对外暴露的入口和正在运行的服务评估它们是否必要第二是确认哪些用户、哪些配置项和后文提到的加固动作会冲突。举个例子你以为可以直接关掉密码登录但一台服务器上可能有某个旧脚本依赖root密码登录拉取备份你一刀切之后业务就断了。摸底能在动手之前把这些雷排掉。1.2 一套可复制的基线检查命令我一般会在目标机器上依次跑下面这几组命令用一台标配8G内存、单核CPU的云主机来说整个过程不超过三分钟。# 查看所有监听端口以及对应的进程 ss -tulnp # 查看当前系统有哪些可登录用户具备shell的用户 cut -d: -f1,3,7 /etc/passwd | grep -v nologin # 查看SSH当前生效的关键配置 sshd -T | grep -E permitrootlogin|passwordauthentication|port # 查看正在运行的服务单元 systemctl list-units --typeservice --staterunning # 查看防火墙当前状态和规则 firewall-cmd --list-all || nft list ruleset || iptables -L -n # 查看最近的成功登录和失败登录记录需要root last -n 20 lastb -n 20 2/dev/null || echo btmp无记录或权限不足拿结果出来之后我会把发现的问题分成三类必须马上改的、评估后再改的、保持原样的。必须马上改的包括开放了不必要的远程管理端口、存在可登录的异常用户、防火墙规则为空评估后再改的包括某个端口虽然开着但业务确实需要、某个用户虽然带shell但很少使用保持原样的则通常是系统服务本身占用的端口比如时钟同步、容器运行时等。1.3 记录与归类哪些需要动哪些不能动顺手建一个表格贴在服务器备注里很有必要不然过两周你自己都会忘了当初为什么开某个端口。发现问题处理建议对应章节22端口面向全网开放且允许密码登录优先处理改配置、限来源、加防护第2、4节/etc/passwd中存在非root且带bash的业务账户评估用途锁定或限制登录方式第3节防火墙没有默认DROP策略优先处理按白名单重新收口第4节未开启审计日志和登录失败记录持久化评估后补上防止事后无据可查第6节这一轮的产出物不是一堆命令输出而是“这台机器的暴露面清单”。带着这份清单去做后续策略每一条都能想清楚自己为什么这么改。2. 策略一把SSH做成不容易敲开的门SSH就是Linux服务器的入户门。默认配置下的SSH服务对公网开放密码登录开着root还能直接登录——这在现实中相当于门锁是坏的门上还贴了个纸条写着“管理员入口”。所以第一道硬功夫一定是放在SSH上。2.1 为什么SSH永远是第一目标攻击者手里的自动化工具会不断扫描公网IP段一旦发现22端口响应SSH协议就开始用常见用户名和密码字典做暴力尝试。哪怕你的密码是十位以上的混合字符也顶不住分布式脚本的长期轰炸而且服务器日志里会堆满无意义的失败记录干扰你发现其他真实问题。有人会说我密码够复杂不怕爆破。问题是复杂密码防不了“撞库”和“中间人窃听”。更稳妥的方案是彻底关掉密码登录改用密钥对认证。密钥认证的安全性建立在私钥的保密性上攻击者即使截获了网络流量也无法用截获的会话逆推出你的私钥。再加上限制登录用户和来源IP大门才真正算关严了。2.2 五条SSH加固动作从容易到彻底我按操作难度和收益把常用的加固动作排了个优先级生成高强度密钥对并只保留公钥在服务器上。本地执行ssh-keygen -t ed25519 -a 100然后把~/.ssh/id_ed25519.pub的内容追加到服务器的/root/.ssh/authorized_keys。私钥注意加密保存别放在能被其他人读取的目录里。修改/etc/ssh/sshd_config禁止密码登录、禁止root直接密码登录、限制最大认证尝试次数PermitRootLogin prohibit-password PubkeyAuthentication yes PasswordAuthentication no MaxAuthTries 3 ClientAliveInterval 300 ClientAliveCountMax 0严格限制允许登录的用户。如果一台机器只有两三个人需要管直接写明白AllowUsers ops deploy修改默认监听端口能挡掉大部分无差别扫描但不代表安全它只降低了被随机扫描命中的概率。配合fail2ban使用才有意义。开启fail2ban让连续失败的IP自动拉黑具体配置放在第4节一起讲。2.3 验证与回退改SSH配置不会把自己锁在外面改SSH配置最怕一件事改完重启发现自己连接不上了。我的习惯是改完先做语法检查再保持当前会话不退出另开一个新连接去验证。# 第一步语法检查 sshd -t # 第二步重载服务不会断开现有连接 systemctl reload sshd # 第三步另开一个终端用新配置登录验证 # 确认没问题再关掉当前连接万一真把自己锁在外面了也别慌。如果机器有VNC等带外管理入口直接通过它登录改回来如果云控制台支持网页终端用网页终端恢复配置比较推荐。经历过一次之后你就会明白每次要改这种涉及远程管理通道的配置提前开一个备用会话是刻在骨头里的习惯。3. 策略二账户、密码与sudo的最小权限闭环SSH入口管好了还得管门里站着的那些人。服务器上一个多余的带shell账户、一个弱密码、一条过宽的sudo规则前期的入口加固都会白费。这条链路我习惯叫“账户、密码、权限的最小化闭环”。3.1 危险账户清理停用、删除、锁定分清楚先扫一遍系统里有哪些账户可以登录。除了root还可能存在安装软件时自动创建的服务账户、某个前同事留下的个人账户、甚至被入侵者种下的后门账户。对可疑账户判断标准不是“它看起来没什么用”而是“它有没有必要存在、有没有必要带shell”。处理方式有三种对应不同情况确定没用的直接删掉。userdel -r 用户名会连家目录一起删除执行前注意备份需要保留的数据。暂时拿不准但近期不用锁定登录而不是删除。usermod -L 用户名可以锁住密码登录usermod -s /usr/sbin/nologin可以把shell换成不可登录。系统服务自带的账户保持系统默认不要手动改动它的家目录和shell否则可能影响服务运行。清理完之后顺手检查一下空密码账户和UID为0的非root账户这两个是明显的后门信号# 检查空密码 awk -F: ($2){print $1} /etc/shadow # 检查是否有非root账户的UID是0 awk -F: ($30){print $1} /etc/passwd3.2 密码策略与登录失败锁定在PAM层拉一道闸如果因为业务原因暂时无法全部改成密钥登录密码策略就不能只靠一句“大家自觉设复杂点”。系统层面必须把底线卡死。在/etc/login.defs里至少把这三项改好PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 7密码复杂度由PAM模块控制。Debian系和红帽系的配置路径有差异但核心参数相似。在对应配置文件中加入或修改minlen 12 dcredit -1 ucredit -1 lcredit -1 ocredit -1含义是密码最短12位必须包含数字、大写字母、小写字母和特殊字符至少各一个。这套参数配完之后弱密码基本不可能创建成功。再在PAM的认证链中启用失败锁定防止暴力破解我用的是faillockauth required pam_faillock.so preauth silent audit deny4 unlock_time600 auth required pam_faillock.so authfail audit deny4 account required pam_faillock.so这里deny4表示连续失败4次就锁定unlock_time600表示锁定10分钟。加锁时间不建议设太长否则运维人员自己输错几次密码就吃闭门羹反而容易引发为了解锁而破例改配置的问题。3.3 sudo权限收缩最小授权不是口号很多服务器上的sudo规则都是“给所有人全部权限”理由是省事。省下的是配置的工夫付出的代价是任何一个被攻破的普通账户都拥有整台服务器的控制权。我的做法是定期用visudo检查/etc/sudoers和/etc/sudoers.d/下的文件把两类问题揪出来一类是NOPASSWD:ALL这种完全裸奔的授权另一类是用户根本不需要的ALL权限。收缩时按“谁、在哪些主机上、可以执行哪些命令”的维度重写# 授权deploy用户只重启nginx和reload配置 deploy ALL(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx # 授权ops用户管理SSH服务但不给root shell ops ALL(root) /usr/bin/systemctl reload sshd顺手让每个sudo用户自己确认一下能执行什么也是经常被忽略的习惯。# 查看当前用户能执行的sudo命令 sudo -l最小授权这条原则会带来一点配置上的麻烦但换个角度想你给普通账户越大的权限就等于替攻击者把路铺得越平。4. 策略三从网络层挡人再让fail2ban动手拉黑账户和权限管好之后下一步是让服务器在网络上变得更“低调”。默认情况下一个刚装好的系统会响应外界大部分的探测请求所有端口对外可见防火墙策略基本为零。网络层要做两件事一是把防火墙默认策略改成拒绝只放行必要端口二是对暴力尝试做自动封禁。4.1 防火墙默认策略白名单思维不管是哪个发行版现代Linux系统基本都基于nftables只不过有直接操作和通过firewalld封装两种方式。我习惯使用firewalld做日常管理因为它对常用服务的配置更简单直接的同时对规则做热加载也不容易出错。先把默认区策略收紧让所有未被明确放行的流量都进不来systemctl enable --now firewalld firewall-cmd --set-default-zonedrop然后按需放行必要端口。注意这一步一定要结合第1节的摸底结果别把业务端口漏了。# 放行SSH新端口假设上一节改成了8822 firewall-cmd --permanent --add-port8822/tcp # 放行Web服务 firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps # 应用规则并查看最终效果 firewall-cmd --reload firewall-cmd --list-all这里再把回环接口和已建立连接放行开避免影响本机进程间的正常通信。firewalld的drop区在默认情况下已经允许回环和状态检查但我仍然建议在策略中明确写出来防止后续调整区域时误伤。4.2 fail2ban实战配置重试阈值与封禁时长防火墙是静态的规则fail2ban是动态的响应。它的逻辑很简单监控日志文件里的失败特征连续命中一定次数之后自动调用防火墙把来源IP封掉。配置时不需要追求“封得狠”更关键的是“反应快、误伤少”。我一般在/etc/fail2ban/jail.local里这样写[DEFAULT] ignoreip 127.0.0.1/8 ::1 [sshd] enabled true backend systemd maxretry 3 findtime 600 bantime 3600参数含义findtime600表示在10分钟内maxretry3表示同一来源IP累计出现3次失败就触发封禁bantime3600表示封禁1小时。这个阈值对正常运维人员来说基本不可能误触发——你连输三次密码的时候真的应该停手去确认用户名了而不是继续盲试。启动之后用下面的命令查看封禁状态能直观看到它的工作过程fail2ban-client status sshd fail2ban-client set sshd unbanip 1.2.3.44.3 端口没少开但IP被拉黑了如何验证防护效果曾遇到过一种情况防火墙规则看起来没问题服务也都在监听但某个白名单IP就是连不上。排查到最后发现是fail2ban误封了。这提醒我弄明白之后别急着清封禁先看封禁原因# 查看某个IP被封的匹配日志 grep 1.2.3.4 /var/log/fail2ban.log* # 临时解除封禁如果可以确认是误伤 fail2ban-client set sshd unbanip 1.2.3.4之后我会根据匹配日志调整ignoreip把常用办公网出口IP加入白名单同时适当放宽敏感业务的阈值。网络层这块的核心思路是默认拒绝 只放必要端口 动态封禁暴力来源。三层叠加之后外部扫描对你服务器的噪音会显著减少。5. 策略四内核参数与强制访问控制别让系统“裸奔”很多运维同行觉得内核参数和SELinux是“能不碰就不碰”的领域理由是容易影响业务。这个想法可以理解但有一点值得想清楚默认的Linux权限体系是DAC也就是任何进程只要持有某个用户身份就可以访问该用户能访问的所有资源。一旦某个服务被利用攻击者获得的权限边界和该服务用户完全一致。做内核参数调优和开启强制访问控制本质上就是把进程的权限边界收得更紧。5.1 值得动手的一组内核参数在/etc/sysctl.d/99-security.conf里加下面这些配置然后用sysctl --system加载。每一条我都会解释理由避免变成“照着抄却不知道在改什么”。# 禁止IP转发防止服务器被当成跳板 net.ipv4.ip_forward 0 # 开启反向路径过滤减少IP欺骗 net.ipv4.conf.all.rp_filter 1 net.ipv4.conf.default.rp_filter 1 # 开启TCP SYN cookies缓解SYN Flood攻击 net.ipv4.tcp_syncookies 1 # 忽略ICMP重定向防止路由劫持 net.ipv4.conf.all.accept_redirects 0 net.ipv4.conf.default.accept_redirects 0 # 关闭本机ICMP重定向发送 net.ipv4.conf.all.send_redirects 0 # 忽略广播ping减少被探测的机会 net.ipv4.icmp_echo_ignore_broadcasts 1 # 开启地址空间布局随机化提升缓冲区溢出利用难度 kernel.randomize_va_space 2 # 关闭SysRq键调试功能能降低物理控制台被滥用的风险 kernel.sysrq 0有一点必须提醒rp_filter1在多网卡做策略路由或负载均衡的场景下可能引起丢包。如果机器有这类特殊网络需求改之前先在测试环境验证别直接在现网一改到底。其他的参数影响相对较小因为它们基本都是把安全相关的默认行为从“关闭”改为“开启”。5.2 SELinux/AppArmor开还是不开这段可能是整篇里最容易引起争论的部分。我自己的结论是新装系统尽量让强制访问控制处在enforcing状态尤其是面向公网、跑Web或数据库服务的机器。SELinux和AppArmor的作用不是替代防火墙和用户权限而是当漏洞被利用时多一层“进程没权力做越界操作”的限制。在红帽系系统上我检查当前状态用的命令是getenforce如果当前是disabled而你又不想冒险一步到位可以先用permissive跑一段时间靠下面的命令收集拒绝日志setenforce 1 ausearch -m avc -ts recentpermissive模式下策略不生效但会记录所有本应拒绝的操作等于一个“审计模式”。观察一周把日志中与业务相关的异常拒绝逐一处理掉再切到enforcing。常见的情况是某个服务需要额外放行比如nginx需要与后端通信用setsebool -P httpd_can_network_connect 1就能解决而不是直接关掉SELinux。5.3 遇到被SELinux拦掉的问题别急着关有一次我部署一个应用启动后始终连接不上本地套接字反复排查了权限、防火墙、配置最后在AVC日志里才看到是SELinux拦了进程访问某个目录。当时我对它的第一反应也是“关掉算了”。但现在回头看正确的处理方式分三步# 第一步确认确实是SELinux拦截 ausearch -m avc -ts recent | tail -50 # 第二步根据日志判断是放行某个布尔值还是修正文件上下文 setsebool -P httpd_can_network_connect 1 # 第三步如果不是布尔值问题就调整安全上下文 semanage fcontext -a -t httpd_sys_content_t /data/web(/.*)? restorecon -Rv /data/web这个过程需要一点学习成本但带来的收益是将来再发生类似问题你能够读懂系统在保护什么而不是一昧地“关了重来”。内核参数和MAC强制访问控制这一层是我个人认为一台服务器从“能用”到“敢放公网”的分水岭。6. 策略五审计日志铺好异常就藏不住最后一道策略不直接阻断攻击但是整个加固体系里最容易被人偷懒跳过的一环。很多服务器并不是没被攻破而是被攻破了几个月都没人发现——因为日志没开、没留存、没人看。审计和日志监控让你在攻击完成之后有迹可循是真出事时的救命稻草。6.1 auditd基础规则盯住谁在动关键文件auditd是Linux自带的审计框架可以监控文件、目录和系统调用。我至少会在每台业务服务器上监控这些关键路径# 安装并启动包名一般叫auditd或audit systemctl enable --now auditd # 监控账户和权限相关文件 auditctl -w /etc/passwd -p wa -k identity auditctl -w /etc/shadow -p wa -k identity auditctl -w /etc/sudoers -p wa -k sudoers # 监控root的SSH授权文件 auditctl -w /root/.ssh/authorized_keys -p wa -k ssh_key # 查询与identity标签相关的审计记录 ausearch -k identity -ts today-w指定监控路径-p wa表示记录写入和属性变更-k是给这一组规则打个标签方便检索。这样一旦有人改了sudoers或者往authorized_keys里塞了公钥就能在审计记录里看到是谁、在什么时间、用哪个进程做的操作。我用过几次在定位“配置被谁改过”的问题时这套机制比翻shell历史靠谱得多。6.2 日志持久化别在重启后丢线索默认情况下很多发行版的systemd-journald把日志放在内存里重启之后只剩可怜的一小部分。要做第一步就是把日志目录持久化。编辑/etc/systemd/journald.conf修改Storagepersistent然后重启journald服务确认日志已经写入磁盘systemctl restart systemd-journald journalctl --list-boots--list-boots能看到历次启动的日志都在说明已经生效了。这一步效果也许不像封禁IP那样立竿见影但出了事回头看你会庆幸自己做了。6.3 日常巡检怎么查“异常”有了日志不等于就安全了还得定期看一眼。我个人习惯每周做一次十分钟的快速巡检命令就是那几条# 查看失败登录尝试来源排名 journalctl -t sshd --since 7 days ago | grep Failed password | awk {print $(NF-3)} | sort | uniq -c | sort -rn | head -20 # 查看最近成功登录记录 last -a -n 30 # 检查近期是否新增了sudo授权 grep -r NOPASSWD\|ALL(ALL) /etc/sudoers /etc/sudoers.d/ # 检查所有用户的家目录下是否存在陌生的authorized_keys find /home -name authorized_keys -newer /etc/shadow -mtime -30 2/dev/null看到异常不要慌按时间线把登录记录、audit日志和业务日志对齐通常能看出攻击者的进入路径和操作痕迹。日志这块的投入没有太高技术门槛但它的作用是长期且稳定的——你给系统装了一双眼睛。另外日志的存放策略也要规划好。最基础的做法是把日志写进独立分区避免日志无限增长撑满根分区进一步的做法是配置远程日志服务器。至少先保证日志轮转正常检查一下/etc/logrotate.conf和/etc/logrotate.d/下的配置确保 auth.log、syslog、journald 这类日志按周期切分和压缩。日志一旦爆炸式增长最先失去作用的往往就是那些基于日志做检测的防护工具。收尾一条可以照着操作的落地检查单说了这么多我把整套思路浓缩成一张检查单按顺序走完基本就是一次标准的Linux安全加固了# 摸底阶段 ss -tulnp cut -d: -f1,3,7 /etc/passwd | grep -v nologin sshd -T | grep -E permitrootlogin|passwordauthentication # SSH加固 ssh-keygen -t ed25519 -a 100 # 编辑 /etc/ssh/sshd_config禁密码、限制用户、限尝试次数 sshd -t systemctl reload sshd # 账户与权限 usermod -L 可疑账户 # 编辑 /etc/login.defs 和PAM配置设置密码复杂度和失败锁定 visudo # 收缩过宽的sudo规则 # 网络层 firewall-cmd --set-default-zonedrop fail2ban-client status sshd # 内核与MAC sysctl --system getenforce # 视情况调整为permissive过渡 # 审计与日志 systemctl enable --now auditd # 编辑 /etc/systemd/journald.conf设置Storagepersistent最后分享一点个人的体会安全加固不是“做一次就安心一辈子”的事它更像是定期体检。上面这些策略覆盖的是最常见、最优先的风险面但每台服务器的业务模型不一样你需要在掌握原则之后不断调整规则。我自己在多次实践之后最大的收获是先顶住最大的攻击风险再逐步完善细节不要追求一步到位也不要因为某次误伤就对某个安全机制因噎废食。服务器安全是一场持续的习惯而不是一次性的交付。
上周帮一位朋友处理了一台测试服务器的异常告警登录日志拉到一半我就关了屏幕——短短两个小时里密码嗅探请求刷出来六百多条失败记录IP来自好几个国家和地区。这台机器上其实没有值钱数据但它因为开着默认的22端口、允许root直接密码登录成了公网上一个任人敲门的靶子。处理完之后他问我Linux服务器安全到底应该先从哪儿下手这其实就是我今天想认真梳理的问题。这里说的“Linux系统安全加固”不是某个厂商的安全套件也不是买一套商业软件就完事而是把一台默认状态下的Linux服务器通过配置、权限、网络规则、审计手段逐步收敛到“能被攻破的概率尽可能低、被攻破之后能及时发现”的状态。这篇文章不会啰嗦一大堆理论名词我打算按自己实际做加固的顺序把最关键的五大策略拆开讲清楚动手前的基线摸底、SSH远程入口收敛、账户与权限最小化、网络层拦截与自动封禁、以及审计日志和内核层面的兜底。每一块都有可以直接抄走的命令、配置文件和验证方法适合刚接触服务器运维的初学者也可以作为老手做配置自查时的一份清单。1. 加固前先摸底三分钟看清你的攻击面有些同学一上来就急着改SSH配置、加防火墙规则结果改到一半把业务端口给拦了或者把某个关键用户锁死了。所以我坚持的第一步永远是摸底——先搞清楚这台机器到底暴露了什么再决定动哪里。不摸底就加固跟闭着眼拆弹没什么区别。1.1 为什么先摸底而不是直接上策略默认安装的Linux发行版通常处于一个“半开放”状态系统自带的网络服务没有做限制防火墙规则基本是空的SSH允许密码登录root账户可以直接远程登录。这些都不是“错误”而是为了初始安装方便而留下的宽松默认值。问题是宽松默认值在公网环境下就是给攻击者铺路。摸底的目的有两个第一是列出所有对外暴露的入口和正在运行的服务评估它们是否必要第二是确认哪些用户、哪些配置项和后文提到的加固动作会冲突。举个例子你以为可以直接关掉密码登录但一台服务器上可能有某个旧脚本依赖root密码登录拉取备份你一刀切之后业务就断了。摸底能在动手之前把这些雷排掉。1.2 一套可复制的基线检查命令我一般会在目标机器上依次跑下面这几组命令用一台标配8G内存、单核CPU的云主机来说整个过程不超过三分钟。# 查看所有监听端口以及对应的进程 ss -tulnp # 查看当前系统有哪些可登录用户具备shell的用户 cut -d: -f1,3,7 /etc/passwd | grep -v nologin # 查看SSH当前生效的关键配置 sshd -T | grep -E permitrootlogin|passwordauthentication|port # 查看正在运行的服务单元 systemctl list-units --typeservice --staterunning # 查看防火墙当前状态和规则 firewall-cmd --list-all || nft list ruleset || iptables -L -n # 查看最近的成功登录和失败登录记录需要root last -n 20 lastb -n 20 2/dev/null || echo btmp无记录或权限不足拿结果出来之后我会把发现的问题分成三类必须马上改的、评估后再改的、保持原样的。必须马上改的包括开放了不必要的远程管理端口、存在可登录的异常用户、防火墙规则为空评估后再改的包括某个端口虽然开着但业务确实需要、某个用户虽然带shell但很少使用保持原样的则通常是系统服务本身占用的端口比如时钟同步、容器运行时等。1.3 记录与归类哪些需要动哪些不能动顺手建一个表格贴在服务器备注里很有必要不然过两周你自己都会忘了当初为什么开某个端口。发现问题处理建议对应章节22端口面向全网开放且允许密码登录优先处理改配置、限来源、加防护第2、4节/etc/passwd中存在非root且带bash的业务账户评估用途锁定或限制登录方式第3节防火墙没有默认DROP策略优先处理按白名单重新收口第4节未开启审计日志和登录失败记录持久化评估后补上防止事后无据可查第6节这一轮的产出物不是一堆命令输出而是“这台机器的暴露面清单”。带着这份清单去做后续策略每一条都能想清楚自己为什么这么改。2. 策略一把SSH做成不容易敲开的门SSH就是Linux服务器的入户门。默认配置下的SSH服务对公网开放密码登录开着root还能直接登录——这在现实中相当于门锁是坏的门上还贴了个纸条写着“管理员入口”。所以第一道硬功夫一定是放在SSH上。2.1 为什么SSH永远是第一目标攻击者手里的自动化工具会不断扫描公网IP段一旦发现22端口响应SSH协议就开始用常见用户名和密码字典做暴力尝试。哪怕你的密码是十位以上的混合字符也顶不住分布式脚本的长期轰炸而且服务器日志里会堆满无意义的失败记录干扰你发现其他真实问题。有人会说我密码够复杂不怕爆破。问题是复杂密码防不了“撞库”和“中间人窃听”。更稳妥的方案是彻底关掉密码登录改用密钥对认证。密钥认证的安全性建立在私钥的保密性上攻击者即使截获了网络流量也无法用截获的会话逆推出你的私钥。再加上限制登录用户和来源IP大门才真正算关严了。2.2 五条SSH加固动作从容易到彻底我按操作难度和收益把常用的加固动作排了个优先级生成高强度密钥对并只保留公钥在服务器上。本地执行ssh-keygen -t ed25519 -a 100然后把~/.ssh/id_ed25519.pub的内容追加到服务器的/root/.ssh/authorized_keys。私钥注意加密保存别放在能被其他人读取的目录里。修改/etc/ssh/sshd_config禁止密码登录、禁止root直接密码登录、限制最大认证尝试次数PermitRootLogin prohibit-password PubkeyAuthentication yes PasswordAuthentication no MaxAuthTries 3 ClientAliveInterval 300 ClientAliveCountMax 0严格限制允许登录的用户。如果一台机器只有两三个人需要管直接写明白AllowUsers ops deploy修改默认监听端口能挡掉大部分无差别扫描但不代表安全它只降低了被随机扫描命中的概率。配合fail2ban使用才有意义。开启fail2ban让连续失败的IP自动拉黑具体配置放在第4节一起讲。2.3 验证与回退改SSH配置不会把自己锁在外面改SSH配置最怕一件事改完重启发现自己连接不上了。我的习惯是改完先做语法检查再保持当前会话不退出另开一个新连接去验证。# 第一步语法检查 sshd -t # 第二步重载服务不会断开现有连接 systemctl reload sshd # 第三步另开一个终端用新配置登录验证 # 确认没问题再关掉当前连接万一真把自己锁在外面了也别慌。如果机器有VNC等带外管理入口直接通过它登录改回来如果云控制台支持网页终端用网页终端恢复配置比较推荐。经历过一次之后你就会明白每次要改这种涉及远程管理通道的配置提前开一个备用会话是刻在骨头里的习惯。3. 策略二账户、密码与sudo的最小权限闭环SSH入口管好了还得管门里站着的那些人。服务器上一个多余的带shell账户、一个弱密码、一条过宽的sudo规则前期的入口加固都会白费。这条链路我习惯叫“账户、密码、权限的最小化闭环”。3.1 危险账户清理停用、删除、锁定分清楚先扫一遍系统里有哪些账户可以登录。除了root还可能存在安装软件时自动创建的服务账户、某个前同事留下的个人账户、甚至被入侵者种下的后门账户。对可疑账户判断标准不是“它看起来没什么用”而是“它有没有必要存在、有没有必要带shell”。处理方式有三种对应不同情况确定没用的直接删掉。userdel -r 用户名会连家目录一起删除执行前注意备份需要保留的数据。暂时拿不准但近期不用锁定登录而不是删除。usermod -L 用户名可以锁住密码登录usermod -s /usr/sbin/nologin可以把shell换成不可登录。系统服务自带的账户保持系统默认不要手动改动它的家目录和shell否则可能影响服务运行。清理完之后顺手检查一下空密码账户和UID为0的非root账户这两个是明显的后门信号# 检查空密码 awk -F: ($2){print $1} /etc/shadow # 检查是否有非root账户的UID是0 awk -F: ($30){print $1} /etc/passwd3.2 密码策略与登录失败锁定在PAM层拉一道闸如果因为业务原因暂时无法全部改成密钥登录密码策略就不能只靠一句“大家自觉设复杂点”。系统层面必须把底线卡死。在/etc/login.defs里至少把这三项改好PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 7密码复杂度由PAM模块控制。Debian系和红帽系的配置路径有差异但核心参数相似。在对应配置文件中加入或修改minlen 12 dcredit -1 ucredit -1 lcredit -1 ocredit -1含义是密码最短12位必须包含数字、大写字母、小写字母和特殊字符至少各一个。这套参数配完之后弱密码基本不可能创建成功。再在PAM的认证链中启用失败锁定防止暴力破解我用的是faillockauth required pam_faillock.so preauth silent audit deny4 unlock_time600 auth required pam_faillock.so authfail audit deny4 account required pam_faillock.so这里deny4表示连续失败4次就锁定unlock_time600表示锁定10分钟。加锁时间不建议设太长否则运维人员自己输错几次密码就吃闭门羹反而容易引发为了解锁而破例改配置的问题。3.3 sudo权限收缩最小授权不是口号很多服务器上的sudo规则都是“给所有人全部权限”理由是省事。省下的是配置的工夫付出的代价是任何一个被攻破的普通账户都拥有整台服务器的控制权。我的做法是定期用visudo检查/etc/sudoers和/etc/sudoers.d/下的文件把两类问题揪出来一类是NOPASSWD:ALL这种完全裸奔的授权另一类是用户根本不需要的ALL权限。收缩时按“谁、在哪些主机上、可以执行哪些命令”的维度重写# 授权deploy用户只重启nginx和reload配置 deploy ALL(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx # 授权ops用户管理SSH服务但不给root shell ops ALL(root) /usr/bin/systemctl reload sshd顺手让每个sudo用户自己确认一下能执行什么也是经常被忽略的习惯。# 查看当前用户能执行的sudo命令 sudo -l最小授权这条原则会带来一点配置上的麻烦但换个角度想你给普通账户越大的权限就等于替攻击者把路铺得越平。4. 策略三从网络层挡人再让fail2ban动手拉黑账户和权限管好之后下一步是让服务器在网络上变得更“低调”。默认情况下一个刚装好的系统会响应外界大部分的探测请求所有端口对外可见防火墙策略基本为零。网络层要做两件事一是把防火墙默认策略改成拒绝只放行必要端口二是对暴力尝试做自动封禁。4.1 防火墙默认策略白名单思维不管是哪个发行版现代Linux系统基本都基于nftables只不过有直接操作和通过firewalld封装两种方式。我习惯使用firewalld做日常管理因为它对常用服务的配置更简单直接的同时对规则做热加载也不容易出错。先把默认区策略收紧让所有未被明确放行的流量都进不来systemctl enable --now firewalld firewall-cmd --set-default-zonedrop然后按需放行必要端口。注意这一步一定要结合第1节的摸底结果别把业务端口漏了。# 放行SSH新端口假设上一节改成了8822 firewall-cmd --permanent --add-port8822/tcp # 放行Web服务 firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps # 应用规则并查看最终效果 firewall-cmd --reload firewall-cmd --list-all这里再把回环接口和已建立连接放行开避免影响本机进程间的正常通信。firewalld的drop区在默认情况下已经允许回环和状态检查但我仍然建议在策略中明确写出来防止后续调整区域时误伤。4.2 fail2ban实战配置重试阈值与封禁时长防火墙是静态的规则fail2ban是动态的响应。它的逻辑很简单监控日志文件里的失败特征连续命中一定次数之后自动调用防火墙把来源IP封掉。配置时不需要追求“封得狠”更关键的是“反应快、误伤少”。我一般在/etc/fail2ban/jail.local里这样写[DEFAULT] ignoreip 127.0.0.1/8 ::1 [sshd] enabled true backend systemd maxretry 3 findtime 600 bantime 3600参数含义findtime600表示在10分钟内maxretry3表示同一来源IP累计出现3次失败就触发封禁bantime3600表示封禁1小时。这个阈值对正常运维人员来说基本不可能误触发——你连输三次密码的时候真的应该停手去确认用户名了而不是继续盲试。启动之后用下面的命令查看封禁状态能直观看到它的工作过程fail2ban-client status sshd fail2ban-client set sshd unbanip 1.2.3.44.3 端口没少开但IP被拉黑了如何验证防护效果曾遇到过一种情况防火墙规则看起来没问题服务也都在监听但某个白名单IP就是连不上。排查到最后发现是fail2ban误封了。这提醒我弄明白之后别急着清封禁先看封禁原因# 查看某个IP被封的匹配日志 grep 1.2.3.4 /var/log/fail2ban.log* # 临时解除封禁如果可以确认是误伤 fail2ban-client set sshd unbanip 1.2.3.4之后我会根据匹配日志调整ignoreip把常用办公网出口IP加入白名单同时适当放宽敏感业务的阈值。网络层这块的核心思路是默认拒绝 只放必要端口 动态封禁暴力来源。三层叠加之后外部扫描对你服务器的噪音会显著减少。5. 策略四内核参数与强制访问控制别让系统“裸奔”很多运维同行觉得内核参数和SELinux是“能不碰就不碰”的领域理由是容易影响业务。这个想法可以理解但有一点值得想清楚默认的Linux权限体系是DAC也就是任何进程只要持有某个用户身份就可以访问该用户能访问的所有资源。一旦某个服务被利用攻击者获得的权限边界和该服务用户完全一致。做内核参数调优和开启强制访问控制本质上就是把进程的权限边界收得更紧。5.1 值得动手的一组内核参数在/etc/sysctl.d/99-security.conf里加下面这些配置然后用sysctl --system加载。每一条我都会解释理由避免变成“照着抄却不知道在改什么”。# 禁止IP转发防止服务器被当成跳板 net.ipv4.ip_forward 0 # 开启反向路径过滤减少IP欺骗 net.ipv4.conf.all.rp_filter 1 net.ipv4.conf.default.rp_filter 1 # 开启TCP SYN cookies缓解SYN Flood攻击 net.ipv4.tcp_syncookies 1 # 忽略ICMP重定向防止路由劫持 net.ipv4.conf.all.accept_redirects 0 net.ipv4.conf.default.accept_redirects 0 # 关闭本机ICMP重定向发送 net.ipv4.conf.all.send_redirects 0 # 忽略广播ping减少被探测的机会 net.ipv4.icmp_echo_ignore_broadcasts 1 # 开启地址空间布局随机化提升缓冲区溢出利用难度 kernel.randomize_va_space 2 # 关闭SysRq键调试功能能降低物理控制台被滥用的风险 kernel.sysrq 0有一点必须提醒rp_filter1在多网卡做策略路由或负载均衡的场景下可能引起丢包。如果机器有这类特殊网络需求改之前先在测试环境验证别直接在现网一改到底。其他的参数影响相对较小因为它们基本都是把安全相关的默认行为从“关闭”改为“开启”。5.2 SELinux/AppArmor开还是不开这段可能是整篇里最容易引起争论的部分。我自己的结论是新装系统尽量让强制访问控制处在enforcing状态尤其是面向公网、跑Web或数据库服务的机器。SELinux和AppArmor的作用不是替代防火墙和用户权限而是当漏洞被利用时多一层“进程没权力做越界操作”的限制。在红帽系系统上我检查当前状态用的命令是getenforce如果当前是disabled而你又不想冒险一步到位可以先用permissive跑一段时间靠下面的命令收集拒绝日志setenforce 1 ausearch -m avc -ts recentpermissive模式下策略不生效但会记录所有本应拒绝的操作等于一个“审计模式”。观察一周把日志中与业务相关的异常拒绝逐一处理掉再切到enforcing。常见的情况是某个服务需要额外放行比如nginx需要与后端通信用setsebool -P httpd_can_network_connect 1就能解决而不是直接关掉SELinux。5.3 遇到被SELinux拦掉的问题别急着关有一次我部署一个应用启动后始终连接不上本地套接字反复排查了权限、防火墙、配置最后在AVC日志里才看到是SELinux拦了进程访问某个目录。当时我对它的第一反应也是“关掉算了”。但现在回头看正确的处理方式分三步# 第一步确认确实是SELinux拦截 ausearch -m avc -ts recent | tail -50 # 第二步根据日志判断是放行某个布尔值还是修正文件上下文 setsebool -P httpd_can_network_connect 1 # 第三步如果不是布尔值问题就调整安全上下文 semanage fcontext -a -t httpd_sys_content_t /data/web(/.*)? restorecon -Rv /data/web这个过程需要一点学习成本但带来的收益是将来再发生类似问题你能够读懂系统在保护什么而不是一昧地“关了重来”。内核参数和MAC强制访问控制这一层是我个人认为一台服务器从“能用”到“敢放公网”的分水岭。6. 策略五审计日志铺好异常就藏不住最后一道策略不直接阻断攻击但是整个加固体系里最容易被人偷懒跳过的一环。很多服务器并不是没被攻破而是被攻破了几个月都没人发现——因为日志没开、没留存、没人看。审计和日志监控让你在攻击完成之后有迹可循是真出事时的救命稻草。6.1 auditd基础规则盯住谁在动关键文件auditd是Linux自带的审计框架可以监控文件、目录和系统调用。我至少会在每台业务服务器上监控这些关键路径# 安装并启动包名一般叫auditd或audit systemctl enable --now auditd # 监控账户和权限相关文件 auditctl -w /etc/passwd -p wa -k identity auditctl -w /etc/shadow -p wa -k identity auditctl -w /etc/sudoers -p wa -k sudoers # 监控root的SSH授权文件 auditctl -w /root/.ssh/authorized_keys -p wa -k ssh_key # 查询与identity标签相关的审计记录 ausearch -k identity -ts today-w指定监控路径-p wa表示记录写入和属性变更-k是给这一组规则打个标签方便检索。这样一旦有人改了sudoers或者往authorized_keys里塞了公钥就能在审计记录里看到是谁、在什么时间、用哪个进程做的操作。我用过几次在定位“配置被谁改过”的问题时这套机制比翻shell历史靠谱得多。6.2 日志持久化别在重启后丢线索默认情况下很多发行版的systemd-journald把日志放在内存里重启之后只剩可怜的一小部分。要做第一步就是把日志目录持久化。编辑/etc/systemd/journald.conf修改Storagepersistent然后重启journald服务确认日志已经写入磁盘systemctl restart systemd-journald journalctl --list-boots--list-boots能看到历次启动的日志都在说明已经生效了。这一步效果也许不像封禁IP那样立竿见影但出了事回头看你会庆幸自己做了。6.3 日常巡检怎么查“异常”有了日志不等于就安全了还得定期看一眼。我个人习惯每周做一次十分钟的快速巡检命令就是那几条# 查看失败登录尝试来源排名 journalctl -t sshd --since 7 days ago | grep Failed password | awk {print $(NF-3)} | sort | uniq -c | sort -rn | head -20 # 查看最近成功登录记录 last -a -n 30 # 检查近期是否新增了sudo授权 grep -r NOPASSWD\|ALL(ALL) /etc/sudoers /etc/sudoers.d/ # 检查所有用户的家目录下是否存在陌生的authorized_keys find /home -name authorized_keys -newer /etc/shadow -mtime -30 2/dev/null看到异常不要慌按时间线把登录记录、audit日志和业务日志对齐通常能看出攻击者的进入路径和操作痕迹。日志这块的投入没有太高技术门槛但它的作用是长期且稳定的——你给系统装了一双眼睛。另外日志的存放策略也要规划好。最基础的做法是把日志写进独立分区避免日志无限增长撑满根分区进一步的做法是配置远程日志服务器。至少先保证日志轮转正常检查一下/etc/logrotate.conf和/etc/logrotate.d/下的配置确保 auth.log、syslog、journald 这类日志按周期切分和压缩。日志一旦爆炸式增长最先失去作用的往往就是那些基于日志做检测的防护工具。收尾一条可以照着操作的落地检查单说了这么多我把整套思路浓缩成一张检查单按顺序走完基本就是一次标准的Linux安全加固了# 摸底阶段 ss -tulnp cut -d: -f1,3,7 /etc/passwd | grep -v nologin sshd -T | grep -E permitrootlogin|passwordauthentication # SSH加固 ssh-keygen -t ed25519 -a 100 # 编辑 /etc/ssh/sshd_config禁密码、限制用户、限尝试次数 sshd -t systemctl reload sshd # 账户与权限 usermod -L 可疑账户 # 编辑 /etc/login.defs 和PAM配置设置密码复杂度和失败锁定 visudo # 收缩过宽的sudo规则 # 网络层 firewall-cmd --set-default-zonedrop fail2ban-client status sshd # 内核与MAC sysctl --system getenforce # 视情况调整为permissive过渡 # 审计与日志 systemctl enable --now auditd # 编辑 /etc/systemd/journald.conf设置Storagepersistent最后分享一点个人的体会安全加固不是“做一次就安心一辈子”的事它更像是定期体检。上面这些策略覆盖的是最常见、最优先的风险面但每台服务器的业务模型不一样你需要在掌握原则之后不断调整规则。我自己在多次实践之后最大的收获是先顶住最大的攻击风险再逐步完善细节不要追求一步到位也不要因为某次误伤就对某个安全机制因噎废食。服务器安全是一场持续的习惯而不是一次性的交付。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
