继续趣事分享。
上回聊到了大学里用一根网线发起攻击，今天接着往后讲。
不过这次讲的正好相反 —— 不是攻击，而是防御。一个奇葩防火墙的开发经历。
第二学期大家都带了电脑，于是可以用更高端的方法断网了。但设备先进反而没有了 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 攻击就能轻松抵挡住了！
不过，攻击者也绝不会罢休。
况且，前端的一切都是公开的，这个秘密早晚会被发现。
对抗 v1
平静了几个月后，一大波僵尸又来了。
日志显示，短时间内白名单进了大量 IP，这绝不是正常用户的。
显然，已有人发现了这个秘密！
事实上，第一版做的非常简单，甚至连脚本都没混淆。
他们把脚本逻辑，移植到了攻击器里。这样不访问网页，也能变成合法用户了。
至于他们是如何发现的，无从得知。但脑补发现后的心情，一定是这样的：卧槽，原来是在这里，居然这么猥琐~~~~
当然，这是意料之中的事。
新版本早已准备就绪，“前端黑魔法” 也跃跃欲试，决定进行反击。
这次，将脚本进行了加密。
不，不是网上流传的那种加密，而是特殊构造的。虽然看起来差不多：整个程序，套在一个 eval 之中。
懂点 JS 的都知道，把 eval 换成 console.log 之类的，代码就原形毕现了。相信 99% 的人会这么做。
于是，利用大家这个心理，在代码中埋下一陷阱：如果只解密，不 eval，就会出现意外的后果。
eval(
(function() {
...
T = setTimeout(die, 1)
...
code += 'clearTimeout(T)'
...
return code
})()
)在解密过程中，偷偷开启一个定时器：1 毫秒后，进入自杀模式 —— 死循环内存申请！
正常情况下，这并不会触发 —— 因为随后 eval 的代码里，会解除这个定时器；但如果把 eval 换成其他的，就无法执行解除了 —— 炸弹触发！
当时的主流内存还是 1~2G，这会瞬间被吞光，卡到硬盘吱吱作响。
为满足好奇心，想看看有多少人栽进去，因此在死循环之前，还加了日志上报的功能。
那段时间，正好在琢磨一个短信接口。于是，这日志就成了测试内容。
每当有人试图破解脚本时，手机就立即收到了消息，体验了回“尽在掌控中”的感觉:)
当然，就这样结束了吗？
不，还早着呢。
继续观看下一篇
