HTTP 关键字

1.http 请求关键字

图1 图2

2.http响应关键字

图3 图4

3.关键字解释

3.1 http_method

使用http_method内容修饰符，可以专门匹配并仅在HTTP方法缓冲区上匹配。关键字可以组合使用与所有上一篇suricata规则提到的内容如：depth，distance，offset，nocase和within。

http方法有：GET，POST，PUT，HEAD， DELETE，TRACE，OPTIONS，CONNECT和PATCH。

示例：

图5

3.2 http_uri和http_raw_uri 

使用http_uri和http_raw_uri内容修饰符，可以特定地匹配请求URI缓冲区。关键字可以组合使用与所有上一篇suricata规则提到的内容如：depth，distance，offset，nocase和within。

uri在suricata中出现两次：raw_uri和规范化的uri。例如，空格可以用十六进制符号％20表示。要在空格中转换此表示法，意味着将其标准化。虽然可以匹配uri中字符％20的特定内容。这意味着匹配raw_uri。raw_uri和规范化的uri是单独的缓冲区。因此，raw_uri检查raw_uri缓冲区并且无法检查规范化缓冲区。

示例：

图6

3.3 uricontent

该uricontent关键字与 http_uri有完全一样的效果。uricontent是一种不推荐使用（虽然仍然支持）的方式，只能在请求URI缓冲区上进行匹配。在创建新规则时，建议使用http_uri修饰符而不是弃用的uricontent。

示例：

图6

http_uri和uricontent之间的语法区别：

图7

3.4 urilen

该urilen关键字用于匹配请求URI的长度。可以使用 < 和 > 运算符，它们分别表示小于和大于.格式如下：

urilen:3;

urilen:>1;

urilen:<10;

urilen:10<>20;   （大于10，小于20）

示例：

图8

3.5 http_protocol 

http_protocol检查从HTTP请求或响应协议字段。如果请求行是'GET /HTTP/1.0rn'，则此缓冲区将包含'HTTP/1.0'。

示例：

alerthttpanyany->anyany(flow:to_server;http_protocol;content:"HTTP/1.0";sid:1;)

3.6  http_request_line

http_request_line确保整个HTTP请求行被检测。

示例：

alerthttpanyany->anyany(http_request_line;content:"GET / HTTP/1.0";sid:1;)

3.7 http_header  和 http_raw_header

使用http_header内容修饰符，可以专门匹配并仅在HTTP头缓冲区上匹配。这包含单个缓冲区中的所有提取的头部，除了文档中指示的那些无法通过此缓冲区匹配并具有自己的内容修饰符（例如http_cookie）的头部。关键字可以组合使用与所有上一篇suricata规则提到的内容如：depth，distance，offset，nocase和within。

标头缓冲区已标准化。删除任何尾随空格和制表符。为避免这种情况，请使用http_raw_header关键字。

示例：

图9

3.8 http_cookie

使用http_cookie内容修饰符，可以专门匹配cookie缓冲区。关键字可以组合使用与所有上一篇suricata规则提到的内容如：depth，distance，offset，nocase和within。请注意，cookie在HTTP头部中传递，但会被提取到专用缓冲区并使用其自己的特定内容修饰符进行匹配。

示例：

图10

3.9 http_user_agent

http_user_agent内容修饰符是HTTP请求报头的一部分。它使得可以特定地匹配User-Agent头部的值。它是标准化的，它不包括_“User-Agent：”_标题名称和分隔符，也不包含尾随回车符和换行符（CRLF）。关键字可以组合使用与所有上一篇suricata规则提到的内容如：depth，distance，offset，nocase和within。请注意，cookie在HTTP头部中传递，但会被提取到专用缓冲区并使用其自己的特定内容修饰符进行匹配。

示例:

图11

说明：

a.http_user_agent缓冲区将不包括头名，冒号，或导致空白。即它不包括“User-Agent：”。

b.http_user_agent缓冲器不包括在最后一个CRLF符（0x0D 0x0A）。如果要匹配缓冲区的末尾，请使用相对isdataat或PCRE（尽管PCRE的性能会更差）。

c.如果请求包含多个“User-Agent”标头，则值将在http_user_agent缓冲区中按照从上到下的顺序连接，每个值之间使用逗号和空格（“，”）

如：

GET/test.htmlHTTP/1.1

User-Agent:SuriTester/0.8

User-Agent:GGGG

http_user_agent 缓冲内容：

