Browse code

modules: readme files regenerated - pike ... [skip ci]

Kamailio Dev authored on 13/10/2020 13:46:25
Showing 1 changed files
... ...
@@ -31,6 +31,7 @@ Bogdan-Andrei Iancu
31 31
         4. Functions
32 32
 
33 33
               4.1. pike_check_req()
34
+              4.2. pike_check_ip(ipaddr)
34 35
 
35 36
         5. RPC Commands
36 37
 
... ...
@@ -50,6 +51,7 @@ Bogdan-Andrei Iancu
50 51
    1.3. Set remove_latency parameter
51 52
    1.4. Set pike_log_level parameter
52 53
    1.5. pike_check_req usage
54
+   1.6. pike_check_ip usage
53 55
    2.1. Using pike.top
54 56
    3.1. Tree of IP addresses
55 57
 
... ...
@@ -73,6 +75,7 @@ Chapter 1. Admin Guide
73 75
    4. Functions
74 76
 
75 77
         4.1. pike_check_req()
78
+        4.2. pike_check_ip(ipaddr)
76 79
 
77 80
    5. RPC Commands
78 81
 
... ...
@@ -175,6 +178,7 @@ modparam("pike", "pike_log_level", -1)
175 178
 4. Functions
176 179
 
177 180
    4.1. pike_check_req()
181
+   4.2. pike_check_ip(ipaddr)
178 182
 
179 183
 4.1.  pike_check_req()
180 184
 
... ...
@@ -191,13 +195,30 @@ Warning
191 195
      * -2 (false) - IP is detected as a new source of flooding - first
192 196
        time detection
193 197
 
194
-   This function can be used from REQUEST_ROUTE.
198
+   This function can be used from REQUEST_ROUTE|ONREPLY_ROUTE.
195 199
 
196 200
    Example 1.5. pike_check_req usage
197 201
 ...
198 202
 if (!pike_check_req()) { exit; };
199 203
 ...
200 204
 
205
+4.2.  pike_check_ip(ipaddr)
206
+
207
+   Process the IP address parameter and return false if it was exceeding
208
+   the blocking limit. The return codes are the same from
209
+   pike_check_req().
210
+
211
+   The parameter can contain variables.
212
+
213
+   This function can be used from REQUEST_ROUTE|ONREPLY_ROUTE.
214
+
215
+   Example 1.6. pike_check_ip usage
216
+...
217
+if (!pike_check_ip("1.2.3.4")) { exit; };
218
+...
219
+if (!pike_check_ip("$si")) { exit; };
220
+...
221
+
201 222
 5. RPC Commands
202 223
 
203 224
    5.1. pike.top
Browse code

modules: readme files regenerated - pike ... [skip ci]

Kamailio Dev authored on 11/08/2020 09:16:25
Showing 1 changed files
... ...
@@ -39,6 +39,7 @@ Bogdan-Andrei Iancu
39 39
    2. RPC calls
40 40
 
41 41
         1. pike.top
42
+        2. pike.list
42 43
 
43 44
    3. Developer Guide
44 45
 
... ...
@@ -49,6 +50,7 @@ Bogdan-Andrei Iancu
49 50
    1.3. Set remove_latency parameter
50 51
    1.4. Set pike_log_level parameter
51 52
    1.5. pike_check_req usage
53
+   2.1. Using pike.top
52 54
    3.1. Tree of IP addresses
53 55
 
54 56
 Chapter 1. Admin Guide
... ...
@@ -219,6 +221,7 @@ Chapter 2. RPC calls
219 221
    Table of Contents
220 222
 
221 223
    1. pike.top
224
+   2. pike.list
222 225
 
223 226
 1.  pike.top
224 227
 
... ...
@@ -230,9 +233,9 @@ Chapter 2. RPC calls
230 233
 
231 234
    Some IPs could be marked as HOT depending on theirs request rates.
232 235
 
