巧用BIND，设置DNS放大攻击可信任源(图文)

一、DNS 放大攻击概述

（一）攻击原理简述

DNS 放大攻击主要是攻击者利用了 DNS 服务器的一些特性来达到放大攻击流量的目的。通常情况下，攻击者会通过僵尸网络中的被控主机，将带有欺骗性 IP 地址的查询请求发送出去，也就是把原本应该是自己真实源 IP 地址伪装成被攻击目标的 IP 地址，然后向那些允许递归查询的 DNS 服务器发送大量的 DNS 服务请求。
这些请求往往是经过构造的，目的在于让 DNS 服务器返回尽可能大的响应。因为 DNS 查询一般是通过 UDP 协议传输，UDP 协议属于一种 “发即忘” 的协议，不需要像 TCP 协议那样通过握手来验证数据包 IP 地址的真实性，所以攻击者可以轻易地伪造数据包的报头，让 DNS 服务器误以为请求来自被攻击目标。
而 DNS 服务器收到这些查询请求后，会按照正常流程进行处理并返回相应的应答数据，关键在于其查询应答数据包通常会比查询请求数据包大数倍，比如攻击者发出一个仅有几十字节的查询请求，而 DNS 服务器返回的响应数据包可能达到数千字节。这些放大后的响应数据都会被发送到被攻击主机处，大量这样的流量汇聚起来，就会让被攻击者的源服务器不堪重负，最终因泛滥的流量导致服务器资源被耗尽，无法提供正常服务，甚至陷入瘫痪状态，从而实现攻击者发起拒绝服务攻击的目的。

（二）常见攻击场景举例

在现实网络环境中，DNS 放大攻击造成过不少严重影响，例如针对 Cloudflare 网络的大型攻击事件。美国时间 6 月 19 日周四深夜（北京时间周五），旧金山有一群人整夜待在 Cloudflare 的办公室里待命，随时准备应对即将到来的网络大战。早在投票前几天，PopVote 投票网站（popvote.hk）就遭受到一波大规模 DDoS 攻击，为了避免影响正式投票，PopVote 网站向 Cloudflare 求助。
然而投票一开始，PopVote 网站还是陆续遭遇了超大规模的 DDoS 攻击，其攻击流量为史上第二高，连 Amazon 或 Google 这样的大型网络服务提供商都难以抵挡。这次攻击中就包含了大量的 DNS 反射及 NTP 反射攻击封包，其中 DNS 反射攻击流量每秒超过 100Gb，而该网站还遭遇到了每秒高达 2 亿 5 千万次的有效 DNS 请求，甚至未经放大，DNS 请求就有高达每秒 128 Gb 的网络流量，最终靠着多家网络业者联手，才撑过了这段投票时间。
此外，还有欧洲反垃圾邮件组织 Spamhaus 曾对外宣称遭受 300G 流量的 DDoS 攻击，后来分析此次攻击使用了 DNS 反射放大攻击。攻击者发出的 DNS 请求数据包仅为 36 bytes，而 DNS 服务器的响应数据包长达 3000 bytes，通过这样的方式，攻击者将攻击流量放大了近 100 倍，使得合法用户无法访问到 Spamhaus 的网站系统，对其正常业务运转产生了极大的阻碍。这些案例都充分说明了 DNS 放大攻击在实际网络环境中所具有的强大破坏力以及可能造成的严重危害。

二、BIND 与 DNS 放大攻击的关联

（一）BIND 在 DNS 服务中的地位和应用情况

