What are a WEB Application and API Protection (WAAP) #

The Web Application and API protection(WAAP) is a progressive evolution of the RELIANOID security product, the Web Application Firewall (WAF). The WAAP offers the same features as a traditional WAF but also protects APIs besides web applications.

With the evolution of cloud services and SaaS (Software as a Service), the need for integrating various environments has advanced the usage of APIs, providing the best solution for orchestrating all those services. This functionality makes the WAAP more advanced than the WAF, as one may deploy A WAAP at the edge of a network containing public services or configure it in the same environment with an ADC.

So, it is here where the RELIANOID ADC and the WAAP unite to work together and offer protection for Web applications and APIs before the delivery of an application.

Why A WAAP is required #

Since one may access APIs and web Applications easily on the internet, security is a big concern because sensitive data is exposed. An attacker may cause a security breach to obtain private information. So, a WAAP is necessary since traditional web security won’t handle the following tasks:

Signature matching is not enough for application security:
The content of Web applications and APIs are continuously changing. So, the Signature of the content is hard to obtain. Since web-published content and APIs keep changing, the system requires constant learning.

Blocking traffic based on source IP or destination Port is not enough:
Traditional firewalls block IPs and Ports, but this information is usually encrypted. A mechanism to decrypt, analyze the content, and re-encrypt is vital. We use the TLS mechanism, so the WAAP can offer a deeper level of security.

HTTP(S) traffic is currently the most used and it can offer complexity in the analysis: Most web traffic is directed toward the Layer 7 protocol HTTP(S) of the OSI model, offering complexity in the behavior of the HTTP protocol defined in the ’80s to modern protocols used today. This obliges the security solution to not only use IPS or IDS mechanism but also be able to protect against attacks on the upper layer in the OSI model, layer 7 protocols like HTTP and HTTPS.

Which features a WAAP can offer that a traditional WAF can’t #

The WAAP offers tremendous capabilities that a traditional WAF can’t offer:

Automation and learning: The WAAP is an alive element integrated within an ADC. This security feature receives information and constantly learns using mechanisms like DoS Detection, bot detection, protocol protection, and enforcement, among others. The WAAP engine requires a channel for receiving INPUT data, where the WAAP engine is constantly receiving new information and comparing the received information to the processed and inspected data.

Secure APIs and Microservices: On a daily basis, engineers build APIs and microservices to offer public services. The WAAP must protect these endpoints, taking into consideration the exposed information.

How Relianoid works as a WAAP #

RELIANOID ADC includes a Cybersecurity module called IPDS (Intrusion prevention and detection system). This module offers WAAP capabilities, automation, and learning for WEBs and APIs. Relianoid includes a package called relianoid-ipds, and this package is updated daily. This package has more than 4 mechanisms for Web Applications and API protection. Its properties are:

Blocklist rules #

Blocklists are part of a security mechanism for grouping traffic based on geolocation and different sources, as described below:

geo_*: These blocklists include IPs and networks based on countries.
TOR_nodes: This blocklist is obtained from the TOR project. Here we can find the source IPs where TOR traffic is published on the internet.
webexploit: Members of the source list have been identified as web exploiters. These attackers attempted to execute multiple requests against web servers to find vulnerabilities.
spyware: The included source(s) is a list of malicious spyware and adware IP Address ranges.
proxy: contains TOR and other open proxies.
mail_spammer: The source included is a list based on IPs detected sending spam.
bad_peers: The source included is a list based on reports of bad deeds in p2p.
CIArmy: The included sources here are offered by the CIArmy project. This project provides the data source obtained by analyzing traffic based on a group of sentinels around the internet.
bogon: The source included here claims to be from an area of the IP address space reserved but not yet allocated or delegated by the Internet.

DOS rules #

Denial of Service mitigation is a set of rules meant to protect or reduce the impact of attacks on a service that renders it unusable due to overwhelming amounts of illegitimate requests. RELIANOID IPDS engine includes various techniques for performing DoS protection to Web Applications and APIs.

These rules have been described below:

