背景說明

在大量來自海外的機器人、爬蟲與攻擊流量中，我發現除了 TCP SYN Flood 之外，Apache 的 access.log 與 error.log 裡也有大量異常存取行為，例如：

• 不存在的網址（404）
• 權限拒絕（403）
• 掃描漏洞（例如嘗試連到 /wp-login.php, /phpmyadmin 等）

這些都是潛在攻擊前兆，因此我撰寫一份腳本，定期分析 Apache 的 log 檔，自動封鎖惡意 IP。

腳本偵測規則

支援以下條件：

• 來自 access.log 或 error.log
• 出現大量 403 或 404 回應（可自訂次數門檻）
• 僅掃描 .log 結尾的檔案，跳過 .log.1 或 .gz 歷史檔
• 可選擇性分析過去 N 分鐘內的 log 記錄（例如搭配 date + awk 過濾）

例如：

grep -hE ' 403 | 404 ' /var/log/apache2/*access.log \
  | awk -v since="$(date --date='5 minutes ago' '+%d/%b/%Y:%H:%M')" \
         '$4 > "["since' {print $1}'

此方法可限制分析最近 5 分鐘內的異常行為，避免封鎖過時的 IP。

腳本實作邏輯：apache-ban-ip.sh

#!/bin/bash

export PATH=/usr/sbin:/usr/bin:/bin:/sbin
LOG_DIR=/var/log/apache2
IPSET_NAME="blacklist"
THRESHOLD=50
IPSET_TIMEOUT=3600
WHITELIST=("127.0.0.1" "你的管理員IP")

# 初始化 ipset
ipset list $IPSET_NAME >/dev/null 2>&1 || ipset create $IPSET_NAME hash:ip timeout $IPSET_TIMEOUT

is_whitelisted() {
  for wip in "${WHITELIST[@]}"; do
    [[ "$1" == "$wip" ]] && return 0
  done
  return 1
}

# 計算最近 5 分鐘的時間戳格式（Apache log 格式）
SINCE=$(date --date='5 minutes ago' '+%d/%b/%Y:%H:%M')

# 擷取最近 5 分鐘內 access.log 中 403, 404 的來源 IP（僅限 .log 結尾）
grep -hE ' 403 | 404 ' $LOG_DIR/*access.log \
  | awk -v since="$SINCE" '$4 > "["since {print $1}' \
  | sort | uniq -c | sort -nr \
  | awk -v thr=$THRESHOLD '$1 > thr {print $2}' \
  | while read ip; do
    if is_whitelisted "$ip"; then
      echo "[略過] $ip 為白名單"
      continue
    fi
    echo "[封鎖] $ip 超過異常門檻，加入黑名單"
    ipset add $IPSET_NAME $ip timeout $IPSET_TIMEOUT 2>/dev/null
  done

建議排程（每 5 分鐘一次）

sudo crontab -e

加入：

*/5 * * * * /usr/local/bin/apache-ban-ip.sh >> /var/log/apache-ban.log 2>&1

補充設定（若未設）

請確保你已有正確的 iptables drop 規則：

sudo iptables -I INPUT -m set --match-set blacklist src -j DROP

後續可進階方向

• 加入封鎖 IP 通知（LINE Notify / Email）
• 將每次封鎖記錄存入 SQLite / JSON Log
• 做出白名單 / 灰名單 / 封鎖名單 dashboard
• 用 fail2ban 整合也可以，但此腳本更輕量彈性

結語

這支腳本已幫助我自動防禦數千次非法掃描與惡意請求，等同為 Apache 建立了應用層 WAF 界限。

若你正在經營 WordPress、WooCommerce、或自架 API Gateway，這個腳本將成為你最值得信任的守門員。

開源、自由擴充，安全你自己定義。

Reality Breaker — 拒絕被動，用邏輯穿透風暴。

