简介面向网络运维与安全工程师这是一份Juniper防火墙巡检报告书模板适用于设备日常巡检、故障排查及交接验收等场景。资源包为单个PDF文档大小约78KB内容涵盖18项标准化巡检条目包括软件版本核对、日志与调试开关检查、系统时间校准、双机配置同步验证、接口状态与IP分配检查、CPU/内存/会话数监测、区域与策略配置审视等并给出Web与命令行两种检查方式及判定标准。模板以表格形式分类呈现检查内容、方法与合格标准一目了然既可作为现场巡检的Checklist也可作为新人培训的参考范本。巡检人员可对照逐项记录结果快速生成规范报告模板末尾还设有巡查结果总结、已解决/未解决问题记录以及工程师与客户签字栏便于存档和后续跟踪。已有116人学习下载适合需要规范化开展防火墙巡检或完善运维文档体系的技术人员。1. 防火墙巡检报告你不写防火墙就在替你写事故记录单连续两次在凌晨两点被叫到机房都是同一个现象防火墙CPU飙到90%以上业务端口通一下断一下登录Web管理台卡到超时。重启设备半小时后业务恢复但谁也说不出触发峰值的原因。翻开交接班记录只有一句“设备运行正常”。不是设备没给过信号而是没有人把信号记下来。防火墙的异常从来不是突然发生的会话数缓慢上涨、内存碎片持续累积、策略命中率悄悄偏移这些前兆每天都在设备上滚动只是没人把它变成一份能追溯的记录。防火墙巡检报告书模版要解决的正是“巡检做没做、做了什么、有没有异常”这三件事。它不是一个打印出来打勾的纸面表格而是一套把设备回显、阈值判断、结论归档串起来的运维证据链。适合三类人管着一堆防火墙却拿不出巡检记录的运维工程师、需要过等保或行业合规检查的网络管理员、以及刚接手防火墙设备、想快速建立运维习惯的入门从业者。这篇笔记会从巡检对象拆解开始一路讲清采集命令、报告字段设计和踩坑经验最后落到如何让报告自动生成。2. 巡检前先拆防火墙不同形态的设备巡检表不能共用一份2.1 边界防火墙、内网防火墙、主机防火墙三种角色的巡检权重很多巡检表翻车第一刀就砍在“所有防火墙一表通用”上。防火墙的形态决定了巡检项该往哪边倾斜硬套同一套指标要么漏掉关键项要么在一堆无关指标上浪费时间。边界防火墙是部署在互联网出口或园区出口的那台设备常用华为USG系列、H3C SecPath F1000系列或深信服AF。它承载NAT、策略控制、攻击防护巡检重心是接口带宽占用、并发会话数、策略命中率、以及WAN口丢包。这类设备最怕会话表被打满因为会话耗尽会导致新建连接直接丢弃表现是“网页能打开但登录不进去”网络层却看不出任何问题。内网防火墙通常部署在核心交换机和服务器区之间做东西向流量隔离。它的策略条数往往比边界防火墙还多黑白名单、端口放行规则、应用识别策略层层堆叠。巡检重心不是带宽而是策略冗余和命中率——一条从没人命中的策略在设备上躺了三年一旦被误命中就是安全事件。主机防火墙指Windows Server、Ubuntu、银河麒麟等操作系统自带的防火墙或者Docker宿主机的iptables/firewalld规则。它没有独立的管理IP也没有CPU内存可视化面板巡检就是查规则和查端口。Windows Server 2016上为1521端口Oracle放行过的规则是否还在、Ubuntu上ufw状态是否enabled、银河麒麟的firewalld有没有在系统更新后被重置——这些都是靠命令核对不能靠“应该没问题”的直觉。三种角色对应三类巡检表字段差异很大。边界防火墙必须写接口流量、会话数、CPU内网防火墙要写策略命中Top N和冗余规则数主机防火墙只需要一张端口放行清单和状态确认。把这三类内容混在一张表里必然有一半字段是空着的另一半字段填了也没人看。2.2 双机热备场景RBMVRRP 下要巡检的是“主备一致性”企业网里出于可用性考虑防火墙普遍做成双机热备。华为叫HRP华为冗余协议H3C叫RBMRemote Backup ManagementVRRP则是它们共同依赖的虚拟IP协议。在HCL模拟器里做RBMVRRP组网实验的人很多但真实设备上的巡检和模拟器完全是两回事。双机热备巡检最核心的一项不是“两台设备都活着”而是“两台设备配置一致、状态一致”。常见的翻车现场是主设备上新增了一条策略备设备没有同步主备切换后业务直接断掉。巡检时必须在主设备上执行display hrp state华为或display rbm infoH3C确认“Active”和“Standby”状态正常且配置一致性计数器为0。只要一致性计数不为0说明两台设备之间存在配置漂移需要立即手动同步不能等切换时才发现。VRRP层面要看虚拟IP和虚拟MAC的备份组状态。VRRP备份组里Master设备的主机名应该和HRP/RBM的主设备一致如果出现Master在A设备、RBM主节点也在A设备但VRRP报文异常的情况常见原因是心跳口和业务口配置混用或者gratuitous ARP报文被策略拦截。巡检时要同时记录主备设备的序列号、软件版本和补丁版本——版本不一致会导致VRRP抢占阶段出现协议协商异常这在平时看不出来一切换就出问题。模拟器里做RBMVRRP实验还有个特点设备重启后状态全部复位必须重新配置。真实设备上不会这样但巡检时如果发现备设备长时间处于“Initial”状态大概率是心跳链路断开或者心跳接口down了。这份状态记录要写进巡检表不能只看主设备。双机热备巡检的最大价值就是提前暴露那些“切换时才暴露”的问题让故障在巡检阶段现形而不是在割接窗口爆炸。2.3 单机与虚拟化容器和超融合环境里的防火墙在哪单机防火墙相对简单按通用巡检项走一遍即可但虚拟化环境里防火墙的位置经常让人找不着北。Docker宿主机就是一个典型例子Docker Daemon启动时会向iptables的FORWARD链写入大量规则同时修改nat表的POSTROUTING链。如果巡检时只查看iptables -L默认表会漏掉nat表里的规则反之如果直接在宿主机上执行iptables -F想去“清理防火墙”Docker容器会瞬间全部断网——这类事故已经发生过很多次。容器场景的巡检逻辑是先把Docker相关的链DOCKER、DOCKER-USER完整列出来确认docker-proxy进程监听在预期的映射端口上再检查firewalld是否开启了伪装masquerade。Docker的端口映射走的是DNATfirewalld里的端口转发和Docker端口映射之间如果配置冲突表现是外部访问容器端口时通时不通防火墙状态确显示一切正常。超融合或虚拟化平台里的防火墙还有一层虚拟机内部防火墙。很多运维只在物理防火墙层面做巡检忽略虚拟机内部OS的防火墙配置是否和网络拓扑一致。比如一台Windows Server 2016上跑着Oracle1521端口在物理防火墙放行了但虚拟机内Windows防火墙的入站规则没有放行业务照样不通。巡检时要顺着业务链路从物理防火墙一直查到虚拟机内防火墙任何一层的默认策略变更都会导致业务静默中断。3. 巡检项和采集命令这张表带回去就能抄3.1 硬件与系统资源最不容易出问题出问题就是大问题防火墙的硬件巡检项包括电源模块、风扇转速、设备温度、板卡状态。华为USG系列用display device、display power、display fan三条命令就能看到全部硬件状态H3C设备对应的是display device、display power、display fan命令格式和华为高度相近但输出字段略有差异前者会显示“Slot”信息后者按“PowerID”“FanID”区分。系统资源方面CPU和内存是必检项。防火墙的CPU使用率和交换机的不同它处理的是深度报文检测DPICPU占用很容易被安全策略的深度检测功能推高。所以不能只看CPU平均值建议用display cpu-usage查看最近5秒、1分钟、5分钟的利用率曲线如果5秒均值持续高于70%说明业务流量已经逼近处理上限。内存关注点则是使用率和碎片化程度华为设备上执行display memory-usage可以看到内存占用比例超过90%时要警惕内存耗尽导致的业务模块异常重启。风扇转速很多人不填因为觉得“设备能ping通就是没坏”。实际上防火墙风扇在环境温度高时会加速如果转速日志显示持续高转速且伴随高温报警大概率是防尘网堵塞或风扇轴承老化不换会在夏天宕机。设备温度建议记录“当前值”并和历史巡检值做对比温度从45°C涨到55°C比绝对值更有预警价值。3.2 安全策略与规则管理黑白名单、策略命中率是核心策略巡检不能只看“策略有没有”要看“策略有没有被用起来”。常见做法是登录设备Web管理台在策略列表里翻看命中计数器或者通过命令行采集命中次数。华为防火墙查看策略命中用display firewall policy hit-count输出是每一条策略的命中次数和最近命中时间H3C设备用display security-policy ip同样能看到命中统计。巡检时重点标记两类策略一类是命中次数长期为0的策略这类冗余策略要么删除要么归档另一类是命中次数异常上涨的策略这往往代表访问行为发生变化——可能是正常业务扩张也可能是攻击流量正在借道。黑白名单是策略巡检里容易被忽略的角落。黑名单的命中次数决定了它的防护价值如果黑名单三个月没有一次命中IP地址可能已经失效白名单的审计价值更高每一条白名单都意味着“绕过所有安全检测直接放行”巡检时必须确认白名单条目的业务归属。我一般会在巡检表里单列一行“白名单变更记录”谁加的、为什么加、预计保留多长时间这三项缺一不可。策略巡检的另一个痛点是策略数量膨胀。一台边界防火墙用了五年策略条数从50条涨到500条其中大部分是临时放行后忘了回收的。巡检报告里加一项“策略总数与活跃策略数对比”能直观反映策略库的健康度——当活跃率低于60%时就该启动一次策略清理。3.3 会话与隧道状态IPSec隧道的完整性和密钥寿命会话数直接决定防火墙能扛住多少并发业务。华为设备用display firewall session table statistics查看当前会话总数H3C设备是display session statistics。会话数的绝对值和设备型号相关一台入门级防火墙会话上限可能是10万中端设备50万到100万巡检时要把当前会话数和设备规格上限做对比给出“会话利用率”指标。会话巡检还要看TCP连接状态分布。正常业务流的会话状态中ESTABLISHED应该占绝大多数如果SYN_SENT或FIN_WAIT类状态的会话比例偏高说明有端口扫描或异常连接在消耗会话资源。华为设备上还可以用display firewall session table verbose看到具体会话的源目IP、端口和协议配合抓包定位异常流量来源。IPSec隧道巡检不能只看隧道状态是up就草草收场。隧道up只能说明IKE协商成功业务数据能不能正常加密传输还要看安全联盟SA的SPI值是否一致。华为设备用display ipsec sa查看隧道两端的入站和出站SAH3C设备用display ipsec sa brief。巡检要点是确认隧道两端协商出的加密算法和认证算法一致——曾经遇到过站点A配置了AES-256站点B配置了AES-128隧道依然显示up但传输速率极不稳定数据包反复重传。密钥寿命也要记录。IPSec隧道的密钥会在生命周期结束时自动重协商重协商期间存在毫秒级中断。如果巡检时发现隧道的剩余寿命低于下次巡检间隔应该主动手动触发重协商避免在业务高峰时段突然断流。记录“上次密钥更新时间和剩余寿命”两列数据能防止这个坑。3.4 日志与备份把采集命令写成脚本日志巡检的重点是攻击日志和系统登录日志。华为设备用display logbuffer查看内存日志缓冲区其中记录了设备自身的操作日志和安全事件dis firewall log-record attack能查到具体的攻击拦截记录。日志里最常见的问题是时间不同步——设备时区设置为GMT而不是GMT08:00导致日志时间比真实时间慢8小时这在攻击溯源时会带来很大麻烦。巡检第一项应该是确认NTP同步状态。备份巡检是巡检报告里“防御性”最强的一项。设备配置和系统文件需要定期备份到外部服务器不能只存在设备本地。华为设备的配置可以display current-configuration后手工保存或者配置了SFTP服务器后自动备份。H3C设备同样支持配置导出。备份巡检的标准动作有两个确认备份文件成功生成、校验备份文件能被正常加载。第二个动作很多人不做等到设备故障要用备份文件恢复时才发现备份文件损坏那才是真正的叫天天不应。以下脚本是我常用的采集方式SSH登录设备后批量拉取关键信息#!/bin/bash # 防火墙巡检信息采集脚本华为USG系列示例 # 用法: ./collect_fw_info.sh 192.168.1.254 admin password HOST$1 USER$2 PASS$3 # 记录采集时间用于和报告中的巡检日期对齐 echo $(date %Y-%m-%d %H:%M:%S) 开始采集 $HOST # 硬件状态设备型号序列号、电源风扇温度 sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display device; display power; display fan; display environment # CPU与内存5秒/1分钟/5分钟平均值以及内存占用率 sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display cpu-usage; display memory-usage # 会话统计总会话数、会话速率、TCP状态分布 sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display firewall session table statistics; display firewall session table stat # 双机热备状态如果启用了HRP sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display hrp state; display vrrp # 安全策略命中计数Top 20 sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display firewall policy hit-count top 20 # IPsec隧道状态与SA信息 sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display ipsec tunnel brief; display ipsec sa echo $HOST 采集完成 这段脚本的逻辑很直接用sshpass传入密码避免交互式输入卡住自动化流程每次采集前echo一行带时间戳的分隔线方便后续把多台设备的回显拼接到一个文件时区分来源。display device和display environment分别拿硬件状态和温度display cpu-usage看趋势数据display firewall session table statistics看会话数是否逼近上限。执行时要注意三点。第一sshpass需要单独安装CentOS上yum install sshpass、Ubuntu上apt install sshpass。第二设备上需要开启SSH服务华为防火墙默认只开Telnet需要先在Web管理台或Console口把SSH服务打开。第三严禁在巡检脚本里使用默认密码并长期保存在服务器上建议用密钥认证替代密码或者用Ansible的vault加密存储凭据。采集是第一步把回显里的关键字段整理成结构化表格才是真正的工作量。以下Python脚本解析session statistics回显提取会话总数和TCP状态分布#!/usr/bin/env python3 解析华为防火墙会话状态回显生成CSV巡检记录 import re import csv import sys def parse_session_stats(output: str) - dict: result {} # 华为设备回显示例: # TCP established: 24567 # TCP syn_sent: 12 # UDP: 18932 # ICMP: 456 patterns { tcp_established: rTCP established:\s(\d), tcp_syn_sent: rTCP syn_sent:\s(\d), udp_total: rUDP:\s(\d), icmp_total: rICMP:\s(\d), } for key, pattern in patterns.items(): match re.search(pattern, output) if match: result[key] int(match.group(1)) # 总会话数一般是各协议之和部分版本直接输出汇总行 total_match re.search(rTotal session:\s(\d), output) result[total_session] int(total_match.group(1)) if total_match else sum(result.values()) return result def main(): raw_output sys.stdin.read() stats parse_session_stats(raw_output) # 写CSV方便直接追加到巡检报告附件的Excel中 with open(session_stats.csv, a, newline) as f: writer csv.writer(f) if f.tell() 0: writer.writerow([timestamp, total_session, tcp_established, tcp_syn_sent, udp_total, icmp_total]) writer.writerow([ __import__(datetime).datetime.now().isoformat(), stats.get(total_session, 0), stats.get(tcp_established, 0), stats.get(tcp_syn_sent, 0), stats.get(udp_total, 0), stats.get(icmp_total, 0), ]) print(f记录完成: total_session{stats[total_session]}) if __name__ __main__: main()这段脚本的价值在于把“看完回显凭感觉判断”升级为“数值入库可对比”。TCP syn_sent一旦持续增长脚本记录的CSV里会留下曲线不用等到设备告警才发现异常。有条件的团队可以用Grafana直接接数据库展示趋势把每台防火墙的日常采集数据变成可视化面板。3.5 巡检频率与阈值建议巡检频率方面不同设备形态适用的频率不同。核心边界防火墙和双机热备主设备建议每周巡检一次内网防火墙可以每两周一次主机防火墙在版本变更或服务器重启后专项巡检。如果公司有等保要求则必须按等保周期实施一般也是每月覆盖一次全量设备。阈值建议以硬件基线为参考。CPU使用率5秒均值超过70%标记为“关注”超过85%标记为“告警”内存使用率超过85%关注、90%告警会话数超过设备规格上限的70%关注、85%告警。IPSec隧道SA剩余寿命低于当前时间到下次巡检间隔的两倍时触发预警。策略命中率为0且策略存在时间超过90天的标记为“待清理”白名单策略必须每季度复核一次业务归属。4. 编制防火墙巡检报告书模版从字段到PDF的完整落地路径4.1 报告章节结构让看报告的人能一眼找到结论一份巡检报告书模版结构上要能让三类人各取所需执行巡检的人要看设备明细、审批的领导要看健康度结论、审计的人要看证据链。我常用的报告章节结构是“封面与结论前置”的布局设备清单、巡检时间、巡检人信息放封面页健康度总评放在第二页用一张表格列出每台设备的综合结论从第三页开始才是设备明细每台设备占两页——第一页是设备基础信息和硬件状态第二页是策略、会话、隧道、日志、备份等专项巡检记录最后一页放问题清单和整改建议。审计的人拿到报告不需要翻设备明细直接看健康度总评和问题清单就能定位风险。巡检结论不能写“正常”两个字就完事。模版里要给每个巡检项预设判定标准硬件类用正常/关注/异常三档策略类用通过/待优化/不通过三档每个非“正常/通过”的结论必须填写说明原因和整改建议。留白反而会消灭信息——模版设计得越严格巡检人员越不容易敷衍。4.2 巡检表字段设计设备信息、巡检项、阈值、结论四层结构巡检报告的核心是那张巡检记录表。表头不能只有“巡检项”和“结果”必须有“现场数据”和“参考阈值”这两列——否则三个月后回看报告只能看到一个“正常”根本想不起来当时设备实际跑了多少会话。字段设计可以这样拆设备信息层设备名称、品牌型号、软件版本、补丁版本、序列号、部署位置、角色边界/内网/主机、管理IP。这些字段每次巡检都要重新采集因为设备可能被更换过部件、升级过版本这些变化比“CPU高了几个点”更值得关注。巡检项层按硬件、资源、会话、策略、隧道、日志、备份、热备八个维度展开。每一行是一个具体巡检项例如“电源模块状态”“CPU均值”“会话总数”“策略命中Top10”等。巡检项的名称要具体到命令级别比如“display device的输出中Power状态是否为Present/OK”这样换一个人来执行也能保持一致性。阈值层每个巡检项配一个“参考阈值”这是用来做自动判定的依据。阈值不是拍脑袋写上去的应该取自设备规格书或历史基线——第一次巡检时记录设备正常负载下的数据作为基线之后每次巡检的阈值按基线值的80%设定比设备规格上限更早触发预警。结论层最后三列分别是“状态”正常/关注/异常“问题描述”“整改建议”。状态为“关注”或“异常”时后两列必须填写不允许有空白——这能倒逼巡检人员去了解为什么数据会异常而不是机械地抄数字。4.3 用 Markdown 生成 PDF 模版免费且可控的落地方式市面上有专业的网络运维软件可以直接生成巡检报告但价格和维护成本不低。个人或中小团队更实际的路径是用Markdown写报告正文搭配Pandoc转成PDF再套一个简洁的标题页。不需要购买商业文档组件也不需要学复杂的模板语法。--- title: 防火墙巡检报告 date: 2026-01-15 author: 网络运维组 toc: false --- # 设备健康度总评 | 设备名称 | 设备型号 | 巡检结论 | 问题数 | |---------|---------|---------|-------| | FW-边界-01 | USG6650 | 关注 | 2 | | FW-内网-02 | SecPath F1000 | 正常 | 0 | # FW-边界-01 巡检明细 ## 硬件状态 - 电源模块正常双电源均工作 - 风扇转速正常转速 5200 RPM设备温度 45°C - CPU5秒均值 62%1分钟均值 55%5分钟均值 50% ## 会话状态 - 当前会话总数68,320规格上限 100,000利用率 68.3% - TCP established62,180TCP syn_sent15UDP5,200 ## 问题与整改 1. CPU 5秒均值 62% 超过关注阈值 60%建议排查是否有新业务上线 2. 策略 105 条活跃 70 条活跃率 66.7%建议清理冗余策略Pandoc转换命令pandoc report.md -o report.pdf --pdf-enginexelatex \ -V CJKmainfontNoto Sans CJK SC \ -V geometry:margin2.5cm \ -V fontsize11pt这段命令的要点是--pdf-enginexelatex中文PDF必须用XeLaTeX引擎才能正确渲染中文字体CJKmainfont指定中文字体Linux系统上一般装Noto Sans CJK SC即可macOS可以用PingFang SCgeometry设置页边距为2.5厘米上下左右留白均匀打印装订不裁切内容。生成后的PDF就是一份可直接归档的任意命名文件比如“防火墙巡检报告_20260115.pdf”。文件内部自带目录可以由toc配置控制但在线巡检报告一般不用自动目录因为页数不多文章里Markdown的一二级标题已经能表达层级关系。这个方案的好处是内容可版本控制——把Markdown源文件存进Git仓库每次巡检记录的变更历史全部留痕审计时可以把PDF和Git提交记录对起来。4.4 巡检结论怎么写从“正常”到“健康度的量化”巡检报告书的结论部分最容易流于形式。我见过不少报告全文只写“设备运行正常”没有任何量化依据。一个可复用的做法是给每台设备算一个“健康度评分”基础分100分按巡检项的异常程度扣分出现“关注”级问题每项扣5分“异常”级问题每项扣15分扣完为止。90分以上为“健康”每项指标都在阈值内70到90分为“关注”存在需要处理的隐患但业务未受影响70分以下为“告警”必须在下次巡检前完成整改。评分制的好处是把“正常/关注/异常”的定性结论变成可比的历史数据——一台设备连续三个月都是80分虽然每次都能解释为“业务增长导致CPU升高”但三个月累计的趋势说明设备快扛不住了该做扩容规划了。评分之外每台设备的结论最好配一句“一句话描述”。比如“设备整体健康但会话利用率持续三个月上升建议关注扩容需求”——这句话写起来不费劲但能让看完报告的领导直接理解接下来该干什么。巡检报告不是写给设备看的是写给决策的人看的结论要让不懂命令行的人也能行动。5. 防火墙巡检避坑这些翻车现场我都替你踩过了5.1 Web界面显示“运行正常”内存已经用了95%现象某次巡检登录Web管理台首页设备状态展示区全部是绿色勾选包括内存占用率显示为95%。报告里差点就写“设备运行正常”但命令行执行display memory-usage时系统提示内存占用达到告警阈值且部分业务模块已经进入“过载保护”状态。原因Web管理台的在线状态刷新机制存在滞后页面可能停留在几分钟前甚至更早的缓存数据上。另一方面防火墙的内存使用率包含多个模块的共享内存和专用内存Web界面显示的是综合值而命令行能看到各模块的明细某个模块内存耗尽但总占比没有达到红色告警线时Web界面依然显示正常。解决巡检以命令行回显为准Web界面只作为辅助查看。display memory-usage看到总占比偏高时继续用display memory-usage slot加上模块维度命令下钻找到具体是哪个进程占用内存。给巡检表加一条规则Web界面状态必须与命令行回显一致才可判定为正常任何不一致都按异常处理。5.2 华为防火墙的会话表统计“按条”还是“按对”搞不清现象巡检时用display firewall session table statistics看到会话总数是三万但设备规格表标注的会话上限是五万结论就是“利用率60%”。后来做容量评估时发现实际并发业务量已经接近设备瓶颈原因是口径搞错了。原因华为防火墙的会话表项分为“单向表项”和“双向表项”两种部分版本统计命令输出的是表项数量而不是完整会话数量。一个完整的TCP连接需要两个方向各一条表项所以真实会话数是表项数的一半三万条表项对应约一万五千个会话。解决先确认设备软件版本的统计口径。用display firewall session table statistics输出的total不是唯一依据可以和display session table verbose逐条统计对比。巡检表里标明“会话数据采集口径双向会话/表项”并和设备的规格表按同一口径对比。不确定时就抓几个典型业务流量通过源目IP和端口确认一个连接占用的表项数。5.3 锐捷/H3C/华为命令不同同一份命令表不能全品牌通用现象一份巡检脚本在华为USG设备上运行正常换到H3C SecPath F1000上SSH登录和大部分命令都能执行但display firewall session table statistics这条命令直接报错。华为的防火墙命令体系继承自USG系列H3C的则是comware体系两者虽然长得像关键查询命令的差异很大。原因各厂商的命令行体系来源不同华为USG走VRP平台H3C走Comware平台锐捷又另起一套。display firewall session table是华为的专有命令H3C查看会话要分两条display session statistics看汇总display session table ipv4看明细。策略命中查看也是两套体系华为是display firewall policy hit-countH3C是display security-policy ip statistics。解决巡检命令表必须按品牌分列。我在报告模版里维护了一张“命令对照表”同一巡检项对应华为命令、H3C命令、锐捷命令三列执行时按设备品牌选择对应列。新接入设备品牌前先花半天时间在一台测试设备上跑通全部命令再纳入正式巡检范围。5.4 把“重启即恢复”写进巡检记录等于承认没有根因现象巡检记录里有一条“设备出现CPU过高告警重启后恢复正常”下一个巡检周期同样的问题又出现。连续三次都是同一个处理方法第四次终于扛不住业务中断半小时。原因CPU过高的根因没有被找到。重启只是清掉了当前的内存碎片和临时会话缓存但触发CPU升高的业务流量还在策略配置也没有调整。把“重启即恢复”当作结论等于给下一次故障埋了雷。解决巡检记录里的“处理措施”一栏禁止写“重启即可”。必须写清楚重启之前采集了哪些数据、数据指向什么结论、下一步要验证什么。例如CPU过高会话数快速上涨需要检查是哪个源IP在大量新建连接顺手抓一段报文分析策略命中异常上涨则要确认是哪条策略、哪个业务在调用。报告里写明根因分析下一次复现就有据可查。5.5 日志时间不同步攻击溯源时差八小时现象某次安全事件溯源需要核对防火墙攻击日志和服务器应用日志的先后顺序发现防火墙记录的拦截时间比服务器时间早了8个小时时间线完全对不上。原因防火墙的时区默认为GMT没有改成GMT08:00。虽然设备日志的时间戳本身是连续的当和业务服务器、NTP服务器的时间联动时8小时的偏移让所有攻击分析都失去了参照系。解决时间同步检查列为巡检第一项。登录设备后用display clock確認系统时间和时区如果时区不是中国标准时间立即修正并配置NTP服务器。巡检表里加一列“NTP状态”确认设备已达到同步状态并在日志中留下同步记录。这个坑最容易踩也最容易修但最容易被忽略。6. 把巡检报告书变成技术资产不靠人记靠脚本生成和留痕最后一层进阶是把巡检报告书从“手工填写”升级为“半自动产物”。前面写的采集脚本可以定时执行Markdown转PDF的流程可以打包成一键脚本每天早上八点自动对核心防火墙跑一遍巡检生成当日PDF并归档到指定目录。不追求全自动生成可发布的报告而是让“采集数据初步判定”自动化巡检人员只需要处理“关注”和“异常”项把精力放在分析和整改上。定时任务可以这样设计crontab里每天执行一次采集脚本输出原始回显和一个粗略的状态CSV每周五生成周报PDF汇总一周的趋势数据敏感设备如双机热备主设备则每天采集状态异常时通过短信或企业微信群机器人推送告警。生成的PDF文件名带上日期和设备名归档目录按年份组织配合Git仓库管理Markdown源文件等于给每台防火墙建立了一份可回溯的健康档案。回看这套方案最大价值不是“省了写报告的时间”而是让巡检从“应付检查”变成“发现问题”。一台防火墙的会话数连续五周上涨、策略命中率持续下降、双机热备一致性计数反复出现非零值这些趋势不会通过一次Web界面截图暴露但它们都会在量化指标的历史曲线里留下痕迹。我自己的习惯是每月翻一次趋势数据只看异常点和拐点不看正常值——异常点才是指向故障的第一线索。巡检报告书模版的技术含量不高但它是一个能把运维经验沉淀下来的载体。反应快、记性好不如一条准确的趋势曲线管用。希望这篇笔记能帮你把防火墙巡检从“打勾交差”变成“数据留痕”下次设备再出问题时翻一翻历史报告就能找到真正的答案。本文还有配套的精品资源点击获取 防火墙巡检报告书模版：从命令采集到自动化留痕的运维闭环
简介面向网络运维与安全工程师这是一份Juniper防火墙巡检报告书模板适用于设备日常巡检、故障排查及交接验收等场景。资源包为单个PDF文档大小约78KB内容涵盖18项标准化巡检条目包括软件版本核对、日志与调试开关检查、系统时间校准、双机配置同步验证、接口状态与IP分配检查、CPU/内存/会话数监测、区域与策略配置审视等并给出Web与命令行两种检查方式及判定标准。模板以表格形式分类呈现检查内容、方法与合格标准一目了然既可作为现场巡检的Checklist也可作为新人培训的参考范本。巡检人员可对照逐项记录结果快速生成规范报告模板末尾还设有巡查结果总结、已解决/未解决问题记录以及工程师与客户签字栏便于存档和后续跟踪。已有116人学习下载适合需要规范化开展防火墙巡检或完善运维文档体系的技术人员。1. 防火墙巡检报告你不写防火墙就在替你写事故记录单连续两次在凌晨两点被叫到机房都是同一个现象防火墙CPU飙到90%以上业务端口通一下断一下登录Web管理台卡到超时。重启设备半小时后业务恢复但谁也说不出触发峰值的原因。翻开交接班记录只有一句“设备运行正常”。不是设备没给过信号而是没有人把信号记下来。防火墙的异常从来不是突然发生的会话数缓慢上涨、内存碎片持续累积、策略命中率悄悄偏移这些前兆每天都在设备上滚动只是没人把它变成一份能追溯的记录。防火墙巡检报告书模版要解决的正是“巡检做没做、做了什么、有没有异常”这三件事。它不是一个打印出来打勾的纸面表格而是一套把设备回显、阈值判断、结论归档串起来的运维证据链。适合三类人管着一堆防火墙却拿不出巡检记录的运维工程师、需要过等保或行业合规检查的网络管理员、以及刚接手防火墙设备、想快速建立运维习惯的入门从业者。这篇笔记会从巡检对象拆解开始一路讲清采集命令、报告字段设计和踩坑经验最后落到如何让报告自动生成。2. 巡检前先拆防火墙不同形态的设备巡检表不能共用一份2.1 边界防火墙、内网防火墙、主机防火墙三种角色的巡检权重很多巡检表翻车第一刀就砍在“所有防火墙一表通用”上。防火墙的形态决定了巡检项该往哪边倾斜硬套同一套指标要么漏掉关键项要么在一堆无关指标上浪费时间。边界防火墙是部署在互联网出口或园区出口的那台设备常用华为USG系列、H3C SecPath F1000系列或深信服AF。它承载NAT、策略控制、攻击防护巡检重心是接口带宽占用、并发会话数、策略命中率、以及WAN口丢包。这类设备最怕会话表被打满因为会话耗尽会导致新建连接直接丢弃表现是“网页能打开但登录不进去”网络层却看不出任何问题。内网防火墙通常部署在核心交换机和服务器区之间做东西向流量隔离。它的策略条数往往比边界防火墙还多黑白名单、端口放行规则、应用识别策略层层堆叠。巡检重心不是带宽而是策略冗余和命中率——一条从没人命中的策略在设备上躺了三年一旦被误命中就是安全事件。主机防火墙指Windows Server、Ubuntu、银河麒麟等操作系统自带的防火墙或者Docker宿主机的iptables/firewalld规则。它没有独立的管理IP也没有CPU内存可视化面板巡检就是查规则和查端口。Windows Server 2016上为1521端口Oracle放行过的规则是否还在、Ubuntu上ufw状态是否enabled、银河麒麟的firewalld有没有在系统更新后被重置——这些都是靠命令核对不能靠“应该没问题”的直觉。三种角色对应三类巡检表字段差异很大。边界防火墙必须写接口流量、会话数、CPU内网防火墙要写策略命中Top N和冗余规则数主机防火墙只需要一张端口放行清单和状态确认。把这三类内容混在一张表里必然有一半字段是空着的另一半字段填了也没人看。2.2 双机热备场景RBMVRRP 下要巡检的是“主备一致性”企业网里出于可用性考虑防火墙普遍做成双机热备。华为叫HRP华为冗余协议H3C叫RBMRemote Backup ManagementVRRP则是它们共同依赖的虚拟IP协议。在HCL模拟器里做RBMVRRP组网实验的人很多但真实设备上的巡检和模拟器完全是两回事。双机热备巡检最核心的一项不是“两台设备都活着”而是“两台设备配置一致、状态一致”。常见的翻车现场是主设备上新增了一条策略备设备没有同步主备切换后业务直接断掉。巡检时必须在主设备上执行display hrp state华为或display rbm infoH3C确认“Active”和“Standby”状态正常且配置一致性计数器为0。只要一致性计数不为0说明两台设备之间存在配置漂移需要立即手动同步不能等切换时才发现。VRRP层面要看虚拟IP和虚拟MAC的备份组状态。VRRP备份组里Master设备的主机名应该和HRP/RBM的主设备一致如果出现Master在A设备、RBM主节点也在A设备但VRRP报文异常的情况常见原因是心跳口和业务口配置混用或者gratuitous ARP报文被策略拦截。巡检时要同时记录主备设备的序列号、软件版本和补丁版本——版本不一致会导致VRRP抢占阶段出现协议协商异常这在平时看不出来一切换就出问题。模拟器里做RBMVRRP实验还有个特点设备重启后状态全部复位必须重新配置。真实设备上不会这样但巡检时如果发现备设备长时间处于“Initial”状态大概率是心跳链路断开或者心跳接口down了。这份状态记录要写进巡检表不能只看主设备。双机热备巡检的最大价值就是提前暴露那些“切换时才暴露”的问题让故障在巡检阶段现形而不是在割接窗口爆炸。2.3 单机与虚拟化容器和超融合环境里的防火墙在哪单机防火墙相对简单按通用巡检项走一遍即可但虚拟化环境里防火墙的位置经常让人找不着北。Docker宿主机就是一个典型例子Docker Daemon启动时会向iptables的FORWARD链写入大量规则同时修改nat表的POSTROUTING链。如果巡检时只查看iptables -L默认表会漏掉nat表里的规则反之如果直接在宿主机上执行iptables -F想去“清理防火墙”Docker容器会瞬间全部断网——这类事故已经发生过很多次。容器场景的巡检逻辑是先把Docker相关的链DOCKER、DOCKER-USER完整列出来确认docker-proxy进程监听在预期的映射端口上再检查firewalld是否开启了伪装masquerade。Docker的端口映射走的是DNATfirewalld里的端口转发和Docker端口映射之间如果配置冲突表现是外部访问容器端口时通时不通防火墙状态确显示一切正常。超融合或虚拟化平台里的防火墙还有一层虚拟机内部防火墙。很多运维只在物理防火墙层面做巡检忽略虚拟机内部OS的防火墙配置是否和网络拓扑一致。比如一台Windows Server 2016上跑着Oracle1521端口在物理防火墙放行了但虚拟机内Windows防火墙的入站规则没有放行业务照样不通。巡检时要顺着业务链路从物理防火墙一直查到虚拟机内防火墙任何一层的默认策略变更都会导致业务静默中断。3. 巡检项和采集命令这张表带回去就能抄3.1 硬件与系统资源最不容易出问题出问题就是大问题防火墙的硬件巡检项包括电源模块、风扇转速、设备温度、板卡状态。华为USG系列用display device、display power、display fan三条命令就能看到全部硬件状态H3C设备对应的是display device、display power、display fan命令格式和华为高度相近但输出字段略有差异前者会显示“Slot”信息后者按“PowerID”“FanID”区分。系统资源方面CPU和内存是必检项。防火墙的CPU使用率和交换机的不同它处理的是深度报文检测DPICPU占用很容易被安全策略的深度检测功能推高。所以不能只看CPU平均值建议用display cpu-usage查看最近5秒、1分钟、5分钟的利用率曲线如果5秒均值持续高于70%说明业务流量已经逼近处理上限。内存关注点则是使用率和碎片化程度华为设备上执行display memory-usage可以看到内存占用比例超过90%时要警惕内存耗尽导致的业务模块异常重启。风扇转速很多人不填因为觉得“设备能ping通就是没坏”。实际上防火墙风扇在环境温度高时会加速如果转速日志显示持续高转速且伴随高温报警大概率是防尘网堵塞或风扇轴承老化不换会在夏天宕机。设备温度建议记录“当前值”并和历史巡检值做对比温度从45°C涨到55°C比绝对值更有预警价值。3.2 安全策略与规则管理黑白名单、策略命中率是核心策略巡检不能只看“策略有没有”要看“策略有没有被用起来”。常见做法是登录设备Web管理台在策略列表里翻看命中计数器或者通过命令行采集命中次数。华为防火墙查看策略命中用display firewall policy hit-count输出是每一条策略的命中次数和最近命中时间H3C设备用display security-policy ip同样能看到命中统计。巡检时重点标记两类策略一类是命中次数长期为0的策略这类冗余策略要么删除要么归档另一类是命中次数异常上涨的策略这往往代表访问行为发生变化——可能是正常业务扩张也可能是攻击流量正在借道。黑白名单是策略巡检里容易被忽略的角落。黑名单的命中次数决定了它的防护价值如果黑名单三个月没有一次命中IP地址可能已经失效白名单的审计价值更高每一条白名单都意味着“绕过所有安全检测直接放行”巡检时必须确认白名单条目的业务归属。我一般会在巡检表里单列一行“白名单变更记录”谁加的、为什么加、预计保留多长时间这三项缺一不可。策略巡检的另一个痛点是策略数量膨胀。一台边界防火墙用了五年策略条数从50条涨到500条其中大部分是临时放行后忘了回收的。巡检报告里加一项“策略总数与活跃策略数对比”能直观反映策略库的健康度——当活跃率低于60%时就该启动一次策略清理。3.3 会话与隧道状态IPSec隧道的完整性和密钥寿命会话数直接决定防火墙能扛住多少并发业务。华为设备用display firewall session table statistics查看当前会话总数H3C设备是display session statistics。会话数的绝对值和设备型号相关一台入门级防火墙会话上限可能是10万中端设备50万到100万巡检时要把当前会话数和设备规格上限做对比给出“会话利用率”指标。会话巡检还要看TCP连接状态分布。正常业务流的会话状态中ESTABLISHED应该占绝大多数如果SYN_SENT或FIN_WAIT类状态的会话比例偏高说明有端口扫描或异常连接在消耗会话资源。华为设备上还可以用display firewall session table verbose看到具体会话的源目IP、端口和协议配合抓包定位异常流量来源。IPSec隧道巡检不能只看隧道状态是up就草草收场。隧道up只能说明IKE协商成功业务数据能不能正常加密传输还要看安全联盟SA的SPI值是否一致。华为设备用display ipsec sa查看隧道两端的入站和出站SAH3C设备用display ipsec sa brief。巡检要点是确认隧道两端协商出的加密算法和认证算法一致——曾经遇到过站点A配置了AES-256站点B配置了AES-128隧道依然显示up但传输速率极不稳定数据包反复重传。密钥寿命也要记录。IPSec隧道的密钥会在生命周期结束时自动重协商重协商期间存在毫秒级中断。如果巡检时发现隧道的剩余寿命低于下次巡检间隔应该主动手动触发重协商避免在业务高峰时段突然断流。记录“上次密钥更新时间和剩余寿命”两列数据能防止这个坑。3.4 日志与备份把采集命令写成脚本日志巡检的重点是攻击日志和系统登录日志。华为设备用display logbuffer查看内存日志缓冲区其中记录了设备自身的操作日志和安全事件dis firewall log-record attack能查到具体的攻击拦截记录。日志里最常见的问题是时间不同步——设备时区设置为GMT而不是GMT08:00导致日志时间比真实时间慢8小时这在攻击溯源时会带来很大麻烦。巡检第一项应该是确认NTP同步状态。备份巡检是巡检报告里“防御性”最强的一项。设备配置和系统文件需要定期备份到外部服务器不能只存在设备本地。华为设备的配置可以display current-configuration后手工保存或者配置了SFTP服务器后自动备份。H3C设备同样支持配置导出。备份巡检的标准动作有两个确认备份文件成功生成、校验备份文件能被正常加载。第二个动作很多人不做等到设备故障要用备份文件恢复时才发现备份文件损坏那才是真正的叫天天不应。以下脚本是我常用的采集方式SSH登录设备后批量拉取关键信息#!/bin/bash # 防火墙巡检信息采集脚本华为USG系列示例 # 用法: ./collect_fw_info.sh 192.168.1.254 admin password HOST$1 USER$2 PASS$3 # 记录采集时间用于和报告中的巡检日期对齐 echo $(date %Y-%m-%d %H:%M:%S) 开始采集 $HOST # 硬件状态设备型号序列号、电源风扇温度 sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display device; display power; display fan; display environment # CPU与内存5秒/1分钟/5分钟平均值以及内存占用率 sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display cpu-usage; display memory-usage # 会话统计总会话数、会话速率、TCP状态分布 sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display firewall session table statistics; display firewall session table stat # 双机热备状态如果启用了HRP sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display hrp state; display vrrp # 安全策略命中计数Top 20 sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display firewall policy hit-count top 20 # IPsec隧道状态与SA信息 sshpass -p $PASS ssh -o StrictHostKeyCheckingno $USER$HOST \ display ipsec tunnel brief; display ipsec sa echo $HOST 采集完成 这段脚本的逻辑很直接用sshpass传入密码避免交互式输入卡住自动化流程每次采集前echo一行带时间戳的分隔线方便后续把多台设备的回显拼接到一个文件时区分来源。display device和display environment分别拿硬件状态和温度display cpu-usage看趋势数据display firewall session table statistics看会话数是否逼近上限。执行时要注意三点。第一sshpass需要单独安装CentOS上yum install sshpass、Ubuntu上apt install sshpass。第二设备上需要开启SSH服务华为防火墙默认只开Telnet需要先在Web管理台或Console口把SSH服务打开。第三严禁在巡检脚本里使用默认密码并长期保存在服务器上建议用密钥认证替代密码或者用Ansible的vault加密存储凭据。采集是第一步把回显里的关键字段整理成结构化表格才是真正的工作量。以下Python脚本解析session statistics回显提取会话总数和TCP状态分布#!/usr/bin/env python3 解析华为防火墙会话状态回显生成CSV巡检记录 import re import csv import sys def parse_session_stats(output: str) - dict: result {} # 华为设备回显示例: # TCP established: 24567 # TCP syn_sent: 12 # UDP: 18932 # ICMP: 456 patterns { tcp_established: rTCP established:\s(\d), tcp_syn_sent: rTCP syn_sent:\s(\d), udp_total: rUDP:\s(\d), icmp_total: rICMP:\s(\d), } for key, pattern in patterns.items(): match re.search(pattern, output) if match: result[key] int(match.group(1)) # 总会话数一般是各协议之和部分版本直接输出汇总行 total_match re.search(rTotal session:\s(\d), output) result[total_session] int(total_match.group(1)) if total_match else sum(result.values()) return result def main(): raw_output sys.stdin.read() stats parse_session_stats(raw_output) # 写CSV方便直接追加到巡检报告附件的Excel中 with open(session_stats.csv, a, newline) as f: writer csv.writer(f) if f.tell() 0: writer.writerow([timestamp, total_session, tcp_established, tcp_syn_sent, udp_total, icmp_total]) writer.writerow([ __import__(datetime).datetime.now().isoformat(), stats.get(total_session, 0), stats.get(tcp_established, 0), stats.get(tcp_syn_sent, 0), stats.get(udp_total, 0), stats.get(icmp_total, 0), ]) print(f记录完成: total_session{stats[total_session]}) if __name__ __main__: main()这段脚本的价值在于把“看完回显凭感觉判断”升级为“数值入库可对比”。TCP syn_sent一旦持续增长脚本记录的CSV里会留下曲线不用等到设备告警才发现异常。有条件的团队可以用Grafana直接接数据库展示趋势把每台防火墙的日常采集数据变成可视化面板。3.5 巡检频率与阈值建议巡检频率方面不同设备形态适用的频率不同。核心边界防火墙和双机热备主设备建议每周巡检一次内网防火墙可以每两周一次主机防火墙在版本变更或服务器重启后专项巡检。如果公司有等保要求则必须按等保周期实施一般也是每月覆盖一次全量设备。阈值建议以硬件基线为参考。CPU使用率5秒均值超过70%标记为“关注”超过85%标记为“告警”内存使用率超过85%关注、90%告警会话数超过设备规格上限的70%关注、85%告警。IPSec隧道SA剩余寿命低于当前时间到下次巡检间隔的两倍时触发预警。策略命中率为0且策略存在时间超过90天的标记为“待清理”白名单策略必须每季度复核一次业务归属。4. 编制防火墙巡检报告书模版从字段到PDF的完整落地路径4.1 报告章节结构让看报告的人能一眼找到结论一份巡检报告书模版结构上要能让三类人各取所需执行巡检的人要看设备明细、审批的领导要看健康度结论、审计的人要看证据链。我常用的报告章节结构是“封面与结论前置”的布局设备清单、巡检时间、巡检人信息放封面页健康度总评放在第二页用一张表格列出每台设备的综合结论从第三页开始才是设备明细每台设备占两页——第一页是设备基础信息和硬件状态第二页是策略、会话、隧道、日志、备份等专项巡检记录最后一页放问题清单和整改建议。审计的人拿到报告不需要翻设备明细直接看健康度总评和问题清单就能定位风险。巡检结论不能写“正常”两个字就完事。模版里要给每个巡检项预设判定标准硬件类用正常/关注/异常三档策略类用通过/待优化/不通过三档每个非“正常/通过”的结论必须填写说明原因和整改建议。留白反而会消灭信息——模版设计得越严格巡检人员越不容易敷衍。4.2 巡检表字段设计设备信息、巡检项、阈值、结论四层结构巡检报告的核心是那张巡检记录表。表头不能只有“巡检项”和“结果”必须有“现场数据”和“参考阈值”这两列——否则三个月后回看报告只能看到一个“正常”根本想不起来当时设备实际跑了多少会话。字段设计可以这样拆设备信息层设备名称、品牌型号、软件版本、补丁版本、序列号、部署位置、角色边界/内网/主机、管理IP。这些字段每次巡检都要重新采集因为设备可能被更换过部件、升级过版本这些变化比“CPU高了几个点”更值得关注。巡检项层按硬件、资源、会话、策略、隧道、日志、备份、热备八个维度展开。每一行是一个具体巡检项例如“电源模块状态”“CPU均值”“会话总数”“策略命中Top10”等。巡检项的名称要具体到命令级别比如“display device的输出中Power状态是否为Present/OK”这样换一个人来执行也能保持一致性。阈值层每个巡检项配一个“参考阈值”这是用来做自动判定的依据。阈值不是拍脑袋写上去的应该取自设备规格书或历史基线——第一次巡检时记录设备正常负载下的数据作为基线之后每次巡检的阈值按基线值的80%设定比设备规格上限更早触发预警。结论层最后三列分别是“状态”正常/关注/异常“问题描述”“整改建议”。状态为“关注”或“异常”时后两列必须填写不允许有空白——这能倒逼巡检人员去了解为什么数据会异常而不是机械地抄数字。4.3 用 Markdown 生成 PDF 模版免费且可控的落地方式市面上有专业的网络运维软件可以直接生成巡检报告但价格和维护成本不低。个人或中小团队更实际的路径是用Markdown写报告正文搭配Pandoc转成PDF再套一个简洁的标题页。不需要购买商业文档组件也不需要学复杂的模板语法。--- title: 防火墙巡检报告 date: 2026-01-15 author: 网络运维组 toc: false --- # 设备健康度总评 | 设备名称 | 设备型号 | 巡检结论 | 问题数 | |---------|---------|---------|-------| | FW-边界-01 | USG6650 | 关注 | 2 | | FW-内网-02 | SecPath F1000 | 正常 | 0 | # FW-边界-01 巡检明细 ## 硬件状态 - 电源模块正常双电源均工作 - 风扇转速正常转速 5200 RPM设备温度 45°C - CPU5秒均值 62%1分钟均值 55%5分钟均值 50% ## 会话状态 - 当前会话总数68,320规格上限 100,000利用率 68.3% - TCP established62,180TCP syn_sent15UDP5,200 ## 问题与整改 1. CPU 5秒均值 62% 超过关注阈值 60%建议排查是否有新业务上线 2. 策略 105 条活跃 70 条活跃率 66.7%建议清理冗余策略Pandoc转换命令pandoc report.md -o report.pdf --pdf-enginexelatex \ -V CJKmainfontNoto Sans CJK SC \ -V geometry:margin2.5cm \ -V fontsize11pt这段命令的要点是--pdf-enginexelatex中文PDF必须用XeLaTeX引擎才能正确渲染中文字体CJKmainfont指定中文字体Linux系统上一般装Noto Sans CJK SC即可macOS可以用PingFang SCgeometry设置页边距为2.5厘米上下左右留白均匀打印装订不裁切内容。生成后的PDF就是一份可直接归档的任意命名文件比如“防火墙巡检报告_20260115.pdf”。文件内部自带目录可以由toc配置控制但在线巡检报告一般不用自动目录因为页数不多文章里Markdown的一二级标题已经能表达层级关系。这个方案的好处是内容可版本控制——把Markdown源文件存进Git仓库每次巡检记录的变更历史全部留痕审计时可以把PDF和Git提交记录对起来。4.4 巡检结论怎么写从“正常”到“健康度的量化”巡检报告书的结论部分最容易流于形式。我见过不少报告全文只写“设备运行正常”没有任何量化依据。一个可复用的做法是给每台设备算一个“健康度评分”基础分100分按巡检项的异常程度扣分出现“关注”级问题每项扣5分“异常”级问题每项扣15分扣完为止。90分以上为“健康”每项指标都在阈值内70到90分为“关注”存在需要处理的隐患但业务未受影响70分以下为“告警”必须在下次巡检前完成整改。评分制的好处是把“正常/关注/异常”的定性结论变成可比的历史数据——一台设备连续三个月都是80分虽然每次都能解释为“业务增长导致CPU升高”但三个月累计的趋势说明设备快扛不住了该做扩容规划了。评分之外每台设备的结论最好配一句“一句话描述”。比如“设备整体健康但会话利用率持续三个月上升建议关注扩容需求”——这句话写起来不费劲但能让看完报告的领导直接理解接下来该干什么。巡检报告不是写给设备看的是写给决策的人看的结论要让不懂命令行的人也能行动。5. 防火墙巡检避坑这些翻车现场我都替你踩过了5.1 Web界面显示“运行正常”内存已经用了95%现象某次巡检登录Web管理台首页设备状态展示区全部是绿色勾选包括内存占用率显示为95%。报告里差点就写“设备运行正常”但命令行执行display memory-usage时系统提示内存占用达到告警阈值且部分业务模块已经进入“过载保护”状态。原因Web管理台的在线状态刷新机制存在滞后页面可能停留在几分钟前甚至更早的缓存数据上。另一方面防火墙的内存使用率包含多个模块的共享内存和专用内存Web界面显示的是综合值而命令行能看到各模块的明细某个模块内存耗尽但总占比没有达到红色告警线时Web界面依然显示正常。解决巡检以命令行回显为准Web界面只作为辅助查看。display memory-usage看到总占比偏高时继续用display memory-usage slot加上模块维度命令下钻找到具体是哪个进程占用内存。给巡检表加一条规则Web界面状态必须与命令行回显一致才可判定为正常任何不一致都按异常处理。5.2 华为防火墙的会话表统计“按条”还是“按对”搞不清现象巡检时用display firewall session table statistics看到会话总数是三万但设备规格表标注的会话上限是五万结论就是“利用率60%”。后来做容量评估时发现实际并发业务量已经接近设备瓶颈原因是口径搞错了。原因华为防火墙的会话表项分为“单向表项”和“双向表项”两种部分版本统计命令输出的是表项数量而不是完整会话数量。一个完整的TCP连接需要两个方向各一条表项所以真实会话数是表项数的一半三万条表项对应约一万五千个会话。解决先确认设备软件版本的统计口径。用display firewall session table statistics输出的total不是唯一依据可以和display session table verbose逐条统计对比。巡检表里标明“会话数据采集口径双向会话/表项”并和设备的规格表按同一口径对比。不确定时就抓几个典型业务流量通过源目IP和端口确认一个连接占用的表项数。5.3 锐捷/H3C/华为命令不同同一份命令表不能全品牌通用现象一份巡检脚本在华为USG设备上运行正常换到H3C SecPath F1000上SSH登录和大部分命令都能执行但display firewall session table statistics这条命令直接报错。华为的防火墙命令体系继承自USG系列H3C的则是comware体系两者虽然长得像关键查询命令的差异很大。原因各厂商的命令行体系来源不同华为USG走VRP平台H3C走Comware平台锐捷又另起一套。display firewall session table是华为的专有命令H3C查看会话要分两条display session statistics看汇总display session table ipv4看明细。策略命中查看也是两套体系华为是display firewall policy hit-countH3C是display security-policy ip statistics。解决巡检命令表必须按品牌分列。我在报告模版里维护了一张“命令对照表”同一巡检项对应华为命令、H3C命令、锐捷命令三列执行时按设备品牌选择对应列。新接入设备品牌前先花半天时间在一台测试设备上跑通全部命令再纳入正式巡检范围。5.4 把“重启即恢复”写进巡检记录等于承认没有根因现象巡检记录里有一条“设备出现CPU过高告警重启后恢复正常”下一个巡检周期同样的问题又出现。连续三次都是同一个处理方法第四次终于扛不住业务中断半小时。原因CPU过高的根因没有被找到。重启只是清掉了当前的内存碎片和临时会话缓存但触发CPU升高的业务流量还在策略配置也没有调整。把“重启即恢复”当作结论等于给下一次故障埋了雷。解决巡检记录里的“处理措施”一栏禁止写“重启即可”。必须写清楚重启之前采集了哪些数据、数据指向什么结论、下一步要验证什么。例如CPU过高会话数快速上涨需要检查是哪个源IP在大量新建连接顺手抓一段报文分析策略命中异常上涨则要确认是哪条策略、哪个业务在调用。报告里写明根因分析下一次复现就有据可查。5.5 日志时间不同步攻击溯源时差八小时现象某次安全事件溯源需要核对防火墙攻击日志和服务器应用日志的先后顺序发现防火墙记录的拦截时间比服务器时间早了8个小时时间线完全对不上。原因防火墙的时区默认为GMT没有改成GMT08:00。虽然设备日志的时间戳本身是连续的当和业务服务器、NTP服务器的时间联动时8小时的偏移让所有攻击分析都失去了参照系。解决时间同步检查列为巡检第一项。登录设备后用display clock確認系统时间和时区如果时区不是中国标准时间立即修正并配置NTP服务器。巡检表里加一列“NTP状态”确认设备已达到同步状态并在日志中留下同步记录。这个坑最容易踩也最容易修但最容易被忽略。6. 把巡检报告书变成技术资产不靠人记靠脚本生成和留痕最后一层进阶是把巡检报告书从“手工填写”升级为“半自动产物”。前面写的采集脚本可以定时执行Markdown转PDF的流程可以打包成一键脚本每天早上八点自动对核心防火墙跑一遍巡检生成当日PDF并归档到指定目录。不追求全自动生成可发布的报告而是让“采集数据初步判定”自动化巡检人员只需要处理“关注”和“异常”项把精力放在分析和整改上。定时任务可以这样设计crontab里每天执行一次采集脚本输出原始回显和一个粗略的状态CSV每周五生成周报PDF汇总一周的趋势数据敏感设备如双机热备主设备则每天采集状态异常时通过短信或企业微信群机器人推送告警。生成的PDF文件名带上日期和设备名归档目录按年份组织配合Git仓库管理Markdown源文件等于给每台防火墙建立了一份可回溯的健康档案。回看这套方案最大价值不是“省了写报告的时间”而是让巡检从“应付检查”变成“发现问题”。一台防火墙的会话数连续五周上涨、策略命中率持续下降、双机热备一致性计数反复出现非零值这些趋势不会通过一次Web界面截图暴露但它们都会在量化指标的历史曲线里留下痕迹。我自己的习惯是每月翻一次趋势数据只看异常点和拐点不看正常值——异常点才是指向故障的第一线索。巡检报告书模版的技术含量不高但它是一个能把运维经验沉淀下来的载体。反应快、记性好不如一条准确的趋势曲线管用。希望这篇笔记能帮你把防火墙巡检从“打勾交差”变成“数据留痕”下次设备再出问题时翻一翻历史报告就能找到真正的答案。本文还有配套的精品资源点击获取