从攻击看设计

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

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

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

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

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

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

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

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

对这个问题进行总结

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

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

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

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

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