BIND（Berkeley Internet Name Domain，伯克利 Internet 名字域）作为一款常用的开源 DNS 服务器软件，在域名解析领域有着举足轻重的地位。
从功能方面来看，它能够维护着一个地址数据库，其中记录了各种主机域名与 IP 地址的对应关系，以此为客户程序提供正向或者反向的地址查询服务，也就是我们常说的正向解析（根据主机名称，即域名查找对应的 IP 地址）以及反向解析（根据 IP 地址查找对应的主机域名）。例如在日常网络访问中，当用户在浏览器输入如 “www.baidu.com” 这样的域名时，就是依靠像 BIND 这类 DNS 服务器软件进行解析，将便于人们记忆的域名转换为计算机能够识别的 IP 地址，从而让用户顺利访问到对应的网站资源。
在应用场景上，BIND 的适用范围极为广泛。它可以运行在大多数 Linux/Unix 主机中，许多网络服务提供商、企业内部网络以及互联网数据中心等都会采用 BIND 来搭建域名服务器。比如在构建缓存域名服务器时，它只提供域名解析结果的缓存功能，目的在于提高查询速度和效率，虽然没有自己控制区域的地址和数据，但可以指定根域或其他 DNS 服务器作为解析来源；主域名服务器则会维护某个特定的 DNS 区域的地址数据库，对其中的解析记录具有自主控制权，是指定区域中唯一的权威服务器、官方服务器，需要自行建立所负责区域的地址数据文件；还有从域名服务器，它与主域名服务器提供完全相同的 DNS 解析服务，通常用于 DNS 服务器的热备份。总之，BIND 凭借其强大且灵活的功能特性，满足了不同网络环境下域名解析的多样化需求。

（二）BIND 面对放大攻击的脆弱性分析

尽管 BIND 有着诸多优点，但在安全方面，它容易遭受 DNS 放大攻击，这背后存在着一些原因。
首先，BIND 的默认配置存在一定的局限性。例如在一些版本中，其对于请求来源验证方面不够严格，由于 DNS 查询一般通过 UDP 协议传输，而 UDP 协议属于一种 “发即忘” 的协议，不需要像 TCP 协议那样通过握手来验证数据包 IP 地址的真实性，这就导致攻击者可以轻易地伪造数据包的报头，把原本应该是自己真实源 IP 地址伪装成被攻击目标的 IP 地址，向 BIND 服务器发送大量构造好的 DNS 服务请求，而 BIND 服务器在默认配置下很难直接识别出这些虚假请求的来源。
另外，以曾经出现过的 CVE-2020-8616 漏洞为例，当 DNS 递归服务器在处理 DNS 请求时会向权威服务器请求解析结果，权威服务器可能会进行子域名委派，而 BIND 的原始设计并未充分限制处理委派响应的查询次数。恶意攻击者就可以利用这样的漏洞给 DNS 递归服务器回复一个巨大的委派列表，达到降低 DNS 递归服务器的性能，进而造成 DNS 放大攻击的情况。而且在实际网络环境中，如果没有针对性地进行安全策略配置和版本更新，BIND 服务器面对这种利用其自身功能特点发起的放大攻击时，就会显得比较脆弱，一旦遭受攻击，大量的放大后的响应数据会发往被攻击主机处，使被攻击者的源服务器因泛滥的流量导致资源被耗尽，无法提供正常服务，甚至陷入瘫痪状态。

三、可信任源设置的重要性

（一）开放解析器带来的风险

在网络环境中，开放的 DNS 解析器犹如一扇未加锁的大门，给攻击者留下了可乘之机，成为发起 DNS 放大攻击的关键因素，其带来的风险不容小觑。
开放 DNS 解析器不会对请求来源进行过滤，它会接受来自所有 IP 的查询。比如在日常网络中，那些配置不当、被错误设置成向互联网全面开放的 DNS 服务器，就属于开放解析器。攻击者可以利用这一特性，通过僵尸网络中的被控主机，将带有欺骗性 IP 地址（把原本自己的真实源 IP 地址伪装成被攻击目标的 IP 地址）的查询请求发送给这些开放的 DNS 解析器。然后按照构造好的方式向其发送大量的 DNS 服务请求，目的在于让 DNS 服务器返回尽可能大的响应。
由于 DNS 查询大多是通过 UDP 协议传输，UDP 协议本身是一种 “发即忘” 的协议，不需要像 TCP 协议那样通过握手来验证数据包 IP 地址的真实性，所以攻击者伪造数据包报头的行为很难被直接识别出来。DNS 服务器收到这些虚假请求后，会按照正常流程处理并返回相应的应答数据，而这些应答数据往往比查询请求数据包大很多倍，像攻击者发出一个几十字节的查询请求，服务器返回的响应数据包可能达到数千字节。
最终，这些放大后的响应数据都会被发送到被攻击主机处，大量这样的流量汇聚起来，就会让被攻击者的源服务器不堪重负，可能因泛滥的流量导致服务器资源被耗尽，无法提供正常服务，甚至陷入瘫痪状态，从而成功实现攻击者发起的拒绝服务攻击，给个人、企业乃至网络服务提供商等带来严重的损失和影响。

