前言：為什麼 ASP 木馬難防？
ASP 木馬本質是合法的 ASP 腳本，僅含 eval(request("x")) 或 execute(request("x")) 等單行代碼。它與正常業務程式同語言、同權限、同目錄、同副檔名，傳統特徵碼掃描極易誤報/漏報。防禦核心在於切斷上傳路徑、嚴格權限最小化、建立不可變基線。本文給出十大可落地執行的鐵律。
鐵律一：原則禁止 Web 端上傳功能，改用 SFTP/FTPS/SCP 部署
- 所有程式碼、靜態資源、配置檔透過 CI/CD 流水線 或手動 SFTP (Port 22) / FTPS (Port 990) 部署
- Web 目錄權限設為 IIS_IUSRS / www-data : 讀 + 執行（腳本），不可寫入
- 若業務必須上傳（如使用者頭像、附件），見鐵律二、三
鐵律二：上傳目錄嚴格隔離 + 執行權限移除
- 上傳目錄放在 Web 根目錄之外（如
D:\Uploads\），或獨立子網域/儲存桶
- IIS/Apache/Nginx 設定該目錄/虛擬目錄：
移除「腳本執行」權限（Handler Mapping 移除 .asp/.aspx/.php/.jsp 映射）
啟用「靜態內容」僅讀取
MIME 僅允許圖片/文件類型（image/*, application/pdf 等）
- 檔案上傳後重新命名為隨機 GUID + 原副檔名，資料庫記錄原檔名/路徑對應
鐵律三：檔案型態驗證三層防線
| 層級 | 檢查點 | 工具/代碼片段 |
|---|
| Client 端 | accept 屬性、JS 檢查副檔名/大小 | <input accept="image/*">（可繞過，僅體驗） |
Server 端
(必要) | 1. 副檔名白名單
2. Magic Bytes (File Signature) 檢查
3. 內容解析（圖片用 GD/GDI+ 重繪、Office 用 LibreOffice 轉 PDF） | ASP 經典：
Set oFS = Server.CreateObject("Scripting.FileSystemObject")
讀取前 8 Bytes 對照 FF D8 FF (JPG)、89 50 4E 47 (PNG)、25 50 44 46 (PDF) |
儲存後
(深度) | ClamAV / Windows Defender 掃描、反序列化檢查、巨集檢測 | 排程掃描上傳目錄，異常隔離 |
鐵律四：資料庫連線帳號最小權限 + 參數化查詢
- Web 連線資料庫帳號：僅擁有業務所需表的 SELECT/INSERT/UPDATE/DELETE，無 DROP/CREATE/ALTER/GRANT，無 sysadmin/db_owner
- 所有 SQL 使用參數化查詢 (Command.Parameters)，徹底杜絕 SQL 注入上傳木馬路徑
- 資料庫檔案 不放在 Web 目錄下，副檔名改非標準（如
.dat），IIS 設定拒絕直接下載 .mdb/.accdb/.dat
鐵律五：後台管理入口隱藏化 + 多因子認證
- 後台登入頁面不在前台任何連結、sitemap、robots.txt 出現
- 路徑使用隨機高熵字串（如
/manage_7x9k2p/），定期輪換
- 強制雙因子認證 (TOTP/WebAuthn) + IP 白名單（僅辦公室/跳板機 IP）
- 登入失敗 5 次鎖定 30 分鐘，記錄審計日誌
鐵律六：敏感配置檔案防洩露
conn.asp、config.inc、web.config 等包含連線字串、金鑰的檔案：
1. 放在 Web 根目錄外
2. 或：IIS 要求驗證/授權規則拒絕直接請求 *.inc、*.config、*.bak、*.old- 編輯器備份檔 (
.bak、~、.swp) 產生即刪除，或設定編輯器不產生備份
鐵律七：定期基線掃描 + 異常檔案自動告警
- 建立 Web 目錄檔案基線（檔名、大小、SHA-256、修改時間）
- 每日排程掃描對比：
新增檔案 → 立即告警（Telegram/Email/企業微信）
修改檔案 → 告警並自動備份舊版
刪除檔案 → 記錄審計
- 工具：
Tripwire、AIDE、OSSEC、自製 PowerShell/Python 腳本
鐵律八：WAF/應用層防火牆攔截已知攻擊載荷
- 部署 ModSecurity (OWASP CRS 3.3+) 或商業 WAF（Cloudflare、Imperva、阿里雲 WAF）
- 規則覆蓋：
SQLi、XSS、RCE、LFI/RFI、WebShell 特徵（eval(、execute(、wscript.shell、adodb.stream）
上傳請求檢查：Content-Type、Multipart 邊界、檔案內容特徵
- 模式：阻擋模式（生產環境）、偵測模式（新規則觀察期）
鐵律九：伺服器層級強化——最小服務、最新補丁、審計日誌
- 停用/移除非必要服務：FTP (改 SFTP)、SMTP、印表機、遠端登錄、WebDAV
- 作業系統/IIS/.NET Framework/資料庫 每月補丁日 應用關鍵更新
- 啟用 IIS 進階日誌（欄位含：
cs-uri-query、cs(Cookie)、cs(Referer)、time-taken），集中轉送至 SIEM/日誌平台
- 啟用 Windows 稽核原則：物件存取失敗、程序建立、特權使用
鐵律十：事件響應 SOP——發現木馬的標準處理流程
- 隔離： 防火牆封鎖來源 IP、IIS 停用該站點、網路隔離受影響伺服器
- 取證： 完整磁碟鏡像 (FTK Imager/dd)、記憶體鏡像、IIS 日誌、資料庫日誌、WAF 日誌
- 溯源： 分析日誌找到上傳請求/注入點/利用漏洞、確認時間線
- 清除： 若無法 100% 確認所有木馬位置 → 重建伺服器（乾淨映像/基礎設施即代碼重建），而非嘗試手動清理
- 恢復： 從離線備份恢復資料庫/檔案、驗證完整性、修改所有帳號密鑰（資料庫、FTP、管理後台、API Key、雲端憑證）
- 複盤： 根因分析（為什麼能上傳？為什麼能執行？為什麼未被偵測？）、更新規則/流程/基線、全團隊分享
結語：防禦是體系，不是單點產品
ASP 木馬之所以猖獗，是因為「上傳 → 執行 → 持久化」鏈路每一環都有鬆動。十大鐵律分別鎖死：部署方式、上傳目錄權限、檔案驗證、資料庫權限、後台入口、配置保護、基線監控、WAF 攔截、主機強化、應急響應。缺一不可。從今天開始，檢視你的每一個 Web 站點：哪一環沒鎖死？ 那就是下一個被植入木馬的入口。
