How to Add New Extensions to CEP
Table With the Correlation Engine Rules

How to Add New Extensions to CEP

Downloading and Decompressing the Project.

To add extensions to the Complex Event Processor (CEP), you must first download the most current version of the project located in Github:

Link: https://github.com/redBorder/cep

To do this, you must click on "Clone or download", and then "Download ZIP."

After decompressing the resulting .zip file, it should look something like this:

Downloading and Adding Extensions to pom.xml

Now, you need to edit the pom.xml file with whatever editor you have. In this case, you will add several extensions of Siddhi, therefore, you will go to its corresponding section:

You can find all the extensions of Siddhi available in this link: https://wso2.github.io/siddhi/extensions/ or https://github.com/wso2-extensions

In this case, let's use "execution map" and "execution regex" extensions. It is important to use a compatible version with the CEP project downloaded previously. In this case you will use version 3.2.0.

You only have to add them as a dependency of Maven in the pomp.xml opened previously adding the corresponding version.

The final result would be something like this:

Installing Maven and Compiling the Project

The next step is to install Maven in the system that you are using at this moment, in my case Windows 10. In this link it appears all the information related to the download in installation:

https://maven.apache.org/index.html

After installing maven, you will open the terminal and place ourselves in the project folder. Then you will execute the following commands:

mvn clean

mvn compile

mvn install

It will be something like this:

If everything goes well, you should obtain a file similar to the one shown in the image:

Last Steps

The next step is disable the CEP service with the following commands:

rb_set_service.sh cep:0

service cep stop

to access the /opt/rb/var/cep/app/ directory of the redborder manager where you want to update CEP. Then you must replace the new file cep-0.1.1-SNAPSHOT-selfcontained.jar with the existing one.

For the last step you must delete the file cep.jar, to create a new one by using the following command using softlink:

ln -s cep-0.1.1-SNAPSHOT-selfcontained.jar ./cep.jar

Everything would be done, you would only need to enable the CEP service.

 rb_set_service.sh cep:1

service cep start

Table with the Correlation Engine Rules

Rule	Description
Local Linux Brute Force Authentication	This rule is capable of generating an alert when there are 10 unsuccessful log-in attempts in a 20 minute time window on a Linux machine locally.
SSH Brute Force Authentication	This rule is capable of generating an alert when 200 unsuccessful log-in attempts occur in a 20 minute time window on a Linux machine via SSH protocol (e.g., openssh-server).
FTP Brute Force Authentication	This rule is capable of generating an alert when 200 unsuccessful log-in attempts occur in a 20 minute time window on a Linux machine via FTP protocol (e.g., vsftpd-server).
HTTP Brute Force Authentication	This rule is capable of generating an alert when 200 response codes are produced whose request has not been processed (eg, 401 Unauthorized or 403 Forbidden) in a 20 minute time window on a Linux machine using HTTP protocol (e.g., Apache-server).
Telnet Brute Force Authentication	This rule is capable of generating an alert when 200 unsuccessful log-in attempts occur in a 20 minute time window on a Linux machine via Telnet protocol (e.g., telnetd-server).
RDP Brute Force Authentication	This rule is capable of generating an alert when 10 unsuccessful log-in attempts occur in a 20 minute time window on a Linux machine via RPD protocol (e.g., xrdp-server).
Local Windows Brute Force Authentication	This rule is capable of generating an alert when there are 10 unsuccessful log-in attempts in a 20 minute time window on a Windows machine locally.
Samba Brute Force Authentication	This rule is capable of generating an alert when 10 unsuccessful log-in attempts occur in a 20 minute time window on a Linux machine via Samba protocol (e.g., smbd-server).
SIP Brute Force Authentication	This rule is capable of generating an alert when 200 unsuccessful log-in attempts occur in a 20 minute time window on a Linux machine via SIP protocol (e.g., asterisk-server).
Local Successful Authentication After Brute Force Attack in Linux	This rule is capable of generating an alert when a successful start attempt is made after a brute-force attack with a 10 attempt dimension occurs in a 20 minute time window on a Linux machine locally.
Successful SSH Authentication After Brute Force Attack	This rule is capable of generating an alert when a successful start attempt is made after a brute-force attack with a 200 attempt dimension occurs in a 20 minute time window on a Linux machine via SSH protocol (e.g., openssh-server).
Successful FTP Authentication After Brute Force Attack	This rule is capable of generating an alert when a successful start attempt is made after a brute-force attack with a 200 attempt dimension occurs in a 20 minute time window on a Linux machine via FTP protocol (e.g., vsftpd-server).
Successful Telnet Authentication After Brute Force Attack	This rule is capable of generating an alert when a successful start attempt is made after a brute-force attack with a 200 attempt dimension occurs in a 20 minute time window on a Linux machine via Telnet protocol (e.g., telnetd-server).
Successful HTTP Authentication After Brute Force Attack	This rule is capable of generating an alert when a successful request (code 200) occurs after receiving 200 response codes whose request has not been processed (eg, 401 Unauthorized or 403 Forbidden) in a 20 minute time window on a Linux machine using HTTP protocol (e.g., Apache-server).
Successful RDP Authentication After Brute Force Attack	This rule is capable of generating an alert when a successful start attempt is made after a brute-force attack with a 200 attempt dimension occurs in a 20 minute time window on a Linux machine via RDP protocol (e.g., xrdp-server).
Local Successful Authentication After Brute Force Attack in Windows	This rule is capable of generating an alert when a successful start attempt is made after a brute-force attack with a 10 attempt dimension occurs in a 20 minute time window on a Windows machine locally.
Successful Samba Authentication After Brute Force Attack	This rule is capable of generating an alert when a successful start attempt is made after a brute-force attack with a 200 attempt dimension occurs in a 20 minute time window on a Linux machine via Samba protocol (e.g., smbd-server).
Successful SIP Authentication After Brute Force Attack	This rule is capable of generating an alert when a successful start attempt is made after a brute-force attack with a 200 attempt dimension occurs in a 20 minute time window on a Linux machine via SIP protocol (e.g., asterisk-server).

Guide to add new extensions to CEP and table with the Correlation Engine Rules