漏洞发生在BIND分析接收到的query数据包阶段,因此对于BIND来说没有任何workaround,除了打补丁。
在F5 GTM上,被攻击的现象是,named会被重启,同时产生一个named的dump文件,日志类似如下:
1 2 3 |
Aug 13 17:40:27 ltm3900 notice logger: Started writing core file: /var/core/named.bld1.0.117.core.gz for PID 16599 Aug 13 17:40:28 ltm3900 notice logger: Finished writing 4211174 bytes for core file: /var/core/named.bld1.0.117.core.gz for PID 16599 Aug 13 17:40:31 ltm3900 emerg logger: Re-starting named |
若攻击不是持续发生,理论上GTM智能解析不会受到影响,当然如果那个时候必须需要BIND返回消息的解析则会在crash期间受到影响,但named重启后则解析恢复正常。
防范:
首先F5有一篇SOL,请查看
https://support.f5.com/kb/en-us/solutions/public/16000/900/sol16909.html
需要说明的是,如果你的GTM还担任着除wideip以外的解析,例如MX,其他域名(就是说你必须依赖GTM 设备自身上的BIND的话),SOL上的关闭use bind on gtm 方法并不可行,会影响到正常功能。
在大部分缺省设置的GTM产品上,是直接受到该漏洞影响的。如果你不能及时升级补丁,那么可以使用irule作为防范方法,举例如下:
1 2 3 4 5 6 7 8 9 |
when DNS_REQUEST { if {[string toupper [DNS::question type]] equals "TKEY" }{ #optionally log TKEY request: #log local0. "query [DNS::question name] type [DNS::question type] dropped " #drop <<optionally just drop the connection DNS::header rcode NOTIMPL DNS::return } } |
如果你发现上面irule在你的GTM上无法直接用,可以使用下面这个:
1 2 3 4 5 6 7 |
when DNS_REQUEST { if {[string toupper [DNS::question type]] equals "TKEY" }{ #optionally log TKEY request: #log local0. "query [DNS::question name] type [DNS::question type] dropped " drop } } |
注:上述irule只适用于未使用DNS express功能的客户。如果使用了DNS express功能,与F5工程师单独联系。
文章评论