每个网站都会受到网络攻击，区别在于你如何提前计划以及你的基础设施如何应对。
我们很难知道网络攻击响应和恢复的真实情况，因为企业都不愿意透露详细信息，毕竟这可能带来负面的财务后果。然而，如果企业不分享自己的故事，其他企业可能会盲目地走上相同的道路。企业应该分享自己的真实经验，并成为提高威胁情报的贡献者。
我们是为中型和大型企业提供Web内容管理的基于SaaS的供应商。我们的客户在全球范围管理着医药和金融服务等行业数百甚至数千个网站。本文中的客户不愿意透露真实名字，他们是一家大型公共医疗服务机构，专注于帮助供应商提高财务和运营业绩。该公司的客户包括数千家医院和医疗服务提供者，管理着数十亿没有的开支。
该公司遭受的DDoS攻击的规模非常大，在攻击高峰期，8600万同时在线的用户从全球10万台主机点击器网站。在攻击39小时候，该公司成功安装了防御措施。下面让我们看看这个攻击过程。
初始攻击向量
在该公司年度会议的前夕，我们收到了一个令人不安的警报。该公司的Web服务器在接收巨量的流量，该公司是内容和分析SaaS提供商，这种流量可能会显著影响服务可用性及该公司的声誉。对此，时间非常紧迫。
在初始攻击向量方面：
· 所有请求都是100%合法的网址，所以我们不能轻易地过滤掉恶意流量
· 攻击来自世界各地，包括朝鲜、爱沙尼亚、立陶宛、中国、俄罗斯和南美
· 其中60%的流量来自美国内部
· 该攻击取消引用DNS，直接攻击IP地址
通过进入到亚马逊的Route 53，重新进行一些调整以及迅速切断到这些IP地址的流量，我们能够成功抵御这些初始攻击向量。一切都恢复正常，我们如释重负，但事实证明这只是第一波攻击，接下来才是真正的攻击。
那天晚上，攻击者又卷土重来，通过DNS名称来攻击网站，这意味着我们不能使用之前采用的相同的IP封锁做法。流量再次大幅度增加。
在这样的时刻你会问自己这样的问题，“我们是等死，还是加强防御?”随后我们与客户首席信息官进行了交谈，我们决定联手加强防御。作为SaaS公司，我们必须提供持续的可靠的服务，这关系到我们的声誉。我们同意与客户共同分担成本(这可能是几万美元)来对抗攻击。
面对第二波攻击，我们意识到我们可以立即部署一些缓解措施：
窗体底端
* 这个公司只有美国客户，但很多流量来自国外。我们迅速部署了一些防火墙规则，只允许美国的流量，这立即阻止了40%的流量。
* 我们在AWS Route 53配置背后插入了Web应用防火墙，并调整了一些HA代理服务器，它会为FBI来收集大量日志信息以事后进行分析。
* 第三，我们特意打破了我们的自动缩放配置。自动缩放具有扩展和缩小的触发器，我们改变了这个触发器，让缩小触发器比扩展触发器更高。这意味着随着更多的流量进来，系统将适当地扩展，但永远不会达到缩小的阈值。其结果是，每个实例都将永久留在服务中，完整保留其日志信息，可提供给FBI。
此时已经是凌晨1点钟，“军备竞赛”已经开始。
DDoS攻击第二天
我们的攻击者已经在扩展，亚马逊云计算[注]服务也在扩展，而攻击者又扩展一些，AWS也扩展一些。这一直持续到第二天。我们向客户的董事会提供每小时更新。
面对这个DDoS攻击，我们有18个非常大型的计算密集型HA代理服务器(+本站微信networkworldweixin)，以及约40台Web服务器。Web服务器群非常大，尽管我们已经排除了非美国的流量部分，还有来自美国内部的60%的合法网址，其中大部分都在访问无法被缓存的动态服务。我们的Web服务器群部署在HA代理防火墙/负载均衡器配置背后，这又位于CloudFront(AWS全球分布式内容分发网络)背后，其本身部署在Route 53(AWS的全球冗余DNS平台)背后。
大约到了晚上7点钟，事情有所转变。我们继续扩展，而攻击者并没有再扩大规模。此时，我们正维持来自全球10万多台主机的8600万并发连接。我们对流量进行了测量，震惊地发现，我们在通过AWS基础设施每秒处理20千兆持续流量。这相当于2014年DDoS攻击中观察到的行业中值的40倍。
攻击者最终放弃了攻击。最后，该公司的首席信息官告诉我们，如果他们在自己的数据中心托管该网站，他们会在攻击的8小时候就无法响应。对于成功应对这个攻击长达36小时，在亚马逊云服务的总成本不到1500美元。
如何应对DDoS攻击
我们成功抵御了这次攻击，因为我们提前有所准备，但这样的经历让我们更加了解如何应对大规模DDoS攻击。下面是保护你的数据中心和企业网站的一些做法：
1. 设计、配置和测试你的基础设施来抵御DDoS攻击。利用托管服务提供商的知识以及他们的协助来设置这些测试。
2. 知道你环境中的正常情况是什么样，当不正常时设置报警。
3. 对于面向公众的域名，在内部域使用其别名。这将让你非常迅速地做出反应，实时做出DNS变更，而不需要依赖第三方服务提供商。
4. 了解在可能有挑战性的情况中如何有效管理DNS变化。
5. 对于来自数百个攻击源的大量多线程请求(以快速耗尽服务器资源)，应该进行流量测试。每个测试运行至少三个小时以维持你的响应时间，然后测试之间保持一定的时间。在进行这些测试之前，应获得明确的许可，因为这可能造成服务的终止或取消。
6. 在构建自动扩展配置时，不要使用CPU负载作为指标。DDoS的好证据是入站HTTP请求数量的增加，所以好设置的警报是“进入网络”触发。
7. 快速扩展，但缓慢缩小，扩展和缩小的阈值比率应该为4:1或者2:1。这可以让你快速响应初始攻击，并减小再次扩展的可能性。
8. 如果使用AWS弹性负载均衡，激活“跨区域负载均衡”选项。这是分配流量的好选择，并显著减少对DNS基础设施的负载。
作为一个行业，我们应该联手合作来更好地了解敌人的战术、技术和程序，以保持领先于坏人。
热门专题
