TLS 1.3正式发布,企业应当如何防御DDoS攻击?

0
5357

加密是安全库中最有价值的工具之一。它能够确保我们上网、打电话时的隐私,使我们的个人信息得到安全的存储。加密使我们能够秘密地交换数据,并使我们(在许多情况下)能够验证与我们交换数据的人或物。加密使得我们“信任”这个连接的世界,因为它几乎渗透到了我们生活的方方面面。

然而,众所周知,加密并不能解决所有的安全问题。在勒索软件中,黑客会使用它来对付我们,而且,像最新版的传输层安全(TLS 1.3)这样的加密技术不断进步,识别和阻止部分威胁也将变得更加困难。

过去,许多基于网络的威胁和欺诈检测解决方案都依赖于通过访问服务器私钥对加密会话进行透明、被动的解密。随着TLS 1.3的引入,这就不那么简单了,因为不能从代码行中检索出解密会话所需的所有额外信息。这项技术规定,作为加密流程的一部分,必须使用完善的前向保密(PFS)密钥协议来提高通信的机密性——但这就要求我们重新思考处理另外一些问题的机制。

需要重新考虑的领域是检测和减轻某些形式的DDoS攻击的机制。最新的全球基础设施安全报告(WISR)证实,针对加密web服务的攻击近年来越来越普遍。

具体来说,在2017年,53%的企业、政府和教育机构在应用层检测到了对加密服务的攻击。应用层攻击使用的流量很难与真正的用户流量区分开来,这通常需要对实际的应用层事务进行分析,以确定攻击中涉及的活动模式。由于采用了TLS 1.3,我们必须改变这一流程的工作方式。

密钥共享

一种方式是使用内容分发网络(CDN)服务,因为这些服务可以有效地抵御应用层攻击。一旦加密服务受到了保护,这就意味着服务所有者可能移交或生成私有密钥供第三方提供者使用。无论这是否发生,CDN提供商都将终止并解密其环境中的客户通信,以供检查。这可以让他们减轻应用层DDoS攻击,但围绕机密性的其他风险仍然存在。

有时,这些风险对于终端客户和服务所有者来说是可以接受的,有时则无法接受——这导致了使用网络反向代理来完成工作的第二种选择。

使用自己的反向代理用于负载均衡是很常见的,并且它们自身允许对流量进行检测。在理想的情况下,代理将提供遥测DDoS保护解决方案,因此便可以识别和阻挡攻击主机,从而防止资源在代理上被消耗掉,因为它们是容易受到状态耗尽的DDoS攻击的。

状态耗尽攻击的目标是会话管理的代理能力,不幸的是这种攻击非常常见。通过使用DDoS保护解决方案提前终止反向代理,可以很容易地克服这个问题;DDoS保护解决方案可以识别和阻止状态耗尽攻击以及目标为TLS协商的攻击。

然而,还有第三种选择——被动、透明的解密。但是,等等,我们不是说TLS.3使之变得不可能了吗?事实证明,如果在会话中重复使用静态密钥,并且通过密钥管理平台在网络安全解决方案上共享该静态密钥,然后周期性地循环使用它,那么在使用短暂的Diffie-Helman密码时——就像在TLS 1.3中使用它时那样——被动加密仍旧是可能的。这种机制允许对流量进行透明的解密,以进行威胁识别和阻挡,就像现有的TLS 1.3机制一样。

和所有安全方面的事情一样,不同的解决方案将根据组织的客户需求和当前的监管要求来吸引它们。然而,随着应用层DDoS攻击变得越来越普遍,必须随时准备好合适的解决方案。
加密是必不可少的,PFS无疑提高了我们与这个连接世界的整体交互安全性,但我们必须考虑并克服它对防御堆栈的其他元素的影响。这就要求我们跨组织内的IT、网络和安全团队进行工作,以确保为企业部署了最合适的解决方案。

LEAVE A REPLY

Please enter your comment!
Please enter your name here