iWall3 — 讓安全人員成為規則的生産者
一、程式設計語言的要素
天存資訊的iWall3應用防火牆是一種創新式的類程式設計 WAF，它包含了程式設計語言的一些基本要素。
1. 變量
iWall3 中廣義的變量包括封包變量、環境變量和使用者變量：封包變量和環境變量相當于程式設計語言中的常量或傳入的參數，使用者變量則是真正程式設計語言意義上的變量，即使用者可以自行建立、使用和維護變量。
2. 條件判斷
iWall3 支援程式設計語言标準的條件判斷：即可以包含無限嵌套的
if
-
then
-
else
條件，每個
if
條件又可以使用
and
-
or
-
not
邏輯運算符連接配接多個子條件。
3. 表達式
iWall3 支援與通用程式設計語言一緻的表達式：表達式由常量、變量、運算符和内置函數組成，以模闆字元串方式内嵌書寫，可在條件判斷、變量指派、模式比對、日志輸出等任意位置使用。
4. 語句
條件執行部分，iWall3 允許使用者書寫任意語句：這些語句不限于 WAF 正常的阻止通路和記錄日志，它可以實作更複雜的功能，如：改變其他規則的行為，修改 HTTP 封包的特定部分，輸出指定變量等。
二、資料方式的語言表達
天存資訊的 iWall3 包含了程式設計語言的設計思想，但獨創性地以資料方式呈現。
1. JSON格式
安全産品的使用者通常是非程式員，他們習慣于面對配置檔案而非一段代碼。是以，iWall3 的配置依舊以規則檔案的形式出現，隻是這裡的規則不是純文字格式，而是可以展現出層次結構的 JSON 格式。
- 充分利用 JSON 格式的名-值對 (對象) 和序清單 (數組) 結構，将語言要素和業務邏輯用 JSON 格式表達出來，兼顧規則的人機可讀性和高度靈活性。
- JSON 格式的每個元素都具有明确的名 (name)，這就給了書寫者一個基本的架構和自說明的參數指引，既友善了自己書寫規則，也便于其他人對規則的維護。
- iWall3 規則具有明确細緻的文法定義，進而能夠使用成熟的 JSON schema 方式來校驗 (validate) 規則的正确性，例如可以細緻檢查動作的必選參數、可選參數以及拼寫錯誤。
2. 規則結構
一個規則即為一個
if-then-else
結構，在 JSON 格式中表現為一個名為
if
的對象和一個名為
then
的對象，以及可選的一個名為
else
的對象——
- if - 變量經選擇和整形後，與表達式模式的運算進行比對。支援用邏輯運算符連接配接多個條件。
- then - 比對後執行的一般語句和裁決語句，還可以包含子
if-then
- else - 不比對時執行的語句和可選的子
if-then
以下是規則的一個舉例：
{
"if": {
"variable": "REQUEST_FILENAME_EXT",
"operator": "inFromFile",
"pattern": "restricted_file_exts.lst"
},
"then": {
"if": {
"variable": "REMOTE_ADDR",
"operator": "begin",
"pattern": "192.168"
},
"then": {
"verdict": {
"log": true,
"action": "pass"
},
"actions": [{
"action": "alterArgGet",
"op": "set",
"name": "iwall_rule_id",
"value": "${RULE.id}"
}],
},
"else": {
"verdict": {
"log": true,
"action": "deny"
}
}
}
}
上述規則實作的功能為： 遇到通路敏感檔案類型時，記錄日志，并對不同通路來源作不同響應：來自内網的，放行且将規則 id 作為參數傳給後端應用；來自外網的，則拒絕。
3. 自動循環
一般程式設計語言中都有名為
for
的循環語句，用來對可疊代資料進行逐個元素處理。HTTP 協定中的請求參數 (args)、頭 (header) 都是可疊代資料，在 iWall3 中表現為集合或者數組的資料類型。如果按照程式設計語言的慣例，用
for
循環去顯式地擷取資料，會讓規則寫得很繁瑣。
iWall3 則實作了對可疊代變量類型的自動循環，隻需列出變量名，即可自動進行循環疊代，簡化了書寫。而對于不需要參與循環的元素，也提供了成員篩選的手段，直接在變量名後列出白名單或黑名單成員即可。
{
"if": {
"variable": "REQUEST_COOKIES:!cnzz_*",
"transform": "urlDecodeUni",
"operator": "detectSQLi"
}
}
上述規則對請求 cookie 中的每個成員進行 SQL 注入檢查，但排除掉 cnzz_ 開頭的成員。
4. 動态修改
規則并非是靜态孤立的，它不僅可以自身執行動作，還可以在 HTTP 會話過程中去改變其他規則的屬性，稱為元屬性覆寫。元屬性覆寫功能實作了運作時的檢測和動作分離，通過動态調整其他規則的輸入和響應，滿足使用者複雜的需求。
{
"if": [{
"variable": "REQUEST_FILENAME",
"operator": "=",
"pattern": "admin.php"
},
{
"variable": "TIME.hour",
"operator": "<",
"pattern": "8"
}],
"then": {
"actions": [{
"action": "alterRuleMeta",
"rules": "10001,30001-30999",
"meta": {
"severity": "warning",
"abnormal_weight": 15
}
}]
}
}
上述規則的功能是： 在 0:00am-8:00am 這一時間段内通路 admin.php 時，部分規則的緊急度将被設為 critical，異常權值則被設為 15。
三、針對HTTP協定的定制
天存資訊的 iWall3 的目标是實作 Web 應用防護，是以在語言設計上也有與 HTTP 協定密切相關的因素。
1. 資料類型
與程式設計語言中的變量一樣，iWall3 的變量也具有多種資料類型。其中有些資料類型是專門針對 HTTP 協定而設計的，如：
| 集合類型 | 結構類型 |
|---|---|
| 允許同名的成員。HTTP 協定允許出現同名的請求參數和頭，用集合類型來展現名-值對而非鍵-值對。 | 允許使用 XPath 和 JsonPath 來指定元素，對 XML 和 JSON 類型的請求資料能夠更精細地處理。 |
2. 持久變量
iWall3 的使用者變量具有自己的生命期。在語言層面，iWall3 不僅提供了 HTTP 會話期内有效的事務内變量，也提供了跨越 HTTP 會話的持久變量。
持久變量提供了跨越 HTTP 事務的儲存、計算和讀取資料的機制。這樣，Web 應用防護的邏輯就不局限于單個 HTTP 會話，而是可以在多個 HTTP 會話間建立聯系。
3. 狀态維護
HTTP 協定本身是無狀态的，這意味着沒有“使用者”的概念。但在防護功能上，我們又需要有一個“使用者”的概念，這樣才能将多個 HTTP 事務關聯起來，制定針對“使用者”的防護措施。
iWall3 提供了主體的概念，它是 HTTP 事務的發起端和通路者。對于每個 HTTP 事務，可以從裝置、網絡和封包等不同層面采集資訊，得到多個類型的主體。如此，書寫者能夠對多個 HTTP 事務中的同一主體應用規則 (如長時間攔截) 和共享資料 (如權重計算)。
四、有什麼用
使用類程式設計 WAF，安全人員不再是規則的使用者，而變成了規則的生産者。針對應用的細緻和獨立的安全需求，基本上都可以用程式設計的方式實作出來，不再受限于 WAF 産品提供的内置功能。
如本文開頭所述的功能需求，即使僅僅在防範注入方面：
- 某個域名或某些特定的 URL 不需要注入檢查；
- 對來自外網的注入通路進行攔截，來自内網的注入通路隻記錄，不攔截；
- 對特定的請求參數名或特定特征的請求參數不進行注入檢查；
- 非工作時段不僅攔截還阻止該使用者一段時間通路；
- 對 admin 等管理賬号登入後的通路不進行注入檢查；
- 對于隻記錄不攔截的請求，附加一個特别的請求頭發往應用；
- 對某些 URL 的注入通路，記錄下 HTTP 請求的全部封包；
- HTTP 響應碼為 500 的注入的日志緊急度設為 alert；
- 對疑似的注入企圖不做一次攔截，而是進行權重計算。
無論是上述某一條還是更複雜的組合，安全人員都可以在使用者現場通過高度靈活的類程式設計 iWall3 來實作。