PIKE module
Admin Guide
Section titled “Admin Guide”Overview
Section titled “Overview”The module provides a simple mechanism for DOS protection - DOS based on floods at network level. The module keeps trace of all (or selected ones) IPs of incoming SIP traffic (as source IP) and blocks the ones that exceeded some limit. Works simultaneous for IPv4 and IPv6 addresses.
The module does not implement any actions on blocking - it just simply reports that there is a high traffic from an IP; what to do, is the administator decision (via scripting).
How to use
Section titled “How to use”There are 2 ways of using this module (as detecting flood attacks and as taking the right action to limit the impact on the system):
- manual - from routing script you can force the check of the source IP of an incoming requests, using “pike_check_req” function. Note that this checking works only for SIP requests and you can decide (based on scripting logic) what source IPs to be monitored and what action to be taken when a flood is detected.
- automatic - the module will install internal hooks to catch all incoming requests and replies (even if not well formed from SIP point of view) - more or less the module will monitor all incoming packages (from the network) on the SIP sockets. Each time the source IP of a package needs to be analyse (to see if trusted or not), the module will run a script route - see “check_route” module parameter -, where, based on custom logic, you can decide if that IP needs to be monitored for flooding or not. As action, when flood is detected, the module will automatically drop the packages.
Dependencies
Section titled “Dependencies”OpenSIPS Modules
Section titled “OpenSIPS Modules”The following modules must be loaded before this module:
- No dependencies on other OpenSIPS modules.
External Libraries or Applications
Section titled “External Libraries or Applications”The following libraries or applications must be installed before running OpenSIPS with this module loaded:
- None.
Exported Parameters
Section titled “Exported Parameters”sampling_time_unit (integer)
Section titled “sampling_time_unit (integer)”Time period used for sampling (or the sampling accuracy ;-) ). The smaller the better, but slower. If you want to detect peeks, use a small one. To limit the access (like total number of requests on a long period of time) to a proxy resource (a gateway for ex), use a bigger value of this parameter.
Default value is 2.
...modparam("pike", "sampling_time_unit", 10)...reqs_density_per_unit (integer)
Section titled “reqs_density_per_unit (integer)”How many requests should be allowed per sampling_time_unit before blocking all the incoming request from that IP. Practically, the blocking limit is between ( let’s have x=reqs_density_per_unit) x and 3x for IPv4 addresses and between x and 8x for ipv6 addresses.
Default value is 30.
...modparam("pike", "reqs_density_per_unit", 30)...remove_latency (integer)
Section titled “remove_latency (integer)”For how long the IP address will be kept in memory after the last request from that IP address. It’s a sort of timeout value.
Default value is 120.
...modparam("pike", "remove_latency", 130)...check_route (integer)
Section titled “check_route (integer)”The name of the script route to be triggers (in automatic way) when a package is received from the network. If you do a “drop” in this route, it will indicate to the module that the source IP of the package does not need to be monitored. Otherwise, the source IP will be automatically monitered.
By defining this parameter, the automatic checking mode is enabled.
Default value is NONE (no auto mode).
...modparam("pike", "check_route", "pike")...route[pike]{ if (src_ip==111.222.111.222) /*trusted, do not check it*/ drop; /* all other IPs are checked*/}....pike_log_level (integer)
Section titled “pike_log_level (integer)”Log level to be used by module to auto report the blocking (only first time) and unblocking of IPs detected as source of floods.
Default value is 1 (L_WARN).
...modparam("pike", "pike_log_level", -1)...Exported Functions
Section titled “Exported Functions”pike_check_req()
Section titled “pike_check_req()”Process the source IP of the current request and returns false if the IP was exceeding the blocking limit.
Return codes:
- 1 (true) - IP is not to be blocked or internal error occurred.
- -1 (false) - IP is source of flooding, being previously detected
- -2 (false) - IP is detected as a new source of flooding - first time detection
This function can be used from REQUEST_ROUTE.
...if (!pike_check_req()) { exit; };...Exported MI Functions
Section titled “Exported MI Functions”pike_list
Section titled “pike_list”Lists the nodes in the pike tree.
Name: pike_list
Parameters: none
MI FIFO Command Format:
:pike_list:_reply_fifo_file__empty_line_Exported Events
Section titled “Exported Events”E_PIKE_BLOCKED
Section titled “E_PIKE_BLOCKED”This event is raised when the pike module decides that an IP should be blocked.
Parameters:
- ip - the IP address that has been blocked.
Developer Guide
Section titled “Developer Guide”One single tree (for both IPv4 and IPv6) is used. Each node contains a byte, the IP addresses stretching from root to the leafs.
/ 193 - 175 - 132 - 164tree root / \ 142 \ 195 - 37 - 78 - 163 \ 79 - 134To detect the whole address, step by step, from the root to the leafs, the nodes corresponding to each byte of the ip address are expanded. In order to be expended a node has to be hit for a given number of times (possible by different addresses; in the previous example, the node “37” was expended by the 195.37.78.163 and 195.37.79.134 hits).
For 193.175.132.164 with x= reqs_density_per_unit:
- After first req hits -> the “193” node is built.
- After x more hits, the “175” node is build; the hits of “193” node are split between itself and its child—both of them gone have x/2.
- And so on for node “132” and “164”.
- Once “164” build the entire address can be found in the tree. “164” becomes a leaf. After it will be hit as a leaf for x times, it will become “RED” (further request from this address will be blocked).
So, to build and block this address were needed 3*x hits. Now, if reqs start coming from 193.175.132.142, the first 3 bytes are already in the tree (they are shared with the previous address), so I will need only x hits (to build node “142” and to make it “RED”) to make this address also to be blocked. This is the reason for the variable number of hits necessary to block an IP.
The maximum number of hits to turn an address red are (n is the address’s number of bytes):
1 (first byte) + x (second byte) + (x / 2) * (n - 2) (for the rest of the bytes) + (n - 1) (to turn the node to red).
So, for IPv4 (n = 4) will be 3x and for IPv6 (n = 16) will be 9x. The minimum number of hits to turn an address red is x.
Contributors
Section titled “Contributors”By Commit Statistics
Section titled “By Commit Statistics”Top contributors by DevScore(1), authored commits(2) and lines added/removed(3)
| # | Name | DevScore | Commits | Lines++ | Lines— |
|---|---|---|---|---|---|
| 1. | Bogdan-Andrei Iancu (@bogdan-iancu) | 130 | 49 | 4188 | 2707 |
| 2. | Andrei Pelinescu-Onciul | 16 | 8 | 121 | 337 |
| 3. | Daniel-Constantin Mierla (@miconda) | 11 | 9 | 24 | 20 |
| 4. | Stefan Darius (@dariusstefan) | 11 | 5 | 379 | 72 |
| 5. | Jan Janak (@janakj) | 9 | 4 | 386 | 34 |
| 6. | Razvan Crainea (@razvancrainea) | 6 | 4 | 62 | 5 |
| 7. | Jiri Kuthan (@jiriatipteldotorg) | 6 | 3 | 257 | 0 |
| 8. | Henning Westerholt (@henningw) | 4 | 2 | 3 | 3 |
| 9. | Elena-Ramona Modroiu | 3 | 2 | 28 | 0 |
| 10. | Ancuta Onofrei | 3 | 1 | 33 | 45 |
All remaining contributors: Konstantin Bokarius, Jesus Rodrigues, Edson Gellert Schubert.
(1) DevScore = author_commits + author_lines_added / (project_lines_added / project_commits) + author_lines_deleted / (project_lines_deleted / project_commits)
(2) including any documentation-related commits, excluding merge commits
(3) ignoring whitespace edits, renamed files and auto-generated files
By Commit Activity
Section titled “By Commit Activity”| # | Name | Commit Activity |
|---|---|---|
| 1. | Stefan Darius (@dariusstefan) | Jun 2026 - Jul 2026 |
| 2. | Razvan Crainea (@razvancrainea) | May 2011 - Jun 2026 |
| 3. | Bogdan-Andrei Iancu (@bogdan-iancu) | Jun 2002 - Oct 2009 |
| 4. | Daniel-Constantin Mierla (@miconda) | Nov 2006 - Mar 2008 |
| 5. | Konstantin Bokarius | Mar 2008 - Mar 2008 |
| 6. | Edson Gellert Schubert | Feb 2008 - Feb 2008 |
| 7. | Henning Westerholt (@henningw) | Aug 2007 - Dec 2007 |
| 8. | Jesus Rodrigues | Dec 2007 - Dec 2007 |
| 9. | Ancuta Onofrei | Sep 2007 - Sep 2007 |
| 10. | Elena-Ramona Modroiu | Oct 2005 - Jan 2007 |
All remaining contributors: Andrei Pelinescu-Onciul, Jan Janak (@janakj), Jiri Kuthan (@jiriatipteldotorg).
(1) including any documentation-related commits, excluding merge commits
Documentation
Section titled “Documentation”Contributors
Section titled “Contributors”Last edited by: Razvan Crainea (@razvancrainea), Bogdan-Andrei Iancu (@bogdan-iancu), Daniel-Constantin Mierla (@miconda), Konstantin Bokarius, Edson Gellert Schubert, Jesus Rodrigues, Elena-Ramona Modroiu, Jan Janak (@janakj).
License
Section titled “License”All documentation files (i.e. .md extension) are licensed under the Creative Common License 4.0