（二）可信任源对防御的意义

面对 DNS 放大攻击的潜在威胁，设置可信任源就如同为网络安全筑起了一道坚固的防线，有着极为重要的防御意义。
通过精准地设置可信任源，我们可以有效缩小攻击面。网络中，每天都会面临各种各样来源不明的 DNS 查询请求，如果不对其进行限制，就相当于对所有潜在的威胁敞开怀抱。而可信任源的设置，就像是给网络设置了一个 “准入门槛”，只有那些来自被认可、被信任的源头的 DNS 查询请求，才能够进入到我们的 DNS 服务器进行处理。例如，企业内部网络可以将本企业内的办公设备 IP 地址段设置为可信任源，那么来自外部网络、未经授权的 IP 发起的 DNS 查询请求，就会被直接拦截在外，避免其进入到内部的 DNS 服务器中，从源头上杜绝了非法请求可能带来的风险。
这样一来，那些试图利用 DNS 放大攻击进行破坏的攻击者，就难以通过伪装 IP 等手段，借助开放解析器来向我们的目标服务器发送恶意的查询请求，进而获取放大后的攻击流量了。而且，这一举措能保障网络资源合理分配和高效利用，让服务器可以将更多的精力和资源用于处理正常、合法的业务请求，确保网络的稳定运行，为用户提供安全可靠的网络服务体验，全方位保障网络安全。

四、BIND 中可信任源的具体设置要点

（一）rate-limit 功能的运用

在 BIND 中，rate-limit 功能对于防御 DNS 放大攻击等恶意行为起着重要作用。首先来说说它在不同版本中的支持情况，在 BIND 9.10-p1 稳定版中，对 rate-limit 默认支持，而在 BIND 9.9 的扩展支持版本中，该功能处于开发状态，需要在编译安装的时候通过执行 “./configure --enable-rrl” 命令来开启 rate-limit 功能。
要运用 rate-limit 功能，通常需要在 named.conf 配置文件里添加相关参数进行设置。例如以下这种常见的配置方式：

options{
……
rate-limit {
ipv4-prefix-length 32;
window 10;
responses-per-second 20;
errors-per-second 5;
nxdomains-per-second 5;
slip 2;
};
……
};
下面详细介绍一下各参数的含义：

• ipv4-prefix-length：用于配置 IPV4 地址块的长度，它可以指定如何划分地址块来统计响应情况，默认值为 24，比如可以根据实际网络布局设置成 32 等合适的值，通过这个参数来界定哪些地址范围的请求按同一个 “客户端” 的情况去统计响应限制等。

• window：指的是速率的测量周期，单位是秒，像设置为 10 意味着在每 10 秒这样一个时间段内去衡量响应速率等情况，以此来判断是否超出设定的限制。

• responses-per-second：限定每秒允许的正常响应数量，例如设置为 20 ，就是说每秒针对相应的请求，允许返回的正常响应最多为 20 个，如果超过这个数量，可能会按照规则进行相应处理（比如丢弃等）。

• errors-per-second：主要是限制例如 SERVFAIL 和 FORMERR 等 DNS 错误的响应速率，避免大量错误响应造成网络拥塞或者被恶意利用，设定具体数值后，每秒超过这个数值的对应错误响应会受到限制。

• nxdomains-per-second：针对所有 NXDOMAIN 错误的响应进行每秒的数量限制，防止因大量不存在域名（NXDOMAIN 情况）的查询响应影响服务器性能或者被用于放大攻击等场景。

• slip：这个参数也在整个速率限制的规则体系中有其作用，帮助更精细地控制响应的一些行为逻辑。

大家可以参考 bind 手册 Page53-P59 的说明情况，进行更深入、更贴合自身网络环境需求的配置，合理运用 rate-limit 功能来保障 DNS 服务的安全稳定，抵御放大攻击带来的风险。

（二）iptables 的辅助设置（若适用）

iptables 作为 Linux 系统上默认的防火墙管理实用程序，在不想升级 BIND 或者将其作为补充防御手段时，可以通过设置相应规则，来进一步防止 DDOS 和放大攻击。
例如以下这组常用的规则示例：

