Mitigating OWASP 2019 API Security Top 10 risks using F5 NGINX App Protect
This 2019 API Security article provides a valuable summary of the OWASP API Security Top 10 risks identified for that year, outlining key vulnerabilities. We will deep-dive into some of those common risks and how we can protect our applications against these vulnerabilities using F5 NGINX App Protect. API2:2019 - Broken User Authentication Problem Statement: A critical API security risk, Broken Authentication occurs when weaknesses in the API's identity verification process permit attackers to circumvent authentication mechanisms. Successful exploitation leads attackers to impersonate legitimate users, gain unauthorized access to sensitive data, perform actions on behalf of victims, and potentially take over accounts or systems. This demonstration utilizes the Damn Vulnerable Web Application (DVWA) to illustrate the exploitability of Broken Authentication. We will execute a brute-force attack against the login interface, iterating through potential credential pairs to achieve unauthorized authentication. Below is the selenium automated script to execute brute-force attack, submitting multiple credential combinations to attempt authentication. The brute-force attack successfully compromised the authentication controls by iterating through multiple credential pairs, ultimately granting access. Solution: To mitigate the above vulnerability, NGINX App Protect is deployed and configured as reverse proxy in front of the application and requests are first validated by NAP for the vulnerabilities. The NGINX App Protect Brute Force WAF policy is utilized as shown below. Re-attempt to gain access to the application using the brute force approach is rejected and blocked. Support ID verification in the Security logs shows request is blocked because of Brute Force Policy. Request captured in NGINX App Protect security log API3:2019 - Excessive Data Exposure Problem Statement: As shown below in one of the demo application API’s, Personal Identifiable Information (PII) data, like Credit Card Numbers (CCN) and U.S. Social Security Numbers (SSN), are visible in responses that are highly sensitive. So, we must hide these details to prevent personal data exploits. Solution: To prevent this vulnerability, we will use the DataGuard feature in NGINX App Protect, which validates all response data for sensitive details and will either mask the data or block those requests, as per the configured settings. First, we will configure DataGuard to mask the PII data as shown below and will apply this configuration. Next, if we resend the same request, we can see that the CCN/SSN numbers are masked, thereby preventing data breaches. If needed, we can update configurations to block this vulnerability after which all incoming requests for this endpoint will be blocked. If you open the security log and filter with this support ID, we can see that the request is either blocked or PII data is masked, as per the DataGuard configuration applied in the above section. Request captured in NGINX App Protect security log API4:2019 - Lack of Resources & Rate Limiting Problem Statement: APIs do not have any restrictions on the size or number of resources that can be requested by the end user. Above mentioned scenarios sometimes lead to poor API server performance, Denial of Service (DoS), and brute force attacks. Solution: NGINX App Protect provides different ways to rate limit the requests as per user requirements. A simple rate limiting use case configuration is able to block requests after reaching the limit, which is demonstrated below. API6:2019 - Mass Assignment Problem Statement: API Mass Assignment vulnerability arises when clients can modify immutable internal object properties via crafted requests, bypassing API Endpoint restrictions. Attackers exploit this by sending malicious HTTP requests to escalate privileges, bypass security mechanisms, or manipulate the API Endpoint's functionality. Placing an order with quantity as 1: Bypassing API Endpoint restrictions and placing the order with quantity as -1 is also successful. Solution: To overcome this vulnerability, we will use the WAF API Security Policy in NGINX App Protect which validates all the API Security event triggered and based on the enforcement mode set in the validation rules, the request will either get reported or blocked, as shown below. Restricted/updated swagger file with .json extension is added as below: Policy used: App Protect API Security Re-attempting to place the order with quantity as -1 is getting blocked. Validating the support ID in Security log as below: Request captured in NGINX App Protect security log API7:2019 - Security Misconfiguration Problem Statement: Security misconfiguration occurs when security best practices are neglected, leading to vulnerabilities like exposed debug logs, outdated security patches, improper CORS settings, unnecessary allowed HTTP methods, etc. To prevent this, systems must stay up to date with security patches, employ continuous hardening, ensure API communications use secure channels (TLS), etc. Example: Unnecessary HTTP methods/verbs represent a significant security misconfiguration under the OWASP API Top 10. APIs often expose a range of HTTP methods (such as PUT, DELETE, PATCH) that are not required for the application's functionality. These unused methods, if not properly disabled, can provide attackers with additional attack surfaces, increasing the risk of unauthorized access or unintended actions on the server. Properly limiting and configuring allowed HTTP methods is essential for reducing the potential impact of such security vulnerabilities. Let’s dive into a demo application which has exposed “PUT” method., this method is not required as per the design and attackers can make use of this insecure unintended method to modify the original content. Solution: NGINX App Protect makes it easy to block unnecessary or risky HTTP methods by letting you customize which methods are allowed. By easily configuring a policy to block unauthorized methods, like disabling the PUT method by setting "$action": "delete", you can reduce potential security risks and strengthen your API protection with minimal effort. As shown below the attack request is captured in security log which conveys the request was successfully blocked, because of “Illegal method” violation. Request captured in NGINX App Protect security log API8:2019 - Injection Problem Statement: Customer login pages without secure coding practices may have flaws. Intruders could use those flaws to exploit credential validation using different types of injections, like SQLi, command injections, etc. In our demo application, we have found an exploit which allows us to bypass credential validation using SQL injection (by using username as “' OR true --” and any password), thereby getting administrative access, as below: Solution: NGINX App Protect has a database of signatures that match this type of SQLi attacks. By configuring the WAF policy in blocking mode, NGINX App Protect can identify and block this attack, as shown below. App Protect WAF Policy If you check in the security log with this support ID, we can see that request is blocked because of SQL injection risk, as below. Request captured in NGINX App Protect security log API9:2019 - Improper Assets Management Problem Statement: Improper Asset Management in API security signifies the crucial risk stemming from an incomplete awareness and tracking of an organization's full API landscape, including all environments like development and staging, different versions, both internal and external endpoints, and undocumented or "shadow" APIs. This lack of comprehensive inventory leads to an expanded and often unprotected attack surface, as security measures cannot be consistently applied to unknown or unmanaged assets. Consequently, attackers can exploit these overlooked endpoints, potentially find older, less secure versions or access sensitive data inadvertently exposed in non-production environments, thereby undermining overall security posture because you simply cannot protect assets you don't know exist. We’re using a flask database application with multiple API endpoints for demonstration. As part of managing API assets, the “/v1/admin/users” endpoint in the demo Flask application has been identified as obsolete. The continued exposure of the deprecated “/v1/admin/users” endpoint constitutes an Improper Asset Management vulnerability, creating an unnecessary security exposure that could be leveraged for exploitation. <public_ip>/v1/admin/users The current endpoint for user listing is “/v2/users”. <public_ip>/v2/users with user as admin1 Solution: To mitigate the above vulnerability, we are using NGINX as an API Gateway. The API Gateway acts as a filtering gateway for API incoming traffic, controlling, securing, and routing requests before they reach the backend services. The server’s name used for the above case is “f1-api” which is listening to the public IP where our application is running. To query the “/v1/admin/users” endpoint, use the curl command as shown below. Below is the configuration for NGINX as API Gateway, in “api_gateway.conf”, where “/v1/admin/users” endpoint is deprecated. The “api_json_errors.conf” is configured with error responses as shown below and included in the above “api_gateway.conf”. Executing the curl command against the endpoint yields an “HTTP 301 Moved Permanently” response. https://f1-api/v1/admin/users is deprecated API10:2019 - Insufficient Logging & Monitoring Problem Statement: Appropriate logging and monitoring solutions play a pivotal role in identifying attacks and also in finding the root cause for any security issues. Without these solutions, applications are fully exposed to attackers and SecOps is completely blind to identifying details of users and resources being accessed. Solution: NGINX provides different options to track logging details of applications for end-to-end visibility of every request both from a security and performance perspective. Users can change configurations as per their requirements and can also configure different logging mechanisms with different levels. Check the links below for more details on logging: https://www.nginx.com/blog/logging-upstream-nginx-traffic-cdn77/ https://www.nginx.com/blog/modsecurity-logging-and-debugging/ https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/ https://docs.nginx.com/nginx/admin-guide/monitoring/logging/ https://docs.nginx.com/nginx-app-protect-waf/logging-overview/logs-overview/ Conclusion: In short, this article covered some common API vulnerabilities and shows how NGINX App Protect can be used as a mitigation solution to prevent these OWASP API security risks. Related resources for more information or to get started: F5 NGINX App Protect OWASP API Security Top 10 2019 OWASP API Security Top 10 2023Overview of MITRE ATT&CK Framework and Initial Access Tactic (TA0001)
Introduction to MITRE ATT&CK: In today’s modern world, cyber threats are becoming more and more sophisticated, causing an urgent need for organizations across the world to understand how adversaries operate, so that they can protect their digital assets from being compromised. MITRE ATT&CK (Adversarial Tactics, Techniques and Common Knowledge) framework acts as a helpful resource for security teams in organizations to identify and analyze the attack patterns, techniques and tactics used to achieve exploitation. It is a globally accepted, continually updated and publicly available framework based on real-world observations of the latest cyber attacks. It keeps track of APT (Advanced Persistent Threat) groups and TTPs (Tactics, Techniques and Procedures) to provide guidance on procedures followed by the adversaries to compromise an organization’s resources. It is widely used in the cybersecurity field to improve security measures for organizations by enhancing their defensive capabilities. Here are some key words to be familiarized with before we dive deeper. APT (Advanced Persistent Threat): These are advanced groups of cyber attackers, heavily backed and funded to perform cyber-attack campaigns for a long period of time without getting detected. TTPs (Tactics, Techniques and Procedures): Tactics: It deals with the objective and goal of attackers Techniques: It deals with how attackers are going to accomplish their objective Sub-Techniques: It provides a more granular detail about the implementation of a specific technique Procedures: It deals with the implementation of techniques or sub-techniques to attain the objective. The current version of Enterprise ATT&CK matrix includes 14 tactics with each tactic containing multiple techniques and sub-techniques. Below are the tactics included in Enterprise matrix with their brief overview: TA0043 Reconnaissance: Gather information about the target. TA0042 Resource Development: Accumulate and prepare resources to carry out attacks. TA0001 Initial Access: Infiltrate into the target’s infra or network or system. TA0002 Execution: Run malicious code on victim’s system. TA0003 Persistence: Maintain access to the compromised system. TA0004 Privilege Escalation: Elevate privileges to access more sensitive information. TA0005 Defense Evasion: Bypass security detections. TA0006 Credential access: Steal credentials. TA0007 Discovery: Learn more about the compromised system’s environment. TA0008 Lateral Movement: Hop to other system’s connected in the same network. TA0009 Collection: Gather sensitive information. TA0011 Command and Control: Establish remote communication with compromised system. TA0010 Exfiltration: Steal data from the compromised system. TA0040 Impact: Destruction or manipulation of data or system, making it unavailable for victim Introduction to Initial Access Tactic (TA0001): As the name explains, Initial access means gaining access to the network. Initial Access tactic provides all the possible techniques used by adversaries to gain access and enter a network. This is a crucial phase in the attack lifecycle as the attacker looks for an entry point to step their foot into the network. Successful initial access can open the door to a wide range of exploitations like privilege escalation, confidential data theft and much more. Let us now quickly go through the techniques that fall under Initial Access and understand them. 1. Content Injection (T1659): Content Injection is a web application vulnerability where an attacker tries to manipulate and inject malicious content into a web page through a vulnerable endpoint within the application. Attackers can inject any type of content like harmful HTML, JavaScript or alter the existing content on the web page, which could lead to harmful consequences. Ideally, this type of attack takes place upon user interactions (click, enter data, submit a form). Example: File inclusion or upload 2. Drive-by Compromise (T1189): Using Drive-by compromise technique, the adversary typically tries to compromise the victim’s browser through a malicious or compromised website. Attackers inject malicious code such as malware, ransomware or exploit kits into the web page, which is then automatically executed when the victim visits the page without their knowledge or interaction. Example: Cross-Site Scripting 3. Exploit Public-Facing Applications (T1190): In this technique, attackers attempt to exploit vulnerabilities in publicly accessible web applications, web servers, or databases to gain access to a network. Vulnerability in the application, security misconfigurations, inadequate access control mechanisms, or the use of outdated or unpatched software are some of the possible reasons for these attacks. Such weaknesses provide attackers the opportunity to gain unauthorized access, escalate privileges, or compromise sensitive data. Example: SQL Injection 4. External Remote Services (T1133): Adversaries target to enter an organization’s network by exploiting weaknesses in external sources like VPNs, Remote Desktop Protocol (RDP), Citrix, Cloud Services, external file sharing and others that allow remote access to the internal systems. Lack of proper authentication mechanisms, access control, VPN misconfiguration and usage of insecure connections lay the path to this type of attack. 5. Hardware Additions (T1200): In this technique, the attacker exploits the target system/network by connecting new hardware, networking devices or other computing devices to gain access. Attackers can use USB keyloggers to capture keystrokes and steal credentials or can use routers/switches/passive network tapping/network traffic modification that can intercept or control networks. As this technique involves physical hardware, it provides persistent access to the attacker even if the software’s defenses are intact. 6. Phishing (T1566): Phishing is a technique in which attackers exploit an individual/organization by sending deceptive emails, texts, files that appear to be from trusted and legitimate sources. Attackers craft and design the content to trick users into clicking malicious links, downloading attachments, or revealing personal sensitive information such as usernames, passwords, or financial details. A more targeted form of phishing is called Spearphishing. (.001) Spearphishing Attachment: This is a type of phishing in which an attacker sends an email or text with malicious files attached to them, such as executable files, PDFs, or Word Documents. When a user opens/downloads an attachment, a malicious payload will be injected into the system. (.002) Spearphishing Link: Here, adversaries send emails or texts with malicious links in it that look legitimate. When a user clicks or copy and pastes the URL into a browser, it can download the malicious content into the system or sometimes, the users are tricked into entering their personal information like credentials, bank details, Unique Identity numbers. (.003) Spearphishing via Service: Here, adversaries use third party online services or platforms like social media services, personal web mail as the source to conduct their phishing attack. (.004) Spearphishing Voice : Here, an attacker compromises a victim with voice communication. The attacker pretends to be a person from trusted organizations such as banks or government officials and tricks the victims into revealing sensitive information over the phone. 7. Replication Through Removable Media (T1091): Replication through removable media is a technique in which adversaries use removable media like USB drives, external hard disks to spread malicious payloads and also to replicate the malware between systems. Sometimes, malicious code can automatically execute when the device is plugged in if the system has autoplay or autorun enabled, or the attacker might rely on user interaction to run the malicious payload. 8. Supply Chain Compromise (T1195): In Supply Chain Compromise, an adversary targets and compromises a company’s supply chain such as suppliers, vendors, or third-party service providers before receipt by the end customer. Attackers can introduce malicious elements into Software updates, hardware or Dependent sources before its delivery. (.001) Compromise Software Dependencies and Development Tools: Here, an adversary tries to manipulate the third-party open-source software system, development tools or service providers that are being used by the organization. (.002) Compromise Software Supply Chain: Attacker manipulates software updates, libraries, or repository used for distributing software before it reaches out to the final customer. This compromised patch will be unknowingly installed by the organization when they update or install software. (.003) Compromise Hardware Supply Chain: Here, an attacker manipulates hardware components or devices before they reach the end-user. Once the device is installed within an organization, it provides a persistent backdoor for attackers. Example: Insecure Deserialization, log4j 9. Trusted Relationship (T1199): In Trusted Relationship technique, adversaries exploit the relationship between the target organization and their partners, vendors, or internal users to gain access. Adversaries focus the trusted entities and leverage them as sources of attack because these entities are typically subjected to less stringent scrutiny and may have elevated permissions to critical systems within the target organization, which adversaries can exploit to carry out their attack. Example: Unsafe Consumption of APIs 10. Valid Accounts (T1078): The Valid Accounts technique is one of the most common methods adversaries use to gain unauthorized access to systems by exploiting legitimate credentials. Attackers attempt to use stolen credentials or guessed passwords to gain access to the systems, leveraging the compromised or weak credentials as this can bypass security mechanisms, gain persistent and privileged access. Example: Brute Force (.001) Default Accounts: Here, adversaries try to exploit credentials of default accounts like Guest or Administrator accounts. Default accounts also include factory/provider set accounts on other types of systems, software, or devices, including the root user account in AWS and the default service account in Kubernetes. Failing to change the credentials provided for default accounts exposes the organization to high security risks. (.002) Domain Accounts: Here, adversaries exploit user or system credentials that are part of a domain. Domain accounts are managed by Active Directory Domain Services, where access and permissions are set across systems and services within the domain. (.003) Local Accounts: Adversaries exploit the credentials of local accounts. Local accounts are typically configured by an organization for use by users, remote support services, or for administrative tasks on individual systems or services. (.004) Cloud Accounts: Adversaries exploit valid credentials of cloud accounts to access cloud-based services and infrastructure. As organizations increasingly rely on cloud environments such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and other cloud platforms, adversaries target cloud accounts to exploit resources, steal data, or perform further malicious activities within the cloud environment. How F5 can help? F5 security solutions like WAF (Web Application Firewall), API security, and DDoS mitigation protect the applications and APIs across platforms including Clouds, Edge, On-prem or Hybrid thereby reducing security risks. In addition to the above solutions, F5 bot and risk management solutions effectively mitigate malicious bots and automation, which can enhance the security posture of your modern applications. The example attacks mentioned under techniques can be effectively mitigated by F5 products like Distributed Cloud, BIG-IP and NGINX. Here are a few links which explain the mitigation steps. Mitigating Cross-Site Scripting (XSS) using F5 Advanced WAF Mitigating Injection flaws using F5 Distributed Cloud Mitigating Log4j vulnerability using F5 Distributed Cloud Mitigating SQL injection using F5 NGINX App Protect For more details on the other mitigation techniques of MITRE ATT&CK Initial Access Tactic TA0001, please reach out to your local F5 team. NOTE: This is the first article in MITRE series and stay tuned for more tactics-related articles. Reference Links: MITRE ATT&CK® Initial Access, Tactic TA0001 - Enterprise | MITRE ATT&CK® MITRE ATT&CK: What It Is, How it Works, Who Uses It and Why | F5 LabsF5 NGINX Automation Examples [Part 1-Deploy F5 NGINX Ingress Controller with App ProtectV5 ]
Introduction: Welcome to our initial article on F5 NGINX automation use cases, where we aim to provide deeper insights into the strategies and benefits of implementing NGINX solutions. This series uses the NGINX Automation Examples GitHub repo and CI/CD platform to deploy NGINX solutions based on DevSecOps principles. Our focus will specifically address the integration of NGINX with Terraform, two powerful tools that enhance application delivery and support infrastructure as code. Stay tuned for additional use cases that will be presented in the upcoming content! In this detailed example, we will demonstrate how to deploy an F5 NGINX Ingress Controller with the F5 NGINX App Protect version 5 in the AWS, GCP, and Azure Cloud. We will utilize Terraform to set up an AWS Elastic Kubernetes Service (EKS) cluster that hosts the Arcadia Finance test web application. The NGINX Ingress Controller will manage this application for Kubernetes and will have security measures provided by the NGINX App Protect version 5. To streamline the deployment process, we will integrate GitHub Actions for continuous integration and continuous deployment (CI/CD) while using an Amazon S3 bucket to manage the state of our Terraform configurations. Prerequisites: F5 NGINX One License AWS Account - Due to the assets being created, the free tier will not work GitHub Account Tools Cloud Provider: AWS Infrastructure as Code: Terraform Infrastructure as Code State: S3 CI/CD: GitHub Action NGINX Ingress Controller: This solution provides comprehensive management for API gateways, load balancers, and Kubernetes Ingress Controllers, enhancing security and visibility in hybrid and multicloud environments, particularly at the edge of Kubernetes clusters. Consolidating technology streamlines operations and reduces the complexity of using multiple tools. NGINX App Protect WAF v5: A lightweight software security solution designed to deliver high performance and low latency. It supports platform-agnostic deployment, making it suitable for modern microservices and container-based applications. This version integrates both NGINX and Web Application Firewall (WAF) components within a single pod, making it particularly well-suited for scalable, cloud-native environments. Module 1: Deploy NGINX Ingress Controller with App Protect V5 in AWS Cloud Workflow Guides: Deploy NGINX Ingress Controller with App ProtectV5 in AWS Cloud Architecture Diagram Module 2: Deploy NGINX Ingress Controller with App Protect V5 in GCP Cloud Workflow Guides: Deploy NGINX Ingress Controller with App Protect V5 in GCP Cloud Architecture Diagram Module 3: Deploy NGINX Ingress Controller with App Protect V5 in Azure Workflow Guides: Deploy NGINX Ingress Controller with App Protect V5 in Azure Architecture Diagram Conclusion This article outlines deploying a robust security framework using the NGINX Ingress Controller and NGINX App Protect WAF version 5 for a sample web application hosted on AWS EKS. We leveraged the NGINX Automation Examples Repository and integrated it into a CI/CD pipeline for streamlined deployment. Although the provided code and security configurations are foundational and may not cover every possible scenario, they serve as a valuable starting point for implementing NGINX Ingress Controller and NGINX App Protect version 5 in your cloud environments.Mitigating OWASP Web Application Security Top 10 risks using F5 NGINX App Protect
The OWASP Web Application Security Top 10 outlines the most critical security risks to web applications, serving as a global standard for understanding and mitigating vulnerabilities. Based on data from over 500,000 real-world applications, the list highlights prevalent security issues. The 2021 edition introduces new categories such as "Insecure Design" and "Software and Data Integrity Failures" emphasizing secure design principles and proactive security throughout the software development lifecycle. For more information please visit: OWASP Web Application Security Top 10 - 2021 F5 products provide controls to secure applications against these risks. F5 NGINX App Protect offers security controls using both positive and negative security models to protect applications from OWASP Top 10 risks. The positive security model combines validated user sessions, user input, and application response, while the negative security model uses attack signatures to detect and block OWASP Top 10 application security threats. This guide outlines how to implement effective protection based on the specific needs of your application. Note - The OWASP Web Application Security Top 10 risks listed below are tested on both F5 NGINX App Protect versions 4.x and 5.x A01:2021-Broken Access Control Problem statement: As the risk name suggests, Broken Access Control refers to failures in access control mechanisms that lead to a vulnerable application. In this demonstration, the application is susceptible to “Directory/Path Traversal” via the URL, which allows unauthorized access to sensitive information stored on the server. Solution: F5 NGINX App Protect WAF(Web Application Firewall) offers an inherent solution to the “Directory/Path Traversal” vulnerability discussed, through its “app_protect_default_policy” bundle. This policy, which will be active by default when “App Protect” is enabled in the nginx configuration, helps prevent Directory/Path Traversal attacks by validating the values provided to the “page” key in URL. The attack request is recorded in the security log, indicating that the attack type is Predictable Resource Location, Path Traversal. The request was blocked, and the signatures responsible for detecting the attack are also visible. Note: The security log shown in the image below is not the default log configuration but has been customized by following the instructions provided in the link. A02:2021-Cryptographic Failures Problem statement: Earlier this attack was known as “Sensitive Data Exposure”, focusing on cryptographic failures that often result in the exposure of sensitive data. The “Juice Shop” demo application, as demonstrated below, is vulnerable to sensitive information disclosure due to the insecure storage of data, which is displayed in plain text to end users. Solution: F5 NGINX App Protect WAF provides best in class “Data Guard” policy, which can block as well as mask (based on policy configuration) sensitive information displayed to the end users. After applying the policy to mask the sensitive data, it’s observed the sensitive information which was visible(Fig. 2.1) is masked now. The attack request is recorded in the security log, indicating that the dataguard_mask policy is triggered, and the request was alerted. . 2.4 – Request captured in NGINX App Protect security log A03:2021-Injection Problem statement: An injection vulnerability arises when an application fails to properly handle user-supplied data, sending it to an interpreter (e.g., a database or operating system) as part of a query or command. Without proper validation, filtering, or sanitization, attackers can inject malicious code, leading to unauthorized access, data breaches, privilege escalation, or system compromise. For example, the DVWA demo application shown below lacks input validation, making it vulnerable to SQL injection attacks that can compromise confidential data. Solution: F5 NGINX App Protect WAF has a robust set of attack signatures which are pre-bundled in default policy. The SQL-Injection vulnerability discussed above can be prevented by enabling App Protect which has around 1000+ signatures related to variety of Injection attacks. The attack request is recorded in the security log, indicating that the attack type is SQL-Injection. The request was blocked, and the signatures responsible for detecting the attack are also visible. A04:2021-Insecure Design Problem statement: The growing reliance on web applications exposes them to security risks, with insecure design being a key concern. For example, a retail chain’s e-commerce website lacks protection against bots used by scalpers to buy high-end video cards in bulk for resale. This causes negative publicity and frustrates genuine customers. Implementing anti-bot measures and domain logic rules can help block fraudulent transactions, with F5 NGINX App Protect providing effective protection against such attacks. Solution: Secure design is an ongoing process that continuously evaluates threats, ensures robust code, and integrates threat modeling into development. It involves constant validation, accurate flow analysis, and thorough documentation. By using F5 NGINX App Protect WAF, which includes bot defense, web applications can effectively prevent bot-driven attacks, identifying and blocking them early to protect against fraudulent transactions. The attack request is recorded in the security log, indicating that the attack type is Non-browser Client. The request was blocked, and the violation stating “VIOL_BOT_CLIENT”. Note: The security log shown in the image below is the default log configuration Request captured in NGINX App Protect security log A05:2021-Security Misconfiguration Problem statement: Security misconfiguration occurs when security settings are improperly configured, exposing web applications to various threats. One such vulnerability is Cross-Site Request Forgery (CSRF), where attackers trick authenticated users into making unauthorized requests. Without proper protection mechanisms, attackers can exploit this misconfiguration to perform malicious actions on behalf of the user. The demonstration using WebGoat below shows how an improperly configured application becomes vulnerable to CSRF, allowing attackers to carry out unauthorized actions. Execute the above malicious script by copying the file path and pasting in new tab of the WebGoat authenticated browser. The script will automatically load the malicious code and redirects to the vulnerable page. Solution: F5 NGINX App Protect WAF provides a comprehensive support against CSRF attack. Users can configure the CSRF policy based on their requirements by following the configuration settings here. In this demonstration, default CSRF policy is used to block the attack. Default CSRF policy used to block CSRF attacks The security log captures the attack request, identifying the type of attack which is CSRF. The request was successfully blocked, and the violations saying “CSRF attack detected” is also visible. A06:2021-Vulnerable and Outdated Components Problem statement: Vulnerable and Outdated Components risk arises when a web application uses third-party libraries or software with known security vulnerabilities that are not updated. Additionally, vulnerable pages like “phpmyadmin.php” that expose sensitive details—such as application versions, user credentials, and database information—further increase the risk. Attackers can use this information to exploit known vulnerabilities or gain unauthorized access, leading to potential data breaches or system compromise. Solution: The vulnerability discussed above can be mitigated using F5 NGINX App Protect WAF Attack Signatures, which includes specific "Signature ID" for various vulnerabilities. These Signature IDs can be incorporated into the policy file to block attacks. For instance, Signature ID 200000014 can be used to block access to phpmyadmin.php page. Attack signatures can be found here. The attack request is recorded in the security log, indicating that the attack type is Predictable Resource Location. The request was blocked, and the signatures responsible for detecting the “/phpmyadmin/ page” attack are also visible. A07:2021-Identification and Authentication Failures Problem statement: Effective authentication and secure session management are crucial in preventing authentication-related vulnerabilities in daily tasks. Applications with weak authentication mechanisms are vulnerable to automated attacks, such as credential stuffing, where attackers use wordlists to perform spray attacks, allowing attackers to determine whether specific credentials are valid, thus increasing the risk of brute-force and other automated attacks. Brute force attacks are attempts to break in to secured areas of a web application by trying exhaustive, systematic, username/password combinations to discover legitimate authentication credentials. Solution: To prevent brute force attacks, F5 NGINX App Protect WAF monitors IP addresses, usernames, and the number of failed login attempts beyond a maximum threshold. When brute force patterns are detected, the F5 NGINX App Protect WAF policy either trigger an alarm or block the attack if the failed login attempts reached a maximum threshold for a specific username or coming from a specific IP address. Note – Brute force attack prevention is supported starting from versions v4.13 and v5.5 The security log captures the attack request, identifying the type of attack as Brute Force Attack. The request was successfully blocked, and the “VIOL_BRUTE_FORCE” violations is also visible. A08:2021-Software and Data Integrity Failures Problem statement: Added as a new entry in the OWASP Top 10 2021, software and data integrity failures, particularly in the context of insecure deserialization, occur when an application deserializes untrusted data without proper validation or security checks. This vulnerability allows attackers to modify or inject malicious data into the deserialization process, potentially leading to remote code execution, privilege escalation, or data manipulation. In this demonstration, a serialized PHP command O:18:"PHPObjectInjection":1:{s:6:"inject";s:18:"system ('ps -ef');";} is passed in the URL to retrieve the running processes. Solution: F5 NGINX App Protect WAF can prevent Serialization Injection PHP attacks by leveraging its default policy bundle, which includes an extensive set of signatures specifically designed to address deserialization vulnerabilities. The security log captures the attack request, identifying the type of attack. The request was successfully blocked, and the signatures used to detect the 'PHP Short Object Serialization Injection' attack are also visible. A09:2021-Security Logging and Monitoring Failures Problem statement: Security logging and monitoring failures occur when critical application activities such as logins, transactions, and user actions are not adequately logged or monitored. This lack of visibility makes it difficult to detect and respond to security breaches, attack attempts, or suspicious user behavior. Without proper logging and monitoring, attackers can exploit vulnerabilities without detection, potentially leading to data loss, revenue impact, or reputational damage. Insufficient logging also hinders the ability to escalate and mitigate security incidents effectively, making the application more vulnerable to exploitation. Solution: F5 NGINX App Protect WAF provides different options to track logging details of applications for end-to-end visibility of every request both from a security and performance perspective. Users can change configurations as per their requirements and can also configure different logging mechanisms with different levels. Check the links below for more details on logging: Version 4 and earlier Version 5 A10:2021-Server-Side Request Forgery Problem statement: Server-Side Request Forgery (SSRF) occurs when a web application fetches a remote resource without properly validating the user-supplied URL. This vulnerability allows attackers to manipulate the application into sending malicious requests to internal systems or external resources, bypassing security measures like firewalls or VPNs. SSRF attacks can expose sensitive internal data or resources that are not meant to be publicly accessible, making them a significant security risk, especially with modern cloud architectures. In this demonstration, patient health records, which should be accessible only within the network, can be retrieved publicly through SSRF. Solution: Server-Side Request Forgery (SSRF) attacks can be prevented by utilizing the default policy bundle of F5 NGINX App Protect WAF, which includes a comprehensive set of signatures designed to detect and mitigate SSRF vulnerabilities. By enabling App Protect, you gain strong defense against SSRF attacks as well as other prevalent security threats, thanks to the default policy's pre-configured signatures that cover a wide range of attack vectors. The security log captures the attack request, identifying the type of attack. The request was successfully blocked, and the signatures used to detect the 'SSRF' attack are also visible. Request captured in NGINX App Protect security log Conclusion: Protecting applications from attacks is simple with F5 NGINX App Protect WAF, a high-performance, lightweight, and platform-agnostic solution that supports diverse deployment options, from edge load balancers to Kubernetes clusters. By leveraging its advanced security controls, organizations can effectively mitigate the OWASP Web Application Security Top 10 risks, ensuring robust protection across distributed architectures and hybrid environments. Ultimately, F5 NGINX App Protect helps strengthen overall security, providing comprehensive defense for modern applications. References: F5 NGINX App Protect WAF OWASP Top 10 - 2021 F5 NGINX App Protect WAF Documentation F5 Attack SignaturesStreamlining App Development: Unlocking Self-Service Workflows with F5 NGINX Instance Manager
The article discusses how the F5 NGINX Instance Manager simplifies managing multiple NGINX instances using standardized templates. These templates, categorized as base and augment types, enhance configuration consistency and reduce deployment risks.A Closer Look at mTLS and the Default Server in F5 NGINX
When you connect to an HTTPS site, your browser (or other client) typically sends a Server Name Indication (SNI)—the hostname it wants to reach—during the TLS handshake. This lets F5 NGINX figure out which cryptographic settings to use for that specific hostname. In other words, SNI influences: Which x509 certificate is sent to the client Which cryptographic algorithms are offered Which session ticket key is used for encrypting and decrypting session tickets Which session cache is active, if you’re using caching Which Certificate Authority (CA) is checked when you require mutual TLS (mTLS) If the client doesn’t provide SNI or if the hostname doesn’t match any of your configured server_name directives, F5 NGINX defaults to a “fallback” setup—usually called the default server. That means: The default server’s certificate, ciphers, ticket key, and session cache get used automatically. If you haven’t explicitly marked any server block as default_server, F5 NGINX chooses the first block for that listen socket in your configuration as the fallback. Here’s the crucial detail: once the TLS handshake finishes and a certificate has been selected (for example, from the default server), F5 NGINX will still examine the HTTP Host header for request routing. If it specifies a different domain matching another server block, the request is forwarded there at the HTTP layer. From the client’s perspective, however, the originally cryptographic settings remain in effect, because the TLS negotiation is already complete. Single Server Block In the simplest configuration, only one server block listens for TLS connections on a given IP address and port: server { listen 443 ssl; server_name example.com; ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; ssl_client_certificate /etc/ssl/certs/ca.crt; ssl_verify_client on; # Additional configuration, such as locations and logging } In this example: If the client provides SNI matching example.com, F5 NGINX presents /etc/ssl/certs/example.com.crt and verifies the client certificate against /etc/ssl/certs/ca.crt. If the client does not provide SNI, this same server block still handles the request because there are no other blocks to consider; the same certificate and CA (ca.crt) apply. Once authenticated, the client proceeds under the cryptographic settings of this single server block. With only one server block present, there is no additional routing or fallback scenario to manage. Multiple Server Blocks on the Same IP/Port When multiple server blocks listen on the same IP address and port, F5 NGINX uses SNI to determine which server block should handle the request. If no matching SNI is found, requests fall back to the server marked with default_server. As previously stated, if the default_server is not explicitly defined, F5 NGINX will use the first server block in the configuration as the fallback. # example.com and the default server (first in config) server { listen 443 ssl; server_name example.com; ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; ssl_client_certificate /etc/ssl/certs/ca_A.crt; ssl_verify_client on; # Additional configuration, such as locations and logging } # www.example.com server { listen 443 ssl; server_name www.example.com; ssl_certificate /etc/ssl/certs/www.example.com.crt; ssl_certificate_key /etc/ssl/private/www.example.com.key; ssl_client_certificate /etc/ssl/certs/ca_B.crt; ssl_verify_client on; # Additional configuration, such as locations and logging } In this example: If the client provides SNI matching example.com, the first server block’s certificate (example.com.crt) and CA settings (ca_A.crt) are used. If the client provides SNI matching www.example.com, the second server block’s certificate (www.example.com.crt) and CA settings (ca_B.crt) are used. If the client does not provide SNI (or provides an unmatched server name), the first server block (example.com) acts as the default. Its certificate (example.com.crt) and CA (ca_A.crt) apply for the TLS handshake. After TLS is established under the default server, if the HTTP Host header is www.example.com, F5 NGINX routes the request to the second server block for application-level processing. However, the TLS session—including which certificate and CA were used—remains with the default server’s settings. This means the second server’s client certificate configuration (ca_B.crt) is not involved in re-validating the client, since no new TLS handshake occurs. Recommendations The fallback behavior mentioned above might not fit all use cases. If it poses a risk or doesn’t align with your security needs, consider reconfiguring F5 NGINX (e.g., setting up a stub default server or applying tighter mTLS rules) to restrict or eliminate this fallback path. Defining a Default Server (or Stub Default Server) It is highly recommended to define a default server in F5 NGINX. If you do not want to allow fallback for clients without valid SNI, you can set up a stub default server (configuration example below). A stub default server, as shown below, ensures that unmatched SNI (or no SNI) connections are rejected at the handshake level, preventing unintended fallback to a less restrictive configuration. Perhaps most importantly, it does not contain any client authentication configuration directives, forcing client authentication to occur in the most specific server blocks. In the example below I have added `ssl_verify_client off;` for illustrative purposes, however the setting of `off` is the default. Note: ssl_reject_handshake appeared in nginx version 1.19.4. For versions prior to that, one can define a server that simply returns the special 444 HTTP response code. Authorization Checks in All Server Blocks Even with a stub default server, all server blocks should implement authorization checks if they serve sensitive content. Because requests may be forwarded from the default server to a non-default server after decryption, every server block must enforce its own mTLS policies and check variables such as $ssl_client_s_dn or $ssl_client_i_dn (if you rely on client certificates) to ensure consistent and robust security across your deployment. # explicit default server server { listen 443 ssl default_server; ssl_reject_handshake on; ssl_verify_client off; ssl_protocols TLSv1.2 TLSv1.3; } # example.com server { listen 443 ssl; server_name example.com; ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; ssl_client_certificate /etc/ssl/certs/ca_A.crt; ssl_verify_client on; # Check subject DN if ($ssl_client_s_dn !~ "CN=TrustedClient_A,O=MyOrg") { return 403; } # Check issuer DN (this may not be necessary for all deployments) if ($ssl_client_i_dn !~ "CN=TrustedCA_A,O=MyOrg") { return 403; } # Additional configuration, such as locations and logging } # This server block handles requests for www.example.com server { listen 443 ssl; server_name www.example.com; ssl_certificate /etc/ssl/certs/www.example.com.crt; ssl_certificate_key /etc/ssl/private/www.example.com.key; ssl_client_certificate /etc/ssl/certs/ca_B.crt; ssl_verify_client on; # Check subject DN if ($ssl_client_s_dn !~ "CN=TrustedClient_B,O=MyOrg") { return 403; } # Check issuer DN (this may not be necessary for all deployments) if ($ssl_client_i_dn !~ "CN=TrustedCA_B,O=MyOrg") { return 403; } # Additional configuration, such as locations and logging } Conclusion In summary, working with multiple server blocks, SNI, and mTLS can make F5 NGINX setups more complex. Knowing precisely which server block handles the TLS handshake—particularly when there is no SNI or an unmatched name—helps maintain the desired security posture. Careful attention to these details keeps certificates and policies consistent for all client connections.What is Message Queue Telemetry Transport (MQTT)? How to secure MQTT?
MQTT is a messaging protocol broadly used in IoT and connected services, very lightweight and reliable even over poor quality networks. It is designed lightweight so it can work on constrained devices but, even in its latest version MQTTv5, the attack surface is very large.Installing and Locking a Specific Version of F5 NGINX Plus
A guide for installing and locking a specific version of NGINX Plus to ensure stability, meet internal policies, and prepare for controlled upgrades. Introduction The most common way to install F5 NGINX Plus is by using the package manager tool native to your Linux host (e.g., yum, apt-get, etc.). By default, the package manager installs the latest available version of NGINX Plus. However, there may be scenarios where you need to install an earlier version. To help you modify your automation scripts, we’ve provided example commands for selecting a specific version. Common Scenarios for Installing an Earlier Version of NGINX Plus Your internal policy requires sticking to internally tested versions before deploying the latest release. You prefer to maintain consistency by using the same version across your entire fleet for simplicity. You’d like to verify and meet additional requirements introduced in a newer release (e.g., NGINX Plus Release 33) before upgrading. Commands for Installing and Holding a Specific Version of NGINX Plus Use the following commands based on your Linux distribution to install and lock a prior version of NGINX Plus: Ubuntu 20.04, 22.04, 24.04 LTS sudo apt-get update sudo apt-get install -y nginx-plus=<VERSION> sudo apt-mark hold nginx-plus Debian 11, 12 sudo apt-get update sudo apt-get install -y nginx-plus=<VERSION> sudo apt-mark hold nginx-plus AlmaLinux 8, 9 / Rocky Linux 8, 9 / Oracle Linux 8.1+, 9 / RHEL 8.1+, 9 sudo yum install -y nginx-plus-<VERSION> sudo yum versionlock nginx-plus Amazon Linux 2 LTS, 2023 sudo yum install -y nginx-plus-<VERSION> sudo yum versionlock nginx-plus SUSE Linux Enterprise Server 12, 15 SP5+ sudo zypper install nginx-plus=<VERSION> sudo zypper addlock nginx-plus Alpine Linux 3.17, 3.18, 3.19, 3.20 apk add nginx-plus=<VERSION> echo "nginx-plus hold" | sudo tee -a /etc/apk/world FreeBSD 13, 14 pkg install nginx-plus-<VERSION> pkg lock nginx-plus Notes Replace <VERSION> with the desired version (e.g., 32-2*). After installation, verify the installed version with the command: nginx -v. Holding or locking the package ensures it won’t be inadvertently upgraded during routine updates. Conclusion Installing and locking a specific version of NGINX Plus ensures stability, compliance with internal policies, and proper validation of new features before deployment. By following the provided commands tailored to your Linux distribution, you can confidently maintain control over your infrastructure while minimizing the risk of unintended upgrades. Regularly verifying the installed version and holding updates will help ensure consistency and reliability across your environments.F5 NGINX Plus R33 Licensing and Usage Reporting
Beginning with F5 NGINX Plus version R33, all customers are required to deploy a JSON Web Token (JWT) license for each commercial instance of NGINX Plus. Each instance is responsible for validating its own license status. Furthermore, NGINX Plus will report usage either to the F5 NGINX licensing endpoint or to the F5 NGINX Instance Manager for customers who are connected. For those customers who are disconnected or operate in an air-gapped environment, usage can be reported directly to the F5 NGINX Instance Manager. To learn more about the latest features of NGINX R33, please check out the recent blog post. Install or Upgrade NGINX Plus R33 To successfully upgrade to NGINX Plus R33 or perform a fresh installation, begin by downloading the JWT license from your F5 account. Once you have the license, place it in the F5 NGINX directory before proceeding with the upgrade. For a fresh installation, after completing the installation, also place the JWT license in the NGINX directory. For further details, please refer to the provided instructions. This video provides a step-by-step guide on installing or upgrading to NGINX Plus R33. Report Usage to F5 in Connected Environment To effectively report usage data to F5 within a connected environment using NGINX Instance Manager, it's important to ensure that port 443 is open. The default configuration directs the usage endpoint to send reports directly to the F5 licensing endpoint at product.connect.nginx.com. By default, usage reporting is enabled, and it's crucial to successfully send at least one report on installation for NGINX to process traffic. However, you can postpone the initial reporting requirement by turning off the directive in your NGINX configuration. This allows NGINX Plus to handle traffic without immediate reporting during a designated grace period. To configure usage reporting to F5 using NGINX Instance Manager, update the usage endpoint to reflect the fully qualified domain name (FQDN) of the NGINX Instance Manager. For further details, please refer to the provided instructions. This video shows how to report usage in the connected environment using NGINX Instance Manager. Report Usage to F5 in Disconnected Environment using NGINX Instance Manager In a disconnected environment without an internet connection, you need to take certain steps before submitting usage data to F5. First, in NGINX Plus R33, update the `usage report` directive within the management block of your NGINX configuration to point to your NGINX Instance Manager host. Ensure that your NGINX R33 instances can access the NGINX Instance Manager by setting up the necessary DNS entries. Next, in the NMS configuration in NGINX Instance Manager, modify the ‘mode of operation’ to disconnected, save the file, and restart NGINX Instance Manager. There are multiple methods available for adding a license and submitting the initial usage report in this disconnected environment. You can use a Bash script, REST API, or the web interface. For detailed instructions on each method, please refer to the documentation. This video shows how to report usage in disconnected environments using NGINX Instance Manager. Conclusion The transition to NGINX Plus R33 introduces important enhancements in licensing and usage reporting that can greatly improve your management of NGINX instances. With the implementation of JSON Web Tokens (JWT), you can validate your subscription and report telemetry data more effectively. To ensure compliance and optimize performance, it’s crucial to understand the best practices for usage reporting, regardless of whether you are operating in a connected or disconnected environment. Get started today with a 30-day trial, and contact us if you have any questions. Resources NGINX support documentation Blog announcement providing a comprehensive summary of the new features in this release.
