我刚刚收到来自我的托管服务的滥用投诉：
[2014-04-04 03:30:23 CET] [时间戳：1396575024] [11717182.634230] 防火墙：UDP_IN 被阻止输入=eth0 输出= SRC=我的 IP DST=128.204.203.251 LEN=70 TOS=0x00 PREC=0x00 TTL=118 ID=6181 DF PROTO=UDP SPT=53 DPT=52117 LEN=50
我该如何解决这个问题？
答案1
首先，必须先问清楚数据包是否真的来自您的主机。源 IP 欺骗一直在发生，如果没有上下文，日志条目根本无法说明源 IP 的真实性。
下一个问题是您是否在该主机上运行 DNS 服务器。如果该主机上没有 DNS 服务器，那么他们记录的数据包很可能是伪造的。然后您应该向托管服务提供商解释这一点。
如果您正在运行 DNS 服务器，那么该数据包可能是真实的，但这并不一定意味着有任何理由抱怨它。您必须问自己是否真的需要运行 DNS 服务器。如果您正在运行 DNS 服务器，而您一开始并不需要它，那么关闭它是个好主意，无论是否有抱怨。
现在让我们假设您确实有理由运行 DNS 服务器，并且数据包确实来自您的 DNS 服务器。这是否意味着您需要采取一些措施？
在这种情况下，您应该考虑确保您的 DNS 服务器不会被放大攻击滥用。但是上面的数据包看起来不像是放大攻击的一部分。在放大攻击中，如果您的 DNS 服务器支持，您会看到至少接近 512 字节或 4KB 大小的数据包。记录的数据包只有 50 字节大小，相比之下，这很小。
如果您正在运行 DNS 服务器，则上述日志条目最有可能的解释实际上是防火墙配置错误，从而产生了该日志条目。最有可能的是，发出了真正合法的 DNS 请求，并返回了合法的 DNS 回复。但由于某种原因，防火墙在回复返回之前丢失了连接跟踪条目。
措辞也暗示他们丢弃了数据包，而不是发回 ICMP 错误。ICMP 错误是可用于检测欺骗攻击并激活对策的工具之一。
如果 DNS 服务器采用了所有技术上可行的最佳对策来对抗放大攻击，那么阻止意外的 UDP 数据包而不发回 ICMP 错误就好比是自找麻烦。
我所给出的推理中哪些部分与你的案例相关，这在一定程度上取决于细节。但我希望托管服务提供商在收到正确的部分内容后，能够意识到投诉是无效的。
答案2
源 IP 是您，源端口是 53 (DNS)。看起来您有一个 DNS 服务器，它对外部查询开放。这可能是有意为之，比如为您自己的子域提供 DNS，但它也可能是一个配置错误的 DNS 服务器，可用于 DNS 放大攻击，然后可用于对其他主机进行 (D)DOS 攻击。
因此，最好检查一下您是否需要本地 DNS 服务器，以及它是否应该对外部查询开放。如果您需要可公开访问的服务器来解析您自己的（子）域，请至少确保它不能用于递归查询。
更多信息请查看https://www.us-cert.gov/ncas/alerts/TA13-088A或者http://help.1and1.com/servers-c37684/parallels-plesk-c37703/protect-against-dns-amplification-attacks-a791842.html