Discover how to implement WAAP – WEB Application and API Protection with SKUDONET

What are a WEB Application and API Protection (WAAP)

The Web Application and API protection(WAAP) is a progressive evolution of the SKUDONET 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 SKUDONET 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 SKUDONET works as a WAAP

SKUDONET ADC includes a Cybersecurity module called IPDS (Intrusion prevention and detection system). This module offers WAAP capabilities, automation, and learning for WEBs and APIs. SKUDONET includes a package called skudonet-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.
• ssh_bruteforce: The included source is a list of ssh attackers using brute force techniques to obtain the user and password of the ssh attacked server.
• 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.
• wordpress_list: All IPs which attack Joomla, WordPress, and other Web-Logins with Brute-Force Logins.
• Private_networks: The source included is a list based on all the IPv4 source address not routable on the internet.
• mail_list: All IP addresses which have been reported within the last 48 hours as having run attacks on the service Mail, Postfix.
• ssh_list: All IP addresses which have been reported within the last 48 hours as having run attacks on the service SSH.
• ftp_list: All IP addresses which have been reported within the last 48 hours for attacks on the Service FTP.
• apache_list: All IP addresses which have been reported within the last 48 hours as having run attacks on the service Apache, Apache-DDOS, RFI-Attacks
• 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. SKUDONET 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. SKUDONET monitors and controls TCP flow. If an unexpected packet is received, SKUDONET will drop it.

Total connection limit per source IP:
SKUDONET applies a source limit based on the number of requests per second, and when the limit per source IP is reached, SKUDONET 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:
SKUDONET applies a destination limit based on the number of requests per second. If the limit per destination IP is reached, SKUDONET 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.

SKUDONET 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. Each DNS zone resolves source IPs based on different behaviors, and these zones have been described below:

• zone all.rbl.skudonet.com: The source IP will try to be resolved against all the subzones included in the rbl.skudonet.com.
• zone apache.rbl.skudonet.com: The source included in this subzone does reference attackers against Apache hosts.
• zone asterisk.rbl.skudonet.com: The sources included in this subzone do reference attackers against Asterisk Hosts.
• zone bruteforcelogin.rbl.skudonet.com: The source included in this subzone does reference attackers that tried to obtain users and passwords against various host services using brute force mechanisms.
• zone ftp.rbl.skudonet.com: The source included in this subzone does reference attackers against FTP Hosts.
• zone mysql.rbl.skudonet.com: The source included in this subzone does reference attackers against Mysql Hosts.
• zone ssh.rbl.skudonet.com: The source included in this subzone does reference attackers against SSH Hosts.
• zone webmin.rbl.skudonet.com: The source included in this subzone does reference attackers against Webmin web Application.
• zone apacheddos.rbl.skudonet.com: The source included in this subzone does reference attackers against the web server, Apache, using Distributed denial of service mechanism.
• zone mail.rbl.skudonet.com: The source included in this subzone does reference attackers against mail Hosts.

WAF rules

SKUDONET inspects HTTP(S) traffic in two ways:

1. Using predefined rules based on OWASP rulesets (Open Web Application Security Project). The rulesets included in SKUDONET 6.3 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. SKUDONET uses the ModSecurity engine support to 3rd party rulesets or creating your own rules based on the dissector HTTP language.

By default, SKUDONET 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 SKUDONET 6.3 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 skudonet-ipds packet, which works as the core for the engine, keeping this engine updated with SKUDONET rules and those customized by the customer.

This skudonet-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 SKUDONET 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.

More content related to WAAP Security and SKUDONET

Do you want to know more related to Web Application and API protection?

Read more about How Skudonet WAF audits https traffic