這篇文章 Apache Log 智能封鎖腳本：自動擷取異常存取與黑名單管理（含 ipset 實作） 最早出現於 碼蟻創研工坊 - CODEANT STUDIOS。

本篇介紹一套我親自實作、已成功抵擋上千次攻擊的 自動封鎖系統腳本，專門對付 TCP SYN Flood 攻擊。適用於 Linux + Apache + ipset 環境，完全開源，輕巧高效，歡迎自由使用與改造！

問題起點：SYN Flood 攻擊讓我 HTTPS 掛點

某天，我的伺服器連線數飆升，Apache 回應延遲，ss -tanp | grep "SYN-RECV" 看到數百條類似這樣的紀錄：

SYN-RECV   0 0 [::ffff:10.140.0.3]:443 [::ffff:179.107.51.201]:37425

這表示 TCP 三次握手被卡住，對方故意不回 ACK，讓伺服器卡在 SYN_RECV 狀態，進而癱瘓。

我的想法：伺服器需要一個「黑盾守門員」

我需要一個 自動偵測＋即時反制 的防火牆腳本，來對抗這種 TCP 層的資源消耗型攻擊。

黑盾守門員的核心邏輯：

1. 每分鐘掃描 ss -tanp | grep SYN-RECV 中的連線
2. 解析來源 IP（含 ::ffff:x.x.x.x 格式）
3. 每個 IP 若連線數 > 門檻（例如 10），就用 ipset 封鎖
4. 封鎖一段時間（如一小時），之後自動解除
5. 可設定白名單，避免誤殺管理者或內網

最新修正版腳本（支援 IPv6 包裝格式）

請將下列內容儲存為 /usr/local/bin/synflood-defender.sh：

#!/bin/bash

IPSET_NAME="blacklist"
IPSET_TIMEOUT=3600
SYN_THRESHOLD=10
WHITELIST=("127.0.0.1" "你的管理員IP")

# 建立 ipset（若尚未存在）
ipset list $IPSET_NAME >/dev/null 2>&1 || ipset create $IPSET_NAME hash:ip timeout $IPSET_TIMEOUT

# 判斷是否白名單
is_whitelisted() {
  for white_ip in "${WHITELIST[@]}"; do
    [[ "$1" == "$white_ip" ]] && return 0
  done
  return 1
}

# 掃描 SYN_RECV 並解析 IP
ss -tanp | grep "SYN-RECV" \
| awk '{print $5}' \
| grep -oP '(?<=::ffff:)(\d{1,3}(\.\d{1,3}){3})' \
| sort | uniq -c \
| awk -v thr=$SYN_THRESHOLD '$1 >= thr {print $2}' \
| while read ip; do
  if is_whitelisted "$ip"; then
    echo "[略過] 白名單 IP：$ip"
    continue
  fi
  echo "[封鎖] $ip 達到 SYN_RECV 門檻，封鎖中..."
  ipset add $IPSET_NAME "$ip" timeout $IPSET_TIMEOUT 2>/dev/null
done

# 輸出目前封鎖總數
COUNT=$(ipset list $IPSET_NAME | grep -c 'add ')
echo "[done] 當前 SYN 封鎖 IP 數：$COUNT"

自動化建議（每分鐘執行）

請加入 crontab：

sudo crontab -e

加入以下內容：

* * * * * /usr/local/bin/synflood-defender.sh >> /var/log/synflood.log 2>&1

搭配 iptables DROP 設定（只要設定一次）

sudo iptables -I INPUT -m set --match-set blacklist src -j DROP

附加工具：查看 SYN 攻擊 IP 排行榜

ss -tanp | grep "SYN-RECV" \
| awk '{print $5}' \
| sed -E 's/.*::ffff:([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+):.*/\1/' \
| sort | uniq -c | sort -nr | head

總結與延伸

這套「黑盾守門員」方案，結合了：

• Linux 原生網路工具（ss + ipset + iptables）
• 自動化執行（cron）
• 白名單控管
• 對 SYN Flood 針對性防禦

