Securing SAP with AWS Network Firewall: Part 2 – Managed Rules

This post was jointly authored by the following individuals from AWS and Fortinet:
Ferry Mulyadi, Principal Partner Solution Architect, AWS

Derek Ewell, Principal Partner Solution Architect, AWS
Julian Petersohn, Global SAP Engineer, Fortinet
Fabian Lee, Solution Architect, AWS


Per CyberCrime’s editor in chief Steve Morgan “Cybercrime To Cost The World $10.5 Trillion Annually by 2025”– which would make it the world’s third-largest economy after the U.S. and China. Given that SAP systems house mission-critical data that is often highly sensitive, they are logical targets for bad actors, making it critical that customers proactively defend against this threat. For SAP customers who are modernizing to S/4HANA, the security risk landscape is shifting to new areas such as SAP Fiori, the web user interface, mobile devices, system interfaces and cloud services that are connected to SAP applications. This eventually pushes SAP customers to implement additional security controls, outside of security updates, for their business-critical enterprise system.

In order to help SAP customers, we wrote a blog series on how AWS Network Firewall can improve security of SAP on AWS deployment. In the first blog, we discussed the various architecture patterns which can be deployed for SAP customers based on SAP use-cases such as incoming and outgoing interfaces, SAP support, remote users, mobile access, and SAP BTP integration. The architecture pattern is based on our AWS Security Reference Architecture (SRA) and Inspection Deployment Models with AWS Network Firewall, which prevents malicious actors from impacting the performance and availability of your SAP system and prevent data theft from your SAP system.

Being customer-obsessed, we are always listening to our customers and partners on how we can further help to improve the deployment speed of the AWS Network Firewall. When we deploy Network Firewall, one of the tasks is to define firewall rules with fine-grained control over SAP network traffic. This task can be daunting if you are starting from scratch.

With AWS Managed Rules, you can jump start the implementation of these firewall rules, as they are ready-to-use rules that AWS writes and maintains, and it is available to AWS customers for free. We will also cover Custom Rules and Partner Managed Rules so you can further deploy more specialized rules to meet your organizational security needs. In this blog, we have invited Fortinet to share about their managed IDS and IPS rules for Amazon Network Firewall.

AWS Managed Rules for Network Firewall

AWS Network Firewall offers a flexible firewall rule engine to enforce fine-grained network protection. AWS Managed rules for Network Firewall are predefined and ready-to-use firewall rules. AWS automatically updates the managed rule groups when new vulnerabilities and threats emerge.

AWS managed rule groups are designed to protect Enterprise workload from common threats by adding another layer of security for your applications. However, AWS managed rule groups are not intended as a replacement for your security responsibilities. Please refer to the Shared Responsibility Model to ensure that your resources in AWS are properly protected.

Today, AWS managed rule groups include:

Managed Domain List Rule Groups (Egress Filtering)

Domain list rules block HTTP or HTTPS traffic to domains identified as low-reputation, or that are known or suspected to be associated with malware or botnets. When deploying these rule groups with “A2. Architecture design pattern for Internet egress access” found in Part 1 of this blog series, you can block suspicious egress traffic originating from your SAP environment.

Rule Name Description
AbusedLegitBotNetCommandAndControlDomainsActionOrderRules Rules that allow you to block requests to a class of domains, which are generally legitimate but are compromised and may host botnets
MalwareDomainsActionOrder Rules that allow you to block requests to domains that are known for hosting malware.
AbusedLegitMalwareDomainsActionOrder Rules that allow you to block requests to a class of domains, which are generally legitimate but are compromised and may host malware.
BotNetCommandAndControlDomainsActionOrder Rules that allow you to block requests to domains that are known for hosting botnets.

Amazon Network Firewall determines the domain name of requests by the Server Name Indication (SNI) extension during TLS negotiation for HTTPS, and the host header for HTTP traffic. To filter domains at a DNS resolution level, you can leverage Amazon Route 53 Resolver DNS firewall in conjunction with Amazon Network Firewall rules for additional protection, as described in our blog post: Secure your Amazon VPC DNS resolution with Amazon Route 53 Resolver DNS Firewall.

