11.3 增幅的风险
CoAP服务端通常用响应包来回复请求包。响应包可能比请求包大许多。网络攻击者可能利用CoAP节点将一个小的攻击包变为一个大的攻击包,这个过程称为增幅。这就存在CoAP节点利用协议的增幅特性产生一个DoS攻击的风险:由于网络限制,攻击者占据的带宽有限,但通过扩大特性,能够使攻击者突破带宽限制。
由于UDP协议不提供验证请求包中的源地址的方法,因此在使能NoSec访问的节点中,网络攻击者能够访问它,并且能够访问潜在的被攻击者,这就存在风险。网络攻击者只需要将被攻击者的IP地址放在合适的请求包中的源地址中,就能产生定向到被攻击者的更大的包。
作为降低影响的方法,很多受限网络只能产生很小的通信量,这样使得CoAP节点在攻击中不容易被注意。然而,受限网络的有限带宽使得网络本身容易成为增幅攻击中的受害者。
因此,如果请求没有认证,在响应中不能有大的增幅因子。CoAP服务端通过使用CoAP的slicing/blocking模式和大的资源表现采用小的分配来减少为攻击者提供的增幅量。举个例子,对于一个1000字节的资源,一个10字节的请求引起一个80字节的响应(64字节的块),而不是1016字节的响应,这样就相当的减少了提供的增幅。
CoAP也能在请求中支持多播IP地址的使用,这在M2M中是一项重要的要求。多播CoAP请求也许是事故或者DoS攻击的源头,尤其在受限网络中。本规范试图在响应返回时加一些限制来减少多播请求的增幅效果。为了减少恶意使用的可能性,CoAP服务端不能接受没被认证的多播请求,也对潜在的源加上一些多播的边界限制。可能的话,CoAP服务端应当限制对特定资源的多播请求的支持。
在提供POSIX接口API[IEEE1003.1]的通用操作系统中,很难查出一个包是否指向多播地址。很多实现能够知道自己是否已经加入多播组,采用FF0x::1格式指向多播地址的包会产生问题,这种包会被所有IPV6节点接收。实现时必须使用诸如IPV6_RECVPKTINFO[RFC3542]的新的API。
最后更新于
这有帮助吗?