不要指望通过连接世界上最好的 DDoS 保护服务，就能 100% 保护您的网站和互联网应用程序免受攻击。这并不是说这些服务的缺点，而是说不同的互联网资源对 DDoS 攻击的抵抗力不同，要使它们达到大致相同的水平可能需要不同的努力、手段和期限。
2017年，我们公司提出将可保护性概念作为抗DDoS攻击的特征。我们想简要指出，可保护性是指互联网资源能够以最少的金钱、时间和精力得到可靠保护，免受DDoS攻击。
在本文中，我们将讨论如何实现通过 API 与基于 HTTP/HTTPS 的协议交互的浏览器、移动应用程序和服务的网站和服务器组件的安全性。
网站保护的具体内容
现代网站是多组件在线应用程序，可为不同类型的客户提供许多不同的互联网服务：来自不同开发人员的 Web 浏览器、移动应用程序以及通过 HTTP 请求和 API 交互的其他在线服务。这些通常是使用各种技术实现的复杂、业务关键型应用程序，包括 10 年前尚未广泛使用的现代技术，例如 AJAX、API、BFF 等。
其架构和技术复杂性的一个不良副作用是，它们通常很容易受到网络风险（包括 DDoS 攻击）的攻击。因此，它们需要受到保护，以抵御在 OSI 模型的不同层进行的攻击：网络层 (L3)、传输层 (L4) 和应用层 (L7)。
此外，所谓的“智能”应用层攻击超出了通常的 DDoS 攻击，近年来变得越来越普遍 - 它们的目的不是查找和利用基于 HTTP/HTTPS 的协议本身中的漏洞（这些协议非常标准），而是查找和利用 Web 应用程序的服务器组件与客户端软件模块和其他系统（例如，与 DBMS 或数据总线）之间某些类型的交互中的漏洞。
要可靠有效地保护 Web 应用程序，需要具备高水平的专业知识。因此，我们建议谨慎选择反 DDoS 服务提供商，不要为了便宜而牺牲保护质量。
互联网应用程序设计阶段该做什么
众所周知，纠正产品生命周期早期阶段的错误是最困难的。特别是，修复即将投入商业运营的软件包中的漏洞比在设计阶段早期及时发现和修复漏洞要昂贵几个数量级。因此，信息安全专家强烈建议与信息安全专家密切合作开发软件产品和系统（包括网站和互联网应用程序），最终节省时间和金钱。
通常，互联网应用在设计阶段都会出现很多错误，导致其无法有效防御 DDoS 攻击。下面是一些典型的例子。
有时，互联网应用程序开发人员会因为某些论点而得意忘形，直接通过其 IP地址设置对其他互联网资源的访问，而不使用 DNS——这些地址已硬性集成到程序代码中。这些地址已硬性集成到程序代码中。替换它们可能会非常麻烦，而且在 DDoS 攻击期间几乎不可能保护它们——对于提供商来说，保护它们需要额外的困难和成本，而这些困难和成本是他们不太可能承担的。
默认情况下不使用标准协议的情况并不少见，例如，当应用程序使用 HTTP 但以非常特殊的方式处理它时：对于交互操作的一部分，应用程序遵循 HTTP，而对于另一部分则不遵循。 因此，反 DDoS 提供商几乎不可能了解哪些流量可以被视为合法，哪些流量不能。 但是，有一种方法可以摆脱这种情况，但在 DDoS 攻击期间直接寻找它的可能性不大，因为需要尽快保护应用程序免受攻击。
请注意，此示例指出了与提供明确的数据包过滤规则相关的另一个问题——反 DDoS 提供商需要这些规则来准确检测合法流量和阻止攻击。
可以将由于不良架构解决方案而产生的漏洞归为一类。例如，互联网应用程序的组件通常相互依赖，以至于如果成功对其中一个组件进行 DDoS 攻击，其他组件要么不可用，要么无法正常运行，从而导致用户感到困惑。减少组件之间的相互依赖性并提供可能性是正确的做法，即使不能通过来自不同子网的不同 IP 地址重复访问功能，至少也可以暂时继续工作并部分替换受攻击组件的功能。以这种方式创建的互联网应用程序对 DDoS 攻击的抵抗力更强。
对应用程序及其安全性进行审核，评估 DDoS 保护的必要性并规划其开发
在开始购买和连接反 DDoS 服务之前，您应该确切了解您的互联网应用程序有哪些组件和资源、哪些组件和资源需要保护以及它们需要什么类型和级别的保护。全面了解您的应用程序将帮助您清楚地描述您的安全要求并确保全面覆盖。
全面覆盖非常重要，因为部分保护可防止 DDoS 攻击，攻击者可找到未受保护的组件并直接攻击它们。为避免明显的保护漏洞，您应注意保护可能发生 DDoS 攻击的所有层：网络（根据 OSI 模型为 L3）、传输层（L4）和应用层（L7）。
为了建立足够完整的保护循环以抵御针对互联网应用程序的攻击，您应该使用专门的服务，这些服务不仅包括防 DDoS 功能，还包括保护 Web 应用程序的防火墙（Web 应用程序防火墙，WAF），这有助于保护应用程序免受“智能”攻击。由于 WAF 本身并非设计用于防御高强度 DDoS 攻击，因此建议将 WAF 和防 DDoS 服务捆绑使用。
为了系统地构建针对 DDoS 风险的应用程序保护，我们建议在初始阶段创建连接和部署路线图，以及中期战略，该战略应考虑到您的互联网应用程序开发计划、DDoS 趋势以及与您相关的风险动态。由于 DDoS 保护是信息安全领域之一，因此协调公司的信息安全发展战略和 DDoS 保护改进计划非常重要。
你需要保密吗？
如果您的互联网应用程序提供金融服务（例如，用于远程银行或支付，它必须符合 PCI-DSS 标准）或支持与个人数据的其他交互，则应考虑在不泄露 SSL 私钥的情况下进行保护。
默认情况下，通常会选择一种更方便的应用程序保护选项——通过披露 SSL 私钥进行保护。但是，如果需要交换财务或机密数据，则应在不泄露私钥的情况下构建保护。这限制了验证应用程序客户端的能力（如何访问、从哪里访问——从哪个浏览器或移动应用程序访问等），但它可以更可靠地保护机密数据。
在组织中，经常会出现某些资源需要在不泄露私钥的情况下进行保护的情况，而对于其他资源来说，这并非绝对必要。在这种情况下，对于第二类资源的安全，最好将保护与公开结合起来，因为这样更有效率，并且可以通过单个请求完成。
在某些情况下，您可以使用混合方法，使用专门为防止 DDoS 攻击而创建的证书密钥对（例如，StormWall 可以使用 Let us Encrypt 服务自动执行此操作）。这样，您可以隐藏真正的私钥，并可以选择使用密钥披露保护。
为反 DDoS 提供商提供明确的攻击过滤选项
为了使反 DDoS 提供商能够清楚地识别哪些流量是合法的，并且能够准确地将其从所有其他数据包中过滤掉而不会丢失合法数据包，必须为提供商提供明确的攻击过滤方法。
正如我们之前提到的，最好在应用程序的设计阶段定义这些功能，并向开发人员详细解释他们将如何检测合法的客户端请求并拒绝非法请求。详细记录这些规则并传递给反 DDoS 提供商非常重要。
如果应用程序已经投入生产，您应该找机会与安全提供商一起讨论并澄清其工作的复杂性，以便他们了解如何过滤您的流量。
需要澄清的是，对于使用非标准交互方法的应用程序（尤其是通过 API 访问的移动应用程序和软件客户端），DDoS 保护通常按如下方式工作。第一步，反 DDoS 服务的机器学习机制揭示应用程序的方案，找出重要的细节，例如合法请求来源的地理位置、标头和交互方法的签名、请求的动态和强度等。第二步是基于此模型构建正常活动模型，未来流量中发生的所有请求都将与该模型进行比较。如果这些请求与正常行为模型匹配，则将其转发给应用程序执行，否则将被阻止。
此方案的关键在于能够区分合法请求和虚假请求。同时，提供商认为恶意机器人尤其会生成非法请求，因此应予以阻止。
如果您作为应用程序的所有者或运营商，没有事先考虑到唯一识别合法客户端的可能性，那么反 DDoS 提供商只能将单个客户端组的可疑高活动或其 IP 地址出现在不受欢迎地址的数据库中作为攻击开始的标志。然而，在这种情况下，反 DDoS 提供商检测恶意活动的能力受到严重限制：聪明的机器人无法在不向应用程序发送大量请求的情况下使应用程序可用，而是迫使它生成大量响应，这些响应的准备和发送会导致性能或带宽耗尽。
为 Anti-DDoS 提供商准备信息
基于互联网应用审计及其信息安全审计所收集的信息，有必要为防DDoS服务提供商准备信息，帮助他们构建可靠有效的防护。
首先，您需要为保护提供商指定非浏览器客户端可以访问您的应用程序的位置列表：移动应用程序、通过 API 访问的服务、AJAX 等。这样，提供商可以更准确地配置检查应用程序客户端的过程并保护他们的请求免受错误阻止。
此外，提供应用程序架构、所用协议以及组件如何与外部系统交互和集成的描述也很有用。这些描述应该足够详细，以便提供商能够清楚地区分应用程序组件和与它们交互的合法客户端模块生成的流量与其他流量。
当移动应用程序或合法机器人访问应用程序时，防御者需要尽可能多地了解它们：它们有哪些用户代理、它们发出的请求类型和标头、它们可能来自哪些合法位置、在正常客户端活动期间来自 IP 地址的请求频率。这些数据可以更好地过滤流量。
顺便说一句，如果提供商本身要求您提供此类详细信息，则意味着它很可能非常专业。相比之下，有不少反 DDoS 提供商只需插入他们的服务，就认为他们的任务完成了。
尽可能向攻击者隐藏有关你的应用程序的信息
一个有充分动机且技术娴熟的攻击者肯定会寻找机会实施成功的攻击，因此，不仅不要给他们机会，而且不要让他们知道攻击是否成功，这一点非常重要。如果不这样做，您的应用程序的信息就有可能变成一整套漏洞。
一旦攻击者找到您的应用程序或其组件的 IP 地址，他们就可以将其作为目标，而仅仅更换 IP 地址（在连接反 DDoS 服务时完成）并不能帮助保护其免受 DDoS 风险，因为互联网资源的 IP 地址很容易计算 - 互联网上有许多工具可以做到这一点。例如，允许您跟踪在 DNS 中注册的域的 IP 地址更改的整个历史记录的工具。其他工具提供了获取与特定域相关联的所有 IP 地址列表的可能性。等等。IP 地址也可以在您的应用程序可能交换的 SMTP 电子邮件数据包的标头中找到。例如，如果安装应用程序的服务器的主机名与网站名称匹配，SSH 将在其横幅中显示它，攻击者可以借助简单的工具确定其 IP 地址。理想情况下，真实服务器的 IP 地址不应从外部可见，无论是通过邮件标头，还是通过开放端口或其他服务。
禁用未使用的服务并关闭不需要的端口
在检查互联网应用程序的互联网安全性时，确定哪些服务和端口被使用以及哪些没有被使用是非常有用的——这些必须关闭。否则，它们遭受攻击的风险仍然存在，而且这种攻击很可能对您和您的反 DDoS 提供商来说都是非常意外的。
此外，一旦连接了保护，非常重要的是仅允许通过反 DDoS 提供商提供的 IP 地址访问网站，并通过正确配置防火墙阻止对所有其他 IP 地址的访问 - 这将防止 DDoS 攻击绕过保护服务。
优化服务器组件
优化对于确保您的互联网应用程序能够抵御弱 DDoS 攻击至关重要。事实上，保护服务无法始终保证 100% 清除不可接受数据包的流量，在这种情况下，一些数据包（即使只有一小部分）可能会通过过滤器泄漏。但是，如果攻击非常强大（例如，如果它达到每秒数十千兆位），那么百分之一的数据包可能足以使您的应用程序无法访问。为了防止这种情况，应用程序的服务器组件及其部署的基础设施必须具有足够高的性能。优化的目标就是提高这一点。
进一步的优化步骤取决于您是否有权访问部署应用程序的服务器。如果您不仅有权访问，而且可以完全控制它，则应该优化操作系统的网络堆栈以提高服务器处理传入请求的能力。特别是，在使用流行的 Web 服务器和 CMS 引擎以及CDN加速时，您需要注意决定服务器性能的参数。此外，如果您的 Internet 应用程序使用 DBMS，您还需要注意优化 DBMS 的性能。
如果您已将应用程序部署在托管服务器或公共云中，则应与云或托管提供商的技术支持讨论优化和性能改进的可能性。您可能需要考虑切换到更强大的硬件或具有大量资源的虚拟机——此措施不仅可以提高应用程序对弱 DDoS 攻击的抵抗力，还可以让您更好地处理峰值负载。
连接受保护的 DNS 服务
在构建针对 DDoS 风险的保护时，当然需要考虑 DNS 受到攻击的可能性，因为如果攻击成功，用户将无法访问您的应用程序，或者应用程序会非常不稳定。有必要检查您的应用程序所连接的 DNS 服务是否受到 DDoS 攻击保护，以及它们的强大程度和可靠性。我们建议至少连接到两个 DNS 服务提供商，其中至少一个应在所有级别（L3/L4 和 L7）受到 DDoS 攻击保护。此类 DNS 服务既可以在反 DDoS 提供商处找到，也可以在专门提供 DNS 服务的公司中找到。其中一个 DNS 服务可以作为主服务连接，另一个可以作为辅助服务连接。
为了以防万一，我们提醒您，StormWall 拥有多种方法来在应用程序级别过滤 DNS 流量。
定期检查保护装置
定期进行压力测试是必要的，这样您就可以验证针对 DDoS 攻击的保护功能和有效性。事实上，攻击的强度和强度都在逐年增加。实施攻击的技术和工具也在不断改进——攻击者不仅增加了僵尸网络的强度，而且还发明了新的攻击类型和方法。此外，您的应用程序也在逐渐变化——版本可能会定期更新，因此也需要定期检查它们对 DDoS 风险的抵抗力。
压力测试通常用于安全测试 - 它们有助于评估应用程序对弱 DDoS 影响的抵御能力，并模拟其在攻击期间的行为。重要的是，压力测试不是正式执行的，而是仔细执行的，以便它们不仅涵盖几乎所有外部可访问的组件，还涵盖其所有服务。这种全面的测试有助于及时识别和消除应用程序中的瓶颈和漏洞，以免它们被入侵者发现。
此外，不仅在正常工作日进行测试是有意义的，在周末、节假日和公共假期前进行测试也是有意义的，因为此时反 DDoS 提供商的技术支持很可能会放松，并且不会发生大规模攻击。同时，还可以检查技术支持对您有关攻击的报告的反应。例如，如果受保护的资源不可用，StormWall 技术支持将联系该资源的所有者，无论该资源当前是否受到 DDoS 攻击。
建立流程以防范 DDoS 攻击
确保针对 DDoS 攻击的防护不仅限于一次性事件，而是以流程的形式建立起来，其次，与其他信息安全流程紧密结合，这一点非常重要。
由于外部网络威胁和应用程序都在动态变化，因此有必要系统地实施确保保护的措施，从系统控制和与反 DDoS 提供商的会议到对应用程序的全面审计和对其信息安全的审计。确保对 DDoS 攻击的保护效果不会降低需要您自己的专业人员和反 DDoS 提供商员工的持续合作。如果您使用他们的服务，您可能还需要云或托管提供商代表的帮助。
此外，还需要将DDoS防护流程与其他信息安全流程紧密结合，包括监控和审计，以及漏洞管理、配置、事件等。
而且由于目前还没有降低DDoS风险的趋势，因此必须做好长期工作的准备以确保防范DDoS攻击。
最终检查清单
- 在设计阶段奠定安全基础
- 对应用程序及其安全性进行审核，评估 DDoS 保护的必要性并规划其开发
- 评估是否需要在不泄露 SSL 私钥的情况下进行保护
- 为反 DDoS 提供商提供明确的攻击过滤选项
- 为 Anti-DDoS 提供商准备信息
- 尽可能向攻击者隐藏有关你的应用程序的信息
- 禁用未使用的服务并关闭不需要的端口
- 优化服务器组件
- 连接受保护的 DNS 服务
- 定期检查保护装置
- 建立流程以防范 DDoS 攻击