一個美好的春日夜晚，當我不想回家，抑制不住對生活和學習的渴望時，我心中充滿了灼熱，就像一塊燒紅的鐵，我突然想到要去嘗試防火牆上一個很誘人的小工具，它叫做“IP DOS 策略“。
經過一些初步的觸摸和閱讀手冊後，我將其設定為 傳遞並記錄，總體上觀察排氣情況以及此設定的可疑實用性。
幾天後（當然，這樣統計數據就會累積起來，而不是因為我忘記了），我查看了日誌，當場跳舞，拍手 - 記錄已經足夠多了。似乎沒有什麼比這更簡單的了——打開阻止模式的策略，阻止所有洪水攻擊、掃描、安裝 半開 經過一小時的禁令，他們可以安然入睡，因為他們知道邊境已被封鎖。但34歲的年紀，戰勝了年輕時的極端主義，腦海深處響起了一個細細的聲音：“讓我們睜開眼，看看我們心愛的防火牆識別出誰的地址是惡意的泛洪者？好吧，這都是些胡說八道。”
我們開始使用異常列表來分析接收到的資料。我透過一個簡單的腳本運行地址 PowerShell的 眼睛看到熟悉的字母 谷歌.
我揉了揉眼睛，眨了眨眼，大約五分鐘，以確保我沒有產生幻覺——防火牆認為的惡意泛洪攻擊類型清單中確實存在一種攻擊類型—— UDP洪水攻擊，屬於good公司的地址。
我正在絞盡腦汁，同時在外部介面上設置資料包捕獲以便進行後續分析。我腦子裡閃過一個個奇思妙想：“谷歌的監控範圍裡怎麼會有東西被感染？然後我就發現了這個？” “嗯，嗯，嗯，這可是獎項、榮譽、紅毯，還有你自己的二十一點賭場，嗯，你懂的……”
我正在分析收到的文件 Wireshark的-om。
是的，確實從地址範圍來看 Google 他們將 UDP 封包從連接埠 443 發送到我設備上的隨機連接埠。
但是等一下...這裡的協議從 UDP 上 GQUIC.
謝苗·謝苗尼奇…
我立刻想到了這份報告 高負荷 亞歷珊卓·托博利亞 «UDP против TCP 或網路堆疊的未來」（).
一方面，我感到一絲失望——先生，您沒有獲得任何榮譽，沒有獲得任何榮譽。另一方面，問題很明顯，剩下的就是了解在哪裡挖以及挖多少。
與善良公司進行幾分鐘的溝通 - 一切就都順利了。為了提高內容交付速度，該公司 Google 早在 2012 年就宣布了該協議 QUIC，這可以消除 TCP 的大部分缺點（是的，是的，是的，在這些文章中 - и 他們談論的是一種完全革命性的方法，但是，說實話，我們希望貓的圖片加載速度更快，而不是你們的所有這些意識和進步的革命）。進一步的研究表明，許多組織現在正在轉向這種類型的內容傳遞選項。
我遇到的問題（我想不僅僅是我遇到的問題）是，最終資料包太多，防火牆將它們視為洪氾。
可能的解決方案有幾個：
1. 新增到排除列表 DoS 策略 防火牆地址範圍 Google。一想到可能的地址範圍，我的眼睛就開始緊張地抽搐——這個想法被當作瘋狂的想法放在了一邊。
2. 提高響應閾值 UDP 洪水策略 - 也不符合規定，但如果有人真的懷有惡意，該怎麼辦呢？
3.阻止來自內部網路的請求 UDP 上 443 端口出。
在閱讀了有關實施和整合的更多資訊之後 QUIC в Google Chrome 最後一個選項被接受為行動的方向。問題是，無論在哪裡，每個人都無情地愛著（我不明白為什麼，最好有一個厚顏無恥的紅髮 Firefox-ov 的杯子將因其吞噬的 GB RAM 而獲得報酬)， Google Chrome 最初嘗試用他來之不易的 QUIC但如果奇蹟沒有發生，他就會回到已證實的方法，例如 TLS，儘管他對此感到非常羞愧。
為服務建立防火牆條目 QUIC:
我們制定了一條新規則並將其置於鏈中更高的位置。
啟用該規則後，異常清單中的所有內容都會保持安靜，但真正惡意的違規者除外。
謝謝大家的關注。
所用資源：
1.
2.
3.
4.
來源： www.habr.com
