简单聊聊网络空间测绘纵横之道
这篇文章来自 heige 投稿，我好像很久都没打理本懒号了，突然感觉也挺对得起本懒号的名字...需要注意的是：我不是真懒，只是创业太忙了，感谢坚持关注的众多铁粉，哪段时间闲一些，我好好分享分享我的一次次有意思的经历...
好，进入 heige 的正文之前再多说两句，ZoomEye 这个大工程能坚持有人带领发展实属不易，烧钱且复杂，一件事一做就是7年了:-)
钱钟书先生的《围城》有句名言“外面的人想进去，里面的人想出来”本来是说婚姻的，但是在我看来在某些技术产品领域也比较适合，比如今天我要讲的网络空间测绘这个方向。本来是不太愿意过多的谈论这个问题的，就跟“结婚”一样，你说他说都不重要，他跟她都还是会去结婚，真正体验过才知道生活的“酸甜苦辣”，所以在网络空间测绘这个领域从2009年Shodan发布、2013年ZoomEye发布、2015年Censys发布后前后多家前后“前仆后继”（国内国外都有，有的早已消声觅迹了）的跟进，这个是必然的，以至于我前面在朋友圈发过一些调侃：
“时常能听到或者见到一些尴尬的段子，大意是：我们做了一套比ZoomEye牛逼的ZoomEye！[擦汗]”
在没有真正走进“围城”的时候，可能很多人认为“网络空间测绘（搜索引擎）= vps+Zmap/MassScan+ES ”，但一旦去尝试进入“围城”就会真正感受到各种“坑”，这也应对了上面提到酸甜苦辣”婚姻生活！
所以我觉得我说啥不重要，我也看到很多业界同行经常发布一些文章，大多不是“侃侃而谈”就是“自我标榜”，当然我之前也针对一些问题写过一些文章，以至于 老白@0x557 看了后调侃我写的内容大有“空手道大师兄”的风范 … （弱弱的尴尬）
虽然我说啥都不重要，但是我看到一些问题还是可以说一说，至于认同不认同那就随缘了，这跟我最近做的直播初衷一样：随缘布道！在我看来网络空间测绘是一个非常庞大及繁琐的领域，我在KCon2019 404发布环节《打造世界领先网络空间测绘能力》
里说的网络空间测绘这个实际上是一个数据类的产品或者领域，核心在于两个关键“获取更多的数据、赋予数据灵魂”。
既然核心都是“数据”，今天就给大家梳理一些简单明面上的“数据”，这些数据是我之前没有在哪篇文章或者ppt里看到过整理梳理过的！
既然要谈测绘我们首先要看测的对象都有谁：
• IPv4地址
• IPv6地址
• 域名
• 暗网
在这几个里面IPv4是唯一可以确定绝对数量的(4,294,967,296)的，而IPv6及域名及暗网地址是需要依靠各种途径收集整理的，比如IPv6地址库ZoomEye目前达到16.2亿，并且这个数据每天都在增涨，域名池ZoomEye达到52亿陆续加入节点列队扫描，在传统的几大搜索引擎里国内以ZoomEye为典型一般都支持IPv4/IPv6/及域名的探测，而国外的以Shodan为首主要还是集中在IPv4/IPv6上，至于暗网的测绘目前都没有直接支持，我们的直接独立出一个“暗网雷达”产品。
所以IPv4仍然是目前测绘的主要对象，下面一些梳理的点主要是基于IPv4测绘的：（如图）
按上图的流程罗列几个数据（一次探测）：
理论上的IPv4地址总量：4,294,967,296
理论上的端口总量：65535 * 2 （包括TCP/UDP，这里很多人把UDP给忽视了）
理论上的协议总量：未知 目前各大搜索引擎支持大概在1000～2000种
理论上的探针总量：不确定 每个协议可能做的深度不一样
这里给大家举个例子说明下这个深度探测的探针，比如针对http协议，把每个网页爬下来对内容进行提取分析并提供检索，这就是谷歌/百度这类传统搜索引擎了，很显然这里谈网络空间测绘不是为了再造一个谷歌或者百度，所以最开始ZoomEye是只获取主页的http返回头及html内容的，但是在我们实际过程中在分析这个主页内容很可能不足以用来识别设备(如常用的titile作为设备指纹很可能就没有)，这里就需要开发一个进一步的探针获取转跳页面的内容，当然再比如获取favicon的hash也算是深度探测的探针之一，随着跟多需求趋势可能导致的探针越来越多。
我们做个简单运算：
n次探测 * 4,294,967,296(IP地址池) * 65535 * 2 （tcp/udp端口）* n个协议 * n个探针
这个是理论上的运算，可以看出是一个非常庞大的数据，由此如果拿着一个单一某个探针的支持而“自我标榜“或者说要实现所谓的“标准”那是比较可笑的，当然这个探针肯定是有一定意义的，理论上说网络空间测绘对目标画像有帮助的数据都是有意义的。
如果把某个协议的深度探测这块理解为“纵向”，那么我们可以把探测频率、port、协议支持等理解为“横向”，这里又需要提到我朋友圈里的“名言”了：
黑哥尔说过：横向扩？还是纵向扩？这是个问题！
根据上面提到的理论运算方式，其实我们可以关联到一些基础指标：探测频率(次数)、地址池覆盖、端口覆盖、协议覆盖、深度探测项目等等。但是实际上你的资源是有限制的，所以在这些指标在真正做的过程中是有取舍的，比如可能不是所有的端口都去探测每一个已知协议，这里都是去取舍的问题，当你的地址池的扩充、探针、协议、端口支持越多，在你的节点带宽有限的情况下你的探测频率在理论上是必然降低的！所以怎么扩？往哪里扩？谁先扩？成为新的灵魂三问！
充分利用有限的资源实现最大化的利用是我们必须思考的一个问题，最起码现阶段是这样！在说这个问题之前我们需要说明下网络空间测绘的一个最原始解决的诉求：找到目标设备。那么对于一个设备来说确定它的指纹方法不是唯一的，一个设备可能开放了多个端口服务，我通过其中一个端口服务能确定指纹可能就能满足需求了，比如某个设备他的3131端口服务上存在一个漏洞，而这个端口搜索引擎并没有覆盖或者说端口覆盖了协议没覆盖，那是不是就没办法了？实际上我们还可以通过这个设备的其他端口如http服务的80端口直接确定他的指纹就可以覆盖到了！当然这里可能会有人说如果某些目标关闭了这个指纹相关的端口呢？实际上这个需要测试覆盖率，在很多情况下网络空间测绘通过大量的高并发扫描或者节点被拦截等情况下丢失的目标可能都比这些认为关闭端口的情况都多。又比如获取某些利用深度探针获取某个信息探针，有时候我们也需要简单评估考虑会不会在其他端口服务就可以获取到这个信息呢？
然而才成本角度还没有完，在每个基础指标上我们还可以站在技术投入的技术上去纠结下，比如探测节点调度及日常管理、协议的分析及逆向、探针的研发 这些都是需要人力成本投入的 …
上面的这些只能算是网络空间探测的“数据获取”这个部分的一些工作流程逻辑，实际上这个工作只是网络空间测绘工作的一个点，我最终得“赋予数据灵魂”这里涉及的问题就比如这些数据怎么存储、怎么更加方便检索分析并解读、用户体验数据展示等等
这些问题以后有机会再跟大家一起探讨！另外我最近尝试下直播，不定期的随缘布道，有兴趣的可以关注下并连线探讨一些有意思问题 : *音搜索关注 hi_heige
