diff --git a/doc/userguide/rules/intro.rst b/doc/userguide/rules/intro.rst index 86ba78860a..07fc3fde21 100644 --- a/doc/userguide/rules/intro.rst +++ b/doc/userguide/rules/intro.rst @@ -135,7 +135,7 @@ concern. The respective ``$HOME_NET`` and ``$EXTERNAL_NET`` settings will be use See :ref:`suricata-yaml-rule-vars` for more information. -For example: +Rule usage examples: ================================== ========================================== Example Meaning @@ -167,7 +167,7 @@ Ports (source and destination) *The first emphasized part is the source port, the second is the destination port (note the direction of the directional arrow).* -Traffic comes in and goes out through ports. Different ports have +Traffic comes in and goes out through ports. Different protocols have different port numbers. For example, the default port for HTTP is 80 while 443 is typically the port for HTTPS. Note, however, that the port does not dictate which protocol is used in the communication. Rather, it determines which @@ -179,8 +179,7 @@ port by the operating system. When writing a rule for your own HTTP service, you would typically write ``any -> 80``, since that would mean any packet from any source port to your HTTP application (running on port 80) is matched. -In setting ports you can make use of special operators as well, like -described above. Signs like: +In setting ports you can make use of special operators as well. Operators such as: ============== ================== Operator Description @@ -190,7 +189,7 @@ Operator Description [.., ..] grouping ============== ================== -For example: +Rule usage examples: ============== ========================================== Example Meaning @@ -211,22 +210,18 @@ Direction alert http $HOME_NET any :example-rule-emphasis:`->` $EXTERNAL_NET any (msg:"HTTP GET Request Containing Rule in URI"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"rule"; fast_pattern; classtype:bad-unknown; sid:123; rev:1;) -The direction tells in which way the signature has to match. Nearly -every signature has an arrow to the right (``->``). This means that only +The directional arrow indicates which way the signature will be evaluated. +In most signatures an arrow to the right (``->``) is used. This means that only packets with the same direction can match. However, it is also possible to -have a rule match both ways (``<>``):: +have a rule match both directions (``<>``):: source -> destination source <> destination (both directions) -.. warning:: - - There is no 'reverse' style direction, i.e. there is no ``<-``. - -The following example illustrates this. Say, there is a client with IP address -1.2.3.4 and port 1024, and a server with IP address 5.6.7.8, listening on port -80 (typically HTTP). The client sends a message to the server, and the server -replies with its answer. +The following example illustrates direction. In this example there is a client +with IP address 1.2.3.4 using port 1024. A server with IP address 5.6.7.8, +listening on port 80 (typically HTTP). The client sends a message to the server +and the server replies with its answer. .. image:: intro/TCP-session.png @@ -234,15 +229,19 @@ Now, let's say we have a rule with the following header:: alert tcp 1.2.3.4 1024 -> 5.6.7.8 80 -Only the first packet will be matched by this rule, as the direction specifies -that we do not match on the response packet. +Only the traffic from the client to the server will be matched by this rule, +as the direction specifies that we do not want to evaluate the response packet. + +.. warning:: + + There is no 'reverse' style direction, i.e. there is no ``<-``. Rule options ------------ The rest of the rule consists of options. These are enclosed by parenthesis and separated by semicolons. Some options have settings (such as ``msg``), which are specified by the keyword of the option, followed by a colon, -followed by the settings. Others have no settings, and are simply the +followed by the settings. Others have no settings; they are simply the keyword (such as ``nocase``):: : ;