2017-07-15 60 views
18

有什麼具體的可以做,以幫助使Django頻道服務器不易受輕或意外從websocket/HTTP客戶端的DDoS攻擊或一般負載增加?由於Channels並非真正的異步(仍然是幕後工作人員),我覺得取下基於頻道的網站是相當容易的 - 即使是相當簡單的硬件。我目前正在Django頻道上構建一個應用程序,稍後將運行一些測試以瞭解它如何成立。負載尖峯保護的Django頻道

是否存在某種形式的內置於達芙妮的節流?我應該實施一些應用程序級別的限制嗎?這仍然很慢,因爲工作人員仍然處理受限制的請求,但請求速度可能更快。我還有什麼可以嘗試阻止這些攻擊?

我想過的一個事情是確保有工作人員爲特定頻道指定 - 這樣,如果websocket頻道超載,HTTP仍會響應。

編輯:我很清楚,低級DDoS防護是一個理想的解決方案,並且我理解DDoS攻擊如何工作。我正在尋找的是一種解決方案,可以幫助處理類似增加的負載。或許達芙妮能夠擴大渠道規模並縮小另一渠道來彌補,或者可以在某個點之後降低每個請求的重量的節流方法。

我正在尋找達芙妮/頻道的具體答案 - 有關DDoS或一般負載處理的一般答案不是我正在尋找的 - 關於這個有很多其他問題。

我還可以根據誰登錄,誰不是 - 對未登錄的用戶節流可以幫助控制節流。

再次編輯:請閱讀整個問題!我不是在尋求一般的DDoS緩解建議或對低級方法的解釋。我想知道如果達芙妮有類似的支持:基於隊列的大小

  • 節流
  • 動態分配工人
  • 中間件對認證的請求優先提供

或者這種性質的東西。我也打算直接與渠道社區聯繫,因爲SO可能不是這個問題的最佳位置。

+0

帶軟件防火牆的DDOS保護?我的意見是「敬畏」的主意!在每個請求上讀取60個字節的數據包標題。觸發更多的拒絕 - 丟棄 - 凍結功能是「系統資源」問題。延遲是'已定的結論'。您可以在低價值攻擊方面取得成功,但如何處理系統資源?不能在防火牆上使用任何存儲過程,意味着good_user vs bad_user請求。 **如果接受不需要的請求,則無法保護自己!**如果數據包達到環回('lo'),則不便宜。 – dsgdfg

回答

3

我從Andrew Godwin收到answer。他不使用StackOverflow,因此我代表他在這裏發佈。

傑米嗨,

目前渠道有限制相當有限的支持 - 它幾乎包含傳入連接的可調通道尺寸,全時,將導致服務器返回503錯誤的。由於渠道設計的原因,工作人員基於可用性進行負載平衡,所以不存在員工比其他人獲得更大隊列的風險。

提供更高級的DoS或DDoS保護可能不是我們可以在Channels自身範圍內做的事情,但我想確保我們提供適當的掛鉤。你認爲我們可以實施哪些具體的事情,可以幫助你寫出一些你需要的東西?

(同時值得注意的是,現在我們正在將工作者/消費者佈局作爲重要改寫的一部分進行實質性改變,這在縮放時意味着不同的考慮因素,所以我也不想放棄確切的建議,只是還沒有)

安德魯

他還寫了關於2.0遷移在他blog

0