233
-   pike.top command takes one string parameter which specifies what kind
234
-   of nodes you are interested in. Possible values are HOT or ALL. If no
235
-   argument is given, it behaves as HOT was used.
236
+   pike.top command can take one string parameter which specifies what
237
+   kind of nodes you are interested in. Possible values are HOT or ALL. If
238
+   no argument is given, it behaves as HOT was used.
236 239
 
237 240
    Marking nodes HOT is done on server side, client only presents given
238 241
    data and make some postprocessing like sorting.
... ...
@@ -240,6 +243,15 @@ Chapter 2. RPC calls
240 243
    Output of this command is a simple dump of ip_tree nodes marked as
241 244
    ip-leafs.
242 245
 
246
+   Example 2.1. Using pike.top
247
+...
248
+kamcli rpc pike.top ALL
249
+...
250
+
251
+2.  pike.list
252
+
253
+   Alias for "pike.top" command.
254
+
243 255
 Chapter 3. Developer Guide
244 256
 
245 257
    One single tree (for both IPv4 and IPv6) is used. Each node contains a
Browse code

modules: readme files regenerated - pike ... [skip ci]

Kamailio Dev authored on 24/03/2020 14:31:11
Showing 1 changed files
... ...
@@ -247,9 +247,9 @@ Chapter 3. Developer Guide
247 247
 
248 248
    Example 3.1. Tree of IP addresses
249 249
            / 193 - 175 - 132 - 164
250
-tree root /                  \ 142
250
+tree root /                \ - 142
251 251
           \ 195 - 37 - 78 - 163
252
-           \ 79 - 134
252
+                   \ - 79 - 134
253 253
 
254 254
    To detect the whole address, step by step, from the root to the leafs,
255 255
    the nodes corresponding to each byte of the ip address are expanded. In
Browse code

modules: readme files regenerated - acc ... [skip ci]

Kamailio Dev authored on 28/02/2018 17:03:37 • The Root committed on 28/02/2018 19:11:36
Showing 1 changed files
... ...
@@ -84,7 +84,7 @@ Chapter 1. Admin Guide
84 84
 
85 85
    The module does not implement any actions on blocking - it just simply
86 86
    reports that there is high traffic from an IP; what to do, is the
87
-   administator decision (via scripting).
87
+   administrator decision (via scripting).
88 88
 
89 89
 2. Dependencies
90 90
 
... ...
@@ -146,7 +146,7 @@ modparam("pike", "reqs_density_per_unit", 30)
146 146
    Specifies for how long the IP address will be kept in memory after the
147 147
    last request from that IP address. It's a sort of timeout value, in
148 148
    seconds. Note that it is not the duration to keep the IP in state
149
-   'blocked'. An IP is unblocked next occurence of 'sampling_time_unit'
149
+   'blocked'. An IP is unblocked next occurrence of 'sampling_time_unit'
150 150
    that does not exceed 'reqs_density_per_unit'. Keeping an IP in memory
151 151
    results in faster reaching of blocked state -- see the notes about the
152 152
    limits of getting to state 'blocked'.
Browse code

modules: readme files regenerated - pike ... [skip ci]

Kamailio Dev authored on 21/06/2017 18:46:26
Showing 1 changed files
... ...
@@ -143,7 +143,7 @@ modparam("pike", "reqs_density_per_unit", 30)
143 143
 
144 144
 3.3. remove_latency (integer)
145 145
 
146
-   Speciies for how long the IP address will be kept in memory after the
146
+   Specifies for how long the IP address will be kept in memory after the
147 147
    last request from that IP address. It's a sort of timeout value, in
148 148
    seconds. Note that it is not the duration to keep the IP in state
149 149
    'blocked'. An IP is unblocked next occurence of 'sampling_time_unit'
Browse code

modules: readme files regenerated - pdt ...

Kamailio Dev authored on 02/01/2017 11:31:16
Showing 1 changed files
... ...
@@ -32,9 +32,9 @@ Bogdan-Andrei Iancu
32 32
 
33 33
               4.1. pike_check_req()
34 34
 
35
-        5. MI Commands
35
+        5. RPC Commands
36 36
 
