【趣事】用 JavaScript 对抗 DDOS 攻击

继续趣事分享。

上回聊到了大学里用一根网线发起攻击，今天接着往后讲。

不过这次讲的正好相反 —— 不是攻击，而是防御。一个奇葩防火墙的开发经历。

第二学期大家都带了电脑，于是可以用更高端的方法断网了。但设备先进反而没有了 GEEK 的感觉。于是，决定做些其他更有意义的事。

一天，几个好友在吐槽，他们的游戏服务器又被打垮了，接着讨论起各种防护方案。

在过去，每当听到防火墙软件时，就觉得毫无卵用。巨大的流量一来，带宽都堵死了，软件又有何用。

不过，大家仍对其寄以厚望。而且还有不少厂商在做，看来，效果总是有一点的。

讨论讨论着，不免又有些蠢蠢欲动。要不，做个防火墙吧，做一个思路完全不同的！

当然，这不是第一次尝试。

初学那会，没有固定的目标。每看见一个小 demo，就想搞个大程序。比如看了 DirectX 就有做游戏的冲动，但不出几天就不了了之。

有段时间对驱动程序产生了兴趣，琢磨起 Windows DDK 里的 demo。当看见 NDIS 中间件这玩意时，顿时起了精神。这不就是一个最底层的包过滤器吗，用来做防火墙，性能自然是极好的。

于是心血来潮，照着其中的样例，改造出一个最简单的 IP 过滤防火墙。为了凸显高性能，硬着头皮看了本数据结构，依样画葫芦写了个哈希表，来更快查询。

然而快归快，没有实际用途，不过是个玩具罢了。

现实中的防火墙，也不可能这么简单的逻辑。肯定还需更高层的协议分析，复杂的策略判断，大量的数据积累。。。当然还少不了无数次的蓝屏调试。

想到这，立马就没有了继续。

然而这一次，决定不再纠结技术层面，而是做一个“另类”的 —— 用最简单的技术，加上巧妙的想法，配合一些独门绝技，来获得出其不意的效果。

考虑到传统的开发人员，对系统、网络都已经非常熟悉，和他们比拼这些，就毫无优势了。

而当时的我，点满了一个和安全毫不相干的技能 —— 网页脚本特效，以及一堆“前端黑魔法”。

但是。。。这。。和网络防御。。。有什么关系？

没有半点关系~~ 想多了。还是考虑正经的吧。

首先想到的，是改造游戏的服务端程序。

毕竟这是“开源”的，肯定能通过修改程序，来加强那脆弱的网络系统。

然而，当看到那密密麻麻的代码、从未用过的语言、完全不熟的调试器，兴致荡然无存。

没兴趣就没想法，果断放弃。

既然如此，那就从客户端试试。

这一次，抱着探索的心情，打开程序，细细揣摩起来。

正当毫无头绪时，突然传来亲切的嚓嚓声 —— 敏感的神经怎能放过，这不是 ie 的专属声音吗。

这才猛然意识到，登录器中内嵌的，不正是一个大大的网页！

有网页，不就可以运行脚本了！

从没想到，居然打起了这个内嵌框的主意~~ 但总算把脚本扯到一起了。

越想越兴奋。现有的防火墙，几乎都是纯服务端的数据分析，能让客户端参与的，应该还很少吧。

“只要在登录器的网页里引一个脚本，就能…”

大家听了，表示可以接受。

有脚本，就可以尽情发挥了。

我们必须让用户运行脚本，才能连上游戏服务器；没运行过脚本的 IP，就一律阻拦。

于是开始构思、整理：

• 当脚本运行时，发送一个请求给 “授权服务器”
• “授权服务器”验证参数之后，将用户 IP 通知给“游戏服务器”上的防火墙，添加到白名单
• “游戏服务器”只允许白名单的 IP 通过（“授权服务器”默认在白名单）

正常用户，这并没影响；但攻击器不会执行脚本，也就无法进入白名单 —— 无论发送什么数据包，都会被拦截。

这样，防火墙的策略，也变得极其简单：仅仅判断数据包的 IP 是否在白名单里。

于是，之前那个简陋的 demo 驱动又被翻了出来。因为功能单一，保证了稳定性。而且是在网卡链路层上拦截，所以有超高的性能。

到此，一个 JavaScript 参与的网络防火墙原型诞生了！

也许你会说，这只是转移了风险而已。把游戏服务器的风险，转移到了网站上。要是网站被打垮，同样无法进游戏。

的确如此。不过相比普通的网络程序，Web 有更多成熟的防御方案，甚至用现成的 CDN，就可以缓解。

因此将普通的 C/S 网络防御，挂靠在了更稳定的 B/S 之上，就无需再造轮子了，节省大量成本。

当然这只是基本雏形。实际应用，还有不少需要考虑的地方。

例如，白名单不能无限增加，得有过期时间；客户端的脚本，也不能只运行一次，得定期触发激活。

….

不过，由于无需考虑兼容性问题，使得开发十分顺利。服务器都是 Win2003；网页运行在 WebBrowser 控件里，都是 ie67 的内核。

几天后功能完成。接着做了个简单的界面程序，将方案进行包装，就开始试用了。

上线后，效果很理想！任何与玩家无关的流量，都进行了拦截。虽然大流量攻击仍无能为力，但各种 CC 攻击就能轻松抵挡住了！

不过，攻击者也绝不会罢休。

况且，前端的一切都是公开的，这个秘密早晚会被发现。

[h1]对抗 v1[/h1]
平静了几个月后，一大波僵尸又来了。

日志显示，短时间内白名单进了大量 IP，这绝不是正常用户的。

显然，已有人发现了这个秘密！

事实上，第一版做的非常简单，甚至连脚本都没混淆。

他们把脚本逻辑，移植到了攻击器里。这样不访问网页，也能变成合法用户了。

至于他们是如何发现的，无从得知。但脑补发现后的心情，一定是这样的：卧槽，原来是在这里，居然这么猥琐~~~~

当然，这是意料之中的事。

新版本早已准备就绪，“前端黑魔法” 也跃跃欲试，决定进行反击。

这次，将脚本进行了加密。

不，不是网上流传的那种加密，而是特殊构造的。虽然看起来差不多：整个程序，套在一个 eval 之中。

懂点 JS 的都知道，把 eval 换成 console.log 之类的，代码就原形毕现了。相信 99% 的人会这么做。

于是，利用大家这个心理，在代码中埋下一陷阱：如果只解密，不 eval，就会出现意外的后果。

eval(

    (function() {

        ...

        T = setTimeout(die, 1)

        ...

        code += 'clearTimeout(T)'

        ...

        return code

    })()

)

在解密过程中，偷偷开启一个定时器：1 毫秒后，进入自杀模式 —— 死循环内存申请！

正常情况下，这并不会触发 —— 因为随后 eval 的代码里，会解除这个定时器；但如果把 eval 换成其他的，就无法执行解除了 —— 炸弹触发！

当时的主流内存还是 1~2G，这会瞬间被吞光，卡到硬盘吱吱作响。

为满足好奇心，想看看有多少人栽进去，因此在死循环之前，还加了日志上报的功能。

那段时间，正好在琢磨一个短信接口。于是，这日志就成了测试内容。

每当有人试图破解脚本时，手机就立即收到了消息，体验了回“尽在掌控中”的感觉:)

当然，就这样结束了吗？

不，还早着呢。

继续观看下一篇