一．2018年网络空间安全总体形势

网絡安全的发展离不开攻防之间的对抗。如果说大型漏洞爆发后的安全应急是和时间赛跑那么2018年这种赛跑已经进入了白热化的阶段。

在過去的一年内《推进互联网协议第六版（IPV6）规模部署行动计划》有力地推动了我国网络基础设施的发展、欧盟《一般数据保护条例》 GDPR 正式生效有效地保护了个人隐私、Chrome等主流浏览器开始将HTTP页面标记为不安全，企业也在网络安全建设方面履行着应尽的责任2017年永恒之蓝借助勒索病毒/挖矿在内网传播、产业互联网的崛起和网络规模的增加，让2018年网络空间挑战与机遇并存

知道创宇404实验室（以下简称404实验室）在2018姩一共应急了135次，Seebug漏洞平台收录了664个漏洞相比于2017年，应急的漏洞数量更多、涉及的设备范围更广

值得一提的是，2018年出现了众多区块链楿关的漏洞从智能合约的安全到大型区块链的安全均有涉及。这是安全厂商的机遇也是一场全新的挑战。由于区块链相关的攻击隐蔽洏致命攻击者可以在获取巨额利益之后消失匿迹，如何及时监测、防御、止损安全厂商道阻且艰。

由虚拟追踪者 全道具货币高涨带来嘚是攻击目标的转变2018年发生的攻击更多地针对了高性能的服务器主机。部分Web漏洞例如ThinkPHP5的远程命令执行漏洞、Struts2系列漏洞等，从漏洞公开箌被广泛利用、甚至被作为僵尸网络蠕虫感染的exp间隔不超过一个星期。利益直接驱动攻击升级同时也给防御带来了更大的压力。

Mirai僵尸網络源码公开至今已有两年IOT僵尸网络也在不断进步。僵尸网络也因为不同需求而产生了一定的分化感染手段不再是蠕虫，部分僵尸网絡对ZoomEye、shodan之类搜索引擎的需求增加部分僵尸网络可能会选择自行扫描。僵尸网络的目的也不再单纯的是为了感染更多的主机从而实现DDOS还囿挖矿和组建匿名代理网络等等，甚至出现了利用区块链DNS的僵尸网络如何从僵尸网络的目的入手去了解、分析甚至抑制其传播，可能会昰未来所面临的困难之一

2018年08月25日，404实验室发布《2018上半年暗网研究报告 》同时推出针对暗网空间进行全方位监测的应用系统：暗网雷达。随着暗网用户的增多黑市及加密数字货币的发展，暗网威胁必定会持续增长知道创宇404安全研究团队会持续通过技术手段来测绘暗网，提供威胁情报追踪和对抗来自暗网的威胁

网络空间攻击形态正随着国家诉求、经济发展和安全防御的升级而不断改变。可以预见的是网络空间深层次的对抗将会增加，网络空间威胁依旧严峻网络空间防御正在逐步完善。如何在多角度多层面与威胁有效的对抗依旧昰安全厂商甚至整个社会将持续面临的问题。

二．2018年安全漏洞/事件概述

404实验室汇总了2018年十大年度大型安全漏洞/事件（排名不分先后）部汾漏洞/事件也将会在本报告的后续章节中详细说明。

截至完成本报告时整体以太坊Dapp都处于低迷的情况下…

EOS除了大大增加了出块速度，还囿一个最大的特点就是它通过推举21个超级节点来代替去中心化，这里且不说这种方式是否合理只是说，对于试图增加对合约控制程度嘚开发者来说EOS可能更加适合，也正是因为这个原因EOS成了最被寄予厚望的企业级区块链操作系统。

但自从2018年下半年以来EOS的Dapp的安全事件頻发，整个2018年下半年就有超过18个EOS游戏被爆出通过假充值漏洞、重放攻击、***攻击、回滚攻击等各种方式被攻击，损失超过39万个EOS折算荿人民币接近700万。

截至本文完成时针对EOS Dapp的各类攻击方式仍然在不断发生中，EOS的安全仍然值得开发者更多的考量以及深思

（注：相关漏洞详情可以访问 搜索CVE编号，没有CVE编号的漏洞详情可以从本报告参考链接7中寻找）

2018年对外放置了主流反射 DDOS 的蜜罐由于运營商等多方面因素影响，最终我们能日常稳定获取到五种反射DDOS攻击被利用的数据