37
-              5.1. pike_list
37
+              5.1. pike.top
38 38
 
39 39
    2. RPC calls
40 40
 
... ...
@@ -72,9 +72,9 @@ Chapter 1. Admin Guide
72 72
 
73 73
         4.1. pike_check_req()
74 74
 
75
-   5. MI Commands
75
+   5. RPC Commands
76 76
 
77
-        5.1. pike_list
77
+        5.1. pike.top
78 78
 
79 79
 1. Overview
80 80
 
... ...
@@ -196,21 +196,23 @@ Warning
196 196
 if (!pike_check_req()) { exit; };
197 197
 ...
198 198
 
199
-5. MI Commands
199
+5. RPC Commands
200 200
 
201
-   5.1. pike_list
201
+   5.1. pike.top
202 202
 
203
-5.1.  pike_list
203
+5.1.  pike.top
204 204
 
205
-   Lists the nodes in the pike tree.
205
+   Lists nodes in the pike tree.
206 206
 
207
-   Name: pike_list
207
+   Name: pike.top
208 208
 
209
-   Parameters: none
209
+   Parameters: filter (optional) - it can be "ALL", "HOT" or "WARM". If
210
+   missing, the "HOT" nodes are listed.
210 211
 
211
-   MI FIFO Command Format:
212
-                :pike_list:_reply_fifo_file_
213
-                _empty_line_
212
+   RPC Command Example:
213
+...
214
+kamcmd pike.top
215
+...
214 216
 
215 217
 Chapter 2. RPC calls
216 218
 
Browse code

core, lib, modules: restructured source code tree

- new folder src/ to hold the source code for main project applications
- main.c is in src/
- all core files are subfolder are in src/core/
- modules are in src/modules/
- libs are in src/lib/
- application Makefiles are in src/
- application binary is built in src/ (src/kamailio)

