应急响应中常见的几种网络日志分析

早期的网络通信通常通过集线器（Hub）、交换机（Switch）和路由器（Router）等设备进行转发和传输。而随着安全威胁的不断演进，网络环境也变得更加复杂，具备安全防护能力的设备逐渐成为网络架构中的重要组成部分。例如，防火墙（Firewall）、入侵检测与防御系统（IDS/IPS）、代理服务器（Proxy）以及 Web 应用防火墙（WAF）等，都在实际环境中发挥着关键作用。

对于应急响应来说，理解这些设备产生的日志至关重要。网络设备所生成的日志，本质上记录的是网络通信的轨迹。每一条日志，都是一次访问、一条连接、一次请求或一次阻断的痕迹。它们共同构成了我们还原攻击路径、判断事件性质的重要依据。

通用日志分析（ NetFlow）

NetFlow 是一种用于采集 IP 流量信息的网络协议，最早由 Cisco 提出。虽然它出身于某一家厂商，但如今已经被广泛支持。不同厂商可能采用 SFlow 或其他类似协议，但核心目标是一致的：能够看清网络中发生了什么。

NetFlow 是如何工作的

NetFlow 是有状态的。也就是说，它会持续跟踪经过监控接口的 IP 通信行为。在 NetFlow 中，每一次 IP 通信都会被定义为一个“流”。一个流并不是单个数据包，而是一组共享关键属性的数据包集合。

timestamp : 2025-10-07T10:13:38.000274+1300
flow_id : 35919104
event_type : netflow
src_ip : 130.xxx.30.131
src_port : 53992
dest_ip : 115.xxx.89.117
dest_port : 1526
proto : UDP
netflow {5}
  pkts : 1
  bytes : 71
  start : 2025-10-07T10:13:07.795117+1300
  end : 2025-10-07T10:13:07.795117+1300
  age : 0

当这些字段组合一致时，设备会将其归为同一个 Flow，并在会话结束或达到时间阈值后导出记录。

需要注意的是，NetFlow 设备导出的数据通常是二进制格式。我们在实际分析中看到的可读日志，往往是经过采集器或分析工具解析后的结果。

NetFlow 的分析场景

举一个典型例子。如果在两分钟内，某个目标主机收到了来自大量不同源 IP 的上万次请求，那么从流量结构上看，这更像是一种拒绝服务攻击模式。但具体是 SYN Flood、UDP Flood 还是 ICMP Flood，则需要结合协议字段进行判断。

再比如，如果某条 NetFlow 记录显示目标端口是 123，我们可能会联想到 NTP 服务。但仅凭端口号，并不能百分之百确认该服务正在运行。端口只是一个线索，而不是结论。

NetFlow 数据可以帮助我们识别网络异常、定位感染主机、分析异常连接模式。但它并不直接告诉我们终端上运行了什么恶意程序，也无法直接解析域名请求细节。这类信息通常需要结合 DNS 日志、代理日志或终端检测日志共同分析。

防火墙日志分析

防火墙往往是我们还原事件经过时最先查看的日志来源之一。它既是网络边界的第一道防线，也是记录网络通信行为的重要审计设备。

防火墙可以是物理设备，也可以是虚拟设备。它的核心职责是根据组织制定的安全策略，控制进出网络的流量。小型环境中，可能每台服务器都启用了本地防火墙；而在大型企业里，通常会部署一台或多台集中式的边界防火墙，对所有对外通信进行统一管理。所有进出流量都必须经过它的检查和过滤。

防火墙的演进与应用层识别能力

早期的防火墙主要基于三层进行过滤，也就是根据 IP 地址和端口来决定是否放行流量。但随着攻击手段的复杂化，仅靠端口已经不足以判断真实业务行为。

现代防火墙通常具备更高级的检测模块，可以识别七层应用流量。这类设备被称为下一代防火墙（NGFW）。它不仅能够识别端口，还可以识别具体应用，例如 HTTP、HTTPS、SSH、DNS 等。

在日志中，如果看到有应用名称字段，或者明确标注了具体服务类型，那么基本可以判断该设备具备应用层识别能力。

防火墙日志中最关键的字段

在分析防火墙日志时，最核心的内容通常包括：

时间戳
源 IP 与目标 IP
源端口与目标端口
接口信息
地理位置
动作结果（允许或阻断）

其中，动作字段是我们判断通信结果的关键。

accept 表示流量成功通过
deny 表示流量被阻断，并且向源地址返回通知
drop 表示流量被丢弃，不会给源地址任何反馈
close 表示通信被正常关闭
client-rst 表示客户端主动终止连接
server-rst 表示服务端主动终止连接

示例日志解析思路