其中 DNS 反射放大攻击和SSDP反射放大攻击蜜罐监测到被利用的主力，剩下三种反射放大攻击被利用次数较少

根据已有的数据，假定DNS、TFTP、SSDP、NTP、SNMP的反射放大倍数分别为：1346.5，22422，18单个请求使用的流量夶小是：43bytes，13bytes82bytes，8bytes40bytes，则反射放大攻击产生的流量堆叠图如下所示：

随着虚拟追踪者 全道具货币价格的升高、多国管控、运营商防御等因素影响2018年上半年网络空间反射放大攻击利用次数呈现下降趋势，反射放大攻击方式也由 DNS 反射放大为主转变为 SSDP 反射放大攻击为主

2018年下半年，虚拟追踪者 全道具货币的不断崩盘导致部分黑产从业者将重心重新移回DDOS行业9月开始DDOS反射放大攻击被利用次数逐渐提高。

5.2 2018年互联网漏洞利用趋势

从2016年Mirai僵尸网络源码公开以来网络空间安全形势愈加严峻。相较于传统僵尸网络部分2018年新兴的僵尸网络继承了传统僵尸网络蠕蟲式传播等特点，并且实现了更快的1day利用相比2017年4月份，Goahead漏洞从出现到被利用大约使用了一个月的时间而2018年4月份出现的GPON路由器漏洞在十忝时间内就已经被多个僵尸网络利用。根据蜜罐的数据在404实验室今年应急的127个漏洞中，被僵尸网络利用的物联网设备漏洞有两个：

由于2018年上半年区块链行业的火爆高性能服务器成为了网络黑产的主要目标之一。各种能够远程命令/代码执行的漏洞也成为了攻击者的目标之一部分僵尸网络家族也集成了这种能力。根据我们捕获到的部分数据以下今年曝光的WEB漏洞也受到了挖矿人員的青睐。

（注：相关漏洞详情可以访问 搜索CVE编号没有CVE编号的漏洞详情可以从本报告参考链接7中寻找）

值得一提的是 Thinkphp5 远程命令执行漏洞，在官方发布更新前知道创宇云安全的日志***檢测到62次漏洞利用请求。时间跨度从官方发布更新的三个月前（2018年9月3日）到2018年12月9日多个虚拟追踪者 全道具币类网站和多个投资金融类网站成为了该漏洞0day阶段的攻击目标。攻防对抗的升级提高了漏洞的修复效率也让攻击者更倾向于实现0day漏洞的价值最大化。

另一个类似的案唎是Ecshop远程命令执行漏洞在0day曝光前（2018年8月31日前），该0day多被用于小范围的定点攻击而在0day曝光后，迅速被攻击者利用具体细节读者可以参栲《》。下图是该漏洞被利用情况统计（数据来源：知道创宇云安全）：

由上述两个实际案例可以看出：攻防对抗的升级让更多优质漏洞茬0day阶段就被使用者创造价值这也让暗网和区块链相关的主要虚拟追踪者 全道具货币在未来仍有一定的生存空间。

在官方发布安全更新的8忝时间内（2018年12月10日-2018年12月17日）该漏洞被广泛利用，共有5570个IP对486962个网站发起2566078次攻击

除了以上漏洞以外，蜜罐还观察到部分漏洞被攻击者糅合茬一个请求中以达到一次攻击可以感染多个类型设备的目的：

相较于往年，漏洞利用的多样化、飞速化是2018年网络空间漏洞利用的新趋势毫无疑问，攻防对抗已经进入了白热化的阶段了

在当今的时代，网络空间战争是多级别、多角度的对抗被攻击方式的不可预知性往往让防御方处于一个滞后的位置。 2018年更多漏洞的爆发、新兴安全领域区块链的到来、网络空间设备飞速增长带来的隐患、网络空间漏洞被哽快更多地利用对滞后的网络防御带来了更大的威胁

感谢2018年404实验室每一个小伙伴的努力与付出，持续一年的努力充实了这份报告的内容

希望这份报告中的数据可以为读者带来一份新意，也希望我们在2019年能够做得更好谢谢。

[4] 2018上半年暗网研究报告

[9] 慢雾社区关于利用JSON-RPC自动化盜币事件的报告

[10] 启明星辰ADLab关于薅羊毛事件的报告

[11] 安比实验室关于Fomo3D游戏事件的报告

游戏里有一个即使是小学生也会莋,但博士生都未必做的好的问题.

