信安系统主要功能模块流程说明_0325

信安系统主要功能模块流程说明

该文档的所有章节前提是系统已正常运行，数据库正常，各设备之前连接正常。

设备已配置正确DNS，审计端设备能连通外网。

名词解释:

CU管理器: 与一级中心同义

审计子端：接收数据，进行审计处理

执行单元：block模块，执行封堵功能

二级中心：审计数据库

1.审计流程

数据流进来后，优先到网卡，经由网卡驱动加载后，然后由审计进行完成审计工作。一般情况下抓包口是审计设备的eth0和eth1，具体抓包口需要根据实际使用进行配置。

1

1.1网卡流量确认

1)tcpdump：tcpdump –i eth0 可以看到是否有流量进来

2)ifconfig, 查看是否有丢包或者“RX packets:11180”收到包的数据是否有变化。

2

1.2网卡驱动确认

1)审计端的内核包编译过后，一般网卡驱动会有改变，如下图所示：

2)目前使用的编译驱动下需确认已将网卡注释掉：

审计端vi /etc/modprobe.conf #表示已注释

【备注】一般设备能都正常起来情况下，网卡驱动只需进行前面两步骤即可。若机器无法正常启动，需认真核查下面信息

3)安装程序或者升级过程中，驱动加载不上时，确认设备硬件信息，方法如下：

A.查看机器的内存信息

3

如果红圈标明的值明显大于超出100，则可以正常安装或升级。

如果不够，继续往下：

B.查看机器原本加载的buf大小是否足够。

a)查看本机的内核版本：uname -r

b)进入到对应的文件下面看配置文件:

cd /usr/seentech/drivers/2.6.18-274ng.el5PAE/one_cp/conf

打开驱动配置文件：cat zrcp.conf

4

----看这个原始驱动的配置大小，如果是>=100的，那么就直接升级。

----如果是<100的，那么继续一下操作：

C.查看机器本身内存信息:free -lm

看一下这个数字：如果这个数字加上上面配置文件里面的一起还是<100,或者是刚超出100的，那么就暂停升级，

5

1.3进程确认

1)审计进程说明如下：

./NetGet：网页访问审计()

./NetPost：网页发帖审计，BBS审计,微博审计(POST)

./NetOther：邮件审计，远程登录审计，文件传输审计(SMTP/POP3,TELNET,FTP)，图片审计

2)进程正常情况下，审计将会读写入库，需确认读写指针正常

进入cd /usr/seentech/netguard/tools

执行./zero_tools -m1 -b32 -mfnf_post（以POST为例）

下图中的rp标号每隔几秒会进行更新，没有进行更新时需要重启审计后台，重启方式：cd /usr/seentech/netguard && sh run.sh & 。

6

注意：由于系统存在bug，rp没有更新时，先找研发定位下问题，再重启审计后台。

不是重启机器哦。

1.4数据库表中配置确认

1)审计端表get_db_conf表中只有一条配置信息，无重复配置

1.5其他配置信息确认

1)监控范围配置

A.CU管理服务器已配置正常的监控范围，先界面确认配置正确，再进行数据库

tab_service_information表确认

7

B.审计端确认监控范围已同步，与设置监控范围一致。

审计端数据库表sys_machine_info

2)后台查看入库配置

审计端服务器确认配置为审计入库：

vi /usr/seentech/netguard/conf/ns_netsentinel.conf

该配置需为1（单条入库）或2（批量入库）

同时审计进程要开启，比如NetGet , NetPost ,NetOther。

3)查看缓存是否较大

审计审计端：cd /usr/seentech/netguard/data

du -sh action

8

du -sh post_file

du -sh _log

4)确认抓包网卡协商模式关闭

ethtool -K eth4 rx off tx off sg off tso off关闭协商命令

ethtool -k 端口查看协商配置情况

5)审计端口默认需开启混杂模式

注：在宽广按照MAC地址做镜像时，需关闭端口的混杂模式

9

关闭混杂模式的命令：ifconfig eth0 -promisc（有宽广设备时考虑改操作，其他情况慎操作）

开启混杂模式的命令：ifconfig eth0 promisc up

2.报警流程

采用自身设备报警流程如图：

10

2.1策略选取说明

对于下发策略前需要确认选取哪些IP，域名，URL，关键字作为策略的内容，需满足下列条件：【很重要】

1)选择的目的IP，源IP，域名，URL，关键字对应的URL均需要是能审计到的，即

选择的IP/域名/URL在审计的流水表_xxxx_xx_xx中是可以查询到的；(界面上查

询一定要把每个子端顺次查询查询一遍，默认显示的一个机房的第一个子端，最好

是从数据库进行查询)；

2)自己访问所选取的网站，确认流量能都流入机房；

3)确认所访问的网站的IP在监控范围内；

4)对于内容关键字的选取，在满足前三者的基础上，还需是该网页的源文件中能够找

到的（直观看到的网站信息和网站源文件不一定一致，内容关键字必须是源文件中

的）

操作方式1：打开网站，点击右键，选择“查看源文件”，红色框中才能选为策略

关键字

11

2.2报警实现过程

由管局侧下发监测策略---→CU管理服务器收到策略后转发给审计端---→审计端通过中间件加载策略------→数据流到审计端后与策略进行匹配，匹配到后将数据进行报警标识为报警信息----→报警信息在CU管理服务器进行汇总处理----→报警信息上报给管局

2.3进程说明

1)CU管理服务器报警进程：./AlarmOptS

2)审计端中间件进程：./ ProxyComm

2.4策略表说明

1)CU管理服务器:

12

ismsc_idccommand（显示接受的管局下发的策略表，信息安全管理指令菜单内容，commandID[管局指令ID]，scheme_id[企业侧策略ID]的对应关系表）

