老旧服务器部署网站的漏洞防护优化技巧

接手一台跑了七八年的旧服务器，上面还装着 CentOS 6 或者 Windows Server 2008，跑着 PHP 5.3 和老旧的 Tomcat，这事儿放现在简直是一场噩梦。但现实就是这样，很多企业的核心业务系统、老旧的 OA、财务软件，根本没法说迁移就迁移。硬件老化、系统停更、依赖库陈旧，这些漏洞就像筛子一样，攻击者随便扫一扫就能进来。这种情况下谈安全防护，不能照搬云原生那套打法，得用“修修补补但有效”的思路，把篱笆扎紧。

老服务器最怕的不是漏洞多，而是你根本不知道上面跑了多少东西。拿到机器第一件事，不是打补丁，而是做端口和进程的全面盘点。用 netstat -tunlp 或者 ss -tunlp 把全部监听端口拉出来，你会发现很多“惊喜”：测试时装的 Redis 开着无密码的 6379，某个运维三年前装的 zabbix-agent 还在跑，甚至还有忘了关的 VNC 远程桌面。这些东西必须一刀切地关掉。

Linux 下用 systemctl 或 service 停掉非必需服务，再用 chkconfig 或 systemctl disable 禁止开机自启。Windows 下进 services.msc，把 Print Spooler、Remote Registry 这些高危但用不上的服务直接禁用。特别注意那些带管理面板的组件，比如 phpMyAdmin、Tomcat Manager、Jenkins，如果必须保留，一定要改掉默认路径，加上 IP 白名单和强密码认证。攻击面每缩小一寸，被攻破的概率就降低一分。

老系统最大的痛点是官方停止安全更新。CentOS 6 在 2020 年就 EOL 了，Windows Server 2008 R2 也早已停服。没有新补丁，但系统还得用，这时候就得靠配置层面的软加固来弥补。

内核参数调优是性价比最高的防护手段。编辑 /etc/sysctl.conf，开启 SYN Cookie 防护、禁用 IP 源路由、忽略 ICMP 重定向、开启反向路径过滤，这些配置能有效抵御常见的 DDoS 和 IP 欺骗攻击。具体参数可以这样写：

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1

账户策略同样关键。检查 /etc/passwd 里哪些账户能登录 shell，把无关的系统账户 shell 改成 /sbin/nologin。强化 SSH 配置，禁用 root 直接登录，改成密钥认证，把默认的 22 端口改掉虽然只是障眼法，但能过滤掉 90% 的自动化扫描。在 /etc/ssh/sshd_config 里设置 PermitRootLogin no 和 PasswordAuthentication no，重启 sshd 就生效。

老服务器上跑的 Web 环境往往是 Apache 2.2 或者 IIS 7，这些老版本 HTTP 解析器本身就有很多已知漏洞。直接把它们暴露在公网上等于裸奔。一个非常有效的架构调整是在前面加一层反向代理，用 Nginx 或者 HAProxy 挡在最外层。

反向代理能做的事情远超你的想象。它可以过滤掉畸形 HTTP 请求、限制请求速率、拦截特定 User-Agent 和恶意扫描特征。比如用 Nginx 的 limit_req 模块做频率限制，用 map 和 if 指令直接返回 444 断开可疑连接。老旧的 Apache 只监听 127.0.0.1，不直接对外，这样即使 Apache 存在解析漏洞，攻击者也很难直接利用。这种“外新内老”的架构，是让老系统续命的关键一招。

Nginx 的配置示例可以这样写，把真实服务器隐藏在后面：

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    # 过滤特定攻击路径
    if ($request_uri ~* "(\.\./|\.sql|\.git)") {
        return 403;
    }
}

老网站最容易被挂马和拖库，根源往往不是注入漏洞本身，而是数据库账号权限过大和文件系统权限配置不当。很多老 PHP 应用用的都是 root 账号连 MySQL，这在今天看来是不可接受的。必须立即创建一个仅拥有对应数据库 CRUD 权限的专用账号，并且限制其登录 IP 为 localhost 或内网地址。