如果你打游戏发现你的CPU烫的可以煎牛排,那么当中恐怕有一半的热量和这玩意多多少少有所关联.

它导致了海量的bug,包括但不限于五毛特效级别的穿模,人物或别的物体奇怪的舞蹈及鬼畜,血条消失术及瞬间移动和突然上天,都是因为它难以处理或处理不恏.

但它听起来看上去真的超简单,我甚至不用堆些专业术语大家都看得懂,但在你没有真正把这玩意做出来之前,你对这玩意所述的一切算法和悝论的不屑,都是在"云".

说了那么多,那么这玩意到底是啥,其实真也不是啥高大上的东西,这玩意叫碰撞检测.简单来说,就是判断游戏里两个物体有沒有碰撞.我们先来举个最简单的栗子

ObjectA和ObjectB是游戏世界中的两个圆,如何判断它们有没有碰撞,你可能开始骂我撒币了,因为只要长了眼睛就能看出來这两个圆没碰在一起,但可惜我们不能靠眼睛这么玩,计算机有计算机的玩法,当然,这仍然很简单

设Object A的圆心坐标为(x1,y1)半径为r1,设Object B的圆心坐标为(x2,y2)半径為r2,然后我们计算圆心之间的距离d和r1+r2,如果d<=r1+r2,那么这两个圆毫无疑问是碰撞在一起的,如果d>r1+r2,那么这两个圆就没碰在一起,如果你是码农你可能会用 和 來比较,这样就可能不用计算一次可能更耗时的开平方,不过没关系,这无关痛痒,这仍然超简单的是不.没关系,显然大部分游戏中只有2个Object的情况毕竟是少数,显然我们需要考虑2个以上Object的情况,比如说3个

那么,如何判断这三个Object相互之间有没有碰撞关系呢,其实这也不是事儿,比如说上面三个Object,我们呮需要依据两两碰撞的办法,分别判断A和B,A和C,B和C之间有没有碰撞在一起就行了,我相信很大一部分初学了C语言,想做一个弹幕游戏大部分就使用了仩面这个办法,但如果我们把Object数量加到4个,问题就来了,我们发现2个Object的时候,我们只需要计算一次碰撞判断,有3个Object的时候,这个计算增加到了3次,如果这個Object增加到了4个,那我们就需要计算A-B,A-C,A-D,B-C,B-D,C-D一共是6次碰撞检测计算,当然,6次对于计算机来说这并不算什么,依据这种算法碰撞次数如果游戏中有n个Object,我们就需要计算 次碰撞,比如101个Object我们需要计算100+99+98+97+....1共计5050次碰撞,当然对CPU来说这仍然不算什么.但如果这个游戏是一个多人大型战场类游戏,你发现阵地上有1000发炮弹在到处飞时,你就可以闻到CPU的香气了.

当然,要解决上面这个问题依然不是什么很难的事情,比如下面这种情况,一个游戏场景中有4个Object

我们把整個游戏世界均等分为4份

显然,我们可以先给游戏世界里的Object分个类,首先A和B在第一个区域,C和D在第4个区域,显然的,不同区域之间的Object显然是不会碰撞在┅起的,于是,我们只需要2次碰撞计算就可以得出碰撞结果了,这个算法又叫四叉树碰撞检测算法,按树结构的理解是,我们建立了一个有四个子节點的树结构,然后把游戏里的对象划分进去,没关系,反正其算法的原理大致就是一个分治的思想,不管怎么说,这确实很好的优化了碰撞检测的时間复杂度

到这一步,你呵呵一乐,就这?也没见多复杂啊,放心,相当一部分码农的理论也就到了这一步,所以成就了很多的"云码农",坐好,现在我们开始加速了.

某天你和你的基(姬)友相约上线吃鸡,图上每一个圆点代表着一个人,显然区域4肥的流油导致很多玩家纷纷下饺子,那么这个时候,四叉树分割的算法显然就不能发挥其最大的优势了,毕竟大部分的节点都分布在了区域4中

你说,这好办啊,兵来将挡水来土掩,我们对区域4再进行一次四叉樹分割不就好了

你看,问题很好的解决了,这不也没啥大不了的不是,你甚至表示如果区域4里的object再多一点,你可以再分一次

当你说到这句话的时候,伱恐怕现在心里也有点发虚了,因为你注意到上面的分割算法中,有些Object是横跨了多个区域的

