1. 项目概述一次DDoS攻击引发的安全组反思前几天我负责维护的一台线上业务服务器突然失联了。不是简单的服务卡顿而是整个SSH连接超时监控面板上的公网出带宽直接拉满到上限CPU使用率却低得可怜。第一反应是“被打了”——典型的分布式拒绝服务攻击。紧急联系云服务商果然控制台告警显示该实例因对外攻击已被临时阻断。一通手忙脚乱的排查、解封、溯源后根源竟指向一个我们自以为“万无一失”的配置云服务器安全组。我们严格按照“最小权限原则”只开放了80、443和特定IP的22端口看似固若金汤。但攻击流量并非从这些端口涌入而是利用了安全组一个常被忽略的“隐形”特性结合服务器自身的Linux防火墙iptables/firewalld的默认策略形成了一道致命的组合漏洞。这次事件让我深刻意识到很多运维和开发者对云上安全的理解可能还停留在“设好安全组就万事大吉”的层面。安全组是云平台提供的虚拟防火墙用于控制实例级别的入站和出站流量它是安全的第一道闸门。然而这道闸门如果设置不当或者你误以为它是一堵密不透风的墙那么风险就会在眼皮底下滋生。尤其是在应对DDoS这种海量畸形流量攻击时安全组的规则逻辑、与操作系统防火墙的联动、以及对“允许”与“拒绝”的深层理解都至关重要。本文将结合这次真实的攻防经历拆解云服务器安全组配置中那些容易被忽视的“隐形”风险点并深入探讨Linux防火墙在云环境下的正确姿势。无论你是使用阿里云、腾讯云还是华为云只要你的业务跑在云上这些坑都可能已经埋下。2. 安全组与Linux防火墙双保险还是双漏洞在云环境中网络安全通常被设计为分层防御体系。最外层是云平台自身的DDoS高防、WAF等产品中间层就是安全组最内层则是操作系统自带的主机防火墙如CentOS/RHEL系的firewalld或更底层的iptables以及Ubuntu/Debian系的ufw。理想情况下它们应该协同工作构成纵深防御。但现实中如果配置不当它们可能互相冲突甚至制造出更大的安全盲区。2.1 安全组的工作原理与常见误区安全组是一种有状态的虚拟防火墙。所谓“有状态”意味着如果你设置了一条允许入站Inbound的规则那么对应的出站Outbound响应流量会被自动允许无需额外配置出站规则。这简化了配置但也容易让人产生误解。最常见的几个配置误区只配入站不配出站或出站全开很多人认为业务只需要被访问所以只精心配置入站规则出站规则则保持默认的“允许所有”。这是一个巨大的风险点。如果服务器被入侵攻击者可以利用这台服务器作为跳板对外发起扫描、攻击或数据泄露。例如恶意脚本可以通过出站连接将敏感数据上传到外部存储或作为DDoS攻击的傀儡机对外发送大量流量。我们的案例中服务器被检测到“对外攻击”极有可能就是出站规则过于宽松导致的。对“0.0.0.0/0”的滥用在配置入站规则时为了方便测试临时对某个端口如22或3306开放了源地址为0.0.0.0/0即所有IP的访问之后却忘了删除。这相当于在互联网上挂了一个告示牌告诉所有扫描器“此处有门可入”。对于管理端口必须使用特定的IP或CIDR地址段。忽略协议类型安全组规则需要指定协议如TCP, UDP, ICMP。有时为了Ping通服务器会开放ICMP协议。但在DDoS攻击中ICMP Flood是一种常见的攻击手段。非必要情况下建议在公网入口关闭ICMP Echo Request即ping。规则优先级理解不清安全组规则按优先级数字从小到大的顺序执行。当一条流量匹配到某条规则后后续规则不再执行。常见的错误是设置了一条低优先级数字大如100的“拒绝所有”规则但前面有一条高优先级数字小如1的“允许所有”规则导致“拒绝所有”完全失效。正确的做法是将具体的允许规则设置为高优先级最后一条设置为低优先级的“拒绝所有”作为默认兜底。2.2 Linux防火墙的“默认放行”陷阱现在我们来到这次事件的核心Linux主机防火墙与安全组的交互。以最常用的firewalld为例它有几个默认zone如public、trusted、drop。新安装的系统网卡通常位于publiczone。关键风险点在于publiczone的默认策略。在未做任何自定义配置时firewalld的publiczone默认是允许所有出站连接拒绝所有入站连接除了与已建立连接相关的数据包。这听起来很安全对吗问题就出在这个“除了”。这个“除了”指的是状态防火墙的ESTABLISHED, RELATED状态跟踪。简单来说一旦有一个从内部发起的出站连接建立成功其后续的入站响应流量会被自动允许。这本是为了保障通信的正常进行。但是在云服务器场景下这个机制与安全组结合会产生一个致命漏洞假设你的安全组出站规则是“允许所有”默认或手动设置。那么服务器上的任何进程都可以自由地对外发起连接。如果服务器上存在恶意软件、被植入的后门、或者一个有漏洞的应用程序例如一个被利用的Redis未授权访问可以执行CONFIG SET dir和SAVE命令写入计划任务攻击者就可以利用这个出站通道“反向”建立一个连接到你的服务器。由于这个连接是从你的服务器内部主动发起的在Linux防火墙看来这是一个合法的出站连接及其相关的入站响应firewalld的默认规则会允许这部分流量通过。而此时安全组的入站规则可能对此毫不知情因为流量在状态跟踪下被视为“已建立连接”的一部分而非新的入站请求。这就成功绕过了安全组对入站流量的严格限制。实操心得永远不要认为安全组是唯一的屏障。主机防火墙的默认行为必须被重新审视和加固。在云上主机防火墙的策略应该比在物理服务器中更加严格。2.3 联动失效的典型场景除了上述的“反向shell”场景联动失效还体现在端口扫描与响应安全组拒绝了某个端口的访问但服务器上的服务依然在监听该端口。当攻击者进行端口扫描时虽然TCP SYN包会被安全组丢弃但服务器本身如果未关闭不必要的服务仍然存在潜在风险。一旦安全组规则被误修改或云平台出现极端情况虽然概率极低服务将直接暴露。DDoS攻击下的资源耗尽安全组可以过滤数据包但过滤动作本身需要消耗云平台虚拟化层的CPU资源。当遭遇超大流量的DDoS攻击时即使所有恶意包都被安全组拒绝海量的包处理请求也可能耗尽实例所在物理宿主机的资源导致同宿主机的其他正常实例受到影响“邻居效应”最终你的实例可能因资源耗尽而瘫痪或被迫进入“黑洞”。此时主机防火墙完全帮不上忙。3. 实战构建纵深防御的安全配置策略理解了风险接下来就是如何构建一个真正有效的防御体系。我们的目标不是追求绝对安全那不存在而是将风险降到可接受的水平并确保在遭受攻击时能快速响应和恢复。3.1 安全组最佳配置实践遵循最小权限原则细化到端口和IP入站规则像雕刻一样精细。Web服务器只开放80/443数据库服务器只对应用服务器IP开放3306/5432等端口SSH/RDP只对运维IP开放。使用“安全组ID”作为源如果同VPC内是更佳选择比IP更灵活。出站规则同样重要不要允许所有。只开放业务必要的出站端口。例如需要调用外部API只允许访问该API服务的IP和端口需要yum/apt更新只允许访问内网镜像源或特定官方源IP的80/443端口通常不需要允许出站的SSH22或数据库端口。一个Web服务器的安全组规则示例以表格形式呈现更清晰规则方向优先级协议类型端口范围源/目的地址策略说明入站1TCP80, 4430.0.0.0/0允许允许公网HTTP/HTTPS访问入站2TCP22106.120.xxx.xxx/32允许仅允许办公室固定IP SSH入站100ALLALL0.0.0.0/0拒绝默认拒绝所有其他入站出站1TCP4430.0.0.0/0允许允许对外HTTPS请求如调用API出站2TCP800.0.0.0/0允许允许对外HTTP请求出站3TCP53, UDP53100.100.2.136/32, 100.100.2.138/32允许出站100ALLALL0.0.0.0/0拒绝默认拒绝所有其他出站善用安全组作为“白名单”将不同的业务层Web层、应用层、数据层部署在不同的安全组内通过安全组之间互相授权来访问而不是直接使用IP地址。这样当服务器IP变更时无需修改大量规则。定期审计与清理利用云监控或配置审计服务定期检查安全组规则变更日志。清理掉那些来源是“0.0.0.0/0”的临时规则、测试规则和不再使用的规则。3.2 Linux防火墙加固配置针对firewalld我们需要修改其默认行为使其在云环境中起到真正的补充作用。修改默认zone的策略核心步骤 我们不直接使用dropzone可能导致某些云助手或监控agent异常而是修改publiczone的默认策略为更严格的default并显式定义规则。# 查看当前默认zone和规则 sudo firewall-cmd --list-all # 设置默认的入站策略为拒绝出站策略为拒绝我们将手动允许需要的 # 注意此操作会断网务必在本地控制台或通过已有会话操作并提前准备好放行规则 sudo firewall-cmd --permanent --set-targetDROP # 重新加载使永久生效 sudo firewall-cmd --reload警告执行--set-targetDROP后所有未匹配到允许规则的入站流量都将被丢弃。你必须在此之前通过firewall-cmd --permanent --add-servicessh --zonepublic等方式确保你的当前SSH连接IP和端口已被允许否则会立即断开连接最好在云控制台的VNC终端里操作。显式允许必要的服务和端口# 允许SSH假设端口22且你的IP已通过安全组过滤 sudo firewall-cmd --permanent --add-servicessh # 允许HTTP/HTTPS sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --permanent --add-servicehttps # 如果需要允许特定端口如3000 sudo firewall-cmd --permanent --add-port3000/tcp # 允许出站DNS解析 sudo firewall-cmd --permanent --add-servicedns # 允许出站到特定IP的特定端口例如连接内网Redis sudo firewall-cmd --permanent --add-rich-rulerule familyipv4 destination address10.0.1.10 port port6379 protocoltcp accept # 重新加载 sudo firewall-cmd --reload使用富规则Rich Rules进行更精细的控制 富规则功能强大可以限制连接速率这对缓解CC攻击有一定效果。# 限制每个IP地址每分钟最多新建10个HTTP连接超过则拒绝 sudo firewall-cmd --permanent --add-rich-rulerule familyipv4 service namehttp limit value10/m accept # 允许来自特定IP段的SSH连接 sudo firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.0/24 service namessh accept3.3 系统层与应用层加固安全组和主机防火墙是网络层防护系统自身也需要加固。关闭不必要的服务与端口使用netstat -tunlp或ss -tunlp查看所有监听端口停用并禁用非必需的服务如bluetooth,cups等。内核参数调优调整/etc/sysctl.conf中的网络参数增强抗DDoS能力。# 编辑sysctl配置 sudo vim /etc/sysctl.conf # 添加或修改以下参数 net.ipv4.tcp_syncookies 1 # 开启SYN Cookies防SYN Flood net.ipv4.tcp_max_syn_backlog 2048 # 增加SYN队列长度 net.ipv4.tcp_synack_retries 2 # 减少SYNACK重试次数 net.ipv4.tcp_syn_retries 2 # 减少SYN重试次数 net.ipv4.icmp_echo_ignore_all 1 # 忽略所有ping根据需求设置 net.ipv4.conf.all.rp_filter 1 # 开启反向路径过滤防IP欺骗 net.ipv4.conf.default.rp_filter 1 # 使配置生效 sudo sysctl -p应用程序配置确保Web服务器Nginx/Apache有连接数限制、请求速率限制模块。对于数据库禁止公网访问使用强密码和最小权限账户。4. 遭遇DDoS攻击时的应急响应与排查流程当监控告警响起怀疑遭遇DDoS攻击时切忌慌乱。按照以下流程操作可以最大程度减少损失和恢复时间。4.1 初步诊断与确认查看云平台监控立即登录云服务器控制台查看实例的公网入带宽、CPU使用率、TCP连接数图表。DDoS攻击的典型特征是入带宽持续打满或接近打满CPU使用率可能不高网络层攻击TCP连接数异常飙升尤其是SYN_RECV状态。同时检查“安全告警”或“DDoS防护”控制台看是否有攻击事件告警。登录服务器检查如果还能登录iftop或nethogs查看实时流量和占用带宽的进程。netstat -an | grep :80 | wc -l统计80端口的连接数如果数字巨大且持续增长很可能是HTTP Flood。ss -s查看总的socket统计信息。dmesg | tail查看内核日志可能有“possible SYN flooding”等报错。journalctl -f或tail -f /var/log/messages跟踪系统日志。4.2 应急缓解措施启用云厂商的DDoS防护服务如果攻击流量已经超过云服务器的免费基础防护阈值例如阿里云是5Gbps实例会被“黑洞”即所有公网入流量被丢弃。此时你需要购买并启用DDoS高防IP或高防包将业务域名解析到高防IP由高防IP清洗流量后再回源到你的服务器。联系客服申请提前解封如果业务非常重要可以尝试联系客服说明情况并承诺购买防护产品有时可以提前解封。调整安全组进行临时封堵针对小流量或特定攻击识别攻击特征通过日志或流量分析如果发现攻击来自某个特定IP段或针对某个特定端口。添加安全组拒绝规则在安全组入方向添加一条高优先级规则拒绝该IP段或端口的所有流量。注意对于海量IP的DDoS此方法无效。在服务器层面进行限流治标不治本但可争取时间使用iptables限制单个IP的连接速率如果攻击IP不多# 限制80端口每个IP每分钟最多建立25个新连接超过则丢弃 sudo iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set sudo iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 25 -j DROP使用iptables丢弃疑似恶意的协议流量如UDP Flood# 如果业务不用UDP可以丢弃所有入站UDP谨慎 # sudo iptables -A INPUT -p udp -j DROP4.3 攻击后的溯源与加固攻击缓解后必须进行溯源防止再次发生。分析日志仔细检查Web服务器访问日志如Nginx的access.log、系统安全日志/var/log/secureauth.log寻找攻击起始时间、攻击源IP、攻击模式是否使用了特定User-Agent、是否针对某个URL。检查服务器是否被入侵last、lastb查看成功和失败的登录记录。history查看当前用户的命令历史。crontab -l、ls -la /etc/cron.*/检查是否有异常的计划任务。ps auxf、netstat -antp查看是否有未知进程和网络连接。使用rkhunter、chkrootkit等工具进行 rootkit 扫描。根因分析与加固如果攻击是利用了应用漏洞如SQL注入、文件上传立即修复漏洞。如果攻击是纯流量型的评估是否需要升级服务器带宽、或长期启用DDoS防护服务。回顾并修正本文前述的所有安全配置收紧安全组出站规则、加固主机防火墙、优化内核参数。制定应急预案将本次处理过程文档化形成应急预案。包括云防护产品购买流程、关键监控指标阈值、服务器限流命令、业务切换流程等。5. 高级防护架构设计与工具推荐对于高频业务或对可用性要求极高的业务仅靠单台服务器和基础配置是不够的需要在架构层面考虑防护。5.1 高可用与弹性架构负载均衡SLB/CLB将流量分发到后端多台服务器避免单点被打垮。同时云厂商的负载均衡产品本身具备一定的抗攻击能力。弹性伸缩ESS配合负载均衡在应用层攻击CC攻击导致CPU飙升时自动扩容后端服务器数量分摊压力。务必设置最大实例数上限防止在攻击下无限扩容产生天价账单。多可用区部署将业务部署在同一个地域的不同可用区AZ即使一个AZ因大规模攻击或故障受影响其他AZ的业务仍可运行。CDN静态资源加速将静态资源图片、CSS、JS托管到CDN不仅可以加速还能将这部分流量压力从源站剥离减少源站带宽消耗。5.2 专业安全产品集成根据业务类型和预算考虑引入专业安全产品Web应用防火墙WAF防御SQL注入、XSS、CC攻击等应用层攻击。对于网站和API服务是必需品。DDoS高防服务提供Tbps级别的流量清洗能力应对大规模网络层/传输层攻击。有高防IP和高防包两种形式前者适合有固定高防需求的业务后者适合临时或保底防护。云安全中心/主机安全提供主机入侵检测、漏洞扫描、基线检查、日志分析等能力帮助发现服务器内部的安全威胁。5.3 监控与告警体系建设“无监控不运维”。完善的监控是发现攻击的“眼睛”。基础资源监控必须监控每台服务器的公网入/出带宽、CPU使用率、TCP连接数、磁盘IO。设置告警阈值如入带宽持续5分钟80%。业务指标监控监控业务的QPS、响应时间、错误率。DDoS攻击往往会导致业务指标异常。日志集中分析使用ELKElasticsearch, Logstash, Kibana或商业日志服务集中收集和分析服务器、应用、安全设备的日志便于快速检索攻击线索。设置多通道告警将关键告警通过短信、电话、钉钉/企业微信机器人等多种方式通知到运维人员确保不漏警。云服务器的安全是一个动态的过程没有一劳永逸的配置。安全组和Linux防火墙是基石但必须正确理解和联动配置。从这次DDoS事件中我学到的最重要一课是安全是一个整体任何一环的疏忽或误解都可能让其他环节的努力付诸东流。定期审计你的安全配置模拟攻击进行测试保持对安全动态的关注才能让你的业务在云上跑得更稳、更安心。
1. 项目概述一次DDoS攻击引发的安全组反思前几天我负责维护的一台线上业务服务器突然失联了。不是简单的服务卡顿而是整个SSH连接超时监控面板上的公网出带宽直接拉满到上限CPU使用率却低得可怜。第一反应是“被打了”——典型的分布式拒绝服务攻击。紧急联系云服务商果然控制台告警显示该实例因对外攻击已被临时阻断。一通手忙脚乱的排查、解封、溯源后根源竟指向一个我们自以为“万无一失”的配置云服务器安全组。我们严格按照“最小权限原则”只开放了80、443和特定IP的22端口看似固若金汤。但攻击流量并非从这些端口涌入而是利用了安全组一个常被忽略的“隐形”特性结合服务器自身的Linux防火墙iptables/firewalld的默认策略形成了一道致命的组合漏洞。这次事件让我深刻意识到很多运维和开发者对云上安全的理解可能还停留在“设好安全组就万事大吉”的层面。安全组是云平台提供的虚拟防火墙用于控制实例级别的入站和出站流量它是安全的第一道闸门。然而这道闸门如果设置不当或者你误以为它是一堵密不透风的墙那么风险就会在眼皮底下滋生。尤其是在应对DDoS这种海量畸形流量攻击时安全组的规则逻辑、与操作系统防火墙的联动、以及对“允许”与“拒绝”的深层理解都至关重要。本文将结合这次真实的攻防经历拆解云服务器安全组配置中那些容易被忽视的“隐形”风险点并深入探讨Linux防火墙在云环境下的正确姿势。无论你是使用阿里云、腾讯云还是华为云只要你的业务跑在云上这些坑都可能已经埋下。2. 安全组与Linux防火墙双保险还是双漏洞在云环境中网络安全通常被设计为分层防御体系。最外层是云平台自身的DDoS高防、WAF等产品中间层就是安全组最内层则是操作系统自带的主机防火墙如CentOS/RHEL系的firewalld或更底层的iptables以及Ubuntu/Debian系的ufw。理想情况下它们应该协同工作构成纵深防御。但现实中如果配置不当它们可能互相冲突甚至制造出更大的安全盲区。2.1 安全组的工作原理与常见误区安全组是一种有状态的虚拟防火墙。所谓“有状态”意味着如果你设置了一条允许入站Inbound的规则那么对应的出站Outbound响应流量会被自动允许无需额外配置出站规则。这简化了配置但也容易让人产生误解。最常见的几个配置误区只配入站不配出站或出站全开很多人认为业务只需要被访问所以只精心配置入站规则出站规则则保持默认的“允许所有”。这是一个巨大的风险点。如果服务器被入侵攻击者可以利用这台服务器作为跳板对外发起扫描、攻击或数据泄露。例如恶意脚本可以通过出站连接将敏感数据上传到外部存储或作为DDoS攻击的傀儡机对外发送大量流量。我们的案例中服务器被检测到“对外攻击”极有可能就是出站规则过于宽松导致的。对“0.0.0.0/0”的滥用在配置入站规则时为了方便测试临时对某个端口如22或3306开放了源地址为0.0.0.0/0即所有IP的访问之后却忘了删除。这相当于在互联网上挂了一个告示牌告诉所有扫描器“此处有门可入”。对于管理端口必须使用特定的IP或CIDR地址段。忽略协议类型安全组规则需要指定协议如TCP, UDP, ICMP。有时为了Ping通服务器会开放ICMP协议。但在DDoS攻击中ICMP Flood是一种常见的攻击手段。非必要情况下建议在公网入口关闭ICMP Echo Request即ping。规则优先级理解不清安全组规则按优先级数字从小到大的顺序执行。当一条流量匹配到某条规则后后续规则不再执行。常见的错误是设置了一条低优先级数字大如100的“拒绝所有”规则但前面有一条高优先级数字小如1的“允许所有”规则导致“拒绝所有”完全失效。正确的做法是将具体的允许规则设置为高优先级最后一条设置为低优先级的“拒绝所有”作为默认兜底。2.2 Linux防火墙的“默认放行”陷阱现在我们来到这次事件的核心Linux主机防火墙与安全组的交互。以最常用的firewalld为例它有几个默认zone如public、trusted、drop。新安装的系统网卡通常位于publiczone。关键风险点在于publiczone的默认策略。在未做任何自定义配置时firewalld的publiczone默认是允许所有出站连接拒绝所有入站连接除了与已建立连接相关的数据包。这听起来很安全对吗问题就出在这个“除了”。这个“除了”指的是状态防火墙的ESTABLISHED, RELATED状态跟踪。简单来说一旦有一个从内部发起的出站连接建立成功其后续的入站响应流量会被自动允许。这本是为了保障通信的正常进行。但是在云服务器场景下这个机制与安全组结合会产生一个致命漏洞假设你的安全组出站规则是“允许所有”默认或手动设置。那么服务器上的任何进程都可以自由地对外发起连接。如果服务器上存在恶意软件、被植入的后门、或者一个有漏洞的应用程序例如一个被利用的Redis未授权访问可以执行CONFIG SET dir和SAVE命令写入计划任务攻击者就可以利用这个出站通道“反向”建立一个连接到你的服务器。由于这个连接是从你的服务器内部主动发起的在Linux防火墙看来这是一个合法的出站连接及其相关的入站响应firewalld的默认规则会允许这部分流量通过。而此时安全组的入站规则可能对此毫不知情因为流量在状态跟踪下被视为“已建立连接”的一部分而非新的入站请求。这就成功绕过了安全组对入站流量的严格限制。实操心得永远不要认为安全组是唯一的屏障。主机防火墙的默认行为必须被重新审视和加固。在云上主机防火墙的策略应该比在物理服务器中更加严格。2.3 联动失效的典型场景除了上述的“反向shell”场景联动失效还体现在端口扫描与响应安全组拒绝了某个端口的访问但服务器上的服务依然在监听该端口。当攻击者进行端口扫描时虽然TCP SYN包会被安全组丢弃但服务器本身如果未关闭不必要的服务仍然存在潜在风险。一旦安全组规则被误修改或云平台出现极端情况虽然概率极低服务将直接暴露。DDoS攻击下的资源耗尽安全组可以过滤数据包但过滤动作本身需要消耗云平台虚拟化层的CPU资源。当遭遇超大流量的DDoS攻击时即使所有恶意包都被安全组拒绝海量的包处理请求也可能耗尽实例所在物理宿主机的资源导致同宿主机的其他正常实例受到影响“邻居效应”最终你的实例可能因资源耗尽而瘫痪或被迫进入“黑洞”。此时主机防火墙完全帮不上忙。3. 实战构建纵深防御的安全配置策略理解了风险接下来就是如何构建一个真正有效的防御体系。我们的目标不是追求绝对安全那不存在而是将风险降到可接受的水平并确保在遭受攻击时能快速响应和恢复。3.1 安全组最佳配置实践遵循最小权限原则细化到端口和IP入站规则像雕刻一样精细。Web服务器只开放80/443数据库服务器只对应用服务器IP开放3306/5432等端口SSH/RDP只对运维IP开放。使用“安全组ID”作为源如果同VPC内是更佳选择比IP更灵活。出站规则同样重要不要允许所有。只开放业务必要的出站端口。例如需要调用外部API只允许访问该API服务的IP和端口需要yum/apt更新只允许访问内网镜像源或特定官方源IP的80/443端口通常不需要允许出站的SSH22或数据库端口。一个Web服务器的安全组规则示例以表格形式呈现更清晰规则方向优先级协议类型端口范围源/目的地址策略说明入站1TCP80, 4430.0.0.0/0允许允许公网HTTP/HTTPS访问入站2TCP22106.120.xxx.xxx/32允许仅允许办公室固定IP SSH入站100ALLALL0.0.0.0/0拒绝默认拒绝所有其他入站出站1TCP4430.0.0.0/0允许允许对外HTTPS请求如调用API出站2TCP800.0.0.0/0允许允许对外HTTP请求出站3TCP53, UDP53100.100.2.136/32, 100.100.2.138/32允许出站100ALLALL0.0.0.0/0拒绝默认拒绝所有其他出站善用安全组作为“白名单”将不同的业务层Web层、应用层、数据层部署在不同的安全组内通过安全组之间互相授权来访问而不是直接使用IP地址。这样当服务器IP变更时无需修改大量规则。定期审计与清理利用云监控或配置审计服务定期检查安全组规则变更日志。清理掉那些来源是“0.0.0.0/0”的临时规则、测试规则和不再使用的规则。3.2 Linux防火墙加固配置针对firewalld我们需要修改其默认行为使其在云环境中起到真正的补充作用。修改默认zone的策略核心步骤 我们不直接使用dropzone可能导致某些云助手或监控agent异常而是修改publiczone的默认策略为更严格的default并显式定义规则。# 查看当前默认zone和规则 sudo firewall-cmd --list-all # 设置默认的入站策略为拒绝出站策略为拒绝我们将手动允许需要的 # 注意此操作会断网务必在本地控制台或通过已有会话操作并提前准备好放行规则 sudo firewall-cmd --permanent --set-targetDROP # 重新加载使永久生效 sudo firewall-cmd --reload警告执行--set-targetDROP后所有未匹配到允许规则的入站流量都将被丢弃。你必须在此之前通过firewall-cmd --permanent --add-servicessh --zonepublic等方式确保你的当前SSH连接IP和端口已被允许否则会立即断开连接最好在云控制台的VNC终端里操作。显式允许必要的服务和端口# 允许SSH假设端口22且你的IP已通过安全组过滤 sudo firewall-cmd --permanent --add-servicessh # 允许HTTP/HTTPS sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --permanent --add-servicehttps # 如果需要允许特定端口如3000 sudo firewall-cmd --permanent --add-port3000/tcp # 允许出站DNS解析 sudo firewall-cmd --permanent --add-servicedns # 允许出站到特定IP的特定端口例如连接内网Redis sudo firewall-cmd --permanent --add-rich-rulerule familyipv4 destination address10.0.1.10 port port6379 protocoltcp accept # 重新加载 sudo firewall-cmd --reload使用富规则Rich Rules进行更精细的控制 富规则功能强大可以限制连接速率这对缓解CC攻击有一定效果。# 限制每个IP地址每分钟最多新建10个HTTP连接超过则拒绝 sudo firewall-cmd --permanent --add-rich-rulerule familyipv4 service namehttp limit value10/m accept # 允许来自特定IP段的SSH连接 sudo firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.0/24 service namessh accept3.3 系统层与应用层加固安全组和主机防火墙是网络层防护系统自身也需要加固。关闭不必要的服务与端口使用netstat -tunlp或ss -tunlp查看所有监听端口停用并禁用非必需的服务如bluetooth,cups等。内核参数调优调整/etc/sysctl.conf中的网络参数增强抗DDoS能力。# 编辑sysctl配置 sudo vim /etc/sysctl.conf # 添加或修改以下参数 net.ipv4.tcp_syncookies 1 # 开启SYN Cookies防SYN Flood net.ipv4.tcp_max_syn_backlog 2048 # 增加SYN队列长度 net.ipv4.tcp_synack_retries 2 # 减少SYNACK重试次数 net.ipv4.tcp_syn_retries 2 # 减少SYN重试次数 net.ipv4.icmp_echo_ignore_all 1 # 忽略所有ping根据需求设置 net.ipv4.conf.all.rp_filter 1 # 开启反向路径过滤防IP欺骗 net.ipv4.conf.default.rp_filter 1 # 使配置生效 sudo sysctl -p应用程序配置确保Web服务器Nginx/Apache有连接数限制、请求速率限制模块。对于数据库禁止公网访问使用强密码和最小权限账户。4. 遭遇DDoS攻击时的应急响应与排查流程当监控告警响起怀疑遭遇DDoS攻击时切忌慌乱。按照以下流程操作可以最大程度减少损失和恢复时间。4.1 初步诊断与确认查看云平台监控立即登录云服务器控制台查看实例的公网入带宽、CPU使用率、TCP连接数图表。DDoS攻击的典型特征是入带宽持续打满或接近打满CPU使用率可能不高网络层攻击TCP连接数异常飙升尤其是SYN_RECV状态。同时检查“安全告警”或“DDoS防护”控制台看是否有攻击事件告警。登录服务器检查如果还能登录iftop或nethogs查看实时流量和占用带宽的进程。netstat -an | grep :80 | wc -l统计80端口的连接数如果数字巨大且持续增长很可能是HTTP Flood。ss -s查看总的socket统计信息。dmesg | tail查看内核日志可能有“possible SYN flooding”等报错。journalctl -f或tail -f /var/log/messages跟踪系统日志。4.2 应急缓解措施启用云厂商的DDoS防护服务如果攻击流量已经超过云服务器的免费基础防护阈值例如阿里云是5Gbps实例会被“黑洞”即所有公网入流量被丢弃。此时你需要购买并启用DDoS高防IP或高防包将业务域名解析到高防IP由高防IP清洗流量后再回源到你的服务器。联系客服申请提前解封如果业务非常重要可以尝试联系客服说明情况并承诺购买防护产品有时可以提前解封。调整安全组进行临时封堵针对小流量或特定攻击识别攻击特征通过日志或流量分析如果发现攻击来自某个特定IP段或针对某个特定端口。添加安全组拒绝规则在安全组入方向添加一条高优先级规则拒绝该IP段或端口的所有流量。注意对于海量IP的DDoS此方法无效。在服务器层面进行限流治标不治本但可争取时间使用iptables限制单个IP的连接速率如果攻击IP不多# 限制80端口每个IP每分钟最多建立25个新连接超过则丢弃 sudo iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set sudo iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 25 -j DROP使用iptables丢弃疑似恶意的协议流量如UDP Flood# 如果业务不用UDP可以丢弃所有入站UDP谨慎 # sudo iptables -A INPUT -p udp -j DROP4.3 攻击后的溯源与加固攻击缓解后必须进行溯源防止再次发生。分析日志仔细检查Web服务器访问日志如Nginx的access.log、系统安全日志/var/log/secureauth.log寻找攻击起始时间、攻击源IP、攻击模式是否使用了特定User-Agent、是否针对某个URL。检查服务器是否被入侵last、lastb查看成功和失败的登录记录。history查看当前用户的命令历史。crontab -l、ls -la /etc/cron.*/检查是否有异常的计划任务。ps auxf、netstat -antp查看是否有未知进程和网络连接。使用rkhunter、chkrootkit等工具进行 rootkit 扫描。根因分析与加固如果攻击是利用了应用漏洞如SQL注入、文件上传立即修复漏洞。如果攻击是纯流量型的评估是否需要升级服务器带宽、或长期启用DDoS防护服务。回顾并修正本文前述的所有安全配置收紧安全组出站规则、加固主机防火墙、优化内核参数。制定应急预案将本次处理过程文档化形成应急预案。包括云防护产品购买流程、关键监控指标阈值、服务器限流命令、业务切换流程等。5. 高级防护架构设计与工具推荐对于高频业务或对可用性要求极高的业务仅靠单台服务器和基础配置是不够的需要在架构层面考虑防护。5.1 高可用与弹性架构负载均衡SLB/CLB将流量分发到后端多台服务器避免单点被打垮。同时云厂商的负载均衡产品本身具备一定的抗攻击能力。弹性伸缩ESS配合负载均衡在应用层攻击CC攻击导致CPU飙升时自动扩容后端服务器数量分摊压力。务必设置最大实例数上限防止在攻击下无限扩容产生天价账单。多可用区部署将业务部署在同一个地域的不同可用区AZ即使一个AZ因大规模攻击或故障受影响其他AZ的业务仍可运行。CDN静态资源加速将静态资源图片、CSS、JS托管到CDN不仅可以加速还能将这部分流量压力从源站剥离减少源站带宽消耗。5.2 专业安全产品集成根据业务类型和预算考虑引入专业安全产品Web应用防火墙WAF防御SQL注入、XSS、CC攻击等应用层攻击。对于网站和API服务是必需品。DDoS高防服务提供Tbps级别的流量清洗能力应对大规模网络层/传输层攻击。有高防IP和高防包两种形式前者适合有固定高防需求的业务后者适合临时或保底防护。云安全中心/主机安全提供主机入侵检测、漏洞扫描、基线检查、日志分析等能力帮助发现服务器内部的安全威胁。5.3 监控与告警体系建设“无监控不运维”。完善的监控是发现攻击的“眼睛”。基础资源监控必须监控每台服务器的公网入/出带宽、CPU使用率、TCP连接数、磁盘IO。设置告警阈值如入带宽持续5分钟80%。业务指标监控监控业务的QPS、响应时间、错误率。DDoS攻击往往会导致业务指标异常。日志集中分析使用ELKElasticsearch, Logstash, Kibana或商业日志服务集中收集和分析服务器、应用、安全设备的日志便于快速检索攻击线索。设置多通道告警将关键告警通过短信、电话、钉钉/企业微信机器人等多种方式通知到运维人员确保不漏警。云服务器的安全是一个动态的过程没有一劳永逸的配置。安全组和Linux防火墙是基石但必须正确理解和联动配置。从这次DDoS事件中我学到的最重要一课是安全是一个整体任何一环的疏忽或误解都可能让其他环节的努力付诸东流。定期审计你的安全配置模拟攻击进行测试保持对安全动态的关注才能让你的业务在云上跑得更稳、更安心。