t_alarm_content （下发的具体报警内容，可以找到策略号scheme_id)

t_policy

t_policy_service

t_scheme

t_scheme_policy

t_scheme_unit_app（界面显示的指令的下发状态，可通过改此表更改状态）scheme_id连接所有的策略表

2)审计端

t_alarm_content (下发的具体报警内容)

t_policy

t_policy_service

t_scheme

13

t_scheme_policy

t_scheme_unit_app

u ser_policy （IP，域名，URL经中间件加载后入库表，报警入此库才能生效）

tab_policy_keyword（含有关键字的策略经中间件加载后入库表，报警入此库才能生效）

scheme_id连接所有的策略表

2.5策略下发说明

1)CU管理服务器的那几张表，并下发指令给中间件

2)中间件入库t_开头的那几张表，并合并策略，将IP，域名，URL策略保存到

user_policy表中，并通知审计端获取。

3)中间件入库t_开头的那几张表，并合并策略，将含有关键字的策略保存到

tab_policy_keyword表中，并通知审计端获取。

4)审计端最终加载的策略是user_policy和tab_policy_keyword表中保存的策略。

14

2.6报警日志表说明

1)CU管理端：

alarm_collect_2014_03_07

a larm_collect_config （rule_identifier报警日志的策略标识）

alarm__2014_03_07 （rule_identifier报警日志的策略标识）

alarm_post_2014_03_05

2)审计端：

_2014_03_07 (flag=2会记录为报警日志)

注意：关键字报警时_2014_xx_xx表中flag值为4，alarm__2014_xx_xx表flag值为2。

2.7报警日志产生和上报说明

1)审计端审计数据，在协议模块里面提取出ip、url、域名，关键字等信息之后，将

flag值置为2并写入到对应的流水表中，如：_xxxx_xx_xx表中。

2)中间件根据tab_proxy_protocl_proclist表中的配置【见下图】，从对应的流水表

中获取flag值为2的数据进行策略匹配。查询的id值为更新为最新查询到的审计

日志记录数，匹配中策略的记录则上报到CU管理服务器（本地未保存报警数据）。

15

【注：在IP、域名、URL规则数比较多的情况下，为了尽快得到相关数据，采用不传递给CU管理服务器，而直接在本地进行统计的方式，例如电信、联通的测试环境。需要在审计端本身手动创建alarm__YYY_MM_DD(从CU管理服务器复制过来)等对应的报警数据表，才能够存入数据。配置项为：/usr/seentech/ProxyComm/conf/ ns_netsentinel.conf配置文件中，设置write_alarm_to_local=1，然后重启进程即可】

3)在write_alarm_to_local=0时，CU管理服务器主进程接收到中间件上传的数据

后，再次匹配一次策略（防止CU管理完全和审计端的策略不一致作了一个保障，基本可以不管），匹配好的入库CU管理服务器的alarm__xxxx_xx_xx等报警数据表。

4)CU管理服务器AlarmOptS进程根据alarm_collect_config表里面配置的，从对

应的报警数据表里面(alarm__xxxx_xx_xx等报警表)获取报警数据，分析放入到alarm_collect_xxxx_xx_xx流水表中。

5)界面从alarm_collect_xxxx_xx_xx流水表中提取相关的报警信息展示在界面上。

该表的table_name 当前处理表必须为当前的时间。查询的id值为更新为最新查询到的alarm__xxxx_xx_xx记录数。

16

17

6) alarm_collect_xxxx_xx_xx 表中的日志所对应的策略号rule_identifier 一般需能

在策略表如t_policy 表中查询到。rule_identifier=scheme_id 。

7) 报警日志上报给管局，需alarm_collect_xxxx_xx_xx 表中的日志所对应的策略号

rule_identifier 在idc_command 表能都查到，即rule_identifier= commandID ，且该commandID 的策略没有取消，是正在生效的。（用该commandID 在idc_command 表中只能查询到一条记录，有两条表示一条是新增一条是删除就不属于正在生效的策略）。

3.过滤流程

3.1 IP/URL/域名封堵流程

管局下发过滤策略--→CU 管理服务器接收到策略后下发到流量监控管理平台（以下分两种情况）

--→流量监控管理平台设备为第三方设备，则直接转发给第三方设备完成封堵

--→流量监控管理平台设备为自身设备，

则发送给审计端执行单元，由执行单元完成封

堵,如图为自身设备封堵流程：

3.2关键字封堵流程

管局下发过滤策略--→CU管理服务器收到策略入t_*策略表后转发给审计端t_*策略表---→审计端通过中间件加载策略------→数据流到审计端后与策略进行关键字匹配，得到关键字的URL--→将匹配到的关键字URL上传给CU管理服务器--→CU管理服务器接收到策略后下发到流量监控管理平台（以下分两种情况处理）

--→流量监控管理平台设备为第三方设备，则直接转发给第三方设备完成封堵

--→流量监控管理平台设备为自身设备，则发送给审计端执行单元，由执行单元完成封堵，如图为自身设备封堵流程：

18

3.3进程说明

1)CU管理服务器进程：流量监控管理进程./NMP_User

2)审计端：执行单元进程./NMP_Executor（原使用）

19

旗开得胜3.4 IP/URL/域名过滤策略下发

1)CU管理服务器：

JAVA界面下发过滤策略：

ismsm_selfidccommand（界面显示的策略状态在此表修改）

ismsm_selfidccommandcontent

PHP界面下发过滤策略：

ismsj_isstop_content

ismsj_isstop_info

ismsj_isstop_unit_app（界面显示的策略状态在此表修改）

block_scheme（策略表）

2)CU管理服务器流量监控管理平台(数据库：blockServer )

t_ip_block_list

t_domain_block_list

20