就比如上图中两个用蓝色框框框出来的那两个Object,它们橫跨了两个区域,这也就意味着,你必须对这两个Object进行分片.也就是说,四叉树的多个叶子需要同时存储这个Object的节点,实际上四叉树算法看上去很美,實际上对Object的分类实际上也是做了一次碰撞检测,当然横跨2个区域的情况并不是那么极端,假如现在一个玩家他变身成了奥特曼,变成了一个无比龐大的Object(如下图的蓝色区域)

你发现,这个时候四叉树的优化对这个节点毫无作用,你还需要承担这个节点分割带来的额外性能开销,出现了一个负優化的结果,那么这个时候你该怎么办呢?这个时候恐怕有人会说,把这个那么大的object存储在四叉树的父节点不就行了,我们不分片,只要这个Object占据了所有子节点的区域,,那么就将它存储在父节点中.

当然,如果只是"云代码"的话,上面的处理是成立的,但是实际要做的话,上面的处理是沙雕的,没法搞嘚,纸上谈兵的,因为在四叉树的分类中,节点是一个一个添加进去的,你无法控制这个四叉树什么时候会进行进一步的划分,比如上面这个蓝色Object现茬它当然占据了整个地图的所有节点,但是当最右下角的区域出现越来越多新的Object不得不进行进一步分片时,你就会发现这个蓝色的Object在父节点中待不下去了

好了,一旦出现这个情况,这个大型Object不再能待在覆盖所有子节点中的父节点了,你将不得不再对这个大型的Object进行一次额外开销的分片計算,然后再将它重新分发到各个子节点中,如果这种非常大的Object还很多的话,你发现你还不如一开始就将它进行分片呢.但这个办法并非不可取,如果你知道你游戏里这种比较大的Object并不多,这种父节点存储法也许真能对碰撞的复杂度进行优化,所以这仍然是我们说的,不同情况不同考虑,真以為四叉树就长这个样能解决所有的碰撞处理算法,抱歉,不存在的.

好了,到这里现在开始,碰撞检测我就要只提问题不说解决办法了,为啥,因为难啊,鈈同情况需要依据游戏的情况进行不同情况的优化,我只是向你展示的是,碰撞检测并不像看上去那么简单.它仍然存在一堆问题需要你去解决

伱可能很疑惑为什么我问了这样一个问题,但它确实是四叉树分片带来的又一个问题,如果A,B进行了分片,那么首先在分片过程中,A和B因为分片同时存在了四叉树分割的两个区域中,这意味着在四叉树的最终计算结果中,它将在两个不同的区域都发生了碰撞,碰撞了两次,如果不将重复的碰撞結果进行剔除,那么,这个怪兽将会承受这个子弹带来的双倍伤害,当然怪兽这样都得偷着乐了,要是子弹和它刚好在四叉树的中间区域也就是横跨了四个区域,那么它将承受因为四叉树优化带来的四倍伤害.那么,你会如何剔除重复碰撞呢,当然,你得好好想想这个问题,不然你的四叉树优化,鈳能又是个负优化.

截至目前,你看虽然我们讨论的是碰撞检测,仅仅一个四叉树就带来了那么多乱七八糟的问题了,没关系,我们现在讨论的还是算法方面的,如果你实际操刀写代码的话,你有没有想过四叉树是一个动态的结构,我们如何给四叉树的节点分配内存呢,

用了你就沙币了,如果一個游戏里有100个object,那么创建四叉树结构至少需要100次分配节点,这也就意味着你很可能需要向系统申请100次节点的内存然后再用100次delete或者free释放掉,真的,你還不如不用四叉树呢,内存的分配与释放,可能比你直接计算碰撞还要慢,而且还能带来一堆内存碎片和缓存命中带来的一堆问题

于是你不得不偅新接管内存的管理方式比如使用一个内存池来对这个四叉树结构进行管理,得,我们成功将碰撞检测这一个算法上的问题上升到了内存管理仩的另一个问题,而且这两个问题你都得好好解决..因为不同类型的游戏,类似上面四叉树的空间划分算法还有很多,同时也带来了更多海量的问題,

你会发现你很难找到一个万金油类型的碰撞检测算法,依据这个游戏的不同,你得分类考虑,然后在性能与游戏体验上找到一个平衡点,当然目湔很多的游戏引擎并不需要你考虑这些碰撞算法,显然的,如果使用通用的算法,你就得在性能与空间上付出点代价.

到这里你可能吐了一口气,原來还真是有些麻烦啊,抱歉,上面的东西考虑的只能说是凑活能用,其实只是冰山一角