SuriTester/0.8,GGGG

3.10 http_accept

在HTTP Accept头部上匹配的缓冲区。仅包含头部值。标头后面的\ r \ n不是缓冲区的一部分。

示例：alerthttpanyany->anyany(http_accept;content:"image/gif";sid:1;)

3.11 http_accept_enc

在HTTP Accept-Encoding头部上匹配的缓冲区。仅包含头部值。标头后面的\r\n不是缓冲区的一部分。

示例：alerthttpanyany->anyany(http_accept_enc;content:"gzip";sid:1;)

3.12 http_accept_lang

在HTTP Accept-Language头部上匹配的缓冲区。仅包含头部值。标头后面的\r\n不是缓冲区的一部分。

示例：alerthttpanyany->anyany(http_accept_lang;content:"en-us";sid:1;)

3.13 http_connection

在HTTP Connection头部上匹配的缓冲区。仅包含头部值。标头后面的\r\n不是缓冲区的一部分。

示例：alerthttpanyany->anyany(http_connection;content:"keep-alive";sid:1;)

3.14 http_content_type

在HTTP Content-Type头部匹配缓冲区。仅包含头部值。标头后面的\r\n不是缓冲区的一部分。

使用flow：to_server或flow：to_client强制检查请求或响应

示例：

alert http any any -> any any (flow:to_server;http_content_type;content:"x-www-form-urlencoded";sid:1;)

alert http any any->any any (flow:to_client;http_content_type;content:"text/javascript";sid:2;)

3.15 http_content_len

在HTTP Content-Length头部上匹配的缓冲区。仅包含头部值，头部后面的\r\n不是缓冲区的一部分。

使用flow：to_server或flow：to_client强制检查请求或响应

示例：

alert  http  any  any->any  any (flow:to_server;http_content_len;content:"666";sid:1;)

alert http  any  any->any any (flow:to_client;http_content_len;content:"555";sid:2;)

要对内容长度进行数字检查，byte_test可以使用。

示例：如果C-L等于或大于8079，则匹配

alert http any any-> any any (flow:to_client;http_content_len;byte_test:0,>=,8079,0,string,dec;sid:3;)

3.16 http_referer

在HTTP Referer头部上匹配的缓冲区。仅包含头部值。标头后面的\r\n不是缓冲区的一部分。

示例：alert http any any -> any any(http_referer;content:".php";sid:1;)

3.17 http_start

检查HTTP请求或响应的开始。这将包含请求/响应行以及请求/响应头。

使用flow：to_server或flow：to_client强制检查请求或响应。

示例：

alert http any any->any any(http_start;content:"HTTP/1.1|0d 0a|User-Agent";sid:1;)

缓冲区包含规范化的头部，并由额外的\r\n终止以指示头部的结尾

3.18 http_header_names

检查仅包含HTTP头部名称的缓冲区。用于确保标头不存在或测试特定顺序的头部。缓冲区以\r\n开头，以额外的\r\n结尾。

示例缓冲区：

\\r\\nHost\\r\\n\\r\\n

示例:

alert http any any -> any any (http_header_names;content:"|0d 0a|Host|0d 0a|";sid:1;)

确保仅存在Host的示例:

alert http any any -> any any (http_header_names;content:"|0d 0a|Host|0d 0a 0d 0a|";sid:1;)

确保User-Agent直接在Host之后的示例:

alert http any any -> any any (http_header_names;content:"|0d 0a|Host|0d 0a|User-Agent|0d 0a|";sid:1;)

确保User-Agent在Host之后的示例，但不一定在以下之后：

alert http any any -> any any (http_header_names;content:"|0d 0a|Host|0d 0a|";content:"|0a 0d|User-Agent|0d 0a|";distance:-2;sid:1;)

3.19 http_client_body

使用http_client_body内容修饰符，可以特定地匹配HTTP请求主体.关键字可以组合使用与所有上一篇suricata规则提到的内容如：depth，distance，offset，nocase和within。

示例：

图12

注意：通过设置libhtp配置部分request-body-limit，控制检查请求/客户端 主体的数量。libhtp配置查看suricata配置文件。

3.20 http_stat_code

使用http_stat_code内容修饰符，可以专门匹配HTTP状态代码缓冲区。关键字可以组合使用与所有上一篇suricata规则提到的内容如：depth，distance，offset，nocase和within。

示例：

图13

3.21 http_stat_msg

