1HTTP Keywords 2============= 3.. role:: example-rule-emphasis 4 5Using the HTTP specific sticky buffers provides a way to efficiently 6inspect specific fields of the HTTP protocol. After specifying a 7sticky buffer in a rule it should be followed by one or more doc:`payload-keywords`. 8 9Many of the sticky buffers have legacy variants in the older "content modifier" 10notation. See :ref:`rules-modifiers` for more information. As a 11refresher: 12 13* **'sticky buffers'** are placed first and all keywords following it apply to that buffer, for instance:: 14 15 alert http any any -> any any (http.response_line; content:"403 Forbidden"; sid:1;) 16 17 Sticky buffers apply to all "payload" keywords following it. E.g. `content`, `isdataat`, `byte_test`, `pcre`. 18 19* **'content modifiers'** look back in the rule, e.g.:: 20 21 alert http any any -> any any (content:"index.php"; http_uri; sid:1;) 22 23 Content modifiers only apply to the preceding `content` keyword. 24 25The following **request** keywords are available: 26 27============================== ======================== ================== 28Keyword Legacy Content Modifier Direction 29============================== ======================== ================== 30http.uri http_uri Request 31http.uri.raw http_raw_uri Request 32http.method http_method Request 33http.request_line http_request_line (*) Request 34http.request_body http_client_body Request 35http.header http_header Both 36http.header.raw http_raw_header Both 37http.cookie http_cookie Both 38http.user_agent http_user_agent Request 39http.host http_host Request 40http.host.raw http_raw_host Request 41http.accept http_accept (*) Request 42http.accept_lang http_accept_lang (*) Request 43http.accept_enc http_accept_enc (*) Request 44http.referer http_referer (*) Request 45http.connection http_connection (*) Request 46http.content_type http_content_type (*) Both 47http.content_len http_content_len (*) Both 48http.start http_start (*) Both 49http.protocol http_protocol (*) Both 50http.header_names http_header_names (*) Both 51============================== ======================== ================== 52 53\*) sticky buffer 54 55The following **response** keywords are available: 56 57============================== ======================== ================== 58Keyword Legacy Content Modifier Direction 59============================== ======================== ================== 60http.stat_msg http_stat_msg Response 61http.stat_code http_stat_code Response 62http.response_line http_response_line (*) Response 63http.header http_header Both 64http.header.raw http_raw_header Both 65http.cookie http_cookie Both 66http.response_body http_server_body Response 67http.server N/A Response 68http.location N/A Response 69file.data file_data (*) Response 70http.content_type http_content_type (*) Both 71http.content_len http_content_len (*) Both 72http.start http_start (*) Both 73http.protocol http_protocol (*) Both 74http.header_names http_header_names (*) Both 75============================== ======================== ================== 76 77\*) sticky buffer 78 79HTTP Primer 80----------- 81It is important to understand the structure of HTTP requests and 82responses. A simple example of a HTTP request and response follows: 83 84**HTTP request** 85 86:: 87 88 GET /index.html HTTP/1.0\r\n 89 90GET is the request **method**. Examples of methods are: GET, POST, PUT, 91HEAD, etc. The URI path is ``/index.html`` and the HTTP version is 92``HTTP/1.0``. Several HTTP versions have been used over the years; of 93the versions 0.9, 1.0 and 1.1, 1.0 and 1.1 are the most commonly used 94today. 95 96Example request with keywords: 97 98+--------------------------------+------------------+ 99| HTTP | Keyword | 100+--------------------------------+------------------+ 101| GET /index.html HTTP/1.1\\r\\n | http.request_line| 102+--------------------------------+------------------+ 103| Host: www.oisf.net\\r\\n | http.header | 104+--------------------------------+------------------+ 105| Cookie: **<cookie data>** | http.cookie | 106+--------------------------------+------------------+ 107 108Example request with finer grained keywords: 109 110+------------------------------------------+---------------------+ 111| HTTP | Keyword | 112+------------------------------------------+---------------------+ 113| **GET** */index.html* **HTTP/1.1**\\r\\n | **http.method** | 114| | *http.uri* | 115| | **http.protocol** | 116+------------------------------------------+---------------------+ 117| Host: **www.oisf.net**\\r\\n | **http.host** | 118| +---------------------+ 119| User-Agent: **Mozilla/5.0**\\r\\n | **http.user_agent** | 120+------------------------------------------+---------------------+ 121| Cookie: **<cookie data>** | **http.cookie** | 122+------------------------------------------+---------------------+ 123 124**HTTP response** 125 126:: 127 128 HTTP/1.0 200 OK\r\n 129 <html> 130 <title> some page </title> 131 </HTML> 132 133In this example, HTTP/1.0 is the HTTP version, 200 the response status 134code and OK the response status message. 135 136Although cookies are sent in an HTTP header, you can not match on them 137with the ``http.header`` keyword. Cookies are matched with their own 138keyword, namely ``http.cookie``. 139 140Each part of the table belongs to a so-called *buffer*. The HTTP 141method belongs to the method buffer, HTTP headers to the header buffer 142etc. A buffer is a specific portion of the request or response that 143Suricata extracts in memory for inspection. 144 145All previous described keywords can be used in combination with a 146buffer in a signature. The keywords ``distance`` and ``within`` are 147relative modifiers, so they may only be used within the same 148buffer. You can not relate content matches against different buffers 149with relative modifiers. 150 151http.method 152----------- 153 154With the ``http.method`` content modifier, it is possible to match 155specifically and only on the HTTP method buffer. The keyword can be 156used in combination with all previously mentioned content modifiers 157such as: ``depth``, ``distance``, ``offset``, ``nocase`` and ``within``. 158 159Examples of methods are: **GET**, **POST**, **PUT**, **HEAD**, 160**DELETE**, **TRACE**, **OPTIONS**, **CONNECT** and **PATCH**. 161 162Example of a method in a HTTP request: 163 164.. image:: http-keywords/method2.png 165 166Example of the purpose of method: 167 168.. image:: http-keywords/method.png 169 170.. image:: http-keywords/Legenda_rules.png 171 172.. image:: http-keywords/method1.png 173 174.. _rules-http-uri-normalization: 175 176http.uri and http.uri.raw 177------------------------- 178 179With the ``http.uri`` and the ``http.uri.raw`` content modifiers, it 180is possible to match specifically and only on the request URI 181buffer. The keyword can be used in combination with all previously 182mentioned content modifiers like ``depth``, ``distance``, ``offset``, 183``nocase`` and ``within``. 184 185The uri has two appearances in Suricata: the uri.raw and the 186normalized uri. The space for example can be indicated with the 187heximal notation %20. To convert this notation in a space, means 188normalizing it. It is possible though to match specific on the 189characters %20 in a uri. This means matching on the uri.raw. The 190uri.raw and the normalized uri are separate buffers. So, the uri.raw 191inspects the uri.raw buffer and can not inspect the normalized buffer. 192 193.. note:: uri.raw never has any spaces in it. 194 With this request line ``GET /uid=0(root) gid=0(root) HTTP/1.1``, 195 the ``http.uri.raw`` will match ``/uid=0(root)`` 196 and ``http.protocol`` will match ``gid=0(root) HTTP/1.1`` 197 Reference: `https://redmine.openinfosecfoundation.org/issues/2881 <https://redmine.openinfosecfoundation.org/issues/2881>`_ 198 199Example of the URI in a HTTP request: 200 201.. image:: http-keywords/uri1.png 202 203Example of the purpose of ``http.uri``: 204 205.. image:: http-keywords/uri.png 206 207uricontent 208---------- 209 210The ``uricontent`` keyword has the exact same effect as the 211``http.uri`` content modifier. ``uricontent`` is a deprecated 212(although still supported) way to match specifically and only on the 213request URI buffer. 214 215Example of ``uricontent``: 216 217.. container:: example-rule 218 219 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN Possible Vundo Trojan Variant reporting to Controller"; flow:established,to_server; content:"POST "; depth:5; :example-rule-emphasis:`uricontent:"/frame.html?";` urilen: > 80; classtype:trojan-activity; reference:url,doc.emergingthreats.net/2009173; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Vundo; sid:2009173; rev:2;) 220 221The difference between ``http.uri`` and ``uricontent`` is the syntax: 222 223.. image:: http-keywords/uricontent1.png 224 225.. image:: http-keywords/http_uri.png 226 227When authoring new rules, it is recommended that the ``http.uri`` 228content sticky buffer be used rather than the deprecated ``uricontent`` 229keyword. 230 231urilen 232------ 233 234The ``urilen`` keyword is used to match on the length of the request 235URI. It is possible to use the ``<`` and ``>`` operators, which 236indicate respectively *smaller than* and *larger than*. 237 238The format of ``urilen`` is:: 239 240 urilen:3; 241 242Other possibilities are:: 243 244 urilen:1; 245 urilen:>1; 246 urilen:<10; 247 urilen:10<>20; (bigger than 10, smaller than 20) 248 249Example: 250 251.. image:: http-keywords/urilen.png 252 253Example of ``urilen`` in a signature: 254 255.. container:: example-rule 256 257 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN Possible Vundo Trojan Variant reporting to Controller"; flow:established,to_server; content:"POST "; depth:5; uricontent:"/frame.html?"; :example-rule-emphasis:`urilen: > 80;` classtype:trojan-activity; reference:url,doc.emergingthreats.net/2009173; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Vundo; sid:2009173; rev:2;) 258 259You can also append ``norm`` or ``raw`` to define what sort of buffer you want 260to use (normalized or raw buffer). 261 262http.protocol 263------------- 264 265The ``http.protocol`` inspects the protocol field from the HTTP request or 266response line. If the request line is 'GET / HTTP/1.0\r\n', then this buffer 267will contain 'HTTP/1.0'. 268 269Example:: 270 271 alert http any any -> any any (flow:to_server; http.protocol; content:"HTTP/1.0"; sid:1;) 272 273``http.protocol`` replaces the previous keyword name: ```http_protocol``. You may continue 274+to use the previous name, but it's recommended that rules be converted to use 275+the new name. 276 277Example:: 278 279 alert http any any -> any any (flow:to_server; http.protocol; content:"HTTP/1.0"; sid:1;) 280 281 282http.request_line 283----------------- 284 285The ``http.request_line`` forces the whole HTTP request line to be inspected. 286 287Example:: 288 289 alert http any any -> any any (http.request_line; content:"GET / HTTP/1.0"; sid:1;) 290 291http.header and http.header.raw 292------------------------------- 293 294With the ``http.header`` content modifier, it is possible to match 295specifically and only on the HTTP header buffer. This contains all of 296the extracted headers in a single buffer, except for those indicated 297in the documentation that are not able to match by this buffer and 298have their own content modifier (e.g. ``http.cookie``). The modifier 299can be used in combination with all previously mentioned content 300modifiers, like ``depth``, ``distance``, ``offset``, ``nocase`` and 301``within``. 302 303 **Note**: the header buffer is *normalized*. Any trailing 304 whitespace and tab characters are removed. See: 305 https://lists.openinfosecfoundation.org/pipermail/oisf-users/2011-October/000935.html. 306 If there are multiple values for the same header name, they are 307 concatenated with a comma and space (", ") between each of them. 308 See RFC 2616 4.2 Message Headers. 309 To avoid that, use the ``http.header.raw`` keyword. 310 311Example of a header in a HTTP request: 312 313.. image:: http-keywords/header.png 314 315Example of the purpose of ``http.header``: 316 317.. image:: http-keywords/header1.png 318 319http.cookie 320----------- 321 322With the ``http.cookie`` content modifier, it is possible to match 323specifically and only on the cookie buffer. The keyword can be used in 324combination with all previously mentioned content modifiers like 325``depth``, ``distance``, ``offset``, ``nocase`` and ``within``. 326 327Note that cookies are passed in HTTP headers, but are extracted to a 328dedicated buffer and matched using their own specific content 329modifier. 330 331Example of a cookie in a HTTP request: 332 333.. image:: http-keywords/cookie.png 334 335Example of the purpose of ``http.cookie``: 336 337.. image:: http-keywords/cookie1.png 338 339http.user_agent 340--------------- 341 342The ``http.user_agent`` content modifier is part of the HTTP request 343header. It makes it possible to match specifically on the value of the 344User-Agent header. It is normalized in the sense that it does not 345include the _"User-Agent: "_ header name and separator, nor does it 346contain the trailing carriage return and line feed (CRLF). The keyword 347can be used in combination with all previously mentioned content 348modifiers like ``depth``, ``distance``, ``offset``, ``nocase`` and 349``within``. Note that the ``pcre`` keyword can also inspect this 350buffer when using the ``/V`` modifier. 351 352Normalization: leading spaces **are not** part of this buffer. So 353"User-Agent: \r\n" will result in an empty ``http.user_agent`` buffer. 354 355Example of the User-Agent header in a HTTP request: 356 357.. image:: http-keywords/user_agent.png 358 359Example of the purpose of ``http.user_agent``: 360 361.. image:: http-keywords/user_agent_match.png 362 363Notes 364~~~~~ 365 366- The ``http.user_agent`` buffer will NOT include the header name, 367 colon, or leading whitespace. i.e. it will not include 368 "User-Agent: ". 369 370- The ``http.user_agent`` buffer does not include a CRLF (0x0D 371 0x0A) at the end. If you want to match the end of the buffer, use a 372 relative ``isdataat`` or a PCRE (although PCRE will be worse on 373 performance). 374 375- If a request contains multiple "User-Agent" headers, the values will 376 be concatenated in the ``http.user_agent`` buffer, in the order 377 seen from top to bottom, with a comma and space (", ") between each 378 of them. 379 380 Example request:: 381 382 GET /test.html HTTP/1.1 383 User-Agent: SuriTester/0.8 384 User-Agent: GGGG 385 386 ``http.user_agent`` buffer contents:: 387 388 SuriTester/0.8, GGGG 389 390- Corresponding PCRE modifier: ``V`` 391 392- Using the ``http.user_agent`` buffer is more efficient when it 393 comes to performance than using the ``http.header`` buffer (~10% 394 better). 395 396- `https://blog.inliniac.net/2012/07/09/suricata-http\_user\_agent-vs-http\_header/ <https://blog.inliniac.net/2012/07/09/suricata-http_user_agent-vs-http_header/>`_ 397 398http.accept 399----------- 400 401Sticky buffer to match on the HTTP Accept header. Only contains the header 402value. The \\r\\n after the header are not part of the buffer. 403 404Example:: 405 406 alert http any any -> any any (http.accept; content:"image/gif"; sid:1;) 407 408http.accept_enc 409--------------- 410 411Sticky buffer to match on the HTTP Accept-Encoding header. Only contains the 412header value. The \\r\\n after the header are not part of the buffer. 413 414Example:: 415 416 alert http any any -> any any (http.accept_enc; content:"gzip"; sid:1;) 417 418 419http.accept_lang 420---------------- 421 422Sticky buffer to match on the HTTP Accept-Language header. Only contains the 423header value. The \\r\\n after the header are not part of the buffer. 424 425Example:: 426 427 alert http any any -> any any (http.accept_lang; content:"en-us"; sid:1;) 428 429 430http.connection 431--------------- 432 433Sticky buffer to match on the HTTP Connection header. Only contains the 434header value. The \\r\\n after the header are not part of the buffer. 435 436Example:: 437 438 alert http any any -> any any (http.connection; content:"keep-alive"; sid:1;) 439 440 441http.content_type 442----------------- 443 444Sticky buffer to match on the HTTP Content-Type headers. Only contains the 445header value. The \\r\\n after the header are not part of the buffer. 446 447Use flow:to_server or flow:to_client to force inspection of request or response. 448 449Examples:: 450 451 alert http any any -> any any (flow:to_server; \ 452 http.content_type; content:"x-www-form-urlencoded"; sid:1;) 453 454 alert http any any -> any any (flow:to_client; \ 455 http.content_type; content:"text/javascript"; sid:2;) 456 457 458http.content_len 459---------------- 460 461Sticky buffer to match on the HTTP Content-Length headers. Only contains the 462header value. The \\r\\n after the header are not part of the buffer. 463 464Use flow:to_server or flow:to_client to force inspection of request or response. 465 466Examples:: 467 468 alert http any any -> any any (flow:to_server; \ 469 http.content_len; content:"666"; sid:1;) 470 471 alert http any any -> any any (flow:to_client; \ 472 http.content_len; content:"555"; sid:2;) 473 474To do a numeric inspection of the content length, ``byte_test`` can be used. 475 476Example, match if C-L is equal to or bigger than 8079:: 477 478 alert http any any -> any any (flow:to_client; \ 479 http.content_len; byte_test:0,>=,8079,0,string,dec; sid:3;) 480 481http.referer 482--------------- 483 484Sticky buffer to match on the HTTP Referer header. Only contains the 485header value. The \\r\\n after the header are not part of the buffer. 486 487Example:: 488 489 alert http any any -> any any (http.referer; content:".php"; sid:1;) 490 491http.start 492---------- 493 494Inspect the start of a HTTP request or response. This will contain the 495request/response line plus the request/response headers. Use flow:to_server 496or flow:to_client to force inspection of request or response. 497 498Example:: 499 500 alert http any any -> any any (http.start; content:"HTTP/1.1|0d 0a|User-Agent"; sid:1;) 501 502The buffer contains the normalized headers and is terminated by an extra 503\\r\\n to indicate the end of the headers. 504 505http.header_names 506----------------- 507 508Inspect a buffer only containing the names of the HTTP headers. Useful 509for making sure a header is not present or testing for a certain order 510of headers. 511 512Buffer starts with a \\r\\n and ends with an extra \\r\\n. 513 514Example buffer:: 515 516 \\r\\nHost\\r\\n\\r\\n 517 518Example rule:: 519 520 alert http any any -> any any (http.header_names; content:"|0d 0a|Host|0d 0a|"; sid:1;) 521 522Example to make sure *only* Host is present:: 523 524 alert http any any -> any any (http.header_names; \ 525 content:"|0d 0a|Host|0d 0a 0d 0a|"; sid:1;) 526 527Example to make sure *User-Agent* is directly after *Host*:: 528 529 alert http any any -> any any (http.header_names; \ 530 content:"|0d 0a|Host|0d 0a|User-Agent|0d 0a|"; sid:1;) 531 532Example to make sure *User-Agent* is after *Host*, but not necessarily directly after:: 533 534 alert http any any -> any any (http.header_names; \ 535 content:"|0d 0a|Host|0d 0a|"; content:"|0a 0d|User-Agent|0d 0a|"; \ 536 distance:-2; sid:1;) 537 538http.request_body 539----------------- 540 541With the ``http.request_body`` content modifier, it is possible to 542match specifically and only on the HTTP request body. The keyword can 543be used in combination with all previously mentioned content modifiers 544like ``distance``, ``offset``, ``nocase``, ``within``, etc. 545 546Example of ``http.request_body`` in a HTTP request: 547 548.. image:: http-keywords/client_body.png 549 550Example of the purpose of ``http.client_body``: 551 552.. image:: http-keywords/client_body1.png 553 554Note: how much of the request/client body is inspected is controlled 555in the :ref:`libhtp configuration section 556<suricata-yaml-configure-libhtp>` via the ``request-body-limit`` 557setting. 558 559``http.request_body`` replaces the previous keyword name: ```http_client_body``. You may continue 560+to use the previous name, but it's recommended that rules be converted to use 561+the new name. 562 563http.stat_code 564-------------- 565 566With the ``http.stat_code`` content modifier, it is possible to match 567specifically and only on the HTTP status code buffer. The keyword can 568be used in combination with all previously mentioned content modifiers 569like ``distance``, ``offset``, ``nocase``, ``within``, etc. 570 571Example of ``http.stat_code`` in a HTTP response: 572 573.. image:: http-keywords/stat_code.png 574 575Example of the purpose of ``http.stat_code``: 576 577.. image:: http-keywords/stat-code1.png 578 579http.stat_msg 580------------- 581 582With the ``http.stat_msg`` content modifier, it is possible to match 583specifically and only on the HTTP status message buffer. The keyword 584can be used in combination with all previously mentioned content 585modifiers like ``depth``, ``distance``, ``offset``, ``nocase`` and 586``within``. 587 588Example of ``http.stat_msg`` in a HTTP response: 589 590.. image:: http-keywords/stat_msg.png 591 592Example of the purpose of ``http.stat_msg``: 593 594.. image:: http-keywords/stat_msg_1.png 595 596http.response_line 597------------------ 598 599The ``http.response_line`` forces the whole HTTP response line to be inspected. 600 601Example:: 602 603 alert http any any -> any any (http.response_line; content:"HTTP/1.0 200 OK"; sid:1;) 604 605http.response_body 606------------------ 607 608With the ``http.response_body`` content modifier, it is possible to 609match specifically and only on the HTTP response body. The keyword can 610be used in combination with all previously mentioned content modifiers 611like ``distance``, ``offset``, ``nocase``, ``within``, etc. 612 613Note: how much of the response/server body is inspected is controlled 614in your :ref:`libhtp configuration section 615<suricata-yaml-configure-libhtp>` via the ``response-body-limit`` 616setting. 617 618Notes 619~~~~~ 620 621- Using ``http.response_body`` is similar to having content matches 622 that come after ``file_data`` except that it doesn't permanently 623 (unless reset) set the detection pointer to the beginning of the 624 server response body. i.e. it is not a sticky buffer. 625 626- ``http.response_body`` will match on gzip decoded data just like 627 ``file_data`` does. 628 629- Since ``http.response_body`` matches on a server response, it 630 can't be used with the ``to_server`` or ``from_client`` flow 631 directives. 632 633- Corresponding PCRE modifier: ``Q`` 634 635- further notes at the ``file_data`` section below. 636 637``http.response_body`` replaces the previous keyword name: ```http_server_body``. You may continue 638+to use the previous name, but it's recommended that rules be converted to use 639+the new name. 640 641http.server 642----------- 643 644Sticky buffer to match on the HTTP Server headers. Only contains the 645header value. The \\r\\n after the header are not part of the buffer. 646 647Example:: 648 649 alert http any any -> any any (flow:to_client; \ 650 http.server; content:"Microsoft-IIS/6.0"; sid:1;) 651 652http.location 653------------- 654 655Sticky buffer to match on the HTTP Location headers. Only contains the 656header value. The \\r\\n after the header are not part of the buffer. 657 658Example:: 659 660 alert http any any -> any any (flow:to_client; \ 661 http.location; content:"http://www.google.com"; sid:1;) 662 663 664http.host and http.host.raw 665--------------------------- 666 667With the ``http.host`` content modifier, it is possible to 668match specifically and only the normalized hostname. 669The ``http.host.raw`` inspects the raw hostname. 670 671The keyword can be used in combination with most of the content modifiers 672like ``distance``, ``offset``, ``within``, etc. 673 674The ``nocase`` keyword is not allowed anymore. Keep in mind that you need 675to specify a lowercase pattern. 676 677Notes 678~~~~~ 679 680- ``http.host`` does not contain the port associated with 681 the host (i.e. abc.com:1234). To match on the host and port 682 or negate a host and port use ``http.host.raw``. 683 684- The ``http.host`` and ``http.host.raw`` buffers are populated 685 from either the URI (if the full URI is present in the request like 686 in a proxy request) or the HTTP Host header. If both are present, the 687 URI is used. 688 689- The ``http.host`` and ``http.host.raw`` buffers will NOT 690 include the header name, colon, or leading whitespace if populated 691 from the Host header. i.e. they will not include "Host: ". 692 693- The ``http.host`` and ``http.host.raw`` buffers do not 694 include a CRLF (0x0D 0x0A) at the end. If you want to match the end 695 of the buffer, use a relative 'isdataat' or a PCRE (although PCRE 696 will be worse on performance). 697 698- The ``http.host`` buffer is normalized to be all lower case. 699 700- The content match that ``http.host`` applies to must be all lower 701 case or have the ``nocase`` flag set. 702 703- ``http.host.raw`` matches the unnormalized buffer so matching 704 will be case-sensitive (unless ``nocase`` is set). 705 706- If a request contains multiple "Host" headers, the values will be 707 concatenated in the ``http.host`` and ``http.host.raw`` 708 buffers, in the order seen from top to bottom, with a comma and space 709 (", ") between each of them. 710 711 Example request:: 712 713 GET /test.html HTTP/1.1 714 Host: ABC.com 715 Accept: */* 716 Host: efg.net 717 718 ``http.host`` buffer contents:: 719 720 abc.com, efg.net 721 722 ``http.host.raw`` buffer contents:: 723 724 ABC.com, efg.net 725 726- Corresponding PCRE modifier (``http_host``): ``W`` 727- Corresponding PCRE modifier (``http_raw_host``): ``Z`` 728 729file_data 730--------- 731 732With ``file_data``, the HTTP response body is inspected, just like 733with ``http.response_body``. The ``file_data`` keyword is a sticky buffer. 734 735Example:: 736 737 alert http any any -> any any (file_data; content:"abc"; content:"xyz";) 738 739.. image:: http-keywords/file_data.png 740 741The ``file_data`` keyword affects all following content matches, until 742the ``pkt_data`` keyword is encountered or it reaches the end of the 743rule. This makes it a useful shortcut for applying many content 744matches to the HTTP response body, eliminating the need to modify each 745content match individually. 746 747As the body of a HTTP response can be very large, it is inspected in 748smaller chunks. 749 750How much of the response/server body is inspected is controlled 751in your :ref:`libhtp configuration section 752<suricata-yaml-configure-libhtp>` via the ``response-body-limit`` 753setting. 754 755If the HTTP body is a flash file compressed with 'deflate' or 'lzma', 756it can be decompressed and ``file_data`` can match on the decompress data. 757Flash decompression must be enabled under ``libhtp`` configuration: 758 759:: 760 761 # Decompress SWF files. 762 # 2 types: 'deflate', 'lzma', 'both' will decompress deflate and lzma 763 # compress-depth: 764 # Specifies the maximum amount of data to decompress, 765 # set 0 for unlimited. 766 # decompress-depth: 767 # Specifies the maximum amount of decompressed data to obtain, 768 # set 0 for unlimited. 769 swf-decompression: 770 enabled: yes 771 type: both 772 compress-depth: 0 773 decompress-depth: 0 774 775Notes 776~~~~~ 777 778- If a HTTP body is using gzip or deflate, ``file_data`` will match 779 on the decompressed data. 780 781- Negated matching is affected by the chunked inspection. E.g. 782 'content:!"<html";' could not match on the first chunk, but would 783 then possibly match on the 2nd. To avoid this, use a depth setting. 784 The depth setting takes the body size into account. 785 Assuming that the ``response-body-minimal-inspect-size`` is bigger 786 than 1k, 'content:!"<html"; depth:1024;' can only match if the 787 pattern '<html' is absent from the first inspected chunk. 788 789- ``file_data`` can also be used with SMTP 790