Deploying F5 WAF in front of Azure Web App Services
Does anyone know of a supported architecture for deploying an Azure F5 WAF in front of Azure Web App Services to handle the SSL and ASM services against traffic destined for an Azure Web App Service (App Service not just an app server running in Azure).
What happens if I only enable ASM in BIG-IP Under System > Resource Provisioning
Hi; Let's say that I have a Big-IP device licensed for LTM and ASM. However, only the ASM module is enabled under System > Resource provisioning with a level of nominal. I know that in this case, you can have a pool of only one member, but just to double check my information, I want to ask this questions: Is my understanding above incorrect, and in this case, the system does load balance to multiple pool members, or I should enable the LTM module for this to happen? Kindly WasfiWhat’s coming in BIG-IP Next Access and SSL Orchestrator
In April, BIG-IP Next version 20.2 was posted to the F5 download site. This is a Limited Availability release that contains Access and SSL Orchestrator functionality on BIG-IP Next. SSL Orchestrator details New Functionality/Features Support for Data Groups SSL Orchestrator now supports using data groups while defining a policy condition. If you have created a data group in Central Manager, you can select the data group from the value drop-down while defining a policy condition. Declarative API An API-first, fully declarative configuration environment, through F5 AS3, Ansible, Terraform, and other options. Container-native architecture Divided into container-based software modules, BIG-IP Next accelerates application delivery with app services that can be deployed and managed wherever they’re needed. These services are supported by programmatic interfaces that are declarative and backward compatible. Its architecture enables quicker setup as well as more frequent and simpler upgrading and updating. It streamlines security management, eases purchasing and managing licenses, and robustly protects any app, anywhere. Supported Deployment Modes/Type: Inbound Application (Layer 3) Inbound Gateway (Layer 3) Supported Inspection Services: Generic TAP Generic ICAP Generic Inline L3 HTTP Transparent Inline HTTP Explicit Inline Coming Soon (June/July) Supported Deployment Modes/Type: Outbound Gateway (Layer 3) Supported Inspection Services: Generic Layer 2 Resources DevCentral article: What is BIG-IP Next? DevCentral article: Configuring SSL Orchestrator on BIG-IP Next* Demo Video: Configuring SSLO Orchestrator on BIG-IP Next DevCentral article: Configuring Inbound Gateway Mode on BIG-IP Next SSL Orchestrator* Demo Video: Configuring Inbound Gateway Mode on BIG-IP Next SSL Orchestrator *The SSLO Orchestrator articles in DevCentral are available in the Community Group “BIG-IP Next Academy”. You must have a DevCentral account and request access to this group in order to view these articles. Click HERE to get started. Next Access details New Functionality/Features Access as Code An API-first, fully declarative configuration environment, through F5 AS3, Ansible, Terraform, and other options. Simplified policy management Simple policy creation and management regardless of policy complexity for both basic and advanced use cases via Visual Policy Designer (VPD) or API. Centralized management Holistic approach to management through Next CM with global session support and shared pool of licenses. Container-native architecture Divided into container-based software modules, BIG-IP Next accelerates application delivery with app services that can be deployed and managed wherever they’re needed. These services are supported by programmatic interfaces that are declarative and backward compatible. Its architecture enables quicker setup as well as more frequent and simpler upgrading and updating. It streamlines security management, eases purchasing and managing licenses, and robustly protects any app, anywhere. Supported features: SAML as Service Provider OAuth Client OAuth Resource Server Multiple SSOs Types (Kerberos, HTTP Basic, OAuth Bearer, Forms and Client-initiated Forms) Per-Session HTTP Connector AD, LDAP, Client Cert Authentication, CRLDP Authentication Resources: Webtops, Webtop Sections, Network Access, ACLs VPN – Full & Split Tunnel (IPv4) VPN – Client Installer Customization VPN – CCU Utilization Dashboard Coming Soon (June/July) Supported features: Access policy versioning JSON formatted logging Global Session support DHCP server support for VPN Resources DevCentral article: What is BIG-IP Next? DevCentral article: BIG-IP Next Access: Introducing Next Access Alongside Our Trusted APM* Demo Video: BIG-IP Next Access Series: Introduction a leap into the future DevCentral article: BIG-IP Next Access: SAML Federation made easier* *The Next Access articles in DevCentral are available in the Community Group “BIG-IP Next Academy”. You must have a DevCentral account and request access to this group in order to view these articles. Click HERE to get started.
Wildcard SSL Certificate Deployment on F5 LTM
We utilize F5 load balancer to generate CSR and implement Entrust SSL certificates across all subdomains within our infra. We're exploring the possibility of deploying a wildcard SSL certificate for a domain and its associated subdomains. ltm version is 14.1.5 If feasible, we seek guidance on the process of importing and deploying it within F5.F5 Distributed Cloud – Multiple custom certificates for HTTP/TCP LB
TLS Certificate A TLS certificate is a digital certificate signed by a trusted Certificate Authority (CA) that will authenticate the identity of the certificate owner. It is required to encrypt and secure traffic over the internet using Public Key Infrastructure (PKI). F5 Distributed Cloud (F5 XC) had already implemented the ability to choose between automatic TLS certificate management and attaching a custom TLS certificate (aka Bring Your Own Certificate) in its HTTP/TCP load balancer configurations. Now a new feature is added enabling customers to attach multiple custom TLS certificates to a single HTTP/TCP load balancer, this will allow them to host multiple domains with different certificates from a single load balancer so that they can optimize costs or simplify configuration. Also, now TLS certificates can be shared across multiple LBs and customers can view and manage their TLS certificates and intermediate certificate chains as standalone objects from a centralized place. Note: This feature is supported for the HTTP/TCP LBs advertised either on Regional Edges (REs) or on Customer Edge (CE). Configuration Step1: Create TLS certificate object in XC console Select `Shared Configuration` service from the home page of XC console. Select `Certificate Management` from the left menu and select `TLS Certificates`, Click `Add TLS Certificate`. Note: Certificate Management configuration can be done either from Multi-Cloud App Connect, Web App & API Protection, Distributed Apps, or Shared Configuration services. Configure certificate properties and upload the certificate. Note: Supported certificate formats are PEM and PKCS#12 (aka P12) Optionally, configure OCSP stapling and intermediate certificate chain. OCSP (Online Certificate Status Protocol) is used to determine the revocation state of digital certificates. For more information on OCSP stapling follow the documentation Certificate Chain of trust refers to all the certificates that are linked together in an ordered fashion to validate the legitimacy of the server certificate. There are 3 components in this certificate chain: Root certificate: This certificate belongs to Root Certificate Authority (CA) and are self-signed. Intermediate certificate: This certificate belongs to intermediate CA and are signed by Root CA, Intermediate CA signs the certificates on behalf of Root CA and there can be one or more Intermediate CA in a certificate chain of trust. Leaf/server certificate: This certificate belongs to the web server to establish secure connection or authenticating clients reaching to the server, this can either be signed by a Root CA or an Intermediate CA. Above screenshot shows the list of TLS Certificates, one certificate is signed by the Root CA and is created in personal namespace (demo) while the other certificate is signed by the Intermediate CA and is created in `shared namespace` (Note: objects created in shared namespace can be used across all other namespaces). Step2: Attach TLS certificates to the load balancer (HTTP/TCP) Note: In this demonstration, we are attaching the TLS certificates to the HTTP LB Click on `Load Balancers`, from the left menu and select `HTTP Load Balancers`. Click Add `HTTP Load Balancer`, Configure HTTP LB, enter valid domains as per the TLS certificates. Select ‘HTTPS with Custom Certificate’ option in ‘Load Balancer Type’ field, and in ‘TLS Configuration’ select `Multiple Certificates` option. Click on ‘Configure’ and attach the above created TLS certificates by keeping ‘TLS Security Level’ as `High`. We have already created origin pools for our two domains and added those origin pool members to the LB with the help of ‘Routes’ as shown inthe screenshots below. (Applications deployed on origin servers are httpbin and dvga) You could either advertise this LB to the internet which is also a default setting or can customize it to be advertised on a CE site. For this demo we have advertised the LB to 'Internet'. Click `Save and Exit`. Note:Each LB has a certificate expiration date, and in case of multiple certs this value is automatically set to the expiry date of its certificate which is expiring earlier. Similarly, you can configure TCP LB as well with multiple custom TLS certificates. For more details on how to configure TCP LB refer to the document. Step3: Check the server certificate details by clicking padlock next to the URL Open the browser and check for the LB domains, Connection should be shown as secure. Note: In this demo we are using local domain names and TLS Certificates, so we have manually added the custom local `Root CA` certificate to the browser and edited the hosts file to map VIP with our domain names. When the certificate expiry date approaches near, you will be notified with alerts. You can see active alerts by navigating to `Notifications -> Alerts` section from the menu on the left side or by clicking the bell icon on top right corner of the XC console. Based on the alerts received, you can renew the certificate expiration date and upload it again to the existing XC’s TLS cert object to reuse it instead of creating a new object. Conclusion: In the above demo, you have seen using XC console how easy it is to manage your multiple custom TLS certificates from a centralized place.
Cannot login to Avaya wanx using f5 apm network access
Hi we are facing some issues related to APM network access, we cannot login to our avaya wanx ip phone communicator using network access, but we can ping the call server we are using, but still no luck on login. Is there something we need to adjust on APM network access setup?Can iRule be used to perform exception of IPI category based on Geolocation
Hi Everyone, Can we configure iRule to perform exception on certain IPI category like "Spam Sources" based on Geolocation. For instance, I want to bypass the mitigation enforced on "Spam Sources" IP intelligence category for "Nepal" -Geolocation specific because of the large false positives on this category. I found the iRules to enforce the mitigation based on the defined IPI category: when HTTP_REQUEST { set ip_reputation_categories [IP::reputation [IP::client_addr]] set is_reject 0 if {($ip_reputation_categories contains "Windows Exploits")} { set is_reject 1 } if {($ip_reputation_categories contains "Web Attacks")} { set is_reject 1 } if {($is_reject)} { log local0. "Attempted access from malicious IP address [IP::client_addr] ($ip_reputation_categories), request was rejected" HTTP::respond 200 content "<HTML><HEAD><TITLE>Rejected Request</TITLE> </HEAD><BODY>The request was rejected. <BR> Attempted access from malicious IP address</BODY></HTML>" } } https://techdocs.f5.com/en-us/bigip-15-0-0/big-ip-local-traffic-manager-implementations/enabling-ip-address-intelligence.htmlPowerPoint, ArcaneDoor, the Z80 and Kaiser Permanente - April 21-27, 2024 - This Week in Security
Notable security news from the week of April 21st with a small side of nostalgia for the Z80 CPU; we'll dive into the exploitation of an old PowerPoint CVE from 2017, ArcaneDoor and the targeting of Cisco perimiter devices and an enormous breach of Kaiser Permanente user information!