適用於 VPS、自架伺服器，或任何可能暴露在公網的 Apache/Nginx 主機上。

最後附註

歡迎轉載或自行改寫本腳本，若你也有實戰經驗與更強化的技巧，歡迎留言交流！如果你覺得「黑盾守門員」有幫助，也歡迎分享給更多站長朋友！

這篇文章 🛡 黑盾守門員：我如何打造一套自動反制 SYN Flood 的伺服器防火牆系統（含腳本更新） 最早出現於 碼蟻創研工坊 - CODEANT STUDIOS。

那麼一個單日30萬PV，而且還是使用虛擬主機建成的網站，有可能嗎？當然有，下面就來完整揭露所有配置。

這個客戶選擇的虛擬主機服務商是： GoDaddy（先聲明，這絕對不是業配文），其實客戶要選擇什麼主機商，我一向是沒意見，因為付錢的是大爺，當初這位客戶是直接選擇了”豪華型的套餐”，然後他又升級成 2 CPU + 1 GB RAM，Total 加起來，虛擬主機這邊的費用，一年聽說約 3000-NT而已，有用 GoDaddy 的就知道這個規格並不是”一拜”的等級。

所使用的 WordPress 目前是更新到 4.6 的版本了，沒有去改動任何的 Code，是原廠的，下面這幾張管理後台的配置圖，就是為何可以承受單日30萬PV的關鍵了，魔鬼就藏在細節裡：

其實故事說到這邊就說完了，下面都是題外話了。事實證明，使用虛擬主機+Wordpress就可以打造出可承受單日30萬PV的網站系統，但最困難的是，要如何才能吸引到單日30萬PV啊？網站技術跟網站經營真的是兩碼子的事。

這篇文章 「密技」如何用 WordPress+虛擬主機，打造一個單日30萬PV的網站？ 最早出現於 碼蟻創研工坊 - CODEANT STUDIOS。

sign up for an API key pair : https://www.google.com/recaptcha/admin

然後到 Joomla 的後台管理頁面，啟用圖形驗證功能：

到外掛中填入剛剛取得的網站金鑰：

記得要選 2.0 版本

下面就是設定成功後的畫面：

這篇文章 Joomla 啟用 reCAPTCHA 圖形驗證的設定流程 最早出現於 碼蟻創研工坊 - CODEANT STUDIOS。

產生程式碼請到，分享按钮-百度分享 : http://share.baidu.com/code

提供一下本站目前所使用的分享按鈕程式碼：

<div class="bdsharebuttonbox"> 
<a href="#" class="bds_more"   data-cmd="more"></a> 
<a href="#" class="bds_qzone"  data-cmd="qzone"  title="分享到QQ空间"></a> 
<a href="#" class="bds_tsina"  data-cmd="tsina"  title="分享到新浪微博"></a> 
<a href="#" class="bds_tqq"    data-cmd="tqq"    title="分享到腾讯微博"></a> 
<a href="#" class="bds_weixin" data-cmd="weixin" title="分享到微信"></a> 
<a href="#" class="bds_fbook"  data-cmd="fbook"  title="分享到Facebook"></a> 
<a href="#" class="bds_twi"    data-cmd="twi"    title="分享到Twitter" ></a> 
<a href="#" class="bds_tieba"  data-cmd="tieba"  title="分享到百度贴吧"></a>
</div> 
<script> 
window._bd_share_config={"common":{"bdSnsKey":{},"bdText":"","bdMini":"2","bdMiniList":false,"bdPic":"","bdStyle":"0","bdSize":"24"},"share":{}};
with(document)0[(getElementsByTagName('head')[0]||body).appendChild(createElement('script')).src='http://bdimg.share.baidu.com/static/api/js/share.js?v=89860593.js?cdnversion='+~(-new Date()/36e5)]; 
</script>