我只回答第一個問題。所以基本上不可能完全免受ddos攻擊,因爲它總是歸結爲資源之爭。如果服務器端資源大於攻擊者端資源,則服務器不會關閉(可能會降低性能),但如果服務器端資源不是,則服務器關閉[不需要參考]。爲什麼不可能100%保護,你可能會問。所以基本上你的服務器「崩潰」,如果人們無法連接到它[https://en.wikipedia.org/wiki/Crash_(computing)#Web_server_crashes --- Web服務器崩潰句子1]。因此,如果您每次在一秒內完成10000次連接,請嘗試通過關閉服務器5分鐘來保護您的服務器,則ddos會成功。它「崩潰」你的服務器。我所知道的唯一的ddos保護應該是Cloudfare(https://www.cloudflare.com/lp/ddos-b/?_bt=207028074666&_bk=%2Bddos%20%2Bprotection&_bm=b&_bn=g&gclid=EAIaIQobChMIu5qv4e-Z1QIVlyW9Ch2YGQdiEAAYASAAEgJbQ_D_BwE)。它通過10Tbps網絡骨幹吸收了ddos攻擊的影響。但即使它不提供100%的ddos保護,因爲一旦其10Tbps速度下降,您的服務器也會下降。所以,我希望這有助於。

+0

感謝您的回答,@Evgeny,但它並沒有真正回答這個問題。我瞭解DDoS攻擊是如何工作的,並且我知道您永遠不會安全。我也知道像Cloudflare這樣的選項存在,但是它們的有效性對websockets的攻擊極其有限,因爲它們不能提供用戶可接受的緩解策略,如CAPTCHA。在使用Daphne ASGI服務器構建Django頻道網站時,我具體詢問了最佳做法。 –

0

的DDoS分佈式=服務

的「分發」部分的拒絕是關鍵:你可以不知道你被特別是「某人」的襲擊,因爲請求來自全國各地的地方。

您的服務器將只接受一定數量的連接。如果攻擊者設法創建了其他人無法連​​接的很多連接,那麼您正在使用DDoS攻擊。

因此,本質上,您需要能夠檢測到連接不合法,或者您需要能夠快速擴展以補償連接數量的限制。

祝你好運!

DDoS防護應該真的是來自您的雲提供商的負載平衡器級別的服務。

像OVH這樣的公司使用先進的機器學習技術來檢測非法流量並禁止準實時採用IP。 對於你建立這樣一個檢測機器是一個巨大的投資,可能是不值得你的時間(除非你的網站是如此重要,並將損失數百萬美元,如果它下跌了一下)

+0

嘿@MrE,當然。我完全理解雲級別保護更好,但我也在詢問有關負載的意外問題。像扼流那樣會減少每個請求的影響量,或者某些特定於可以幫助的頻道,例如允許達芙妮縮小某個頻道以補償另一個頻道。 websockets的問題是他們很難保護。我會更新我的問題,以便更清楚一點。 –

+0

單個websocket中的流量真的取決於您的應用程序,如果您期望流量較低(如聊天頻道),那麼yes油門是一個很好的解決方案:暫停或踢出發送太多消息的任何人。對於其他類似物聯網數據的數據,您還應該擁有預期的數據速率。一般來說,節流似乎是一個好主意。 – MrE

+0

,但處理未知流量的最佳方法是不處理任何與您的websocket api服務器相關的東西,而是直接將消息發送到消息隊列(如Kafka,RabbitMQ),然後可以處理尖峯並將消息推送到該進程實際上處理處理。 – MrE

0

這很多你無法做的關於DDOS的事情..但是有一些整潔的「技巧」取決於你有多少資源在你的處置,以及有多少人想讓你脫機。

您是否提供需要直接連接到您嘗試保護的資源的總體公共服務?

如果是這樣,你只需要用你擁有的資源「擴大」DDOS,通過擴展和擴展......甚至彈性......這兩種方式都會花費你的錢!

或讓攻擊者更難消耗您的資源。有很多方法可以做到這一點。

如果您的服務需要某種身份驗證,請將您的身份驗證服務與您嘗試保護的資源分開。

許多應用程序,身份驗證和「服務」運行在相同的硬件上。這是一個DOS等待發生。

只允許完全認證的用戶訪問您嘗試使用動態防火牆過濾規則保護的資源。如果您通過身份驗證,則會打開資源(限制QOS)!如果你是一個知名的,長期信任的用戶,那麼就可以全面訪問資源。

如果您使用奇怪的金額查看特定帳戶,禁止它們或施加限制,則可以審計用戶資源行爲(網絡,內存,cpu),最終導致其流量的防火牆丟棄策略。

與ISP一起工作,該系統可以將系統的流量降至ISP邊界處的規格.... OVH是您的最佳選擇。一個ISP公開過濾器和流量作爲API暴露的ISP,我希望它們存在......基本上將防火牆過濾規則移動到AS邊界...... niiiiice! (幻想)

它不會阻止DDOS,但會給你一些工具來保持資源被攻擊者浪費在一個可管理的級別上。 DDOS不得不轉向你的驗證服務器...(可能),或者危及許多用戶帳戶....在已經過身份驗證的用戶仍然可以訪問:-)

如果您的DDOS正在佔用您的所有ISP帶寬,那是一個更難的問題,請遷移到更大的ISP!或移動ISP的...... :-)。隱藏你的主要資源,允許它動態移動,保持移動! :-)。

將問題分解爲碎片......在較小的碎片上應用DDOS控件。 :-)

我試過一個最普遍的答案,但有很多依賴,每個DDOS緩解需要一點皮膚,而不是錫方法..真的,你需要一個反ddos忍者你的團隊。 ;-)

看看分佈式協議.... DP的也許是DDOS的答案。

玩得開心。

0

讓我們對您的問題進行一些分析。 DDoS就像一個DoS,但和朋友一樣。如果你想避免DDoS泄漏,你需要儘量減少DoS的可能性。感謝capitan明顯。

第一件事是做的就是在你的系統中發生了什麼,並至極資源受到影響的列表:

  • 一個TCP握手進行(SYN_COOKIES受到影響)
  • 一個SSL握手來得晚(熵,CPU)
  • 一個連接到溝道層由...

然後monitorize每個資源,並嘗試以實現應對措施:

  • 保護到SYN_FLOOD配置內核PARAMS和防火牆
  • 使用熵發電機
  • 配置防火牆,限制在較短的時間打開/關閉連接(簡單的方法來減少SSL握手)
  • ...

分離你的大問題(DDoS)在許多簡單和容易糾正的任務。硬件部分是獲取步驟和資源的詳細列表。

請原諒我可憐的英語。

+0

capitan?隊長? – Pang

+0

嘿@lasizoillo,謝謝你的迴應。正如我在其他答案中提到的,我真的在尋找有關達芙妮支持這種事情的信息。一種處理大型隊列的方式,優雅地爲特定頻道產生更多工作人員,甚至某種節流。我知道真正的DDoS保護是在低得多的水平上完成的,但我正在尋找關於Daphne和Django Channels的應用程序級別支持的信息(想想DRF的節流)。 –