本文讲的是 一次对抗大规模DDoS的真实经历，每个网站都会面对网络攻击。唯一的区别在于，如何建设防御，以及如何进行警报和响应。
在网络上很难找到关于防御黑客攻击的真实案例。一方面，信息披露可能会引发官司，另一方面，披露这些信息往往会导致不良的财务后果，因此各公司往往不情愿分享相关细节。然而，如果我们完全不披露这些故事，会使其它人在不知情的情况下犯相同的错误。如果我们为建立威胁情报共享体系做出贡献，分享网络安全战场上的真实经验，可以让事情变得更好。
乙方是一家SaaS（软件即服务）公司，为大中型企业提供网页内容管理服务。其服务的客户A公司专注于帮助医疗供应商提高运营和财务绩效，A公司为数千家医院和医疗保健机构客户提供服务，管理数十亿美元的开支。
要分析的这次DDoS攻击的规模极大：在攻击高峰时，8600万个用户同时从世界各地的超过10万台主机*问网站（当事方联系了FBI）。当攻击结束39小时后，防护方艰难的取得防御性胜利。下面是事件过程：
疯狂攻击
A公司的年度会议即将召开，会议将有15000人参加。会议的前一天晚上，乙方收到了警报消息。A公司的网站服务器正承载着难以置信的网络流量。需要说明的是，A公司也是一家SaaS提供商，为客户提供数据内容和分析，因此这种程度的访问量会极大地影响该公司的服务质量和信誉。没有多少时间，必需快速做出响应。
所有访问请求都来自百分百合法的URL。所以很难分辨出其中的恶意流量
攻击来源遍布世界各地：北朝鲜、爱沙尼亚、立陶宛、中国、俄罗斯、南美
60%的访问量来自美国本土
攻击者直接解除DNS和攻击IP地址的关联
一开始，防御方使用AWS（Amazon Web Service）Route 53，重新配置了一些文件，然后立即切断了与这些IP地址的通信。在成功抵御了最初的几波攻击后，网络似乎恢复了正常，但事实证明，这只是第一波，而接下来的才是更疯狂的攻击。
当天傍晚，攻击再次发起并直接指向DNS域名，这意味着之前的IP拦截策略不再奏效，眼看着数据流量急剧上升。
放弃还是抵抗
乙方和A公司的首席信息官进行了讨论，最后达成一致意见：决定抵抗到底。作为一家SaaS公司，提供持续、可靠的服务，维持公司信誉是重中之重。双方同意分担预计为数万美元的防御成本，为正义而战。
经过仔细审视第二波攻击，防御方意识到可以立即采取一些缓解措施：
- A公司的业务只面向美国客户，不过也有少部分流量来自国外。因此防御方迅速地建立了一些防火墙规则，这些规则只允许来自美国的流量通过。于是，40%的攻击流量被拒之门外。
- 在AWS（Amazon Web Service）Route 53后面加了一道网络应用防火墙，配置了一些HA代理，这可以为FBI收集大量的登录信息，便于他们进行事后分析工作。
- 调整流量自动缩放的配置。自动缩放会根据接入流量规模大小调整自己的上下阈值。将下阈值调整得比上阈值大得多，这意味着系统在流量变大时会做出合适的反应，但永远不会达到流量下阈值。结果，每个运行的实例都会在服务列表中永续存在，记录完整无损的登录信息，以备FBI分析。
兵来将挡，水来土淹
攻击者放大攻击强度，AWS就放大防御强度。攻击者进一步放大攻击强度，AWS就进一步放大防御强度，这样的情景在第二天反复上演。与此同时，乙方每小时就向A公司的董事会负责人汇报一次情况。
在DDoS攻击的最高峰，共部署了18台大型、计算机能力加强版的HA代理服务器，40台大型网页服务器。网页服务器群特别大，因为尽管阻隔了美国本土外的流量，降低了总数据流量的40%，但剩下的60%来源于美国本土的连接中也包括合法的URL。大多数连接都在访问动态服务，这部分访问记录不太容易抓取。
攻击者的目标是一个非常大型的全球化机构。防御方通过非常稳定的HA代理防火墙和负载均衡配置，部署了高度延展的网页服务器群。然后就是云防护（CloudFront），这是AWS的全球内容分发网络。再然后是Route 53，Route 53是AWS的全球冗余DNS平台。这些设备共同组成了关键基础设施，提供了在每一层上的可扩展性和安全性。
在第二天晚上7点左右，事情开始发生转变。在加强了防御强度后，攻击者并没有进一步增加攻击强度。此时此刻，服务器正承载着来自全球10万台主机的8600万个攻击连接，通过AWS基础设施的流量达到每秒20GB。
攻击者无计可施，只能反复地发动攻击，最后直到完全放弃。事后A公司的首席执行官告诉我们，如果他们的网站托管在自己的数据中心，防御的选择就会非常少，而且可能在攻击开始仅仅八个小时之内就会完全无力应对。
最后核算一下防御成本，本次通过亚马逊网络服务成功进行的这次长达36个小时的防御，费用不超过1500美元。双方平摊的话，各方还不到750美元。
下面是这次在大规模DDoS攻击中存活下来的经验，以及一些可以用来加强数据中心，并保护公司网站的策略：
- 针对DDoS攻击设计、配置、测试你的设备。借助你的托管服务商的经验来进行这些测试，善用他们的援助。
- 确认你的网络环境中的“正常”是什么样子。这样在网络状态进入“不正常”状态时可以即时设置报警。
- 将你面向公共的域名别名化（alias）到内部域名。这可以让你在幕后进行快速响应，并实时做出DNS修正，而不需要依赖第三方服务供应商。
- 学会如何有效地在可能受到威胁的情况下进行DNS修正。经常进行练习。
- DDoS攻击会用到数百个攻击向量，试图耗尽服务器的资源。流量测试会启动许多并行线程，这可能使DDoS攻击更加凶猛。每个测试都至少应当运行三小时，以维持响应时间，但在两次测试之间应留出足够的响应区间。在进行显著性测试、风险悬浮以及取消服务之前应当授予明确的许可。
- 在进行自动放大配置时，不要将CPU负载作为量度。DDoS攻击的最好证据就是接入HTTP请求的数量上升，因此最好将接入连接数作为触发警报的量度。
- 防御规模应当增加得迅速，但下降得缓慢。增加和下降的速度比应当设置为4:1或2:1。这会使系统在应对第一波攻击时响应快速，之后也不需要反复增加规模。特别是在攻击者采取放风筝战术，即撤退后又杀回来的情况下。
- 如果使用AWS弹性负载均衡（AWS Elastic Load Balancing），激活“交叉地带负载均衡”选项。这对于均衡后端服务器群的流量而言是最好选择，会显著地减轻DNS设施上的负载。
安全行业需要集体合作，更好地了解敌人的战术、技术和攻击流程，以在和恶意黑客的战斗中取得先机。
原文发布时间为：四月 28, 2015
本文作者：Venvoo
本文来自云栖社区合作伙伴安全牛，了解相关信息可以关注安全牛。
原文链接：http://www.aqniu.com/industry/7527.html