老规矩实验课结束当晚把记录整理出来。这次的实验七和以往不太一样它把防火墙和入侵防护放到了一起做而不是像前几次那样单独验证某个功能点。这其实是刻意设计的——现在实际的网络环境里单纯靠防火墙或者单纯靠IDS已经很难撑住场面了两者配合才是常态。这篇就把实验从设计思路到最终实施完整理一遍给后面做同样实验的同学一个参考。先说清楚这个实验到底在做什么。整个实验环境是一套完全隔离的虚拟化网络模拟了一个典型的企业内外网拓扑。核心任务是先部署状态检测防火墙配置包过滤规则和NAT策略然后在防火墙内侧部署入侵检测引擎并尝试把检测能力和防火墙联动起来实现自动阻断。最后用模拟攻击来验证整套防线有没有真正生效。涉及的典型知识点包括防火墙的链与规则匹配、状态检测机制、NAT转换、入侵检测的规则语法、误报漏报的调整以及日志分析的基本方法。做这个实验的难点不在于单个技术点而在于把两套系统串起来理解。很多同学做完防火墙实验就会习惯性地把所有安全寄托在几条ACL上做完IDS实验又觉得只要装了检测引擎就万事大吉。这次实验恰恰要打破这种单点思维让你亲手体会到防火墙只看会话、 IPS看内容、两者各有边界只有配合才能覆盖完整的攻击链路。1. 实验目标与整体设计思路1.1 为什么要让防火墙和入侵防护“打配合”先抛一个我讲课时常问的问题如果内网有一台服务器被种了后门每五分钟向外回传一次数据防火墙能拦住吗答案有点反直觉。如果你在防火墙上没有显式封禁这台服务器的外联端口那么这段回传流量就是一个“合法的、新建的、出方向的”会话状态检测防火墙会判定为正常连接直接放行。这个场景很直观地说明了一个事实——防火墙的强项是“基于状态和五元组做访问控制”它对流量内容完全无感不会去检查里面装的是图片还是恶意代码。那入侵防护能解决这个问题吗能但要看怎么部署。如果只是把IDS旁路挂在交换机镜像口上那它最多只能报警没法阻断等管理员看到告警的时候数据早就传完了。所以实验里必须把“检测”和“响应”串成闭环让检测引擎发现恶意行为后通过联动机制动态生成防火墙阻断规则这才算真正意义的入侵防护。用一个不太严谨但很好懂的生活类比防火墙是小区大门的门禁系统任何出入都要刷卡管得住谁进谁出入侵防护是小区里的巡逻保安他会跑到楼里去检查各个房间有没有异常动静。门禁管方向、管身份保安管行为、管内容。单靠门禁防不住住户里出了内鬼单靠保安你根本不知道大门口谁进来了。这俩必须同时存在而且信息要互通——保安发现了可疑情况得通知门禁赶紧加黑名单。1.2 实验场景与网络拓扑规划实验组网采用了三张隔离网段模拟最经典的双防火墙分区模型只不过这里用一台设备充当穿过三张网的路由器。拓扑结构如下外部模拟区网段 203.0.113.0/24部署攻击模拟主机用来发起端口扫描、暴力破解尝试等恶意行为。边界防护区网段 198.51.100.0/24这台机器是整个实验的核心安装双网卡配置防火墙策略同时承担NAT转换和路由转发。内部服务区网段 192.0.2.0/24放置目标服务器对外只提供少数服务比如 Web 服务和数据库服务方便后续验证防火墙放行和阻断的效果。很多同学做这个实验都会犯一个错误——把防火墙和IDS装在同一台机器上然后在内网里来回切换操作。这样做虽然省了一台虚拟机但网络拓扑完全失真抓包分析的时候很难区分流量是经过防火墙转发的还是本机直接产生的。我还是坚持把“检测引擎”部署在边界防护设备上ID S监听的是经过防火墙转发后的内部流量接口这样才能观察“边界放行后”的流量长什么样。也就是说防火墙是转发路径上的第一道关口入侵检测是它背后的第二道研判节点两个环节都有了数据链路才是完整的。1.3 实验验收标准实验做完的时候自测清单如下每一条都对应一个具体的操作验证而不是“老师你看我把服务都配置好了”这种模糊表述外部主机能正常访问内网服务——说明NAT和放行规则工作正常。外部主机发起端口扫描时防火墙会记录相关会话日志且对于敏感端口比如远程管理端口的访问会被拒绝。入侵检测引擎能对模拟攻击行为产生告警告警内容包含攻击类型和源目IP。联动阻断生效时攻击主机的IP会在防火墙黑名单中动态出现后续连接被主动拒绝。对规则的增删操作可以实时生效不需要重启防火墙服务。这套标准明确了一个关键思想防护能不能起作用不是看你配置了多少策略而是看攻击链路能不能被真正切断。后面所有的排查工作都围绕这个标准来推进。2. 实验环境搭建与前置准备2.1 虚拟化平台与网络模式选择实验基于常见的虚拟化平台完成创建三台虚拟机。每台虚拟机的网络连接方式要严格对应上文规划的三张网段而不是全都用默认的 NAT 模式否则虚拟机之间根本走不到同一张二层网络里。这里要特别提醒一个新手容易踩的坑虚拟机用的网络模式决定的是它接入哪张“虚拟交换机”而不是你后续在虚拟机里配置的IP地址。如果三台机器都选 NAT 模式哪怕你手工把IP改成三个不同网段它们依然处于同一个NAT网络内彼此连通拓扑关系完全是乱的。正确做法是创建多张虚拟网卡为每台机器分配独立的网卡接口再在网络拓扑层面规划好网段归属确保流量走向符合实验设计。虚拟机的配置方面每台分配两核CPU、2G内存、20G磁盘即可。整套实验跑起来时负载不高资源占用主要集中在编译规则和日志写入上配置太高反而浪费宿主机资源。操作系统选择通用服务器版本安装时尽量最小化组件后续需要什么工具再单独补装这样也可以保持环境尽可能干净。2.2 三台虚拟机的基础配置实录先约定一下主机名方便后面写规则和看日志的时候能快速对应外部主机直接使用攻击发起端的默认主机名IP 配置为 203.0.113.10/24默认网关指向 203.0.113.1。防火墙主机双网卡一块连接外部区域分配 203.0.113.1/24另一块连接内部区域分配 192.0.2.1/24。同时开启内核转发功能作为路由设备。目标服务器单网卡连接内部区域IP 配置为 192.0.2.10/24默认网关指向 192.0.2.1。在防火墙主机上开启转发的方式比较直接编辑系统内核参数配置文件将net.ipv4.ip_forward的值改为1然后让系统重载该配置。注意单纯改配置文件不生效一定要执行重载步骤这一步漏掉的话后面所有跨网段通信都会直接失败而且看起来就像是防火墙把包全丢了排查起来非常干扰思路。配置完成后的第一步是用ping做连通性测试三张网段之间应该两两互通尤其是外部主机能 ping 通内网服务器的网关。如果这里就不通后面配置防火墙策略时根本分不清是策略拦截还是网络本身有问题所以这个环节宁可多花几分钟验证清楚也不要急着往下走。2.3 必要的辅助工具准备实验过程中有几类工具是刚需建议提前装好命令行网络诊断工具ping、tcpdump用来验证连通性和抓包分析。流量分析工具比如抓包分析客户端用来后期打开抓取的报文文件查看TCP握手细节和数据载荷。端口扫描工具模拟攻击端发起扫描验证防火墙和IDS的检测能力。文本处理工具查看日志时经常需要过滤关键字、统计IP出现次数这类命令是纯文本过滤的标配手段。这些工具都是常规的网络诊断和日志分析软件在正规运维和实验环境中非常常见。准备充分之后环境的可操作性和问题定位效率会高很多。没装抓包工具就贸然开始防火墙实验等于闭着眼睛开车遇到问题只能靠猜效率极低。3. 防火墙配置实操与参数解析3.1 防火墙规则链结构与默认策略本实验使用系统自带的防火墙管理框架它基于内核网络协议栈的钩子机制对进出数据包进行规则匹配。核心概念是内置了几条规则链其中最常打交道的三条分别为用于处理发往本机的入站数据包、用于处理本机发起的外出数据包、以及用于处理需要经过本机转发的数据包。这里需要明确一个基本概念本实验中的防火墙承担路由转发任务外部主机到内部服务器的流量最终会进入专门的转发链而不是入站链。这个区别非常重要因为很多新手把放行规则写在入站链上却发现流量还是不通——其实数据包根本没走那条链规则自然匹配不到。默认策略应当设置为拒绝也就是未显式放行的数据包一律丢弃。理由很简单白名单模式比黑名单模式安全得多——黑名单永远有遗漏而白名单只要设计合理暴露面就是可控的。先设置默认拒绝再逐条放行必要流量这样整台防火墙的规则含义一目了然。3.2 Web 服务与远程管理的放行规则先按最基础的场景做四条放行规则放行回环接口通信、放行外部主机访问目标服务器的 Web 服务、放行外部主机访问目标服务器的数据库服务、放行外部主机访问防火墙自身的远程管理端口源地址限定为实验管理网段。配置规则时的语法是“链 匹配条件 动作”其中匹配条件可以包含协议、源地址、目的地址、目的端口等多个维度。以放行 Web 服务为例规则语义是在转发链上对于协议为 TCP、目标地址为内网服务器、目标端口为 80 且来自外部网段的报文执行接受动作。远程管理规则单独强调一点源地址必须限定。如果不限定等于把防火墙的管理口暴露在整个外网任何可达的地址都能尝试暴力破解这是运维中最常见的高危配置。实验环境虽然风险可控但习惯要从第一次配置就养成。有同学可能会问ICMP 协议要不要放行我的建议是放行但不盲目。实验环境完全可以放行 ICMP 回显方便排查连通性生产环境则需要慎重——ICMP 虽然看起来无害但探测工具往往先通过 ICMP 判断主机存活再决定是否对它发起进一步探测。所以生产上更常见的做法是限制 ICMP 的速率甚至直接丢弃。3.3 NAT 配置与内外网转换目标服务器位于内部网络其地址为私网地址外部主机无法直接路由到该地址因此必须在防火墙上配置网络地址转换把外部发往防火墙地址的流量映射到内网服务器。这种模式通常称为目标地址转换访问者以为自己在访问防火墙的某个端口实际数据包会被改写目的地址后转发给内网机器。具体配置分为两步第一步配置转发规则把发往防火墙公网地址指定端口的流量转发给内网的特定IP和端口第二步在内部接口上配置源地址转换让内网服务器回程的流量也能正确返回外部主机。后者的原因是回程流量源地址是私网地址如果不做转换外部主机收到后无法正确回复连接会中断。两个方向都配置完成后外部主机访问目标服务器时整个会话的地址转换对用户完全透明。动手实现时要注意规则之间的顺序关系——这里的顺序不是指防火墙链内规则的先后而是目标地址转换必须和放行规则配合好放行规则中匹配的目的地址应该是防火墙外网口的地址而不是后端服务器的真实地址。如果写反了数据包在NAT之前就因为目的地址不匹配而匹配不到放行规则直接被默认策略丢掉。3.4 防火墙规则生效验证规则全部配置完成后验证工作要分两个层面第一层是连通性验证。外部主机访问目标服务器的 Web 服务和数据库服务预期可以正常建立连接访问未在放行列表中的端口预期失败。第二层是会话和日志验证。查看防火墙当前建立的会话表确认有活动的 NAT 会话再翻一下防火墙的日志能从里面看到数据包被接受或拒绝的记录。我特别关注日志这一步。很多同学验证防火墙规则时只看“通”还是“不通”从来不看日志导致后面IDS联动时没有日志可查非常被动。防火墙日志是整个实验中最重要的数据源之一后续做攻击验证和规则调优时所有依据都从日志里来。所以实验做这一步的时候不要赶进度把日志的格式、字段含义都过一遍后面会省很多事。4. 入侵检测引擎的部署与规则编写4.1 从 IDS 到 IPS 的本质跃迁入侵检测系统IDS的核心价值在于被动监测和分析它通过网络流量镜像或分光器接入链路不影响数据包的正常转发。它看到的是流量的“副本”因此部署风险很低——即使设备故障也不会导致业务中断。但代价是它只能事后告警不能实时阻断。入侵防护系统IPS则不同它必须以串联模式接入链路实时检查每一个经过的数据包发现恶意行为时可以直接丢弃或阻断连接。代价是如果设备本身出故障或者性能到瓶颈整个链路通信都会受影响。实验里采用了一个折中方案先用 IDS 做检测再把告警事件回调到防火墙由防火墙动态生成阻断策略。这个方案的本质就是用“软件联动”把旁路 IDS 的检测能力与防火墙的阻断能力连接起来形成实际意义上的 IPS 能力。绝大多数开源安全方案都支持这种联动模式这也是小规模网络中自建防护体系最主流的落地思路。4.2 入侵检测引擎的安装与基本配置本实验采用开源入侵检测引擎安装过程分三步更新软件源、安装引擎主程序、安装规则集。规则集是告警能力的来源没有规则集的 IDS 就像一本页数空白的安全条例什么异常行为也报不出来。安装完成后的主配置文件里需要修改的几个关键项包括监听网卡接口、内网网段声明、规则文件路径。监听接口务必指定为防火墙连接内部区域的网卡——因为从外部来的攻击流量在转发后还会再次从这里经过而检测引擎只需要关心这部分从外到内的流量就足够了。如果选错接口比如选了外网口虽然也能看到攻击但看到的流量形态包含所有进出的会话日志会比较乱而且更容易漏掉真正需要关注的南下流量。配置完成后重启引擎服务然后查看日志文件里有没有报错比如规则解析失败、接口不存在之类的异常。确认加载正常后再用命令行查看已加载的规则数量基线值一般都在数万条以上。如果加载数量为零或极少说明规则路径配置有问题。4.3 自定义检测规则的语法拆解规则集自带的规则虽然覆盖面广但实验验证时往往不够精准——要么告警太多分不清主次要么漏掉我们想演示的特定攻击场景。所以必须要写自定义规则。规则语法的基本结构分为三部分规则头、规则选项、动作。以一条模拟攻击检测规则为例语义是在外部接口上检测到任何 TCP SYN 包发往内网服务器远程管理端口时直接产生告警并把日志级别记为紧急。这条规则看起来简单却是后面联动阻断的基础——有告警事件才能触发响应动作。规则拆解一下各个配置项的含义第一部分包含动作和基本匹配条件比如“当出现满足条件的 TCP 包时告警”第二部分是协议类型第三部分描述源地址和源端口相当于“源任意”第四部分是目的地址和目的端口即目标服务器的远程管理端口最后是规则选项告诉引擎当命中规则时输出什么消息、什么级别、用什么标识。写规则时最容易犯的错是源端口写得太死。很多初学者会规定源端口必须等于某个固定值但实际攻击者发起连接时用的是随机高端口这样规则会漏报得很厉害。正确处理方式是把源端口留空让规则匹配所有源端口只把目标的端口作为关键限定条件。4.4 告警日志与事件解读规则写完后重新加载规则然后用模拟攻击去触发。每触发一次检测引擎就会在日志文件里追加一条告警记录。告警记录的关键字段包括时间戳、规则编号、告警分类、优先级、源IP、源端口、目的IP、目的端口以及规则描述。看日志时的基本功是“把多条记录连成一条线”。单看一条日志只能知道有某个IP访问了某个端口没有太大意义但如果你把同一个源IP在过去十分钟的所有告警拉出来看发现它在逐个扫描所有端口就能判断这是一次系统性的探测行为而不是偶然访问。日志分析的思维是找趋势、找聚簇、找反常规而不是盯着单条记录发呆。5. 联动阻断与攻击模拟验证5.1 实现联动响应的两种主流思路前面提到过让 IDS 的告警变成防火墙的动态阻断规则是整个实验里最有价值的一个环节。实现路径通常有两条第一种是用现成的联动框架。这种框架自带告警读取和策略下发能力配置好对接信息后检测引擎一产生告警框架就自动在防火墙上添加黑名单规则。优点是一体化程度高开箱即用缺点是架构相对重而且依赖框架本身的稳定性。第二种是自己写一个轻量级联动脚本。核心逻辑比较简单实时读取检测引擎的告警日志解析出源IP和目的IP调用防火墙命令为这个IP添加一条限时阻断规则同时记录一条联动日志方便审计。这种实现方式可控性更强也更能帮助你理解联动的每一个环节建议实验用这种方式。脚本的语言选择无妨Python 或者 Shell 都能胜任。关键点在于日志读取的实时性和去重逻辑——已经处理过的告警必须做标记否则同一个攻击源超过阈值后会重复触发N次添加规则的命令白白消耗系统资源。5.2 威胁解除后的自动恢复机制联动阻断还有一个容易被忽略的细节阻断策略不能永久生效。因为攻击者的IP可能是动态变化的而且有时候触发告警的只是一次配置错误引发的误报如果永久封禁某个IP很可能把正常访问也一起拦了。所以在添加防火墙策略的时候必须设置一个合理的存活时间比如600秒或按需设置。这个策略到期后会被自动清理源IP重新获得访问能力。设计这个机制的好处显而易见降低了误封生产业务的风险同时攻击方如果持续试探它每轮新连接都会触发新的告警和阻断防护并不依赖单条规则的持久性。实现方式也简单脚本里执行添加规则时顺带注册一个定时任务到期后自动执行删除命令。别忘了在白板里维护一张“当前拦截列表”方便人工排查问题时快速查看当前防火墙正处于封禁状态的IP集合。5.3 模拟攻击场景一端口扫描行为检测第一个验证场景是端口扫描。从模拟攻击主机向内网服务器发起一次全端口TCP扫描一次覆盖最常用的端口范围。预期结果有两层。第一层是防火墙的功能扫描过程中绝大多数端口会被防火墙壁垒挡住扫描结果会显示大量端口被过滤只有少数显式放行的端口Web、数据库正常开放。第二层是IDS的功能检测引擎会产生大量SYN扫描相关的告警因为这种行为特征非常明显——短时间高频连接尝试不同的端口是状态检测引擎最喜欢抓的典型异常模式。更重要的是验证联动阻断当扫描告警累计到阈值之后脚本会自动把攻击主机的IP加入防火墙黑名单。加入之后即使再次发起扫描也不会收到RST包或连接响应了——这就完成了“发现即阻断”的完整闭环。5.4 模拟攻击场景二应用层弱口令探测第二个验证场景更加贴近真实攻击。模拟外部主机对目标服务器的远程管理端口发起弱口令探测攻击即不断尝试常见的用户名密码组合。这个行为的特征和端口扫描完全不同源和目标端口固定但TCP连接频繁断开重连而且攻击载荷里有明显的协议交互特征。这类攻击防火墙是默许的——新连接建立、数据包收发看起来都符合正常业务逻辑除非有显式规则写死“封禁登录失败超过N次”否则传统防火墙几乎无能为力。但检测引擎在应用层识别能力上就有明显优势。规则集的检测能力能准确解包应用层协议发现连续多次身份认证失败后触发告警。实验中可以看到第一条失败尝试产生时会形成日志但尚不构成明确攻击特征随着尝试次数快速攀升告警量激增联动脚本在超过预设阈值后启动了IP封禁后续的探测连接全部超时。这个场景的教学价值最直接防火墙看的是“能不能连”IPS看的是“连上来干什么”。两个视角一叠加实际的防护纵身就出来了。5.5 攻击验证过程中的抓包分析联动阻断生效后不要急着写实验报告再做一步抓包验证。在攻击主机上对目标服务器进行少量端口的SYN探测同时在内网侧网卡上抓包观察整个交互过程。正常情况下会看到三次握手流程被防火墙拒绝对应一个TCP重置的回复完全被黑名单拦截后则没有任何回复只看到持续的SYN重传直到超时。这三种表现分别对应防火墙三种策略白名单放行、黑名单拒绝、静默丢包。抓包结果一定要截图存档这是证明实验完成度的最有力证据。我见过不少实验报告文字写了满满几页但一张抓包图都没有说服力大打折扣。网络实验如果拿不出报文级别的证据逻辑链是不完整的。6. 常见问题与排查技巧实录6.1 防火墙规则不生效的排查顺序做实验时最折磨人的问题不是配置复杂而是明明写了规则测出来却和预期完全不一样。我总结了一个固定排查顺序每次遇到的90%的问题都能按这个顺序找出来第一查数据包走的路径是否正确。很多人写的规则链和数据包实际走的链不一致比如转发流量写到了入站链上那规则永远匹配不到。第二查规则的顺序是否正确。防火墙策略是顺序匹配、首条优先匹配的机制如果前面有一条更宽的允许或拒绝规则涵盖了后续规则的范围那后面的规则根本执行不到。第三查默认策略是否可控。如果默认策略是拒绝却没有放行对应流量结果就是不通如果默认策略是接受那拒绝规则不生效时流量会静默通过看起来“好像没拦也没报错”。第四查日志确认数据包有没有真正到达主机。这一步能排除网卡、IP、路由等底层问题。这个排查思路的核心是先确认机制再排查配置最后再怀疑策略本身。如果一开始就盯着某条规则反复改方向很容易跑偏。6.2 IDS告警泛滥的“误报”处理思路检测引擎刚上线时有一个常见现象告警日志刷得飞快打开一看全是“误报”。比如内网正常服务器之间做时间同步协议通信也会被某些规则标记为可疑行为或者本机自己在做漏洞扫描实验时被检测引擎也在同一个网口抓到了自己产生的探测流量。处理误报的思路不是“把告警都删掉”而是分三步走先把同类告警合并统计看占比和来源。分析触发这条规则的流量特征判断是规则写得过宽还是主机行为确实偏离了基线。针对优先级较低且确认无风险的告警在规则配置里缩小范围比如限定源IP网段或直接禁用一个分类下的规则。有些初学者为了省事直接关闭日志输出这是最糟糕的做法。告警多不等于系统无用误报治理本身就是安全运营的一项常态工作学会和误报共处并逐步优化规则比追求一个“零误报”的假象重要得多。6.3 实验环境网络中断的应急恢复手段实验过程中最紧张的时刻是什么是把防火墙默认策略设置为拒绝后突然发现自己远程管理连接也被丢掉了或者更严重的是调节NAT规则时把访问目标服务器的通路弄断了同时外网口安全策略又因为临时改动变得异常严格。这种时候任何一个有过实操经验的人都会告诉你同一个字不要着急从图形界面反复点“应用”按钮而是要用最底层的手段去恢复。做防火墙实验强烈建议保留一台能够直接访问虚拟化控制台的备用终端也就是说即使虚拟机网络配置全废还能通过虚拟化平台自带的控制台窗口直接登录系统操作。开通串行控制台登录能力是这类实验的前提安全网。有了控制台通路之后最常见的恢复操作就是清空防火墙所有规则把默认策略改回接受先恢复连通再逐步重新配置。如果系统里开了快照直接回滚到最近的正常状态是最快的办法。所以做实验前一定养成一个习惯每完成一个阶段性配置就手动创建一个快照。这不丢人反而是正式运维时也常用的保护手段。6.4 日志检索技巧与小技巧汇总日志检索是这个实验里最耗时间的环节掌握几个小技巧能省一半精力按时间范围过滤只看攻击窗口内的日志避免被干扰信息淹没。按源IP聚合统计能快速判断是否存在一个高频攻击源。按端口号过滤可以定位特定服务的访问情况。联动日志与防火墙日志一起查看能还原一条攻击从触发告警到策略封禁的完整时间线。这些小技巧平时不会有人系统教但在真实的安全运维里能不能在十分钟内从几十万条日志里定位到一个异常IP直接决定了应急响应的效率。实验阶段多练练这些基本功后面工作上手会快很多。最后补一段操作心得实验做到这里整个“防火墙 入侵防护”的组合闭环就算跑通了。我个人最大的体会是不要把这两个系统割裂开来看它们本质上是同一道防线的两个位置——防火墙在最前面决定谁可以进入侵检测在门后面盯着进来看起来正常的人到底在搞什么动作发现异常再把前面的门关上。这个“门 监控 连锁关门”的机制比单独讨论某个产品强多少之类的问题要重要得多。后续如果想在这套环境上继续扩展方向也很明确试着把 HTTP 应用层的内容检测规则加进来或者把联动脚本里封禁策略的触发条件改得更精细一些比如按照威胁等级采取不同时长和不同范围的封禁动作。总之先把这套实验吃透再往上加东西就不难了。