可能的 DOS 攻擊或電腦“崩潰”
我是一名 dev-ops Web 開發人員，其站點在 AWS 上的負載均衡器後面執行兩個 ec2.smalls。
最近我們看到每秒有 3-4 個請求關閉我們的客戶網站。
該站點已關閉，並且在多次伺服器重新啟動和錯誤日誌掃描任何可能導致問題的腳本後不會恢復，即使最近沒有推送任何更改。
打開負載平衡器日誌記錄後，我看到單個頁面的 1000 多個請求來自一個 IP 地址。
我們使用 X-forwarded-for 將請求從負載均衡器轉發到處理請求的伺服器，並使用 .htaccess 規則阻止 IP。
在與客戶 IT 通信時，他們被告知負責大量請求的 IP 地址實際上是他們的內部公司機器之一。
負責的機器被遠端重啟，所有請求都停止了。該網站重新上線。
對此的官方解釋是“電腦嚇壞了”。
Web 瀏覽器或 Windows 機器是否可以每秒向負載平衡的網頁發出 3-4 個請求並將其關閉 5 小時以上？
以下是請求的樣子：
2017-01-14T01:00:46.170447Z west-ssl XX.XXX.XX.XXX:33370 - -1 -1 -1 503 0 0 0 "GET https://www.example.com:443/example/12 HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" ECDHE-RSA-AES128-SHA256 TLSv1.2
當然有可能——儘管這取決於許多因素：
1）聽起來伺服器端應用程序存在並發問題。可能值得一看的是應用程序伺服器是否是瓶頸，或者它是否在上游（例如數據庫）並且由於 apache 配置沒有足夠快地刷新執行緒而導致應用程序伺服器記憶體不足。如果是應用程序伺服器，可能值得進行一些調整——在 ELB 之外啟動一台相同的機器，並使用 JMeter 對其施加一些負載以找出瓶頸。
如果是數據庫，您可以使用 memcache/elasticache（因為看起來您正在檢索特定對象）來記憶體實際查詢。這樣數據庫連接快速響應，Apache 可以快速響應，並殺死執行緒而不是填滿應用程序機器的記憶體池。
如果你真的感覺很脆弱，你可以將 Varnish 放在上游以 1-5 秒的 TTL 記憶體請求，以防止主要的請求氾濫。但要小心，因為 VCL 是不可原諒的，並且可能導致重大問題和痛苦（記憶體中毒/洩漏）。
2）至於“主題”機器本身。顯然它可能已經被破壞了——它絕對應該被調查。我會讓你決定 IT 人員是否誠實——這超出了伺服器故障的範圍。
假設它沒有被破壞，它可能是一些糟糕的 javascript 程式碼 - 如果您進行輪詢刷新並且以某種方式修改了時間參數，它很可能開始每秒發送許多請求。同樣，JS 可能表現良好，但該人可能打開了 25 個選項卡並在晚上回家 - 如果每個人每 5 秒發送 1 個請求，那就是 5req/秒。