iptables -A INPUT -p udp --dport 53 -m recent --set --name dnslimit
iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP
其原理就是，第一条规则 “iptables -A INPUT -p udp --dport 53 -m recent --set --name dnslimit”，它会对通过 UDP 协议且目标端口为 53（DNS 服务常用端口）的进入流量进行标记，设置名称为 “dnslimit” 的相关记录。而第二条规则 “iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP” 则是在后续的判断中，如果在 60 秒内，命中（满足条件的流量达到）11 次，就会执行 DROP 操作，也就是直接丢弃这些流量，以此来防止短时间内大量可疑的 DNS 相关流量冲击服务器，避免可能的放大攻击等恶意行为对服务器造成影响。
此外，还可以有更多定制化的 iptables 规则设置来应对不同场景的攻击威胁，比如根据源 IP、目标 IP、不同的协议类型等多维度去构建规则体系，像可以针对特定的 IP 段进行限制访问，只允许信任的 IP 段向 DNS 服务器发起请求等，具体的规则构建需要依据实际网络环境的安全需求以及网络拓扑结构等因素综合考量来进行灵活配置，从而更好地配合 BIND 守护网络安全，增强对 DNS 放大攻击等的防御能力。

（三）其他配置选项说明

除了上述提到的 rate-limit 以及利用 iptables 进行辅助防御外，还有一些其他配置选项对于构建可信任源的防护体系也至关重要。

限制递归

递归查询功能在方便用户进行域名解析的同时，也可能被攻击者利用，成为 DNS 放大攻击的突破口。在 BIND 的配置中，可以通过 “recursion” 这个参数来控制是否允许递归查询，例如在某些场景下，如果服务器不需要为外部网络提供递归查询服务，可以在 named.conf 配置文件里进行如下设置：

options {
……
recursion no;
……
};
这样就关闭了递归查询功能，让服务器只进行迭代查询，返回根 DNS 信息，从一定程度上减少了遭受放大攻击的风险。当然，如果服务器还想为特定 IP 段的查询提供递归功能，可以这样设置：

options {
allow-query { any; };
allow-recursion { corpnets; };
};
也就是通过 “allow-recursion” 参数指定允许进行递归查询的 IP 范围（此处 “corpnets” 可替换为实际信任的 IP 网段等），实现更精准的访问控制，既满足内部合法用户的需求，又避免被外部恶意利用。

设置允许查询的 IP 范围

可以使用 “allow-query” 参数来限定允许查询 BIND 服务的客户端 IP 地址或网段，构建起可信任源的重要防线。比如在企业内部网络环境中，只希望内部办公设备能够访问公司内部的 DNS 服务器进行域名解析，可以进行如下配置：

options {
……
allow-query { 192.168.1.0/24; }; //这里以192.168.1.0/24网段为例，可替换为实际企业内部IP网段
……
};
这样一来，来自外部网络未经授权的 IP 发起的 DNS 查询请求，就会被直接拦截在外，从源头上杜绝了非法请求可能带来的风险，保障 DNS 服务的安全性和稳定性，让服务器资源能够更合理地被用于处理合法的业务请求，全方位抵御 DNS 放大攻击等威胁。
通过综合运用这些配置选项，从多个角度、多个层面去打造可信任源的防护体系，才能更有效地保障基于 BIND 的 DNS 服务在复杂网络环境中的安全可靠运行。

五、设置后的效果检测与维护

（一）检测设置是否生效的方法

