security
17575 TopicsCan BIG-IP DNS recursion only my domain?
Hi We are using F5 DNS as DNS server and have many CNAME record. We want to query those CNAME record and then get IP as a result too. (Which solved by Enable "recursion yes; in named configuration) But we found problem that our F5 DNS perform recursion on EVERY domain client asking. (eg. f5.com, nginx.com., etc.) We want F5 DNS to answer query on only domain we handle (many domain in zonerunner and gslb) How can we do that? Is it possible to do that? because "recursion yes;" is config on named configuration. I think it's global configuration. and "allow-recursion {}" is only check for client IP address (it's not check on domain we handle) Thank you24Views0likes3CommentsAutomating ACMEv2 Certificate Management on BIG-IP
While we often associate and confuse Let's Encrypt with ACMEv2, the former is ultimately a consumer of the latter. The "Automated Certificate Management Environment" (ACME) protocol describes a system for automating the renewal of PKI certificates. The ACME protocol can be used with public services like Let's Encrypt, but also with internal certificate management services. In this article we explore the more generic support of ACME (version 2) on the F5 BIG-IP.2.3KViews7likes6CommentsINFORM: Entrust CA will be untrusted in Chrome after Oct 31, 2024
If you manage certs from Entrust in your environment, this will impact your Google Chrome users, so intermediate certs will likely need to be bundled to handle this in your clientssl profiles OR if you control all the clients you can assure that explicit trust in the clients is enabled for Entrust CAs. Google details on the situation96Views0likes1CommentF5 Distributed Cloud - Mitigation for Cross Tenant Origin Exposure (CTOE)
F5 Distributed Cloud (XC) offers a suite of powerful features designed to simplify the lives of administrators and engineers. A key aspect of this ease of use comes from shared objects, such as Regional Edge Proxies which utilize well-known public IP addresses. However, while this shared infrastructure enhances scalability and efficiency, it can also present risks if leveraged by attackers; and in this case, cross tenant origin exposure (CTOE). For instance: Customer(x) has tenant(x) in XC with a Load Balancer pointing to their public IP origin servers. These may be behind a perimeter firewall NAT (as diagrammed below) or be actual public IPs on the servers. Customers perimeter firewall is configured to deny all inbound traffic to public IP for site1.example.com Perimeter Firewall is configured to allow inbound traffic to public IP for site1.example.com for XC IP’s. (which is a well-known and public shared IP range) XC Proxy IP’s Reference Doc This setup is generally considered a minimum best practice because it restricts traffic to only those sources originating from XC. However, depending on the organization’s risk appetite, this level of security may be insufficient. The Risk Another account/tenant(y) within Distributed Cloud could create a load balancer and point to the public IP or DNS name of the origin pools for tenant(x). The attacker must know or learn the actual origin servers IP, or network segment to perform this attack. This discovery is fairly trivial and there are many approaches. In addition, what if the origin pool in tenant(x) is pointing to a DNS name that resolves to public IP’s? This is common with SaaS API gateways such as AWS and Azure to name a few and these gateways all use the same DNS name for the gateway respective to their cloud. Same DNS = Same IP’s = Easy to learn or guess Origin IP’s. For instance a common flow where a customer is using XC for WAF/WAAP and a 3rd party SAAS solution for an APIGW, may be Client–>XC(LB-WAAP)–>APIGW(pub-ip)–>API. In this default configuration, an attacker could learn the customers public NAT IP and add it to their Origin Pool. They can now instantiate attacks from their tenant(y) which will be sourced from the XC IP’s and allowed by the customer(x) perimeter firewall. Mitigation There are at least 4 ways to mitigate this risk. 1. L7 Header - If the origin servers (on-prem or SAAS) have something in front of them that is “L7 aware” or they themselves can be configured to do header validation, a custom HTTP request header could be injected into the flow by the load balancer in “tenant x”. Tenant y would not know or be able to see this header. Of course traffic not containing this header would still make it all the way to the L7 aware service before being dropped. While this would suffice for a L7 DoS or or other L7 type attack, it would not help with a L3/4 type attack which could still make it’s way through the infrastructure. 2. MTLS - A unique differentiator for F5 XC, is our ability to use server-side MTLS. If a customer has the capability on the Web Server/Service or something in front of it similar to the previous L7 header example, then we can add an additional layer of source validation by using mutual certificate authentication (mtls). Even a self-signed cert would add a lot of value here. No cert = no layer 7 access to the app or service. This does not prevent an L3/4 attack but will prevent unwanted application access. 3. Customer Edge (CE) proxies are deploy-able software that creates a private mesh back to our Application Delivery Network (ADN). These come with additional cost and need to be deployed at each location, thus creating a private mesh or overlay network that is unavailable outside of the tenant. in this scenario, the attacker traffic could potentially make it to the public IP of (or in front of) the CE and be dropped, thus protecting the application itself but still potentially allowing bad L3/4. 4. Private Link is a paid add-on to XC that enables connectivity between XC, clients, and resources. It offers many advantages, particularly when addressing regulatory and other security compliance requirements. Perimeter firewall rules can be simplified to allow traffic exclusively from Private Links, which are accessible only from the designated tenancy. Private Links can mitigate L3-L7 attacks because the link is entirely private by design. XC Private Link Overview A Word on L3/4 DDoS: L3/4 attacks were brought up several times above when talking about the technicalities of each mitigation method. While a L3/4 attack is not always distributed by nature, most are. One very important concept to keep in mind is the fact that XC natively provides L3/4 DDoS mitigation at our Regional Edges. Even in the examples above where “attack” traffic could make it all the way to the app or at least to the perimeter, if it was a true DDoS, this would get picked up by our Regional Edges and automatically mitigated. Conclusion In today’s interconnected cloud ecosystems, mitigating CTOE attacks is crucial to maintaining service availability and performance. By understanding the vulnerabilities that stem from cross-cloud communications and applying best practices, organizations can safeguard their systems from exploitation. As we continue to expand our cloud footprints, proactive security measures are not only necessary but must evolve alongside the complexity of the environments we manage. Effective CTOE prevention is an essential part of ensuring a resilient, high-performing network in this cloud-driven world. Like this article? Please drop a like or line below!51Views0likes2CommentsHelp with Setting up WAF in Guided Configuration - Route Configuration Issue
Hello F5 Community, I’m trying to set up the WAF functionality using the UI on my F5 device (version BIG-IP 17.1.1.3 Build 0.0.5 Point Release 3) in a clustered environment. I’m going through the steps as follows: Security -> Guided Configuration -> Web Application Protection -> Web Application Comprehensive Protection When I attempt to use this guided configuration, a list of prerequisites appears. The primary issue seems to be that there are no routes configured, even though my DNS and NTP are set up. I don’t fully understand why route configuration is necessary for this WAF setup or what it should entail. Additionally, if I try to bypass this warning and proceed with the deployment, I receive the following error message: “Error: <IP> not discovered in any device-group.” The F5 documentation doesn’t seem to cover this issue and I’m unsure how to resolve it. Could anyone help clarify: Why is route configuration required for WAF in this scenario? How should I proceed with configuring the necessary routes, or is there a workaround? If further information is needed, I’d be happy to provide it. Thank you very much for any guidance or resources you can offer!56Views0likes4CommentsCurious about the ASM Attack Signature Update
When I update signatures through ".im files", some signatures were often deleted. I thought the signatures to be deleted would be "risk : low" or "accuracy : low". But their risk, their accuracy, was High or Medium. What's the point of removing these signatures from F5? I'm curious about the criteria for signature deletion. Thank you.46Views0likes3CommentsEnhancing Web Server Security via F5 Cookie Hash Exposure
I have a suggestion to improve web server security against CSRF attacks by leveraging the F5 load balancer's persistence cookie. Overview: - Current Functionality: F5 creates a persistence cookie to maintain client connections within a web farm. This cookie isn't directly accessible by the web server. - Proposal: Expose a hash sum (Hash-Sum) of this persistence cookie and include it in the HTTP request headers sent to the web server. How It Can Be Used: - Hash-Sum in Headers: Configure F5 to append the Hash-Sum of its persistence cookie to HTTP request headers. - Session Change Detection: If the Hash-Sum changes, the web server can detect that F5 initiated a new session, potentially indicating a CSRF attack. - Security Analysis: The web server can use the Hash-Sum to monitor session continuity and validate request legitimacy. Benefits: - Enhanced Security Checks: Provides additional data for the web server to verify client requests. - Early CSRF Detection: Helps identify unexpected session initiations that may signal CSRF attacks. - Session Integrity Monitoring: Assists in maintaining session integrity by detecting new sessions initiated by F5 without client action. - Infrastructure Leverage: Utilizes existing F5 functionality without significant changes to client-side applications. Challenges and Considerations: - Purpose Alignment: F5's persistence cookie is designed for load balancing, not security. Repurposing it requires careful consideration. - Hash Security: Must use strong hashing algorithms to prevent collisions and reverse-engineering. - Data Exposure Risks: Exposing the Hash-Sum could pose security risks if not properly secured. - Implementation Complexity: Changes needed in both F5 configuration and web server logic. - Standards Compliance: Must ensure alignment with security best practices and regulatory requirements. Recommendations: - Security Assessment: Perform a thorough security analysis before implementation. - Use Robust Hash Functions: Employ secure, industry-standard hashing algorithms. - Limit Exposure: Ensure the Hash-Sum cannot be used to reconstruct the original cookie. - Collaboration: Work with web server teams to standardize Hash-Sum validation methods. - Complement Existing Measures: Integrate with established CSRF protection mechanisms for layered security. Conclusion: Including the Hash-Sum of the F5 persistence cookie in HTTP headers can help web servers detect session changes initiated by F5, enhancing security against CSRF attacks. While promising, this approach requires careful implementation to address potential challenges. I welcome any thoughts or feedback on this proposal. Best regards, Mykola Uspalenko.44Views1like4CommentsApplication redirection
Hollo Community We are creating an application in F5(legacy app). The application need to working on port 443 and we created a vip with port 443. When login in to the application it's redirecting to port 7900 and the connection got refused as we are not having a vip(on port 7900). Application team need secure connection towards vip and 7900 vip with pool creation not a suggested solution For example, if we try application in https://xys.com it's working and getting the login page. After providing login credentials it's redirecting to http://xys.com:7900 and blocking After login I removed 7900 and refresh https:xys.com it's working as logged session. Need your suggestion how I can establish secure connection for this vip all communication. If any 7900 traffic in browser it's should forward to port 443 . AmirSolved55Views0likes6CommentsPositive Security vs. Negative Security: A Comparison Using F5's Security Portfolio
In the world of cybersecurity, understanding different approaches to threat mitigation is critical. Two fundamental security strategies often discussed are positive security and negative security. Both methods aim to protect applications, but they do so in contrasting ways. This post will explore these concepts using products in the F5 portfolio, particularly focusing on Web Application and API Protection(WAAP) solutions, such as F5 BIG-IP Advanced WAF, F5 Distributed Cloud WAAP and F5 NGINX App Protect. What is Positive Security? The positive security model is often referred to as a "default deny" model. It allows only known, trusted traffic, blocking everything else unless explicitly allowed. The idea is to trust a predefined list of "good" behaviors while blocking any unexpected or abnormal traffic. Key Features of Positive Security: Whitelisting: A whitelist is created based on known safe entities (IP addresses, users, behaviors, etc.), and only these are allowed access. Strict Enforcement: Any traffic that deviates from the defined norms is blocked. Reduced Attack Surface: Because only permitted actions are allowed, the potential for exploiting unknown vulnerabilities is minimized. F5 Implementation of Positive Security F5 BIG-IP Advanced WAF, F5 Distributed Cloud WAAP and NGINX App Protect employ positive security techniques, especially through custom security policies. These policies are based on the specific needs of the application and can be fine-tuned to only allow desired inputs and behaviors. Application Layer Protection: BIG-IP Advanced WAF can block traffic that doesn't conform to predefined application rules, allowing only legitimate users to interact with the app. Automated Learning Mode: Advanced WAF offers a learning mode where it can automatically profile the application, identify typical behaviors, and suggest a positive security model. Layer 7 DDoS Mitigation: The positive security model also helps block malicious Layer 7 traffic by identifying and allowing only legitimate request patterns. F5 Distributed Cloud WAP: Employs positive security techniques by enabling strict traffic rules based on user behavior analytics and advanced bot detection. API security feature, you can lock down APIs to accept only specific, defined inputs, making it much harder for attackers to exploit vulnerabilities. What is Negative Security? The negative security model works as a "default allow" model, where all traffic is allowed unless it matches a defined list of malicious behaviors. Essentially, this strategy relies on blocking known bad entities (e.g., IP addresses, signatures of attacks, etc.). Key Features of Negative Security: Blacklisting: A blacklist contains signatures or patterns of known attacks, and traffic matching these signatures is blocked. Flexibility: Since most traffic is allowed unless it is identified as harmful, this model is more flexible but often less secure. Signature-Based Detection: Most negative security systems depend on an updated list of attack signatures, such as SQL injection, cross-site scripting (XSS), and other known vulnerabilities. F5 Implementation of Negative Security F5 products incorporate negative security practices, particularly through signature-based protections. BIG-IP ASM: The Application Security Manager (ASM) module of F5 offers robust signature-based detection for common vulnerabilities like SQL injection and XSS. Predefined Attack Signatures: BIG-IP WAFs come preloaded with a vast library of attack signatures, making it easier to block known threats. Real-Time Updates: Regular updates to threat intelligence ensure that new and emerging threats are quickly blacklisted. Distributed Cloud: It leverages bot mitigation using a negative security approach, where known bot signatures and behaviors are automatically blocked. Positive Security vs. Negative Security: Which to Choose? Both approaches have their merits and limitations, and the best choice depends on the specific application and environment. Positive Security: Pros: Highly effective for sensitive applications like banking or healthcare, where only specific actions should be permitted. Cons: Requires meticulous configuration and constant monitoring, as it can block legitimate traffic if not properly tuned. Negative Security: Pros: Easier to implement and maintain since it focuses on blocking only known threats. Better suited for less critical applications where flexibility is key. Cons: Leaves the application vulnerable to zero-day attacks or new threats that haven't been blacklisted yet. Hybrid Approach with F5 Products One of the strengths of F5’s WAF solutions is the ability to combine both positive and negative security models for a hybrid approach. F5 BIG-IP Advanced WAF allows organizations to implement both positive security (through custom policies and traffic shaping) and negative security (using signature-based detection). This ensures comprehensive coverage by blocking known threats while also enforcing strict access controls. NGINX App Protect also offers flexibility by supporting both models, allowing businesses to optimize their security posture based on the application’s requirements. Distributed Cloud WAAPnot only supports a hybrid model but it provides security services via a SaaS consumption model. Additionally, the platform addresses the growing complexity of managing applications across multiple environments—public clouds, private data centers, and edge locations. Conclusion In a modern, dynamic security landscape, both positive and negative security models play vital roles. Positive security offers a strong defense for highly sensitive applications by allowing only trusted behaviors, while negative security provides broader coverage against known threats. F5 products, such as BIG-IP Advanced WAF, Distributed Cloud F5 Distributed Cloud WAAP, and NGINX App Protect, empower organizations to choose the best model or combine both, ensuring a tailored, effective security strategy.42Views0likes0CommentsNeed iRule to block the traffic for specific URL
Hello Can somebody help on this please? I have LTM appliance &Virtual server 'https://www100.test.com' hosted. The requirement I have is to block all the traffic destinated to one of the application 'https://www100.test.com/ce' - is this something achievable by iRule If so do you have any idea on the iRule? Would appreciate somebody can help. Have seen this - https://support.f5.com/csp/article/K74012450 but that is looking too complex to me. Thanks1.9KViews0likes6Comments