Threat Signature Rule Groups that are applicable to SAP

AWS Network Firewall managed threat signature rule groups support several categories of threat signatures to protect against various types of malware and exploits, denial of service attempts, botnets, web attacks, credential phishing, scanning tools, and mail or messaging attacks. There are also signatures for intrusion detection and to enforce fair use policies as well as guard against emerging threats. Currently, Network Firewall supports only Suricata-compatible stateful managed rule groups.
The rules in the table below will block malicious requests with known Signatures that are harmful to the SAP’s technology stack. We’ve excluded rules as they are not related to SAP use cases, such as: Malware Coin Mining, VOIP, Games, Inappropriate, P2P. You can pre-select these rules that are applicable to optimize the cost of your implementation.

Category Rule name
Botnet ThreatSignaturesBotnet – Signatures that are autogenerated from several sources of known and confirmed active botnet and other Command and Control (C2) hosts.
Botnet Web ThreatSignaturesBotnetWeb – Signatures that detects HTTP botnets.
Compromised ThreatSignaturesIOC – Attack Response – Signatures to identify responses indicative of intrusion—examples included but not limited to LMHost file download, presence of certain web banners and the detection of Metasploit Meterpreter kill command.
Exploit Kit – Signatures to detect activity related to Exploit Kits, their infrastructure, and delivery.
DoS ThreatSignaturesDoS – Signatures that detect Denial of Service (DoS) attempts.
Emerging Threats ThreatSignaturesEmergingEvents – Current Events – Signatures with rules developed in response to active and short-lived campaigns and high-profile items that are expected to be temporary.
DoS ThreatSignaturesDoS – Signatures that detect Denial of Service (DoS) attempts.
Exploits ThreatSignaturesExploits – Exploits – Signatures that protect against direct exploits not otherwise covered in a specific service category. ActiveX, FTP, ICMP, NetBIOS, Remote Procedure Call (RPC), ShellCode (remote shellcode detection), Simple Network Management Protocol (SNMP), Telnet, Trivial File Transport Protocol (TFTP), Structured Query Language (SQL).
Malware ThreatSignaturesMalware – Signatures that detect malware (TCP, UDP, SMTP, ICMP, SMB, IP) and WORM. Malware – Detects malicious software. Rules in this category detect activity related to malicious software that is detected on the network Worm – Detects malicious activity that automatically attempts to spread across the internet or within a network by exploiting a vulnerability.
Malware Mobile ThreatSignaturesMalwareMobile – Signatures that indicate malware that’s associated with mobile and tablet operating systems such as Google Android, Apple iOS, and others.
Malware Web ThreatSignaturesMalwareWeb – Signatures that detect malicious code in HTTP and TLS protocols.
Phishing ThreatSignaturesPhishing – Signatures that detect credential phishing activity.
Scanners ThreatSignaturesScanners – Signatures that detect reconnaissance and probing from tools such as Nessus, Nikto, and other port scanning tools. User Agents – Signatures that detect suspicious and anomalous user agents.
Web Attacks ThreatSignaturesWeb – Web Client – Signatures that detect attacks and vulnerabilities regarding web clients such as web browsers as well as client-side applications like CURL, WGET and others. Web Server – Signatures that detect attacks against web server infrastructure such as APACHE, TOMCAT, NGINX, Microsoft Internet Information Services (IIS) and other web server software. Web Specific Apps – Signatures that detect attacks and vulnerabilities in specific web applications.

Testing of AWS Network Firewall with AWS Managed Rules

After implementing AWS Managed Rules, you may want to validate that the rules. You can do the following:

  • Let’s take a “ThreatSignaturesWeb” rule as an example
  • If there is a SAP Server serving Fiori where traffic will be inspected by AWS Network Firewall, you can try injecting payloads into a query segment of the webserver by using tools curl, metasploit, etc. You can refer to the examples in this blog.
  • You will begin seeing the matches in CloudWatch Logs Log Group for the Log Destination for Alerts.
  • You can then look up the matching AWS Network Firewall Managed Rule by using the signature as an identifier. Here is an example below:
