我们在 Linux 机器上运行面向公众的递归 DNS 服务器。我们曾遭受过 DNS 放大攻击。是否有任何推荐的iptables规则可以帮助缓解这些攻击？
显而易见的解决方案就是将出站 DNS 数据包限制在一定的流量水平。但我希望找到更巧妙的方法，以便攻击只阻止到受害者 IP 地址的流量。
我搜索过各种建议，但似乎都是“不要运行面向公众的递归名称服务器”。不幸的是，我们陷入了一种境地：如果我们不这样做，那些不容易改变的东西就会被破坏，而这要归咎于十多年前在这些攻击成为问题之前做出的决定。
答案1
整个事情听起来都像是“不是我的问题”的场景，其实这不是你的错，应该/可以通过采取适当的行动得到 100% 解决，无论它有多“困难”或“艰难”，这就是终止开放的递归服务器。
逐步淘汰：告诉客户该服务器将于 X 日期停止使用。此后，他们需要安装补丁（假设您有补丁）以阻止它使用您的 DNS 服务器。这一直都在发生。系统管理员、网络管理员、帮助台人员、程序员？我们得到它；这种寿命终止的事情一直在发生，因为这是供应商/服务提供商/合作伙伴告诉我们在 X 日期之后停止使用某件产品的标准操作程序。我们并不总是喜欢它，但这是 IT 生活中的现实。
你说你目前的设备上没有这个问题，所以我假设你已经通过固件更新或补丁解决了这个问题。我知道你说过你无法触摸设备，但他们肯定可以吗？我的意思是，如果他们允许这些盒子给你打电话，他们实际上不能那仔细检查谁对他们的设备做了什么；你可以为他们设置一个反向代理，那么为什么不让他们安装一个补丁来修复这个问题呢？告诉他们使用自己的 DNS 服务器您的设备肯定支持 DHCP；我想不出有哪个网络设备（无论多旧/脆弱/奇怪）没有。
如果你做不到这一点，下一步就是控制谁可以访问你的递归服务器：您说“很难说”谁在使用它以及如何使用它，但现在是时候确定并开始丢弃不合法的流量了。
这些是“准军事/政府”组织，对吧？好吧，他们很可能是他们拥有的合法网络块的一部分；这些设备不是动态 IP 背后的家用路由器。找出答案。联系他们，解释问题以及你的情况通过不强制更换固件或产品为他们节省大量资金只要他们可以确认设备将用于访问您的 DNS 服务器的网络块/IP 地址。
这种情况一直都在发生：我有几个客户以这种方式限制医疗合作伙伴的外联网访问或 HL7 监听器；这是没那么难让他们填写表格并提供我应该预期流量的 IP 和/或网络块：如果他们想要访问外部网络，他们必须给我一个 IP 或子网。而且这很少是一个移动目标，所以你不会每天都被数百个 IP 更改请求淹没：拥有自己的网络块的大型校园医院网络有数百个子网和成千上万个主机 IP，它们经常给我一些我应该预期的 IP 地址或子网；再说一次，这些不是一直在校园里闲逛的笔记本电脑用户，那么我为什么会期望看到来自不断变化的 IP 地址的 UDP 源数据包？显然，我在这里做了一个假设，但我敢打赌，对于<100台设备来说，它并不像你想象的那么多。是的，这将是一个冗长的 ACL，是的，它需要一些维护和通信（喘气！）但这是除了完全关闭它之外的第二好办法。
如果出于某种原因，沟通渠道不畅通（或者有人太害怕或懒得联系这些旧设备所有者并正确地做到这一点），你需要建立一个正常使用/活动的基线，这样你就可以制定一些其他策略来帮助（但不能阻止）您参与 DNS 放大攻击。
长期运行tcpdump应该能够过滤传入的 UDP 53 并在 DNS 服务器应用程序上进行详细日志记录。我还想开始收集源 IP 地址/网络块/地理 IP 信息（您的所有客户都在美国吗？阻止其他一切），因为正如您所说，您不是添加任何新设备，您只是为现有安装提供传统服务。
这也将帮助你理解请求的记录类型有哪些、针对哪些域、由谁请求以及请求频率：为了使 DNS 放大按预期工作，攻击者需要能够请求大记录类型（1）发挥功能领域（2）。
“大型记录类型”：您的设备是否需要 TXT 或 SOA 记录才能由您的递归 DNS 服务器解析？您可能能够指定 DNS 服务器上哪些记录类型有效；我相信使用 BIND 和 Windows DNS 是可能的，但您必须进行一些挖掘。如果您的 DNS 服务器响应
SERVFAIL任何 TXT 或 SOA 记录，并且至少那响应比预期的有效载荷小一个数量级（或两个数量级）。显然，您仍然是“问题的一部分”，因为被欺骗的受害者仍会SERVFAIL从您的服务器获取这些响应，但至少您没有打击他们，并且您的 DNS 服务器可能会因不“合作”而从机器人使用的收集列表中“除名”。“有效域”：您可能能够仅将有效的域列入白名单。我在强化数据中心设置中执行此操作，其中服务器只需要 Windows 更新、Symantec 等即可运行。但是，您只是在减轻此时造成的损害：受害者仍会受到您服务器的轰炸
NXDOMAIN或SERVFAIL响应，因为您的服务器仍会响应伪造的源 IP。同样，Bot 脚本还可能根据结果自动更新其开放服务器列表，因此这可能会导致您的服务器被删除。
我也会使用某种形式的速率限制，正如其他人所建议的那样，无论是在应用程序级别（即消息大小、每个客户端的请求限制）还是防火墙级别（参见其他答案），但同样，你必须做一些分析以确保你没有杀死合法流量。
经过调整和/或训练的入侵检测系统（再次强调，这里需要基线）应该能够根据来源或数量随时间检测异常流量，但可能需要定期进行看管/调整/监控以防止误报和/或查看它是否真正防止了攻击。
到最后，你不得不想，所有这些努力是否值得，或者你是否应该坚持做正确的事情，那就是首先消除问题。
答案2
这取决于您想要执行的速率限制类型。
速率限制iptables实际上更适合限制传入数据包，因为达到限制的数据包将与过滤器匹配并应用指定的目标（例如ACCEPT）。您可能对DROP过滤器不匹配的数据包设置后续目标。尽管iptables设置了QUEUE目标，但它只是将数据包传递到用户空间，您需要在其中提供自己的排队应用程序。您还可以限制传出数据包的速率，但很少有人真正想开始丢弃传出流量。
iptables速率限制降低：
iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP
使用hashlimit而不是limit将为您提供每个目标 IP 的速率限制。例如，如果 5 个数据包到达 8.8.8.8 并达到限制，则将阻止数据包发送到 8.8.4.4，而使用hashlimit即使 8.8.8.8 达到最大值，您仍然可以到达 8.8.4.4，这听起来更像您想要的。
如果您不希望超过限制的数据包被丢弃，那么您真正想要的是tc。tc将调节流量以获得良好的稳定流而不是大量突发流量。在传入端，数据包以较慢的速度传送到应用程序，但所有数据包都会按顺序到达。在传出端，数据包将尽可能快地离开您的应用程序，但以一致的流放置在线路上。
我没用过tc太多，但这里有一个例子限制 ICMP 速率您可能可以轻松地将其适应为 DNS。
答案3
您可以采取以下措施来潜在地减轻对欺骗查询的响应，但这需要一些工作：
首先，查看您的安全通道日志并找到正在被欺骗的 IP 地址。
然后使用该源 IP (10.11.12.13) 运行 tcpdump，如下所示：
tcpdump -n src 10.11.12.13 and udp dst port 53 -v -X -S
你会得到类似这样的结果：
18:37:25.969485 IP（tos 0x0、ttl 52、id 46403、偏移量 0、标志[无]、协议：UDP（17）、长度：45）10.11.12.13.51169 > 01.02.03.04.domain: 4215+ 有无？。（17）
0x0000：4500 002d b543 0000 3411 b9d9 0A0B 0C0D E..-.C..4.......
0x0010：0102 0304 c7e1 0035 0019 0e89 1077 0100 .......5.....w..
0x0020：0001 0000 0000 0000 0000 ff00 0100 ...........
现在到了有趣的部分！打开 rfc1035https://www.rfc-editor.org/rfc/rfc1035并转到第 4.1.1 节。
现在是时候翻译 tcpdump 的结果并找出我们可以用来创建数据包级过滤器的模式了。
标题的 ID 从 0x1C 开始，因此我们在 0x1E 处有一些标志，在 0x20 处有一些 QDCOUNT，在 0x22 处有一些 ANCOUNT，在 0x24 处有一些 NSCOUNT，在 0x26 处有一些 ARCOUNT。
这样，实际问题就出现在 0x28 处，在本例中，NAME 为空 (ROOT)，QTYPE = ANY 为 0xFF，QCLASS = IN 为 0x01。
长话短说，我发现添加以下 iptables 规则可以阻止 95% 以上的请求 ROOT 中任何记录的欺骗查询：
iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP
您的里程可能会有所不同...希望这会有所帮助。
答案4
我会尝试编写一个列表，列出所有依赖于面向外部的递归解析器的客户端。从 DNS 框上一天左右的数据包跟踪开始。从那里开始创建 iptables 规则以允许您识别和授权的流量。默认最终会将流量降至 53/tcp 和 53/udp。如果这破坏了某些东西，请微调您的规则。