這篇文章 百度提供的社群網站分享按鈕 最早出現於 碼蟻創研工坊 - CODEANT STUDIOS。

我個人相當推薦這種方式，非常的友善，使用上對於已經有採用 Google Analytics 網站來說，基本上是無痛的一種方式。

JavaScript 程式碼如下

(無關帳號或網址，所有網站都用同樣的程式碼)：

<script>
(function(){     
var bp = document.createElement('script');     
var curProtocol = window.location.protocol.split(':')[0];     

if (curProtocol === 'https') {         
    bp.src = 'https://zz.bdstatic.com/linksubmit/push.js';             
} else {         
    bp.src = 'http://push.zhanzhang.baidu.com/push.js';     
}     
var s = document.getElementsByTagName("script")[0];
s.parentNode.insertBefore(bp, s); })();
</script>

我自己的習慣是這類的程式都會放在網頁的底部，但是在< / body > 前面。

這篇文章 百度 Sitemap 自動推送 JavaScript 程式碼 最早出現於 碼蟻創研工坊 - CODEANT STUDIOS。

站在網站防禦的角度上，DoS 攻擊可以是一台電腦就達到，例如用ApacheBench這隻測試程式就可以達到攻擊的目的，所以我們可以用 IP 來源+單位時間內的連線數，去做出有效的判斷，進而採取防禦手段；但 DDoS 是分散式的，也就是攻擊的來源是由多個不同的來源 IP 在同一段時間內持續發起連線請求，進而佔據目標網站的大量資源，達到阻斷服務的目的，在判斷上跟防禦上，難度都高很多，舉一個簡單的問題為例，誰是真的訪客？誰又是真的來亂的？這就防禦DDoS的難處。

當你決定採取自建主機的方案（包含 AWS EC2）來營運網站時，你的網站就已經被列入 DoS 攻擊的目標了，這就是一場駭客與工程師的千日戰爭，永無休止的那一天！那採取虛擬主機方案的網站就可以放心了嗎？可以是但也不完全是，是的部份是因為虛擬主機通常環境都是固定，服務商都會有一套SOP去達成一定水準的防禦佈署，不完全是的部份，則是防線永遠有被突破的可能。

我看到的很多情況是自建主機者，連基本的防 DoS 能力都不具備，更遑論去抵禦 DDoS 的攻擊，所以對網站經營的初心者來說，我通常都建議採取虛擬主機的方案，因為相對安全而且便宜，不需要一開始就把學習曲線弄的太陡峭，容易喪失信心，畢竟網站經營的初期，應該放在內容的管理維護，而不是太多的技術實戰，除非你已經是個練家子，那麼自建主機絕對能給你更大的彈性跟效能，也能讓你有更多的練功機會，但這種人相對稀少。

網路如馬路，馬路如虎口！所有有興趣要踏入網站經營的人，當應該先評估那個方案最有效益，這也包含了所有的中小企業，做生意將本求利，辛苦弄了一個網站，就是希望能有人流，產生更多獲利，如果一直被DoS其實也等於沒用，當然駭客也會挑啦，沒有價值的攻擊目標，也不會浪費氣力就是了，但拿這種來練練功的初入門駭客也沒少過就是了。

這篇文章 架設網站選用虛擬主機?還是自建主機？先從防 DoS 攻擊能力談起！ 最早出現於 碼蟻創研工坊 - CODEANT STUDIOS。

Server : AWS EC2 t2.micro + Ubuntu 16.04 LTS 

測試指令：

ab2 -n 5000 -c 50 http://codeant.cc/

