F5 BIG-IP APM – Identity-aware proxy (IAP)

I’ve been reading about Identity-Aware Proxy (IAP) this week because it’s a new feature in F5 BIG-IP APM and I wanted to know exactly what the advantages of this solution are. Initially, I was reading and I didn’t understand anything. It were the same as I knew it. Authentication, Single Sign-On (SSO) and a few more things. However, I’ve realised it’s a new feature from the point of view of usability. It’s a new feature for deploying a Zero Trust model validation based on granular context- and identity-awareness, securing every application access request.

Identity Aware Proxy (IAP) delivers secure access to applications based on the principle of “Never Trust, Always Verify”. It means, IAP is a Zero Trust architecture where there is no a secure network perimeter and there is no trusted insider. As a result, everything is untrusted, even users that have already been authenticated, authorized, and granted access to applications and resources. IAP should verify not just at the time a user requests access but also when users have access to the application or resource, and upon every subsequent access request and attempt.

Identity-aware proxy - IAP

IAP grants access to applications by evaluating real-time device posture, user identity and step-up authentication. Thanks to F5 Access Guard, IAP can check the device security posture such as firewall, antivirus, patches, etc from the client-side. Therefore, IAP along with Access Guard go beyond simply checking device integrity at authentication. Instead, they deliver continuous, ongoing device posture checks. As a result, if IAP detects any change in the device integrity, it may either limit or stop the user’s application access.

Define a firewall Posture Assessment

IAP is going to authenticate, authorize and encrypt every access request. We can also add an extra security layer with MFA as well as enable SSO. IAP supports modern authentication and authorization protocols like SAML, OpenID Connect and OAuth. In addition, due to every access request is encrypted, we can use IAP instead of VPN to access the enterprise network because IAP is per request application access while VPNs apply session-based access. Therefore, IAP is more secure than VPNs.

BIG-IP APM is a single, centralized control point for securing and managing user access to applications, wherever they may be hosted

Thanks to Access Guided Configuration (AGC) for version 15 and Simplified Guided Configuration (SGC) for version 16, it is really easy to deploy an IAP architecture. There is a step by step guide where we can easily configure the device security posture, the authentication servers, SSO authentication profiles, etc. It’s the best way to deploy an IAP solution with a Zero Trust model validation.

Access Guided Configuration - Single Proxy

To sum up, I knew most of the features about F5 BIG-IP APM such as Identity federation, MFA, SSO, SSL VPN and API Protection but I didn’t know the Identity-aware proxy (IAP) solution very well until recently. Once I’ve been reading about it, I’m going to take the plunge and I’m going to configure a small lab to see how it is working with the AGC. I think this is the best way to know how IAP works.

F5 BIG-IP APM features

Regards my friends! What have you been doing this Christmas?

Log4Shell

We have lived a really interesting week from the security point of view because we have known the most widespread cybersecurity vulnerabilities in recent years. There are lots of vulnerabilities day in and day out but most of them are not as important as the vulnerabilities discovered last week in a piece of free and open source software called log4j. These vulnerabilities are very important because log4j is widely used by lots of applications as well as the vulnerabilities discovered are really critical.

Log4j is used by thousands of websites and apps. In fact, there are companies who don’t know yet how many websites and apps are using this piece of code, which is really dangerous because they don’t know yet the extent of these vulnerabilities in their services. Actually, log4j is mainly used for logging information which is a functionality needed by most web applications. In addition, these vulnerabilities are extremely easy to exploit but it is also easy to protect against these vulnerabilities because updating servers or disabling log4j is simple.

As I write this article, there are three Log4j vulnerabilities. The first vulnerability publicly disclosed is CVE-2021-44228, which is a Remote Code Execution (RCE) vulnerability and it is the most critical vulnerability. This vulnerability is critical because Apache log4j Java library doesn’t properly validate input thus attackers can execute arbitrary code loaded from LDAP servers. The second vulnerability discovered is CVE-2021-4104, which is also a RCE vulnerability. However, this one is less critical than the first one because this vulnerability only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. In addition, Log4j 1.2 reached end of life in 2015. Finally, the third vulnerability is CVE-2021-45046, which is a Denial of Service (DoS) vulnerability. This is the less critical one.

Source: Swiss Government Computer Emergency Response Team

These three vulnerabilities have to make us think about the software supply chain. There are lots of developers who use libraries which are never updated. In fact, most of them don’t know if they are using vulnerable software. What’s more, there are lots of companies who don’t have a software inventory. Therefore, they don’t know what servers they have to update. In addition, there is now a lack of developer resources that updating software will be longer than it used to be.

