DoS 攻擊？絕大多數 apache 工作人員處於「閱讀請求」模式，網站昨晚關閉，現在速度很慢

Question

所以我認為我的伺服器可能會遭受拒絕服務攻擊。

我們收到 pingdom（網站監控）通知，我們的網站從凌晨 3 點左右開始不可用。今天早些時候，我們開始檢查 apache 錯誤日誌，發現了一大堆這樣的錯誤：

AH00485：記分板已滿，不在 MaxRequestWorkers 處

我們也發現我們的 PHP-FPM 進程池經常需要產生更多伺服器：

[pool www] 似乎很忙（您可能需要增加 pm.start_servers 或 pm.min/max_spare_servers），產生 8 個子進程

我們嘗試在 apache conf 中增加 MaxRequestWorkers 和其他一些補救措施，但這些並不能消除 apache 錯誤日誌中的記分板錯誤，因此，與我更好的判斷相反，我遵循了中的建議這個線程並設定最小備用線程數和最大備用線程數等於最大請求工作者數。這些更改似乎消除了記分板錯誤。

我還大大增加了 MaxRequestWorkers，因為我們有大量 RAM 顯然沒有被利用。我們的伺服器有 8 個核心，儘管配置值非常高，但似乎根本沒有使用太多 RAM：

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8G        1.8G        2.0G         38M        4.0G        5.8G
Swap:            0B          0B          0B

我對 apache conf 中的 MaxRequestWorkers 和 php-fpm 配置中的 pm.max_children 的這些高值感到非常緊張。

這是 mpm_event.conf 中的基本配置

<IfModule mpm_event_module>
        StartServers        2
        MinSpareThreads     800
        MaxSpareThreads     800
        ThreadLimit     64
        ThreadsPerChild     25
        ServerLimit 800
        MaxRequestWorkers       800
        MaxConnectionsPerChild   0
</IfModule>

以下是 php-fpm conf 檔案中的一些設定：

pm.max_children = 256
pm.start_servers = 64
pm.min_spare_servers = 64
pm.max_spare_servers = 128

這是一些基本的伺服器資訊：

Server version: Apache/2.4.18 (Ubuntu)
Server built:   2019-10-08T13:31:25
Server's Module Magic Number: 20120211:52
Server loaded:  APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture:   64-bit
Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)

以下是 apache 伺服器狀態輸出的一些資料：

Server Version: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g
Server MPM: event
Server Built: 2019-10-08T13:31:25

Current Time: Friday, 10-Jan-2020 22:58:55 CST
Restart Time: Friday, 10-Jan-2020 22:26:32 CST
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 32 minutes 22 seconds
Server load: 4.69 5.06 5.12
Total accesses: 78434 - Total Traffic: 1.5 GB
CPU Usage: u2970.53 s5037.34 cu0 cs0 - 412% CPU load
40.4 requests/sec - 0.8 MB/second - 19.7 kB/request
797 requests currently being processed, 3 idle workers

PID Connections     Threads Async connections
total   accepting   busy    idle    writing keep-alive  closing
6124    28  yes 25  0   0   0   3
6125    27  yes 25  0   0   0   2
6182    30  yes 25  0   0   1   4
6210    28  yes 25  0   0   0   3
6211    29  yes 25  0   0   0   5
6266    28  yes 25  0   0   2   1
6267    25  yes 25  0   0   0   1
6269    28  no  24  1   0   1   3
6276    28  yes 25  0   0   0   3
6378    28  yes 25  0   0   0   3
6379    31  no  24  1   0   4   3
6380    27  yes 25  0   0   0   3
6384    26  yes 25  0   0   0   2
6397    28  yes 25  0   0   2   1
6405    27  yes 25  0   0   0   2
6414    26  yes 25  0   0   1   0
6423    27  no  24  1   0   1   1
6602    27  yes 25  0   0   0   3
6603    28  yes 25  0   0   0   4
6604    26  yes 25  0   0   0   1
6617    30  yes 25  0   0   0   5
6646    26  yes 25  0   0   0   2
6676    27  yes 25  0   0   0   2
6694    30  yes 25  0   0   0   5
6705    28  yes 25  0   0   0   3
6730    29  yes 25  0   0   0   4
6765    29  yes 25  0   0   0   4
6781    27  yes 25  0   0   0   2
6805    28  yes 25  0   0   0   4
6836    28  yes 25  0   0   0   3
6858    27  yes 25  0   0   0   3
6859    27  no  25  0   0   1   1
Sum 888     797 3   0   13  86

