【趣事】用 JavaScript 对抗 DDOS 攻击 (下)

上一篇：https://www.cnblogs.com/index-html/p/js-network-firewall.html

对抗 v2

之前的那些奇技淫巧，纯属娱乐而已，并不能撑多久。

但简单、好玩，似乎这正是对抗的乐趣。之前从未想过，居然还能把脚本黑科技，用在网络防御上。

于是，又陆陆续续对抗了一段时间。

直到兴致淡却，懒得再频繁升级了，于是换上一个更复杂的脚本。其中打包了大量的算法库，光是代码，就能吓退一些密集恐惧症者。

此外，还暗藏了一些自检功能，干扰脚本的分析破解。

这时，要把脚本逻辑移植出来，就格外困难了。

这迫使攻击者，不得不用另一种方式。。。

对抗 v3

为何要破解脚本，为何要了解其中的细节？直接让攻击器运行脚本，不就可以了！

之前担心的，还是发生了。升级后的攻击器，居然会弹网页了，看起来和正常用户一样。。。

黑盒攻击！加密混淆那些都没用了，只能寻找一些破绽。开始收集区分“真网页”和“内嵌网页”的黑魔法。

例如，有些攻击者为了隐蔽，把网页弹在屏幕之外。因此，分析页面 screenLeft、screenTop 就可以识破。

例如，内嵌网页的尺寸是锁定的。而弹出的网页，没准能调整大小，可以改变一两个像素试试。

.....

于是，光坐标尺寸，就扛了一阵子。

事实上，大多攻击者都不注重细节。所以，破绽还是不少的。

不过，发现破绽后怎么处理？直接在前端中止吗？当然不是，这样太明显。

即使识破，仍会发送请求，仍能进白名单。只是，请求里悄悄做了标记，暗示这是一个可疑用户 —— 最终白名单的有效时间，比正常短得多。

这样，就把测试效果延后了，增加破解时间。

同时，升级了防火墙策略，增加了“黑名单”机制。黑名单的 IP，是永远不能变白的。

因此，某些用户的可疑值积累到一定程度，就直接拉黑了。

随着防火墙装机量增加，将黑名单进行了共享，避免了不少重复分析。

对抗 v4

前端的秘密，早晚会被发现的。

最后，逼迫攻击器也采用了“内嵌网页”！之前的黑魔法，又纷纷失效了。。。

然而，破绽总还是有的。

很多攻击器，程序界面是隐藏的。这，会导致一些渲染上的差异。

例如，Flash 就有这么个机制：当界面不可见时，帧率会降到 2 fps，以节省开销。

例如，复杂的 JS 动画特效，原本跑的并不流畅。但界面挡住后，就能毫无压力的运行。

.....

当然，这些只能用来参考，并非一定正确。

同时，对防火墙的策略也进行了调整：只有当机器压力大时，才开启拦截。尽量降低被“黑科技”误伤的可能。

就这样，修修补补又一年。

对抗 v5

Chrome 浏览器流行后，极大激发了人们研究前端的热情。同时，脚本调试也变得更容易了。

为了不丧失最后的优势，决定“反其道而行之” —— 将脚本的部分逻辑，换成了 VBScript，迫使停留在 IE 上。而正常用户都运行于 WebBrowser，并无影响。

同时还将一些功能，做到了 Flash 里。

整个流程，需要 JS、VBS、Flash、iframe 等交互才能完成，大幅增加了调试复杂度。

对抗 v6

在对抗窘迫时，甚至还尝试了一些下策。例如，弹出一个对话框：

alert('欢迎光临 XXX')

只有点了确定，才能继续运行。于是，一些假人就卡死在了这里。

当然，攻击者很快做出回应 —— 屏蔽了对话框。

我是如何知道的呢？因为每次弹框，都记录了停顿时间：

t = time()

alert(...)

t = time() - t

然而这其中，居然有 0ms 的！！！

这是有多快的手速？？即使一直按着 ESC 键，对话框好歹也会闪一下，至少也有几十毫秒了。怎么试不出这么快的~~~

最终，将过短的时间都 XXX

对抗 v7

一段时候后，攻击者也摸索出了规律，不直接屏蔽了。

先让它弹出来，延时几秒，再发送回车键去关闭。。。反正我都想到了，人家也想得到。

于是，改成弹两个、三个、随机个对话框，而对方也许只会点一次。

当然，这都是临时的搞笑方案。

。。。

最后，迫不得己，不再使用系统对话框。而是用 HTML 画一个，并且只能通过鼠标点击关闭。

其实这早已想过，但一直不敢实施 —— 因为这只是个内嵌网页，即使不点，也不影响程序使用。一些用户可能没注意到，就错过了。

系统对话框没有这个问题。因为它会阻塞整个程序的消息，不点就无法其他操作。

为了不让用户错过，这次做了一个格外醒目的浮层，并配上声音和闪烁效果。

回到了 HTML，对抗优势就大幅增加了。

尽管攻击者也能模拟鼠标点击，但是，光点击是远远不够的 —— 鼠标不可能一出来，正好就在关闭按钮上吧，肯定还得先移进去。

因此，还统计了鼠标 move、over、out 等事件。如果次数特别少，也是极其可疑的。

类似的行为分析方式，还有不少。配合独特的思路，陆续更新直到最后。

其他对抗

当然，并非所有攻击，都从脚本着手的。

还是有不少喜欢简单暴力的 —— 网络攻击。尤其那台“授权服务器”，自然成了众矢之的。

使用传统的负载均衡？简单，但不隐蔽。攻击者只需跟踪域名，既可遍历出 IP。

为了隐蔽，于是将 IP 列表写在脚本里，让脚本程序来负载。而脚本，是经过加密混淆的。

这样，又把攻击者带回“前端黑魔法”这个坑里了！

当然，“授权服务器” 的实际 IP，在网页运行时还是能够观察到，只是麻烦一些。

同时，结构上也进行一些策略优化。

例如，在游戏服务器上，也开了一个“授权服务”。

平时拦截未开启时，可直接走这条“绿色通道”；只有走不通时，才通过“授权服务器”中转。

这样，就大幅降低对“授权服务器”的依赖！

当然，这么做也有弊端：授权服务的逻辑泄露了。所以，防火墙的部分模块，也做了一些加壳处理。

结束

随着前端技术日趋成熟，优势大不如从前。而且对黑科技的淡却，以及其他工作，逐渐减少了更新。

到了大学结束前，已彻底放弃了更新。

虽然其中趣事还有不少，但这是最长、最有科技的一段。不，并没有什么高级技术，除非“思路”也算。

前前后后绝大多数的时间，都花在“想”上面，“码”的过程少之又少。

当然，这其中也想过一些其他类型的 “JavaScript 防火墙”，例如“跨站防火墙”、“流量劫持防火墙”等等。后来也都变成了现实，用在了工作之中。

用前端脚本玩转安全防御，从那一刻起，持续至今。

后记：关于 JS 前端加密与混淆的方案，可以查看：https://github.com/EtherDream/myppt/blob/master/前端加密与混淆.pdf

巴特西