I’m wondering where is the Zero Trust that all security companies were telling us in webinars. Why does Log4j have access to outside servers? Log4j should never have been able to communicate with outside servers. We should learn as much as possible with this event. Zero Trust is not a project with a start and a finish because environments are constantly changing. This is why we should always think about inventory. Zero Trust is the new implementation of security but it is a process that will never finish.

To sum up, there is lots of work to do. Updating servers is one task to do. Deploying WAF appliances and upgrading signatures is also a task to do. However, security management is a process where we have to take lots of things into account.

Regards my friends! Do you have any thoughts about this event?

Souvenirs d’un soir d’été

J’ai été hier soir dans un bal d’été dans mon village où j’ai grandi, j’ai joué et j’ai connu mes meilleures amis. C'était un soir très chaud. Je ne me rappelais pas bien les soirs d’été de mon village. Cependant, le bal d’été a été une belle opportunité pour la rencontre de tous mes amis et pour parler de toutes les choses que nous avons fait ensemble quand nous étions adolescents.

Dès que je suis arrivé au bal, je me suis réjoui d’y être allé parce que tous mes amis étaient là-bas. Au fur et à mesure que nous parlions, et nous buvions aussi, nous étions plus ravies. En fait, je crois que je n’ai jamais dansé autant qu’hier soir. Nous étions aux anges de retourner au village même s’il est une fois par an. À mon avis, nous sautions tous de joie de nous revoir.

Une fois que le bal a fini, la tristesse est arrivée à tous les nous. Je voulais rester au bal pendant toute ma vie mais nous devions rentrer chez nous. Donc, la mélancolie et la nostalgie sont revenues dans nos vies. Avant que j’écrive ce journal, j’ai été abattue et j’ai pleuré toutes les larmes de mon corps mais, maintenant que je me rends compte que ces sentiments sont très beaux, je suis joyeux de ma vie, de mes amis et d’être allé au bal d’été.

 

Salut!

F5 AWAF - Securing APIs with BIG-IP

There are lots of web servers on the Internet and most companies know they should protect them against attacks. As a result, companies deploy WAF appliances. However, there are increasingly APIs on the Internet, which are used by apps to request and send data, that we should also protect. API servers are like web servers because they respond to requests using the HTTP protocol. Therefore, we must also protect them.

From my point of view, the API Protection feature included in APM 14.1 along with the API Security feature included in AWAF 15.0 is the best solution for protecting API servers from attackers. API Protection means authentication, authorization and federation services using OAuth, JWT, OpenID Connect or SAML while API Security means security against attacks such as SQLi, XSS or XXE. Therefore, the best way to protect API servers will be to import an OpenAPI Spec 2.0 file into BIG-IP which will add the details of the API such as paths, API servers, responses, API protection profile, etc.

REST API Security - Configuration example

Configuring a WAF policy to protect API servers is really easy. Firstly, we should deploy the AWAF module (formerly ASM module). Secondly, we have to create a security policy where we are going to choose API Security as Policy Template. In addition, we are going to import the OpenAPI file where application-specific configuration is defined such as URLs, parameters and methods. Finally, we have to assign the security policy to the virtual server where the API service is listening. Once the security policy is created, we can see a list of allowed components in the security policy.

API Security template

The API Security template is great because F5 AWAF is going to configure a security policy to protect API services easily for us. However, we can add more security layers to this protection. For instance, I like to add a bot defense profile to prevent all types of malicious bots from accessing the API services. This protection relies on signatures and javascript based challenges. Therefore, it is important to highlight that JS challenges need to be used with caution.

Bot Defense profile

There is another security layer I really like to add to web assets such as API servers. As attackers can send legitimate requests at a high scale, they can bring down an API service. As a result, I like to add a DDoS Defense profile to API servers. There are mainly three protection mechanisms. Firstly, transaction per second (TPS) Based DoS Defense which is the most straightforward mechanism because it measures requests rate. Secondly, the stress-based mechanism is similar to TPS but it only mitigates when the protected asset is under stress. Finally, behavioral anomaly detection (BADoS) mechanism which uses a machine learning algorithm.

DoS Defense profile

To sum up, if you have API services, you will also have to protect them. If you have F5 AWAF, you have almost everything. You only have to enable API Security to your services.

Regards my friends! Do you protect your API servers?