API Gateway provides API firewalling capabilities by embedding Apache ModSecurity. This is a toolkit for real-time HTTP traffic monitoring, logging, and access control. This helps companies to mitigate application-level threats to their APIs. For example, this includes cross-site scripting, SQL injection, command injection, cross-site request forgery, and many others.
API Gateway administrators can configure the embedded ModSecurity engine to protect API Gateway HTTP traffic against threats and monitor reported exceptions. This chapter explains how to enable API firewalling on an API Gateway interface in Policy Studio, and how to monitor API firewalling in the API Gateway Manager web console.
For more details on ModSecurity, see www.modsecurity.org.
This section explains how to configure API firewalling by enabling threat protection and configuring threat protection rules.
The embedded ModSecurity engine is not enabled by default. To enable ModSecurity on an API Gateway interface, perform the following steps:
-
In the Policy Studio tree on the left, select the interface port that you wish to enable (for example, under Listeners > API Gateway > Default Services > Ports).
-
Right-click the HTTP or HTTPS interface in the window on the right, and select Edit.
-
Click the Advanced tab, and select Protect this interface with Threat Protection rules.
ModSecurity provides very little protection on its own. However, you can configure the required protection by configuring its rules engine. Protecting against specific threats requires specific rules, and different vendors provide rules for specific threat protection capabilities. The Open Web Application Security Project (OWASP) ModSecurity Core Rule Set (CRS) project provides a popular rule set.
When threat protection has been enabled, the embedded ModSecurity engine looks for threat protection rules configuration in the following directory:
$VDISTDIR/system/conf/threat-protection/default
The API Gateway uses the OWASP ModSecurity CRS folder structure, and expects to find the following
inside the threat-protection/default directory:
-
modsecurity.conffile: Contains the engine global settings. For details on the file format and recommended settings, see the "Recommended Base Configuration" in the ModSecurity documentation. -
activated_rulesfolder: Containing the threat protection rules files. All files with a.confextension in this folder are loaded by the embedded ModSecurity engine.
![[Note]](../common_oracle/images/admon/note.png) |
Note |
|---|---|
|
The recommended ModSecurity default configuration sets the engine mode to You must restart the API Gateway instance after changing any ModSecurity configuration. |
An API Gateway administrator or operator can use the Traffic > HTTP tab in the API Gateway Manager web console to monitor API firewalling. You can use this tab to show how threat protection affects the HTTP traffic served by the API Gateway.
You can filter this tab to display by Threat Protection to quickly locate all passed or failed transactions.
For example, perform the following steps:
-
Click Filter + in the search pane on the left.
-
Select Threat Protection in the list.
-
Select a threat protection status in the dialog:
-
Pass: The ModSecurity engine marks all transactions that pass its rules with this status.
-
Fail: Transactions that violate any active ModSecurity engine rules are marked with this status. These transactions should be monitored because they represent a false positive (the protection rules might need to be adjusted), or malicious client traffic. You can view more details about the failure reason and specific rule violation by drilling down a specific transaction and looking at the trace details.
-
Exception: Transactions that cause a rule processing or other unknown error are marked with this status. These should not occur and probably indicate some rule configuration problem.
-
-
Click Apply.
For example, the following shows detailed trace output from drilling down a failed transaction:
Message: Access denied with code 403 (phase 2). Pattern match
"(?i:(?:\\b(?:(?:s(?:ys\\.(?:user_(?:(?:t(?:ab(?:_column|le)|rigger)|object|view)
s|c(?:onstraints|atalog))|all_tables|tab)|elect\\b.{0,40}\\b(?:substring|users?|ascii))
|m(?:sys(?:(?:queri|ac)e|relationship|column|object)s|ysql\\.(db|user))|c(?:onstraint ..."
at ARGS:q. [file "C:\Axway\APIGateway\apigateway\system\conf\threat-protection\default\
activated_rules\modsecurity_crs_41_sql_injection_attacks.conf"] [line "116"] [id "950007"]
[rev "2"] [msg "Blind SQL Injection Attack"] [data "Matched Data: SELECT * FROM USERS
found within ARGS:q: SELECT * FROM USERS"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.9"]
[maturity "9"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"]
[tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]
For more details on OWASP, see https://www.owasp.org.
For more details on supported security features, see the API Gateway Security Guide.
