轉(zhuǎn)自：http://blog.csdn.net/wuyangbotianshi/article/details/44854121
1.簡介
之前的常用關(guān)鍵字中介紹了content以及許多修飾它的關(guān)鍵字谱仪，除此之外，http協(xié)議中還有一些修飾content的關(guān)鍵字，也是由于http協(xié)議使用量較大，關(guān)鍵字較多抡驼，因此單獨拿出來學習屿附。參考：HTTP協(xié)議-維基百科。
2.Request和Response
http協(xié)議包括了http request和http response數(shù)據(jù)包葱色。通常卸伞，由HTTP客戶端發(fā)起一個request請求抹镊，創(chuàng)建一個到服務器指定端口（默認是80端口）的TCP連接。HTTP服務器則在那個端口監(jiān)聽客戶端的請求荤傲。一旦收到請求垮耳，服務器會向客戶端返回一個狀態(tài)，比如”HTTP/1.1 200 OK”遂黍，以及返回的內(nèi)容终佛，如請求的文件、錯誤消息雾家、或者其它信息铃彰。
2.1 http request
http request請求包括請求行、請求頭芯咧、空行和內(nèi)容豌研。一個普通的request請求如下：
紅框部分是請求行，GET表示http method唬党，除了GET還有POST,PUT,HEAD等；后面的/webshell/c99_locus7s.php則是http uri鬼佣；HTTP/1.1則是版本驶拱，可以是0.9、1.0和1.1晶衷。綠框部分是請求頭蓝纲，也就是http head阴孟，除了HOST字段必須要有，其余字段都是可選的税迷。藍框部分是空行永丝，只允許有\(zhòng)r\n。由于這個包是GET方法箭养，因此沒有內(nèi)容慕嚷，如果是POST等方法后面會跟上內(nèi)容。
2.2 http response
http response應答包括應答行毕泌，頭部喝检，空行和內(nèi)容，整體結(jié)構(gòu)和request差不多撼泛，下圖是針對上節(jié)request的應答包：
紅框部分挠说，HTTP/1.1是http版本，后面的200是返回的狀態(tài)碼愿题，OK是狀態(tài)信息损俭。綠框部分是http header，藍框部分則是返回的html頁面潘酗，也就是結(jié)果杆兵。
3.HTTP關(guān)鍵字
3.1 http_method
http_method是content的修飾符，表示其所修飾的content只匹配http method部分崎脉。http可以使用的方法包括：GET, POST, PUT, HEAD, DELETE, TRACE, OPTIONS, CONNECT和PATCH拧咳。下面這個例子匹配GET方法，無論是否加http_method都能匹配：
但是下面這種情況就必須加http_method關(guān)鍵字囚灼，因為在http的uri部分也有GET：
3.2 http_uri和http_raw_uri
http_uri和http_raw_uri這兩個關(guān)鍵字都是說明所修飾的content是用來匹配http uri部分的內(nèi)容骆膝。所不同的是http_uri指在匹配之前先對URI進行標準化，所謂的標準化就是對數(shù)據(jù)包中的uri按照RFC文檔規(guī)定進行一定的轉(zhuǎn)化灶体，包括保留語義轉(zhuǎn)化阅签、一般保留語義轉(zhuǎn)化、改變語義轉(zhuǎn)化蝎抽。保留語義轉(zhuǎn)化有以下幾種,詳細的解釋參考URL標準化-維基百科：
將url中的協(xié)議政钟、域名等轉(zhuǎn)化為小寫，比如HTTP://www.Example.com/ → http://www.example.com/
將以%開頭的轉(zhuǎn)義字符中的字母轉(zhuǎn)化為大寫樟结，比如http://www.example.com/a%c2%b1b → http://www.example.com/a%C2%B1b
將以%開頭但在可見字符范圍內(nèi)的進行轉(zhuǎn)化养交，比如http://www.example.com/%7Eusername/ → http://www.example.com/~username/
移出默認的端口號，比如http對應的80端口
而http_raw_uri則是直接對uri進行匹配瓢宦。下面這兩個關(guān)鍵字用法的一個例子：
3.3 uricontent
uricontent的作用和http_uri相同碎连，都是匹配uri部分的，不同的是uricontent可以獨立使用驮履，相當于content+http_uri的效果鱼辙。但是官方文檔里說明這個關(guān)鍵字已經(jīng)被棄用廉嚼，但目前還對其進行支持。
3.4 http_header和http_raw_header
和http_uri一樣倒戏，http_header也是只匹配http的header部分的內(nèi)容（不包括cookie）怠噪，http_raw_header則是匹配沒有標準化過的header（參考HTTP header），簡單來說就是標準化的header在每個字段的結(jié)尾\r\n之前都會去掉其余的空白字符杜跷。兩個簡單的例子：
3.5 http_cookie
http_cookie從http_header中獨立出來傍念，但其使用方法和前幾個關(guān)鍵字并無區(qū)別，這里就直接貼出例子了：
3.6 http_user_agent
http_user_agent用于匹配http的User-Agent字段的內(nèi)容葱椭，它是http_header的一部分捂寿，但是把它單獨拿出來說明其出現(xiàn)的頻率比較高，用法與前幾個沒什么差別孵运。關(guān)于http_user_agent和http_header的性能對比可以參考Suricata http_user_agent vs http_header秦陋，得出的結(jié)論是http_user_agent比http_header要快大約10%，除此之外規(guī)則中使用http_user_agent的可讀性也比較好治笨。例子如下：
3.7 http_client_body和http_server_body
使用了這兩個修飾符的content表示只匹配http包中的內(nèi)容部分驳概，前者值匹配request包，而后者只匹配response旷赖。用法很簡單：
需要注意的是suricata會根據(jù)suricata.yaml配置文件中的libhtp小節(jié)對于這兩部分長度限制來進行匹配顺又，也就是說如果想要匹配的內(nèi)容在數(shù)據(jù)包中的長度超過了配置文件中的數(shù)值，則這條規(guī)則不會被匹配到等孵。目前自己的配置如下稚照，由于需要檢測webshell大馬，所以這里的response部分的值為40KB俯萌，而request則維持原來的默認配置：
3.8 http_stat_code和http_stat_msg
這兩個content修飾符分別匹配response應答包返回的狀態(tài)碼和狀態(tài)信息果录，例子如下：
3.9 file_data
file_data的作用和http_server_body差不多，都是使content匹配response body中的內(nèi)容咐熙，唯一不同的是使用了file_data關(guān)鍵字的規(guī)則弱恒，其在file_data之后的content都會受到它的影響。比如下面這條規(guī)則棋恼，值為”abc”和”xyz”的content都必須在response body里面匹配：
alert http any any -> any any (file_data; content:"abc"; content:"xyz";)
3.10 urilen
urilen關(guān)鍵字用于匹配http uri部分的長度返弹，可以使用<和>運算符，下面是幾個例子：
urilen:1; uri長度為1字節(jié)
urilen:>1; 大于1字節(jié)
urilen:<10; 小于10字節(jié)
urilen:10<>20; 10字節(jié)和20字節(jié)之間
除此之外還可以在后面指定是否以raw uri計算長度爪飘，下面表示以raw格式來計算的uri長度不超過5字節(jié)：
urilen:<5,raw;
4.小結(jié)
HTTP協(xié)議的檢測規(guī)則在所有規(guī)則中占有非常大的比例义起，比如2014年的bash破殼漏洞、2015年初的glibc ghost針對wordpress的攻擊都可以利用http數(shù)據(jù)包师崎。同時因為他也比很多其他規(guī)則要復雜并扇，因此關(guān)鍵字也更多，不過這些關(guān)鍵字用法大部分比較簡單，掌握起來也會比較容易穷蛹。
參考鏈接
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/HTTP-keywords#HTTP-keywords
http://zh.wikipedia.org/wiki/%E8%B6%85%E6%96%87%E6%9C%AC%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE
http://tools.ietf.org/html/rfc2616
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/HTTP-uri_normalization
http://en.wikipedia.org/wiki/URL_normalization
https://lists.openinfosecfoundation.org/pipermail/oisf-users/2011-October/000935.html
http://blog.inliniac.net/2012/07/09/suricata-http_user_agent-vs-http_header/