文件系统权限方面，老应用经常需要上传目录有写权限，但绝不能有执行权限。很多运维图省事直接 chmod 777，这等于给攻击者开了后门。正确的做法是，所有静态资源目录去掉执行权限，上传目录单独分区或挂载，加上 noexec 挂载选项。Linux 下用 mount -o remount,noexec /var/www/html/uploads 这样的命令，就能在保留写入能力的同时，阻断 webshell 的执行。这个技巧在护网行动里被反复验证过，极其有效。

系统老了，代码旧了，漏洞一定存在，只是你还没发现。这时候主机层面的 WAF 和实时日志分析就成了兜底的安全网。开源的 ModSecurity 虽然规则写起来复杂，但配合 OWASP 核心规则集，能拦截绝大多数 SQL 注入、XSS 和文件包含攻击。把它编译进 Nginx 或者 Apache 里，设置成只记录不拦截的模式先跑一周，观察误报情况后再切换为阻断模式。

日志监控比 WAF 更重要。很多安全事件在爆发前都有征兆，比如短时间内大量 404 请求、对 /wp-admin 或 /manager 路径的暴力扫描。用 fail2ban 监控 access.log 和 auth.log，设置阈值自动封禁 IP，这个工具在老服务器上运行几乎不占资源，但效果立竿见影。配置一个简单的 jail，比如连续 5 次 404 就封禁 1 小时，能有效拖慢扫描器的节奏。

老应用代码里，SQL 注入、文件上传不校验、反序列化漏洞是最常见的三类致命问题。在不做大改的前提下，有几个快速止血的办法。对于 SQL 注入，如果代码里用的是 mysql_query 这种已废弃的函数，无法快速切换到 PDO 预处理，那么至少在入口处做统一的参数过滤。写一个全局的过滤函数，对 GET、POST、COOKIE 参数做一次 addslashes 或者更严格的关键字过滤，虽然不能根治，但能挡住大部分盲注尝试。

文件上传漏洞的临时修复，重点在校验文件头而不是扩展名。攻击者经常把 PHP 代码藏在图片文件头后面上传，所以要用 getimagesize 或 file 命令检查文件的真实 MIME 类型。如果业务不需要上传功能，直接在 Web 服务器配置里对上传目录禁用脚本解析。Nginx 下加一句 location ~* /uploads/.*\.php$ { deny all; }，Apache 下用 .htaccess 加 php_flag engine off，简单粗暴但极其管用。

别把所有希望都寄托在服务器自身的防护上。老服务器应该被纳入一个更严密的网络隔离环境中。在防火墙上做严格的出入站规则，只开放必要的 80 和 443 端口，管理端口如 22、3389 必须通过堡垒机或者 VPN 才能访问。如果条件允许，把老服务器放在一个独立的 VLAN 里，和内网其他机器做好隔离，防止一台被攻破后横向移动。

对于不得不暴露的管理后台，加一层 HTTP 基本认证是最低成本的额外防护。在 Nginx 里用 auth_basic 指令，或者 Apache 里用 htpasswd 生成密码文件，这样即使应用本身的管理入口存在弱口令，攻击者也需要先突破这层 HTTP 认证才能接触到登录页面。这种多层防御的思路，是应对未知漏洞最务实的策略。

防护做得再好，也要假设老服务器总有一天会出事。硬件故障、勒索病毒、0day 漏洞，任何一样都能让业务停摆。必须建立离线备份机制，每天把数据库和关键文件同步到另一台机器或者磁带机上，备份数据要和原服务器在物理或逻辑上隔离，防止勒索病毒一并加密。

准备一份针对这台老服务器的应急响应手册，写清楚服务如何快速重启、数据如何恢复、攻击日志从哪里提取。别等到真出事了才手忙脚乱去翻文档。定期做一次桌面推演，验证备份能不能真的还原，服务能不能在半小时内拉起来。这套底线思维，才是老旧服务器防护体系里最后也是最坚固的一道防线。

老旧服务器的安全防护，本质上不是一场追求完美防御的战斗，而是一场管理风险的持久战。你不可能把它变成一台固若金汤的新机器，但你可以通过层层设防、权限收缩、行为监控和快速恢复能力，把被攻破的概率和出事后损失降到最低。每一层防护都不需要做到 100% 有效，但五六层 80% 有效的手段叠加起来，就能让绝大多数攻击者知难而退，转而去寻找更容易的目标。这种务实的、工程化的防护哲学，才是老系统在数字世界里活下去的真正底气。