Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

明枪得躲,暗箭也得防

  服务器端限流并不是个简单的问题。服务器要做的不仅仅是把流量给挡下来而已。如果只考虑正常的情况,确实没有什么好扯的。但是除了正常用户外,还有很多的各怀鬼胎的坏人。对正常用户的限流只是所有限流规则中极少数的一部分,更多的规则限流规则是在和坏人做斗争。
  假如我们的服务器支持 n 个连接,并且在服务器允许的连接数满时无差别地拒绝连接。假如原本的 n 个连接都是正常用户,这时候攻击者也发来 n 个连接请求,那么服务器对正常用户的处理能力就降低了一半。所以无差别地拒绝连接是最无脑的做法,如果服务器允许同 IP 下发起大量请求,那么攻击者就能很轻松地造出大量连接把服务器打爆。至少也考虑一下同 IP 请求的情况吧?
  如果外层服务器基于 IP Hash 做转发,对于同 IP 请求还是很容易防下来的。但是攻击者也不是傻逼,一般 CC 攻击还可以通过购买肉鸡,从大量不同 IP 上发起,虽然成本有点高,但如果攻击者着真下这血本怎么办?
  业务是需要登录的话,可以让服务器根据用户来限制请求。因为对于 CC 攻击而言,登录的成本会高出许多,更何况要准备那么多账号需要提前注册。而且如果注册需要手机号绑定之类的话就更加增加了攻击的难度了。但是代理服务器要验证用户身份是一件非常可怕的事情,因为要想对用户鉴权就必须建立连接、从 HTTP 请求头解析用户信息。虽然可以是短连接,但一旦要建立连接就有点压力了。更何况我们还要从某个地方查询到用户是否是真实的,这可能需要通过脚本给七层代理服务器推送一份用户信息表到其内存中。
  还有一个方案是无需授权也可以使用的,只不过效果比较差。实际上防攻击这件事的本质就是防止机器操作。如果攻击者真实雇佣几百万人来同时操作那似乎没有什么方法可以阻止,而且如果是人类用户,就算是被雇来刷的也会偶发性地产生真实转换率嘛。我们要考虑的是如何防止机器操作。比如整个页面上 CDN,至少让访问无阻。当服务器无法处理更多请求时吐出验证码再停止操作,并且对于前端发送过来的请求优先处理验证码正确的那些。
  然而,生成图形验证码是一个 CPU 密集型的操作,服务器是否扛得住?这又是一个挑战。如果可以解决这些问题,还是可以用起来的。就像谷歌搜索,如果使用一个公用代理服务器去访问,由于终端用户有很多同时在使用的,那么就经常就会出验证码。
  道高一尺魔高一丈嘛,防御机制有了之后攻击机制也会越来越多,以上这些方案可以算是常规的吧?将来还有各种我想都没想过的攻击方式给我带来相当大的惊喜呢。
网名:
34.203.245.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^