如何處理濫用投訴？
我剛剛收到來自我的託管服務的濫用投訴：
$$ 2014-04-04 03:30:23 CET $$ $$ Timestamp:1396575024 $$ $$ 11717182.634230 $$ 防火牆：UDP_IN 阻塞IN=eth0 OUT= 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
我應該如何解決這個問題？
第一個必須首先詢問數據包是否實際上來自您的主機。源 IP 欺騙一直在發生，並且在沒有上下文的情況下，日誌條目沒有說明源 IP 的真實性。
下一個問題是您是否在該主機上執行 DNS 伺服器。如果該主機上沒有 DNS 伺服器，那麼他們記錄的數據包很可能是偽造的。然後這就是您應該向託管服務提供商解釋的內容。
如果您正在執行 DNS 伺服器，那麼該數據包可能是真實的，但這並不一定意味著有任何理由抱怨它。您必須問自己是否真的需要執行 DNS 伺服器。如果您正在執行 DNS 伺服器，而您一開始就不需要，那麼無論投訴如何，關閉它都是一個好主意。
現在讓我們假設您確實有理由執行 DNS 伺服器，並且數據包確實來自您的 DNS 伺服器。這是否意味著您需要做一些事情？
在這種情況下，您應該考慮確保您的 DNS 伺服器不會在放大攻擊中被濫用。然而，上面的數據包看起來不像是放大攻擊的一部分。在放大攻擊中，如果您的 DNS 伺服器支持，您希望看到的數據包大小至少接近 512 字節或 4KB。記錄的數據包只有 50 字節大小，相比之下很小。
如果您正在執行 DNS 伺服器，則上述日誌條目最可能的解釋實際上是防火牆的錯誤配置，它產生了日誌條目。很可能有一個真正合法的 DNS 請求發出，而一個合法的 DNS 回復又回來了。但是防火牆由於某種原因在回復回來之前失去了連接跟踪條目。
措辭也暗示他們丟棄了數據包，而不是發回 ICMP 錯誤。ICMP 錯誤是其中一種工具，可用於檢測欺騙攻擊並啟動對策。
如果 DNS 伺服器對放大攻擊採取了所有最好的對策，這在技術上是可行的，那麼在不發回 ICMP 錯誤的情況下阻止意外的 UDP 數據包就像要求被攻擊一樣。
我的推理的哪些部分與您的案例有關，這在一定程度上取決於細節。但我希望託管服務提供商能夠意識到投訴是無效的，當他們看到正確的部分時。