工作模式部分是最令人不安的。幾乎每個都處於讀取模式：

RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRR_RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
_RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR_RRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR

最後是這樣的：

SSL/TLS Session Cache Status:
cache type: SHMCB, shared memory: 512000 bytes, current entries: 2176
subcaches: 32, indexes per subcache: 88
time left on oldest entries' objects: avg: 220 seconds, (range: 197...243)
index usage: 77%, cache usage: 99%
total entries stored since starting: 60122
total entries replaced since starting: 0
total entries expired since starting: 0
total (pre-expiry) entries scrolled out of the cache: 57946
total retrieves since starting: 3405 hit, 59594 miss
total removes since starting: 0 hit, 0 miss

netstat 顯示了大約 3000 個到連接埠 80 和連接埠 443 的連線：

$ netstat -n | egrep ":80|443" | wc -l
3715

到底他媽發生了什麼事？伺服器已經運作良好數月了更適度的配置設定。昨晚凌晨 3 點左右，事情似乎突然改變了。

任何指導將不勝感激。我首先搜尋這裡並發現另一個線程但它是在 prefork 模式下運行的 apache 的不同版本，而不是像我這樣的事件。我也不明白該線程中的一點信息如何導致 SlowLoris 診斷。

編輯看來我必須更準確地表達我的問題：

1）如何恢復伺服器的回應能力。顯然，apache 工作人員陷入了困境右模式是某些問題的症狀。

2）我可以採取一些可靠的一系列步驟來更具體地識別實際問題嗎？

3）有什麼方法可以確認機器是否受到DoS攻擊？

Answer 1

僅僅計算記分板上的連接數量並不足以證明客戶粗魯並且沒有跟進他們的連接。這是一個急劇的增長，因此要么該網絡應用程式變得非常受歡迎，要么有人提出了愚蠢的請求。

查看每秒完成的請求的速率。假設您的網頁應用程式表現良好，對於這麼多工作人員來說應該相當高。檢查 Web 伺服器效能的各個方面，包括使用者可用的頻寬、伺服器負載以及相關元件（如任何資料庫）的效能。修復由於資源不足而導致的任何效能問題。

分析連接 Web 連接埠的 IP 位址的分佈。儘管 IPv4 NAT 使這一情況變得複雜，但用一個 IP 執行所有數百個連接是不尋常的。確定來源位址的ISP。檢查 IP 位址的安全信譽評分，以及它是否可能是一個巨大的 NAT。

對傳入請求進行封包捕獲，同時仍進行監視。您應該至少看到一些來自行為良好的客戶端的 HTTP 請求。如果客戶端只是連接並坐在那裡，這看起來有點像 SlowLoris 風格的資源耗盡。

考慮連結答案中的調整建議。在 Linux 上，net.ipv4.tcp_fin_timeout = 10可以嘗試使用 sysctl 等稍微減少逾時 。

考慮將此 Web 伺服器置於面向安全性和負載平衡的代理程式後面。 Web 應用程式防火牆功能可讓您巧妙地過濾要求。水平擴展可以讓您處理更多請求。

Answer 2

有什麼方法可以確認機器受到DoS攻擊嗎？

拒絕服務是拒絕服務。

攻擊是為了造成傷害而採取的敵對行動。

（被動攻擊是不明白這一點的人所使用的矛盾修辭法被動的意味著沒有採取行動——根據定義，不採取行動，並且侵略（根據定義也是如此）意味著敵對行動。但這當然是另一個故事了。

這兩者之間有一個差距，即 DoS，但就敵對行動而言，它不是攻擊。比方說，如果不採取對策，使用者鍵盤上的 F5 卡住就會導致 DoS，但這並不是一種攻擊，而是一種旨在造成傷害的敵對行為。 OTOH，如果使用者知道這會導致 DoS 並故意按住該鍵，則這是一種攻擊。

所以回答你的問題——除非你能證明有意圖，否則顯然不可能確定。如果因資源缺乏（即過載）而導致服務中斷，則可以判斷是否為 DoS。