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

信安系统主要功能模块流程说明该文档的所有章节前提是系统已正常运行，数据库正常，各设备之前连接正常。

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

1、审计流程数据流进来后，优先到网卡，经由网卡驱动加载后，然后由审计进行完成审计工作。

一般情况下抓包口是审计设备的eth0和eth1，具体抓包口1.1.网卡流量确认1)tcpdump：tcpdump –i eth0 可以看到是否有流量进来2)ifconfig, 查看是否有丢包或者“RX packets:11180”收到包的数据是否有变化。

11.2.网卡驱动确认1)审计端的内核包编译过后，一般网卡驱动会有改变，如下图所示：2)目前使用的编译驱动下需确认已将网卡注释掉：审计端vi /etc/modprobe.conf #表示已注释【备注】一般设备能都正常起来情况下，网卡驱动只需进行前面两步骤即可。

若机器无法正常启动，需认真核查下面信息3)安装程序或者升级过程中，驱动加载不上时，确认设备硬件信息，方法如下：A.查看机器的内存信息2如果红圈标明的值明显大于超出100，则可以正常安装或升级。

如果不够，继续往下：B.查看机器原本加载的buf大小是否足够。

a)查看本机的内核版本：uname -rb)进入到对应的文件下面看配置文件:cd /usr/seentech/drivers/2.6.18-274ng.el5PAE/one_cp/conf打开驱动配置文件：cat zrcp.conf3----看这个原始驱动的配置大小，如果是>=100的，那么就直接升级。

----如果是<100的，那么继续一下操作：C.查看机器本身内存信息:free -lm看一下这个数字：如果这个数字加上上面配置文件里面的一起还是<100,或者是刚超出100的，那么就暂停升级，41.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标号每隔几秒会进行更新，没有进行更新时需要重启该进程。

561.4. 数据库表中配置确认1) 审计端表get_db_conf 表中只有一条配置信息，无重复配置1.5. 其他配置信息确认1) 监控范围配置A. CU 管理服务器已配置正常的监控范围，先界面确认配置正确，再进行数据库tab_service_information 表确认B. 审计端确认监控范围已同步，与设置监控范围一致。

审计端数据库表sys_machine_info2)后台查看入库配置审计端服务器确认配置为审计入库：vi /usr/seentech/netguard/con/ns_netsentinel.conf该配置需为1（单条入库）或2（批量入库）3)查看缓存是否较大审计审计端：cd /usr/seentech/netguard/datadu -sh actiondu -sh post_filedu -sh _log74)确认抓包网卡协商模式关闭ethtool -K eth4 rx off tx off sg off tso off关闭协商命令ethtool -k 端口查看协商配置情况5)审计端口默认需开启混杂模式注：在宽广按照MAC地址做镜像时，需关闭端口的混杂模式8关闭混杂模式的命令：ifconfig eth0 -promisc（有宽广设备时考虑改操作，其他情况慎操作）开启混杂模式的命令：ifconfig eth0 promisc up2、报警流程2.1.策略选取说明对于下发策略前需要确认选取哪些IP，域名，URL，关键字作为策略的内容，需满足下列条件：【很重要】1)选择的目的IP，源IP，域名，URL，关键字对应的URL均需要是能审计到的，即选择的IP/域名/URL在审计的流水表_xxxx_xx_xx中是可以查询到的；2)自己访问所选取的网站，确认流量能都流入机房；3)确认所访问的网站的IP在监控范围内；4)对于内容关键字的选取，在满足前三者的基础上，还需是该网页的源文件中能够找到的（直观看到的网站信息和网站源文件不一定一致，内容关键字必须是源文件中的）910操作方式1：打开网站，点击右键，选择“查看源文件”，红色框中才能选为策略关键字2.2. 报警实现过程由管局侧下发监测策略---→CU 管理服务器收到策略后转发给审计端---→审计端通过中间件加载策略------→数据流到审计端后与策略进行匹配，匹配到后将数据进行报警标识为报警信息----→报警信息在CU 管理服务器进行汇总处理----→报警信息上报给管局2.3. 进程说明1) CU 管理服务器报警进程：./AlarmOptS2) 审计端中间件进程：./ ProxyComm2.4.策略表说明1)CU管理服务器:ismsc_idccommand（显示接受的管局下发的策略表，信息安全管理指令菜单内容，commandID[管局指令ID]，scheme_id[企业侧策略ID]的对应关系表）t_alarm_content （下发的具体报警内容，可以找到策略号scheme_id)t_policyt_policy_servicet_schemet_scheme_policyt_scheme_unit_app（界面显示的指令的下发状态，可通过改此表更改状态）scheme_id连接所有的策略表112)审计端t_alarm_content (下发的具体报警内容)t_policyt_policy_servicet_schemet_scheme_policyt_scheme_unit_appu ser_policy （IP，域名，URL经中间件加载后入库表，报警入此库才能生效）tab_policy_keyword（含有关键字的策略经中间件加载后入库表，报警入此库才能生效）scheme_id连接所有的策略表2.5.策略下发说明1)CU管理服务器的那几张表，并下发指令给中间件122)中间件入库t_开头的那几张表，并合并策略，将IP，域名，URL策略保存到user_policy表中，并通知审计端获取。

