拒绝服务(简称DoS)——特别是分布式拒绝服务(简称DDoS)——攻击近来困扰着许多知名企业，从索尼公司到美国银行皆未能幸免。
经年以来，大多数企业都将DoS攻击列为一种可接受范围内的安全风险，因为其发生概率与业务破坏风险类似，相对较低。然而如今，这一类攻击的出镜频率大为提高，进而使得不少机构不得不重新估量其相对危险性。CIO们懊恼于其所带来的收益损失及负面新闻;IT部门也被其导致的应用程序崩溃及额外工作量弄得焦头烂额。
虽然没人能彻底杜绝所有DDoS攻击，但我们仍然有办法减弱其不良影响并使自己的机构尽快从问题中恢复正常。在当下的袭击中，大多数是针对Web应用程序而来——它们只需轻松地发送大量请求，即可让目标Web应用程序应接不暇，进而导致其他访问者无法正常使用。
在这类攻击活动中，大多数攻击者并不在意目标系统及应用程序是否确实崩溃掉了，当然如果崩溃结果真的发生，他们绝对会乐观其成。事实上他们的主要诉求是通过给受害企业挖坑，进而妨害合法用户的正常操作。
如果大家具备适当的监控技术，那么这类攻击活动很容易被揪出来。我们的网络操作中心(简称NOC)将明确反馈运行现状——带宽、每秒请求数量以及系统资源使用情况等各项参数都应显示正常。一旦所有参数在很短或是较短的一段时间中突然增大并既而达到阈值，监控系统将立即发出警报。
一般说来，成熟的机构会立即就此做出反应，例如调动IT团队中合适的技术人员加以处理。管理层也将很快拿到此次站点及应用程序异常事态的通知，同时这种短时间内各项参数急速提升的情况会立刻引起大家的警觉。
此时，除非你的网站上了Slashdot网站的主页，否则最可能的情况一定是DDoS攻击光顾了。恭喜!你现在正式成为DDoS受害者俱乐部中的一员——这些攻击活动的通常起因是那帮家伙不喜欢你的企业政策，当然也可能是有人花钱雇人来阴你。
首先我们要做的是对记录请求信息的日志文件展开分析。你肯定想知道激增的请求到底在请求些啥功能，另外这些请求到底来自何处。通过对新请求与正常请求的对比来判断这到底是汹涌而来的高人气还是切实存在的攻击行为。
要作个聪明人，集中管理日志记录是不可或取的好习惯，这样一来我们就可以立即着手系统分析而不必担心查询请求被淹没在攻击者的请求大潮中。遗憾的是，如果登录服务无法正常运作，那么它可能也处于过载状态下了——这时日志文件可能丢失、你的搜索也可能得不到正确响应。如果攻击已经彻底拿下了你的应用程序，日志文件可能无法从受影响的服务器上传输到登录系统中。这时你必须抢在攻击活动整体展开前进行分析，否则就只能望洋兴叹了。
如果大家需要更多的当前日志信息——而且还同时具备用于托管目标应用程序的冗余系统——可以将其中之一暂时从池中取出、获取日志文件、再将其放回集群当中。这种方式可能会在一段时间内令攻击活动的效果更加明显，但如果不及时拿到日志文件，这帮贼人会在疯狂地扇了我们无数耳光之后瞬间消失，而你再也没机会将其绳之以法了。
一旦我们得到了日志文件，立刻选用自己最顺手的排序工具及分析工具进行处理。我个人的推荐是grep和sed。通过分析，我们可以从日志中找出一些关键性信息，并顺藤摸瓜了解整个攻击的实施过程并加以应对。
首先，我们需要确定此次攻击的实施方式。该攻击是对某个远程系统上未开放的端口发送数据，进而消耗大量防火墙资源吗?还是在搞TCP三路握手，一遍又一遍地索取某个特定的URL?抑或是仅仅简单地向网页服务器发送基础的"Get /HTTP/1.1"指令?
通过企业监控系统，应该有可能对当前负载的所处位置加以锁定。如果大家的防火墙已然失守但网页服务器常未被攻陷，那么结论就是我们遇上了第一类攻击。而如果网页服务器在后方已经被无数处理请求折磨得死去活来——同时防火墙尚能抵挡一阵，但资源占用率已经高于平时——那么可以认定网页应用程序是攻击活动的直接目标。
一旦攻击方式得以确认，我们接下来要做的就是通过日志文件对几个关键因素进行辨别。
通过查看日志文件内容，我们能够判断出攻击工具的实时动态。无论请求指向网页应用程序还是由防火墙在处理，我们观察到的数据都是相同的。
首先，我们要识别出那些违规请求。日志文件中应该可以清楚地留下攻击痕迹，例如大量相似的请求或者以集合形式存在的一类请求。也就是说，其中可能存在上万个尝试访问某个URL的请求或是指向某个无效的端口。
在某些情况下，分布式攻击工具可能会产生不同类型的请求。但是总体来说，我们能够找出来自同一资源且指向另一种相同资源的请求集合——例如日志中记录下的不断向某个不存在的URL发出的请求。由此我们可以判断攻击所使用的请求样式。如果所有攻击节点使用的都是同类请求，我们就具备了掌握攻击者蛛丝马迹并将其从正常流量中区分出来的钥匙。
当我们明确了请求的模式，下一步就是要揪出攻击者。找到那些发送量最高且提交请求最快的攻击节点，这些正是引起麻烦的罪魁祸首，控制住它们能够有效地缓解攻击活动带来的负面作用。换言之，只要了解了攻击请求的通常形式及其来源，我们就能够有效地做出回应。
在攻击活动最猖獗的时期，我常常收到诸如将受影响的资源进行重命名的建议——例如更改URL或是主机名称。这么做可谓正中攻击者的下怀;因为只要他们搞清楚了我们的应对方式，就可以马上重新组织进攻、或是将目标指向新的资源。#p#
这种应对策略只在攻击活动调用了某个合法的网页应用程序URL时才会奏效，而该URL的作用是执行诸如大型数据库查询等资源密集型工作。在这种情况下，修改应用程序、部署确认界面或是执行一套会令攻击者的工具无法解读的重定向操作(例如CAPTCHA或者具备用户确认及重定向功能的Flash应用程序)的确可以减轻攻击造成的影响。然而遗憾的是，在大多数情况下，攻击者会很快改变攻击手段。
大家尝试了上述初始应对措施，下一级防御体系也随之明确：源过滤、连接及速率限制。如果我们能够将主要攻击组件瓦解掉、并让其余部分暂缓生效，攻击活动的不良效果将大打折扣。要想继续犯坏，攻击者部署的各节点必须能够在任何特定的时间段内向我们的生产集群发出超过承载能力的大量请求。只要我们将其中一部分节点堵住，系统负载将立即得到有效降低，这就为大家封堵更多攻击节点、向网络供应商通报问题、迁移服务项目或是静待攻击结束提供了机会。
为了尽量保护好自己的基础设施，大家一定要将过滤系统部署在自己网络中尽可能边缘的位置上。如果我们可以说服自己的网络供应商或者数据中心管理员参与协助，那就非常理想了;因为他们能在设备上提供的过滤系统将提供最佳的屏蔽效果。他们的设备永远领先于我们的实际需求，因此将繁重的过滤工作交给他们可谓再合适不过。
如果大家由于种种原因而不得不在自己的设备上部署过滤系统——或者我们打算在上游供应商回馈结果之前先做点积极的补救工作——边缘设备和逆向工程是我们的切入点。充分调动一切手段屏蔽不良请求并尽可能减少系统遭受的负载冲击。路由器、负载均衡、入侵防御系统、网页应用防火墙甚至系统本身，都能在拒绝请求方面发挥一定作用。
第一道过滤体系应该断开来自攻击者的全部连接，因为它们正是这海量请求的根源。此规则应部署于我们访问控制列表的最高优先级上。当然，我们的边缘设备也不要再接受来自此类接口的数据流量，同时也不要回馈数据包。因为一旦发出回应，攻击者们会迅速将其锁定为额外的攻击目标。
接下来，我们要根据各类源的实际情况设置连接速率限制。这样做的目的在于，一旦某些连入主机的新连接在特定时段内达到限制条件，即会被立刻断开。仔细检查日志文件，并将限制条件设定地略宽于正常访问请求。
如果大家不确定日志中哪些具体条目与攻击者有关、而哪些又是正常的，那么将最大的攻击来源作为出发点将是明智的选择。由于主要攻击来源发出请求的速度远高于平均水平，因此我们可能仍然漏掉了不少多余的请求。别忘了根据实际需要不断进行审查和调整。
此外，大家还可以调整主机及边缘设备，以使其较平时更快终止空闲会话进程进而保持足够的剩余资源。但要小心调整的幅度不能过大——因为这样一来我们可能反而要在建立及关闭连接方面消耗更多的资源。
源屏蔽及速率限制工作完成之后，我们算是已经在减轻攻击活动带来的负面影响方面取得了阶段性进展。如果此时攻击仍没有停止的迹象(且似乎没完没了)，技术团队应该立刻将工作重点放在保护那些尚未被触及的业务之上。
通常情况下，攻击者们会将目标设定为特定的主机、应用程序或是网络。将指向这类资源的流量通过路由引导至其它位置——或是干脆放弃此类流量——确实能够为后端系统减轻负荷，但这同时意味着我们的服务项目也无法正常工作了，这正是攻击者们希望看到的结果。
将受到攻击的服务项目与尚未被触及的其它服务项目隔离开来也是不错的主意。只要大家有能力将受影响的服务从不相关的项目中独立出来，我们就没有理由坐以待毙、看着全套业务系统逐渐陷入瘫痪。
如果大家通过互联网提供服务项目，那么各位实际上都是DDoS攻击的潜在目标。而这种攻击实际到来的可能性，取决于我们各自的经营方式、攻击者的突发奇想以及那些对我们的企业感到不满的人群。尽管无法完全避免，但我们仍有不少措施削弱攻击影响：提高业务能力、部署冗余站点、隔离服务项目以及在攻击来临之前做好充分的应对计划。
【编辑推荐】