Bogus TCP Flags:
In any TCP traffic, the TCP packets follow a known flow. A BOGUS TCP attack is one where the TCP flow doesn’t follow an expected TCP path. For example, the packet may follow an SYN-FIN path which is unexpected, instead of an SYN-ACK path. RELIANOID monitors and controls TCP flow. If an unexpected packet is received, RELIANOID will drop it.

Total connection limit per source IP:
RELIANOID applies a source limit based on the number of requests per second, and when the limit per source IP is reached, RELIANOID will drop the incoming packets.

Limit RST packet per second:
This is a common DoS attack in which the attacker attempts to open a TCP socket, and once the TCP response packet is received, the attacker sends a TCP RST packet to the host.

Connection limit per second:
RELIANOID applies a destination limit based on the number of requests per second. If the limit per destination IP is reached, RELIANOID will drop the incoming packets.

RBL rules #

A real-time blackhole list is a security system used by Mail Servers to protect against spammers. If the Mail server receives a connection, it captures the source IP and attempts to resolve it against known DNS servers. If the DNS resolution works, the source IP address will be detected as an attacker.

RELIANOID has evolved this security mechanism making it possible to capture any source IP in a certain flow and try to resolve the source IP against a DNS zone. For this purpose, a collection of some of the most robust RBL domains have been selected.

WAF rules #

RELIANOID inspects HTTP(S) traffic in two ways:

1 – Using predefined rules based on OWASP rulesets (Open Web Application Security Project). The rulesets included in RELIANOID 6 are based on OWASP Core Rule Set version 4. These rules are updated daily. If any change occurs in the OWASP ruleset, the next IPDS package update will include the changes.

2 – Using rules obtained from 3rd party vendors or custom rules designed by you, our customer. RELIANOID uses the ModSecurity engine support to 3rd party rulesets or creating your own rules based on the dissector HTTP language.

By default, RELIANOID IPDS includes security packets against the following attacks:

SQL Injection (SQLi)
Cross-Site Scripting (XSS)
Local File Inclusion (LFI)
Remote File Inclusion (RFI)
PHP/Java/Ruby/Perl Code Injection
Shellshock
Unix Shell Injection
Session Fixation
Scripting/Scanner/Bot Detection

The rulesets found in RELIANOID 6 Include:

REQUEST-905-COMMON-EXCEPTIONS
These rules are used as exception mechanisms to remove common false positives that may be encountered.
REQUEST-911-METHOD-ENFORCEMENT
Allowed request methods.
REQUEST-913-SCANNER-DETECTION
Checks for scanners like crawlers, bots, scripts, etc.
REQUEST-920-PROTOCOL-ENFORCEMENT
Validates HTTP requests eliminating a large number of application layer attacks.
REQUEST-921-PROTOCOL-ATTACK
Checks for protocol attacks.
REQUEST-930-APPLICATION-ATTACK-LFI
Checks for application attacks using Local File Inclusion (LFI).
REQUEST-931-APPLICATION-ATTACK-RFI
Checks for application attacks using Remote File Inclusion (RFI).
REQUEST-932-APPLICATION-ATTACK-RCE
Checks for application attacks using Remote Code Execution (RCE).
REQUEST-933-APPLICATION-ATTACK-PHP
Checks for application attacks using PHP.
REQUEST-934-APPLICATION-ATTACK-GENERIC
Check for application attacks using Node.js, Ruby, and Perl.
REQUEST-941-APPLICATION-ATTACK-XSS
Checks for application attacks using XSS.
REQUEST-942-APPLICATION-ATTACK-SQLI
Checks for application attacks using Sql Injection.
REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION
Checks for application attacks using session fixation.
REQUEST-944-APPLICATION-ATTACK-JAVA.
Checks for application attacks using Java.

The IPDS engine is a threat-intelligence mechanism for Web Applications and API protection. It updates daily through the relianoid-ipds packet, which works as the core for the engine, keeping this engine updated with RELIANOID rules and those customized by the customer.

This relianoid-ipds core ruleset uses various mechanisms for creating these security rules, like crossing 3rd party data, analyzing sentinel logs, or doing Big-data analysis against private information. If you identify that the RELIANOID IPDS core ruleset includes some source IPs or rules as false positives, contact us, and we will be glad to fix the issue as soon as possible.