宜人贷安全建设之端口监控服务篇

本次分享宜人贷端口扫描服务的开发部署及演进过程,借此抛砖引玉,与大家一起交流讨论。

宜人贷安全建设之端口监控服务篇

作者:YISRC-Punck

在企业安全建设中部署端口扫描服务作为一个必不可少的基础环节,有研发资源的安全团队都会开发部署端口扫描监控服务,定期扫描梳理公司资产、端口开放情况及时发现违规高危端口开放问题,响应处理。

本次分享宜人贷端口扫描服务的开发部署及演进过程,借此抛砖引玉,与大家一起交流讨论。

Nmap版本V1

谈到端口扫描技术,相信大部分同学都会用到功能丰富且非常强大的’ Nmap’。没错,宜人贷初期的端口扫描监控服务是基于Nmap进行端口探测和指纹识别的,扫描监控服务框架大致如下:

1.png

用到的也是比较常见的分布式扫描架构(Django+Celery+redis)、Mysql、扫描(libnmap模块)。整体的流程大致为,触发扫描任务、Celery调度扫描任务、调用Nmap扫描集群、扫描结果入库、邮件告警、Web端展示并处理。

但是Nmap在面对企业全网全端口扫描场景时就会受到限制,扫描速度就显得捉襟见肘,所以既需要保证扫描速度,又要准确获取Banner、识别服务成为版本迭代的需求。

Masscan+Nmap版本V2

Masscan是号称‘六分钟内扫遍互联网’端口扫描器,但是在端口Banner获取及服务识别这方面,面对Nmap极度丰富的服务识别指纹库这方面是存在劣势的,因此采用Masscan+Nmap的扫描方式,成为当时迭代的方法。

触发扫描任务后,利用Masscan进行1-65535全端口扫描,扫描结果入库,针对Masscan探测到的存活端口掉用Nmap进行服务指纹识别,这样Nmap调用次数就减少了一个量级,提高整体的扫描速度。

邮件告警

扫描结果的邮件推送展示,除了针对自定义的高危端口及时告警之外,通常的做法是对比历史扫描数据,也就是对比昨天的扫描结果,提取新增端口,并邮件告警展示,如新增80、433端口,可能为新增业务,供后续安全工作及联动漏洞扫描的开展及推进,邮件推送详情大致如下:

2.png

通常扫描过程中因网络条件以及Masscan、Nmap等不可见因素,每次扫描结果可能存在误差及漏报,若发送邮件时只比较昨天历史数据会存在大量的误报,因此针对非高危端口的新增判断增加了一个逻辑,“该端口历史3天内未扫描探测到”,来减少邮件展示的误报率,但也存在一定的缺点,场景如下:

3.png

6月16日,未扫描80端口,可能确实为业务下线,17日扫描到的80为重新上线的新业务,也可能16日未探测到80属于漏报,这种情况下是不会进行生成邮件事件告警的,因为针对非高危端口设定的策略为‘近3天内未探测到该端口开放’,可能会漏报,但另一方面新上线业务的发现及扫描可以通过其他途径来获取发现。

通过安全服务台下的端口监控Web端进行告警事件详情查看及处理,查看扫描数据大致如下:

4.png

 内网资产进程级监控

相比于外网端口的扫描监控,针对内网资产的监控,采集数据细化到进程级别,进程入库数据(包括进程名称、PID、启动路径、启动事件、启动命令等)大致如下:

5.png

同时告警规则也支持黑白名单配置(规则包含IP、进程名称、端口、协议),如下:

6.png

以图中第二条举例说明:任意服务器启动“ossec-csyslogd”进程,该规则情况下新增any端口不进行告警。

为了降低邮件告警事件量,通常需要将正常业务进程添加白名单当中,持续优化,内网端口推送邮件如下:

7.png

内网端口总览,如下:

8.png

联动漏洞扫描器

针对内网新增端口,会联动POC扫描进行漏洞扫描,如下:

9.png

写在最后

本文主要介绍了宜人贷端口扫描监控系统的开发迭代过程,包括用到的技术栈以及系统架构,如何优化告警规则,联动扫描器等方面。都是一些常用的方法和思路,欢迎大家批评指正,借此抛砖引玉,有好的建议也希望一起交流共同进步,比如是否可以抛弃Celery自己实现分布式调度?或者是否有更好的分布式框架可以参考?是否可以直接用DNmap进行分布式扫描?对于新增端口的规则定义是否还有更多更好的方法来优化?自动化程度是否可以再高一点?欢迎一起讨论,我们也会持续迭代优化,感谢大家的阅读和交流,谢谢!

发表评论

已有 3 条评论

取消
Loading...

填写个人信息

姓名
电话
邮箱
公司
行业
职位
css.php