Jump to content
Updated Privacy Statement
  • Hemang Raval
    Introduction
    Weak or stolen passwords are a leading cause of breaches in Enterprise networks. They can lead to loss of Intellectual Property, loss of Personally identifiable information (PII) and result in a significant impact on the business. Multifactor Authentication (MFA) is one of the best security measures to guard against identity vulnerabilities.
    Typically there are three types of authentication used to identify users:
    1) Something you know (for example, password) - this type is historically the most common type used. Users enter a user name and a password that only they know. Passwords can be strengthened against attacks from bad actors, with greater amounts of characters and with more types of characters. However, users are only human and may keep them simple or avoid changing them regularly. Then if the endpoint is infected with malware, it is only a matter of time until unrelenting algorithms figure out the password and compromise systems and data that the user has access to.
    2) Something you have (for example, a digital key, physical, or virtual smartcard) - this type is a common second factor, particularly with the US government. Users are issued a smartcard, and after entering their user name and password, a private certificate and key are extracted and validated. Physical cards are inserted into readers attached to endpoints, or virtual cards are installed on the endpoint for the user to copy and pasted into the authentication form.
    3) Something you are (for example, fingerprint scanner) - this type is a third method that focuses on using biometrics to uniquely identify a user. Historically biometrics have seen slower mainstream adoption due to expense to implement and complexity, yet they are a powerful option for high-security environments.
    Multifactor authentication pertains to using two or more of these types of authentication to verify user identity and mitigate the risk of bad actors obtaining access to Enterprise environments.

    Overview
    The Citrix ADC supports various multifactor authentication methods. It provides an extensible and flexible approach to configuring them with nFactor authentication.
    It also supports various application delivery technologies that can utilize multifactor authentication, including Content Switching, Traffic Management Load Balancing, Full VPN, and Gateway proxy. It can be employed in on-premises, Cloud, and Hybrid environments.
    This brief describes multifactor authentication using five pairs of methods with Citrix Gateway. It focuses on using the methods with Citrix Virtual Apps and Desktops on-premises environments and with Citrix Workspace.

    nFactor
    nFactor uses Citrix ADC AAA Virtual Servers to deploy multifactor authentication. They bind to advanced policies and actions, grouped in factors, to implement authentication methods. The interface to users requesting authentication credentials, and the variables that store their input, are defined in a login schema.
    nFactor can be configured through the CLI, through the GUI manually, or through the visualizer tool in the GUI. Pertinent configuration elements include:
    Visualizer - a tool available in the Citrix ADC GUI to aid with the configuration of nFactor to implement MFA flows for a multitude of authentication requirements. Citrix ADC AAA Virtual Server - “Factor 0” is the starting point for MFA, which is referenced by Gateway, LB, or Content Switch Virtual Servers that rely on it for authentication. Factor - factors, which are bound to the Citrix ADC AAA Virtual Server, act as a “bucket” to contain a set of policies and pertinent schema. (Also known as Policy Labels when the Visualizer is not used) Login Schema - the “landing page” for each authentication factor includes field types and variables referenced throughout the flow. Policy - an object that maps to authentication actions and includes an expression to determine when it’s a match. Action - Defines the various authentication methods. SAML, OAuth, Certificate, LDAP, and so on.
    Methods
    Citrix ADC supports many authentication methods. For more information, see Citrix ADC Authentication Methods. In this brief, we focus on using domain credentials, representing something the user knows, with five variations of something the user has.
    Native OTP Push Token Email OTP Group Extraction Device Certificate Native OTP
    Native OTP or “One Time Pin” works by the Citrix ADC, having users register with an app that supports OTP and sharing a key with it. Then it uses the current time along with that key to generate a string of numbers, at regular intervals, that only the user’s OTP app has (for example Microsoft Authenticator, or Citrix SSO app). By default, it uses a six-digit OTP code that is valid for 30 seconds.
    In our scenario, in order to successfully authenticate, the user enters their domain credentials followed by the OTP code. After successful validation by the Citrix ADC, the user’s credentials are relayed to the target delivery systems, and their apps sessions can be established with single sign-on.

    For more information regarding how to try it out in your environment, see: Proof of Concept Guide: nFactor for Citrix Gateway with Native OTP Authentication
    Push Token
    With Push Token, the user also does an initial registration with the Citrix ADC. Yet, with this method, the user is not required to copy and paste a code. Instead, the ADC sends a PUSH notification over mobile delivery networks (APNS for Apple devices or GCM for Android devices). Then the user simply has to accept a popup from the Citrix SSO app to complete the second factor. Again, once the user’s credentials are relayed to the target delivery systems and their apps, sessions can be established with single sign-on.

    For more information regarding how to try it out in your environment, see: Proof of Concept Guide: nFactor for Citrix Gateway Authentication with Push Token
    Email OTP
    Email OTP works like Native OTP, yet the OTP code is sent as an email rather than to an app. This method is valuable for user groups that do not have mobile devices. It works in a similar fashion in that the code generated expires at regular intervals, and the user must copy and paste it into a field along with their credentials.

    For more information regarding how to try it out in your environment, see: Proof of Concept Guide: nFactor for Citrix Gateway Authentication with Email OTP
    Group Extraction
    Group Extraction is the same type of authentication as entering domain credentials, yet it is able to route to other types by extracting the user’s group membership. Then, using the earlier example, admins can designate a group as mobile users or non-mobile users to determine whether their second factor is Push Token and Email OTP. Alternatively, they can designate groups of users according to their security persona and match the number and type of authentication methods according to the groups’ risk profile.
    Examples of user groups include:
    Normal-security-group for individuals that have lower security requirements by the nature of their job or limited data access and are located within the bounds of the corporate security perimeter. This group may only require 1 factor.
    Elevated-security-group for third-party workers or contractors who do not have had background checks done and have higher security requirements. This group may require two or more factors.
    High-security-group for employees that perform critical jobs and require special government clearance or industry approval. This group may require two or more factors and contextual verifications such as source IP address.

    For more information regarding how to try it out in your environment, see: Proof of Concept Guide: nFactor for Citrix Gateway Authentication with Group Extraction
    Device Certificate
    Device Certificate relies on the availability of a unique certificate on the endpoint. The Citrix ADC validates that the certificate was issued by a designated Certificate Authority. There are various methods to manage issuing and revoking the certificates. Once in place, it can provide a seamless second authentication factor that requires little or no input from the user.

    For more information regarding how to try it out in your environment, see: Proof of Concept Guide: nFactor for Citrix Gateway Authentication with Device Certificate
    Workspace service
    Once you have a nFactor flow setup, you can integrate with Workspace service. Within Workspace service under Identity and Access Management, the Citrix Gateway service provides settings required to integrate with the Citrix ADC using OAuth.
    1.) Citrix Workspace - configure the Citrix Gateway service to point to the Citrix ADC Virtual Server. Change the Workspace authentication method to Citrix Gateway
    For more information regarding how to try it out in your environment, see: Tech Insight video: Authentication - On-Premises Citrix Gateway

    2.) Citrix ADC nFactor - create an Oauth policy using tenant information obtained from Workspace service. Bind it to the pertinent AAA Virtual Server with a higher priority than the nFactor flow. Update the “Logon Point” landing page theme with the Citrix Workspace look and feel.
    For more information regarding how to try it out in your environment, see: Customizing the on-premises Citrix Gateway authentication page to look identical to Citrix Cloud logon page

    Once configured, users continue to access their Workspace service domain (for example, https://<customerdomain>.cloud.com) and are automatically redirected to the Citrix ADC FQDN. Upon successful authentication, Citrix ADC relays the status for the user name back to the Workspace, and the user is presented with their resources.

    Summary
    With Citrix nFactor, Enterprises can implement reliable multifactor authentication and fortify the primary entrance to their environments. They can implement this security improvement all while maintaining a good user experience.

    Konstantinos Kaltsas
    Agile, flexible DevOps practices are crucial to successful application modernization initiatives, which often involve migrating applications from on-premises to public cloud using containers. At the same time, many organizations must continue hosting applications on-premises due to regulatory and compliance requirements, cost concerns, or other business needs. NetScaler, an application delivery and security platform, and Google Anthos, a cloud-centric container platform, work together to provide consistent and reliable application delivery and security for any application on any infrastructure.
    NetScaler for hybrid cloud application delivery
    NetScaler provides powerful and flexible topologies that complement organizational boundaries. Dual-tier deployments employ high-capacity hardware or virtualized NetScaler ADCs in the first tier to segment control between network operators and Kubernetes operators, while the second tier employs containerized NetScaler ADCs within the Kubernetes cluster.
    With its flexible topologies, NetScaler makes it as easier to migrate applications between on-premises and cloud. Because all NetScaler form factors share the same code base, NetScaler works the same regardless of the environment in which it is deployed. So you gain operational consistency along with greater agility regardless of the type of application (monolith or microservices) and infrastructure. Key NetScaler features include auto-scaling, global server load-balancing (GSLB), multi-cluster ingress, and a web application firewall.
    Google Anthos for hybrid cloud infrastructure management
    Google Anthos unifies the management of compute infrastructure and applications across on-premises, at the edge, and in multiple public clouds with a Google Cloud-backed control plane for consistent operation at scale. Key features like an enterprise-grade container orchestration and management service; policy and configuration management; and a service mesh help you to accelerate the adoption of Day 2 operations and make your DevOps pipeline more efficient.
    Key capabilities of NetScaler with Google Anthos
    Key capabilities you gain from using NetScaler with Google Anthos include:
    Auto-scale ADCs from within a Google Kubernetes Engine (GKE) cluster based on user demand Automate ADC Day 2 operations using Anthos Config Management Implement advanced security controls and enforce security policies with NetScaler Web App Firewall and Anthos Policy Controller Automate multi-cluster/multi-regional deployments and load balancing configurations from within GKE using NetScaler GSLB and Anthos Config Management Export metrics and transaction data from NetScaler using the containerized NetScaler Observability Exporter and export them to such popular endpoints as Zipkin, Kafka, Elasticsearch, Prometheus, and Splunk Enterprise Automate canary deployments using NetScaler Ingress Controller and Anthos Config Management We provide fully functional labs for you to test. The labs’ source code is publicly available on GitHub. Note that our GitHub account refers to Citrix ADC, which is the former name of NetScaler.
    Request a free consultation with the NetScaler product team
    If you’re looking to get started with application modernization, request a free consultation with the NetScaler product team: appmodernization@citrix.com.
    To participate in the discussion about application modernization, join the NetScaler cloud-native Slack channel.
     
     

    Konstantinos Kaltsas
    This is the third post in our series on Citrix ADC with Google Anthos. In our first post, we talked about the importance of modern app deliver and security for hybrid multi-cloud, and in our second post, we focused on achieving consistent and reliable app delivery for Kubernetes apps and shared a lab on GitHub for readers to test.
    In this post, we’ll focus on security and demonstrate how:
    Citrix ADC can strengthen your security posture across hybrid and multi-cloud. Citrix Web App Firewall (WAF) works seamlessly with Google Anthos Policy Controller to provide protection for Kubernetes apps and APIs. Citrix Web App Firewall with Google Anthos Policy Controller enforce app protection using configuration as code GitOps enhances continuous configuration along with Google Anthos Config Management for automating security configuration. Protecting Web Apps and APIs
    When it comes to application delivery, security is a top priority. Web apps and APIs are often an organization’s most valuable but vulnerable assets, and to reach production and go live, there are several requirements that need to be met. From governance and compliance requirements to organization-specific requirements, the task is not an easy one.
    Citrix Web App Firewall has proven and robust security controls to protect apps against known and unknown application attacks. It defends apps and APIs against OWASP top 10 threats and zero-day attacks and provides security insights for faster remediation. To learn how Citrix Web App Firewall is designed to provide security, check out our product documentation. Our introduction to Citrix Web App Firewall, overview of security checks, and FAQs and deployment guide are great resources to help you get started.
    Citrix Web App Firewall is designed to be easily enabled and configured as code following the infrastructure and configuration as code paradigms. By providing WAF, bot management, CORS CRD for Kubernetes, security configurations are now possible from within a GKE cluster. You can now automate the configuration of both Tier-1 and Tier-2 Citrix Web App Firewalls easily.
    Common protections such as buffer overflow, cross site request forgery (CSRF), cross site scripting (XSS), SQL injection, URL allow lists and block lists, or more advanced ones can be easily enabled as policies using simple YAML files. Combining these capabilities with policy agents (as we’ll see in our lab) introduces an enterprise-grade practice of configuring and automating security.
    The key advantage of using Citrix WAF is that it uses a single code base across all Citrix ADC form factors (MPX and SDX, as well as VPX and CPX) so you can consistently apply and enforce security policies across any application environment. That gives you ease of deployment and simplicity in configurations which saves time and reduces configuration errors.
    Citrix Web App Firewall follows well-established principles that provide DevOps, CloudOps and SecOps teams with the tools they need to effectively do their job. By supporting both positive and negative security models Citrix Web App Firewall provides the widest protection possible. In addition to that, common event format (CEF) logging enables customers to easily collect and aggregate WAF data for analysis by an enterprise management system. Configuring and integrating a WAF has never been easier.
    Because security configurations can be part of the source code and stored in Git, different configurations can be created and maintained per environment. “Shifting Security Left” in the early stages of testing can become easier and Dev(Sec)Ops practices can be applied. Configurations are now closer to meeting the actual need, closer to the apps that need protection, and can eliminate false positives. And with a single point of truth, full visibility is achieved for both Operations and Audit teams, making it even easier to perform required audits.
    Deploying a Modern Application Architecture
    Here, we’ll focus on deploying a Tier-1 Citrix ADC (VPX) in front of a Google Anthos GKE cluster within GCP. We will leverage Google Anthos Configuration Management for consistent deployment of Citrix components into the Anthos GKE cluster. Additionally, we’ll leverage Google Anthos Policy Controller to ensure that Citrix Web App Firewall configurations exist to protect ingress objects within a cluster.
    ACM (Anthos Configuration Management) is a GitOps-centric tool that synchronizes configuration into a Anthos Kubernetes cluster from a Git repository. Policy Controller is a component of ACM that can audit or enforce configurations across the cluster. This lab automation has been written with GitHub as the git repository tool of choice.
    The following diagram illustrates the infrastructure used by our lab that will be deployed. (Click the image to view larger.)

    Citrix ADC VPX
    A single Citrix ADC VPX instance is deployed with two network interfaces:
    nic0 provides access for management (NSIP) and access to back-end servers (SNIP). nic1 provides access for deployed applications (VIPs). Each interface is assigned an internal private IP address and an external public IP address. The instance is deployed as a pre-emptible node to reduce lab costs. The instance automatically configures the password with Terraform. The instance is then automatically configured by the Citrix Ingress Controller and Citrix Node Controller deployed in the GKE cluster. VPCs and Firewall Rules
    Two VPCs are used in this deployment:
    The default VPC and subnets are used for instance and GKE cluster deployment. The vip-vpc is used only to host VIP addresses, which routes the traffic back to the services in the default VPC. Default firewall rules apply to the default VPC. Ports 80/443 are permitted into the vip-vpc. GKE Cluster with Anthos Configuration Management
    A single GKE cluster is deployed as a zonal cluster:
    Autoscaling is enabled with a minimum of one node and a configurable maximum. The Google Anthos Config Management (ACM) operator is deployed into the GKE cluster and configured to sync the cluster configuration from a GitHub repository. Citrix Ingress Controller and Citrix Node Controller components are automatically installed via ACM into the ctx-ingress namespace. Citrix Web App Firewall Custom Resource Definition (CRD) is installed via ACM to enable developers to create WAF configurations. Worker nodes are deployed as pre-emptible nodes to reduce lab costs. Policy Controller is installed to demonstrate constraints that enforce the presence of a WAF object in a namespace prior to accepting an Ingress resource. GitHub Repository
    A dedicated GitHub repository is created and loaded with a basic cluster configuration:
    A basic hierarchical format is used for ease of navigation through namespaces and manifests. Citrix Ingress Controller and Citrix Node Controller deployment manifests are built from templates and added to this repository, along with their other required roles / rolebindings / services / etc. This repository is created and destroyed by Terraform. Online Boutique Demo Application
    The online boutique demo application provides a microservices-based application for our lab. It has been modified slightly for this environment:
    An ingress resource has been added to receive all traffic through the Citrix VPX. Application components are controlled through Anthos Config Management and the source git repo. To learn more about how to deploy this lab and see autoscaling in action, please visit Citrix ADC with Google Anthos – WAF with Policy Controller Lab on our Citrix Cloud Native Networking (CNN) hands-on guides.
    Additional Information
    Read more about how Citrix can help you on your application modernization journey in our Microservices App Delivery Best Practices library.
    Interested in learning more about Citrix application and API security? Check our Citrix Web App Firewall data sheet.
    Find out how a Citrix ADC solution helps manage, monitor, and secure your entire infrastructure and ensure application security efficacy on our e-book on the Top 6 WAF Essentials to Achieve Application Security Efficacy.
    In our app delivery and security developer docs, you’ll find guidance on configuring Citrix components to meet your specific requirements.
    Our e-book on six must-haves for app delivery in hybrid- and multi-cloud environments has details on why you need an application delivery controller along with a management and orchestration platform.
    You can learn more about the role of application delivery in the cloud-native journey in our white paper on seven key considerations for microservices-based application delivery.
    Finally, the ADC Guide to Managing Hybrid (IT and DevOps) Application Delivery covers how Citrix ADC bridges the gap between traditional and DevOps app delivery.
    What’s Next?
    Watch out for the next blog post in our series, where we will discuss how you can use Citrix ADC, with its extensive set of policies, as an API gateway for Kubernetes apps.
    Looking to get started or take the next step in your app modernization? Our team is now offering free consultations! Send an email to appmodernization@citrix.com to schedule your session or request a call and a specialist will promptly reply with options to connect.
    Want to join our Citrix cloud-native Slack channel? Sign up now to receive an invitation.

    Konstantinos Kaltsas
    In the previous post in our series on Citrix ADC and Google Anthos, we covered the importance of security and how NetScaler ADC can strengthen your security posture across hybrid and multi-cloud using Citrix Web App Firewall (WAF). NetScaler WAF works seamlessly with Google Anthos Policy Controller to enforce protection for Kubernetes apps and APIs using configuration as code, and the GitOps paradigm enhances Continuous Configuration along with Google Anthos Config Management for automating security configuration.
    In this blog post we will look at why APIs are important for organizations, and we will discuss how you can leverage NetScaler ADC, with its extensive set of policies, to provide API gateway functionalities at the edge, as an enterprise API gateway or within a Kubernetes cluster as an ingress API gateway. We will cover a dual-tier topology for API gateways and showcase how we can leverage Google Anthos Config Management for consistent API management and protection.
    Why Are APIs Important?
    Finance, manufacturing, transportation, healthcare, and telecommunications are just some of the sectors trying to stay competitive in today’s economy by providing access to services through web APIs. With the increasing adoption of cloud, use of smart devices, IoT and more, demand for APIs continues to increase with hundreds of services provided through public or private APIs.
    Developers have long used APIs to share data and integrate with other systems. Although there are several types of APIs, web APIs are the most common, with REST, SOAP, and gRPC the most frequently adopted. As the use of public cloud and consumption of cloud services grows, APIs have become one of the most important aspects of software architecture. With an increasing shift from monolith apps to microservices-based architectures, APIs are no longer just for exposing services to external consumers. APIs have become the standard method for communication between microservices.
    There are dozens of architectural patterns for application modernization, and APIs play an important role. Shifting to microservices provides incredible benefits including dynamic scalability, fault isolation, reduced response downtime, and technology stack flexibility to eliminate vendor or technology lock-in and platform dependency.
    But all these benefits hide challenges that can require deep expertise on microservices-based architecture concepts. Exposing APIs, handling communication between microservices, applying authentication, authorization, and rate limiting require specific measures to be applied in a proper way. Security, high availability, and more require different handling with API management now becoming a cornerstone for the success of application modernization.
    Citrix API Gateway
    One of the most common architectures for API management and protection is the API gateway. An API gateway acts as a single-entry point for all clients that make API calls to a particular set of back-end services such as containerized web apps in a Kubernetes cluster. The API gateway is responsible for proxying/routing requests to the appropriate services. Learn more about why you need an API gateway, how it works, and what its benefits are.
    Citrix provides an enterprise-grade API gateway for north/south API traffic into the Kubernetes cluster. The API gateway integrates with Kubernetes through the Citrix Ingress Controller and the Citrix ADC platforms (ADC MPX, VPX, CPX) deployed as the ingress gateway for on-premises or cloud deployments.
    Citrix ADC has an extensive set of policies you can use to enforce authentication and authorization policies, rate limit access to services, perform advanced content routing, apply HTTP transactions transformation using rewrite and responder policies, enforce WAF policies and more — all to support secure and reliable access to APIs and to microservices. Citrix’s API gateway is designed to be easily enabled and configured as it follows the infrastructure-as-code and configuration-as-code paradigms. By providing auth, rate limit, content routing, rewrite and responder, WAF CRDs and more, applying policies centrally in an easy manner becomes possible from within a GKE cluster. By creating simple YAML files you can easily provide common API gateway functionalities such as:
    Authentication mechanism like basic, digest, bearer, API keys, OpenID Connect, SAML, and more. Integration with authentication providers like OAuth, LDAP, and more. Fine-grained authorization using OAuth 2.0. Rate limiting for APIs that are in high demand. OWASP-suggested hardening measures using rewrite and responder policies. The key advantage of using Citrix API gateway is that it integrates with Kubernetes through Citrix Ingress Controller and Citrix ADC. This gives you flexibility as you create your architecture. You can configure an API gateway both on Tier-1 using MPX, VPX and on Tier-2 using CPX.
    Tier 1 ingress will act as an enterprise API gateway sitting in front of Kubernetes clusters and traditional 3-tier applications. Functionalities like WAF and Auth can be offloaded and managed centrally for all environments. Tier 2 API gateways can be introduced per Kubernetes cluster, namespace or particular set of apps according to business requirements and SDLC (Software Development Lifecycle) practices being followed. Additionally, when extreme isolation is required you can introduce API gateway functionalities for namespace-to-namespace communication. In this case Tier 2 API gateways can be configured from the team responsible for the appropriate namespace or particular set of apps. This high level of flexibility gives all the relevant personas the tools required to do their job while focusing on what they do best. Citrix follows well-established principles that provides DevOps, CloudOps, SecOps and Software Engineering teams with the tools they need to effectively do their job. By supporting the Swagger API specification format, APIs can be defined by software engineers who design the APIs while configuration can be automated from DevOps and CloudOps teams, and security teams can specify the appropriate measures for the APIs to be protected.
    Combining these capabilities with GitOps tools like Google Anthos Config Management or adopting Citrix’s own API Gateway with GitOps implementation introduces an enterprise-grade practice of API management and protection. Because policy configurations can be part of the source code and stored in Git, different configurations can be created and maintained per environment, enhancing SDLC and DevOps practices even more while the API gateway can be deployed closer to the apps that need be managed and protected.
    Modern Application Architectures
    In this section, we will focus on deploying:
    Tier 1 Citrix ADC (VPX) in front of a Google Anthos GKE cluster within GCP. We will leverage Google Anthos Configuration Management for consistent deployment of Citrix components into the Anthos GKE cluster. VPX will act as a Tier 1 enterprise API gateway where WAF policies will be enabled. Tier 2 Citrix ADC (CPX) using ACM within a Kubernetes namespace that will act as a Tier 2 ingress API gateway for the microservices deployed in that namespace and make use of ACM for consistent Tier 2 API gateway policy configurations. Authentication, authorization, rate limiting, rewrite, and responder policies will be applied for a specific set of APIs. Keycloak, one of the most popular open source identity and access management (IAM) solutions, in a dedicated Kubernetes namespace and use it as our identity provider and authorization (OAuth 2.0) server for our Tier-2 CPX API Gateway. ACM (Anthos Configuration Management) is a GitOps-centric tool that synchronizes configuration into an Anthos Kubernetes cluster from a Git repository. This lab automation has been written with GitHub as the git repository tool of choice.
    The following diagram illustrates the infrastructure used by our Lab that will be deployed.

    Citrix ADC VPX
    A single Citrix ADC VPX instance is deployed with two network interfaces:
    nic0 provides access for management (NSIP), and access to back-end servers (SNIP). nic1 provides access for deployed applications (VIPs). Each interface is assigned an internal private IP address and an external public IP address. The instance is deployed as a pre-emptible node to reduce lab costs. The instance automatically configures the password with Terraform. The instance is then automatically configured by the Citrix Ingress Controller and Citrix Node Controller deployed in the GKE cluster. VPCs and Firewall Rules
    This deployment uses two VPCs:
    The default VPC and subnets are used for instance and GKE cluster deployment. The vip-vpc is used only to host VIP addresses, which routes the traffic back to the services in the default VPC. Default firewall rules apply to the default VPC. Ports 80/443 are permitted into the vip-vpc. GKE Cluster with Anthos Configuration Management
    A single GKE cluster is deployed as a zonal cluster:
    Autoscaling is enabled with a minimum of one node and a configurable maximum. Google Anthos Config Management (ACM) operator is deployed into the GKE cluster and configured to sync the cluster configuration from a GitHub repository. Citrix Ingress Controller and Citrix Node Controller components are automatically installed via ACM into the ctx-ingress namespace. Citrix auth, rate limit, rewrite and responder, and WAF CRDs are installed via ACM to enable developers to create policy configurations Keycloak with Postgresql database is installed via ACM into the keycloak namespace. Worker nodes are deployed as pre-emptible nodes to reduce lab costs. GitHub Repository
    A dedicated GitHub repository is created and loaded with a basic cluster configuration:
    A basic hierarchical format is used for ease of navigation through namespaces and manifests. Citrix Ingress Controller and Citrix Node Controller deployment manifests are built from templates and added to this repository, along with their other required roles / rolebindings / services / etc. This repository is created and destroyed by Terraform. Echoserver Demo Application
    An echoserver is a server that replicates the request sent by the client and sends it back. It will be used from our lab to showcase:
    How a request is blocked on Tier 1 VPX based on WAF policies. How a request is blocked on Tier 2 CPX based on Authentication / Authorization Policies. How a request is blocked on Tier 2 CPX based on Rate limiting policies when a threshold is reached. How a request is manipulated (by adding some extra headers) on Tier 2 CPX based on Rewrite policies. How a response is manipulated on Tier 2 CPX based on Responder policies. For our lab we will deploy a single echoserver instance to see the requests reaching our application and the relevant response. To keep it simple, three Kubernetes services will be created (Pet, User, Play) that will use different ports to access the same microservice (echoserver). That will provide us with an easy way of creating different content routes for each one of the Kubernetes services and showcase how we can apply policies to each API endpoint. Application components and API gateway configurations are controlled through Anthos Config Management and the source Git Repo. The following diagram illustrates a high-level architecture, aiming to present the role of each component for our Lab.

    To learn more about how to deploy this lab and see API gateway policies in action, please visit Citrix ADC with Google Anthos: Dual-tier API Gateway with ACM Lab in our Citrix Cloud Native Networking (CNN) hands-on guides.
    Additional Information
    Visit our Microservices App Delivery Best Practices library to learn how Citrix can help you on your app modernization journey.
    What is an API gateway? Learn about them here.
    For more information on dual-tier topology for the API gateway, check our API Gateway for Kubernetes documentation.
    Want to see how Citrix automates you API gateway configuration? Check our Deploy API Gateway with GitOps.
    Read our solution brief to find out how to protect your APIs with NetScaler ADC.
    Learn how to configure Citrix components for your specific requirements in our Developer Docs .
    For more details on why you need an application delivery controller (ADC) and a management and orchestration platform, read about six must-haves for application delivery in hybrid- and multi-cloud environments.
    For more on the role of application delivery in the cloud-native journey, read about seven key considerations for microservices-based application delivery.
    Finally, learn how Citrix ADC bridges the gap between traditional and DevOps app delivery in The ADC Guide to Managing Hybrid (IT and DevOps) Application Delivery
    What’s Next?
    Stay tuned for the next blog post in our series, where we will discuss how Citrix ADC’s security-as-code capabilities enable automation for East/West Security for Modern Apps.
    Looking to get started or take the next step in your app modernization? Our team is offering free consultations! Send an email to appmodernization@citrix.com to schedule your session or request a call and a specialist will reply with options to connect.
    Want to join our Citrix cloud-native Slack channel? Sign up now to receive an invitation.

    Farhan Ali
    The hybrid-cloud model is an effective way to align IT priorities with business needs, which are constantly changing. Citrix supports this by providing customers with choice in how they deploy and manage applications, whether they keep workloads on premises or shift business-critical apps to the cloud (or take a hybrid approach).
    Citrix ADC is validated to run on AWS Outposts and is a great option for your GSLB deployments. It works for both standalone and HA deployments, simplifying app delivery in hybrid-cloud environments with AWS. This enables improved availability for your critical apps, including in disaster recovery scenarios, and a better user experience.
    AWS Outposts is a fully managed service that offers the same AWS infrastructure, AWS services, APIs, and tools to virtually any datacenter, co-location space, or on-premises facility for a truly consistent hybrid experience. It’s ideal for workloads that require low latency access to on-prem systems, local data processing, data residency, and migration of apps with local system interdependencies.
    As organizations speed up digital transformation, many are finding they can move faster by using public cloud services to build on modern architectures and refresh legacy apps. Some workloads, however, must remain on premises due to technology, security, regulatory, or other requirements.
    Now, you can deploy your Citrix ADCs in the cloud and on premises via AWS and extend the AWS experience across your entire environment. Citrix ADC solutions in AWS Outposts and AWS cloud supports your disaster recovery initiatives and enables you to run apps in an on-premises environment and on AWS cloud together.
    With Citrix ADC as a validated partner product in AWS Outposts, Citrix customers get myriad benefits:
    Operational consistency across hybrid-cloud environments with AWS services, infrastructure, and operations for AWS cloud, on-prem Citrix ADCs, and AWS Outposts. Flexible pooled capacity licensing, which eases migration of apps to the cloud when the time is right for your organization. Better user experience, throughput, and apps availability with GSLB features like geo location, HTTP proxy, and active/passive deployments. GSLB balances the load across datacenters by directing client requests to the closest or best performing datacenter or to online datacenters if there’s an outage. A hybrid multi-cloud experience at your fingertips, with traffic flowing between your on-premises datacenter and the AWS cloud GSLB connects multiple Citrix ADCs, irrespective of their location, so you can deploy your Citrix ADC in multiple on-prem locations and clouds with full connectivity between them (and with site metrics). To take full advantage of the GSLB features, use Citrix ADC for load balancing or content switching at each datacenter so your GSLB configuration can use the proprietary MEP to exchange site metrics. The Citrix solution also includes Citrix Application Delivery Management (ADM), which enables you to manage your entire Citrix ADC infrastructure across your AWS environment and AWS Outposts, all with the same tools, from a single pane of glass. Citrix ADM also provides real-time insights into the status of your entire hybrid-cloud environment and helps you to resolve issues quicker, with proactive troubleshooting.
    With validation of Citrix ADC VPX in AWS Outposts, Citrix can provide ultimate choice and flexibility for your ADC deployment. Deliver a great user experience and security for your apps no matter how, or where, you deploy them.
    Learn more about AWS Outposts and Citrix ADC’s GSLB feature.

    Sridevi K N
    What is a sample dashboard?
    A sample dashboard is a collection of metrics related to a particular use case/scenario that allows you to visualize the metrics and analyse the scenario in a meaningful way within a short duration. With the sample dashboards, you can avoid looking at multiple metrics in different locations or files to analyse a particular scenario.
    Use Case
    Consider a scenario where you want to view the overall health of NetScaler in your network. To know the overall health, you need to view the data such as the total number of requests received by the virtual server, CPU utilization, currently used memory of NetScaler.
    Observability Sample Dashboard for NetScaler ADC  is one of many dashboards that NetScaler supports that provides you with visualisation of some key metrics that helps you determine the health of NetScaler in less time. 
    Supported endpoints: NetScaler provides sample dashboards for the following endpoints:
    Grafana Splunk For the list of sample dashboards that NetScaler supports and how to view them, refer the docs link here.

    Hitesh Mistry
    The growth in Internet of Things (IoT) devices has been tremendous over the last 10 years, with an estimated 10 billion to 15 billion IoT devices active as of 2022. Every major industry either actively uses or is considering using IoT technologies to better equip, deliver, manage, or monitor their solutions. Connected cars, smart home devices, smart warehousing, and human health monitoring are a few use cases for IoT, some of which are documented by the MQTT organization.
    There are several protocols to establish communication with IoT devices. At the application layer, Message Queue Telemetry Transport (MQTT), Advanced Message Queuing Protocol (AMQP), and Constrained Application Protocol (CoAP) are among the most common options. MQTT is the most popular solution for secure IoT data communication because of its reliability, fast response time, and support for a large number of devices. The MQTT protocol provides a publish/subscribe model where clients (IoT devices) connect to message brokers over a network to either publish or subscribe to information under specific topics.
    With many devices active at any given time, each generating data, and a system that enables many-to-many communication, scalability is often a major challenge. Citrix ADC can help unburden message brokers by evenly distributing the load and offload TLS operations from the broker servers while ensuring secure communication.
    In a typical IoT deployment, the broker (the cluster of servers) manages the group of IoT devices (the IoT clients). The Citrix ADC appliance load balances the MQTT traffic to the brokers based on various parameters, such as client ID, topic, and username.
    Deploy MQTT solutions with Citrix ADC Customers using Citrix ADCs for MQTT configurations can leverage its advanced features to build more scalable IoT solutions. Key benefits include:
    App Configuration: Customers can choose to configure an MQTT or MQTT_TLS vserver based on whether TLS operations need to be offloaded to Citrix ADC. Improved Security: With MQTT security based on message parameters, you can block malicious clients sending large messages to overload servers or large number of connections. Leverage Citrix ADC Policy Infrastructure: Advanced policy infrastructure enables you to make MQTT-aware decisions using policies and actions for MQTT-specific headers, types of connection, and quality of service (QoS) flags. File Store for Bulk Operations: As the number of devices increases, Citrix ADC provides a method (file store) to define lists of identifiers outside the ADC that can be referenced through an HTTP callout. You can then use policy definitions and actions to perform bulk operations based on these identifiers. Protocol-specific Logging: Citrix ADC can log MQTT-specific information at the application layer. App Visibility: Citrix ADC provides you with MQTT-aware application monitoring. Offload AAA Operations: You can offload authentication, authorization, and accounting (AAA) operations to the Citrix ADC. With such a wide range of options, Citrix ADCs can offer your organization a comprehensive solution to deploy and manage your MQTT app. Check out our Citrix ADC documentation for MQTT for details, and learn more about Citrix ADC.

    Hitesh Mistry
    Citrix ADCs support critical application infrastructure that is essential to operations at many organizations. The first five seconds of a web page load has a high impact on user experience and, ultimately, business revenue. Capabilities such as high availability and connection failover offer a layer of assurance that there will be no interruptions in your data flow and app delivery.
    By keeping your Citrix ADCs updated with the latest software, you get access to new features, critical security patches, and important bug fixes. However, when it comes to software upgrades for your Citrix ADC, admins need to plan accordingly to ensure there is no interruption to business continuity. Candidate software versions need to be tested, traffic patterns need to be analyzed for downtime, and IT teams must be available to ensure a successful upgrade.
    The new In-Service Software Upgrade (ISSU) for high availability for Citrix ADC pairs helps you upgrade to the latest software version without disrupting your apps. A high availability (HA) deployment of two Citrix ADC appliances can provide uninterrupted operation where one appliance is configured as the primary node and the other as the secondary or backup node.
    The primary node actively processes traffic while the secondary node monitors the primary and takes over (failover) if the primary node becomes unhealthy. When an HA pair needs upgrading, the secondary node is upgraded, a force failover is executed where the upgraded node takes over, and the remaining node is upgraded. This way, one node is always actively processing traffic, keeping the application alive.
    Upgrading a Citrix ADC HA pair For an HA pair to truly function to its fullest potential, both nodes must run the same version of the Citrix ADC software. Features such as connection failover only function in this format. During the upgrade process, there is a time right after upgrading the secondary node and prior to upgrading the remaining node when there is a version mismatch. When a failover occurs at this stage, all existing connections are lost, leading to downtime.
    This is where ISSU can help. It introduces a migration function that honors existing connections during the failover process, resulting in zero downtime. When the migration function is executed, the upgraded node (new primary) receives traffic for the existing connection but then steers it back to the node that was previously serving traffic for these connections (old primary). The old primary then processes the traffic and sends it to the destination.
    The migration is complete when all existing connections are closed. Then, a user can upgrade the remaining node. This migration step ensures that all active connections are fulfilled and results in a zero-loss upgrade process.
    The migration can be initiated from the UI or CLI, and its status can be monitored. SNMP traps are also supported to alert users when migration begins and completes. Information pertaining to the respective sessions can be viewed as well. The ISSU statistics displays the following information:
    Current status of ISSU migration operation Start time of the ISSU migration operation End time of the ISSU migration operation Start time of the ISSU rollback operation Total number of connections that are processed as part of ISSU migration operation Number of remaining connections that are being processed as part of ISSU migration operation Information on connections that were migrated. If an end user sees issues after the upgrade or has concerns regarding the health of the system, the admin can always rollback using the ISSU rollback capability. The rollback stops the migration process and triggers a failover on the node now processing new connections. The system is brought back to the state before the initial migration began.
    Even during the rollback, the system honors all connections — old and new — and continues to process them. A user with an active connection prior to or during the upgrade will not experience disruption, regardless of whether the upgrade was successful or unsuccessful. It’s a truly transparent experience for the end user.
    Check out our product documentation for more information and a detailed walkthrough on the new ISSU capability.

    Sunit Chauhan
    A zero-day exploit affecting the Apache Log4j version from 2.0-beta9 to 2.14.1 was made public on December 9, 2021, as to which JNDI features used in the configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI-related endpoints. As a result, an attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
    Citrix recommends that customers follow Apache’s recommendations. In addition, Citrix Web App Firewall (WAF) customers should consider the following recommendations to improve the security of their applications from this vulnerability.
    Citrix research team has released updated Citrix WAF signatures designed to mitigate in part the CVE-2021-44228 vulnerability. If you are using any of these Log4j versions (from 2.0-beta9 to 2.14.1), Citrix strongly recommends that you download the signatures version 73 and apply to your Citrix WAF deployments as an additional layer of protection for your applications. Signatures are compatible with the following software versions of Citrix Application Delivery Controller (ADC) 11.1, 12.0, 12.1, 13.0 and 13.1. Please note, version 12.0 is End of Life. Learn more about the release life cycle at https://www.citrix.com/support/product-lifecycle/product-matrix.html.
    If you are already using Citrix WAF with signatures with auto-update feature enabled, you may follow these steps after verifying that the signature version is at least version 73.
    Search your signatures for CVE-2021-44228 LogString. Select the results. Choose “Enable Rules” and click OK. Click image to view larger. Citrix ADC Standard and Advanced edition customers, as well as Premium edition customers who do not have WAF signatures enabled, can use responder policies for protection as shown below. Please bind the responder policy to the appropriate bind point (vserver or global).
     
    add policy patset patset_cve_2021_44228 bind policy patset patset_cve_2021_44228 ldap bind policy patset patset_cve_2021_44228 http bind policy patset patset_cve_2021_44228 https bind policy patset patset_cve_2021_44228 ldaps bind policy patset patset_cve_2021_44228 rmi bind policy patset patset_cve_2021_44228 dns add responder policy mitigate_cve_2021_44228 q^HTTP.REQ.FULL_HEADER.SET_TEXT_MODE(URLENCODED).DECODE_USING_TEXT_MODE.AFTER_STR("${").BEFORE_STR("}").CONTAINS("${") || HTTP.REQ.FULL_HEADER.SET_TEXT_MODE(URLENCODED).DECODE_USING_TEXT_MODE.SET_TEXT_MODE(IGNORECASE).STRIP_CHARS("${: }/+").AFTER_STR("jndi").CONTAINS_ANY("patset_cve_2021_44228") || HTTP.REQ.BODY(8192).SET_TEXT_MODE(URLENCODED).DECODE_USING_TEXT_MODE.AFTER_STR("${").BEFORE_STR("}").CONTAINS("${") || HTTP.REQ.BODY(8192).SET_TEXT_MODE(URLENCODED).DECODE_USING_TEXT_MODE.SET_TEXT_MODE(IGNORECASE).STRIP_CHARS("${: }/+").AFTER_STR("jndi").CONTAINS_ANY("patset_cve_2021_44228")^ DROP  
    Citrix recommends Citrix WAF customers to use the latest signature version, enable signatures auto-update and subscribe to receive signature alert notifications. Citrix will continue to monitor this dynamic situation and update as new mitigations become available.
    Update 1 (December 15, 2021)
    If any of your application availability is inadvertently impacted due to false positives resulting from above mentioned mitigation policies, Citrix recommends the following modifications to the policy. Please note that any end point covered by the exception_list may expose those assets to the risks from CVE-2021-44228.
    Modifications to Responder Policy  
    add policy patset exception_list # (Example: bind policy patset exception_list "/exception_url") set responder policy mitigate_exploit_cve_2021_44228 -rule q^HTTP.REQ.URL.CONTAINS_ANY("exception_list").NOT && (HTTP.REQ.FULL_HEADER.SET_TEXT_MODE(URLENCODED).DECODE_USING_TEXT_MODE.AFTER_STR("${").BEFORE_STR("}").CONTAINS("${") || HTTP.REQ.FULL_HEADER.SET_TEXT_MODE(URLENCODED).DECODE_USING_TEXT_MODE.SET_TEXT_MODE(IGNORECASE).STRIP_CHARS("${: }/+").AFTER_STR("jndi").CONTAINS_ANY("patset_cve_2021_44228") || HTTP.REQ.BODY(8192).SET_TEXT_MODE(URLENCODED).DECODE_USING_TEXT_MODE.AFTER_STR("${").BEFORE_STR("}").CONTAINS("${") || HTTP.REQ.BODY(8192).SET_TEXT_MODE(URLENCODED).DECODE_USING_TEXT_MODE.SET_TEXT_MODE(IGNORECASE).STRIP_CHARS("${: }/+").AFTER_STR("jndi").CONTAINS_ANY("patset_cve_2021_44228"))^  
    Modifications to WAF Policy  
    add policy patset exception_list # (Example: bind policy patset exception_list "/exception_url") Prepend the existing WAF policy with HTTP.REQ.URL.CONTAINS_ANY("exception_list").NOT # (Example :  set appfw policy my_WAF_policy q^HTTP.REQ.URL.CONTAINS_ANY("exception_list").NOT && <existing rule>^  
    Update 2 (December 15, 2021)
    A second Log4j vulnerability was reported on December 14 — CVE-2021-45046 — rated 3.7 out of a maximum of 10 on the CVSS rating system and affects all versions of Log4j from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0.
    Citrix recommendations for CVE-2021-44228 with WAF Signatures version 73 and Responder policies, will also mitigate the CVE-2021-45046 vulnerability.
    Update 3 (December 19, 2021)
    Another Log4j vulnerability was reported on December 18 (CVE-2021-45105) that affects Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3).
    Citrix recommendations for CVE-2021-44228/CVE-2021-45046 with WAF Signatures version 73 and Responder policies will also mitigate the CVE-2021-45105 vulnerability exploits.
    Update 4 (December 24, 2021)
    The Cybersecurity and Infrastructure Security Agency (CISA) has announced the release of a scanner for identifying web services impacted by two Apache Log4j remote code execution vulnerabilities, tracked as CVE-2021-44228 and CVE-2021-45046.
    Citrix recommendations for CVE-2021-44228/CVE-2021-45046/CVE-2021-45105 with WAF Signatures version 73 and Responder policies have been validated against the above mentioned CISA Apache Scanner to mitigate vulnerability exploits.
    The current WAF signatures version 74 includes regular updates not related to Log4j vulnerabilities.
    Update 5 (February 9, 2022)
    Another critical Log4j vulnerability with score 9.8 was reported on January 18th  - CVE-2022-23305 that affects Log4j versions from 1.2 to 1.2.17.

    Citrix recommends to enable SQL Injection Protection in WAF configuration to mitigate the CVE-2022-23305 vulnerability exploits. For customers on software release versions 13.0 and 13.1 Citrix recommends to enable SQL Grammar-based protection. 
    Please note, an ADC firmware upgrade is not required for any of the above mentioned Log4j mitigations. However, if for any other reason a new ADC build is needed, please use the following latest builds – 13.1.12.51, 13.0.84.11 or 12.1.63.24. In case any older build is installed post creating the protection with WAF signatures, please update WAF signatures to the latest version and ensure that the required signatures are enabled.
    Citrix will continue to update this advisory for CVE-2021-45105 as additional information becomes available.
    Additional Information
    Citrix WAF has a single code base across physical, virtual, bare-metal, and containers that brings consistency to your deployment model. This signature update applies to all form factors and deployment models of Citrix WAF.
    To learn more about Citrix Web App Firewall, see https://docs.citrix.com/en-us/citrix-adc/current-release/application-firewall/introduction-to-citrix-web-app-firewall.html.
    To learn more about Citrix Web App Firewall signature, check out our alert articles and bot signature articles.
    To learn about the signature alert notification, go to https://docs.citrix.com/en-us/citrix-adc/current-release/application-firewall/signature-alerts/how-to-receive-signature-alert.html.
    Patches and Mitigations
    Citrix strongly recommends that customers consider the security guidance from vendors of other products that they may have deployed. Until a patch is made available, you may reduce the risk of a successful attack by applying mitigations. Mitigations should not be considered full solutions as they do not fully address the underlying issue(s).

×
×
  • Create New...