AWS WAF(Web 應用防火牆)怎麼用? 有效防禦 SQL 注入、跨站腳本與黑客惡意刷量
在公網環境裡,任何一個對外的 Web 服務、APP 接口或者電商網站,每天一開門營業,面對的就不僅是真實的客戶,還有密密麻麻的
黑客掃描器、惡意刷量爬蟲、以及各種針對應用層漏洞的自動化攻擊
。
很多技術團隊防範意識不夠,以為服務器裝個殺毒軟件、安全組關掉不用的端口就萬事大吉了。 結果就是：
核心數據庫被一條簡單的 SQL 注入語句直接脫褲洗劫、網頁被植入惡意腳本(XSS)導致用戶資金被盜、或者營銷活動接口被黑產用黑客工具在幾分鐘內薅幹了幾十萬的預算。
在傳統架構里,對付這種應用層(OSI 七層模型中的第七層)的惡意攻擊,需要改動大量的後端代碼或在 Nginx 層面寫一堆極其複雜的攔截規則,運維成本高且極易誤殺正常請求。
AWS亞馬遜雲代支付
而在亞馬遜雲上,最優雅、最省心的防禦兵器就是
AWS WAF(Web Application Firewall,Web 應用防火牆)
。 它就像一個守在服務器最前線的「魔鬼安檢員」,在請求還沒到達你的後端服務器之前,就在邊緣把各種暗器、毒藥和惡意刷量大軍死死擋在門外。
今天這篇深度教程不扯高深的安全黑話,用最接地氣的實戰視角,帶你徹底收服 AWS WAF。
核心原理:AWS WAF 守在哪裡? 它是怎麼工作的?
在配置之前,我們先搞清楚這個「安檢員」在你的架構里到底站在什麼位置。 AWS WAF
不能
直接掛在單台 EC2 雲服務器上面,它是通過「寄生」在以下三個核心的流量入口層來發揮作用的:
Application Load Balancer (ALB): 你的應用負載均衡器。
Amazon CloudFront: 你的全球 CDN 邊緣節點。
Amazon API Gateway: 你的微服務接口網關。
AWS亞馬遜雲代支付
當一個美國黑客精心構造了一個包含惡意代碼的請求發送過來時:
流量首先到達 CloudFront CDN 邊緣節點(或者 ALB)。
AWS WAF 瞬間介入。 它會用你配置好的「防禦規則集(Web ACL)」,像過 X 光機一樣去掃描這個請求的 Header(請求頭)、Query String(URL參數)、Body(請求體)以及 IP 來源。
如果匹配到黑客特徵,WAF 直接在邊緣吐出 403 Forbidden 攔截,攻擊流
量連你後端伺服器的毛都碰不到,更不會消耗你任何的 CPU 和業務帶寬。
第一階段:三步落地 AWS WAF 核心防禦(實戰抄作業)
配置 AWS WAF 的核心是創建一個
Web ACL(Web 訪問控制列表)
。 我們直接以「保護國內或海外的 ALB 負載均衡」為例,進行防禦部署:
第一步:新建 Web ACL 並綁定入口
登錄 AWS 管理控制台,搜索並進入 WAF & Shield 控制台。
在左側導航欄點擊 Web ACLs,然後點擊右側的 Create Web ACL。
關鍵參數配置:Resource type: 如果你是想保護 CloudFront CDN,選 Global (CloudFront);如果你是保護負載均衡,選 Regional resources 並選擇你服務器所在的地域(如 us-west-2 美西俄勒岡)。 Name: 給它起個清爽的名字,如 prod-web-waf-acl。
在下方 Associated AWS resources 處,點擊 Add AWS resources,勾選你正在跑著 Web 服務的 ALB 實例。 點擊 Next。
第二步:一鍵配置 AWS 官方託管規則集(封死 SQL 注入與 XSS)
AWS 官方非常貼心地幫我們寫好了應付常規黑客攻擊的「頂級防彈衣」,叫做
AWS Managed Rule Groups
。 你不需要懂高深的網絡安全對抗,直接一鍵啟用即可:
在 Add rules and rule groups 頁面,點擊右側的 Add rules -> Add managed rule groups。
展開 AWS managed rule groups,你會看到一堆官方維護、實時更新的規則。 強烈建議閉著眼睛勾選以下三款「核心主力」:core rule set (CRS): 核心規則集。 這是 WAF 的靈魂,裡面包含了對絕大多數常見漏洞(包括 OWASP Top 10)、本地文件包含(LFI)等常規攻擊的防禦。 SQL database (SQLi) rule set: SQL 注入專項防禦。 專門盯著請求里的數據庫特殊字符,死死焊死後端的數據庫大門。 Known bad inputs rule set: 漏洞掃描器防禦。 很多黑客喜歡用自動化的開源工具(如 SQLmap)來盲測你的
網站,這個規則能精準識別這些工具的探針並直接封殺。
點擊 Add rules 保存。
第三步:開啟速率限制(Rate-based Rule)-- 專治黑客惡意刷量
封死了漏洞攻擊,接下來就要對付最讓人頭疼的
惡意刷量、撞庫、爬蟲和 CC 攻擊
。
黑客為了打滿你的帶寬或者刷爆你的短信/驗證碼接口,會動用大量的肉雞或者代理 IP 在短時間內瘋狂並發。 AWS WAF 的
Rate-based Rule(基於速率的規則)
是降服它們的最強手段。
在規則頁面,點擊 Add rules -> Add my own rules and rule groups。
配置參數:Rule type: 勾選 Rate-based rule。 Rate limit(速率紅線): 設定一個單個 IP 在 5 分鐘內的訪問上限。 例如,對於普通的 Web 網站,設置 2000 即可。 如果是極其敏感的註冊/登錄接口,可以壓縮到 100 - 300。 Action: 選擇 Block(直接攔截)或 Count(只記錄不攔截,通常用於前期觀察)。
這樣,一旦有某一個海外 IP 在 5 分鐘內瘋狂請求超過了你設定的紅線,AWS WAF 會立刻給這個 IP 戴上上手銬,接下來的訪問全部賞它一個 403,通常 5 到 10 分鐘後行為正常了才會自動解封。
第二階段:高手進階--如何減少 WAF 的「誤殺率」?
安全領域有一個永恆的痛點:
防守越嚴,越容易誤殺好人。
比如,你公司的財務員工在後台上傳一個包含財務公式的 Excel 表格,WAF 的 SQL 注入規則可能誤認為這是黑客代碼,直接把財務大姐攔截了。
老練的架構師在 WAF 上線的第一天,會用下面這兩個技巧來精細化運營:
1. 先開啟「觀察模式(Count)」走火測試
新買的防彈衣不要立刻拉去擋子彈。 在生產環境剛添加完規則時:
AWS亞馬遜雲代支付
避坑大招: 先將所有剛加入的 Managed Rules 的 Action 改為 Count。
在這個模式下,WAF 發現嫌疑請求時不會真的去攔截它,而是僅僅在日誌里蓋一個「嫌疑犯」的圖章,讓請求繼續通過。
跑個 3 到 7 天,去控制台查看 WAF 的 CloudWatch 採樣日誌(Sampled requests)。 如果發現很多正常用戶的正常操作也被蓋了章,說明
規則過激了。 此時可以在控制台針對特定的子規則進行 Exclude(排除),洗淨誤殺後,再正式把 Action 切換為 Block。
2. 精準開闢「綠色通道(IP 白名單)」
如果你們公司有專門的合作夥伴、或者是內部辦公區的公網 IP 需要頻繁調用接口,千萬別讓他們去跟黑客一起排隊過安檢。
在 WAF 手動創建一個 IP Set,把你公司的固定公網 IP 輸進去。
在 Web ACL 里添加一條自定義規則:如果請求來自這個 IP Set,action 直接設置為 Allow(放行),並且把這條規則的優先級(Priority)提到最頂上的 0 號位置。 這樣內部流量就可以直接刷臉進場。
第三階段:看清 AWS WAF 的計費賬本(它貴嗎?)
AWS WAF 的計費非常清爽,它沒有任何隱形的服務器開銷,採用的是
固定底座費 流量處理費
的模式:
Web ACL 底座費: 每個 Web ACL 每月固定收取 $10。
規則(Rule)費: 你在 Web ACL 里每添加一條規則(比如勾了一個 CRS 集,或者自己寫了一個限速規則),每條規則每月收取 $1(AWS 官方自帶的託管規則集大部分免費提供,不額外加錢)。
請求處理費: 真正的彈性支出,每處理 100 萬個請求,收取 $0.60。
💡賬本精算小案例: 假設你建了一個 Web ACL,掛了 3 條基礎官方規則加 1 條限速規則(共 4 條 Rule),你的網站一個月總共有 2000 萬次請求。 固定月租:$10 (ACL) $1 * 4 (Rules) = $14請求費:(2000萬 / 100萬) * $0.60 = $12總賬單:一個月只需 $26 美元(約合人民幣 180 元)。 用兩張電影票的錢,就給公司的核心業務請了一個 24 小時貼身保護、永不疲倦的頂級數字保鏢。
總結與防身口訣
在現代雲原生架構里,把安全防禦寄託在後端代碼上是極度危險且落後的。 利用 AWS WAF,我們在最外層的網絡邊緣就完成了洗滌惡意流量的壯舉。 最後送你四句老手都在用的 WAF 口訣:
入口第一先掛鎖: WAF 掛在 ALB 或 CDN 前,黑客探針邊緣截。
官方託管全勾上: CRS、SQLi 加 注入,主流漏洞一鍵補。
限速規則壓刷量: 敏感接口設紅線,惡意爬蟲直接閃。
先 Count 後 B
Lock: 生產發布別大意,先看日誌再升級。
AWS亞馬遜雲代支付
