朱燚

--书到读透处,酒于微醺时

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::

前几天,我们的站点的速度忽然慢了下来,接着发生了当机,重新启动后最初访问不错,不久又慢了下来,数据库服务器方面没有显示有什么巨大压力,并且在网站根目录下创建一个静态文件,居然访问速度也奇低,由于网站最近正在更新,所以怀疑是不是逻辑有什么问题,然而和同事交流发现最近并没有更新关键的逻辑,在排除这种可能性后,焦点集中到了攻击上

可是web服务器端统计数据显示也没有很大的压力,正纳闷的时候,回去想看邮箱里的错误报告(这是由程序把所有黄页错误自动转发过来的),由于网站经常会被各种程序扫描,扫描会造成许多无法访问的路径错误,加上访问超时等,这种报告每天都会有7-800封,所以一般都忽略掉:),而今天由于网站奇慢,错误报告瞬间超过了5000多封,邮箱已经无法打开,后来据同事说,整个公司的邮件服务器都当掉,所以只好请运维人员清空了我们邮箱

幸好本地的outlook中还保留了一些发生问题最初时候的错误邮件,发现有很多outofmemory错误,都是由一种特定的操作引起的(不妨称为A操作)而这种错误本身并不能解释问题,因为发生错误的模块是分布在和服务器不同的另外一台机器上,去查了以下这个操作涉及的资源,(下称为资源B)发现这个资源由于被反复增加内容而巨大无比,而对这种资源的操作成本是和资源的大小成比例的,而且调用是同步而非异步,也就是虽然整个对资源的操作过程是在另外一台机器上,但是调用端会一直阻塞等到操作完毕(或者超时)才会退出

这就造成请求排队的原因.

攻击者就是利用A操作没有时间间隔的限制,反复调用,而使得网站瘫痪

整理逻辑发现,A操作首先是向数据库中插入一条数据,然后更新资源B,开始时候B不大,而由于请求频繁,数据库的压力大,请求可能有一些排队,但是网站还可以承受,后来随着B资源的增大,请求开始排队,这时反而数据库的压力反而小了,因为请求都堆在了对资源B的操作上

再次重启动服务后,果然看到了这个现象,发现数据库开始压力很大(由于B资源已经无法操作,大概攻击这开始操作其他的资源)

我们在解决的时候,首先在数据库端对A操作加上了时间间隔,数据库的压力立刻降低,然而请求依然排队,最后在前端也加入了限制,解决了这个问题

对这个问题进行总结
尽量使用异步调用,同步调用一定要注意超期时间:可以看到,虽然对B资源使用了分布式技术,但是由于其是同步调用,并且超期时间没有设置,所以实际没有利用到分布的优势。

限制操作的间隔时间和处理时间:每次请求处理的时间(包括成功和不成功)如果大于请求间隔时间,就会排队,适当的排队没有问题,就好象我们排队买火车票,虽然队很长,但是只要大家都有票,(当然,访问网站不会象买排队火车票一样有耐性),可是当有许多恶意请求参与排队,比如买票时候前面总是有很多黄牛:),所以我希望有一天所有售票员都可以识别所有的黄牛,等他走到授票窗口前的时候,授票员就直接告诉他,“滚”,这样就省去了他买票,后面等待的时间

所以要想办法减低恶意请求的处理时间,一方面是要识别他们,另外就是如果是恶意请求,就要尽快的返回,能够尽量在前端判断就在前端判断,能多早判断就多早判断,尽量不要拖到数据层。比如在解决这个问题时,我们就认为1秒内两次执行A操作为恶意操作,并且对时间间隔的判断在请求一开始就执行。

保护好复杂的逻辑:由于网站业务逻辑日趋复杂,许多操作都会涉及很多资源,这会给攻击者造成机会,所以大家在设计这些极端复杂操作时要尽量想到上面的问题

不要忽略错误报告:无论错误报告有多长,请不要轻易删除他们,因为他们永远可能是你找到问题的钥匙

posted on 2007-11-18 23:05  朱燚:-)  阅读(4953)  评论(17编辑  收藏  举报