對 DNS 伺服器的放大反射攻擊
這個詞
Amplified reflected attack對我來說是新的，我有幾個問題。我聽說這主要發生在 DNS 伺服器上——是真的嗎？
你如何防範它？
您如何知道您的伺服器是否可以用於此類攻擊——這是配置問題嗎？
首先，這種攻擊並不（主要）像您的標題所暗示的那樣針對 DNS 本身。它當然會在 DNS 伺服器上產生一些額外的負載，但主要目的是對其他人進行 DDoS。糟糕的伺服器配置可能會使情況變得更糟，但最終這個問題是 DNS 和 UDP 設計中固有的，事實上，任何無狀態通信協議也是如此。
它基本上是這樣工作的：攻擊者將普通的（DNS）查詢發送到（DNS）伺服器。這些查詢被偽造，看起來好像它們來自目標系統。DNS 伺服器現在回答查詢，將答案發送回其所謂的來源——受害者。這就是為什麼它被稱為反射攻擊。
這是可能的，因為您可以像信任明信片上的發件人地址一樣驗證無狀態通信的來源（如基於 UDP 的 DNS）。伺服器無法確定查詢是合法的還是此類攻擊的一部分。DNS 只是這裡最流行的協議，因為它周圍有很多很多伺服器，並且您不需要太多的技術見解或特殊設備來（誤用）它。
讓事情變得更糟（並且完全有攻擊效率），看看放大部分。如果攻擊者的流量與產生的流量大小相等，那將不會造成太大的傷害。攻擊者的唯一好處是他的地址被隱藏在 DNS 伺服器後面。他可以直接偽造發件人地址，完全不需要通過 DNS 重新路由。但是 DNS 的答案，這也是 DNS 在這裡如此受歡迎的另一個原因，它可能比問題大得多。您可以根據使用的確切查詢找到不同的數字，但如果伺服器足夠友好以執行遞歸查詢，它可以上升到1:60為你。所以攻擊者不需要在他控制下的許多機器來產生大量的惡意流量。
由於您可以在公共 Internet 上輕鬆找到成百上千的“開放”DNS 伺服器，因此您可以快速計算一下，如果攻擊者知道的每個開放 DNS 伺服器都會將他的查詢放大 60 倍反映到目標，那麼攻擊者只需要做多少工作。正如我一開始所說，沒有真正好的方法來應對這種情況。由於配置錯誤，許多 DNS 伺服器自然而然地對所有人開放，但它們不應該如此。但是有許多開放伺服器必須開放，因為這正是他們的目的。
雖然您無法判斷請求是否屬於攻擊的一部分，但您唯一的選擇是不再執行伺服器。您可以擺弄速率限制和其他玩具，但您無法完全擺脫這一點。如果您提供 DNS 是為了好玩，您可以將請求的源 IP 列入黑名單。但如果你的規模更大，這會對受害者造成更大的傷害。請記住，您在 DNS 伺服器上只能看到受害者的地址。想像一下，您的公司正在通過您的提供商的 DNS 受到攻擊，而您的提供商決定為您的公司切斷 DNS 服務。攻擊者可以將此作為與拒絕服務相關的無數獎勵積分。
無論如何，這些攻擊整天都在發生，它們被認為是網際網路的“背景噪音”。如果您設置一個公共（遞歸）DNS 伺服器，您很快就會參與隨機攻擊。當然，當大型基礎設施（甚至是 dns 根伺服器）被濫用來放大時，有時事情會變得非常糟糕，但在這種情況下，personell 會採取主動對策，直到攻擊降至“正常”水平。
教學到此為止。最後回答你的問題：
**如果您的伺服器無限制地回答查詢，您就知道它很容易受到攻擊。**時期。如果您提供遞歸查詢，您的伺服器可以為攻擊者生成上述 1:60 的比率。如果它只提供非遞歸服務，那就沒那麼糟糕了，但仍然……
所以…
- 確保您確實需要執行公共DNS 伺服器
- 如果必須，請查看 BIND
allow-recursion和allow-query指令- 如果您的 DNS 伺服器對您自己的區域具有權威性，則根本不需要遞歸，設置
allow-recursion為“無”；- 如果您想為其他域執行解析器，請限制允許的使用者進行查詢和遞歸查詢。您可以在上述指令中定義 IP 地址、網路或訪問列表
- 考慮不僅在 BIND 中而且在系統級別上**限制 DNS 流量的速率。**作為一個非常簡單的範例，這些 iptables 規則將不允許每個 IP 地址每分鐘進行超過 10 次查詢：
.
iptables -A INPUT -p udp --dport 53 --set --name dnslimit iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP現在，考慮到這些要點，您應該可以開始了。您的伺服器上可能仍然存在惡意流量，但數量不會讓您睡個好覺。