200万条恶意域名黑名单
没错,是200万条,还没撑满。
现在很多安全系统,比如NTA、APT检测设备,部署方式都是旁路的。也就是说,它们只能“看”,不能“拦”。
识别得再准、告警跳得再响,攻击流量该去哪儿还是去哪儿。
所以,最后那一刀,还是要交给真正串接在网络路径上的设备来砍,比如出入口的防火墙或者网关。
但新问题又来了。
安全检测系统每天识别出来的恶意IP和域名成千上万,有些组织自己维护的IOC库,常年在几十万到上百万条之间。
但另一头,传统防火墙/网关却很难跟得上。
很多中低端设备,对地址/域名对象的支持还停留在几千条的级别。就算是配置高一点的设备,真加载进去后也可能会发现:
就这样,海量黑名单涌进来,串接设备却吃不下、消化不了——“能识别,却拦不住”成了常态。
所以小派决定换个思路:让能跑得动的设备也能拦得住。
我们的Panabit网关,性能不用多说,还支持开放的RESTful API接口,正好可以用来做动态对象同步。
👉了解RESTful API:基于RESTful API实现流量监控自定义大屏自由
于是小派连夜写了两个脚本:
一个是用Python写的,另一个也是用Python写的。
一个同步IP对象,一个同步域名对象。
核心逻辑大概是这样:
# 核心逻辑示意代码(以域名为例)
api = PanabitAPI(
CONFIG["gateway_ip"],
CONFIG["username"],
CONFIG["password"]
)
api.sync_domains_from_url(
CONFIG["group_id"],
CONFIG["domain_list_url"]
)
我们需要在设备上事先建立好IP或域名群组,并设置针对群组的阻断策略。
这里小派再啰嗦一句,黑名单并不一定越多越好,要注意别被误伤。 比如,本来正常的DNS服务器,因为解析了一个C2域名,结果直接把DNS服务器拉黑了,导致全网解析异常,这就有点得不偿失了。 所以小派建议,在黑名单策略前面加一个放通规则,放行你的DNS服务器、办公常用域名等,先白再黑,避免误拦。 在Panabit策略配置中,这种组合非常容易实现,灵活、清晰、不卡壳。
然后设置脚本中的相关信息:
CONFIG = {
"gateway_ip": "你的Panabit设备IP", # 例如: "192.168.0.100"
"username": "你的Panabit用户名", # 例如: "admin"
"password": "你的Panabit密码", # 例如: "panabit123"
"group_id": 你的域名群组ID, # **重要!** 可在Panabit WEB UI查看,例如: 1,IP群组类似
"domain_list_url": "包含域名列表的URL" # 例如: "https://raw.githubusercontent.com/hagezi/dns-blocklists/main/domains/light.txt"
}
运行脚本,就可以开始自动同步。
想定时同步?加个cron
或任务计划就好了。
这次同步的是一个超过210万条的黑名单(多个来源合并)。
整个过程用时20s。
全量导入,策略生效,命中立刻开始拦截,没有延迟,也没有掉性能。
当然,小派今天拿的是最小的AX40。
真要跑性能、上大流量,无论是10G、20G、100G,甚至400G的场景,都有对应型号能跑得动、拦得住。
如果你也有类似需求——比如旁路安全平台输出IOC,想联动网关拦截,这套方案就可以复用。
当然,不只是拦截,还可以基于IP/域名群组做限速、改路由甚至流量镜像等等,具体怎么用取决于你的策略。
代码在这里,欢迎使用或扩展👇
https://github.com/Panabit-Software/Panabit-API-Scripts/tree/main/sync_tools
说到底,能识别是一回事,能拦住才是真本事。
过去我们靠人工导入、手动更新,要导表、登录、套格式……现在设备接口开放、API能力成熟,不必如此繁琐了。
如果你也正为“识别了却拦不住”烦恼,不妨试试这套组合吧。