date=2025-05-21 time=14:06:38 devname="FG500" devid="FG5HSTF109K" eventtime=1653131198230012501 tz="+0300" logid="0000000013" type="traffic" subtype="forward" level="notice" vd="root" srcip=172.14.14.26 srcname="CNL" srcport=50495 srcintf="ACC-LAN" srcintfrole="lan" dstip=142.xxx.186.142 dstport=443 dstintf="Wan" dstintfrole="wan" srccountry="Reserved" dstcountry="United States" sessionid=445180938 proto=6 action="accept" policyid=284 policytype="policy" poluuid="8ec32778-a70a-51ec-9265-8fdf896d07f1" service="HTTPS" trandisp="snat" transip=89.xxx.185.195 transport=50495 duration=72 sentbyte=2518 rcvdbyte=49503 sentpkt=13 rcvdpkt=42

以示例日志为例，我们可以看到完整的流量记录。

date = 日期
time = 时间
devname = 设备主机名
devid = 设备 ID
eventtime = 事件精确时间戳（Epoch 格式）
tz = 时区
logid = 日志 ID
type = 日志类型（traffic、utm、event 等）
subtype = 子日志类型（forward、vpn、webfilter、virus、ips、system 等）
level = 日志级别
srcip = 源 IP 地址
srcname = 源主机名
srcport = 源端口
srcintf = 源接口名称
srcintfrole = 源接口角色
dstip = 目标 IP 地址
dstport = 目标端口
dstintf = 目标接口名称
dstintfrole = 目标接口角色
srccountry = 源 IP 所属国家信息
dstcountry = 目标 IP 所属国家信息
action = 处理动作（drop、deny、accept 等）
service = 服务类型
transip = NAT 转换后的出口 IP 地址
transport = NAT 转换后的端口
duration = 会话持续时间
sentbyte = 发送字节数
rcvdbyte = 接收字节数
sentpkt = 发送数据包数量
rcvdpkt = 接收数据包数量

从应急响应角度分析时，可以按照以下思路进行：

确认通信双方是谁。
确认使用了哪个端口或服务。
查看 action 字段判断是否成功。
结合字节数和数据包数量判断通信规模。
查看是否存在 NAT 转换，确定真实出口 IP。

例如，如果某个 IP 曾被 IPS 标记为攻击源，但在防火墙日志中又出现了后续的 accept 行为，就需要重点关注。这可能意味着策略放行存在漏洞，或者攻击者通过某种方式绕过了检测。

VPN 日志分析

VPN 日志往往是调查账号滥用和外部入侵的关键突破口。相比内部横向流量，VPN 本身就是对外开放的入口，一旦账号或凭证被窃取，攻击者就可以“合法”地进入内网环境。

VPN 的本质，是让用户在不处于本地网络的情况下，仍然可以访问内部资源。对普通用户来说，它可能意味着“切换网络位置访问受限网站”；但在企业环境中，它更多承担的是远程办公、远程运维等关键功能。

也正因为 VPN 服务通常暴露在公网，它天然就是攻击者重点关注的目标。

企业环境中的 VPN 部署方式

VPN 通常有两种常见部署模式：

一种是集成在防火墙设备中，作为防火墙的一个模块存在。
另一种是单独部署的专用 VPN 设备，例如OpenVPN。

因此，在日志来源上，VPN 日志可能来自防火墙，也可能来自独立 VPN 系统。

VPN 示例日志解析

date=2025-05-21 time=14:06:38 devname="FG500" devid="FG5HSTF109K" eventtime=1653134913959078891 tz="+0300" logid="0101039424" type="event" subtype="vpn" level="information" vd="root" logdesc="SSL VPN tunnel up" action="tunnel-up" tunneltype="ssl-web" tunnelid=462105151 remip=13.xxxx.5.4 user="letsdefend-user" reason="login successfully" msg="SSL tunnel established"

示例日志中，可以看到如下关键信息：

事件时间
设备名称和设备 ID
日志类型为 event
子类型为 vpn
日志级别为 information
动作 action 为 tunnel-up
隧道类型 tunneltype 为 ssl-web
远端 IP 为 remip
用户字段为 user
reason 字段为 login successfully

从这条日志可以明确判断：一个 SSL-VPN 隧道成功建立。

这里有几个重点字段必须关注：

发起连接的源 IP 地址（remip）
认证成功的用户名（user）
登录结果（reason）

例如，在示例中，IP 地址 13.xxx.5.4 使用用户名 oa-user 成功建立了 VPN 连接。

VPN 成功建立之后发生了什么

当 VPN 连接成功建立后，系统通常会分配一个内部 IP 地址给该用户，这个地址通常被称为 tunnelip。

后续该用户通过 VPN 发起的所有访问行为，都会以这个 tunnelip 作为源地址出现在防火墙流量日志中。因此，在调查中，VPN 日志只是第一步。下一步需要结合防火墙 traffic 日志，查看 tunnelip 后续访问了哪些内部资源。

