iMC UBA采集DIG和SR志的配置和维护指导.docx

iMC UBA采集DIG和SR志的配置和维护指导.docx

《iMC UBA采集DIG和SR志的配置和维护指导.docx》由会员分享，可在线阅读，更多相关《iMC UBA采集DIG和SR志的配置和维护指导.docx（19页珍藏版）》请在冰点文库上搜索。

iMCUBA采集DIG和SR志的配置和维护指导

iMCUBA的配置和维护指导

iMCUBA的配置和维护指导1

摘要1

名词解释1

准备工作：

2

组网方式3

探针的UBA实现案例3

和NAT设备配合进行用户行为审计案例9

iMCUBA的维护：

14

日志收集16

摘要

iMC智能管理中心，是华三推出的下一代业务智能管理平台。

它融合了当前多个产品，以统一的风格提供与网络相关的各类管理、控制、监控等功能；同时以全开放的、组件化的架构原型，向平台及其承载业务提供分布式、分级式交互管理特性；并为业务软件的下一代产品提供最可靠的、可扩展的、高性能的业务平台。

iMCUBA用户行为审计组件是一套用户上网日志审计系统，能够处理包含NAT日志、FLOW日志、NetStreamV5日志、DIG日志等多种日志类型；支持对用户上网行为进行查询和审计；当和DIG探针采集器配合时，可以基于URL和Web站点审计用户的上网行为，可以审计用户用FTP传输文件的行为，还可以审计用户的Email信息；用户还可以自定义日志审计任务，通过审计任务用户可以持续审计自己关注的上网行为。

当UBA组件和iMCUAM（用户接入管理）组件一起安装时，UBA能够和iMC用户接入管理组件实现联动，实现基于用户名的审计，替代基于IP地址审计用户上网行为的方式。

名词解释

主服务器：

部署iMC平台的服务器；

从服务器：

通过Web登录iMC配置台，将所选组件分步式部署在非主台服务器的服务器；

用户行为审计：

对用户上网过程中以何地址、何端口访问了哪里等进行记录，如果是NAT日志可以审计到NAT前后的地址、端口，如果何DIG配合可以审计到网页，同时对应用FTP、HTTP、MAIL进行审计；

流量分析：

一般部署在网络出口，主要关注用户网络的实时带宽大小，同时涵盖了这些流量信息中的应用区分，为优化网络提供帮助，主要关注实时的信息多一些，报表丰富；

数据库空间使用率：

在iMC平台安装好以后，UBA或者NTA会自动创建数据库，在这个数据库中存放从设备或者探针发来经过分析处理后的日志文件，在此数据库空间中以存放的日志占用空间与目前数据库申请的空间的比值就是数据库空间使用率，其值会随着保存日志的增多而变大，当数据库空间用完的时候，数据库会进行自动扩张，从而间接降低磁盘数据库空间使用率，用户存放新的日志数据；

磁盘空间使用率：

数据库所在磁盘已使用空间与总空间的比值，随着数据库空间的不断增长而变大，单纯的删除数据库空间的表不会降低磁盘空间使用率，只有将数据库中的表删除后，并进行数据库收缩才能够降低磁盘空间使用率；

准备工作：

概览：

iMC平台包含了网管的功能，根据用户应用的需要可以将UAM、EAD、UBA、NTA等组件跟平台进行集中式部署，也可以分步式实现，即为了功能的明确和性能的要求，可以对部分组件采用分步式的方式来不属到其他的服务器上。

例如UBA、NTA组件可以通过分步式部署来实现，这种分步式部署最多支持5台服务器，部署方法是将用户行为审计组件或流量分析组件部署在主服务器上，即和iMC平台部署在一起，而将用户行为审计服务器组件或流量分析服务器组件部署到从服务器上，要求每台服务器只能部署一个用户行为审计或/和流量分析服务器组件；

本案例以集中式部署为例进行说明，同时兼顾探针和SR66的NAT日志审计，默认平台和UBA都已部署完成，且能够自动启动。

1、硬件准备

平台（以5000个用户的平台推荐配置，具体参考对应组件的版本说明书）：

