Crs規則中默認inbound_anomaly_score_threshold=5閾值5
paranoia_level=1 嚴格等級默認爲1，調高會匹配高等級規則
critical_anomaly_score=5命中嚴重異常規則的請求會加5分
error_anomaly_score=4 命中錯誤異常規則的請求會加4分
warning_anomaly_score=3 命中警告異常的請求會加3分
notice_anomaly_score=2 命中提示異常的請求會加2分
全部採用默認配置，選用全部默認規則結果如下
產生較多誤報
分析誤報請求
[12, 26, 28, 32, 39, 51, 56, 58, 89, 91, 94, 99, 111, 133, 140, 149, 152, 164, 197, 199, 209, 218, 226, 227, 229, 232, 236, 263, 276, 281, 288, 290, 307, 312, 315, 323, 330, 336, 341, 352, 353, 355, 383, 389, 391, 392, 399, 402, 403, 411, 412, 416, 428, 438, 454, 467, 472, 483, 484, 489, 491, 497, 498, 499, 501, 503, 526, 538, 549, 575, 587, 595, 596, 599, 608, 616, 618, 625, 651, 655, 657, 659, 677, 699, 736, 764, 767, 781, 785, 797, 845, 854, 884, 892, 908, 925, 932, 955, 959, 977, 982, 986, 997, 1003, 1004, 1048, 1068, 1073, 1095, 1102, 1125, 1160, 1173, 1192, 1193, 1195, 1205, 1215, 1221, 1224, 1235, 1236, 1240, 1259, 1262, 1264, 1270, 1274, 1296, 1314, 1320, 1328, 1332, 1333, 1342, 1362, 1365, 1369, 1380, 1382, 1392, 1403, 1404, 1424, 1445, 1451, 1466, 1477, 1481, 1490, 1509, 1517, 1546, 1552, 1574, 1584, 1595, 1596, 1626, 1627, 1646, 1658, 1691, 1698, 1700, 1731, 1733, 1741, 1756, 1760, 1771, 1777, 1808, 1824, 1831, 1846]
攔截日誌如下
2019/09/26 11:46:43 [error] 10616#0: *42 [lua] waf.lua:494: _process_rule(): 943120 collection...0 pattern...0..value....0...rule.var...{["type"]="REQUEST_HEADERS",["length"]=true,["collection_key"]="REQUEST_HEADERS|specific|Referer",["parse"]={[1]="specific",[2]="Referer",},}, client: 10.232.132.53, server: cert.placuna.cn, request: "GET /mobsong_notfound.html HTTP/1.1", host: "cert.placuna.cn:8080"
2019/09/26 11:46:43 [error] 10616#0: *42 [lua] waf.lua:519: _process_rule(): after match rule.actions...{["disrupt"]="SCORE",["nondisrupt"]={[1]={["data"]={["value"]="%{rule.msg}",["key"]="MSG",["col"]="TX",},["action"]="setvar",},[2]={["data"]={["inc"]=true,["value"]="%{TX.CRITICAL_ANOMALY_SCORE}",["key"]="SESSION_FIXATION_SCORE",["col"]="TX",},["action"]="setvar",},[3]={["data"]={["inc"]=true,["value"]="%{TX.CRITICAL_ANOMALY_SCORE}",["key"]="ANOMALY_SCORE_PL1",["col"]="TX",},["action"]="setvar",},[4]={["data"]={["value"]="%{TX.0}",["key"]="943120-OWASP_CRS/WEB_ATTACK/SESSION_FIXATION-REQUEST_HEADERS",["col"]="TX",},["action"]="setvar",},},}, client: 10.232.132.53, server: cert.placuna.cn, request: "GET /mobsong_notfound.html HTTP/1.1", host: "cert.placuna.cn:8080"
從攔截日誌中可以看出爲id爲943120的規則誤攔
將規則文件REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf屏蔽掉
再測
誤報基本沒有
召回率由70.422%下降至66.549%、
研究session會話攻擊的規則，id:943120爲鏈式規則，第一步先匹配請求中是否有特殊sessionid字段，如果沒有不攔截，如果有進入第二步，判斷此請求的header中是否有referer，如果有則不攔截，沒有則對此請求增加critical得分=5，默認閾值爲5，所以直接觸發攔截行爲。所以對此邏輯造成誤報率過高的初步解決方法是將critical得分改爲warning得分3，來降低誤報率。
修改後測試結果
相當於把943文件屏蔽掉了。
探究召回率下降的原因。修改後增加的漏報的請求爲
[11, 82, 122, 128, 462, 463, 508, 552, 610, 634, 682, 722, 734, 746, 911, 987, 1098, 1138, 1176, 1199, 1223, 1263, 1371, 1439, 1498, 1570, 1614, 1619, 1692, 1727, 1847, 1848, 1849]
即這些請求在未修改前會被943規則阻攔。
（在此過程中發現500錯誤）
2019/09/27 17:44:45 [error] 7067#0: *5 lua entry thread aborted: runtime error: .../kswaf/openresty20190423/waf_lua_ng/resty/core/regex.lua:374: attempt to get length of local 'subj' (a number value)
原因是在初始化階段向matched_var中寫入數字，後面的等級2規則中需要對.data文件中的字符串和matched_var中的內容進行匹配，匹配方式爲refind，這要求其不能爲數字，否則會報錯。
解決辦法：在向寫入matched_var寫入數據時加一層數據類型校驗避免這一錯誤
繼續分析943處理後增加的漏報問題
[11, 82, 122, 128, 462, 463, 508, 552, 610, 634, 682, 722, 734, 746, 911, 987, 1098, 1138, 1176, 1199, 1223, 1263, 1371, 1439, 1498, 1570, 1614, 1619, 1692, 1727, 1847, 1848, 1849]
將943的規則文件調值默認發送上述單個請求。
請求的行號: 11
請求的label: 1
響應狀態: 403
method: GET
urlpath: /jobs/jobs-list.php?key=%C7%EB%CA%E4%C8%EB%D6%B0%CE%BB%C3%FB%B3%C6%A1%A2%B9%AB%CB%BE%C3%FB%B3%C6%A1%A2%BC%BC%C4%DC%CC%D8%B3%A4%A1%A2%D1%A7%D0%A3%B5%C8%B9%D8%BC%FC%D7%D6...&Submit=%CB%D1%D6%B0%CE%BB%22%20and%20%22a%22=%22a
postbody: None
headers: {'Cookie': 'PHPSESSID=45a1i8dljhmcp4bfm5bdv7c6u0', 'User-Agent': 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322)'}
其中11,82,122,128,463,508,552,682,610,634,722,734,911,1176,1263,1371, 1498,1570,1614,1692,1727,1847,1848,1849爲疑似sql注入請求,加粗部分sql注入在 body中，所以lable爲1，但實際攔截爲943文件，攔截依據是cookie中含有sessionid字段且無referer。
746,987,1098,1138,1199,1223,1439,1619爲疑似會話固定攻擊
漏報猜測：sql注入漏報，sql注入規則等級過低。
初步處理方式，單獨調高sql注入攔截的等級，看誤報是否會減少。
結果
因爲每個等級有每個等級的得分，只有當默認等級設置爲跟高等級，阻斷時纔會將各個等級的得分相加，所以單獨設置某個規則文件的等級對阻斷是沒有意義的，但是可以從日誌中查看是否會命中高等級的規則。
（調試過程中遇到轉碼問題，發現1849請求中的unicode在解析過程中沒有被轉碼，導致規則匹配不成功，調試do_transform函數，解決辦法：保留緩存命中率高的collection_key
的格式，在第一次遇到緩存未命中時對數據進行全部類型解碼，之前進行的是replacetr和alltransform兩種解碼，造成解碼不完全的問題。）
2019/09/29 18:21:02 [error] 12468#0: *11 [lua] waf.lua:496: _process_rule(): 942130 collection...{[1]="45a1i8dljhmcp4bfm5bdv7c6u0",[2]="λ˾ѧУ...",[3]="λ and a=a",} pattern...(?i:([\s'"`\(\)]*?)([\d\w]++)([\s'"`\(\)]*?)(?:<(?:=(?:([\s'"`\(\)]*?)(?!\2)([\d\w]+)|>([\s'"`\(\)]*?)(?:\2))|>?([\s'"`\(\)]*?)(?!\2)([\d\w]+))|(?:not\s+(?:regexp|like)|is\s+not|>=?|!=|\^)([\s'"`\(\)]*?)(?!\2)([\d\w]+)|(?:(?:sounds\s+)?like|r(?:egexp|like)|=)([\s'"`\(\)]*?)(?:\2)))..value....table: 0x400b8250...rule.var...{["type"]="REQUEST_ARGS",["collection_key"]="REQUEST_ARGS|values|true",["parse"]={[1]="values",[2]=true,},}, client: 10.232.11.16, server: cert.placuna.cn, request: "GET /jobs/jobs-list.php?key=%C7%EB%CA%E4%C8%EB%D6%B0%CE%BB%C3%FB%B3%C6%A1%A2%B9%AB%CB%BE%C3%FB%B3%C6%A1%A2%BC%BC%C4%DC%CC%D8%B3%A4%A1%A2%D1%A7%D0%A3%B5%C8%B9%D8%BC%FC%D7%D6...&Submit=%CB%D1%D6%B0%CE%BB%22%20and%20%22a%22=%22a HTTP/1.1", host: "cert.placuna.cn:8080"
2019/09/29 18:21:02 [error] 12468#0: *11 [lua] waf.lua:521: _process_rule(): after match rule.actions...{["disrupt"]="SCORE",["nondisrupt"]={[1]={["data"]={["value"]="%{rule.msg}",["key"]="MSG",["col"]="TX",},["action"]="setvar",},[2]={["data"]={["inc"]=true,["value"]="%{TX.CRITICAL_ANOMALY_SCORE}",["key"]="SQL_INJECTION_SCORE",["col"]="TX",},["action"]="setvar",},[3]={["data"]={["inc"]=true,["value"]="%{TX.CRITICAL_ANOMALY_SCORE}",["key"]="ANOMALY_SCORE_PL2",["col"]="TX",},["action"]="setvar",},[4]={["data"]={["value"]="%{TX.0}",["key"]="%{RULE.ID}-OWASP_CRS/WEB_ATTACK/SQL_INJECTION-%{MATCHED_VAR_NAME}",["col"]="TX",},["action"]="setvar",},},}, client: 10.232.11.16, server: cert.placuna.cn, request: "GET /jobs/jobs-list.php?key=%C7%EB%CA%E4%C8%EB%D6%B0%CE%BB%C3%FB%B3%C6%A1%A2%B9%AB%CB%BE%C3%FB%B3%C6%A1%A2%BC%BC%C4%DC%CC%D8%B3%A4%A1%A2%D1%A7%D0%A3%B5%C8%B9%D8%BC%FC%D7%D6...&Submit=%CB%D1%D6%B0%CE%BB%22%20and%20%22a%22=%22a HTTP/1.1", host: "cert.placuna.cn:8080"
從日誌中發現，sql注入規則文件的二三四等級均有對當前漏報產生critical等級的提醒，證明這些請求對於crs規則來說並不算是漏報，只是crs認爲這些請求只有在嚴格要求的時候纔會阻攔，正常模式下是會放過這些請求的。所以目前的調整策略是優先遵從crs規則，後期根據實際場景和業務再進行調整。
繼續分析誤報請求
[164, 352, 596, 659, 767, 1365, 1731]
149和596爲底層默認規則攔截誤報。
請求352請求內容及相應狀態如下
攔截的日誌如下：
分析日誌可知，該請求被規則id941130（xss）的var攔截
[2] => table: 0x656b80 {
[type] => "COOKIES"
[collection_key] => "COOKIES|keys|true"
[parse] => table: 0x657000 {
[1] => "keys"
[2] => true
}
}
因爲該請求的cookie的key爲‘union-indexhtml’，匹配到了 (?i)[\s\S](?:x(?:link:href|html|mlns)|!ENTITY.*?SYSTEM|data:text\/html|pattern(?=.*?=)|formaction|\@import|base64)\b，命中後的action爲下，直接加一個critical得分（5）導致攔截。
[3] => table: 0x658bb0 {
[data] => table: 0x659010 {
[value] => "%{TX.CRITICAL_ANOMALY_SCORE}"
[key] => "ANOMALY_SCORE_PL1"
[inc] => true
[col] => "TX"
}
[action] => "setvar"
}
規則解析如下
解決方法：先將此條規則屏蔽，後期研究此條規則（941130）的優化。
解決後誤報消除，漏報沒有增加。
至此，誤報問題解決，接下來研究漏報請求
請求11如下：
urlpath: /jobs/jobs-list.php?key=%C7%EB%CA%E4%C8%EB%D6%B0%CE%BB%C3%FB%B3%C6%A1%A2%B9%AB%CB%BE%C3%FB%B3%C6%A1%A2%BC%BC%C4%DC%CC%D8%B3%A4%A1%A2%D1%A7%D0%A3%B5%C8%B9%D8%BC%FC%D7%D6...&Submit=%CB%D1%D6%B0%CE%BB%22%20and%20%22a%22=%22a
postbody: None
headers: {'Cookie': 'PHPSESSID=45a1i8dljhmcp4bfm5bdv7c6u0', 'User-Agent': 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322)'}
不會被crs攔截，但是sql注入引擎942130會在level2等級對其產生critical得分，嘗試將此條規則寫入level1,。查看結果漏報減少約10%，但是此條規則會增加10%的誤報。誤報請求如下{[1]="cnzz_eid=1850184636-1394596016-http%3a%2f%2fwww.yaose.net%2f&ntime=1394596016&cnzz_a=2&sin=none<ime=1394595991292"
會命中“n=n”產生誤報
處理方法：將此條規則設置爲level2等級，遵從crs本身設定，後期研究此條規則942130，消除誤報
除信息泄露等低危請求漏報，剩餘漏報如下：
[11, 13, 48, 49, 53, 67, 79, 81, 82, 105, 113, 122, 124, 127, 128, 131, 139, 142, 145, 161, 168, 175, 177, 180, 193, 212, 214, 238, 246, 254, 333, 344, 357, 367, 370, 375, 397, 409, 410, 413, 419, 430, 444, 445, 449, 459, 463, 488, 508, 517, 520, 533, 552, 554, 555, 558, 562, 566, 581, 591, 598, 610, 620, 629, 634, 654, 668, 674, 682, 704, 705, 722, 734, 737, 746, 768, 772, 780, 788, 808, 836, 856, 870, 873, 879, 906, 911, 915, 917, 924, 931, 935, 936, 949, 952, 953, 965, 987, 994, 1013, 1024, 1025, 1027, 1050, 1053, 1062, 1078, 1085, 1088, 1113, 1117, 1121, 1129, 1135, 1138, 1144, 1167, 1176, 1199, 1203, 1214, 1223, 1243, 1263, 1279, 1282, 1315, 1319, 1331, 1351, 1354, 1356, 1360, 1371, 1374, 1401, 1405, 1412, 1415, 1423, 1434, 1439, 1443, 1446, 1449, 1470, 1473, 1479, 1488, 1498, 1529, 1544, 1558, 1560, 1567, 1570, 1571, 1577, 1585, 1591, 1598, 1599, 1610, 1614, 1618, 1619, 1632, 1648, 1652, 1676, 1684, 1685, 1692, 1696, 1701, 1718, 1727, 1737, 1740, 1750, 1751, 1781, 1786, 1794, 1796, 1805, 1810, 1833, 1834, 1840, 1847, 1848, 1849]
此類漏報大部分爲sql注入和php代碼注入漏報
如1840-1849
請求如下method: GET
urlpath: /user/category/1)%20AND%20(SELECT%204037%20FROM(SELECT%20COUNT(*),CONCAT(CHAR(58,100,114,108,58),(SELECT%20(CASE%20WHEN%20(4037=4037)%20THEN%201%20ELSE%200%20END)),CHAR(58,122,103,111,58),FLOOR(RAND(0)*2))x%20FROM%20information_schema.tables%20GROUP%20BY%20x)a)%20AND%20(9909=9909
postbody: None
headers: {'User-Agent': 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)'}
經一系列轉碼後出現sql注入特殊字符
解決方法：增加base64解碼功能。結果如下
減少了漏報，持續優化中。。。