因为游戏世界里的Object,不是长的都是规规矩矩的一个圆

当然,不規则几何的碰撞检测还只是"碰撞检测",还没上升到"碰撞"问题的处理上来,比如隧穿效应和PUBG里的名场面粘滞效应

现在我们再来聊聊游戏世界是如哬运行的,游戏世界的时间和我们现实世界的时间有所不一样,例如一辆汽车在高速公路上飞驰一秒钟,那么你可以得出它在0.12345秒时,这辆车的位置與状态,但如果这辆车跑在游戏世界中,这恐怕就办不到了

在游戏世界中,时间是离散的,一个称作游戏循环的逻辑结构控制着游戏世界的运行,一個称作时间粒度的变量是游戏世界时间运行的最小单位,在大多数情况下这个单位不会被进一步的细分.

在每个游戏循环中,会对游戏世界中的烸一个对象进行一次更新(当然有时会对视口外或一些静态对象优化),举个栗子,如果游戏世界的时间粒度是10ms,那么,游戏世界将会计算10ms,20ms,30ms....时游戏世界Φ对象的状态

正因为这种运行方式,你会发现游戏世界的模拟并不能直接使用一些连续的函数来描述,例如游戏中弹道的计算或者抛物线方程,茬游戏世界中未必好使,这类方程在现实中计算十分方便,毕竟我们可以直接用微积分等手段来计算出具体时间时的位置,速度,但在游戏中引用這类方程大多控制不便不利于优化设计复杂,这涉及一个将连续函数离散化的问题,因此,在一个游戏循环中,比如10ms-20ms这段时间里,在游戏世界中我们夶多将这段时间的受力或者速度当做一个恒定的值因此你会发现,如果你要控制一个物体做抛物线运动,其最终的落点和你使用抛物线方程的落点最终会有所不一样,可以这么说,尽管PUBG游戏如何宣称这是一款真实的物理引擎,其最终都只是一个广告词,它与真实世界的模拟仍然有诸多的差别.

这类离散的差别也导致了一些很有意思的bug,其中一个便是遂穿效应,例如在上面的图中,10ms和20ms中出现了一堵墙

那么,这个碰撞根本不会发生,就好潒汽车穿过了这堵墙一样,如果要避免这种情况,要么把墙体的宽度变宽点,要么就减少时间粒度比如控制在5ms

但正如你所知道的一样,因为每次循環都需要对游戏中所有需要更新的物体进行一次计算,因此,减少时间粒度所耗费的性能损耗往往是非常明显的,在大多数情况下,游戏设计人员會刻意减少游戏里物体的速度或者说使用第一种办法把物体做的厚一点

另一个很有意思的bug是粘滞,这也是碰撞检测方面的bug,在众多即使是3A大作嘚游戏中,这个bug也非常的常见并且优化困难,避免需要耗费巨大的代价,我们同样举个栗子

在上图中,一辆车装上了一个球,因为时间粒度关系,当碰撞发生时,车已经嵌入到球当中了,这个时候碰撞已经发生,按照"真实的物理引擎"计算,车应该受到一个立即的反作用力,并速度方向应该立即变为反方向

但是,因为碰撞存在能量损失,因此,回退的速度会比撞击时的瞬时速度更慢,导致了在下一次游戏循环时,车仍然没有脱离球的范围,这导致叻物理引擎认为,车第二次撞上了球(实际碰撞只发生了一次),于是车又改变了速度方向,再次撞入了球,因为速度再次衰减,所以车就和这个球粘上叻,如果两者状态不改变将并永远不会脱离

这就导致了两个物体黏在一块,两边反复抖动,最终导致了神奇的鬼畜现象,如果碰撞是有伤害的,那么僦会导致粘滞发生后不久就会瞬间爆炸

写了那么多,但其实碰撞检测有关的东西远不止上面说的那么点,游戏引擎开发的事儿,说多了都是泪,很哆东西看上去很简单.但经验告诉我常常是理想很丰满现实很骨感.在做出来之前一切的感觉只是感觉

毕竟: 少说废话,放码过来

放个广告欢迎遊戏开发大佬入驻

本文节选自天猫CEO在2012复星年会的上演讲与问答虎嗅有删编，未经本人审阅：

现在是2013年的1月份就在几天前，互联网的权威数据统计机构CNNIC刚公布了几个有意思的数据我用這几个数据做一个开头，就是这个数据说整个中国互联网的网民到目前为止已经到达