3)中间件入库t_开头的那几张表，并合并策略，将含有关键字的策略保存到tab_policy_keyword表中，并通知审计端获取。

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

2.6.报警日志表说明1)CU管理端：alarm_collect_2014_03_07a larm_collect_config （rule_identifier报警日志的策略标识）alarm__2014_03_07 （rule_identifier报警日志的策略标识）alarm_post_2014_03_052)审计端：_2014_03_07 (flag=2会记录为报警日志)2.7.报警日志产生和上报说明131)审计端审计数据，在协议模块里面提取出ip、url、域名，关键字等信息之后，将flag值置为2并写入到对应的流水表中，如：_xxxx_xx_xx表中。

2)中间件根据tab_proxy_protocl_proclist表中的配置【见下图】，从对应的流水表中获取flag值为2的数据进行策略匹配。

查询的id值为更新为最新查询到的审计日志记录数，匹配中策略的记录则上报到CU管理服务器（本地未保存报警数据）。

【注：在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 流水表中提取相关的报警信息展示在界面上。

14该表的table_name 当前处理表必须为当前的时间。

查询的id值为更新为最新查询到的alarm__xxxx_xx_xx记录数。

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、过滤流程5.1.IP/URL/域名封堵流程管局下发过滤策略--→CU管理服务器接收到策略后下发到流量监控管理平台（以下分两种情况）--→流量监控管理平台设备为第三方设备，则直接转发给第三方设备完成封堵15--→流量监控管理平台设备为自身设备，则发送给审计端执行单元，由执行单元完成封堵5.2.关键字封堵流程管局下发过滤策略--→CU管理服务器收到策略入t_*策略表后转发给审计端t_*策略表---→审计端通过中间件加载策略------→数据流到审计端后与策略进行关键字匹配，得到关键字的URL--→将匹配到的关键字URL上传给CU管理服务器--→CU管理服务器接收到策略后下发到流量监控管理平台（以下分两种情况处理）--→流量监控管理平台设备为第三方设备，则直接转发给第三方设备完成封堵--→流量监控管理平台设备为自身设备，则发送给审计端执行单元，由执行单元完成封堵5.3.进程说明1)CU管理服务器进程：流量监控管理进程./NMP_User2)审计端：执行单元进程./NMP_Executor（原使用）165.4.IP/URL/域名过滤策略下发1)CU管理服务器：JAVA界面下发过滤策略：ismsm_selfidccommand（界面显示的策略状态在此表修改）ismsm_selfidccommandcontentPHP界面下发过滤策略：ismsj_isstop_contentismsj_isstop_infoismsj_isstop_unit_app（界面显示的策略状态在此表修改）block_scheme（策略表）172)CU管理服务器流量监控管理平台(数据库：blockServer )t_ip_block_listt_domain_block_listt_url_block_listt_domain_ip_block_list（组合策略）3)第三方设备执行封堵：策略直接从CU管理服务器发送到外部设备4)自身设备执行封堵：审计端执行单元(数据库：clear, 过滤信息入此库才能生效)block_url_policyblock_domain_policytab_pass_ip_policyb lock_ip_domain_policy（组合策略）5.5.关键字过滤策略下发关键字过滤策略的生效需要先完成关键字转换为URL的过程，所以其策略下发入表同报警策略一致。