这活儿我前后在好几台USG6600上折腾过也帮客户排查过不少“日志不对”“日志缺东西”的案子。很多人一听“全流量日志”第一反应是抓包、存PCAP其实在企业出口防火墙这个场景里审计和溯源要的日志根本不是一个概念——你不需要把每个报文都留下来你要的是每一笔会话、每一次NAT转换都有据可查什么时候谁从哪个内网IP访问了哪个公网IP、转换成了哪个公网地址、走了哪个接口、传了多少字节这些东西能完整落到日志服务器就够应对绝大多数安全事件回溯和合规审计了。USG6600虽然是老将但作为企业核心出口它的会话日志和NAT日志能力完全够用。这篇文章我把从日志接收端规划、设备侧配置、策略日志开启、NAT日志单独处理到服务器端落盘解析的完整链路写一遍顺带把我踩过的坑也交代了。内容适合正在接手USG6600、或者被审计要求追着要日志的运维和安全同学直接对着敲就行。1. 先想清楚全流量日志到底要记什么1.1 流量日志、策略日志与会话日志别混为一谈华为USG6600的日志体系容易让人迷糊因为它散落在好几个地方。最容易被误解的是“安全策略日志”和“全流量会话日志”。你在安全策略里开log enable记的是“命中该策略的流量记录”本质是策略命中日志。而真正意义上的“全流量日志”指的是设备转发过的每一笔会话从建连到老化都有对应的会话日志输出。这个区别很关键。举个例子如果内网用户访问外网时命中了一条放行的安全策略策略日志会记录源目IP、端口、协议、动作但如果NAT发生在策略之后策略日志里大概率只看到转换前的IP看不到公网地址和端口。而会话日志则更接近“连接追踪”的视角它记录的是整个会话生命周期配合NAT日志才能还原出“内网谁用哪个私网IP的哪个端口通过哪条NAT规则转换成了哪个公网IP的哪个端口访问了哪个目的地址”。USG6600上还有一个信息中心Info-center的概念系统log、接口log、安全日志都通过它往外发。很多人只知道info-center loghost可以指定日志服务器就把所有日志一股脑丢过去结果发现要的没有、不要的一堆。1.2 会话日志和NAT日志为什么必须分开看我见过不少现场安全策略日志开了一堆NAT日志没开结果被问“外网攻击源到底转换成了哪个内部IP”的时候日志里只有一个公网IP根本定位不到人。在USG6600上NAT日志和会话日志是两条线。NAT日志记录的是地址转换关系包含转换前源IP/端口、转换后源IP/端口、目的IP/端口、协议、接口等关键信息。会话日志记录的是流本身的建立和老化。两者结合才能形成完整的访问链条。如果只开策略日志看到的顶多是“防火墙放行了某个五元组流量”如果只开NAT日志你只知道映射关系不知道这条流最终是否被策略允许。所以想做全流量审计策略日志、会话日志、NAT日志三者都得出。2. 动手前的准备工作日志服务器和时间同步2.1 日志服务器规划Linux装个rsyslog就够踏实日志服务器是整个方案的落点我强烈建议别用Windows机器直接收syslog除非你有商业日志平台。最简单的方案是拿一台Linux虚机装rsyslogUSG6600的syslog报文本质上就是文本rsyslog完全扛得住中小企业的日志量级。我的标准做法是这样的日志服务器Ubuntu/CentOS均可装好rsyslog配置两个接收端口一个UDP 514、一个TCP 514。落盘目录按设备IP和日志类型分开例如/var/log/usg6600/all.log和/var/log/usg6600/nat.log。权限和轮转logrotate按天切割保留90天这个后面细说。有人问要不要用专门的商业日志系统比如Splunk、ELK。如果预算充足当然可以但底层思路是一样的设备做syslog外发平台做接收解析。本文先把“能收到日志、能查日志”这个基础打牢。2.2 时间同步是最大坑时区、NTP、日志时间戳如果你之前配过思科或H3C的syslog大概率被时间问题坑过。USG6600默认日志时间戳可能是UTC也可能是设备本地时间取决于info-center timestamp log的配置。很多现场发现日志服务器上收到的记录比北京时间慢8小时原因就是设备没配时区或者配了时区但没开NTP。我建议设备侧必须做两件事第一配置时区为北京时间对应的UTC8命令是这样clock timezone BJ add 08:00:00第二配置NTP同步让设备和内网时间源或公网NTP服务器对齐ntp-service enable ntp-service unicast-server 192.168.1.254这一步一定要做尤其是USG6600这种可能有多块单板、多核转发引擎的设备如果单板间时间不同步日志服务器上收到的记录会乱序排查问题的时候非常痛苦。2.3 syslog通道选择UDP还是TCPUSG6600外发syslog支持UDP和TCP两种方式。UDP简单高效但存在丢包风险TCP可靠但增加连接开销。日志量不大、审计要求又不高的话UDP 514足够如果日志量每天有几GB级别或者客户明确要求日志不能丢那就用TCP 514。我在生产环境里默认配置成UDP接收因为rsyslog默认的UDP处理能力已经可以支撑每秒几千条日志对绝大多数企业出口来说够了。只有当对方明确说“日志必须不丢”的时候才会上TCP或RELP。3. USG6600日志配置实操一条一条敲给你看3.1 信息中心和日志主机配置USG6600的syslog外发配置入口是信息中心命令基本是VRP通用的。假设日志服务器IP是10.10.10.2管理接口是GigabitEthernet0/0/0配置如下info-center enable info-center timestamp log local-time info-center loghost 10.10.10.2 source interface GigabitEthernet0/0/0这里有个细节source interface建议指定为管理口或专门用于日志传输的接口不要从业务口走。这样即使业务侧流量异常、接口拥堵日志还是能发出去。如果设备上没有专门的管理口那就选一个平时流量可控的接口。配置完可以先用display info-center确认配置生效再用terminal monitor和terminal debugging配合在服务器端看日志是否到达。我实际验证的时候更喜欢直接到服务器上tail -f日志文件效果直观得多。3.2 安全策略日志开启每条放行策略加一句话要让USG6600记录“谁访问了谁”需要在安全策略规则上开启日志。命令模板如下security-policy rule name trust-to-untrust source-address 192.168.0.0 16 destination-address any action permit log enable注意这个log enable不是默认开启的。很多设备上线的默认策略都是放行策略但没有加日志结果审计要日志的时候才发现啥也没有。我的习惯是所有明确用于业务放行的策略都统一加上log enable对于默认拒绝的流量可以考虑在rule name deny-all的策略上不开日志避免全网扫描、误探测直接把日志服务器灌爆。如果安全策略数量很多一家几十条还好几百条的时候人工加容易漏。可以用批处理导出配置在文本里批量加log enable再导回设备但前提是导出导入格式必须规范不然容易搞出配置事故。3.3 NAT日志开启全局开关和策略联动NAT日志在USG6600上是独立的配置项老版本VRP上通常是一个全局开关。我实际环境的命令是nat log enable版本不同命令可能有差异。如果敲完报错就敲nat log ?或者display this看当前配置里NAT部分的写法。开启后NAT会话的建立和老化日志会通过信息中心外发到日志服务器日志里会包含转换前后的IP和端口。需要注意的是NAT日志默认可能只记录NAT会话建立不一定记录老化。如果需要完整的NAT会话生命周期需要确认版本是否支持“NAT会话日志结束”字段或者结合会话日志来做结束记录。审计要求严格的话最好在设备上先跑一小段流量抓一条NAT日志看字段全不全再决定要不要加打开更多日志选项。3.4 全局会话日志按需开启别盲目全开USG6600在不同版本里提供过会话日志增强能力有的是通过session log或firewall log session enable这类全局开关开启有的则必须依赖每条策略单独记录。我不建议在一台承载核心业务的防火墙上盲目开全局会话日志因为一旦开启所有经过设备的新建会话和老化会话都会产生日志日志量可能是策略日志的几倍甚至十几倍处理不当会耗费设备CPU也可能导致日志风暴。我通常的建议是优先依赖安全策略上的log enable把策略命中日志拿到再按需开启NAT日志。如果确实需要完整的会话全量记录再考虑全局会话日志。开启前先和厂商确认当前版本支持哪条命令并在非高峰期做小流量验证。3.5 验证配置本地缓冲区和服务器端双向确认配置完不能直接下班验证这一步跑不掉。USG6600本机有logbuffer可以先在设备上看有没有生成对应日志display logbuffer比如你在内网随便找一台机器ping一个公网地址或者访问一个网站然后刷新logbuffer看有没有对应的策略日志和NAT日志。这一步能快速确认设备侧是否产生了日志。接着到日志服务器上看有没有收到tail -f /var/log/usg6600/all.log如果设备buffer里有、服务器上没有优先查route和防火墙USG6600到日志服务器的网络通不通日志服务器自身的iptables有没有挡514端口。别问我为什么知道要先查防火墙说多了都是泪。4. 日志落盘和解析装好接收端才算闭环4.1 rsyslog接收端配置按来源分文件Linux这边我用rsyslog配置非常简单。以CentOS/RHEL为例在/etc/rsyslog.conf或/etc/rsyslog.d/下新建文件内容如下$template USGAllLog,/var/log/usg6600/all.log $template USGNatLog,/var/log/usg6600/nat.log :fromhost-ip, isequal, 10.10.10.1 -?USGAllLog :fromhost-ip, isequal, 10.10.10.1 ~如果希望按天分文件可以用$template加时间戳$template USGDayly,/var/log/usg6600/all-%$YEAR%%$MONTH%%$DAY%.log :fromhost-ip, isequal, 10.10.10.1 -?USGDayly注意rsyslog配置里先创建/var/log/usg6600目录并且要确保rsyslog进程对该目录有写权限。改完配置后执行systemctl restart rsyslog。这一步容易踩的坑是日志文件权限。rsyslog默认可能以syslog用户运行目录如果给了root权限而文件是syslog用户创建的后续logrotate轮转时可能报错。建议直接把目录属主改成syslog:syslog或者用chmod 755控制好。4.2 NAT日志字段解析Python脚本提取关键信息日志到了服务器上只是第一步人类可读才是价值。USG6600的NAT日志字段在不同VRP版本里略有差异但关键信息基本固定时间戳、日志类型/ID、源IP/端口、转换后IP/端口、目的IP/端口、协议、接口名等。我写过一个简单的Python脚本从NAT日志里提取“内网IP - 公网IP - 目的IP”的映射关系用于日常快速查询某个外网IP在指定时间内被哪个内网IP访问过。大致思路是import re from collections import defaultdict log_file /var/log/usg6600/all.log # 示例根据实际日志格式调整这里只做演示 pat re.compile(r(?Pts\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}).* rsrc(?Psrc\d\.\d\.\d\.\d):(?Psport\d).* rdst(?Pdst\d\.\d\.\d\.\d):(?Pdport\d).* rnat(?Pnat\d\.\d\.\d\.\d):(?Pnatport\d)) access_map defaultdict(list) with open(log_file, r, encodingutf-8, errorsignore) as f: for line in f: m pat.search(line) if m: access_map[m.group(nat)].append( (m.group(ts), m.group(src), m.group(sport), m.group(dst), m.group(dport)) ) for public_ip, records in access_map.items(): print(f公网IP {public_ip} 的访问记录) for r in records: print( , r)这套脚本的关键在于正则要和实际日志格式匹配。不同版本的USG6600日志字段顺序可能不一样建议先抓几条真实日志把字段顺序看清楚了再写正则别照抄网上的模板硬套。4.3 磁盘容量估算与logrotate轮转日志每天增长多少必须提前算清楚。我给一个粗略估算公式假设平均每条日志400字节设备平均每秒产生200条日志那么一天日志量约200条/秒 × 86400秒 × 400字节 ≈ 6.9GB/天也就是说如果按90天留存大约需要620GB空间。如果日志量翻倍到400条/秒就要1.2TB以上。所以日志服务器磁盘至少按“每天10GB × 留存天数 × 1.5”来规划别等到磁盘满了才发现。logrotate配置很简单每天切割、压缩、保留90天/var/log/usg6600/*.log { daily rotate 90 compress delaycompress missingok notifempty postrotate /usr/bin/systemctl restart rsyslog 2/dev/null || true endscript }5. 常见问题与排错实录5.1 日志时间差8小时或时间明显不对八成是时区配置问题。先display clock看设备当前时间再确认info-center timestamp log是local-time还是utc。我自己的标准配置是设备时区BJ add 08:00:00日志时间戳local-timeNTP对准内网时间源。三步做完时间不会再漂。5.2 只看到内网IP看不到NAT后的公网地址这个问题几乎每周都有人问。NAT转换后的IP和端口必须靠NAT日志来看。如果只开启安全策略log enable日志里看到的是策略匹配时的原始五元组也就是内网私网IP。要看到公网IP必须确认设备已经开启nat log enable并且日志服务器上实际收到了NAT会话类型的日志而不是只收到策略日志。5.3 日志风暴把CPU打满设备都变卡了我在一个客户现场遇到过默认拒绝策略开了日志结果内网某个网段被扫描每秒产生几千条deny日志设备CPU直接100%。排查下来是日志量太大syslog外发本身消耗CPU同时日志服务器UDP处理不过来也在丢包。解决办法检查安全策略里log enable的分布尤其是拒绝策略如果不想放弃拒绝日志可以在设备侧做日志过滤或者限制loghost发送速率。USG6600上可以配置日志信息的过滤规则把不关心的模块或级别过滤掉比如只保留security和nat相关的告警和错误。日志风暴发生后优先确认是哪个模块的日志在刷屏再针对性治理。5.4 日志服务器收不到日志设备buffer里也没有这种情况先别怀疑设备先查网络链路。USG6600到日志服务器之间如果有防火墙要检查有没有放行UDP/TCP 514端口如果日志服务器本机有iptables/firewalld也要放行。真实环境中很多故障都是因为中间链路某台设备的ACL把日志报文默默丢了。另外指定了source interface以后还要确认这个接口能路由到日志服务器别出现“日志报文从管理口发出去了但回包路径不对”这种诡异现象。如果走了业务口还要确认安全策略放行了到日志服务器的syslog流量。5.5 双机热备场景下的日志疑问USG6600做双机热备时活跃设备转发流量时会发日志备用设备一般不产生业务日志。主备切换的瞬间可能短暂出现日志中断这是正常现象。关键是两台设备的loghost配置、NTP配置、时区配置必须保持一致否则切换后日志时间乱跳、来源IP变化后期排查会非常困惑。有人问备机的日志要不要收如果备机不参与转发理论上不需要收。但如果开启了会话备份某些状态同步的日志可能会从备机发出。注意看日志来源IP至少能帮助你判断当前谁是活跃设备。5.6 日志顺序乱时间戳前后颠倒USG6600是多核设备不同业务板的日志并发产生syslog外发时不一定按时间顺序到达。日志服务器不能依赖“到达顺序”必须以设备产生的时间戳为准。所以我在做审计查询时通常会先按时间戳字段排序再配合日志ID去重。如果需要更精确的排序建议部署NTP保证各单板时间一致日志里再带上设备序列号或日志序列号能在强审计场景下做到更完整的回溯。6. 日志配置的经验心得最后分享几个我在实际项目里的做法不一定写在厂商手册里但对运维很有用。一是日志源和业务型号要规划好。USG6600的loghost虽然可以配置多个但我通常一个设备只发一台日志服务器避免多目标情况下日志管理混乱。如果一定要双发务必保证两边配置一致否则排查的时候自己给自己添乱。二是NAT日志、策略日志、会话日志要分文件存储。在设备侧通过日志服务器配置或rsyslog的过滤规则把不同类型日志拆开。查询的时候“按文件查”比“在一坨日志里grep”快得多。我甚至建议把安全告警日志单独拆一份方便日常巡检。三是存储容量永远比想象中消耗得快。日志如果没有轮转半年就能把几TB磁盘吃光。建议日志服务器配置告警磁盘使用率超过80%就通知别等到日志写不进去才发现。四是设备侧配置完日志后一定要做“业务回归”。开日志会影响设备CPU和转发性能尤其是NAT日志高新建连接速率下对性能有影响。我的习惯是在业务低峰期配置然后用工具打一小段时间的测试流量观察设备CPU、内存、日志服务器接收速率确认都在合理范围再放量。USG6600这台机器很多人觉得它老但作为企业出口防火墙它的日志能力还是扎实的。只要把策略日志、NAT日志、会话日志三块理清楚再配上一台能落盘、能解析的syslog服务器日常溯源和合规审计完全够用。我团队现在接手的几个项目哪怕客户后续换了更高端的防火墙日志架构也没动过全是当年基于USG6600跑通的那一套思路。