SecCenter审计NTA日志故障排查

关键词:
问题现象

本文主要对SecCenter审计NAT日志相关问题进行排查说明。包含:抓包文件分析、日志审计流程、页面配置等方面分享处理经验。以方便读者处理相关问题。

SecCenter能够接收防火墙NAT日志,并通过源IP、目的IPNAT后源IPNAT后目的IP、源端口、目的端口、NAT后源端口、NAT后目的端口、时间段等信息来查询,并列出符合条件的所有NAT访问的详细信息列表。

告警信息

原因分析

对于NATSyslog日志数据处理流程如下。

安全设备->SecCenter接收器->直接写入数据库。

因此对于SecCenter审计处理NTA流量问题,排查思路如下:在设备侧是否已对应日志转发做相应配置;SecCenter侧是否收到日志文件,NTA日志报文是否正确写入数据库

解决办法

1SecCenter安装部署规范检查

SecCenter安装部署规范参考相应版本说明书。SecCenter不同版本对服务器的硬件规格,配套安全设备也有不同的型号及版本要求,安装部署前请严格按照文档要求检查安装环境是否符合规范,所要管理的安全设备是否符合配套关系。CPU、内存、磁盘、网卡核心硬件资源必须满足最小的资源规划要求。

服务器部署要求:SecCenter目前只支持安装在Windows系统,并且对版本有严格的要求。SecCenter不允许与其他具有类似功能的软件安装在同一台服务器上。

客户端要求:SecCenter目前只支持IE8浏览器;使用其他浏览器访问会报Http 404错误,具体参考公司KMS案例,案例号码:201602010001

2SecCenter处理NAT日志流程说明及配置检查

SecCenter日志入库流程主要分为两类。

对于NetStream(流日志)日志从安全设备到SecCenter数据库及页面显示中间经过的流程如下。

安全设备->SecCenter接收器->SecCenter\data\各模板文件夹->前台读取文件并写入数据库

对于NATSyslog日志数据处理流程如下。

安全设备->SecCenter接收器->直接写入数据库

在设备侧需要对应日志转发做相应配置,SecCenter侧才有可能受到日志文件,确认日志报文是否正确发送到SecCenter,可以通过Wireshark抓包分析网卡接收报文情况。

NAT日志审计功能使用防火墙二进制日志,默认端口为30017,可以自定义端口(本文以默认端口30017为准)。需要在安全设备上做对应UserLog配置。SecCenter也需要做对应配置,具体在“系统管理”页签下的“系统配置”,再点击“管理端口配置”,对其进行配置,具体如下图所示:

注:请确保SecCenter与其所管理的安全设备,双方配置的日志服务器的端口一致,并且不被占用。

设备配置正确配置UserLog(注意不是配置CustomLog日志),SecCenter侧正确配置日志接收端口,随后在SecCenter服务器侧抓包,能抓到端口为30017UDP报文,具体如下图所示:

说明上述配置正确,且安全设备到SecCenter之间的网络通畅且不过滤NAT日志报文。

否则需要检查上述端口配置和安全设备与SecCenter服务器之间是否有安全策略过滤NAT日志报文。

对于端口被占用情况,请阅读下述第五项。

3查看系统运行状态

SecCenter服务器端在运行过程中根据功能的不同主要分为数据库服务、web服务和接收器服务三个子服务。任何一个子服务运行不正常都会导致出现相应的错误。所以在处理各种问题之前请务必保证这三个服务运行正常,在服务器桌面右下角点击SecCenter运行图标即可看到,如下图所示:

SecCenter Web服务”以及“SecCenter接收器服务”状态为下图红框标出则为正常状态。具体如下图所示:

4检查添加设备的时间和时区

SecCenter管理安全设备的第一步就是正确配置安全设备的HTTPSNMP等访问参数,将设备加入SecCenter系统中管理,正确识别设备型号和版本信息。

在添加安全设备时,SecCenter提供了“以本地时钟处理以格林威治时间处理两种时区校正方式。