在某些场景中，防火墙的流量日志会先于 VPN 日志产生，因为连接建立本身也是一次 HTTPS 流量行为。这也是为什么在 traffic 日志中，可能会看到 srcip 与 VPN 日志中的 remip 相同，而服务字段显示为 HTTPS——因为 SSL-VPN 本质上基于 HTTPS。

从登录行为到内网访问

很多攻击在早期阶段并不会触发终端告警，但异常的 VPN 登录行为往往是第一条线索。在成功确认某次 VPN 登录存在异常后，下一步应当追踪该 tunnelip 的访问记录。

调查方向通常包括：

是否访问了敏感服务器
是否进行了横向移动
是否下载或上传了异常数据
是否存在可疑外联行为

VPN 日志告诉我们“谁进来了”，而防火墙日志告诉我们“进来之后做了什么”。

IDS 与 IPS 日志分析

在企业安全体系中，单纯依赖防火墙的访问控制规则，往往无法应对复杂多变的攻击场景。防火墙更像一道门卫，根据既定规则判断流量是否可以通过；而 IDS/IPS 更像是安检设备，它不仅看“谁进来”，还会检查“包里装了什么”。

简单来说，IDS/IPS 的核心能力在于对数据包内容进行检测。它能够分析通信内容是否包含已知攻击特征，从而识别恶意请求，甚至在攻击到达目标系统之前进行阻断。

IDS 与 IPS 的区别

在应急响应中，我们经常会看到 IDS 和 IPS 这两个概念。它们的核心区别在于“是否阻断”。

IPS（Intrusion Prevention System）不仅能够检测攻击，还可以主动阻断可疑行为。
IDS（Intrusion Detection System）则只负责检测和告警，不主动拦截流量。

两者本质上依赖的是同一套机制——签名匹配。所谓签名，是针对已知攻击行为提炼出来的一组规则。当流量特征与签名匹配时，就会触发告警或阻断动作。

签名库会不断更新，以适应新的攻击方式。例如 Log4j 漏洞利用、端口扫描、漏洞利用尝试、僵尸网络通信等，都可以通过签名进行识别。

IPS 示例日志解析

date=2025-05-21 time=14:06:38 devname="FG500" devid="FG5HSTF109K" eventtime=1750585615163261716 tz="+0300" logid="0419016384" type="utm" subtype="ips" eventtype="signature" level="alert" vd="root" severity="high" srcip=12.xxx.2.4 srccountry="Reserved" dstip=19.xxx.201.16 dstcountry="United States" srcintf="AOS_LAN" srcintfrole="lan" dstintf="Wan_RL" dstintfrole="lan" sessionid=254830141 action="detected" proto=17 service="DNS" policyid=2 poluuid="6b5c8674-a36a-51ec-bbfd-2250544a9125" policytype="policy" attack="DNS.Server.Label.Buffer.Overflow" srcport=57673 dstport=53 direction="incoming" attackid=37088 profile="default" ref="http://www.fortinet.com/ids/VID37088" incidentserialno=254762092 msg="misc: DNS.Server.Label.Buffer.Overflow" crscore=30 craction=8192 crlevel="high"

以示例 IPS 日志为例，我们可以看到以下关键信息：

日志类型为 utm，子类型为 ips
事件类型为 signature
严重级别为 high
源 IP 与目标 IP
服务类型为 DNS
攻击名称为 DNS.Server.Label.Buffer.Overflow
action 为 detected

这条日志表示：源 IP 向目标 IP 的 53 端口发起请求时，触发了 DNS 相关漏洞利用的签名规则。

例如，如果攻击详情中提到的是某个特定 DNS 服务漏洞，而目标主机根本没有运行该服务，那么事件很可能是误报或无效攻击尝试。但如果目标确实运行相关服务，且 action 字段显示为 detected 而非 blocked，那么意味着攻击流量已到达目标系统，这时事件级别应当提升，甚至升级为应急响应事件。

WAF 日志分析

在真实的应急响应过程中，仅依赖防火墙或 IDS/IPS 日志，往往不足以完整识别 Web 攻击。原因很简单：大多数 Web 流量都是加密的 HTTPS，如果无法解密流量内容，就无法看到真正的攻击载荷。而这正是 WAF 发挥作用的地方。

WAF（Web Application Firewall，Web 应用防火墙）专门用于保护 Web 应用系统。它通常部署在公网入口与 Web 服务器之间，所有外部访问请求都会先经过 WAF，再决定是否转发到后端服务器。

为什么需要 WAF

传统防火墙关注的是 IP 和端口，IDS/IPS 关注的是签名匹配。但在 Web 攻击场景中，攻击往往隐藏在 HTTP 请求参数中，比如：

