1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
Generic App Layer Keywords
==========================
.. _rule-keyword-app-layer-protocol:
app-layer-protocol
------------------
Match on the detected app-layer protocol.
Syntax::
app-layer-protocol:[!]<protocol>(,<mode>);
Examples::
app-layer-protocol:ssh;
app-layer-protocol:!tls;
app-layer-protocol:failed;
app-layer-protocol:!http,final;
app-layer-protocol:http,to_server; app-layer-protocol:tls,to_client;
app-layer-protocol:http2,final; app-layer-protocol:http1,original;
app-layer-protocol:unknown;
A special value 'failed' can be used for matching on flows in which
protocol detection failed. This can happen if Suricata doesn't know
the protocol or when certain 'bail out' conditions happen.
A special value 'unknown' can be used to match on a protocol being
not yet known. It can not be negated.
The different modes are
* direction : protocol recognized on the direction of the current packet
* to_server : protocol recognized in the direction to server
* to_client : protocol recognized in the direction to client
* either : tries to match protocols found on both directions
* final : final protocol chosen by Suricata for parsing
* original : original protocol (in case of protocol change)
By default, (if no mode is specified), the mode is ``direction``.
.. note:: when negation is used, like ``!http``, it will not match on the
"unknown" state in the flow.
Here is an example of a rule matching non-http traffic on port 80:
.. container:: example-rule
alert tcp any any -> any 80 (msg:"non-HTTP traffic over HTTP standard port"; flow:to_server; app-layer-protocol:!http,final; sid:1; )
.. _proto-detect-bail-out:
Bail out conditions
~~~~~~~~~~~~~~~~~~~
Protocol detection gives up in several cases:
* both sides are inspected and no match was found
* side A detection failed, side B has no traffic at all (e.g. FTP data channel)
* side A detection failed, side B has so little data detection is inconclusive
In these last 2 cases the ``app-layer-event:applayer_proto_detection_skipped``
is set.
app-layer-event
---------------
Match on events generated by the App Layer Parsers and the protocol detection
engine.
Syntax::
app-layer-event:<event name>;
Examples::
app-layer-event:applayer_mismatch_protocol_both_directions;
app-layer-event:http.gzip_decompression_failed;
Protocol Detection
~~~~~~~~~~~~~~~~~~
applayer_mismatch_protocol_both_directions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The toserver and toclient directions have different protocols. For example a
client talking HTTP to a SSH server.
applayer_wrong_direction_first_data
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Some protocol implementations in Suricata have a requirement with regards to
the first data direction. The HTTP parser is an example of this.
https://redmine.openinfosecfoundation.org/issues/993
applayer_detect_protocol_only_one_direction
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Protocol detection only succeeded in one direction. For FTP and SMTP this is
expected.
applayer_proto_detection_skipped
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Protocol detection was skipped because of :ref:`proto-detect-bail-out`.
app-layer-state
---------------
Match on the detected app-layer protocol transaction state.
Syntax::
app-layer-state:[<>]<state>;
Examples::
app-layer-state:request_headers;
app-layer-state:>request_body;
|
