抵擋爬蟲

Cloudflare頁中有「抵擋爬蟲」的段落

DS720+ 檢測

找出佔用 CPU 的環節

監看目前所有程式的執行狀況：top
- PID: 執行任務的 Process ID
- USER: 執行任務的使用者是誰
- PR: 任務的優先度 (Priority)
- NI: 任務的 Nice Value，負的值代表優先度高，正的值代表優先度低
- VIRT: 總共用到多少 kB 虛擬記憶體 (Virtual Memory)
- RES: 實體記憶體 (Resident Size) 大小 kB
- SHR: 總共用到多少 kB 的共享記憶體 (Shared Memory)
- S: 狀態 (Status)
  - R 代表執行中
  - D 代表不可中斷睡眠 (不可被 signal 打斷通常在等 I/O)
  - S 代表睡眠 (可被喚醒)
  - T 中斷中或停止，可能是被 SIGSTOP 或 SIGTSTP 停止，或是被 degubber 中斷 (ptrace)
  - Z 代表殭屍，通常發生在 Child 已經執行完，等待 Parent 結束或回收
- %CPU: 占用到多少 CPU %，注意到一個核心是 100%，所以多核心是可以超過 100% 的
- %MEM: 占用到多少全部記憶體多少比例
- TIME+: 已經執行多少時間
- COMMAND: 任務的指令名稱
查連網統計：netstat(Network Statistics)
常見參數：
- -a：顯示所有連線與監聽的連接埠。
- -t：顯示 TCP 協定相關資訊。
- -u：顯示 UDP 協定相關資訊。
- -n：以數字形式顯示位址與連接埠（不進行 DNS 反查，速度較快）。
- -p：顯示佔用該連線的程式名稱與 PID（需具備 root 權限）。
- -l：僅顯示正在「監聽（Listening）」的服務。
應用的命令：
- 「netstat -antp | grep :80」查從 80 進來的工作都在幹嘛
- 「netstat -tn | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20」
  1. netstat -tn：列出目前的 TCP 網路連線。輸出可能像這樣：
    Proto Recv-Q Send-Q Local Address Foreign Address State
    tcp 0 0 192.168.1.10:80 47.82.8.63:52344 ESTABLISHED
    tcp 0 0 192.168.1.10:443 66.249.66.1:44321 ESTABLISHED
  2. grep ESTABLISHED：只保留 TCP 連線已成功建立，雙方正在或可以傳輸資料的狀態(ESTABLISHED)的連線。排除：LISTEN、TIME_WAIT、CLOSE_WAIT、SYN_SENT、FIN_WAIT等狀態的連線。
  3. awk '{print $5}'：取出第 5 欄，也就是遠端位址 Foreign Address。即 47.82.8.63:52344 。
  4. cut -d: -f1：用冒號「:」當分隔符，只取第 1 段。取回 47.82.8.63 。
  5. sort：把 IP 排序，讓相同 IP 排在一起，以便下一步的 uniq -c 能正確統計。
  6. uniq -c：統計連續重複的行數。如「3 47.82.8.63」代表 47.82.8.63 出現 3 次。
  7. sort -nr：依照數字由大到小排序。-n 用數字大小排序；-r 表示反向排序，也就是由大到小。
  8. head -20：只顯示前 20 筆，也就是連線數最多的前 20 個遠端 IP。
- 發現是阿里雲上的虛擬伺服器來打爆 DS720+ 。

封阿里雲常見的掃描來源網段：
在「DSM / 控制台 / 安全性 / 防火牆 / 防火牆設定檔 / 編輯規則 / 新增」：
「所有連接埠 | 拒絕 | 特定 IP => IP 範圍：從 47.82.0.0 到 47.82.255.255」
47.79.0.0/16

47.82.0.0/16

47.88.0

.0/16

狀態	封鎖前	封鎖後
ESTABLISHED	1115	27
CLOSE_WAIT	308	0
FIN_WAIT2	297	0
SYN_SENT	92	0
CPU	50~85%	你之前觀察已明顯下降
寫入量	很高	幾乎歸零

HTTP
↓
Apache
↓
PHP
↓
MediaWiki
↓
MariaDB
TCP 的正常流程：ESTABLISHED
↓
FIN_WAIT
↓
TIME_WAIT
↓
消失

http_response_code(503); 能瞬間降低負載。

sudo iostat -xm 1

netstat -ant | awk '{print $6}' | sort | uniq -c 回應

     1 established)
    23 ESTABLISHED
     2 FIN_WAIT1
     2 FIN_WAIT2
     1 Foreign
     2 LAST_ACK
    32 LISTEN
     3 SYN_RECV
   961 TIME_WAIT

或

     1 established)
    41 ESTABLISHED
     1 Foreign
    32 LISTEN
   985 TIME_WAIT

列出 cpu 佔用的前 20 名：「ps aux --sort=-%cpu | head -20」
發現主要是 mariadbd 和數個 php-fpm worker => 11MB/s 寫入量來自「MediaWiki → PHP → MariaDB」鏈條

檢查儲存裝置被頻繁寫入

發現儲存裝置有 11MB/s 寫入量

查資料庫請求的增量：「SHOW GLOBAL STATUS LIKE 'Questions';」 60 秒後再執行一次，看增加多少 => 60 秒增加：76491 => 約 1,275 queries / 秒
查是哪些請求：「SHOW FULL PROCESSLIST;」秀出運行中的全部請求
如果太多，先用這個：
---------- information_schema 資料庫中的 PROCESSLIST 資料表 ----------
- SELECT ID,USER,DB,COMMAND,TIME,STATE,LEFT(INFO,300) AS SQL_TEXT FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND<>'Sleep' ORDER BY TIME DESC;
  也查資料庫連線來源：
- SELECT USER,DB,COMMAND,COUNT(*) FROM INFORMATION_SCHEMA.PROCESSLIST GROUP BY USER,DB,COMMAND ORDER BY COUNT(*) DESC;
- 查到：
  REPLACE /* SqlBagOStuff::updateTable */ INTO `wiki_objectcache` (keyname,value,exptime) VALUES ('alWiki:messages:zh-tw','………','20380119031407')
11MB/s 寫入的原因很明確：objectcache 一直被 REPLACE
---------- 查快取是否使用 wiki_objectcache ----------
SELECT COUNT(*) FROM wiki_objectcache; 等一分鐘再查一次，如果數量持續增加，是使用 wiki_objectcache
看 SHOW TABLE STATUS LIKE 'wiki_objectcache'; 中的：
- Data_length
- Index_length
- Update_time
清快取表：「TRUNCATE TABLE wiki_objectcache;」
sudo synopkg restart MariaDB10 重啟資料庫服務
sudo synopkg restart WebStation 重啟網頁服務
sudo synosystemctl restart pkgctl-WebStation 只重啟 PHP-FPM

抵擋爬蟲

DS720+ 檢測

找出佔用 CPU 的環節

檢查儲存裝置被頻繁寫入

導覽選單

搜尋