PC服务器-HPML350G4p-2*Xeon3.0GHz-2G-6*72G（10K）SCSIRAID5-软驱-CDR-集成网卡+100&1000M网卡-642RAID卡（192M）-15"-塔式-3年5*8服务-英文资料-725W-键/鼠

探针服务器：

要求探针服务器双网卡（具体参考对应组件的版本说明书），使用的操作系统为LinuxES3.0，

2、软件安装

操作系统：

iMC支持Windows2000SP4Server、Windows2003SP1Server及以上版本，数据库支持SQLServer2000SP4、SQLServer2005

iMC版本：

目前最新的版本为iMCPLAT3.20-E2403、iMCUAM3.20-E0401P05、iMCEAD3.20-E0401P05、iMC-UBA-3.20-B0401P01，如果是山西电力用户使用iMCUBA组件，还需要打上如下两个补丁：

iMCUBA3.20-B0401L02、iMCUBA3.20-B0401L03；

探针版本：

操作系统为LinuxES3.0，版本为：

iMCh3cprobeE0401，其中包括SingleCPU和MultipleCPU两种，分别表示工作在单核和多核系统下的探针采集器；

组网方式

1、探针方式组网

2、和NAT设备配合组网

探针的UBA实现案例

1、操作系统的安装

安装方法参见LinuxES3.0的安装指导书；

2、探针采集器的安装

对于iMCh3cprobeE0401探针的安装之前，要先确定所进LinuxES3.0系统是多核还是单核，安装完LinuxES3.0默认所进系统为多核操作系统，其命名方式为：

RedhatEnterpriseLinuxEs（2.4.21-**.Elsmp），单核系统的名称为：

RedhatEnterpriseLinuxEs-up（2.4.21-**.El），以多核操作系统为例，登录用户权限为root，探针的安装方法如下：

a、首先在登录探针服务器的时候选择多核操作系统，登录权限为root，同时通过ifconfig的命令查看当前的网卡的名称，并规划好哪一个网卡作为采集口，连接镜像设备，哪一个网卡作为管理口连接iMCUBA服务器。

本例以eth0作为采集口，eth1作为管理口（有的服务器网卡命名为en0和en1等）；

b、将多核探针以binary的方式上传到探针服务器上，假设挂载的位置为：

\h3cprobe\MultipleCPU，然后进入探针安装目录：

#cd\h3cprobe\MultipleCPU\h3cprobe

目录下有探针采集器的安装文件probe.tar.gz和安装脚本probe_installer.sh；

c、执行probe_installer.sh脚本，提示信息如下：

安装程序默认将采集器安装到/usr/local/目录下，直接回车即可进行安装。

用户可以根据实际情况输入其他绝对路行进行安装。

d、选择采集器所在服务器的以太网卡名称，本例中选择采集网卡为eth0：

输入采集器网卡名称之后，系统会提示用户是否增加其他网卡作为采集器，本例不增加其他网卡，输入“n”后提示如下：

注：

在询问是否重起服务器的时候，输入“y”，必须重起服务器采集器才能正常工作。

采集器会在服务器重起时自动运行，使用ps–ax|grepprobe命令查看probe进程是否存在，如果存在表示采集器已经启动。

3、iMCUBA服务器的配置

默认iMC平台和UBA组件已经部署，并且能够正常启动，然后通过web界面登录iMC配置管理平台，登录方法是http:

//localhost:

8080/imc。

a、在iMCUBA服务器上开启FTPSERVER服务，或者安装类似ServU的ftp软件，用户接收从探针服务器发来的dig日志信息。

不建议使用3CDaemon软件作为ftp接收软件，原因是该软件具有syslog接收功能，与iMC平台有端口冲突的问题；

b、增加采集器：

进入如下位置，选择增加，并按照如下截图进行采集器配置：

如果要只对某些内网网段进行采集，可以设置过滤，即增加内网信息。

c、服务配置：

进入“业务>>流量分析与审计>>服务器管理”，输入FTP的目录、用户名、密码，注意目录需要输入绝对路径，同时选择该服务对应的采集器，点击确定，如下图所示：

d、下发配置：

进入“业务>>流量分析与审计>>服务器管理”，在“服务器列表”中选择配置下发，出现如下图示时表示下发成功：

下发成功的截图如下：

