Jump to content

  • Articles

    Show all categories
    Priyanka Yadav
    NetScaler File Integrity Monitoring 
     NetScalerⓇ has introduced a new feature within Application Delivery Management (ADM) Service called File Integrity Monitoring that will help you determine if changes have been made to your NetScaler build files.
    The challenge: Unapproved changes in your NetScaler build files
    Even when you take all precautions to prevent unapproved changes to the core build files for NetScaler, subtle manipulation of these files can go unnoticed, allowing attackers to operate undetected.

    Compounding this problem is the sheer volume of files within NetScaler. Monitoring each of these files for changes manually is an enormous task, prone to error, and often insufficient for detecting subtle or rapid alterations. Even with existing security measures in place, the dynamic nature of cyber threats demands a more proactive approach to identifying unauthorized modifications to your NetScaler build files.
    NetScalerⓇ File Integrity Monitoring provides you with valuable insights that help you manage this risk.
    The response: NetScaler File Integrity Monitoring
    NetScaler File Integrity Monitoring proactively identifies any changes in the very core of your NetScaler ADCs — the build files.
    How it works: 
    NetScaler File Integrity Monitoring examines the integrity of your NetScaler build files. Think of it as a digital fingerprint: NetScaler will compare the binary hash value of your current NetScaler build against the original binary hash linked to the same NetScaler build. Discrepancies in the NetScaler build files identified by this feature will be flagged for your attention.
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_08/image.jpg.d4e4d5cc7fc956162ef319ba172e407c.jpg" data-ratio="41.68" width="1526" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">

    1. On-demand scan: Run file integrity scans as needed. 
     
    2. Reliable comparisons: NetScaler ADM stores the original binary hashes of files across all NetScaler build releases and compares them against your existing NetScaler files. Any detected deviation raises a red flag for further investigation. Please proceed with your organization's digital forensics procedure if you see any changes.
     
    3. File altered and file added: File Integrity Monitoring helps detect changes in the existing NetScaler build files as well as files added to your NetScaler build. 
    How to use File Integrity Monitoring
    Go to the Security Advisory section of the NetScaler Application Delivery Management dashboard, click the File Integrity Monitoring tab, and run an on-demand scan:
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_08/image.jpg.ef626e59156072717c15a06bdb5652d6.jpg" data-ratio="25.53" width="940" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">


    You can view the identified NetScaler ADCs and the list of files that were changed or added:
     
    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_08/image.jpg.fa3acd2c46127c744ba1916370842c11.jpg" data-ratio="47.66" width="940" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">


    Click the existing files that were modified or on the newly added files to see the impacted file names:
     
    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_08/image.jpg.ba886f810f81435e94926f450f733a3f.jpg" data-ratio="46.6" width="940" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_08/image.jpg.1aa6f41dd027b2f5f2af69654665c893.jpg" data-ratio="50.43" width="940" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     This proactive approach will help you detect file changes early so you can take immediate action to secure your NetScaler ADCs. 

    To learn more about NetScaler File Integrity Monitoring, refer to the documentation.
    Note that File Integrity Monitoring is available only with the cloud-hosted NetScaler Application Delivery Management (ADM) Service. If you do not yet have access to NetScaler ADM Service, get started today.
     DISCLAIMER
     
    Please note that NetScaler File Integrity Monitoring (“the Feature”) is not capable of detecting all techniques, tactics, or procedures (TTPs) threat actors may use when targeting relevant environments. Threat actors change TTPs and infrastructure frequently, and therefore the Feature may be of limited to no forensic value as to certain threats. You are strongly advised to retain the services of experienced forensic investigators to assess your environment in connection with any possible threat. 
    This document and the information contained in it is provided as-is. Cloud Software Group, Inc. makes no warranties or representations, whether express or implied, regarding the document or its contents, including, without limitation, that this document or the information contained in it, is error-free or meets any conditions of merchantability or fitness for a particular purpose.           
    Sridevi K N
    We’re excited to inform you that the recently launched NetScaler version 14.1 is packed with many new features and enhancements that we believe will be highly beneficial for you. Take a look at some of the key highlights.
    Security
    Improved protection against TCP spoofing attacks - To strengthen the protection against TCP spoofing attacks, NetScaler is compliant with RFC-5961. With this compliance, NetScaler provides the following capabilities in addition to RST window attenuation and SYN spoof protection: Reduces the probability of invalid data injection. Allows imposing a limit on the number of challenge ACK responses per second sent by the NetScaler. Rate limiting SSL renegotiations - Limits the number of renegotiation requests received on an SSL entity in one second. Store Authentication Context Class Reference values - NetScaler configured as an on-premises IdP can store Authentication Context Class Reference (ACR) values provided by Citrix Workspace to support the Citrix multi-domain login feature of Citrix Workspace Platform. When Citrix Workspace sends the ACR values to the OAuth authorization endpoint of the NetScaler IdP, NetScaler stores the ACR values. You can use ACR values to determine the next factor in the nFactor flow. Observability
    Splunk integration - Export the events generated on NetScaler to Splunk, and use the Splunk dashboard to visualize the exported data to get meaningful insights. Compressed core dumps for NetScaler BLX - NetScaler BLX generates compressed core dumps if the core-dumps parameter is enabled in the NetScaler BLX configuration file (blx.conf). Support for an extended StoreFront monitor - Supports extended StoreFront monitor that can simulate the authentication and app enumeration on the Citrix StoreFront store on behalf of a test user account. This account is pre-cofigured and enabled for the purpose of monitoring. Performance
    Backup VPX partitions - You can now back up and restore the following properties of VPX partitions during the backup and restore of NetScaler SDX. Responder file Partition MACs TLS 1.3 protocol support on back-end services, service groups, and monitors - Back-end services, service groups, and monitors now support the TLS 1.3 protocol when connecting to back-end servers. Versatility
    View SSL rating of an application - You can review SSL issues and upgrade the application to obtain an A+ rating. Web Insights You can now understand the percentage distribution received based on the total requests for the selected duration for the following metrics: Clients Servers Geo Locations URLs You can drill down any metric and also export the required data from any widget. An administrator can view the complete graph, including the nil values. Earlier nil values were skipped in the graph. Stylebooks The "replace ()" built-in function can also accept the list of the following built-in types: "String" "ipaddress" "tcp-port" "number" "boolean" The built-in functions support the multiple () function. As an administrator, you can restrict user groups from accessing configuration packs created by other user groups. Infrastructure
    NetScaler SDX 9100 license enhancements A new license limit of 60G. The license limit is increased from 30G to 95G.
    To know more about the NetScaler 14.1-4.x release enhancements, see ADC Release Notes and ADM Release Notes.
    Steven Wright
    NetScalers are used by some of the world's largest service providers to handle inbound application traffic. In this article, I will show how you can deploy an NetScaler environment that will scale to millions of HTTP requests and SSL handshakes per second. In the next, I will show you how to automate that environment with a basic introduction to Terraform.
     
    The suggested architecture will allow for multiple datacenters. In addition, it will provide load balancing, SSL offload, and the capability to secure and optimize your web application traffic. The architecture will also be scalable and fully automatable.
     
    We will begin by reviewing technologies to get traffic to your datacenter, how to distribute that traffic across NetScalers once it arrives, and how you can configure your NetScalers with code using in-house deployment scripts.
     
    Assuming you have sized the rest of your environment appropriately, this design should allow you to process around 100 million HTTP requests per second at each datacenter. However, the layout is scalable and can be used for smaller implementations without significant changes.
     
      Directing users to their most appropriate datacenter
    Historically, there have been two approaches to directing users to their closest datacenter: dynamic routing (anycast) and GSLB.
     
     
    Dynamic routing (anycast)
    With the dynamic routing / anycast approach, the routers at each datacenter announce the same IP ranges and rely on the Internet's routing protocol (BGP) to take the shortest path. The approach operates on the assumption that a British user will have a shorter path to your British datacenter and your American user to an American datacenter. The method also assumes that a short path will be the best route.
     
    The concept is illustrated in simplistic terms in the diagram below. Users, sending traffic to their ISP, will have that traffic forwarded to the datacenter that is the smallest number of hops away.
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_08/image.jpg.5297f77afd663ad75f92dff56168d667.jpg" data-ratio="44.59" width="628" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
    LinkedIn's engineering team wrote an excellent article on this topic some years ago, which is well worth reading. They found that global anycast showed cross-continent problems but was good when used within a continent. 
     
    Their recommendation was to use DNS to return an IP address within the user's continent and to use anycast within each region. Users would perform a DNS lookup and be directed to the best continent to service their request. If you had multiple datacenters in that continent, these would share the same IP addresses using anycast, and users would then take the shortest path.  
     
     
    GSLB (Global Server Load Balancing) / CADS Service (Citrix Application Delivery and Security Service)
    GSLB, Global Server Load Balancing, is a DNS based technology used to direct users to datacenters. Administrators commonly configure GSLB to ensure users receive the IP address of a datacenter in their region (or a redundant location if they are not using anycast). 
     
    NetScaler fully supports GSLB, and you can read about configuring it here. However, GSLB configurations are often simplistic as they rely on relatively few data points. 
     
    CADS Service (Citrix Application Delivery and Security Service) includes a feature known as ATM (Intelligent Traffic Management), which is the next generation of GSLB and an "Internet Aware" SaaS offering.
    While GSLB only takes metrics from your locations, CADS also allows you to integrate the radar tag into your website and collect metrics from end-users.
     
    To highlight the difference, if there were a problem at a regional ISP entirely separate from your environment, a GSLB configuration would examine metrics from your datacenters, conclude everything was healthy, and take no action. In contrast, ITM would see that users from the regional ISP are unable to reach your datacenter and immediately redirect them to a more performant location.
     
    If you intend to deploy without anycast, CADS is a must-have capability to detect and avoid connectivity issues between your users and datacenters. However, with anycast, CADS remains of significant benefit as it operates on objective user metrics to direct users to the location that provides the best possible service, avoiding both intercontinental link issues that LinkedIn wrote about and temporary connectivity problems.
     
    In this solution, we will assume that you have implemented anycast within each region and are using CADS’s ITM feature to ensure DNS sends users to the region where they receive the lowest latency and the fastest application response.

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_08/image.jpg.111f9b3e0e05fa4dca6f59cc18a5cbe0.jpg" data-ratio="55.58" width="806" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    A standardized repeatable design at each datacenter
    With traffic now arriving at the most appropriate datacenter, we can focus on handling the resultant traffic.  
     
    We will design each datacenter to operate with a standardized design so that it's simple and easy to update and maintain.
     
    We will use physical hardware NetScalers known as "MPXs" for their high performance. However, our design is equally suitable for virtual NetScalers "VPX" if you favor a complete infrastructure-as-code approach.
     
    In our design, traffic (directed by CADS) will enter the network at the router/firewall. The router will then distribute these inbound connections to our NetScalers.
     
    Next, the NetScalers will terminate the connections, process the requests, and deliver them to backend servers.
     
    Finally, the servers will service the requests, potentially using local data or a storage solution replicated between your datacenters.
     
    All of the configuration will be automated using Terraform (covered in the next article). However, the use of Terraform is a personal preference, and NetScaler also supports a range of other automation technologies, such as:
    Ansible Citrix ADM Service Nitro REST API to allow for custom scripts. We assume you have appropriately sized your routers, firewalls, and storage. And you have ensured your storage is replicated between datacenters if your servers so require. This article shows a single router as a simplification.
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_08/image.jpg.41f25b29c276a8e06aa0eedf7848b701.jpg" data-ratio="130.94" width="446" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Splitting traffic within the datacenter
    Within the datacenter, the router/firewall will divide connections between our NetScalers using dynamic routing.  We will be automating the configuration in the next article but, it would be helpful to first understand how this could be achieved manually.
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_08/image.jpg.63ceac6ab1bfeb5fb56d0a9f6ec48d9d.jpg" data-ratio="56.07" width="428" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
    In our dynamic routing configuration, each NetScalers "announces" the IP addresses of the virtual servers (vServers) they host to the router. As each NetScaler will host vServers with the same IP addresses, the router will distribute the inbound connections between the NetScalers.
     
    On a Cisco router, the distribution of traffic between OSPF neighbors will likely occur in hardware using a technology known as CEF, Cisco Express Forwarding, to reduce the impact on CPU. You must take care to ensure your router has sufficient resources to handle the distribution.
     
    Additionally, to ensure all packets from a user are directed to the same NetScaler, you should consult your routers manual to ensure it is using per-destination load-sharing, which is the default on a Cisco router.
     
    To implement our dynamic routing configuration, we first need to configure our router to have an OSFP neighbor relationship with the NetScalers. On a Cisco router, a very simplistic OSPF configuration would look as follows:
     
    enable router# config t
    router(config)# router ospf 100
    router(config-router)# network 192.168.1.0 0.0.0.255 area 0
    router(config-router)# maximum-paths 16
    router(config-router)# end
    After we enter the "network 192.168.1.0 0.0.0.255 area 0" command, our router will enable OSPF on all of its interface addresses within that network range.
     
    Next, on our NetScalers, we need to enable the OSPF routing facility with the command "enable ns feature ospf".After enabling OSPF, we can configure the NetScaler's included routing platform known as "ZebOS", by entering the command "vtysh".
     
    The ZebOS configuration on each NetScaler would look as follows:
     
    NetScaler# config terminal NetScaler(config)# router ospf
    NetScaler(config-router)# network 192.168.1.0/24 area 0
    NetScaler(config-router)# redistribute kernel
    With the OSPF configuration created, we can tell each NetScaler to advertise the IP address of a vServer (such Load Balancing vServer) using the following command:
     
    set ns ip 10.0.0.10 255.255.255.255 -hostroute ENABLED -vserverRHILevel ALL_VSERVERS This command will tell the NetScaler to announce the IP address 10.0.0.10 to the router.
     
     
    With each of our NetScalers now announcing itself to our router as a path to the Load Balancing vServer, the router will distribute inbound traffic to each of the NetScalers.
     
    After enabling OSPF, you can validate communication between the NetScalers and router using the following commands on the router. Here, we can see three NetScalers on "192.168.1.10", "1.11", and "1.12" advertising the LB vServer on "10.0.0.10".
     
    R1# sh ip ospf | s 10.0.0.10 > 10.0.0.10/32, Intra, cost 1, area 0
      via 192.168.1.10, GigabitEthernet1.1
      via 192.168.1.11, GigabitEthernet1.2
      via 192.168.1.12, GigabitEthernet1.3
    R1# sh ip cef 10.0.0.1 detail
    10.0.0.1/32, epoch 0, per-destination sharing
      nexthop 192.168.1.10 GigabitEthernet1.1
      nexthop 192.168.1.11 GigabitEthernet1.2
      nexthop 192.168.1.12 GigabitEthernet1.3
    We have used a relatively simplistic configuration with a single router and each NetScaler acting as an OSPF path. As routers are generally limited to 16 OSPF paths, this design will likely be limited to 16 NetScalers.  More advanced implementations will be able to expand on this simple design.
     
    16 low-end appliances (such as the MPX9130) will equate to around 33 million L7 HTTP requests per second. Using high-end appliances (such as the MPX26200-50S), this design should service over 100 million L7 requests/sec at each datacenter.
     
    Note: You will have multiple routers in a production environment to meet redundancy and throughput requirements and may need to work with your network team to adjust the proposed configuration.
     
     
     
    Testing
    To test, our configuration, we will configure each NetScaler to return a different colored web page. The colors will make it immediately apparent which NetScaler is servicing our traffic.
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_08/image.jpg.f61a8ac323f8f95d5335f023e60872c4.jpg" data-ratio="80.57" width="422" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
    To return the colored web page, we need to add the green, blue, or purple responder policy to each of our NetScalers and bind it to the LB vServer.
     
    #NetScaler 1 add responder action Green_Responder_Act respondwith q{"HTTP/1.1 200 OKrnrn<html><body><p style="background-color:#78c445;">Green NetScaler</p></body></html>n"}
    add responder policy Green_Responder_Pol true Green_Responder_Act
    bind lb vserver LB_vServer -policyName Green_Responder_Pol -priority 1 -gotoPriorityExpression END -type REQUEST
     
    # NetScaler 2
    add responder action Blue_Responder_Act respondwith q{"HTTP/1.1 200 OKrnrn<html><body><p style="background-color:#00c9cc;">Green NetScaler</p></body></html>n"}
    add responder policy Blue_Responder_Pol true Blue_Responder_Act
    bind lb vserver LB_vServer -policyName Green_Responder_Pol -priority 1 -gotoPriorityExpression END -type REQUEST
     
    # NetScaler 3
    add responder action Purple_Responder_Act respondwith q{"HTTP/1.1 200 OKrnrn<html><body><p style="background-color:#a87bd9;">Purple NetScaler</p></body></html>n"}
    add responder policy Green_Responder_Pol true Purple_Responder_Act
    bind lb vserver LB_vServer -policyName Green_Responder_Pol -priority 1 -gotoPriorityExpression END -type REQUEST
     
    With the responder rules now added we can test traffic from different locations before removing the responder to restore usual service.
     
     
     
    Next steps
    We have seen how to create a scalable NetScaler solution that allows for multiple datacenters, scales to 100M L7 requests/sec at each, and supports both physical and virtual NetScalers.
     
    In the next article, we will explore how to automate the design using Terraform.
     
     
       
    Isha Khurana
    Announcing the General Availability of NetScaler App Delivery and Security service for workloads in Azure
     
    Author: Chris Chau , Isha Khurana
     
    Today I am excited to announce the general availability (GA) of the NetScaler App Delivery and Security service (ADS service) support for Azure workloads.  App Delivery and Security service is the industry’s first intent-based, continuously optimising, self-healing, internet-aware application delivery service and this GA marks the anchor for App Delivery and Security service service to support hybrid multi-cloud workloads across on-premises/private clouds, and also AWS and Azure clouds.
     
    App Delivery and Security (ADS) service embarked its journey on 5th April 2022 when the service was generally available for AWS cloud workloads and Multi-Site/Internet facing Apps. Since then the customers resonate with the value it creates. I would like to take this as an opportunity to share below testimonial from the customer: 
    “Within a week of App Delivery and Security service's deployment, customer observed a DDoS attack that did not reach data center because it is scrubbed by App Delivery and Security service”
     
    Over the one-year of App Delivery and Security service journey, customers leveraged the ADS service and shared their requirements. The NetScaler team has added a lot of features and supports multiple deployment architectures based on customer requirements. For more info on the list of new features below explore this  link.
     
    Get started with App Delivery and Security service with your hybrid multi cloud workloads ( AWS, Azure) today by logging into your cloud.citrix.com account and click "Request Trial" on App Delivery and Security tile.
     

     
     
    Disclaimer: The development, release and timing of any features or functionality described for our products remains at our sole discretion and are subject to change without notice or consultation. The information provided is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making purchasing decisions or incorporated into any contract.
    NetScaler Cyber Threat Intelligence
    NetScaler WAF mitigates risk from Zimbra XSS vulnerability 
     
    NetScaler has new signatures available for its integrated Web App Firewall to help customers mitigate the recent critical cross site scripting vulnerability in Zimbra Collaboration Suite (ZCS) v.8.8.15, Zimbra Classic Web Client version 8 before 8.8.15 Patch 41 and Zimbra Collaboration ZCS v.8.8.15 and v.9.0 . 
    The new signatures protect customers from the recent CVE-2023-34192, CVE-2023-29382, CVE-2023-37580 vulnerabilities that allow XSS and arbitrary code execution.
    The aforementioned vulnerabilities are classed as critical. Customers should apply the latest NetScaler WAF signature file to help mitigate exploitation of this vulnerability in their environments.You can download the signatures and apply them immediately.  
    Mitigations:
    CVE-2023-34192
    The NIST database has details about the vulnerability:
     Cross Site Scripting vulnerability in Zimbra ZCS v.8.8.15 allows a remote authenticated attacker to execute arbitrary code via a crafted script to the /h/autoSaveDraft function.
    CVE-2023-29382
    The NIST database has details about the vulnerability:
     An issue in Zimbra Collaboration ZCS v.8.8.15 and v.9.0 allows an attacker to execute arbitrary code via the sfdc_preauth.jsp component.
    CVE-2023-37580
    The NIST database has details about the vulnerability:
     Zimbra Collaboration (ZCS) 8 before 8.8.15 Patch 41 allows XSS in the Zimbra Classic Web Client.
     The vendor (Zimbra) recommends that users of Zimbra Collaboration Suite Version 8.8.15 immediately adhere to their published mitigation measures and apply the appropriate patch to the software in order to prevent exploitation of these vulnerabilities. 
     NetScaler customers can quickly implement the  following recommendations to help reduce risk and lower exposure associated with this vulnerability. If you are using any of the affected MOVEit Transfer  versions, NetScaler strongly recommends that you download the version 111 or later of the signature file and apply it to your NetScaler Web App Firewall deployments as an additional layer of protection for your applications.  Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: software versions 11.1 and 12.0 are end of life and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
    Signature rule
    CVE ID
    Description
    998641
    CVE-2023-37580
    WEB-MISC Zimbra Collaboration Suite Multiple Versions - XSS Vulnerability (CVE-2023-37580)
    998644
    CVE-2023-34192
    WEB-MISC Zimbra Collaboration Suite Multiple Versions - XSS Vulnerability (CVE-2023-34192)
    998645
    CVE-2023-29282
    WEB-MISC Zimbra Collaboration Suite Multiple Versions - RCE Via sfdc_preauth.jsp (CVE-2023-29382)
     
    If you are already using NetScaler Web App Firewall with the signature auto-update feature enabled, verify that your signature file version is 111 or later and then follow these steps.
    Search your signatures for CVE-2023-37580, CVE-2023-34192, CVE-2023-29382 LogString Select the results with ID  Choose “Enable Rules” and click OK  
    NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. NetScaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
    Handling false positives
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
    Modifications to NetScaler Web App Firewall 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>^
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks from CVE-2023-37580, CVE-2023-34192, CVE-2023-29382.
    Additional Information
    NetScaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of NetScaler Web App Firewall.
    Learn more about NetScaler Web app Firewall, read our alert articles and bot signature articles to learn more about NetScaler WAF signatures, and find out how you can receive signature alert notifications.
    Please join the NetScaler Community today and engage with your peers to learn more about how they are protecting their businesses with NetScaler WAF. 
     
     
    NetScaler Cyber Threat Intelligence
    NetScaler WAF mitigates risk from Ivanti Remote Unauthenticated API access vulnerabilities
     
    NetScaler has new signatures available for its integrated Web App Firewall to help customers mitigate the vulnerabilities related to Ivanti Endpoint Manager Mobile (Core) affecting versions 11.2 and prior.
    The new signatures protect customers from the recent CVE-2023-35078 and CVE-2023-35082 vulnerability found in versions of Ivanti Endpoint Manager Mobile (Core) that allows unauthorized access to users’ personally identifiable information and limited changes to the server. 
    The vulnerability (CVE-2023-35078) is classed as critical. Customers should apply the latest NetScaler WAF signature file to help mitigate exploitation of this vulnerability in their environments.You can download the signatures and apply them immediately.  
    Mitigating CVE-2023-35078
    The NIST database has details about the vulnerability:
     Ivanti Endpoint Manager Mobile (EPMM), formerly MobileIron Core, through 11.10 allows remote attackers to obtain PII, add an administrative account, and change the configuration because of an authentication bypass, as exploited in the wild in July 2023. A patch is available.
     
    Ivanti Endpoint Manager Mobile (EPMM), formerly known as MobileIron Core, recommends that customers refer to their published remediation measures
     NetScaler customers can quickly implement the  following recommendations to help reduce risk and lower exposure associated with this vulnerability. If you are using any of the affected Ivanti Endpoint Manager Mobile  versions, NetScaler strongly recommends that you download the version 111 or later of the signature file and apply it to your NetScaler Web App Firewall deployments as an additional layer of protection for your applications.  Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: software versions 11.1 and 12.0 are end of life and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
     
     
    Signature rule
    CVE ID
    Description
    998642
    CVE-2023-35082
    WEB-MISC MobileIron Core (Ivanti EPMM) prior to 11.2 - Authentication Bypass (CVE-2023-35082)
    998643
    CVE-2023-35078
    WEB-MISC Ivanti EndPoint Manager Mobile - Authentication Bypass (CVE-2023-35078)
     
    If you are already using NetScaler Web App Firewall with the signature auto-update feature enabled, verify that your signature file version is 111 or later and then follow these steps.
    Search your signatures for CVE-2023-35078, CVE-2023-35082 LogString Select the results with ID  Choose “Enable Rules” and click OK  
    NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. NetScaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
    Handling false positives
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
    Modifications to NetScaler Web App Firewall 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>^
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks from CVE-2023-35078, CVE-2023-35082.
    Additional Information
    NetScaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of NetScaler Web App Firewall.
    Learn more about NetScaler Web app Firewall, read our alert articles and bot signature articles to learn more about NetScaler WAF signatures, and find out how you can receive signature alert notifications.
    Please join the NetScaler Community today and engage with your peers to learn more about how they are protecting their businesses with NetScaler WAF. 
     
     
    NetScaler Cyber Threat Intelligence
    NetScaler’s CTRI Team on Zimbra and Ivanti vulnerabilities (Update #2 - Signatures published)
     
    NetScaler’s CTRI Team is aware of the below recent vulnerabilities shared by CISA:
    Ivanti Endpoint Manager Mobile (EPMM) and more specifically CVE-2023-35081 and CVE-2023-35078
    Zimbra Collaboration (ZCS)   with CVE-2023-34192, CVE-2023-29382 and CVE-2023-37580
     Please find follow the links for more details on Zimbra  and Ivanti CVEs and signatures
     
     
    Guest
    NetScaler ADC Admin Partitions Validated Reference Design Part 1
    September 12, 2022
     
    Continued in Part 2
    Author:  Luis Ugarte, Beth Pollack
    Feature overview
    Citrix ADC Admin Partitions enables multi-tenancy at the software level in a single Citrix ADC instance. Each partition has its own control plane and network plane.
    The key benefits of Admin Partitions are:
    Control Plane – Isolated configuration and management Data Plane – Key partition data and files tightly controlled within partition boundary Network plane – Traffic is isolated with its own network configuration. Two partitions on same Citrix ADC do not see the same traffic passing through each partition This document covers the typical use cases in detail that are enabled by Admin Partitions and guidelines for using Admin Partitions in customer environment.
    Admin partitions use cases
    Enterprise use case for admin partitions
    Citrix ADC admins can partition a Citrix ADC into multiple ADCs and assign the partitions to different application administrators like Microsoft SharePoint and Microsoft Lync. Each application administrator/owner can make his own configuration changes.
    IP overlapping: The key benefit of IP Overlapping is that the same IP range can be used across different Admin Partitions without any IP conflict. For the backend servers, you can use the same set of private IP address. In an IP Overlapping scenario, the VLANs cannot be shared.
    Virtual routing: Routing configuration is unique to each partition and each partition owner can configure their own routing protocols.
    Name space isolation: Entity names are unique across different partitions, so you can use the same names across different Admin Partition.
    Reference diagram:
    Single Nic – Multiple Vlans

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.0b33459b40c143693b4dc5fc87534d62.jpg" data-ratio="56.25" width="960" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
    IP overlapping:

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.5208910df3f9614fb307895917bfce52.jpg" data-ratio="56.25" width="960" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
    Service provider use case for admin partitions
    Service Providers can partition a Citrix ADC and assign it to individual clients based on their bandwidth requirements and number of concurrent connections.
    Service Providers can develop orchestration tools using NITRO APIs to get input from their individual clients on their bandwidth requirements and concurrent connections, create partitions and assign them to their clients.
    Below is a set of isolations that aid Service Providers:
    Filesystem: Each partition is assigned part of a file system and files stored in that respective partition space are not visible to other partitions. SSL certs/keys are stored in that partition and are not visible to other partition owners, thereby making each partition secure.
    Shared VLAN: In a typical Service Provider with a multi-tenant deployment, the end customers might not have independent VLANs for incoming traffic. The Shared VLAN feature shares the VLAN when it is not possible to have dedicated VLAN.
    VLAN tagging: A single interface can be shared across multiple admin partitions and isolated by using a tagged VLAN. For an untagged VLAN, use a shared VLAN.
    Troubleshooting and debugging: Admins can see traffic stats of each partition independently and separate out the logs by filtering by the partition ID. The trace function ensures partition independence since the trace fired from one partition will never see packets from another partition.
    Reference diagram

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.1d32a4f34b79c762b757a6ebb7de3f13.jpg" data-ratio="56.25" width="960" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
    Guidelines for implementing admin partitions
    Admin Partitions enable the sharing of resources including bandwidth, memory and concurrent connections, and provides isolation at the network, data, and management plane.
    Partition of resources
    ADC admins need the following details for configuring admin partition:
    Connections – (Number of TCP Connections) Memory Bandwidth Requirements The number of connections and bandwidth requirements depends on the application and the traffic handled by the respective partition. The ADC admin in consultation with the application admin will get the connections/bandwidth for a partition.
    Memory allocation guidelines
    The amount of memory allocated to a default partition should be a minimum of 50% of total memory available for the following reasons:
    To provide flexibility to the customer in the future for increasing the memory of other partitions in case the limit is reached. The integrated caching memory for all partitions is taken from the default partition. Total Memory that can be consumed by a PE is 4 GB. So total of 2 GB can be allocated to all partitions excluding admin partition.
    Memory assigned to admin partition is used for two purposes:
    Storing static objects (configuration, SSL keys) Dynamic objects – depending on the list of features enabled and the number of connections the memory allocated for dynamic objects vary The ADC admin uses the connections and bandwidth requirements from the app owner and the below guidelines to come up with the memory estimation.
    Guidelines for allocating static memory for config
    Table 1 lists the commonly used configs and the required memory.
    Table 1
    Type of config
    Memory allocated in KB per packet engine
    Add SNIP
    255
    Add IPv4 server
    0.384
    Add Service
    5.253
    Add vServer with a Service
    11.157
    bind vlan to partition
    0.116
    add route to partition
    0.564
    add acl
    0.5
    add monitor
    4.34
    add service groups
    4.625
    bind server to service group
    5.817
    add cs action
    4.532
    add cs policy
    2.548
    add cs vserver
    11.589
    bind cs policy to cs vServer
    7.348
    The configurations are replicated across PE’s, so the above requirement needs to be multipled by the number of PE’s.
    Guidelines for dynamic memory
    Table 2
    Feature
    Memory Requirement
    Connections (Applicable only if Citrix ADC version is 12.0 and above)
    2.4 MB per 1 K connections
    Persistent sessions
    600 KB per 1 K sessions
    GSLB Persistent sessions
    6 MB per 1 K sessions
    SSL
    6 MB for 1000 SSL Connections/Sessions in SSL Offload and 9 MB for 1000 SSL Connections/Sessions in End-End SSL
    AAA – Dependent on the number of users
    Number of Users * 2 KB
    Rewrite – Get the maximum length that will be parsed by Rewrite policy
    Number of Connections * Maximum length
    Responder – Get the maximum length that will be parsed by the Responder policy
    Number of Connections * Maximum Length
    TCP Buffering
    20% of connections * size of TCP buffer configured
    Dynamic memory = sum of the memory calculated from each of the above row in the above table.
    Add a buffer of 10-20% to the total memory calculated.
    Memory requirements for some features like AppQoE are not provided because the memory consumed from the partition memory is negligible for these features and the buffer of 10-20% is sufficient to handle them.
    Total Memory = Static Memory*No of PE’s + Dynamic Memory
    Let’s assume we come to a conclusion that the memory required is 1 GB and number of packet engines are 4. Then, for that particular partition, the amount of memory needed is derived by the below formula:
    Admin Partition memory configuration = (Amount of Memory required/Number of Packet Engines)
    Admin Partition Memory = 1GB/4 = 250 MB
    Behaviors when the resource limit is reached
    Connections – new connections will be dropped Bandwidth – new traffic will be dropped Memory – new traffic will get dropped You can configure SNMP alerts which are triggered if the particular partition’s resources are exhausted. List ofSNMP Traps are given in the Additional Resources Section.
    Network plane
    VLAN: Configure and assign different VLANS to Admin Partitions to maintain network-level isolation.
    Routing: Routing configuration is unique per partition.
    The ADC admin in consultation with the network admin (with input from application admin) define the VLAN and routing-related configurations based on the network topology.
    L3 Parameters: Can be partition specific. Some of the L3 parameters are Drop DF Packets, ICMP err threshold, overridernat, etc., and the input should come from the network or ADC admin.
    Control plane: User experience
    Admin Partitions provide isolation at different levels allowing the user to securely manage an isolated ADC instance.
    Different levels of isolation include:
    UI Page – Configuration, stats displayed only for the partition Diagnostics – Trace isolation. Trace will not capture the traffic of other partitions SNMP Alerts - configured at the partition level Log-level isolation UI-level isolation can be configured using the following method:
    In the respective partition, enable mgmt. access for one SNIP and use that SNIP to access the GUI. This will provide UI-level isolation and visibility only into that partition. Table 3
    Log Type
    Partition Specific
    Weblog
    Yes
    Techsupport bundle
    Yes
    Auditlogs
    No
    /var/log
    No
     
    Administration partition for enterprise use case
    This section describes an enterprise customer use case with four applications using Admin Partitions.
    Customer Requirements
    Needs to host 4 applications  
    Each application has its own administrator and a different set of ADC requirements. The table below lists the applications and their unique requirements.  
    Table 4
    Application
    Characteristics
    Requirement/Features
    SharePoint
    Sharing of files, audio, files etc.
    Caching, Compression, Authentication, SSL Offload, SSL Profiles
    Database
    Custom SQL rules, Authentication, split between read and write for better performance
    Content Switch, Policy Infra for SQL related keywords
    Enterprise Website
    Public access - prone to attacks, Application firewall
    DDoS, AppQOE, AppFW, SSL Profiles
    Outlook
    Integrated with AD, SSO, better performance in HTTP
    Authentication SSO, SSL Offload
    From the above requirements table, it is clear that each of the applications needs a different set of configurations to realize the complete benefits of Citrix ADC. It’s recommended to partition the Citrix ADC and assign those partitions to the respective application owners.
    Bandwidth and connections estimation
    Outlook and SharePoint
    Bandwidth for the enterprise applications like SharePoint, Exchange, and Lync are dependent on the:
    Number of concurrent users Type of usage Exchange – average size and number of messages SharePoint – type of files, ratio of read vs. write The application admin calculates the bandwidth requirements using the above two factors and provide the information to Citrix ADC admin for configuration of the admin partition.
    Examples:
    Bandwidth for Outlook 2010: Types of users (light, medium, heavy, etc.). For medium users, send 10 emails, receive 40 emails, avg. msg. size 50 kb = 2.15 Kbps. For 1,000 users, the required bandwidth is 2,150 Kbps.
    Bandwidth for SharePoint: Number of Users = 1,000. Assuming 20% of users are active at any point in time and the average page load size is 100 KB and accessing around 10 pages during a period of 1 hour:
    = 100 KB * 200 * 10 per hour = 200000 KB/hr = 200000*8(8 bits per byte)/3600(no of seconds)
    = 444 Kbps
    Connections per sec = Number of active users * 10
    MSSQL
    Based on the rate of queries and size of response, derive the bandwidth and connections.
    Enterprise website
    Bandwidth Requirements: Average page size * Max number of users at any time * 2
    Connections: Max number of users * number of connections per user
    Example:
    Bandwidth: 4KB10002 = 48000 Kbps
    Max Number of Users = 1000 and number of connections per user = 10. The connections = 10K
    If most of the users are from HTTP/1.1, then the number of connections per user would be 2–3, but if the mix is tilted more towards HTTP/1.0, then the number of connections would be 10–15. The multiplicative factor num-ber of connections per user varies 3–15 depending on the traffic/client mix.
    Memory to be configured depends on:
    List of configs in the respective admin partition – static memory. Refer to Table 1 for more details. Dynamic Memory – Number of connections and type of connections (HTTP vs. SSL) – Please refer to Table 2 for more details. Number of Packet Engines. Memory = (static memory + dynamic memory)/(number of packet engines) Steps for ADC admin
    Collect the bandwidth and connections for each application Create three partitions for SharePoint, Database, and Outlook respectively. Use the bandwidth and connections from the previous step and assign it to respective partition. The enterprise website can be hosted on default partition if the customer needs AppFW as AppFW is only supported on default partitions. Create users for each of the partitions and share the credentials. Enable Integrated caching and set the cache memory. Cache memory is taken from the cache memory configured in the default partition. For detailed information on the allocation, refer to the appendix section of IC.  
    Assign cache memory after consulting with the ADC admin. Try to allocate 30–40% of the total cache memory in the system. If the total allocated is 10 GB, allocate around 3-4 GB for cache in the SharePoint partition. Application owners should initially monitor the caching statistics to check the level of benefits. Check the Caching Objects Hit ratio and, if large number of cache objects have a high hit, increase the size of IC memory for that particular partition. Enable Compression SharePoint will publish files of different types (Excel, PowerPoint, Word) and the same files, if compressed and delivered to clients, will result in reduced bandwidth usage. Database user
    Configure the CS, VIP, and the backend servers. Use Content Switching to split the read/write requests and redirect to the respective set of servers. Enterprise website
    Configure the VIP and backend servers. Enable integrated caching.  
    Enterprise website is in the default partition so the unused cache memory from other partitions is available for Enterprise website. So assuming SharePoint and Outlook each consume 35%, then total consumed would be 70% leaving the remaining 30% to default partition (Enterprise website). If total cache memory is 10 GB, the default partition would have 3 GB of cache memory. Application owners should initially monitor the caching statistics to check the level of benefits. Check the Caching Objects Hit ratio, and if large number of cache objects have a high hit, then increase the size of IC memory for that particular partition. Enable front-end optimization. Enable AppFW.  
    Continued in Part 2 
     
    Guest
    Tech Brief: Citrix Gateway and Citrix Virtual Apps and Desktops
     
     
    May 4, 2021
     
     
     
     
    Author:  Florin Lazurca
     
     
     
     
    Overview
     
     
     
     
    Citrix Gateway is the best secure remote access solution for Citrix Workspace. It provides a myriad of unique integrations that enhance security and user experience. Moreover, Citrix Gateway consolidates access to any app, from any device, through a single URL.
     
     
     
     
    Citrix Gateway enables encrypted and contextual access (authentication and authorization) to Citrix Workspace. Its NetScaler ADC-powered load balancing distributes user traffic across the Citrix Virtual Apps and Desktops servers. Citrix Gateway also accelerates, optimizes, and provides visibility into the traffic flow that is useful to ensuring optimal user performance in a Citrix Virtual Apps and Desktops deployment.
     
     
     
     
    The following integrations add value to a Citrix Workspace deployment:
     
     
     
     
    Contextual Authentication – Validate the user and device with multifactor (nFactor) authentication Contextual Authorization - Limit app and desktop availability based on the user, location, and device properties Contextual Access - Limit access to HDX capabilities by modifying Citrix HDX connection behavior End to End Monitoring – Identify the source of delays and triage issues which impact user performance Adaptive Network Transport – Deliver a superior user experience by dynamically responding to changing network conditions Optimal Routing – Ensure a better user experience by always launching apps and desktops from the local gateway Custom Availability Monitors – Provide deep application health monitoring of back-end services running on the StoreFront and Delivery Controller servers  
     
     
     
    Conceptual architecture
     
     
     
     
    Citrix Gateway is a hardened appliance (physical or virtual) that proxies and secures all Citrix Workspace traffic with standards-based SSL/TLS encryption. The most common deployment configuration is to place the Citrix Gateway appliance in the DMZ. That places the Citrix Gateway between an organization’s secure internal network and the Internet (or any external network).
     
     
     
     
    Many organizations protect their internal network with a single DMZ (Figure 1). However, multiple Citrix Gateway appliances can be deployed for more complex deployments requiring a double-hop DMZ (Figure 2).
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.f6375812d1a49d53f07ae379e386cef6.jpg" data-ratio="55.98" width="936" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 1: Virtual App and Desktops with Citrix Gateway deployed in a single DMZ
     
     
     
     
    Some organizations use multiple firewalls or to protect their internal networks. The three firewalls in Figure 2 divide the DMZ into two stages (double-hop) to provide an extra layer of security for the internal network.
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.3f911628b64d5e809ab4471c37b0350e.jpg" data-ratio="47.86" width="936" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 2: Virtual Apps and Desktops with Citrix Gateway deployed in a double-hop DMZ
     
     
     
     
    Citrix administrators can deploy Citrix Gateway appliances in a double-hop DMZ to control access to servers running Citrix Virtual Apps and Desktops. In a double-hop deployment the security functions are split across the two appliances.
     
     
     
     
    The Citrix Gateway in the first DMZ handles user connections and performs the security functions such as encryption, authentication, and access to the servers in the internal network.
     
     
     
     
    The Citrix Gateway in the second DMZ serves as a Citrix Gateway proxy device. This Citrix Gateway enables the HDX traffic to traverse the second DMZ to complete user connections to the server farm. Communications between Citrix Gateway in the first DMZ and the Secure Ticket Authority (STA) in the internal network are also proxied through Citrix Gateway in the second DMZ.
     
     
     
     
    In enterprises where multiple StoreFront and Delivery Controllers servers are deployed, Citrix recommends load balancing the services by using the NetScaler ADC appliance. One virtual server load balances all StoreFront servers and another load balances all Delivery Controller servers. Application intelligent health monitoring ensures that only fully functioning servers are marked available to take user requests.
     
     
     
     
    NetScaler ADC appliances configured for global server load balancing (GSLB) can balance the Citrix Workspace load across data centers. GLSB directs user requests to the closest or best performing data center, or to surviving data centers if there is an outage. Using GSLB provides for disaster recovery across multiple data centers and ensures continuous availability of applications by protecting against points of failure.
     
     
     
     
    In Figure 3, the ADCs use the Metric Exchange Protocol (MEP) and the DNS infrastructure to connect the users to the data center that best meets the criteria set by administrators. The criteria can designate the least loaded, closest, or quickest data center to respond to requests.
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.3533e86dcff2136b762e1f5ed9c24f7d.jpg" data-ratio="55.98" width="936" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 3: Global Server Load Balancing for Virtual Apps and Desktops
     
     
     
     
    Contextual Authentication (nFactor and EPA)
     
     
     
     
    Citrix Gateway consolidates remote access authentication infrastructure for all applications whether in a data center, in a cloud, or if the apps are delivered as SaaS apps. Moreover, Citrix Gateway provides:
     
     
     
     
    The single point of access to all applications Secure access management, granular and consistent access control across all apps A better user experience that improves productivity Multifactor authentication that improves security  
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.0bc2e38bc8f1be48f8379066e3004c1d.jpg" data-ratio="71.08" width="816" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 4: Citrix Gateway Single Sign On consolidation
     
     
     
     
    Citrix Gateway authentication incorporates local and remote authentication for users and groups. Citrix Gateway includes support for the following authentication types.
     
     
     
     
    Local Lightweight Directory Access Protocol (LDAP) RADIUS SAML TACACS+ Client certificate authentication (including smart card authentication)  
     
     
     
    Citrix Gateway also supports multifactor authentication solutions such RSA SecurID, Gemalto Protiva (Thales), Duo (Cisco), and SafeWord (Aladdin) using a RADIUS server configuration.
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.7ceb7d556bd1d95517396ded2def4792.jpg" data-ratio="50.21" width="936" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 5: Citrix Gateway nFactor options
     
     
     
     
    nFactor Authentication
     
     
     
     
    Citrix Gateway extends two-factor authentication with true multifactor capabilities and gives flexibility to administrators for authentication, authorization, and auditing. For example, dynamic login forms and on-failure actions are possible by using nFactor authentication. Administrators can configure two types of multifactor authentication on Citrix Gateway:
     
     
     
     
    Two-factor authentication that requires users to log on by using two types of authentication Cascading authentication that sets the authentication priority level  
     
     
     
    If the Citrix Gateway deployment has multiple authentication servers, administrators can set the priority of the authentication polices. The priority levels determine the order in which order the authentication server validates users’ credentials. When administrators configure a cascade, the system traverses each authentication server to validate a user’s credentials.
     
     
     
     
    nFactor authentication enables dynamic authentication flows based on the user profile. The flows can be simple, or they can be coupled with more complex security requirements using other authentication servers. The following are some use cases enabled by Citrix Gateway:
     
     
     
     
    Dynamic user name and password selection: Traditionally, the Citrix clients (including browsers and the Workspace app) use the Active Directory (AD) password as the first password field. The second password is reserved for the One-Time-Password (OTP). However, to secure AD servers against brute force and lockout attacks, customers can require that the second factor such as OTP is to be validated first. nFactor can do this without requiring client modifications. Multitenant authentication endpoint: Some organizations use different Citrix Gateway login points for certificate and non-certificate users. With users using their own devices to log in, their access levels can vary on the Citrix Gateway based on the device being used. Citrix Gateway can cater to different authentication needs on the same login point – reducing complexity and improving user experience. Authentication based on group membership: Some organizations obtain user properties from AD servers to determine authentication requirements which can vary for individual users. For example, group extraction can be used to determine if a user is an employee or a vendor and present the appropriate second factor authentication.  
     
     
     
    End Point Analysis Scans
     
     
     
     
    Endpoint Analysis (EPA) scans are used to check user device compliance to endpoint security requirements. They are policy-based pre-authentication and post-authentication scans configured on the Citrix Gateway appliance. EPA scans are a part of contextual authentication if the state of the endpoint is involved in the authentication policies.
     
     
     
     
    When a user device tries to access Citrix Workspace through the Citrix Gateway appliance, the device is scanned for compliance before being granted access. For example, EPA can be used to check parameters such as operating system, antivirus, web browser, specific processes, file system or registry key, and user or device certificates.
     
     
     
     
    Administrators can configure two types of EPA scans using the OPSWAT EPA engine scan and a System scan using the Client Security engine. Using the OPSWAT EPA engine, administrators can configure product, vendor, and generic scans. These checks look for a particular product offered by a particular vendor, a vendor in a specific category, or a category across all vendors and products respectively.
     
     
     
     
    System scans validate system level attributes such as MAC address or device certificates. Device certificates can be configured in nFactor as an EPA component and administrators can selectively allow or block access to corporate intranet resources based on device certificate authentication.
     
     
     
     
    Contextual Authorization (SmartAccess)
     
     
     
     
    SmartAccess uses EPA post-authentication policies to limit user access to apps and desktops. For example, a sensitive Human Resources application can be enabled or disabled when a user connects from a managed or unmanaged device respectively.
     
     
     
     
    Using SmartAccess policies, administrators can identify the resources available on a per user and per app basis. Factors such as the end user, source IP range, specific registry key, or file on the user endpoint are used to determine if compliance is met. Similarly, SmartAccess scans can be used to identify specific peripherals attached to a computer and show applications that require that device.
     
     
     
     
    SmartAccess is configured on both the Citrix Gateway and inside Citrix Studio. The results of an EPA scan are matched to the corresponding access policies in Citrix Studio. In Figure 6, a user logs on to Citrix Workspace through Citrix Gateway with managed device and passes the compliance scan. Since the scan passed, the associated Citrix Gateway virtual server and session policy trigger the Citrix Studio policy to enable access for the app.
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2024_01/image.thumb.jpg.2a88110184cf67b8ba05dcf4ad2fb67e.jpg" data-ratio="70.49" width="1396" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 6: EPA scan with compliance pass and app is allowed
     
     
     
     
    In Figure 7, the same user logs on to Citrix Workspace through Citrix Gateway with personal device and fails the compliance scan. Conversely, failing the EPA scan doesn’t not trigger the enabling of the app for this user and device.
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2024_01/image.thumb.jpg.2c34423d401a5fab57dfba44bfa330eb.jpg" data-ratio="70.59" width="1394" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 7: EPA scan with compliance fail and app is restricted
     
     
     
     
    Contextual Access (SmartAccess and SmartControl)
     
     
     
     
    Citrix administrators can also modify Citrix HDX connection behavior based on how users connect to Citrix Gateway. Some examples include disabling client drive mappings, disabling access to specific apps and desktops, and disabling access to printing.
     
     
     
     
    In Figure 8, a user logs on to Citrix Workspace through Citrix Gateway with personal device and fails the compliance scan. The results of the EPA scan performed by the Citrix Gateway are communicated with Citrix Workspace. Using SmartAccess, the Delivery Controller enforces the results of the scan and prohibits clipboard access and client drive mappings.
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2024_01/image.thumb.jpg.4032fd63e969b44de87071e3fb17261b.jpg" data-ratio="70.63" width="1396" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 8: EPA scan with compliance fail
     
     
     
     
    In Figure 9, the same user connects to the same Citrix Gateway with a compliant device. The EPA results now allow clipboard access and client drive mappings.
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2024_01/image.thumb.jpg.19b4e2578b92a3c4a59e1c2ca5bb70c6.jpg" data-ratio="70.49" width="1396" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 9: EPA scan with compliance pass
     
     
     
     
    SmartControl helps customers meet security requirements that stipulate that access conditions are evaluated at the edge of the network. Customer security policies can require the ability to block access to resources even before a user has gained access to the corporate network. SmartControl can be used to block or allow certain components such as printer access, audio redirection, and client device drive redirection – at the Citrix Gateway.
     
     
     
     
    SmartAccess and SmartControl are similar, however, SmartControl is configured exclusively on Citrix Gateway, while SmartAccess requires configuration on both Citrix Gateway and inside Citrix Studio. When administrators want to make access policy decisions for the entire farm, they can use SmartControl on Citrix Gateway that applies to the entire farm. One difference is that SmartAccess lets administrators control the visibility of published icons, while SmartControl does not. Figure 10 compares SmartAccess and SmartControl feature support.
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.585493586edc773c371fc72e041f99b1.jpg" data-ratio="27.56" width="936" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 10: SmartAccess and SmartControl feature comparison
     
     
     
     
    SmartControl policies are designed to not enable any type of access if prohibited at the individual Delivery Controller level. The options are to default to the policy setting at the Delivery Controller level or prohibit a certain access even if it is allowed at the Delivery Controller. SmartAccess and SmartControl policies can be defined concurrently, and the most restrictive policy set is applied. Below is a list of SmartControl settings:
     
     
     
     
    Connect Client LPT Ports – Blocks LPT port redirection used for printers Client Audio Redirection – Redirect audio from VDA to client device Local Remote Data Sharing – Allows or disallows data sharing using Receiver HTML5 Client Clipboard Redirection – Redirects client clipboard contents to VDA Client COM Port Redirection – Redirect COM (serial) ports from client to VDA Client Drive Redirection – Redirect client drives from client to VDA Client Printer Redirection – Redirects client printers from client to VDA Multistream – Allow or disable multistream Client USB Drive Redirection – Redirect USB drives from client to desktop VDA only  
     
     
     
    Adaptive Network Transport (EDT)
     
     
     
     
    Citrix HDX is a set of technologies that ensure an unparalleled user experience when connecting to a remote Citrix resource. With the HDX engine in the Citrix Workspace app and the HDX protocol, Citrix HDX lets users interact seamlessly with resources even in challenging network conditions.
     
     
     
     
    A recent optimization to HDX is the Citrix UDP-based reliable transport protocol called Enlightened Data Transport (EDT). EDT is faster, improves application interactivity, and is more interactive on challenging long-haul WAN and internet connections. EDT delivers a superior user experience by dynamically responding to changing network conditions while maintaining high server scalability and efficient use of bandwidth.
     
     
     
     
    EDT is built on top of UDP and improves data throughput for all ICA virtual channels, including Thinwire display remoting, file transfer (Client Drive Mapping), printing, multimedia redirection. When EDT is not available, EDT intelligently switches to TCP ICA to deliver the best performance. Citrix Gateway supports EDT and Datagram Transport Layer Security (DTLS) which must be enabled to encrypt the UDP connection used by EDT.
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.7e4da68e9f4f1f3e6525033916735717.jpg" data-ratio="37.61" width="936" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 11: HDX Adaptive Transport
     
     
     
     
    Watch this video to
     
     
    :
     
     
    End to End Monitoring (HDX Insight)
     
     
     
     
    Citrix HDX Insight provides end-to-end visibility for HDX traffic to Virtual Apps and Desktops passing through Citrix Gateway. Using Citrix Application Delivery Management (ADM), administrators can view real-time client and network latency metrics, historical reports, end-to-end performance data, and troubleshoot performance issues.
     
     
     
     
    By parsing HDX traffic, HDX Insight can identify the source of delays and triage issues which impact user performance. For example, a user may experience delays while accessing Citrix Virtual Apps and Desktops. To identify the root cause of the issue, administrators can use HDX Insight to analyze WAN Latency, Data Center Latency, and Host Delay. Using HDX Insight helps determine if the latency is on the server, data center network, or client network side.
     
     
     
     
    Figure 12 shows an example where a specific user has normal WAN latency but high Data Center latency. This information is crucial to helping administrators triage a performance issue.
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.b5612f4b274a99c93851436b5cd84438.jpg" data-ratio="48.5" width="936" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 12: HDX Insight session visibility
     
     
     
     
    An important capability of HDX Insight is the ability to capture and display latency at the Layer 7 (L7). L7 latency calculation is done at the HDX layer and thus provides end-to-end latency detection regardless of the existence of TCP proxies. Looking at Figure 10, visibility into the application layers helps administrators diagnose latency by detecting that it is coming from apps and not the network for example in the situation of an overloaded server or back end.
     
     
     
     
    The L7 latency thresholding actively detects end-to-end network latency issues at the application. This capability is contrasted to capturing Layer 4 network latency, which does not require HDX parsing but suffers from the major drawback of an incomplete view of latency end-to-end.
     
     
     
     
    Successful user logons, latency, and application-level details for virtual HDX applications and desktops are provided by HDX Insight. Endpoint analysis (EPA), authentication, single sign-on (SSO), and application launch failures for a user are available with Gateway Insight.
     
     
     
     
    Gateway Insight also provides visibility into the reasons for application launch failure for virtual applications. Gateway Insight enhances an administrator’s ability to troubleshoot any kind of logon or application launch failure issues and also view the:
     
     
     
     
    Number of applications launched Number of total and active sessions Number of total bytes and bandwidth consumed by the applications Details of the users, sessions, bandwidth, and launch errors for an application Number of gateways Number of active sessions Total bytes and bandwidth used by all gateways associated with a Citrix Gateway appliance at any given time Details of all users associated with a gateway and their logon activity  
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.79ab73a3ea5b65bf2f17458d10bb3a90.jpg" data-ratio="57.05" width="936" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 13: HDX Insight L7 session visibility
     
     
     
     
    HDX Optimal Gateway Routing
     
     
     
     
    Citrix delivers the best app and desktop user experience with Citrix Workspace. In a hybrid cloud deployment, customers simplify the user experience with Global Server Load Balancing (GSLB). GSLB makes it easy for users to access apps, desktops and data regardless of their location. But with multiple Citrix Gateways, customers ask: “how can we send users to a specific data center where users’ unique data or back end application dependencies reside?”
     
     
     
     
    HDX Optimal Gateway Routing gives administrators the ability to point Citrix Gateway connections to zones. This ensures that the Citrix Gateway picks the zone it typically has the best connection as defined by the administrator. Using GSLB also routes the user to the optimal Citrix Gateway based on their location, and that Gateway would be connected to a zone for complete optimal gateway routing.
     
     
     
     
    HDX Optimal Gateway Routing ensures that the user experience is both simple and consistent by de-coupling the authentication gateway from the optimal launch gateway. This ensures that users always launch their apps and desktops from the local gateway, thus ensuring a better user experience when working from anywhere, on any device.
     
     
     
     
    GSLB powered zone preference is a feature that integrates with Workspace, StoreFront, and the ADC appliance to provide user access to the most optimized data center on the basis of the user location. With this feature, the client IP address is examined when an HTTP request arrives at the Citrix Gateway appliance, and the real client IP address is used to create the data center preference list that is forwarded to StoreFront.
     
     
     
     
    If the ADC is configured to insert the zone preference header, StoreFront 3.5 or later can use the information provided by the appliance to reorder the list of delivery controllers and connect to an optimal delivery controller in the same zone as the client. StoreFront selects the optimal gateway VPN virtual server for the selected data center zone, adds this information to the ICA file with appropriate IP addresses, and sends it to the client. StoreFront then tries to launch applications hosted on the preferred data center’s delivery controllers before trying to contact equivalent controllers in other data centers.
     
     
     
     

    /applications/core/interface/js/spacer.png" data-src="/monthly_2023_07/image.jpg.fd9812b95023d600632eef66d309084e.jpg" data-ratio="52.35" width="936" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
     
     
     
     
    Figure 14: HDX Insight Optimized Gateway Routing
     
     
     
     
    Custom Availability Monitors
    Citrix Gateway deployed with Citrix Workspace ensures the efficient delivery of applications. Using Citrix Gateway, incoming user requests from Citrix Workspace app can be load balanced between multiple StoreFront nodes in a server group. While some other solutions utilize simple ICMP-Ping or TCP port monitors, Citrix Gateway has deep application health monitoring of back end services running on the StoreFront and Delivery Controller servers.
    StoreFront services are monitored by probing a Windows service that runs on the StoreFront server. The Citrix Service Monitor Windows service has no other service dependencies and can monitor and report the failure of the following critical services on which StoreFront relies for correct operation:
    W3SVC (IIS) WAS (Windows Process Activation Service) CitrixCredentialWallet CitrixDefaultDomainService  
    Citrix Gateway also has custom Delivery Controller monitors to make sure the Delivery Controllers are alive and responding before the Citrix Gateway load balances to the resource. The monitors probe will validate a user’s credentials and confirm application enumeration to confirm whether the XML service is working. This prevents black hole scenarios where requests might be sent to an unresponsive server.
     
    Summary
    Citrix Gateway has the most integration points with Citrix Workspace of any HDX proxy solutions. Citrix Gateway provides secure remote access to Citrix Virtual Apps and Desktops and is augmented with visibility and optimization features that are useful to ensure optimal user performance. The NetScaler ADC provides intelligent global server load balancing that enhances availability and user experience. The following features enhance security and user experience:
    Contextual Authentication – Multifactor (nFactor) authentication to validate the user and device Contextual Authorization - Limit app and desktop availability based on the user, location, and device properties Contextual Access - Limit access to HDX capabilities by modifying Citrix HDX connection behavior End to End Monitoring - Identify the source of delays and triage issues which impact user performance Adaptive Network Transport – Delivers a superior user experience by dynamically responding to changing network conditions Optimal Routing – Ensure a better user experience by always launch apps and desktops from the local gateway Custom Availability Monitors – Deep application health monitoring of back end services running on the StoreFront and Delivery Controller servers  
    NetScaler Cyber Threat Intelligence
    NetScaler Web App Firewall -  New WAF signatures available
     
    NetScaler has integrated 43 new signatures into its Web App Firewall to help customers mitigate moderate and high CVSS vulnerabilities.
     The most notable CVEs in WAF Signatures version 110 are:
      CVE
    Description
    CVSS
    CVE-2023-29300
    CVE-2023-38203
    CVE-2023-38204
    Adobe ColdFusion - Deserialization of Untrusted Data Vulnerability
    9.8
    CVE-2023-29298
    CVE-2023-38205
    Adobe ColdFusion - Access Control Bypass Vulnerability
    7.5
    CVE-2022-29303
    Contec SolarView Compact < 7.21 - OS Command Injection Vulnerability
    9.8
    CVE-2023-33157
    Microsoft SharePoint Remote Code Execution Vulnerability
    8.8
     Adobe ColdFusion is a popular server-side scripting language that has recently been found to have a critical vulnerability. This vulnerability, tracked as CVE-2023-29300, allows remote attackers to execute arbitrary code. The vulnerability affects multiple versions of ColdFusion, including 2018, 2021, and 2023.
     Contec SolarView Series is affected by an unauthenticated and remote command injection vulnerability tracked as CVE-2022-29303. This poses a significant threat to organizations relying on these ICS devices. The impact of this vulnerability extends far beyond the initially reported subset of affected systems. Less than one-third of the internet-facing SolarView installations have applied the necessary patches, exposing many systems to exploitation.
     Microsoft SharePoint Server is affected by CVE-2023-33157 which is a remote code execution vulnerability1. The vulnerability has a base score of 8.8.. Microsoft has released a security update for SharePoint Server 2019 to address this vulnerability.
    Mitigating vulnerabilities
    If you are using any of the affected products, make sure you download WAF Signatures version 110 and apply it to your NetScaler Web App Firewall deployments as an additional layer of protection for your applications.  Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: software versions 11.1 and 12.0 are end of life and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
    NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. Netscaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
    Handling false positives
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
    Modifications to NetScaler Web App Firewall 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>^
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks from CVE-2023-34362.
    Additional Information
    Netscaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of Netscaler Web App Firewall.
     

© Cloud Software Group, Inc. All rights reserved.

×
×
  • Create New...