Daniel-Constantin Mierla authored on 07/12/2016 11:03:51
Showing 1 changed files
1 1
new file mode 100644
... ...
@@ -0,0 +1,281 @@
1
+pike Module
2
+
3
+Bogdan-Andrei Iancu
4
+
5
+   Voice Sistem SRL
6
+
7
+Edited by
8
+
9
+Bogdan-Andrei Iancu
10
+
11
+   Copyright © 2003 FhG FOKUS
12
+     __________________________________________________________________
13
+
14
+   Table of Contents
15
+
16
+   1. Admin Guide
17
+
18
+        1. Overview
19
+        2. Dependencies
20
+
21
+              2.1. Kamailio Modules
22
+              2.2. External Libraries or Applications
23
+
24
+        3. Parameters
25
+
26
+              3.1. sampling_time_unit (integer)
27
+              3.2. reqs_density_per_unit (integer)
28
+              3.3. remove_latency (integer)
29
+              3.4. pike_log_level (integer)
30
+
31
+        4. Functions
32
+
33
+              4.1. pike_check_req()
34
+
35
+        5. MI Commands
36
+
37
+              5.1. pike_list
38
+
39
+   2. RPC calls
40
+
41
+        1. pike.top
42
+
43
+   3. Developer Guide
44
+
45
+   List of Examples
46
+
47
+   1.1. Set sampling_time_unit parameter
48
+   1.2. Set reqs_density_per_unit parameter
49
+   1.3. Set remove_latency parameter
50
+   1.4. Set pike_log_level parameter
51
+   1.5. pike_check_req usage
52
+   3.1. Tree of IP addresses
53
+
54
+Chapter 1. Admin Guide
55
+
56
+   Table of Contents
57
+
58
+   1. Overview
59
+   2. Dependencies
60
+
61
+        2.1. Kamailio Modules
62
+        2.2. External Libraries or Applications
63
+
64
+   3. Parameters
65
+
66
+        3.1. sampling_time_unit (integer)
67
+        3.2. reqs_density_per_unit (integer)
68
+        3.3. remove_latency (integer)
69
+        3.4. pike_log_level (integer)
70
+
71
+   4. Functions
72
+
73
+        4.1. pike_check_req()
74
+
75
+   5. MI Commands
76
+
77
+        5.1. pike_list
78
+
79
+1. Overview
80
+
81
+   The pike module keeps trace of all (or selected ones) incoming
82
+   request's IP source and blocks the ones that exceed the limit. It works
83
+   simultaneously for IPv4 and IPv6 addresses.
84
+
85
+   The module does not implement any actions on blocking - it just simply
86
+   reports that there is high traffic from an IP; what to do, is the
87
+   administator decision (via scripting).
88
+
89
+2. Dependencies
90
+
91
+   2.1. Kamailio Modules
92
+   2.2. External Libraries or Applications
93
+
94
+2.1. Kamailio Modules
95
+
96
+   The following modules must be loaded before this module:
97
+     * No dependencies on other Kamailio modules.
98
+
99
+2.2. External Libraries or Applications
100
+
101
+   The following libraries or applications must be installed before
102
+   running Kamailio with this module loaded:
103
+     * None.
104
+
105
+3. Parameters
106
+
107
+   3.1. sampling_time_unit (integer)
108
+   3.2. reqs_density_per_unit (integer)
109
+   3.3. remove_latency (integer)
110
+   3.4. pike_log_level (integer)
111
+
112
+3.1. sampling_time_unit (integer)
113
+
114
+   Time period in seconds used for sampling (or the sampling accuracy).
115
+   The smaller the better, but slower. If you want to detect peeks, use a
116
+   small one. To limit the access (like total number of requests on a long
117
+   period of time) to a proxy resource (a gateway for example), use a
118
+   bigger value of this parameter.
119
+
120
+   IMPORTANT: a too small value may lead to performance penalties due to
121
+   timer process overloading.
122
+
123
+   Default value is “2”.
124
+
125
+   Example 1.1. Set sampling_time_unit parameter
126
+...
127
+modparam("pike", "sampling_time_unit", 10)
128
+...
129
+
130
+3.2. reqs_density_per_unit (integer)
131
+
132
+   How many requests should be allowed per sampling_time_unit before
133
+   blocking all the incoming request from that IP. Practically, the
134
+   blocking limit is between ( let's have x=reqs_density_per_unit) x and
135
+   3*x for IPv4 addresses and between x and 8*x for IPv6 addresses.
136
+
137
+   Default value is 30.
138
+
139
+   Example 1.2. Set reqs_density_per_unit parameter
140
+...
141
+modparam("pike", "reqs_density_per_unit", 30)
142
+...
143
+
144
+3.3. remove_latency (integer)
145
+
146
+   Speciies for how long the IP address will be kept in memory after the
147
+   last request from that IP address. It's a sort of timeout value, in
148
+   seconds. Note that it is not the duration to keep the IP in state
149
+   'blocked'. An IP is unblocked next occurence of 'sampling_time_unit'
150
+   that does not exceed 'reqs_density_per_unit'. Keeping an IP in memory
151
+   results in faster reaching of blocked state -- see the notes about the
152
+   limits of getting to state 'blocked'.
153
+
154
+   Default value is 120.
155
+
156
+   Example 1.3. Set remove_latency parameter
157
+...
158
+modparam("pike", "remove_latency", 130)
159
+...
160
+
161
+3.4. pike_log_level (integer)
162
+
163
+   Syslog log level to be used by module to auto report the blocking (only
164
+   first time) and unblocking of IPs detected as source of floods.
165
+
166
+   Default value is 1 (L_WARN).
167
+
168
+   Example 1.4. Set pike_log_level parameter
169
+...
170
+modparam("pike", "pike_log_level", -1)
171
+...
172
+
173
+4. Functions
174
+
175
+   4.1. pike_check_req()
176
+
177
+4.1.  pike_check_req()
178
+
179
+   Process the source IP of the current request and return false if the IP
180
+   was exceeding the blocking limit.
181
+
182
+   Return codes:
183
+     * 1 (true) - IP is not to be blocked or internal error occurred.
184
+
185
+Warning
186
+       IMPORTANT: in case of internal error, the function returns true to
187
+       avoid reporting the current processed IP as blocked.
188
+     * -1 (false) - IP is source of flooding, previously detected
189
+     * -2 (false) - IP is detected as a new source of flooding - first
190
+       time detection
191
+
192
+   This function can be used from REQUEST_ROUTE.
193
+
194
+   Example 1.5. pike_check_req usage
195
+...
196
+if (!pike_check_req()) { exit; };
197
+...
198
+
199
+5. MI Commands
200
+
201
+   5.1. pike_list
202
+
203
+5.1.  pike_list
204
+
205
+   Lists the nodes in the pike tree.
206
+
207
+   Name: pike_list
208
+
209
+   Parameters: none
210
+
211
+   MI FIFO Command Format:
212
+                :pike_list:_reply_fifo_file_
213
+                _empty_line_
214
+
215
+Chapter 2. RPC calls
216
+
217
+   Table of Contents
218
+
219
+   1. pike.top
220
+
221
+1.  pike.top
222
+
223
+   Pike.top behaves like a 'top' command and shows source IP addresses of
224
+   incoming requestes to pike_check_req() function.
225
+
226
+   The IP list is sorted by sum of leaf hits (prev and curr) descending
227
+   and in second level by hits.
228
+
229
+   Some IPs could be marked as HOT depending on theirs request rates.
230
+
231
+   pike.top command takes one string parameter which specifies what kind
232
+   of nodes you are interested in. Possible values are HOT or ALL. If no
233
+   argument is given, it behaves as HOT was used.
234
+
235
+   Marking nodes HOT is done on server side, client only presents given
236
+   data and make some postprocessing like sorting.
237
+
238
+   Output of this command is a simple dump of ip_tree nodes marked as
239
+   ip-leafs.
240
+
241
+Chapter 3. Developer Guide
242
+
243
+   One single tree (for both IPv4 and IPv6) is used. Each node contains a
244
+   byte, the IP addresses stretching from root to the leafs.
245
+
246
+   Example 3.1. Tree of IP addresses
247
+           / 193 - 175 - 132 - 164
248
+tree root /                  \ 142
249
+          \ 195 - 37 - 78 - 163
250
+           \ 79 - 134
251
+
252
+   To detect the whole address, step by step, from the root to the leafs,
253
+   the nodes corresponding to each byte of the ip address are expanded. In
254
+   order to be expended a node has to be hit for a given number of times
255
+   (possible by different addresses; in the previous example, the node
256
+   “37” was expended by the 195.37.78.163 and 195.37.79.134 hits).
257
+
258
+   For 193.175.132.164 with x= reqs_density_per_unit:
259
+     * After first req hits -> the “193” node is built.
260
+     * After x more hits, the “175” node is build; the hits of “193” node
261
+       are split between itself and its child--both of them gone have x/2.
262
+     * And so on for node “132” and “164”.
263
+     * Once “164” build the entire address can be found in the tree. “164”
264
+       becomes a leaf. After it will be hit as a leaf for x times, it will
265
+       become “RED” (further request from this address will be blocked).
266
+
267
+   So, to build and block this address were needed 3*x hits. Now, if reqs
268
+   start coming from 193.175.132.142, the first 3 bytes are already in the
269
+   tree (they are shared with the previous address), so I will need only x
270
+   hits (to build node “142” and to make it “RED”) to make this address
271
+   also to be blocked. This is the reason for the variable number of hits
272
+   necessary to block an IP.
273
+
274
+   The maximum number of hits to turn an address red are (n is the
275
+   address's number of bytes):
276
+
277
+   1 (first byte) + x (second byte) + (x / 2) * (n - 2) (for the rest of
278
+   the bytes) + (n - 1) (to turn the node to red).
279
+
280
+   So, for IPv4 (n = 4) will be 3x and for IPv6 (n = 16) will be 9x. The
281
+   minimum number of hits to turn an address red is x.