e、配置常用审计模版：

以审计web应用为例，配置模版如下：

f、点击web_audit的审计，结果输出如下：

同理，还可以创建基于MAIL、FTP的应用审计任务，如下截图分别是基于MAIL应用和基于FTP应用的审计结果：

和NAT设备配合进行用户行为审计案例

设备侧配置：

1、配置设备snmp参数：

snmp-agent

snmp-agentsys_infoversionall

snmp-agentcommunityreadpublic

snmp-agentcommunitywriteprivate

2、配置发送日志的版本、设备地址、接收服务器地址和端口：

userlogflowexportversion3//配置发送日志版本

userlogflowexportsource-ip172.16.254.9//配置发送设备源地值，同添加iMC平台的设备地址一致

userlogflowexportslot0host172.16.40.329020//配置接收日志的iMCUBA服务器地址和端口

userlogflowexportslot3host172.31.61.29020//配置接收日志的iMCUBA服务器地址和端口

3、配置日志生成机制：

sessionlogbytes-active1//配置输出会话日志的字节数流量阈值

sessionlogtime-active10//配置输出会话日志的时间阈值

4、在外网NAT端口使能日志统计功能：

sessionlogenableinbound//使能入方向上的NAT日志统计

sessionlogenableoutbound//使能出方向上的NAT日志统计

iMCUBA侧配置：

说明：

由于iMCUBA组件默认不对二进制日志进行处理，所以需要修改配置文件，使能iMCUBA处理NAT日志，方法是：

将文件$\imc\unba\conf\sysreceiver.xml中的红色0修改为1，然后保存，并重起iMC服务即可：

--二进制日志的处理方式，包括三个选项：

0-不处理，1-处理成NAT1.0日志，2-处理成FLOW1.0日志-->

--缺省是0-不处理-->

0

1、添加NAT发送设备，添加设备的时候使用的SNMP模版要与设备侧配置一致：

下图显示的是在iMC平台添加成功后的NAT日志设备列表：

2、在iMCUBA中增加该设备为NAT日志发送设备，如下图所示：

3、进行iMCUBA服务配置，即在用户行为审计服务中将NAT设备添加为该服务的日志发送设备：

4、下发配置。

在服务器管理中选中对应的服务，点击配置下发，截图如下：

下发成功的截图如下：

5、创建NAT日志审计任务，用于审计刚才添加的NAT设备所发送的NAT日志，通常在下发配置后十分钟就能够在创建的审计任务中看到结果，创建审计任务的截图如下：

6、点击刚刚创建的NAT审计任务，输入如下审计结果：

iMCUBA的维护：

引子：

iMCUBA&NTA对日志处理和最后的呈现及审计，日志也有最初的日志生成、发送、接收、处理、存储、显示这些过程，就象流水一样，可能会由于某一个环节的原因而被截流，呈现给用户的就是看不到想要看的日志或者流量信息报表，所以，在回溯原因的时候，我们也就使用这种环节定位的思路来分段检查，直至定位最终的原因，并解决它。

以下就iMCUBA看不到日志为起点，分探针和设备两种情况，以环节检查的思路来溯源定位：

1、探针方式实现iMCUBA而看不到日志的定位思路：

第一环：

日志是否生成

查看probe进程是否运行，方法是通过命令：

ps–ef|grepprobe

如果探针进程没有运行，可能原因是安装探针不对，即单核系统安装了多核探针，或者多核系统安装了单核探针，也可能是安装探针后没有重新启动服务器；

如果探针进程运行正常，那么看/data/目录下是否时刻有日志生成，如果没有可能原因是在iMCUBA服务配置中没有进行配置下发，请进行配置下发；

第二环：

iMCUBA服务器上能否看到探针发来的日志

查看方法是查看iMCUBA服务器上配置的ftp目录下是否实时有日志从探针服务器传过来；

如果没有日志传过来，请检查ftpserver是否启动，如果启动请检查ftp给探针服务器分配的用户是否具有写权限，中间是否有防火墙将日志给阻断了，简单方法是从探针服务器以ftp登录到iMCUBA服务器并上传文件检查一下，如果不成功以以上方法检查一下。

如果OK则进入下一个环节；

第三环：

日志是否被处理

