3、进行iMC UBA服务配置，即在用户行为审计服务中将NAT设备添加为
该服务的日志发送设备：
4、下发配置。在服务器管理中选中对应的服务，点击配置下发，截图如下：
下发成功的截图如下：
5、创建NAT日志审计任务，用于审计刚才添加的NAT设备所发送的NAT
日志，通常在下发配置后十分钟就能够在创建的审计任务中看到结果，创建审计任务的截图如下：
6、点击刚刚创建的NAT审计任务，输入如下审计结果：
iMC UBA的维护：
引子：iMC UBA&NTA对日志处理和最后的呈现及审计，日志也有最初的日志生成、发送、接收、处理、存储、显示这些过程，就象流水一样，可能会由于某一个环节的原因而被截流，呈现给用户的就是看不到想要看的日志或者流量信息报表，所以，在回溯原因的时候，我们也就使用这种环节定位的思路来分段检查，直至定位最终的原因，并解决它。以下就iMC UBA看不到日志为起点，分探针和设备两种情况，以环节检查的思路来溯源定位： 1、探针方式实现iMC UBA而看不到日志的定位思路： 第一环：日志是否生成
查看probe进程是否运行，方法是通过命令：ps –ef|grep probe 如果探针进程没有运行，可能原因是安装探针不对，即单核系统安装了多核探针，或者多核系统安装了单核探针，也可能是安装探针后没有重新启动服务器；
如果探针进程运行正常，那么看/data/目录下是否时刻有日志生成，如果没有可能原因是在iMC UBA服务配置中没有进行配置下发，请进行配置下发； 第二环：iMC UBA服务器上能否看到探针发来的日志
查看方法是查看iMC UBA服务器上配置的ftp目录下是否实时有日志从探针服务器传过来；
如果没有日志传过来，请检查ftp server是否启动，如果启动请检查ftp给探针服务器分配的用户是否具有写权限，中间是否有防火墙将日志给阻断了，简单方法是从探针服务器以ftp登录到iMC UBA服务器并上传文件检查一下，如果不成功以以上方法检查一下。如果OK则进入下一个环节； 第三环：日志是否被处理
检查方法是$\\imcdata\\processorData\\（新版本为：$\\imc\\data\\processorData）目录下是否有日志不断更新，如果没有可能原因是iMC UBA的processor.exe进程没有起来，检查iMC监控代理是否有没有起来的进程存在； 第四环：日志是否被存储
日志最终的归属地就是终于数据库，目前iMC UBA只支持SQL数据库，也就是查看SQL Server数据库中是否有对应地日志表生成。检查办法是登录SQL Server地企业管理器，选择unba_slave数据库，打开表，查看所有表中是否有如下格式地表生成：tbl_nets_08******（*代表当前日期）表生成，如果启用地摘要日志分析，还有如下格式地表生成：tbl_ftps_08******，tbl_mail_08******，tbl_web_08******；如果没有，可能是日志被丢弃或者数据库有问题，这是不可能的，因为之前的三个环节都OK：） 外一环：以上四个环节都OK，但是还不能审计日志
如果这时还不能审计日志，可能是探针服务器的时间与iMC UBA服务器的时间不一致，请检查确认修改。
经过以上五个环节后，用户按照自己的需求进行审计的时候，日志就会乖乖的出来了。建议处理问题的时候可以采用逆向的方式来排查。 2、设备直接向iMC UBA发送日志
处理方式同探针，只是日志生成有设备自己来完成，不需要探针来实现，环节如下：
第一环：日志是否生成
查看方法是在设备侧display日志发送统计，看是否向iMC UBA服务器发送日志的统计，如果没有，请检查该设备的日志发送配置是否正确，如是否配置发送目的地址、端口，是否使能日志统计等； 如果OK，进入下一环节； 第二环：日志是否被接收
查看方法，检查iMC UBA服务器目录$\\imcdata\\ recieverData\\下是否有日志更新，如果没有，日志可能是被阻塞或者丢弃，阻塞的可能是因为iMC UBA和日志生成设备之前有防火墙没有配置正确的acl，或者iMC UBA的9020、9021端口被占用，排除阻断可能，那就是丢弃了，这个原因可能就是添加设备的地址和设备发送日志的源地值不同，确认方法是抓包看一下发往iMC UBA服务器的源IP是否与添加设备的IP地址相同，如果不同删除设备重新添加，或者更改设备配置的日志发送地址； 第三环：日志是否被处理
检查方法是$\\imcdata\\processorData\\目录下是否有日志不断更新，如果没有可能原因是iMC UBA的processor.exe进程没有起来，检查iMC监控代理是否有没有起来的进程存在； 第四环：日志是否被存储
日志最终的归属地就是终于数据库，目前iMC UBA只支持SQL数据库，也就是查看SQL Server数据库中是否有对应地日志表生成。检查办法是登录SQL Server地企业管理器，选择unba_slave数据库，打开表，查看所有表中是否有如下格式地表生成：tbl_nat_08******（*代表当前日期）表生成；如果没有，可能是日志被丢弃或者数据库有问题，这是不可能的，因为之前的三个环节都OK：）
外一环：以上四个环节都OK，但是还不能审计日志
如果经历了以上四个环节还是不能在iMC UBA上审计到日志，可能原因是设备时间设置不对，请确认修改；还有两个原因可能是设备时区与iMC UBA服务配置中添加接收设备的时候选择的时区不一致，解决办法是改变添加时区重新适配解决。另一个可能原因是设备接口索引和iMC UBA识别的索引不一致造成的，目前这种情况比较少了。到时联系二线处理即可。
日志收集
iMC UBA&NTA经历了以上环节后还不能解决问题，需要联系二线进行问题定位，这样就需要收集较为详细的日志和配置信息，包括如下信息：
1、配置信息：
将iMC UBA&NTA服务器上$\\imc\%unba\\conf目录下的所有文件打包反馈； 2、debug日志信息
以cmd的方式进入$\\imc\%unba\\bin文件夹，分别修改接收器和处理器的debug日志的方式如下
receiver.exe loglevel debug processor.exe loglevel debug
然后将$\\imc\%unba\\log目录下的日志打包反馈，同时将debug的日志级别改回warning级别，方式如下： receiver.exe loglevel warning processor.exe loglevel warning