本帖最后由 下一代防火墙 于 2025-8-31 21:16 编辑
一、梗概 本贴主要两个目的,一是分享AF本身的本地蜜罐功能,此功能个人认为在安全运营建设中具有很大意义,为AF的优势功能;二是分享本地蜜罐落地过程的遇到的问题,便于大家后续快速落地
二、蜜罐功能介绍 蜜罐功能从旧架构一直延续到新架构。此功能分为本地蜜罐与云蜜罐。 本地蜜罐开通增强级模块后即可使用,其效果为AF本身监听配置的蜜罐端口,针对访问蜜罐端口的IP进行自动化封锁。蜜罐端口仅为模拟监听,如配置3389为蜜罐端口,终端使用RDP无法链接成功,但可telnet通,通常telnet 2-5分钟后,即可处罚自动化策略。(访问蜜罐后有2-5分钟延迟,个人认为够用) 云蜜罐功能需要额外订购相关模块,可以将攻击者流量转发到云端的云蜜罐上,业务模拟更仿真,并可思想攻击者画像分析,社交溯源分析等。
综上,本地蜜罐仅监听蜜罐端口,实现TCP交互,无法实现业务类交互,仅可实现访问即封装;云蜜罐可模拟业务,对攻击者进行分析溯源。本文主要讲的是本地蜜罐。
三、本地蜜罐配置 本地蜜罐策略与云蜜罐在同一处,伪装服务选Local 类型即为本地蜜罐,并可自定义端口。 本地落地蜜罐的网络架构有多种,如出口地址转换映射到内网AF蜜罐端口,实现自动化诱捕封锁公网IP,也可AF对内网IP诱捕,实现防止内网被入侵后横向扩散。根据个人经验,内网场景需要业务流量经过AF,或蜜罐IP与AF本身的IP同网段。
四、问题与排障 在如上述完成蜜罐配置后,发现telnet80 端口可触发蜜罐并实现自动化封锁,但telnet 3389端口则不通。之前在旧架构AF下此配置无问题,此次为新架构AF下配置。 排查思路 1、首先在AF上抓包,确认访问3389的流量经过了AF1、(下图仅体现在何处抓包与抓包命令) 经过抓包可以看到数据包到了AF 2、使用AF自身的故障排查功能,发现AF 本机DOS防护模块阻断了数据包 关闭相关模块后蜜罐恢复正常 日志如下 五、结论 经过与CTI确认,AF新架构增加了本机DOS防护功能,对于3389这种AF本身就不监听的端口,此模块先进行阻断。之所以未关闭此模块时,80端口蜜罐功能正常,是因为AF本身监听了80端口用于认证功能。因此本地蜜罐如有自定义端口需求,需要先关闭此模块。根据经验旧架构AF(8.0.48及之前版本)无此机制。 |