检查方法是$\imcdata\processorData\（新版本为：

$\imc\data\processorData）目录下是否有日志不断更新，如果没有可能原因是iMCUBA的processor.exe进程没有起来，检查iMC监控代理是否有没有起来的进程存在；

第四环：

日志是否被存储

日志最终的归属地就是终于数据库，目前iMCUBA只支持SQL数据库，也就是查看SQLServer数据库中是否有对应地日志表生成。

检查办法是登录SQLServer地企业管理器，选择unba_slave数据库，打开表，查看所有表中是否有如下格式地表生成：

tbl_nets_08******（*代表当前日期）表生成，如果启用地摘要日志分析，还有如下格式地表生成：

tbl_ftps_08******，tbl_mail_08******，tbl_web_08******；如果没有，可能是日志被丢弃或者数据库有问题，这是不可能的，因为之前的三个环节都OK：

）

外一环：

以上四个环节都OK，但是还不能审计日志

如果这时还不能审计日志，可能是探针服务器的时间与iMCUBA服务器的时间不一致，请检查确认修改。

经过以上五个环节后，用户按照自己的需求进行审计的时候，日志就会乖乖的出来了。

建议处理问题的时候可以采用逆向的方式来排查。

2、设备直接向iMCUBA发送日志

处理方式同探针，只是日志生成有设备自己来完成，不需要探针来实现，环节如下：

第一环：

日志是否生成

查看方法是在设备侧display日志发送统计，看是否向iMCUBA服务器发送日志的统计，如果没有，请检查该设备的日志发送配置是否正确，如是否配置发送目的地址、端口，是否使能日志统计等；

如果OK，进入下一环节；

第二环：

日志是否被接收

查看方法，检查iMCUBA服务器目录$\imcdata\recieverData\下是否有日志更新，如果没有，日志可能是被阻塞或者丢弃，阻塞的可能是因为iMCUBA和日志生成设备之前有防火墙没有配置正确的acl，或者iMCUBA的9020、9021端口被占用，排除阻断可能，那就是丢弃了，这个原因可能就是添加设备的地址和设备发送日志的源地值不同，确认方法是抓包看一下发往iMCUBA服务器的源IP是否与添加设备的IP地址相同，如果不同删除设备重新添加，或者更改设备配置的日志发送地址；

第三环：

日志是否被处理

检查方法是$\imcdata\processorData\目录下是否有日志不断更新，如果没有可能原因是iMCUBA的processor.exe进程没有起来，检查iMC监控代理是否有没有起来的进程存在；

第四环：

日志是否被存储

日志最终的归属地就是终于数据库，目前iMCUBA只支持SQL数据库，也就是查看SQLServer数据库中是否有对应地日志表生成。

检查办法是登录SQLServer地企业管理器，选择unba_slave数据库，打开表，查看所有表中是否有如下格式地表生成：

tbl_nat_08******（*代表当前日期）表生成；如果没有，可能是日志被丢弃或者数据库有问题，这是不可能的，因为之前的三个环节都OK：

）

外一环：

以上四个环节都OK，但是还不能审计日志

如果经历了以上四个环节还是不能在iMCUBA上审计到日志，可能原因是设备时间设置不对，请确认修改；还有两个原因可能是设备时区与iMCUBA服务配置中添加接收设备的时候选择的时区不一致，解决办法是改变添加时区重新适配解决。

另一个可能原因是设备接口索引和iMCUBA识别的索引不一致造成的，目前这种情况比较少了。

到时联系二线处理即可。

日志收集

iMCUBA&NTA经历了以上环节后还不能解决问题，需要联系二线进行问题定位，这样就需要收集较为详细的日志和配置信息，包括如下信息：

1、配置信息：

将iMCUBA&NTA服务器上$\imc\unba\conf目录下的所有文件打包反馈；

2、debug日志信息

以cmd的方式进入$\imc\unba\bin文件夹，分别修改接收器和处理器的debug日志的方式如下

receiver.exelogleveldebug

processor.exelogleveldebug

然后将$\imc\unba\log目录下的日志打包反馈，同时将debug的日志级别改回warning级别，方式如下：

receiver.exeloglevelwarning

processor.exeloglevelwarning