Let's Get Critical, Critical
MegaZoneis back again for a roundup of the security news that caught my eye for the week of November 10th - 16th, 2024. This time, I want to get Critical. Yes, let's get into the Critical - issues, of course. We're going to look at some very recent Critical issues making the rounds, as well as issues which made the charts in 2023 - including an old friend which keeps on giving. And I'll end with a critical issue for all of us in the cybersecurity field, one I feel strongly about. Atomic Batteries to Power! Turbines to Speed!Cyber Security Attack Mitigations with BIG-IP features
ArvinF is back to share mitigation options for Cyber Security Attacks with BIG-IP features! This article aim to bring these attack mitigations options much more visible and available. Cyber Security Attacks There are many types of Cyber Security Attacks. I will limit to the types that BIG-IP mostly encounter. Network Attacks Network attacks are aimed at compromising, disrupting, or gaining unauthorized access to an organization’s internal or external network, usually targeting communication protocols, devices, or services within the network. Web Application Attacks Web application attacks target weaknesses in web-based applications to gain unauthorized access to data, manipulate functionality, or exploit users. Web Application and Network Attacks are common and these can affect the Web application and network traffic processed thru F5 Virtual Servers and in some cases, affect the availability of the BIG-IP device itself. Malware Attacks Malware (malicious software) includes viruses, worms, Trojans, ransomware, and spyware designed to damage or gain control over a computer system. BIG-IP Cyber Security Attacks Mitigations But First, Finding "Help" I have always found it helpful to review the Help Tab of the feature and configuration. While logged in on the BIG-IP Configuration utility for the specific BIG-IP Application Security Manager (BIG-IP ASM/Adv WAF) or BIG-IP Advanced Firewall Manager (BIG-IP AFM) menu, the "Help" tab contains details of the relevant configurations. If you hit Launch, it opens on a new window. You can also click on Expand All to view each options documentation. On to the mitigation options.. Bot Defense Profile We have here the description of the Bot Defense Profile Templates where it provides details of each template - Relaxed, Balanced and Strict - on the Verification and Mitigation it will provide. Take note of the Relaxed template Browser verification as it uses "Challenge-Free Verification". This means clients that do not support Javascript such as mobile applications will not be prevented due to verification and is less intrusive. From K42323285: Overview of the unified Bot Defense profile https://my.f5.com/manage/s/article/K42323285 Challenge-Free Verification—The default value when Profile Template is set to Relaxed. The system performs header-based verification but does not perform JavaScript verification. The Balanced and Strict offers more stringent client verification. For the mitigation from Bot Defense to take effect, it should be in blocking mode. Relaxed Mode Defines a permissive security policy that performs basic non-intrusive verification of Browsers, strong verification of Mobile Apps using Anti-Bot Mobile Security SDK, blocks Malicious Bots and allows all other clients. Malicious Bots are detected mostly by using bot signatures. The mode provides basic protection level with very low risk of false positives. Balanced Mode Defines a moderate security policy that performs advanced verification of Browsers, strong verification of Mobile Apps using Anti-Bot Mobile Security SDK, blocks Malicious Bots, initiates CAPTCHA challenge for Suspicious Browsers, limits the total request rate produced by Unknown bots and allows Trusted and Untrusted Bots. Malicious Bots and Suspicious Browsers are identified by using both anomaly detection algorithms and bot signatures. This mode provides an advanced protection level with reduced latency impact because Browser verification is performed by injecting challenge in HTTP response. Strict Mode Defines a strict security policy that performs advanced verification of Browsers, strong verification of Mobile Apps using Anti-Bot Mobile Security SDK, and blocks all bots except Trusted Bots. This mode provides the most advanced and strict protection level using all capabilities of Bot Defense. Browser clients are not allowed to access unless they pass proactive verification. Mobile clients security access requires the use of Anti-Bot Mobile SDK. Here is a sample log for Bot Defense it is detecting a client that is classified as a "Suspicious Browser". The Bot Defense Profile that detected this bot request was configured with the "Relaxed" profile template. Here are sample Bot Traffic detected and actioned by a Bot Defense profile. Notice the Alarm and Block events. A detected "Suspicious Browser" is not blocked but generates an Alarm. A "malicious bot" is blocked DoS Protection Profile For the DoS Protection profiles, detection and mitigation can be configured thru TPS , Behavioral and Stress-based. The threshold for each configuration can be configured with Manual or Automatic thresholds. Manually configured TPS based detection looks at defined conditions and thresholds by Source IP, Device ID, Geolocation, URL and Site Wide and when exceeded, configured mitigation will take effect. The DoS Protection profile should be in Blocking mode for the mitigation to take effect. When using automatic threshold configuration in BIG-IP ASM/Adv WAF DoS Protection profile, the system sets the values using a wide range to begin with, then calculates the values using 7 days of historical data and sets threshold values to the highest levels during normal activity (to minimize false positives). Reference: K000138529: Understanding Automatic Threshold in BIG-IP ASM/Adv WAF DoS Protection profile The by Device ID detection option uses JavaScript to detect clients and requires a Bot Defense profile with Device ID mode to be configured. Here is the description of conditions from the TPS based detection configuration ================== Consider an IP as an attacking entity if either of the following conditions occur: Relative Threshold: TPS increased by: <traffic percentage> and reached at least <TPS> transactions per second OR Absolute Threshold: TPS reached: <TPS> transactions per second ================== Here is the description of conditions when TPS based detection is configured with Automatic Threshold ============== Consider an IP as an attacking entity if TPS reached an auto-calculated threshold in range <minimum TPS> - <upper limit TPS> transactions per second ============== For environments that have a mix of web and mobile application clients, only the Request Blocking option does not use Javascript to mitigate attacking clients. The Behavioral and Stress-based detection threshold can also be configured as Manual or Automatic and have the same configuration options TPS based detection. The difference is Server Stress is a requirement in this detection mode. Ensure that the DoS protection profile is in blocking mode. From the Online Help ============ Behavioral & Stress-based Detection In this area you can configure the system to prevent DoS attacks based on the server’s health condition. An attack is detected if the system finds the server to be under stress and either of the TPS thresholds are crossed. =========== Similar mitigation options are also available. Another section of Behavioral & Stress-based Detection is the Behavioral Detection and Mitigation where Bad Actor detection and mitigation can be configured From the Online Help ========= Bad actors behavior detection: Enables traffic behavior, server's capacity learning, and anomaly detection. Request signatures detection: Enables signatures detection. Use TLS fingerprints identification: Allows the system to distinguish between bad and good actors behind the same IP (NAT). When disabled (default), any attack behind the NAT treats all users behind the NAT as attackers. ========= Do take note of Request signatures detection and Use TLS fingerprints identification as these options are useful in identifying attacking clients behind a NAT device by way of TLS fingerprint and clients with specific HTTP signatures. Here is the Bad actors behavior detection mitigation descriptions. Review the protection levels and use what is appropriate as per your needs. Mitigation: No mitigation:Learns and monitors traffic behavior, but no action is taken. Conservative protection:If «Bad actors detection» enabled, slows down and rate limits requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. If «Request signatures detection» enabled, blocks requests that match the attack signatures. Standard protection:If «Bad actors detection» enabled, slows down requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. Rate limits requests from anomalous IP addresses and, if necessary, rate limits all requests based on the servers health. Limits the number of concurrent connections from anomalous IP addresses and, if necessary, limits the number of all concurrent connections based on the server's health. If «Request signatures detection» enabled, blocks requests that match the attack signatures. Aggressive protection:If «Bad actors detection» enabled, slows down requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. Rate limits requests from anomalous IP addresses and, if necessary, rate limits all requests based on the servers health. Limits the number of concurrent connections from anomalous IP addresses and, if necessary, limits the number of all concurrent connections based on the server's health. Proactively performs all protection actions (even before an attack). Increases the impact of the protection techniques. If «Request signatures detection» enabled, blocks requests that match the attack signatures. Increases the impact of blocked requests. Regarding Server Stress There are a couple of locations where Server Stress can be observed. A spike in Server Stress will trigger Behavioral and Stress-based DoS detection and mitigation if configured. Protected Objects List This is under Security ›› DoS Protection : Protected Objects : Protected Objects List This menu is available when you have BIG-IP AFM provisioned in this sample, notice the Server Stress is at 100/100 - this means the backend server is Stressed and the latency of Server response is High. The protected object's attack status is "red" signaling an attack is ongoing and being mitigated. On this sample, the detected attack is ongoing and the server stress value has gone down to 55/100. The request rate also shows the connections per second and has gone down. Behavioral DoS Dashboard Under the Statistics menu, click on Dashboard Select Behavioral DoS in the Dashboard options Review Server Stress Here are sample DoS Application Events generated thru a DoS protection profile TPS Based detection and mitigation Behavioral detection and mitigation It provides insight which DoS "Threshold condition" was exceeded and what "Mitigation" was applied to the detected "Attack (Attack ID)" also noting the start and end of the attack. Inspecting these events will help in figuring out a threshold you may apply. DoS Dashboard under Security Reporting When looking for details of the attack, the DoS Dashboard under Security Reporting provides insight on the detected attack and related entities and statistics. In this sample, the detected attack was triggered thru App Behavioral and mitigated with Behavioral mitigation In this sample, notice the "transaction outcomes" shows "Blocked Bad Actor" which means the transactions were blocked by Bad Actor detection and mitigation configuration in the DoS protection profile. IP reputation , IP Intelligence license - must have! During DDoS attacks, it is very likely that the some of the source IP addresses will have bad IP reputation. Having the IP Intelligence license available in the BIG-IP will provide mitigation for matched IP addresses. IP Intelligence can be used in BIG-IP LTM (iRules and LTM Policy), AFM (IP Intelligence Policy) and ASM/Adv WAF (Security Policy) configurations. Refer to the following links on sample iRule configurations. https://clouddocs.f5.com/api/irules/IP__reputation.html https://clouddocs.f5.com/api/irules/IP__intelligence.html Note that the IP intelligence feature requires an add-on license.Contact your F5 or Partner salesperson for details on ordering the license. Cyber Security Attack Scenarios and Recommendations As introduced earlier, here are Cyber Security Attack Scenarios that BIG-IP deployments encounter and corresponding mitigation options and configuration recommendations. These sample scenarios will be helpful in finding initial mitigation options using BIG-IP features should it match your deployment configuration. Scenario: DDoS attack on a F5 Virtual Server fronting a web application and the BIG-IP have ASM/Adv WAF license. There are no DoS protection and Bot Defense profile configured on the Virtual Server. Recommendations: For the DoS Protection profile, configure TPS and Behavioral and Stress based Detection. Set Detection Thresholds and mitigations for both options as per your needs. You can monitor the traffic pattern on the Virtual Server you are protecting. Consider the clients that access the web application. If the clients are web browsers and mobile application users, use non Javascript (JS) based detection and mitigations. This will allow mobile application clients that do not support Javascript challenges to access the protected web application and ensure they are not blocked by Javascript challenges or mitigations. Another detection method is thru Bad Actor detection configuration under Behavioral and Stress Based Detection menu. This feature slows down and rate limits requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. Automatic Threshold can also be configured for TPS based detection. For more information on HTTP enabled DoS Protection configured with Automatic Threshold, refer to K000138529: Understanding Automatic Threshold in BIG-IP ASM/Adv WAF DoS Protection profile For the Bot Defense profile, configure the Relaxed Profile template. This does not use Javascript challenges for detecting end clients and will allow mobile application clients that do not support Javascript to access the protected web application. Configure a logging profile that logs remotely to trusted logging server for DoS protection and Bot Defense events. Scenario: DDoS attack on a F5 Forwarding IP or Performance Layer 4 Virtual Server processing network traffic. Recommendations: Ensure DoS mitigations are available to protect the network traffic. BIG-IP AFM have DoS Attack types for Network Based DoS and can be set to Mitigate to detect and mitigate/drop excess packets for the matched attack type. These DoS Attack types can be configured with Fully Manual or Fully Automatic threshold. You should set detection and mitigation thresholds as per your needs. It is important to review traffic statistics and pattern on the Virtual Server you are protecting. AFM threshold values are in EPS - Events Per Second, synonymous to Packets Per Second and the observed traffic pattern can be the basis of the manually configured thresholds. Another method of defining the threshold is thru "Threshold Sensitivity" where the BIG-IP system CPU usage and traffic pattern is the basis. When AFM DoS attack types are configured with Fully Automatic, it uses the "Threshold Sensitivity" configuration. For BIG-IP Advanced Firewall Manager (AFM) systems protecting networks against Distributed Denial of Service (DDoS) attacks, DoS Auto Threshold sensitivity can be configured for system-wide thru Device Protection and per DoS Protection Profile. A setting of High will be more sensitive to changes in BIG-IP System CPU usage and traffic. A setting of Medium is the default configuration. A setting of Low will be less sensitive to changes in BIG-IP System CPU usage and traffic. From the BIG-IP Configuration utility, navigate to: For System Wide: Security ›› DoS Protection : Device Protection per DoS Protection Profile: Security ›› DoS Protection : Protection Profiles .. select the specific profile Reference: K000141430: Configuring BIG-IP AFM DoS Protection Threshold Sensitivity https://my.f5.com/manage/s/article/K000141430 Scenario: DNS DDoS attack on F5 DNS listener Virtual Server Recommendations: BIG-IP AFM have DNS Attack types to detect and mitigate DNS DDoS attacks. If your BIG-IP does not have BIG-IP AFM licensed, it would be beneficial for the DNS service processed thru the F5 DNS listener VS to have mitigation options available from the DNS Attack types in the AFM DoS device or DNS enabled protection profile. Configure thresholds as per your needs. Here is a sample configuration from a lab device where DNS A Query Attack type in Device Protection is configured in Mitigate state and Fully Manual detection and mitigation thresholds. Bad Actor Detection can also be configured with thresholds. It is also possible to configure it for Fully Automatic threshold and will be dependent on the Threshold Sensitivity configuration. Scenario: DDoS attack on F5 Virtual Server and attacking IP addresses needs to be blocked Recommendations: BIG-IP AFM has Network Firewall Policy and rules where it can be configured to match a source address list and drop its traffic. This can also be done thru iRules, however, AFM firewall rule configuration is a native feature and is built for such operations. The F5 SIRT created a playbook for HTTP brute force mitigation and the LTM mitigation options includes such configurations should you decide to use iRules and BIG-IP LTM features. HTTP Brute Force Mitigation Playbook: BIG-IP LTM Mitigation Options for HTTP Brute Force Attacks - Chapter 3 HTTP Brute Force Mitigation Playbook: BIG-IP LTM Mitigation Options for HTTP Brute Force Attacks - Chapter 3 | DevCentral F5 also have K30534815: Attack mitigation matrix using F5 security products and services which lists existing F5 Support articles for attack mitigation. https://my.f5.com/manage/s/article/K30534815 During DDoS attacks, it is very likely that the some of the source IP addresses will have bad IP reputation, it will be beneficial to have IP Intelligence license available and use it in BIG-IP LTM (iRules and LTM Policy), AFM (IP Intelligence Policy) and ASM/Adv WAF (Security Policy) configurations. Refer to the following links on sample iRule configurations. https://clouddocs.f5.com/api/irules/IP__reputation.html https://clouddocs.f5.com/api/irules/IP__intelligence.html Note that the IP intelligence feature requires an add-on license.Contact your F5 or Partner salesperson for details on ordering the license. Scenario: BIG-IP device is suspected to be compromised. Recommendations: BIG-IP can be affected by malware and it finds it's way to it by exposing the BIG-IP management and self (self-IP) IP addresses and configured with insecure or easy to guess BIG-IP user password. BIG-IP product had previous Critical CVEs where authentication was not needed to exploit the vulnerability. F5 has the article K11438344: Considerations and guidance when you suspect a security compromise on a BIG-IP system to provide guidance on handling suspected compromised BIG-IP devices. https://my.f5.com/manage/s/article/K11438344 To minimize the attack surface of a BIG-IP device against CVEs and unauthorized access, ensure that only trusted authenticated users and networks have access to the BIG-IP management and self (self-IP) IP addresses and the BIG-IP device is running the latest BIG-IP software version. Do review the "Major Release and Long-Term Stability Release versions supported with active software development" of K5903: BIG-IP software support policy as it notes BIG-IP 15.1.x version reaches "End of Technical Support" this December 31, 2024. Note: For BIG-IP Next (BIG-IP 20.x and later), refer toBIG-IP Next software support policy. Major Release and Long-Term Stability Release versions First customer ship End of Software Development End of Technical Support Latest maintenance release 17.1.x March 14, 2023 March 31, 2027 March 31, 2027 17.1.1 16.1.x July 7, 2021 July 31, 2025 July 31, 2025 16.1.5 15.1.x December 11, 2019 December 31, 2024 December 31, 2024 15.1.10 K5903: BIG-IP software support policy https://my.f5.com/manage/s/article/K5903 F5 Distributed Cloud "F5 Distributed Cloud Services are SaaS-based security, networking, and application management services that enable customers to deploy, secure, and operate their applications in a cloud-native environment wherever needed–data center, multi-cloud, or the network or enterprise edge." https://www.f5.com/products/distributed-cloud-services F5 Distributed Cloud have many mitigation options for DDoS attacks. Volumetric DDoS can be handled by F5 Distributed Cloud DDoS Mitigation Service. F5 Distributed Cloud Bot Defense mitigates complex bot attacks. It provides integration option with your mobile application so it can be properly classified and detected as a trusted client. see Making Mobile SDK Integration Ridiculously Easy with F5 XC Mobile SDK Integrator https://www.f5.com/products/distributed-cloud-services/bot-defense https://www.f5.com/products/distributed-cloud-services/l3-and-l7-ddos-attack-mitigation Conclusion The Cyber Security Attack Scenarios and recommendations using BIG-IP features shared are not exhaustive. There are more complex environments and scenarios that BIG-IP deployments may have opportunity to mitigate network and application attack traffic and it is important that the appropriate BIG-IP licenses are available so the relevant modules can be provisioned and related features and configuration can be enabled. This will help your environment's network and application traffic to be resilient against DDoS attacks when BIG-IP is properly licensed, positioned and configured. I hope the sample configuration, logs and configuration help details have been useful and helpful as you consider the BIG-IP features mitigation options and improve your network, application and BIG-IP device security posture. Until next time! The F5 SIRT creates security-related content posted here in DevCentral, sharing the team’s security mindset and knowledge. Feel free to view the articles that are tagged with the following: F5 SIRT series-F5SIRT-this-week-in-security TWISF5 NGINX HTTP Request Header Rules: What’s Permitted and What’s Not
When managing web servers like F5 NGINX, it's crucial to understand the rules that govern HTTP headers—particularly which characters are allowed or disallowed in both header names and values. HTTP headers play a vital role in the communication between a client and server, carrying essential metadata such as content type, length, and caching policies. NGINX strictly enforces these rules to ensure compliance with HTTP/1.1, HTTP/2, and HTTP/3 protocols. Misconfigured headers or the use of improper characters can lead to a range of issues, including security vulnerabilities, degraded performance, or even rejected requests. One common security threat,HTTP Request Smuggling, exploits desynchronization between devices involved in handling the request, such as frontends, caching servers, load balancers, and web servers. These attacks rely on inconsistencies in how each device parses the request, enabling malicious actors to inject hidden or split requests. This article outlines the allowed and disallowed characters in HTTP request headers as enforced by NGINX, which I compiled throughcode review, test case review and manual testing for HTTP Smugglingon NGINX version "nginx/1.25.5 (nginx-plus-r32-p1)". If I missed something please let me know bycontacting the F5 SIRT. Allowed Characters Header Names Lowercase letters: (a-z) Uppercase letters: (A-Z) Allowed in HTTP/1.1 Disallowed in HTTP/2 and HTTP/3, which require lowercase. Digits: (0-9) Hyphen: (-) Underscore: (_)Allowed in all versions only ifunderscores_in_headers is enabled Colon: (:) Allowed only as a prefix inHTTP/2 and HTTP/3 pseudo headers. Header Values Printable ASCII characters: Characters from ! to ~, including digits, letters, punctuation, and symbols, are allowed. Space: (0x20) Allowed within the value. Horizontal Tab (HT): (0x09) Generally allowed within values but with exceptions in headers such as Content-Length and Host (details below). Disallowed Characters Header Names Control Characters: ASCII control characters (<= 0x20), including space and horizontal tab, are disallowed in header names. DEL (0x7f): The delete character is not allowed. Colon: (:) Disallowed in header names except forHTTP/2 and HTTP/3 pseudo headers. Uppercase Letters: (A-Z) Disallowed in HTTP/2 and HTTP/3 header names (must be lowercase). Special characters: Characters such as ()<>@,;:\"/[]?={} are implicitly disallowed as they don’t belong to any allowed category for header names. Header Values Null Character: (\0) Disallowed in header values. Line Feed (LF): (0x0A) Not allowed within the value and used only to terminate headers. Carriage Return (CR): (0x0D) Not allowed within the value, used for header termination. Control Characters (<= 0x20) with special conditions for Horizontal Tab (HT): Horizontal Tab (HT, 0x09): Disallowed in the Host header value in HTTP/1. Disallowed in the pseudo-header values in HTTP/2 and HTTP/3. Disallowed in the Content-Length header value in HTTP/1. Summary This list of allowed and disallowed characters provides an overview of how NGINX handles HTTP headers across different protocol versions. While HTTP/1.1 is somewhat lenient with uppercase letters and certain characters, HTTP/2 and HTTP/3 enforce stricter validation rules, particularly for header names. Understanding these restrictions ensures your server configuration remains compliant with protocol specifications and avoids potential issues with malformed headers.Money, Agents, Apologies, Switcheroos, Hype, and Hope
MegaZoneis your editor once again, for this belated issue of This Week In Security, covering the week of September 22-28, 2024. Apologies, it was a very hectic week and every time I thought I'd have a chance to sit down and write this, something came up. I planned to work on it Monday and the next thing I knew it was Friday afternoon and I still hadn't had a chance. Sometimes that's just how the week goes. Oddly, a few of the items Icovered last time are back in the news this week - or, perhaps, still in it. And here... we... go...