沒有快取時：Requests per second:    25.99 [#/sec] (mean)

累進快取模式(剛開啟，快取資料量少時)：Requests per second:    72.57 [#/sec] (mean)

累進快取模式(快取資料量大時)：Requests per second:   13.54 [#/sec] (mean)

(使用：wget -r –spider http://codeant.cc 爬完全站，產生大量快取資料)

保守快取模式(剛開啟，快取資料量少時)：Requests per second:    65.90 [#/sec] (mean)

保守快取模式(快取資料量大時)：Requests per second:   65.78 [#/sec] (mean)

(使用：wget -r –spider http://codeant.cc 爬完全站，產生大量快取資料)

測試結論：

1. 快取資料量少時：累進快取 > 保守快取 > 沒有快取。

2. 快取資料量大時：保守快取 > 沒有快取 > 累進快取。

3. 保守快取比沒有快取的模式下，效能提升 153.5%

這篇文章 Joomla 快取模式效能測試 最早出現於 碼蟻創研工坊 - CODEANT STUDIOS。

使用上非常簡單，首先添加一行 Code 引入 Javascript：

<script src="https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js" async="async"></script>

然後在有程式碼內容的使用下面的範例編輯即可：

<pre class="prettyprint">........</pre>

下面示範一下 C 語言的效果：

void geo_ip_city (char *ip_str, IP_INFO *ip_info)
{
	GeoIP       *gi  = NULL;
	GeoIPRecord *gir = NULL;

	gi = GeoIP_open("/root/GeoIP/GeoLiteCity.dat", GEOIP_INDEX_CACHE);
	if (gi == NULL) {
		printf("Error opening database\n");
		return;
	}
	
	gir = GeoIP_record_by_name(gi, (const char *)ip_str);
	if (gir != NULL) {
		//printf("%s\n%s\n%s\n%s\n", ip_str, _mk_NA(gir->country_code), _mk_NA(GeoIP_region_name_by_code(gir->country_code, gir->region)), _mk_NA(gir->city));
		snprintf(ip_info->country, IP_COUNTRY_LENGTH, "%s", _mk_NA(gir->country_code));
		snprintf(ip_info->city, IP_CITY_LENGTH, "%s, %s", _mk_NA(GeoIP_region_name_by_code(gir->country_code, gir->region)), _mk_NA(gir->city));
		GeoIPRecord_delete(gir);
	}

	GeoIP_delete(gi);
	return;
} 

 真的是好物，一用就愛上。

這篇文章 讓你網站文章中的程式碼漂亮起來 – Code Prettifier 最早出現於 碼蟻創研工坊 - CODEANT STUDIOS。

原本客戶使用的QCA9533 AL3A是沒問題的，直到換了BL3A才出現30 dBm 的 loss，這種突然間出現的Project往往都很急也很趕，只好努力一下，最後花了2天處理好這個已困擾客戶三個禮拜的問題，Happy hacked.

這是修正前(Before)的訊號強度:

這是修正後(After)的訊號強度:

剛剛客戶已確認測試通過了，很高興再次救援成功，下面分享一下修改後的patch內容。

diff -Naur ../orig-compat-wireless-2014-05-22/drivers/net/wireless/ath/ath9k/hw.c ../compat-wireless-2014-05-22/drivers/net/wireless/ath/ath9k/hw.c  
--- ../orig-compat-wireless-2014-05-22/drivers/net/wireless/ath/ath9k/hw.c      2015-06-07 14:13:10.655703572 +0800 
+++ ../compat-wireless-2014-05-22/drivers/net/wireless/ath/ath9k/hw.c   2015-06-07 14:14:12.336864783 +0800 
@@ -260,7 +260,7 @@         
                case AR9300_DEVID_AR953X:                 
                    ah->hw_version.macVersion = AR_SREV_VERSION_9531;                 
                    if (ah->get_mac_revision) 
-                       ah->hw_version.macRev = ah->get_mac_revision(); 
+                       ah->hw_version.macRev = 1; //ah->get_mac_revision();                 
                        return;         
                    }

這篇文章 關於OpenWRT使用ATH9K，QCA953X BL3A訊號異常BUG的修正 最早出現於 碼蟻創研工坊 - CODEANT STUDIOS。