使用http_stat_msg内容修饰符，可以特定地匹配HTTP状态消息缓冲区.关键字可以组合使用与所有上一篇suricata规则提到的内容如：depth，distance，offset，nocase和within。

图14

3.22 http_response_line

http_response_line确保在整个HTTP响应行被检测。

示例：

alert http any any -> any any (http_response_line;content:"HTTP/1.0 200 OK";sid:1;)

3.23 http_server_body

使用http_server_body内容修饰符，可以专门匹配并仅在HTTP响应主体上匹配。关键字可以组合使用与所有上一篇suricata规则提到的内容如：depth，distance，offset，nocase和within。

注意：通过设置libhtp配置部分response-body-limit，控制检查请求/服务端主体的数量。libhtp配置查看suricata配置文件。

说明：

a.使用http_server_body类似于具有之后的内容匹配的file_data除了它不是永久地（除非重置）将检测指针设置为服务器响应主体的开头。即它不是一个粘性缓冲区。

b.http_server_body将匹配gzip解码数据就像 file_data那样。

c.由于http_server_body服务器响应匹配，因此不能与to_server或from_client f流指令一起使用。

d.相应的PCRE修饰符： Q

e.file_data以下部分的进一步说明

3.24 http_host 和http_raw_host

使用http_host内容修饰符，可以专门匹配并仅匹配规范化的主机名。该http_raw_host检查的原始主机名。关键字可以组合使用与所有上一篇suricata规则提到的内容如：depth，distance，offset等。

nocase不再允许使用该关键字。请记住，您需要指定小写模式。

说明：

a.http_host和http_raw_host缓冲区从任一URI填充（如果完整的URI存在于就像在一个代理请求的请求）或HTTP Host头。如果两者都存在，则使用URI。

b.在http_host和http_raw_host缓冲区将不包括头名，冒号或前导空格，如果从主机头填充。即他们不会包括“Host：”。

c.在http_host与http_raw_host缓冲器不包括在最后一个CRLF（0X0D 0x0A）。如果要匹配缓冲区的末尾，请使用相对的“isdataat”或PCRE（尽管PCRE的性能会更差）。

d.该http_host缓冲器被归一化至全部小写。

e.http_host适用的内容匹配必须全部小写或nocase设置标志。

f.http_raw_host匹配非标准化缓冲区，因此匹配将区分大小写（除非nocase已设置）。

g.如果请求包含多个“主机”头部，则值将按照 从上到下的顺序在http_host和http_raw_host缓冲区中连接，并在每个标头之间使用逗号和空格（“，”）。

示例（请求）：

GET/test.htmlHTTP/1.1

Host:ABC.com

Accept:*/*

Host:efg.net

http_host缓冲区：abc.com,efg.net

http_raw_host缓冲区：ABC.com,efg.net

相应的PCRE修饰符（http_host）: W

相应的PCRE修饰符（http_raw_host）：Z

3.25 file_data

使用file_data，检查HTTP响应正文，就像使用http_server_body。该file_data关键字的工作有点不同于正常内容匹配; 在规则中使用时，规则中跟随它的所有内容匹配都会受到影响（修改）。

示例：

alert http any any -> any any(file_data;content:"abc";content:"xyz";)

图15

该file_data关键字影响以后的所有内容匹配，直到遇到pkt_data关键字或到达规则的结束。这使得它成为将许多内容匹配应用于HTTP响应主体的有用快捷方式，从而无需单独修改每个内容匹配。

由于HTTP响应的主体可能非常大，因此会以较小的块进行检查。

注意：通过设置libhtp配置部分response-body-limit，控制检查请求/服务端主体的数量。libhtp配置查看suricata配置文件。

如果HTTP主体是使用'deflate'或'lzma'压缩的flash文件，它可以解压缩并且file_data可以匹配解压缩数据。必须在libhtp配置下启用Flash解压缩：

图15

说明：

a.如果HTTP正在使用gzip或deflate，file_data则会对解压缩的数据进行匹配

b.否定匹配受到分块检查的影响。例如:'content:!"<html";' 。在第一个块上无法匹配，但可能在第二个块上匹配。要避免这种情况，请使用深度设置。深度设置考虑了体型。假设它response-body-minimal-inspect-size大于1k，‘content:!”<html”; depth:1024;’  只有在第一个被检查的块中没有模式'<html'时才能匹配。

c.file_data 也可以用于SMTP