在完成 BIND 中可信任源的相关设置后，我们需要对设置是否生效进行检测，以确保其能达到预期的防御 DNS 放大攻击的效果。下面为大家介绍几种常用的检测手段。
其一，查看相关日志。BIND 服务器自身会生成详细的日志记录，其中涵盖了各类 DNS 请求、响应以及可能出现的异常情况等信息。我们可以通过查看这些日志来确认可信任源设置是否按预期在工作。比如，在 Linux 系统下，BIND 的日志文件通常位于特定的目录中（具体路径可通过配置文件中的相关参数指定，默认一般在 /var/log 等目录下），使用如 “tail -f [日志文件名]” 这样的命令来实时查看日志内容。若我们设置了只允许特定 IP 段作为可信任源进行查询，那么在日志中就应该只能看到来自这些被允许 IP 的正常查询记录，而来自其他未授权 IP 的查询请求如果被拦截，日志里会相应地出现拒绝访问等提示信息，以此来判断可信任源的限制是否生效。
其二，进行模拟攻击测试。当然，这里的模拟攻击测试是在合法且可控的范围内进行的，目的在于检验我们设置的可信任源能否有效抵御外部的恶意查询。可以利用一些专业的网络测试工具，例如向 DNS 服务器发送模拟的 DNS 查询请求，将源 IP 伪装成不同的地址，一部分是我们设置的可信任源 IP 段内的地址，另一部分是外部未经授权的 IP 地址。观察服务器的响应情况，如果对于来自可信任源 IP 的请求能够正常处理并返回正确的解析结果，而对于那些非可信任源的恶意伪装请求能够按照我们设置的规则进行拦截（比如直接丢弃请求、返回错误提示等），那就说明可信任源设置已经起到了相应的防御作用。不过要注意的是，模拟攻击测试需要谨慎操作，避免对实际的网络环境和正常业务造成不必要的影响，测试前最好在小范围的测试环境中先进行验证，确保无误后再应用到正式的网络环境中。
通过以上这些检测方法，我们就能较为准确地验证可信任源设置是否达到了预期的防御效果，保障网络安全稳定运行，减少 DNS 放大攻击带来的潜在风险。

（二）定期维护与更新的要点

网络环境并非一成不变的，为了保证 BIND 中可信任源设置持续有效地发挥防御 DNS 放大攻击的作用，我们需要对其进行定期的维护与更新，以下是一些关键的要点。
首先，要关注网络环境的变化。随着企业业务的拓展、网络架构的调整或者新增办公设备等情况的出现，原本设置的可信任源 IP 段可能就需要相应地进行扩充或修改。例如，企业新开设了一个部门，新增了一批办公电脑，这些电脑的 IP 地址如果不在之前设置的可信任源范围内，就会导致它们无法正常进行 DNS 查询，影响工作效率。所以，网络管理员需要及时了解这些网络环境的变动情况，对可信任源的 IP 范围进行合理的调整，确保合法的内部设备能够正常访问 DNS 服务器。
其次，BIND 软件本身也会不断更新迭代。新版本的 BIND 可能会修复一些旧版本存在的安全漏洞，或者对相关功能进行优化和改进，这其中就可能涉及到与可信任源设置相关的部分。比如，某个版本更新后对 rate-limit 功能的参数计算方式进行了微调，或者对 IP 地址验证机制做了优化，那么我们之前所做的可信任源设置就需要根据新版本的特性进行重新检查和适配，避免因软件版本差异而出现设置失效的情况。因此，要及时关注 BIND 的官方更新信息，在有新版本发布且经过测试评估可行后，尽快对服务器进行软件升级，并同步更新可信任源的相关配置。
另外，网络安全威胁也是在不断演变的，攻击者可能会想出新的手段来绕过现有的防御机制。我们需要定期回顾可信任源设置的有效性，结合网络安全领域出现的新趋势、新攻击方式，判断当前的设置是否还能满足防御需求。如果发现存在潜在的安全风险，就要及时对可信任源设置进行强化，比如增加额外的限制条件、细化 IP 段的划分等操作，全方位保障
 

墨者安全 防护盾

墨者安全作为专业级别安全防护专家，在应对 Webshell 风险隐患方面展现出了卓越的能力。其拥有全面的检测机制，能够精准识别 Webshell 的各种类型和变体，无论是复杂的大马，还是隐蔽的内存马，都难逃其敏锐的监测。
墨者安全防护盾具备强大的实时监控功能，对服务器的各项活动进行 7*24 小时不间断的监视。一旦发现任何可疑的 Webshell 活动迹象，立即发出警报，并迅速采取隔离和清除措施，将风险扼杀在萌芽状态。
在防护策略上，墨者安全防护盾采用了多层次的防御体系。不仅能够在网络层面阻挡外部的恶意访问和攻击，还能深入系统内部，对服务器的文件系统、进程等进行深度检查和保护，确保 Webshell 无法植入和运行。
同时，墨者安全防护盾拥有快速的应急响应能力。当 Webshell 攻击事件发生时，专业的安全团队能够迅速介入，进行深入的分析和处理，最大程度减少攻击带来的损失，并帮助用户快速恢复服务器的正常运行。
墨者安全防护盾还注重用户教育和培训，为用户提供关于 Webshell 防范的专业知识和最佳实践，帮助用户提升自身的安全意识和防范能力，共同构建坚实的网络安全防线。