老旧服务器在当下的网络环境中，往往不是因为计算能力不足而崩溃，而是因为默认配置、过期组件和缺乏精细化防护策略，被低成本攻击直接打穿。漏洞利用和DDoS流量洪峰经常是组合出现的，攻击者先用漏洞拿到权限或触发高消耗行为，再配合流量攻击放大破坏效果。所以防护思路不能只盯着带宽，必须从系统层、服务层、网络层同时收紧。
先处理最容易被忽略的漏洞面老旧服务器最常见的漏洞不是某个具体CVE，而是长期未更新的中间件和语言运行环境。Apache 2.2、旧版OpenSSL、PHP 5.x、老版本Tomcat，这些组件即使业务代码没问题，自身暴露的已知漏洞也足以让攻击者直接执行命令或读取敏感文件。检查方式很简单：用包管理器列出已安装版本，对照发行版的安全公告，凡是已经停止维护的版本一律升级或隔离。如果业务确实无法升级，至少要在反向代理层屏蔽掉不必要的HTTP方法，并对管理后台路径做IP白名单。
另一个高频问题是目录遍历和文件上传限制缺失。很多老站点允许访问/uploads/目录下的任意文件，或者上传目录本身可执行脚本。攻击者上传一个webshell后，不仅能篡改页面，还能利用服务器作为跳板发起对内网的扫描。防护上必须做到上传目录与执行权限分离，上传的文件只允许静态读取，不允许任何脚本解释器介入。Nginx下可以用location匹配上传目录，明确禁止PHP解析；Apache则通过RemoveHandler和php_admin_flag engine off来实现。
SSH和远程管理入口的加固老旧服务器被入侵的另一个主要入口是SSH弱口令或使用默认端口。很多运维觉得改了端口就安全了，实际上端口扫描成本极低，真正有效的是禁用密码登录、只允许密钥认证，并且限制来源IP。如果必须保留密码登录，至少启用fail2ban类的登录失败封禁机制，同时把登录失败阈值调到很低。root账户直接登录应该彻底关闭，普通用户通过sudo提权，这样即使单点被爆破，攻击者拿到的也不是最高权限。
对于Windows老服务器，远程桌面端口暴露在公网是极其危险的。建议通过防火墙只放行特定办公网段，或者使用跳板机中转。系统自带的账户锁定策略要开启，管理员账户改名，并定期审计登录日志。很多入侵事件事后复盘发现，攻击者在被攻破前已经进行了长达数周的弱口令尝试，只是没有触发任何告警。
DDoS防御要从协议层开始优化老旧服务器面对DDoS时最容易犯的错误是只关注带宽大小，忽略了协议栈和内核参数的调优。SYN Flood攻击在百兆级别就能让一台默认配置的老服务器瘫痪，因为半连接队列很快被占满。Linux内核中net.ipv4.tcp_syncookies应当开启，net.ipv4.tcp_max_syn_backlog和net.ipv4.tcp_synack_retries需要根据内存和业务类型调整。开启syncookies后，服务器不再为每个SYN分配完整连接资源，而是用算法验证客户端真实性，能有效缓解中小规模SYN Flood。
对于UDP Flood和ICMP Flood，老旧服务器上如果业务不依赖这些协议，最直接的做法是在边界防火墙或云安全组直接丢弃。很多情况下服务器本身并没有UDP服务，攻击流量却依然消耗着入站带宽和CPU中断处理资源。在iptables中可以对非业务端口设置DROP而非REJECT，减少响应包的产生。同时限制ICMP速率，只允许必要的ping回应。
# 开启SYN Cookie sysctl -w net.ipv4.tcp_syncookies=1 # 增大半连接队列 sysctl -w net.ipv4.tcp_max_syn_backlog=8192 # 减少SYN+ACK重试次数 sysctl -w net.ipv4.tcp_synack_retries=2 # 限制ping速率 iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --limit-burst 5 -j ACCEPT iptables -A INPUT -p icmp --icmp-type echo-request -j DROP应用层DDoS比流量型攻击更难防
老旧服务器上跑的动态页面往往是应用层DDoS的最佳目标。攻击者不需要多大带宽，只要反复请求搜索接口、数据库查询页面或登录接口，就能让CPU和数据库连接数耗尽。这类攻击的特征是请求本身合法，但单次请求消耗资源极高。防护的关键在于识别和限制异常请求模式，而不是简单封IP。
Nginx和Apache都可以配置连接数限制和请求速率限制。Nginx的limit_req模块可以对单个IP的请求频率做精确控制，limit_conn则限制并发连接数。对于搜索、登录等敏感接口，应该设置比普通页面更严格的阈值。例如普通页面允许每秒10个请求，登录接口只允许每分钟5次尝试。超出限制后返回444或503，而不是直接放行。
# Nginx 请求速率限制配置示例
http {
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
server {
location /login {
limit_req zone=login burst=3 nodelay;
proxy_pass http://backend;
}
location / {
limit_req zone=general burst=20 nodelay;
proxy_pass http://backend;
}
}
}
数据库连接池的耗尽也是常见问题。老旧应用往往没有对数据库查询做超时控制，一个慢查询就能占住连接几十秒。攻击者利用这一点，并发请求大量复杂查询，很快就能让连接池满。优化上要为所有数据库操作设置合理超时，对前端请求做最大执行时间限制，并在应用层增加缓存，避免相同查询反复打到数据库。
利用反向代理和CDN分担压力老旧服务器本身性能有限，直接暴露在公网面对攻击时，很容易在流量到达应用层之前就把带宽或CPU耗尽。在架构上增加一层反向代理或CDN是性价比较高的做法。反向代理可以终止SSL、缓存静态资源、过滤恶意请求，只有通过验证的请求才会转发到源站。源站服务器甚至可以只监听内网地址，彻底不暴露公网IP。
对于没有预算上商业CDN的场景，可以自建Nginx反向代理节点，部署在带宽较大的VPS上。源站与代理之间通过专线或VPN隧道通信，代理节点承担大部分流量和攻击。需要注意的是，代理节点本身也要做内核调优和请求限制，否则攻击者直接打代理节点一样有效。代理层还可以根据User-Agent、Referer和请求路径做初步过滤，把明显的扫描器和攻击工具拦截在外层。
日志监控和自动化响应防护策略部署后，没有监控就等于没有防护。老旧服务器上至少要做到对关键日志的实时分析，包括SSH登录失败、Web服务器错误码突增、异常请求路径等。使用轻量级工具如fail2ban、logwatch或自定义脚本定期检查日志，发现异常后自动调用iptables封禁或触发告警。很多攻击在造成实际损害前会有明显的侦察行为，比如批量扫描常见漏洞路径、尝试访问/admin/、/phpmyadmin/等敏感目录，这些行为在日志中非常清晰。
自动化响应方面，可以设置当某个IP在短时间内触发多次404或403时自动加入黑名单。对于更复杂的应用层攻击，需要结合请求特征做动态限速。例如检测到某个IP对同一URL的请求间隔极短且参数高度相似，可以直接在Nginx层返回444。这些规则不需要很复杂，但必须持续运行，否则攻击者换个IP就能绕过。
老旧系统的定期加固与备份很多老旧服务器之所以一直带病运行，是因为运维担心升级会破坏现有业务。实际上，不升级的风险远大于升级可能带来的短暂中断。至少每个月要评估一次系统补丁状态，对高危漏洞做到及时修补。如果业务无法停机，可以采用灰度升级或先在新环境验证再切换的方式。备份同样关键，很多服务器在遭受攻击后数据被加密或删除，没有备份就只能支付赎金。备份要做到异地存储、定期恢复演练，确保在极端情况下能快速重建。
最终，老旧服务器的安全防护是一个持续收紧的过程，不是一次性的配置工作。攻击手段在不断变化，防护策略也要跟着调整。把漏洞面缩到最小、把请求路径管住、把异常行为拦住，即使硬件老旧，也能在相当长的时间内稳定运行。
