荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: cfans (cfans.yao), 信区: Homepage
标 题: 网站遭受攻击的一个案例---Zz
发信站: 荔园晨风BBS站 (Mon Nov 19 10:21:38 2007), 站内
前几天，我们的站点的速度忽然慢了下来，接着发生了当机，重新启动后最初访问不错，不
久又慢了下来，数据库服务器方面没有显示有什么巨大压力，并且在网站根目录下创建一个
静态文件，居然访问速度也奇低，由于网站最近正在更新，所以怀疑是不是逻辑有什么问题
，然而和同事交流发现最近并没有更新关键的逻辑，在排除这种可能性后，焦点集中到了攻
击上
可是web服务器端统计数据显示也没有很大的压力，正纳闷的时候，回去想看邮箱里的错误
报告（这是由程序把所有黄页错误自动转发过来的），由于网站经常会被各种程序扫描，扫
描会造成许多无法访问的路径错误，加上访问超时等，这种报告每天都会有7 -800封，所以
一般都忽略掉:)，而今天由于网站奇慢，错误报告瞬间超过了5000多封，邮箱已经无法打开
，后来据同事说，整个公司的邮件服务器都当掉，所以只好请运维人员清空了我们邮箱
幸好本地的outlook中还保留了一些发生问题最初时候的错误邮件，发现有很多
outofmemory错误，都是由一种特定的操作引起的（不妨称为A操作）而这种错误本身并不能
解释问题，因为发生错误的模块是分布在和服务器不同的另外一台机器上，去查了以下这个
操作涉及的资源，（下称为资源B）发现这个资源由于被反复增加内容而巨大无比，而对这
种资源的操作成本是和资源的大小成比例的，而且调用是同步而非异步，也就是虽然整个对
资源的操作过程是在另外一台机器上，但是调用端会一直阻塞等到操作完毕（或者超时）才
会退出
这就造成请求排队的原因.
攻击者就是利用A操作没有时间间隔的限制，反复调用，而使得网站瘫痪
整理逻辑发现，A操作首先是向数据库中插入一条数据，然后更新资源B,开始时候B不大，而
由于请求频繁，数据库的压力大，请求可能有一些排队，但是网站还可以承受，后来随着B
资源的增大，请求开始排队，这时反而数据库的压力反而小了，因为请求都堆在了对资源B
的操作上
再次重启动服务后，果然看到了这个现象，发现数据库开始压力很大(由于B资源已经无法操
作,大概攻击这开始操作其他的资源)
我们在解决的时候，首先在数据库端对A操作加上了时间间隔，数据库的压力立刻降低，然
而请求依然排队，最后在前端也加入了限制，解决了这个问题
对这个问题进行总结
尽量使用异步调用，同步调用一定要注意超期时间：可以看到，虽然对B资源使用了分布式
技术，但是由于其是同步调用，并且超期时间没有设置，所以实际没有利用到分布的优势。
限制操作的间隔时间和处理时间：每次请求处理的时间（包括成功和不成功）如果大于请求
间隔时间，就会排队，适当的排队没有问题，就好象我们排队买火车票，虽然队很长，但是
只要大家都有票，（当然，访问网站不会象买排队火车票一样有耐性），可是当有许多恶意
请求参与排队，比如买票时候前面总是有很多黄牛：），所以我希望有一天所有售票员都可
以识别所有的黄牛，等他走到授票窗口前的时候，授票员就直接告诉他，“滚”，这样就省
去了他买票，后面等待的时间
所以要想办法减低恶意请求的处理时间，一方面是要识别他们，另外就是如果是恶意请求，
就要尽快的返回，能够尽量在前端判断就在前端判断，能多早判断就多早判断，尽量不要拖
到数据层。比如在解决这个问题时，我们就认为1秒内两次执行A操作为恶意操作,并且对时
间间隔的判断在请求一开始就执行。
保护好复杂的逻辑：由于网站业务逻辑日趋复杂，许多操作都会涉及很多资源，这会给攻击
者造成机会，所以大家在设计这些极端复杂操作时要尽量想到上面的问题
不要忽略错误报告：无论错误报告有多长，请不要轻易删除他们，因为他们永远可能是你找
到问题的钥匙
--
※ 来源:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM: 121.15.157.2]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店