"alert": {
            "action": "blocked",
            "signature_id": 2811788,
            "rev": 7,
            "signature": "ipTIME firmware < 9.58 RCE",
            "category": "Web Application Attack",
            "severity": 1,
            "metadata": {
                 "created_at": [
                "updated_at": [
        "http": {
            "hostname": "",
            "http_port": 80,
            "url": "/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh",
            "http_user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36",
            "http_method": "POST",
            "protocol": "HTTP/1.1",
            "length": 0
        "files": [
                "filename": "/bin/sh",
                "sid": [],
                "gaps": false,
                "state": "CLOSED",
                "stored": false,
                "size": 33,
                "tx_id": 0
        "app_proto": "http"

Custom Firewall Rules

AWS Network Firewall uses two rules engines to inspect packets. The engines inspect packets according to the rules configured in your firewall policy.

  • Stateless rules engine – Inspects each packet in isolation, without regard to factors such as the direction of traffic, or whether the packet is part of an existing, approved connection. Network Firewall stateless rules are similar in behaviour and use to Amazon VPC network access control lists (ACLs).
  • Stateful rules engine – Inspects packets in the context of their traffic flow, allows you to use more complex rules, and allows you to log network traffic and to log Network Firewall alerts on traffic. Stateful rules consider traffic direction. The stateful engine takes rules that are compatible with Suricata, an open-source intrusion prevention system (IPS). For more information, you can refer Working with stateful rule groups in AWS Network Firewall.

You can write your own custom firewall rules by following these blogs:

Examples rules relevant for SAP applications:

#These example Firewall Rules will alert SQL injection attempts to SAP MaxDB Sybase database as well as SAP Netweaver AS Java Use Case
#alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE SAP MaxDB error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"SQL error"; fast_pattern; content:"POS("; distance:0; pcre:"/SQL error.*POS\([0-9]+\)/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020545; rev:2;)
#alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE SAP MaxDB error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Warning"; content:"maxdb"; fast_pattern; distance:0; pcre:"/Warning.*maxdb/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020546; rev:2;)
#alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Warning"; content:"sybase"; fast_pattern; distance:0; pcre:"/i?Warning.*sybase/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020547; rev:3;)
#alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Sybase message"; fast_pattern:only; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020548; rev:2;)
#alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Sybase Server message"; fast_pattern:only; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020549; rev:2;)
alert http any any -> $HOME_NET any (msg: "ATTACK [PTsecurity] SAP NetWeaver AS Java UDDI 7.11-7.50 SQL Injection (CVE-2016-2386)"; flow: established, to_server; content: "POST"; http_method; content: "/UDDISecurityService/UDDISecurityImplBean"; http_uri; fast_pattern; content: "permissionId"; http_client_body; content: "|27|"; http_client_body; distance: 0; pcre: "/permissionId\s*>[^<]+?\x27/Pi"; reference: cve, 2016-2386; reference: url,; classtype: attempted-recon; reference: url,; sid: 10002408; rev: 1; )

Partner Managed Rules

If your security needs go beyond the ready-to-use AWS Managed Rules, you can leverage Partner’s delivered solutions. In this blog, we will cover managed IDS and IPS rules from AWS Partner Fortinet.
Fortinet Managed IPS Rules for AWS Firewall provides a set of pre-configured rules for AWS Network Firewall designed to detect and prevent a range of network attacks. These rules can be used to protect against known vulnerabilities and exploits, Web application attacks, as well as zero-day attacks, which are previously unknown exploits that are difficult to detect with traditional security measures.
Fortinet Managed IPS Rules are regularly maintained to stay up-to-date with the latest threat intelligence data powered by FortiGuard Labs, ensuring that your environment is protected against the latest threats. This can be particularly important for SAP Landscapes, which can be targeted by attackers due to the sensitive data they store.
There are multiple sets of groups to fulfill the requirements of customer deployments. These rule sets are as follows:

Name Technical Name
Client Vulnerabilities Fortinet-ips-client-enable-rulegroup1
Malware Detection Fortinet-ips-malware-enable-rulegroup1
Server and OS Vulnerabilities Fortinet-ips-serveros-enable-rulegroup1
Web Client Vulnerabilities Fortinet-ips-webclient-enable-rulegroup1
Web Application Vulnerabilities Fortinet-ips-webapp-enable-rulegroup1
Web Server Vulnerabilities Fortinet-ips-webserver-enable-rulegroup1

Each set of rules consists of two sub-sets – intrusion detection and intrusion prevention signatures:

  • Intrusion prevention signatures (IPS) can perform DROP or ALERT action.
  • Intrusion detection signatures (IDS) can perform only ALERT action.

Overall, the Fortinet Managed IPS Rules for AWS Firewall can provide an additional layer of security to your SAP Landscape, helping to protect your business-critical data and applications.
For more Information on how to setup and validate Fortinet Managed Rules for AWS Firewall, please refer to the Administration Guide

Intrusion Prevention Signature Rules dedicated to SAP

Fortinet offers Managed AWS Network Firewall rules tailored specifically for SAP, as well as a range of other security solutions such as firewalls, endpoint protection, and cloud security services. These solutions provide advanced threat detection and prevention capabilities to help organizations secure their SAP systems against a wide range of known and emerging threats.
Fortinet provides over 60 (and growing) specific signatures to prevent attacks or malicious behavior specific to SAP Applications. These signatures are part of the Managed IPS rules provided by Fortinet.

Signature Name  Severity  Area
SAP.Netweaver.publicinfo.HTTP.Request.Smuggling Severity 5  Server 
SAP.Netweaver.Visual.Composer.Unrestricted.File.Upload Severity 5  Server 
SAP.Netweaver.LM.Configuration.Wizard.Authentication.Bypass Severity 5  Server
SAP.Netweaver.SOAP.Query.Directory.Traversal Severity 4  Server
SAP.Solution.Manager.SMDAgent.Remote.Code.Execution Severity 5  Server
SAP.Netweaver.Log.Injection.Remote.Command.Injection Severity 3  Server
SAP.Netweaver.DIAG.Request.DoS Severity 4  Server
SAPGUI.Regsver32.Rule.Security.Policy.Bypass Severity 5  Client
SAP.Netweaver.CrashFileDownloadServlet.Directory.Traversal Severity 4  Server
SAP.Netweaver.UDDI.Server.SQL.Injection Severity 5  Server
SAP.SQL.Anywhere.NET.Data.Provider.Column.Alias.Buffer.Overflow Severity 4  Server
SAP.Sybase.Event.Stream.Processor.DoS Severity 3  Server
SAP.Sybase.Event.Stream.Processor.Code.Execution Severity 3  Server

Figure 1. Example of SAP specific signatures in Fortinet Managed IPS rules.

To avoid complexity, these signatures are distributed over the provided rule groups. To secure an SAP deployment, the following rule groups are highly relevant.

  • Server and OS Vulnerabilities
  • Web Application Vulnerabilities
  • Web Server Vulnerabilities
  • Client Vulnerabilities
  • Malware Detection

To identify which rule groups is relevant for your use case, you can refer to the Administration Guide – use case section. For example: For a SAP S/4 HANA deployment on AWS, the following rule groups are applicable: Server and OS Vulnerabilities, Web Server Vulnerabilities and Web Application Vulnerabilities.

  • The Server and OS Vulnerabilities rule group prevents attacks against the Operating System and SAP Services like SAP Web Dispatcher, RFC (Remote Function Call) Gateway, etc.
  • As SAP moves towards SAP web-base front-end Fiori, HTTP(s) requests need to be secured against The OWASP Top 10 (Open Web Application Security Project). To secure such HTTP(s) requests, it is strongly recommended to implement a Web Application Firewall like AWS WAF or FortiWeb, which are designed for analysing information at Layer 7 of the OSI Model, such as HTTP headers, HTTP body, URI strings and paylods to identify SQL injection and cross-site scripting. The aforementioned Web Server Vulnerabilities, and Web Application Vulnerabilities managed rule groups provide basic web protection in such scenarios.
  • In the context of protecting SAP S/4HANA deployment on AWS, the Client Vulnerabilities rule group is not used. This rule group is only effective at blocking attacks against Client Software like Chrome Browser or SAP GUI, and not be able to prevent attacks against Server Components. If the SAP deployment would act as a client, e.g., to secure and filter the outgoing traffic (egress traffic), then the Client Vulnerabilities and Malware Detection rule groups would be relevant.

As these sets of rules get regular updates from the threat intelligence of FortiGuard Labs, the number of included Signatures will grow over time and include rules to block new attacks.

Design and Usage considerations when using AWS Network Firewall in SAP Environments

Before implementing AWS Network Firewall for SAP deployments on AWS, it is essential to consider several factors.

  • Consider using a combination of AWS WAF, AWS Network Firewall, and Amazon VPC security groups depending on your use case. AWS Web Application Firewall (WAF) provides Layer 7 protection for HTTP based traffic fronted by Application Load Balancer (ALB), Amazon API Gateway or Amazon CloudFront.
  • AWS Firewall Manager is a security management service that acts as a central place for you to configure and deploy firewall rules across AWS Regions, accounts, and resources in AWS Organizations. Firewall Manager helps you to ensure that all firewall rules are consistently enforced, even as new accounts and resources are created. Firewall Manager integrates with AWS Network Firewall, Amazon Route 53 Resolver DNS Firewall, AWS WAF, AWS Shield Advanced, and Amazon VPC security groups.
  • Always perform testing to avoid blocking legitimate traffic. You can copy AWS managed rule groups into a customer managed rule group, and customize or control the lifecycle of included rules. As a best practice, you may want to implement the AWS and Partner Managed Rules in your staging environment first for testing before you apply this in your production environment. This allows you to understand the impact of adding these new rules to your SAP environment, and customize them appropriately. AWS Network Firewall provides observability into the interactions between rules and traffic via “alert mode”. This allows you to test rules by alerting on rule matches instead of dropping them. For AWS Managed rule groups, step-by-step instructions to implement this can be found here. Fortinet Managed rules come in IPS and IDS version – IDS rules can be used for testing as they alert on rule matches.
  • Network Firewall rules and IPS Signatures can have a negative performance impact. The number of AWS network firewall rules have an impact on inspection performance. These rules operate by analyzing network traffic in real time, which can slow down network traffic processing and negatively impact your SAP application performance. For this reason, it is not recommended to inspect network traffic between SAP Application and Database components.
  • Ingress vs. Egress traffic inspection. Ingress traffic filtering with Network Firewall focuses on detecting and preventing threats that enter a network from external sources. Egress traffic filtering, on the other hand, is concerned with detecting and preventing threats that attempt to leave a network, such as data theft/exfiltration and other malicious activity. Keep in mind that SAP Systems can act as a client (example: outbound web interfaces), and relevant egress traffic inspection will then be applicable


We have discussed how ready-to-use AWS Managed Rules for AWS Network Firewall helps protect your SAP environment against well-known attacks. It provides this protection while reducing the overhead for you to implement and maintain custom firewall rules. When your security needs are not covered by existing AWS Managed Rules, you can augment them with solutions from AWS Partners, such as Fortinet.
Fortinet provides dedicated security services and support for SAP deployments, including a range of Fortinet Managed IPS rules designed specifically to secure SAP deployments on AWS. These IPS rules provide targeted threat detection and prevention capabilities to help organizations protect their SAP systems against a range of known and emerging threats. Fortinet’s commitment to SAP security underscores the importance of securing critical business systems and highlights the need for dedicated security solutions tailored to the unique needs of SAP environments.
In summary, AWS Network Firewall helps secure your SAP workload on AWS by inspecting and dropping suspicious network traffic, and provides a flexible stateless and stateful rule engine so you can protect your SAP system from emerging threats. A secure and performant SAP deployment on AWS enables SAP users to complete their mission critical business processes.
You can find out more about SAP on AWS and AWS Network Firewall from the AWS product documentation.
To find out more on Fortinet, you can look at SAP Security Solutions from Fortinet and how Fortinet can help to protect critical SAP Enterprise Environments.