SQL 注入
XSS 跨站脚本
目录遍历
代码注入
异常 HTTP 方法滥用

这些攻击都发生在应用层。WAF 的核心优势在于能够进行 SSL Offload，也就是对 HTTPS 流量进行解密，从而检查请求中的参数和载荷内容。如果没有 SSL 解密能力，HTTPS 中的恶意请求内容将无法被检测。WAF 是 Web 攻击的第一道检测防线。

WAF 示例日志解析

date=2025-01-26 time=19:47:26 log_id=20000008 msg_id=000018341360 device_id=FVVM08 vd="root" timezone="(GMT+3:00)Istanbul" timezone_dayst="GMTg-3" type=attack main_type="Signature Detection" sub_type="SQL Injection" severity_level=High proto=tcp service=https/tls1.2 action=Alert policy="Alert_Policy" src=19.xxx.150.138 src_port=56334 dst=172.16.10.10 dst_port=443 http_method=get http_url="?v=(SELECT (CHR(113)||CHR(120)||CHR(120)||CHR(118)||CHR(113))||(SELECT (CASE WHEN (1876=1876) THEN 1 ELSE 0 END))::text" http_host="zgao.top" http_agent="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110703 Firefox/3.0b1" msg="Parameter(Password) triggered signature ID 030000136" signature_subclass="SQL Injection" signature_id="030000136" srccountry="Germany" attack_type="SQL Injection"

在示例 WAF 日志中，可以看到如下关键信息：

main_type 为 Signature Detection
sub_type 为 SQL Injection
severity_level 为 High
action 为 Alert
policy 为 Alert_Policy
http_method 为 GET
http_url 包含可疑 SQL 语句
attack_type 为 SQL Injection

从日志内容来看，这是一次典型的 SQL 注入攻击尝试。URL 参数中包含了 SQL 表达式，这正是常见的注入特征。在这条日志中，action 设置为 Alert，而不是 Block。这意味着 WAF 识别到了攻击特征，但只是告警，没有阻断，请求已经被转发到了后端服务器。

DNS 日志分析

DNS 日志往往是最容易被忽视、却又最有价值的线索来源之一。很多攻击行为的第一步，都是域名解析。从 C2 通信到数据外传，从恶意软件下载到钓鱼页面访问，几乎都离不开 DNS 请求。DNS 日志能帮助我们回答一个关键问题：某台主机在什么时候解析过哪些域名。

DNS 本质上是域名与 IP 地址之间的解析系统。我们在浏览器中输入域名时，底层实际上是通过 DNS 查询获取目标服务器的 IP 地址，然后再建立连接。所有基于域名的访问行为，都会留下 DNS 请求记录。

DNS 日志的两类来源

从日志来源的角度，DNS 日志大致可以分为两类。

第一类是 DNS 服务器审计日志。这类日志记录的是对 DNS 服务本身的管理操作，例如新增记录、删除记录或修改区域配置。在 Windows 系统中，可以在 DNS Server 的审计日志中查看这些操作。

第二类是 DNS 查询日志，也就是客户端发起的域名解析请求。这类日志记录的是“谁在查询什么域名”。

需要注意的是，DNS 查询日志默认通常不会开启，需要手动启用。在 Linux 环境中，Bind DNS 的查询日志通常位于 /var/log/querylog 文件中。

DNS 查询示例日志解析

{ "timestampt": 1591367999.306059, "source_ip": "192.168.4.76", "source_port": 36844, "destination_ip": "192.168.4.1", "destination_port": 53, "protocol": "udp", "query": "zgao.top", "qtype_name": "A", }

例如以下日志结构：

时间戳
源 IP 地址
源端口
目标 DNS 服务器 IP
查询类型
查询域名

如果我们看到某台主机在短时间内频繁请求随机生成的子域名，例如长度异常、无明显含义的域名，那么需要高度警惕。这类行为很可能与 DNS 隧道或 DGA 域名生成算法有关。

DNS 隧道行为识别

在示例中，如果一台主机在 1 分钟内向同一个域名下的多个随机子域发起请求，这可能是 DNS 隧道行为。DNS 隧道通常被用于数据外传或隐藏通信，因为 DNS 流量通常不会被严格限制。

一旦发现类似行为，应当：

定位产生该请求的主机
调查该主机上的进程
检查是否存在异常程序或恶意软件

DNS 日志通常只是线索的开始。可以将IOC 与 DNS 日志的结合，IOC（入侵指标）包括攻击发生前、中、后的关键证据，例如恶意域名、IP 地址或文件哈希。DNS 日志是验证 IOC 是否被访问的重要来源。

Post Views: 19

赞赏

微信赞赏支付宝赞赏

应急响应中常见的几种网络日志分析