宜人贷安全建设之端口监控服务篇 – 作者:yirendai_sec

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

作者：YISRC-Punck

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

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

Nmap版本V1

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

用到的也是比较常见的分布式扫描架构（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端口，可能为新增业务，供后续安全工作及联动漏洞扫描的开展及推进，邮件推送详情大致如下：

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

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

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

 内网资产进程级监控

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

同时告警规则也支持黑白名单配置（规则包含IP、进程名称、端口、协议），如下：

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

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

内网端口总览，如下：

联动漏洞扫描器

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

写在最后

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

来源：freebuf.com 2018-05-22 11:14:11 by: yirendai_sec