如果选择错误则会出现由于存在时间差导致无法审计到安全设备的流量信息或数据一直不准确等问题。故在保证安全设备和SecCenter服务器的时间一致的前提下,安全设备的时区、SecCenter服务器时区及时间矫正方式的对应关系应如下表所示:

安全设备时区

SecCenter服务器时区

时钟处理方式

北京时间(GMT+8

北京时间(GMT+8

以本地时钟处理

格林威治时间(GMT

北京时间(GMT+8

以格林威治时钟处理

 

如果出现下述情况:日志正确写入数据库,但是SecCenter页面上无日志审计数据显示,登陆数据库(SecCenter内嵌使用MySQL数据库存放数据,默认连接端口为3308,默认用户名root,默认登陆密码为123456。推荐使用Navicat for MySQL数据库客户端工具连接数据库)。发现数据库中日志的时间与SecCenter服务器时间的当前时间相差8小时。

 

此时说明上述时区设置错误。需要做时区校正操作,即可解决问题。具体如下图所示:

5查看端口占用情况

SecCenter默认情况下以UDP 30017接收NAT日志,如果此端口与服务器上其他进程所用端口存在冲突,则导致SecCenter接收日志失败。

此时需要在SecCenter服务器上检查使用30017端口的进程具体信息。在Windows“开始”菜单中执行“命令提示符”中运行命令:netstat –aon | findstr 30017能查看到使用30017端口的进程PID信息,此处PID11448PID不固定,不同客户的环境值不同,同一客户的环境进程重启后PID值会变化)。

获取到进程的PID信息后,再运行命令:tasklist  | findstr 11448可以通过进程PID查看具体的进程名字为“natreciver.exe”。具体如下图所示:

上图所述情况为正常情况,SecCenterNAT日志的接收器进程名称为“natreciver.exe”。

如果30017被其他进程占用,此时natreciver.exe进程接收安全设备的NAT日志会出现异常。

此时处理方法请参考公司KMS案例,案例号码为201504150001,能及时解决问题。

6查看数据库数据

SecCenter审计NAT日志,后台MySQL数据库中存放数据表文件名为“tb_audit_nat_detail_日期表”,文件存放的路径为D:\Program Files (x86)\SecCenter\database\data\rpt(此处以SecCenter安装在D盘为例)。

每个表有三种格式文件,分别为.MYI.MYD以及.frm结尾的文件。其中.MYI文件用来存储数据库索引信息,.MYD文件用来存储数据文件,.frm文件则用来定义表结构。

当在SecCenter上通过抓包能获取到NAT日志报文,但是页面无NAT日志审计数据,此时需要关注数据库中.MYD数据表是否有数据。无数据则分析为NAT日志接收器进程相关问题,有数据则需要关注数据库数据。

请阅读下述第八项,收集日志信息,以定位具体问题。

7页面查看有NAT日志审计记录但是地址未转换问题

问题现象:在SecCenter的防火墙管理的事件管理来查看NAT日志审计结果,发现源IP及目的IP都没有经过地址转换,具体如下图所示。

登陆设备查看发现设备上地址有转换操作,具体如下图所示。

查看设备的Web网管页面,发现地址转换也是正常的,具体如下图所示。

分析前先介绍我司设备的Flow日志信息:Flow日志信息指BAS用户访问外部网络的流信息。用户通过BAS接入成功后访问外部网络,此时,将这部分IP报文按照源IP地址、目的IP地址、源端口、目的端口、协议号等5元组进行分类,每一类报文构成一条Flow流,生成一个Hash表项记录到FlowHash表中,并通过定时老化和强制老化等方式,将记录下来的Flow日志信息输出。

Flow日志的格式分为1.0版本和3.0版本。3.0版本比1.0版本增加了NAT转换及流量信息,相应的占用空间也会增加。

防火墙日志分为Syslog日志和二进制日志。Syslog格式由RFC3164定义。二进制日志由UDP报文承载,端口号由主机配置。日志内容位于为UDP报文的数据部分,由日志头和日志体组成,日志体中可以包括一条或多条日志记录。

对日志报文头的格式说明如下:

Type

Contents

Description

UCHAR 1

Version

日志报文版本号,防火墙V2R1版本为0x02V2R50x03

UCHAR 1

LogType;

日志报文的类型, NAT=1 BAS(ACCESS)=2 FLOW=4

USHORT 2

Count

当前报文中的流记录数(1-100)

ULONG 4

Second

1970110时起,到报文产生时间的整秒数

ULONG 4

FlowSequence

序列号,等于发送的记录数

USHORT 2

DeviceId

设备类型号(暂未定义)

UCHAR 1

Slot

发送日志报文的槽号(防火墙都为0

UCHAR 1

Reserved

保留

Flow1.0 版本录输出UDP报文的记录格式说明如下:

Type

Contents

Description

ULONG 4

SIP

IP地址

ULONG 4

DIP

目的IP地址

USHORT 2

SPORT

TCP/UDP源端口号

USHORT 2

DPORT

TCP/UDP目的端口号

ULONG 4

STIME

流起始时间,以秒为单位,以1970/1/1 0:0开始计算

ULONG 4

ETIME

流结束时间,以秒为单位,以1970/1/1 0:0开始计算

UCHAR 1

PROT

IP承载的协议类型

UCHAR 1

OPERATOR

操作字,主要指流结束原因,与NAT操作字的定义相同。

USHORT 2

RESERVED

保留

下述表格为Flow 3.0版本记录输出UDP报文的记录格式:

Type

Contents

Description

UCHAR 1

Prot

IP承载的协议类型

UCHAR 1

Operator

操作字,主要指流结束原因。

0x0:保留不用

0x1:正常流结束

0x2:定时器超时老化

0x3CLEAR/配置变动引起的流老化

0x4:资源不足带来的流老化,这样获得资源满足新流

0x5:一对一的NAT映射,此时记录中只有源IP地址和转换后IP以及时间字段有效

0x6:标志长时间存在流的中间发送记录

0x7:替换引起的流删除

0x8:流创建时的记录

0xFE:其他

0x09~0xFD:保留

UCHAR 1

IpVersion

IP报文版本

UCHAR 1

TosIPv4

IPv4报文的Tos字段

ULONG 4

SourceIP

IP

ULONG 4

SrcNatIP

NAT转换后的源IP

ULONG 4

DestIP

目的IP

ULONG 4

DestNatIP

NAT转换后的目的IP

USHORT 2

SrcPort

TCP/UDP源端口号

USHORT 2

SrcNatPort

NAT转换后的TCP/UDP源端口号

USHORT 2

DestPort

TCP/UDP目的端口号

USHORT 2

DestNatPort

NAT转换后的目的TCP/UDP目的端口号

ULONG 4

StartTime

流起始时间,以秒为单位,以1970/1/1 0:0开始计算

ULONG 4

EndTime

流结束时间,以秒为单位,以1970/1/1 0:0开始计算

ULONG 4

InTotalPkg

(源IP方)接收包数

ULONG 4

InTotalByte

(源IP方)接收字节数

ULONG 4

OutTotalPkg

(源IP方)发出包数

ULONG 4

OutTotalByte

(源IP方)发出字节数

ULONG 4

Reserved1

对于0x02版本(FirewallV200R001)保留;

对于0x03版本(FirewallV200R005)第一个字节为源VPN ID,第二个字节为目的VPN ID,第三、四个字节保留

ULONG 4

Reserved2

保留

ULONG 4

Reserved3

保留

分析抓包文件,查看UDP 30017报文头信息,具体如下图所示。

于是能分析出问题的原因:设备发的日志第一个字节表示VersionNum而第二个字节为LogType4,发送的是如下格式的日志,没有NAT后的IP信息的。

因此程序中会将NATIP置为NAT前的IP一样的值来显示,设备发送的就不是NAT日志,而是Flow日志。

分下述三种情况分析问题原因。

第一种:设备发的日志第一个字节表示VersionNum1  而第二个字节为LogType1,发送的是如下格式的NAT日志,没有NAT