Advanced Concepts

Citrix ADC VPX on Azure Deployment Guide

Overview

Citrix ADC is an application delivery and load balancing solution that provides a high-quality user experience for web, traditional, and cloud-native applications regardless of where they are hosted. It comes in a wide variety of form factors and deployment options without locking users into a single configuration or cloud. Pooled capacity licensing enables the movement of capacity among cloud deployments.

As an undisputed leader of service and application delivery, Citrix ADC is deployed in thousands of networks around the world to optimize, secure, and control the delivery of all enterprise and cloud services. Deployed directly in front of web and database servers, Citrix ADC combines high-speed load balancing and content switching, HTTP compression, content caching, SSL acceleration, application flow visibility, and a powerful application firewall into an integrated, easy-to-use platform. Meeting SLAs is greatly simplified with end-to-end monitoring that transforms network data into actionable business intelligence. Citrix ADC allows policies to be defined and managed using a simple declarative policy engine with no programming expertise required.

Citrix ADC VPX

The Citrix ADC VPX product is a virtual appliance that can be hosted on a wide variety of virtualization and cloud platforms.

This deployment guide focuses on Citrix ADC VPX on Azure.

Microsoft Azure

  • Microsoft Azure is an ever-expanding set of cloud computing services to help organizations meet their business challenges. Azure gives users the freedom to build, manage, and deploy applications on a massive, global network using their preferred tools and frameworks. With Azure, users can:

  • Be future-ready with continuous innovation from Microsoft to support their development today—and their product visions for tomorrow.

  • Operate hybrid cloud seamlessly on-premises, in the cloud, and at the edge—Azure meets users where they are.

  • Build on their terms with Azure’s commitment to open source and support for all languages and frameworks, allowing users to be free to build how they want and deploy where they want.

  • Trust their cloud with security from the ground up—backed by a team of experts and proactive, industry-leading compliance that is trusted by enterprises, governments, and startups.

Azure Terminology

Here is a brief description of key terms used in this document that users must be familiar with:

  • Azure Load Balancer – Azure load balancer is a resource that distributes incoming traffic among computers in a network. Traffic is distributed among virtual machines defined in a load-balancer set. A load balancer can be external or internet-facing, or it can be internal.

  • Azure Resource Manager (ARM) – ARM is the new management framework for services in Azure. Azure Load Balancer is managed using ARM-based APIs and tools.

  • Back-End Address Pool – These are IP addresses associated with the virtual machine NIC to which load will be distributed.

  • BLOB - Binary Large Object – Any binary object like a file or an image that can be stored in Azure storage.

  • Front-End IP Configuration – An Azure Load balancer can include one or more front-end IP addresses, also known as a virtual IPs (VIPs). These IP addresses serve as ingress for the traffic.

  • Instance Level Public IP (ILPIP) – An ILPIP is a public IP address that users can assign directly to a virtual machine or role instance, rather than to the cloud service that the virtual machine or role instance resides in. This does not take the place of the VIP (virtual IP) that is assigned to their cloud service. Rather, it is an extra IP address that can be used to connect directly to a virtual machine or role instance.

Note:

In the past, an ILPIP was referred to as a PIP, which stands for public IP.

  • Inbound NAT Rules – This contains rules mapping a public port on the load balancer to a port for a specific virtual machine in the back-end address pool.

  • IP-Config - It can be defined as an IP address pair (public IP and private IP) associated with an individual NIC. In an IP-Config, the public IP address can be NULL. Each NIC can have multiple IP configurations associated with it, which can be up to 255.

  • Load Balancing Rules – A rule property that maps a given front-end IP and port combination to a set of back-end IP addresses and port combinations. With a single definition of a load balancer resource, users can define multiple load balancing rules, each rule reflecting a combination of a front-end IP and port and back end IP and port associated with virtual machines.

  • Network Security Group (NSG) – NSG contains a list of Access Control List (ACL) rules that allow or deny network traffic to virtual machine instances in a virtual network. NSGs can be associated with either subnets or individual virtual machine instances within that subnet. When an NSG is associated with a subnet, the ACL rules apply to all the virtual machine instances in that subnet. In addition, traffic to an individual virtual machine can be restricted further by associating an NSG directly to that virtual machine.

  • Private IP addresses – Used for communication within an Azure virtual network, and user on-premises network when a VPN gateway is used to extend a user network to Azure. Private IP addresses allow Azure resources to communicate with other resources in a virtual network or an on-premises network through a VPN gateway or ExpressRoute circuit, without using an Internet-reachable IP address. In the Azure Resource Manager deployment model, a private IP address is associated with the following types of Azure resources – virtual machines, internal load balancers (ILBs), and application gateways.

  • Probes – This contains health probes used to check availability of virtual machines instances in the back-end address pool. If a particular virtual machine does not respond to health probes for some time, then it is taken out of traffic serving. Probes enable users to keep track of the health of virtual instances. If a health probe fails, the virtual instance is taken out of rotation automatically.

  • Public IP Addresses (PIP) – PIP is used for communication with the Internet, including Azure public-facing services and is associated with virtual machines, Internet-facing load balancers, VPN gateways, and application gateways.

  • Region - An area within a geography that does not cross national borders and that contains one or more data centers. Pricing, regional services, and offer types are exposed at the region level. A region is typically paired with another region, which can be up to several hundred miles away, to form a regional pair. Regional pairs can be used as a mechanism for disaster recovery and high availability scenarios. Also referred to generally as location.

  • Resource Group - A container in Resource Manager that holds related resources for an application. The resource group can include all of the resources for an application, or only those resources that are logically grouped.

  • Storage Account – An Azure storage account gives users access to the Azure blob, queue, table, and file services in Azure Storage. A user storage account provides the unique namespace for user Azure storage data objects.

  • Virtual Machine – The software implementation of a physical computer that runs an operating system. Multiple virtual machines can run simultaneously on the same hardware. In Azure, virtual machines are available in various sizes.

  • Virtual Network - An Azure virtual network is a representation of a user network in the cloud. It is a logical isolation of the Azure cloud dedicated to a user subscription. Users can fully control the IP address blocks, DNS settings, security policies, and route tables within this network. Users can also further segment their VNet into subnets and launch Azure IaaS virtual machines and cloud services (PaaS role instances). Also, users can connect the virtual network to their on-premises network using one of the connectivity options available in Azure. In essence, users can expand their network to Azure, with complete control on IP address blocks with the benefit of the enterprise scale Azure provides.

Logical Flow of Citrix WAF on Azure

image-vpx-azure-appsecurity-deployment-01

Figure 1: Logical Diagram of Citrix WAF on Azure

Logical Flow

The Web Application Firewall can be installed as either a Layer 3 network device or a Layer 2 network bridge between customer servers and customer users, usually behind the customer company’s router or firewall. It must be installed in a location where it can intercept traffic between the web servers that users want to protect and the hub or switch through which users access those web servers. Users then configure the network to send requests to the Web Application Firewall instead of directly to their web servers, and responses to the Web Application Firewall instead of directly to their users. The Web Application Firewall filters that traffic before forwarding it to its final destination, using both its internal rule set and the user additions and modifications. It blocks or renders harmless any activity that it detects as harmful, and then forwards the remaining traffic to the web server. The figure above (Figure 1) provides an overview of the filtering process.

Note: The figure omits the application of a policy to incoming traffic. It illustrates a security configuration in which the policy is to process all requests. Also, in this configuration, a signatures object has been configured and associated with the profile, and security checks have been configured in the profile. As the figure shows, when a user requests a URL on a protected website, the Web Application Firewall first examines the request to ensure that it does not match a signature. If the request matches a signature, the Web Application Firewall either displays the error object (a webpage that is located on the Web Application Firewall appliance and which users can configure by using the imports feature) or forwards the request to the designated error URL (the error page).

If a request passes signature inspection, the Web Application Firewall applies the request security checks that have been enabled. The request security checks verify that the request is appropriate for the user website or web service and does not contain material that might pose a threat. For example, security checks examine the request for signs indicating that it might be of an unexpected type, request unexpected content, or contain unexpected and possibly malicious web form data, SQL commands, or scripts. If the request fails a security check, the Web Application Firewall either sanitizes the request and then sends it back to the Citrix ADC appliance (or Citrix ADC virtual appliance), or displays the error object. If the request passes the security checks, it is sent back to the Citrix ADC appliance, which completes any other processing and forwards the request to the protected web server.

When the website or web service sends a response to the user, the Web Application Firewall applies the response security checks that have been enabled. The response security checks examine the response for leaks of sensitive private information, signs of website defacement, or other content that should not be present. If the response fails a security check, the Web Application Firewall either removes the content that should not be present or blocks the response. If the response passes the security checks, it is sent back to the Citrix ADC appliance, which forwards it to the user.

Use Cases

Compared to alternative solutions that require each service to be deployed as a separate virtual appliance, Citrix ADC on Azure combines L4 load balancing, L7 traffic management, server offload, application acceleration, application security, and other essential application delivery capabilities in a single VPX instance, conveniently available via the Azure Marketplace. Furthermore, everything is governed by a single policy framework and managed with the same, powerful set of tools used to administer on-premises Citrix ADC deployments. The net result is that Citrix ADC on Azure enables several compelling use cases that not only support the immediate needs of today’s enterprises, but also the ongoing evolution from legacy computing infrastructures to enterprise cloud data centers.

Deployment Types

Multi-NIC Multi-IP Deployment (Three-NIC Deployment)

  • Typical Deployments

    • StyleBook driven

    • With ADM

      • With GSLB (Azure Traffic Management (TM) w/no domain registration)

      • Licensing - Pooled/Marketplace

  • Use Cases

    • Multi-NIC Multi-IP (Three-NIC) Deployments are used to achieve real isolation of data and management traffic.

    • Multi-NIC Multi-IP (Three-NIC) Deployments also improve the scale and performance of the ADC.

    • Multi-NIC Multi-IP (Three-NIC) Deployments are used in network applications where throughput is typically 1 Gbps or higher and a Three-NIC Deployment is recommended.

Multi-NIC Multi-IP (Three-NIC) Deployment for High Availability (HA)

Customers would potentially deploy using three-NIC deployment if they are deploying into a production environment where security, redundancy, availability, capacity, and scalability are critical. With this deployment method, complexity and ease of management are not critical concerns to the users.

Azure Resource Manager Template Deployment

Customers would deploy using ARM (Azure Resource Manager) Templates if they are customizing their deployments or they are automating their deployments.

ARM (Azure Resource Manager) Templates

The GitHub repository for Citrix ADC ARM (Azure Resource Manager) templates hosts Citrix ADC custom templates for deploying Citrix ADC in Microsoft Azure Cloud Services. All of the templates in this repository have been developed and maintained by the Citrix ADC engineering team.

Each template in this repository has co-located documentation describing the usage and architecture of the template. The templates attempt to codify the recommended deployment architecture of the Citrix ADC VPX, or to introduce the user to the Citrix ADC or to demonstrate a particular feature / edition / option. Users can reuse / modify or enhance the templates to suit their particular production and testing needs. Most templates require sufficient subscriptions to portal.azure.com to create resources and deploy templates. Citrix ADC VPX Azure Resource Manager (ARM) templates are designed to ensure an easy and consistent way of deploying standalone Citrix ADC VPX. These templates increase reliability and system availability with built-in redundancy. These ARM templates support Bring Your Own License (BYOL) or Hourly based selections. Choice of selection is either mentioned in the template description or offered during template deployment. For more information on how to provision a Citrix ADC VPX instance on Microsoft Azure using ARM (Azure Resource Manager) templates, visit: Citrix ADC Azure templates.

For more information on how to deploy a Citrix ADC VPX instance on Microsoft Azure, please refer to: Deploy a Citrix ADC VPX Instance on Microsoft Azure.

For more information on how a Citrix ADC VPX instance works on Azure, please visit: How a Citrix ADC VPX Instance Works on Azure.

Deployment Steps

When users deploy a Citrix ADC VPX instance on Microsoft Azure Resource Manager (ARM), they can use the Azure cloud computing capabilities and use Citrix ADC load balancing and traffic management features for their business needs. Users can deploy Citrix ADC VPX instances on Azure Resource Manager either as standalone instances or as high availability pairs in active-standby modes.

Users can deploy a Citrix ADC VPX instance on Microsoft Azure in either of two ways:

  • Through the Azure Marketplace. The Citrix ADC VPX virtual appliance is available as an image in the Microsoft Azure Marketplace. The Azure Resource Manager Template is published in the Azure Marketplace and can be used to deploy Citrix ADC in a standalone and in an HA pair deployment.

  • Using the Citrix ADC Azure Resource Manager (ARM) json template available on GitHub. For more information, see the GitHub repository for Citrix ADC solution templates.

Choosing the Right Azure Instance

VPX virtual appliances on Azure can be deployed on any instance type that has two or more cores and more than 2 GB memory. The following table lists the recommended instance types for the ADC VPX license:

VPX Model Azure Instance (recommended)
VPX10 Standard D2s v3
VPX200 Standard D2s v3
VPX1000 Standard D4s v3
VPX3000 Standard D8s v3

Once the license and instance type that needs to be used for deployment is known, users can provision a Citrix ADC VPX instance on Azure using the recommended Multi-NIC multi-IP architecture.

Multi-NIC Multi-IP Architecture (Three-NIC)

In this deployment type, users can have more than one network interfaces (NICs) attached to a VPX instance. Any NIC can have one or more IP configurations - static or dynamic public and private IP addresses assigned to it. Multi-NIC architecture can be used for both Standalone and HA pair deployments. The following ARM templates can be used:

  • Citrix ADC Standalone: ARM Template-Standalone 3-NIC

  • Citrix ADC HA Pair: ARM Template-HA Pair 3-NIC

Refer to the following use cases:

Citrix ADM Deployment Architecture

The following image provides an overview of how Citrix ADM connects with Azure to provision Citrix ADC VPX instances in Microsoft Azure.

image-vpx-azure-appsecurity-deployment-02

Users are required to have three subnets to provision and manage Citrix ADC VPX instances in Microsoft Azure. A security group must be created for each subnet. The rules specified in Network Security Group (NSG) govern the communication across the subnets.

Citrix ADM service agent helps users to provision and manage Citrix ADC VPX instances.

Configure a High-Availability Setup with Multiple IP Addresses and NICs

In a Microsoft Azure deployment, a high-availability configuration of two Citrix ADC VPX instances is achieved by using the Azure Load Balancer (ALB). This is achieved by configuring a health probe on ALB, which monitors each VPX instance by sending health probes at every 5 seconds to both primary and secondary instances.

In this setup, only the primary node responds to health probes and the secondary does not. Once the primary sends the response to the health probe, the ALB starts sending the data traffic to the instance. If the primary instance misses two consecutive health probes, ALB does not redirect traffic to that instance. On failover, the new primary starts responding to health probes and the ALB redirects traffic to it. The standard VPX high availability failover time is three seconds. The total failover time that might occur for traffic switching can be a maximum of 13 seconds.

Users can deploy a pair of Citrix ADC VPX instances with multiple NICs in an active-passive high availability (HA) setup on Azure. Each NIC can contain multiple IP addresses.

The following options are available for a multi-NIC high availability deployment:

  • High availability using Azure availability set

  • High availability using Azure availability zones

For more information about Azure Availability Set and Availability Zones, see the Azure documentation Manage the Availability of Linux Virtual Machines.

High Availability using Availability Set

A high availability setup using availability set must meet the following requirements:

  • An HA Independent Network Configuration (INC) configuration

  • The Azure Load Balancer (ALB) in Direct Server Return (DSR) mode

All traffic goes through the primary node. The secondary node remains in standby mode until the primary node fails.

Note:

For a Citrix VPX high availability deployment on Azure cloud to work, users need a floating public IP (PIP) that can be moved between the two VPX nodes. The Azure Load Balancer (ALB) provides that floating PIP, which is moved to the second node automatically in the event of a failover.

In an active-passive deployment, the ALB front-end public IP (PIP) addresses are added as the VIP addresses in each VPX node. In an HA-INC configuration, the VIP addresses are floating and the SNIP addresses are instance specific.

Users can deploy a VPX pair in active-passive high availability mode in two ways by using:

  • Citrix ADC VPX standard high availability template: use this option to configure an HA pair with the default option of three subnets and six NICs.

  • Windows PowerShell commands: use this option to configure an HA pair according to your subnet and NIC requirements.

This section describes how to deploy a VPX pair in active-passive HA setup by using the Citrix template. If users want to deploy with PowerShell commands, see Configure a High-Availability Setup with Multiple IP Addresses and NICs by using PowerShell Commands.

Configure HA-INC Nodes by using the Citrix High Availability Template

Users can quickly and efficiently deploy a pair of VPX instances in HA-INC mode by using the standard template. The template creates two nodes, with three subnets and six NICs. The subnets are for management, client, and server-side traffic, and each subnet has two NICs for both of the VPX instances.

Users can get the Citrix ADC 13.0 HA Pair template at the Azure Marketplace: Azure Marketplace/Citrix ADC 13.0 (High Availability).

Complete the following steps to launch the template and deploy a high availability VPX pair, by using Azure Availability Sets.

  1. From Azure Marketplace, select and initiate the Citrix solution template. The template appears.

  2. Ensure deployment type is Resource Manager and select Create.

  3. The Basics page appears. Create a Resource Group and select OK.

  4. The General Settings page appears. Type the details and select OK.

  5. The Network Setting page appears. Check the VNet and subnet configurations, edit the required settings, and select OK.

  6. The Summary page appears. Review the configuration and edit accordingly. Select OK to confirm.

  7. The Buy page appears. Select Purchase to complete the deployment.

It might take a moment for the Azure Resource Group to be created with the required configurations. After completion, select the Resource Group in the Azure portal to see the configuration details, such as LB rules, back-end pools, health probes, and so on. The high availability pair appears as ns-vpx0 and ns-vpx1.

If further modifications are required for the HA setup, such as creating more security rules and ports, users can do that from the Azure portal.

Next, users need to configure the load-balancing virtual server with the ALB’s Frontend public IP (PIP) address, on the primary node. To find the ALB PIP, select ALB > Frontend IP configuration.

See the Resources section for more information about how to configure the load-balancing virtual server.

Resources:

The following links provide additional information related to HA deployment and virtual server configuration:

Related resources:

High Availability using Availability Zones

Azure Availability Zones are fault-isolated locations within an Azure region, providing redundant power, cooling, and networking and increasing resiliency. Only specific Azure regions support Availability Zones. For more information, see the Azure documentation Availability Zones in Azure: Configure GSLB on an Active-Standby High-Availability Setup.

Users can deploy a VPX pair in high availability mode by using the template called “NetScaler 13.0 HA using Availability Zones,” available in Azure Marketplace.

Complete the following steps to launch the template and deploy a high availability VPX pair, by using Azure Availability Zones.

  1. From Azure Marketplace, select and initiate the Citrix solution template.

  2. Ensure deployment type is Resource Manager and select Create.

  3. The Basics page appears. Enter the details and click OK.

Note: Ensure that an Azure region that supports Availability Zones is selected. For more information about regions that support Availability Zones, see Azure documentation Availability Zones in Azure: Regions and Availability Zones in Azure.

  1. The General Settings page appears. Type the details and select OK.

  2. The Network Setting page appears. Check the VNet and subnet configurations, edit the required settings, and select OK.

  3. The Summary page appears. Review the configuration and edit accordingly. Select OK to confirm.

  4. The Buy page appears. Select Purchase to complete the deployment.

It might take a moment for the Azure Resource Group to be created with the required configurations. After completion, select the Resource Group to see the configuration details, such as LB rules, back-end pools, health probes, and so on, in the Azure portal. The high availability pair appears as ns-vpx0 and ns-vpx1. Also, users can see the location under the Location column.

If further modifications are required for the HA setup, such as creating more security rules and ports, users can do that from the Azure portal.

For more detailed information on provisioning Citrix ADC VPX instances on Microsoft Azure, please see: Provisioning Citrix ADC VPX Instances on Microsoft Azure.

Citrix Application Delivery Management

Citrix Application Delivery Management Service (Citrix ADM) provides an easy and scalable solution to manage Citrix ADC deployments that include Citrix ADC MPX, Citrix ADC VPX, Citrix Gateway, Citrix Secure Web Gateway, Citrix ADC SDX, Citrix ADC CPX, and Citrix SD-WAN appliances that are deployed on-premises or on the cloud.

Users can use this cloud solution to manage, monitor, and troubleshoot the entire global application delivery infrastructure from a single, unified, and centralized cloud-based console. Citrix ADM Service provides all the capabilities required to quickly set up, deploy, and manage application delivery in Citrix ADC deployments and with rich analytics of application health, performance, and security.

Citrix ADM Service provides the following benefits:

  • Agile – Easy to operate, update, and consume. The service model of Citrix ADM Service is available over the cloud, making it easy to operate, update, and use the features provided by Citrix ADM Service. The frequency of updates, combined with the automated update feature, quickly enhances user Citrix ADC deployment.

  • Faster time to value – Quicker business goals achievement. Unlike with the traditional on-premises deployment, users can use their Citrix ADM Service with a few clicks. Users not only save the installation and configuration time, but also avoid wasting time and resources on potential errors.

  • Multi-Site Management – Single Pane of Glass for instances across Multi-Site data centers. With the Citrix ADM Service, users can manage and monitor Citrix ADCs that are in various types of deployments. Users have one-stop management for Citrix ADCs deployed on-premises and in the cloud.

  • Operational Efficiency – Optimized and automated way to achieve higher operational productivity. With the Citrix ADM Service, user operational costs are reduced by saving user time, money, and resources on maintaining and upgrading the traditional hardware deployments.

How Citrix ADM Service Works

Citrix ADM Service is available as a service on the Citrix Cloud. After users sign up for Citrix Cloud and start using the service, install agents in the user network environment or initiate the built-in agent in the instances. Then, add the instances users want to manage to the service.

An agent enables communication between the Citrix ADM Service and the managed instances in the user data center. The agent collects data from the managed instances in the user network and sends it to the Citrix ADM Service.

When users add an instance to the Citrix ADM Service, it implicitly adds itself as a trap destination and collects an inventory of the instance.

The service collects instance details such as:

  • Host name

  • Software version

  • Running and saved configuration

  • Certificates

  • Entities configured on the instance, and so on.

Citrix ADM Service periodically polls managed instances to collect information.

The following image illustrates the communication between the service, the agents, and the instances:

image-vpx-azure-appsecurity-deployment-03

Documentation Guide

The Citrix ADM Service documentation includes information about how to get started with the service, a list of features supported on the service, and configuration specific to this service solution.

Citrix ADC WAF and OWASP Top Ten – 2017

The Open Web Application Security Project: OWASP (released the OWASP Top 10 for 2017 for web application security. This list documents the most common web application vulnerabilities and is a great starting point to evaluate web security. Here we detail how to configure the Citrix ADC Web Application Firewall (WAF) to mitigate these flaws. WAF is available as an integrated module in the Citrix ADC (Premium Edition) and a complete range of appliances.

The full OWASP Top 10 document is available at OWASP Top Ten.

OWASP Top-10 2017 Citrix ADC WAF Features
A1:2017- Injection Injection attack prevention (SQL or any other custom injections such as OS Command injection, XPath injection, and LDAP Injection), auto update signature feature
A2:2017 - Broken Authentication AAA, Cookie Tampering protection, Cookie Proxying, Cookie Encryption, CSRF tagging, Use SSL
A3:2017 - Sensitive Data Exposure Credit Card protection, Safe Commerce, Cookie proxying, and Cookie Encryption
A4:2017 XML External Entities (XXE) XML protection including WSI checks, XML message validation & XML SOAP fault filtering check
A5:2017 Broken Access Control AAA, Authorization security feature within AAA module of NetScaler, Form protections, and Cookie tampering protections, StartURL, and ClosureURL
A6:2017 - Security Misconfiguration PCI reports, SSL features, Signature generation from vulnerability scan reports such as Cenzic, Qualys, AppScan, WebInspect, Whitehat. Also, specific protections such as Cookie encryption, proxying, and tampering
A7:2017 - Cross Site Scripting (XSS) XSS Attack Prevention, Blocks all OWASP XSS cheat sheet attacks
A8:2017 – Insecure Deserialization XML Security Checks, GWT content type, custom signatures, Xpath for JSON and XML
A9:2017 - Using Components with known Vulnerabilities Vulnerability scan reports, Application Firewall Templates, and Custom Signatures
A10:2017 – Insufficient Logging & Monitoring User configurable custom logging, Citrix ADC Management and Analytics System

A1:2017- Injection

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into running unintended commands or accessing data without proper authorization.

ADC WAF Protections

  • SQL Injection prevention feature protects against common injection attacks. Custom injection patterns can be uploaded to protect against any type of injection attack including XPath and LDAP. This is applicable for both HTML and XML payloads.

  • The auto update signature feature keeps the injection signatures up to date.

  • Field format protection feature allows the administrator to restrict any user parameter to a regular expression. For instance, you can enforce that a zip-code field contains integers only or even 5-digit integers.

  • Form field consistency: Validate each submitted user form against the user session form signature to ensure the validity of all form elements.

  • Buffer overflow checks ensure that the URL, headers, and cookies are in the right limits blocking any attempts to inject large scripts or code.

A2:2017 – Broken Authentication

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

ADC WAF Protections

  • Citrix ADC AAA module performs user authentication and provides Single Sign-On functionality to back-end applications. This is integrated into the Citrix ADC AppExpert policy engine to allow custom policies based on user and group information.

  • Using SSL offloading and URL transformation capabilities, the firewall can also help sites to use secure transport layer protocols to prevent stealing of session tokens by network sniffing.

  • Cookie Proxying and Cookie Encryption can be employed to completely mitigate cookie stealing.

A3:2017 - Sensitive Data Exposure

Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such poorly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

ADC WAF Protections

  • Application Firewall protects applications from leaking sensitive data like credit card details.

  • Sensitive data can be configured as Safe objects in Safe Commerce protection to avoid exposure.

  • Any sensitive data in cookies can be protected by Cookie Proxying and Cookie Encryption.

A4:2017 XML External Entities (XXE)

Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

ADC WAF Protections

  • In addition to detecting and blocking common application threats that can be adapted for attacking XML-based applications (that is, cross-site scripting, command injection, and so on).

  • ADC Application Firewall includes a rich set of XML-specific security protections. These include schema validation to thoroughly verify SOAP messages and XML payloads, and a powerful XML attachment check to block attachments containing malicious executables or viruses.

  • Automatic traffic inspection methods block XPath injection attacks on URLs and forms aimed at gaining access.

  • ADC Application Firewall also thwarts various DoS attacks, including external entity references, recursive expansion, excessive nesting, and malicious messages containing either long or many attributes and elements.

A5:2017 Broken Access Control

Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, and so on

ADC WAF Protections

  • AAA feature that supports authentication, authorization, and auditing for all application traffic allows a site administrator to manage access controls with the ADC appliance.

  • The Authorization security feature within the AAA module of the ADC appliance enables the appliance to verify, which content on a protected server it should allow each user to access.

  • Form field consistency: If object references are stored as hidden fields in forms, then using form field consistency you can validate that these fields are not tampered on subsequent requests.

  • Cookie Proxying and Cookie consistency: Object references that are stored in cookie values can be validated with these protections.

  • Start URL check with URL closure: Allows user access to a predefined allow list of URLs. URL closure builds a list of all URLs seen in valid responses during the user session and automatically allows access to them during that session.

A6:2017 - Security Misconfiguration

Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or improvised configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched and upgraded in a timely fashion.

ADC WAF Protections

  • The PCI-DSS report generated by the Application Firewall, documents the security settings on the Firewall device.

  • Reports from the scanning tools are converted to ADC WAF Signatures to handle security misconfigurations.

  • ADC WAF supports Cenzic, IBM AppScan (Enterprise and Standard), Qualys, TrendMicro, WhiteHat, and custom vulnerability scan reports.

A7:2017 - Cross Site Scripting (XSS)

XSS flaws occur whenever an application includes untrusted data in a new webpage without proper validation or escaping, or updates an existing webpage with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to run scripts in the victim’s browser which can hijack user sessions, deface websites, or redirect the user to malicious sites.

ADC WAF Protections

  • XSS protection protects against common XSS attacks. Custom XSS patterns can be uploaded to modify the default list of allowed tags and attributes. The ADC WAF uses a white list of allowed HTML attributes and tags to detect XSS attacks. This is applicable for both HTML and XML payloads.

  • ADC WAF blocks all the attacks listed in the OWASP XSS Filter Evaluation Cheat Sheet.

  • Field format check prevents an attacker from sending inappropriate web form data which can be a potential XSS attack.

  • Form field consistency.

A8:2017 - Insecure Deserialization

Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

ADC WAF Protections

  • JSON payload inspection with custom signatures.

  • XML security: protects against XML denial of service (xDoS), XML SQL and Xpath injection and cross site scripting, format checks, WS-I basic profile compliance, XML attachments check.

  • Field Format checks and Cookie Consistency and Field Consistency can be used.

A9:2017 - Using Components with Known Vulnerabilities

Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

ADC WAF Protections

  • Citrix recommends having the third-party components up to date.

  • Vulnerability scan reports that are converted to ADC Signatures can be used to virtually patch these components.

  • Application Firewall templates that are available for these vulnerable components can be used.

  • Custom Signatures can be bound with the firewall to protect these components.

A10:2017 - Insufficient Logging & Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

ADC WAF Protections

  • When the log action is enabled for security checks or signatures, the resulting log messages provide information about the requests and responses that the application firewall has observed while protecting your websites and applications.

  • The application firewall offers the convenience of using the built-in ADC database for identifying the locations corresponding to the IP addresses from which malicious requests are originating.

  • Default format (PI) expressions give the flexibility to customize the information included in the logs with the option to add the specific data to capture in the application firewall generated log messages.

  • The application firewall supports CEF logs.

Application Security Protection

Citrix ADM

Citrix Application Delivery Management Service (Citrix ADM) provides a scalable solution to manage Citrix ADC deployments that include Citrix ADC MPX, Citrix ADC VPX, Citrix Gateway, Citrix Secure Web Gateway, Citrix ADC SDX, Citrix ADC CPX, and Citrix SD-WAN appliances that are deployed on-premises or on the cloud.

Citrix ADM Application Analytics and Management Features

Below are listed and summarized the salient features that are key to the ADM role in App Security.

Application Analytics and Management

The Application Analytics and Management feature of Citrix ADM strengthens the application-centric approach to help users address various application delivery challenges. This approach gives users visibility into the health scores of applications, helps users determine the security risks, and helps users detect anomalies in the application traffic flows and take corrective actions. Most important among these roles for App Security is Application Security Analytics:

  • Application security analytics: Application Security Analytics. The App Security Dashboard provides a holistic view of the security status of user applications. For example, it shows key security metrics such as security violations, signature violations, threat indexes. The App Security dashboard also displays attack related information such as SYN attacks, small window attacks, and DNS flood attacks for the discovered Citrix ADC instances.

Stylebooks

StyleBooks simplify the task of managing complex Citrix ADC configurations for user applications. A StyleBook is a template that users can use to create and manage Citrix ADC configurations. Here users are primarily concerned with the StyleBook used to deploy the Web Application Firewall. For more information on StyleBooks, see: StyleBooks.

Analytics

Provides an easy and scalable way to look into the various insights of the Citrix ADC instances’ data to describe, predict, and improve application performance. Users can use one or more analytics features simultaneously. Most important among these roles for App Security are:

  • Security Insight: Security Insight. Provides a single-pane solution to help users assess user application security status and take corrective actions to secure user applications.

  • Bot Insight

  • For more information on analytics, see Analytics: Analytics.

Other features that are important to ADM functionality are:

Event Management

Events represent occurrences of events or errors on a managed Citrix ADC instance. For example, when there is a system failure or change in configuration, an event is generated and recorded on Citrix ADM. Following are the related features that users can configure or view by using Citrix ADM:

For more information on event management, see: Events.

Instance Management

Enables users to manage the Citrix ADC, Citrix Gateway, Citrix Secure Web Gateway, and Citrix SD-WAN instances. For more information on instance management, see: Adding Instances.

License Management

Allows users to manage Citrix ADC licenses by configuring Citrix ADM as a license manager.

  • Citrix ADC pooled capacity: Pooled Capacity. A common license pool from which a user Citrix ADC instance can check out one instance license and only as much bandwidth as it needs. When the instance no longer requires these resources, it checks them back in to the common pool, making the resources available to other instances that need them.

  • Citrix ADC VPX check-in and check-out licensing: Citrix ADC VPX Check-in and Check-out Licensing. Citrix ADM allocates licenses to Citrix ADC VPX instances on demand. A Citrix ADC VPX instance can check out the license from the Citrix ADM when a Citrix ADC VPX instance is provisioned, or check back in its license to Citrix ADM when an instance is removed or destroyed.

  • For more information on license management, see: Pooled Capacity.

Configuration Management

Citrix ADM allows users to create configuration jobs that help them perform configuration tasks, such as creating entities, configuring features, replication of configuration changes, system upgrades, and other maintenance activities with ease on multiple instances. Configuration jobs and templates simplify the most repetitive administrative tasks to a single task on Citrix ADM. For more information on configuration management, see Configuration jobs: Configuration Jobs.

Configuration Audit

Enables users to monitor and identify anomalies in the configurations across user instances.

Signatures provide the following deployment options to help users to optimize the protection of user applications:

  • Negative Security Model: With the negative security model, users employ a rich set of preconfigured signature rules to apply the power of pattern matching to detect attacks and protect against application vulnerabilities. Users block only what they don’t want and allow the rest. Users can add their own signature rules, based on the specific security needs of user applications, to design their own customized security solutions.

  • Hybrid security Model: In addition to using signatures, users can use positive security checks to create a configuration ideally suited for user applications. Use signatures to block what users don’t want, and use positive security checks to enforce what is allowed.

To protect user applications by using signatures, users must configure one or more profiles to use their signatures object. In a hybrid security configuration, the SQL injection and cross-site scripting patterns, and the SQL transformation rules, in the user signatures object are used not only by the signature rules, but also by the positive security checks configured in the Web Application Firewall profile that is using the signatures object.

The Web Application Firewall examines the traffic to user protected websites and web services to detect traffic that matches a signature. A match is triggered only when every pattern in the rule matches the traffic. When a match occurs, the specified actions for the rule are invoked. Users can display an error page or error object when a request is blocked. Log messages can help users to identify attacks being launched against user applications. If users enable statistics, the Web Application Firewall maintains data about requests that match a Web Application Firewall signature or security check.

If the traffic matches both a signature and a positive security check, the more restrictive of the two actions are enforced. For example, if a request matches a signature rule for which the block action is disabled, but the request also matches an SQL Injection positive security check for which the action is block, the request is blocked. In this case, the signature violation might be logged as <not blocked>, although the request is blocked by the SQL injection check.

Customization: If necessary, users can add their own rules to a signatures object. Users can also customize the SQL/XSS patterns. The option to add their own signature rules, based on the specific security needs of user applications, gives users the flexibility to design their own customized security solutions. Users block only what they don’t want and allow the rest. A specific fast-match pattern in a specified location can significantly reduce processing overhead to optimize performance. Users can add, modify, or remove SQL injection and cross-site scripting patterns. Built-in RegEx and expression editors help users configure user patterns and verify their accuracy.

Use Cases

Compared to alternative solutions that require each service to be deployed as a separate virtual appliance, Citrix ADC on AWS combines L4 load balancing, L7 traffic management, server offload, application acceleration, application security, flexible licensing, and other essential application delivery capabilities in a single VPX instance, conveniently available via the AWS Marketplace. Furthermore, everything is governed by a single policy framework and managed with the same, powerful set of tools used to administer on-premises Citrix ADC deployments. The net result is that Citrix ADC on AWS enables several compelling use cases that not only support the immediate needs of today’s enterprises, but also the ongoing evolution from legacy computing infrastructures to enterprise cloud data centers.

Citrix Web Application Firewall (WAF)

Citrix Web Application Firewall (WAF) is an enterprise grade solution offering state of the art protections for modern applications. Citrix WAF mitigates threats against public-facing assets, including websites, web applications, and APIs. Citrix WAF includes IP reputation-based filtering, Bot mitigation, OWASP Top 10 application threats protections, Layer 7 DDoS protection and more. Also included are options to enforce authentication, strong SSL/TLS ciphers, TLS 1.3, rate limiting and rewrite policies. Using both basic and advanced WAF protections, Citrix WAF provides comprehensive protection for your applications with unparalleled ease of use. Getting up and running is a matter of minutes. Further, using an automated learning model, called dynamic profiling, Citrix WAF saves users precious time. By automatically learning how a protected application works, Citrix WAF adapts to the application even as developers deploy and alter the applications. Citrix WAF helps with compliance for all major regulatory standards and bodies, including PCI-DSS, HIPAA, and more. With our CloudFormation templates, it has never been easier to get up and running quickly. With auto scaling, users can rest assured that their applications remain protected even as their traffic scales up.

Web Application Firewall Deployment Strategy

The first step to deploying the web application firewall is to evaluate which applications or specific data need maximum security protection, which ones are less vulnerable, and the ones for which security inspection can safely be bypassed. This helps users in coming up with an optimal configuration, and in designing appropriate policies and bind points to segregate the traffic. For example, users might want to configure a policy to bypass security inspection of requests for static web content, such as images, MP3 files, and movies, and configure another policy to apply advanced security checks to requests for dynamic content. Users can use multiple policies and profiles to protect different contents of the same application.

The next step is to baseline the deployment. Start by creating a virtual server and run test traffic through it to get an idea of the rate and amount of traffic flowing through the user system.

Then, deploy the Web Application Firewall. Use Citrix ADM and the Web Application Firewall StyleBook to configure the Web Application Firewall. See the StyleBook section below in this guide for details.

After the Web Application Firewall is deployed and configured with the Web Application Firewall StyleBook, a useful next step would be to implement the Citrix ADC WAF and OWASP Top Ten.

Finally, three of the Web Application Firewall protections are especially effective against common types of Web attacks, and are therefore more commonly used than any of the others. Thus, they should be implemented in the initial deployment. They are:

  • HTML Cross-Site Scripting. Examines requests and responses for scripts that attempt to access or modify content on a different website than the one on which the script is located. When this check finds such a script, it either renders the script harmless before forwarding the request or response to its destination, or it blocks the connection.

  • HTML SQL Injection. Examines requests that contain form field data for attempts to inject SQL commands into a SQL database. When this check detects injected SQL code, it either blocks the request or renders the injected SQL code harmless before forwarding the request to the Web server.

Note: If both of the following conditions apply to the user configuration, users should make certain that your Web Application Firewall is correctly configured:

  • If users enable the HTML Cross-Site Scripting check or the HTML SQL Injection check (or both), and

  • User protected websites accept file uploads or contain Web forms that can contain large POST body data.

For more information about configuring the Web Application Firewall to handle this case, see Configuring the Application Firewall: Configuring the Web App Firewall.

  • Buffer Overflow. Examines requests to detect attempts to cause a buffer overflow on the Web server.

Configuring the Web Application Firewall (WAF)

The following steps assume that the WAF is already enabled and functioning correctly.

Citrix recommends that users configure WAF using the Web Application Firewall StyleBook. Most users find it the easiest method to configure the Web Application Firewall, and it is designed to prevent mistakes. Both the GUI and the command line interface are intended for experienced users, primarily to modify an existing configuration or use advanced options.

SQL Injection

The Application Firewall HTML SQL Injection check provides special defenses against the injection of unauthorized SQL code that might break user Application security. Citrix Web Application Firewall examines the request payload for injected SQL code in three locations: 1) POST body, 2) headers, and 3) cookies.

A default set of keywords and special characters provides known keywords and special characters that are commonly used to launch SQL attacks. Users can also add new patterns, and they can edit the default set to customize the SQL check inspection.

There are several parameters that can be configured for SQL injection processing. Users can check for SQL wildcard characters. Users can change the SQL Injection type and select one of the 4 options (SQLKeyword, SQLSplChar, SQLSplCharANDKeyword, SQLSplCharORKeyword) to indicate how to evaluate the SQL keywords and SQL special characters when processing the payload. The SQL Comments Handling parameter gives users an option to specify the type of comments that need to be inspected or exempted during SQL Injection detection.

Users can deploy relaxations to avoid false positives. The learning engine can provide recommendations for configuring relaxation rules.

The following options are available for configuring an optimized SQL Injection protection for the user application:

Block — If users enable block, the block action is triggered only if the input matches the SQL injection type specification. For example, if SQLSplCharANDKeyword is configured as the SQL injection type, a request is not blocked if it contains no key words, even if SQL special characters are detected in the input. Such a request is blocked if the SQL injection type is set to either SQLSplChar, or SQLSplCharORKeyword.

Log — If users enable the log feature, the SQL Injection check generates log messages indicating the actions that it takes. If block is disabled, a separate log message is generated for each input field in which the SQL violation was detected. However, only one message is generated when the request is blocked. Similarly, one log message per request is generated for the transform operation, even when SQL special characters are transformed in multiple fields. Users can monitor the logs to determine whether responses to legitimate requests are getting blocked. A large increase in the number of log messages can indicate attempts to launch an attack.

Stats — If enabled, the stats feature gathers statistics about violations and logs. An unexpected surge in the stats counter might indicate that the user application is under attack. If legitimate requests are getting blocked, users might have to revisit the configuration to see if they need to configure new relaxation rules or modify the existing ones.

Learn — If users are not sure which SQL relaxation rules might be ideally suited for their applications, they can use the learn feature to generate recommendations based on the learned data. The Web Application Firewall learning engine monitors the traffic and provides SQL learning recommendations based on the observed values. To get optimal benefit without compromising performance, users might want to enable the learn option for a short time to get a representative sample of the rules, and then deploy the rules and disable learning.

Transform SQL special characters—The Web Application Firewall considers three characters, Single straight quote (‘), Backslash (), and Semicolon (;) as special characters for SQL security check processing. The SQL Transformation feature modifies the SQL Injection code in an HTML request to ensure that the request is rendered harmless. The modified HTML request is then sent to the server. All default transformation rules are specified in the /netscaler/default_custom_settings.xml file.

  • The transform operation renders the SQL code inactive by making the following changes to the request:

  • Single straight quote (‘) to double straight quote (“).

  • Backslash () to double backslash ().

  • Semicolon (;) is dropped completely.

These three characters (special strings) are necessary to issue commands to a SQL server. Unless a SQL command is prefaced with a special string, most SQL servers ignore that command. Therefore, the changes that the Web Application Firewall performs when transformation is enabled prevent an attacker from injecting active SQL. After these changes are made, the request can safely be forwarded to the user protected website. When web forms on the user protected website can legitimately contain SQL special strings, but the web forms do not rely on the special strings to operate correctly, users can disable blocking and enable transformation to prevent blocking of legitimate web form data without reducing the protection that the Web Application Firewall provides to the user protected websites.

The transform operation works independently of the SQL Injection Type setting. If transform is enabled and the SQL Injection type is specified as SQL keyword, SQL special characters are transformed even if the request does not contain any keywords.

Tip: Users normally enable either transformation or blocking, but not both. If the block action is enabled, it takes precedence over the transform action. If users have blocking enabled, enabling transformation is redundant.

Check for SQL Wildcard Characters—Wild card characters can be used to broaden the selections of a SQL SELECT statement. These wild card operators can be used with LIKE and NOT LIKE operators to compare a value to similar values. The percent (%), and underscore (_) characters are frequently used as wild cards. The percent sign is analogous to the asterisk (*) wildcard character used with MS-DOS and to match zero, one, or multiple characters in a field. The underscore is similar to the MS-DOS question mark (?) wildcard character. It matches a single number or character in an expression.

For example, users can use the following query to do a string search to find all customers whose names contain the D character.

SELECT * from customer WHERE name like “%D%”:

The following example combines the operators to find any salary values that have 0 in the second and third place.

SELECT * from customer WHERE salary like ‘_00%’:

Different DBMS vendors have extended the wildcard characters by adding extra operators. The Citrix Web Application Firewall can protect against attacks that are launched by injecting these wildcard characters. The 5 default Wildcard characters are percent (%), underscore (_), caret (^), opening bracket ([), and closing bracket (]). This protection applies to both HTML and XML profiles.

The default wildcard chars are a list of literals specified in the *Default Signatures:

  • <wildchar type=” LITERAL”>%</wildchar>

  • <wildchar type=”LITERAL”>_</wildchar>

  • <wildchar type=”LITERAL”>^</wildchar>

  • <wildchar type=”LITERAL”>[</wildchar>

  • <wildchar type=”LITERAL”>]</wildchar>

Wildcard characters in an attack can be PCRE, like [^A-F]. The Web Application Firewall also supports PCRE wildcards, but the literal wildcard chars above are sufficient to block most attacks.

Note: The SQL wildcard character check is different from the SQL special character check. This option must be used with caution to avoid false positives.

Check Request Containing SQL Injection Type—The Web Application Firewall provides 4 options to implement the desired level of strictness for SQL Injection inspection, based on the individual need of the application. The request is checked against the injection type specification for detecting SQL violations. The 4 SQL injection type options are:

  • SQL Special Character and Keyword—Both a SQL keyword and a SQL special character must be present in the input to trigger a SQL violation. This least restrictive setting is also the default setting.

  • SQL Special Character—At least one of the special characters must be present in the input to trigger a SQL violation.

  • SQL key word—At least one of the specified SQL keywords must be present in the input to trigger a SQL violation. Do not select this option without due consideration. To avoid false positives, make sure that none of the keywords are expected in the inputs.

  • SQL Special Character or Keyword—Either the key word or the special character string must be present in the input to trigger the security check violation.

Tip: If users configure the Web Application Firewall to check for inputs that contain a SQL special character, the Web Application Firewall skips web form fields that do not contain any special characters. Since most SQL servers do not process SQL commands that are not preceded by a special character, enabling this option can significantly reduce the load on the Web Application Firewall and speed up processing without placing the user protected websites at risk.

SQL comments handling — By default, the Web Application Firewall checks all SQL comments for injected SQL commands. Many SQL servers ignore anything in a comment, however, even if preceded by an SQL special character. For faster processing, if your SQL server ignores comments, you can configure the Web Application Firewall to skip comments when examining requests for injected SQL. The SQL comments handling options are:

  • ANSI—Skip ANSI-format SQL comments, which are normally used by UNIX-based SQL databases. For example:

    • /– (Two Hyphens) - This is a comment that begins with two hyphens and ends with end of line.

    • {} - Braces (Braces enclose the comment. The { precedes the comment, and the } follows it. Braces can delimit single- or multiple-line comments, but comments cannot be nested)

    • /*/: C style comments (Does not allow nested comments). Please note /! <comment that begins with a slash followed by an asterisk and an exclamation mark is not a comment > */

    • MySQL Server supports some variants of C-style comments. These enable users to write code that includes MySQL extensions, but is still portable, by using comments of the following form: [/*! MySQL-specific code */]

    • .#: Mysql comments : This is a comment that begins with the # character and ends with an end of the line

  • Nested — Skip nested SQL comments, which are normally used by Microsoft SQL Server. For example; – (Two Hyphens), and /**/ (Allows nested comments)

  • ANSI/Nested — Skip comments that adhere to both the ANSI and nested SQL comment standards. Comments that match only the ANSI standard, or only the nested standard, are still checked for injected SQL.

  • Check all Comments — Check the entire request for injected SQL without skipping anything. This is the default setting.

Tip: Usually, users should not choose the Nested or the ANSI/Nested option unless their back-end database runs on Microsoft SQL Server. Most other types of SQL server software do not recognize nested comments. If nested comments appear in a request directed to another type of SQL server, they might indicate an attempt to breach security on that server.

Check Request headers — Enable this option if, in addition to examining the input in the form fields, users want to examine the request headers for HTML SQL Injection attacks. If users use the GUI, they can enable this parameter in the Advanced Settings -> Profile Settings pane of the Web Application Firewall profile.

Note: If users enable the Check Request header flag, they might have to configure a relaxation rule for the User-Agent header. Presence of the SQL keyword like and a SQL special character semi-colon (;) might trigger false positive and block requests that contain this header. Warning: If users enable both request header checking and transformation, any SQL special characters found in headers are also transformed. The Accept, Accept-Charset, Accept-Encoding, Accept-Language, Expect, and User-Agent headers normally contain semicolons (;). Enabling both Request header checking and transformation simultaneously might cause errors.

InspectQueryContentTypes — Configure this option if users want to examine the request query portion for SQL Injection attacks for the specific content-types. If users use the GUI, they can configure this parameter in the Advanced Settings -> Profile Settings pane of the Application Firewall profile.

Cross-Site Scripting

The HTML Cross-Site Scripting (cross-site scripting) check examines both the headers and the POST bodies of user requests for possible cross-site scripting attacks. If it finds a cross-site script, it either modifies (transforms) the request to render the attack harmless, or blocks the request.

Note: The HTML Cross-Site Scripting (cross-site scripting) check works only for content type, content length, and so forth. It does not work for cookie. Also ensure to have the ‘checkRequestHeaders’ option enabled in the user Web Application Firewall profile.

To prevent misuse of the scripts on user protected websites to breach security on user websites, the HTML Cross-Site Scripting check blocks scripts that violate the same origin rule, which states that scripts should not access or modify content on any server but the server on which they are located. Any script that violates the same origin rule is called a cross-site script, and the practice of using scripts to access or modify content on another server is called cross-site scripting. The reason cross-site scripting is a security issue is that a web server that allows cross-site scripting can be attacked with a script that is not on that web server, but on a different web server, such as one owned and controlled by the attacker.

Unfortunately, many companies have a large installed base of JavaScript-enhanced web content that violates the same origin rule. If users enable the HTML Cross-Site Scripting check on such a site, they have to generate the appropriate exceptions so that the check does not block legitimate activity.

The Web Application Firewall offers various action options for implementing HTML Cross-Site Scripting protection. In addition to the BlockLogStats and Learn actions, users also have the option to Transform cross-site scripts to render an attack harmless by entity encoding the script tags in the submitted request. Users can configure Check complete URLs for the cross-site scripting parameter to specify if they want to inspect not just the query parameters but the entire URL to detect a cross-site scripting attack. Users can configure the InspectQueryContentTypes parameter to inspect the request query portion for a cross-site scripting attack for the specific content-types.

Users can deploy relaxations to avoid false positives. The Web Application Firewall learning engine can provide recommendations for configuring relaxation rules.

The following options are available for configuring an optimized HTML Cross-Site Scripting protection for the user application:

  • Block — If users enable block, the block action is triggered if the cross-site scripting tags are detected in the request.

  • Log — If users enable the log feature, the HTML Cross-Site Scripting check generates log messages indicating the actions that it takes. If block is disabled, a separate log message is generated for each header or form field in which the cross-site scripting violation was detected. However, only one message is generated when the request is blocked. Similarly, one log message per request is generated for the transform operation, even when cross-site scripting tags are transformed in multiple fields. Users can monitor the logs to determine whether responses to legitimate requests are getting blocked. A large increase in the number of log messages can indicate attempts to launch an attack.

  • Stats — If enabled, the stats feature gathers statistics about violations and logs. An unexpected surge in the stats counter might indicate that the user application is under attack. If legitimate requests are getting blocked, users might have to revisit the configuration to see if they must configure new relaxation rules or modify the existing ones.

  • Learn — If users are not sure which relaxation rules might be ideally suited for their application, they can use the learn feature to generate HTML Cross-Site Scripting rule recommendations based on the learned data. The Web Application Firewall learning engine monitors the traffic and provides learning recommendations based on the observed values. To get optimal benefit without compromising performance, users might want to enable the learn option for a short time to get a representative sample of the rules, and then deploy the rules and disable learning.

  • Transform cross-site scripts — If enabled, the Web Application Firewall makes the following changes to requests that match the HTML Cross-Site Scripting check:

    • Left angle bracket (<) to HTML character entity equivalent (<)

    • Right angle bracket (>) to HTML character entity equivalent (>)

This ensures that browsers do not interpret unsafe html tags, such as <script>, and thereby run malicious code. If users enable both request-header checking and transformation, any special characters found in request headers are also modified as described above. If scripts on the user protected website contain cross-site scripting features, but the user website does not rely upon those scripts to operate correctly, users can safely disable blocking and enable transformation. This configuration ensures that no legitimate web traffic is blocked, while stopping any potential cross-site scripting attacks.

  • Check complete URLs for cross-site scripting — If checking of complete URLs is enabled, the Web Application Firewall examines entire URLs for HTML cross-site scripting attacks instead of checking just the query portions of URLs.

  • Check Request headers — If Request header checking is enabled, the Web Application Firewall examines the headers of requests for HTML cross-site scripting attacks, instead of just URLs. If users use the GUI, they can enable this parameter in the Settings tab of the Web Application Firewall profile.

  • InspectQueryContentTypes — If Request query inspection is configured, the Application Firewall examines the query of requests for cross-site scripting attacks for the specific content-types. If users use the GUI, they can configure this parameter in the Settings tab of the Application Firewall profile.

Important: As part of the streaming changes, the Web Application Firewall processing of the cross-site scripting tags has changed. In earlier releases, the presence of either open bracket (<), or close bracket (>), or both open and close brackets (<>) was flagged as a cross-site scripting Violation. The behavior has changed in the builds that include support for request side streaming. Only the close bracket character (>) is no longer considered as an attack. Requests are blocked even when an open bracket character (<) is present, and is considered as an attack. The Cross-site scripting attack gets flagged.

Buffer Overflow Check

The Buffer Overflow check detects attempts to cause a buffer overflow on the web server. If the Web Application Firewall detects that the URL, cookies, or header are longer than the configured length, it blocks the request because it can cause a buffer overflow.

The Buffer Overflow check prevents attacks against insecure operating-system or web-server software that can crash or behave unpredictably when it receives a data string that is larger than it can handle. Proper programming techniques prevent buffer overflows by checking incoming data and either rejecting or truncating overlong strings. Many programs, however, do not check all incoming data and are therefore vulnerable to buffer overflows. This issue especially affects older versions of web-server software and operating systems, many of which are still in use.

The Buffer Overflow security check allows users to configure the BlockLog, and Stats actions. In addition, users can also configure the following parameters:

  • Maximum URL Length. The maximum length the Web Application Firewall allows in a requested URL. Requests with longer URLs are blocked. Possible Values: 0–65535. Default: 1024

  • Maximum Cookie Length. The maximum length the Web Application Firewall allows for all cookies in a request. Requests with longer cookies trigger the violations. Possible Values: 0–65535. Default: 4096

  • Maximum Header Length. The maximum length the Web Application Firewall allows for HTTP headers. Requests with longer headers are blocked. Possible Values: 0–65535. Default: 4096

  • Query string length. Maximum length allowed for a query string in an incoming request. Requests with longer queries are blocked. Possible Values: 0–65535. Default: 1024

  • Total request length. Maximum request length allowed for an incoming request. Requests with a longer length are blocked. Possible Values: 0–65535. Default: 24820

Virtual Patching/Signatures

The signatures provide specific, configurable rules to simplify the task of protecting user websites against known attacks. A signature represents a pattern that is a component of a known attack on an operating system, web server, website, XML-based web service, or other resource. A rich set of preconfigured built-in or native rules offers an easy to use security solution, applying the power of pattern matching to detect attacks and protect against application vulnerabilities.

Users can create their own signatures or use signatures in the built-in templates. The Web Application Firewall has two built-in templates:

  • Default Signatures: This template contains a preconfigured list of over 1,300 signatures, in addition to a complete list of SQL injection keywords, SQL special strings, SQL transform rules, and SQL wildcard characters. It also contains denied patterns for cross-site scripting, and allowed attributes and tags for cross-site scripting. This is a read-only template. Users can view the contents, but they cannot add, edit, or delete anything in this template. To use it, users must make a copy. In their own copy, users can enable the signature rules that they want to apply to their traffic, and specify the actions to be taken when the signature rules match the traffic.

The signatures are derived from the rules published by SNORT: SNORT, which is an open source intrusion prevention system capable of performing real-time traffic analysis to detect various attacks and probes.

  • *Xpath Injection Patterns: This template contains a preconfigured set of literal and PCRE keywords and special strings that are used to detect XPath (XML Path Language) injection attacks.

Blank Signatures: In addition to making a copy of the built-in Default Signatures template, users can use a blank signatures template to create a signature object. The signature object that users create with the blank signatures option does not have any native signature rules, but, just like the *Default template, it has all the SQL/XSS built-in entities.

External-Format Signatures: The Web Application Firewall also supports external format signatures. Users can import the third-party scan report by using the XSLT files that are supported by the Citrix Web Application Firewall. A set of built-in XSLT files is available for selected scan tools to translate external format files to native format (see the list of built-in XSLT files later in this section).

While signatures help users to reduce the risk of exposed vulnerabilities and protect the user mission critical Web Servers while aiming for efficacy, Signatures do come at a Cost of additional CPU Processing.

It is important to choose the right Signatures for user Application needs. Enable only the signatures that are relevant to the Customer Application/environment.

Citrix offers signatures in more than 10 different categories across platforms/OS/Technologies.

image-vpx-azure-appsecurity-deployment-04

The signature rules database is substantial, as attack information has built up over the years. So, most of the old rules may not be relevant for all networks as Software Developers may have patched them already or customers are running a more recent version of the OS.

Signatures Updates

Citrix Web Application Firewall supports both Auto & Manual Update of Signatures. We also suggest Enabling Auto-update for signatures to stay up to date.

image-vpx-azure-appsecurity-deployment-05

These signatures files are hosted on the AWS Environment and it is important to allow outbound access to NetScaler IP’s from Network Firewalls to fetch the latest signature files. There is no effect of updating signatures to the ADC while processing Real Time Traffic.

Application Security Analytics

The Application Security Dashboard provides a holistic view of the security status of user applications. For example, it shows key security metrics such as security violations, signature violations, and threat indexes. Application Security dashboard also displays attack related information such as syn attacks, small window attacks, and DNS flood attacks for the discovered Citrix ADC instances.

Note: To view the metrics of the Application Security Dashboard, AppFlow for Security insight should be enabled on the Citrix ADC instances that users want to monitor.

To view the security metrics of a Citrix ADC instance on the application security dashboard:

  1. Log on to Citrix ADM using the administrator credentials.

  2. Navigate to Applications > App Security Dashboard, and select the instance IP address from the Devices list.

Users can further drill down on the discrepancies reported on the Application Security Investigator by clicking the bubbles plotted on the graph.

Centralized Learning on ADM

Citrix Web Application Firewall (WAF) protects user web applications from malicious attacks such as SQL injection and cross-site scripting (XSS). To prevent data breaches and provide the right security protection, users must monitor their traffic for threats and real-time actionable data on attacks. Sometimes, the attacks reported might be false-positives and those need to be provided as an exception.

The Centralized Learning on Citrix ADM is a repetitive pattern filter that enables WAF to learn the behavior (the normal activities) of user web applications. Based on monitoring, the engine generates a list of suggested rules or exceptions for each security check applied on the HTTP traffic.

It is much easier to deploy relaxation rules using the Learning engine than to manually deploy it as necessary relaxations.

To deploy the learning feature, users must first configure a Web Application Firewall profile (set of security settings) on the user Citrix ADC appliance. For more information, see Creating Web Application Firewall profiles: Creating Web App Firewall Profiles.

Citrix ADM generates a list of exceptions (relaxations) for each security check. As an administrator, users can review the list of exceptions in Citrix ADM and decide to deploy or skip.

Using the WAF learning feature in Citrix ADM, users can:

  • Configure a learning profile with the following security checks

    • Buffer Overflow

    • HTML Cross-Site Scripting

      Note: The cross-site script limitation of location is only FormField.

    • HTML SQL Injection

      Note:

      For the HTML SQL Injection check, users must configure set -sqlinjectionTransformSpecialChars ON and set -sqlinjectiontype sqlspclcharorkeywords in the Citrix ADC instance.

  • Check the relaxation rules in Citrix ADM and decide to take necessary action (deploy or skip)

  • Get the notifications through email, slack, and ServiceNow

  • Use the dashboard to view relaxation details

To use the WAF learning in Citrix ADM:

  1. Configure the learning profile: Configure the Learning Profile

  2. See the relaxation rules: View Relaxation Rules and Idle Rules

  3. Use the WAF learning dashboard: View WAF Learning Dashboard

StyleBook

Citrix Web Application Firewall is a Web Application Firewall (WAF) that protects web applications and sites from both known and unknown attacks, including all application-layer and zero-day threats.

Citrix ADM now provides a default StyleBook with which users can more conveniently create an application firewall configuration on Citrix ADC instances.

Deploying Application Firewall Configurations

The following task assists you in deploying a load balancing configuration along with the application firewall and IP reputation policy on Citrix ADC instances in your business network.

To Create a LB Configuration with Application Firewall Settings

In Citrix ADM, navigate to Applications > Configurations > StyleBooks. The StyleBooks page displays all the StyleBooks available for customer use in Citrix

  • ADM. Scroll down and find HTTP/SSL Load Balancing StyleBook with application firewall policy and IP reputation policy. Users can also search for the StyleBook by typing the name as lb-appfw. Click Create Configuration.

The StyleBook opens as a user interface page on which users can enter the values for all the parameters defined in this StyleBook.

  • Enter values for the following parameters:

    • Load Balanced Application Name. Name of the load balanced configuration with an application firewall to deploy in the user network.

    • Load balanced App Virtual IP address. Virtual IP address at which the Citrix ADC instance receives client requests.

    • Load Balanced App Virtual Port. The TCP Port to be used by the users in accessing the load balanced application.

    • Load Balanced App Protocol. Select the front-end protocol from the list.

    • Application Server Protocol. Select the protocol of the application server.

image-vpx-azure-appsecurity-deployment-06

  • As an option, users can enable and configure the Advanced Load Balancer Settings.

image-vpx-azure-appsecurity-deployment-07

  • Optionally, users can also set up an authentication server for authenticating traffic for the load balancing virtual server.

image-vpx-azure-appsecurity-deployment-08

  • Click “+” in the server IPs and Ports section to create application servers and the ports that they can be accessed on.

image-vpx-azure-appsecurity-deployment-09

  • Users can also create FQDN names for application servers.

image-vpx-azure-appsecurity-deployment-10

  • Users can also specify the details of the SSL certificate.

image-vpx-azure-appsecurity-deployment-11

  • Users can also create monitors in the target Citrix ADC instance.

image-vpx-azure-appsecurity-deployment-12

  • To configure an application firewall on the virtual server, enable WAF Settings.

Ensure that the application firewall policy rule is true if users want to apply the application firewall settings to all traffic on that VIP. Otherwise, specify the Citrix ADC policy rule to select a subset of requests to which to apply the application firewall settings. Next, select the type of profile that has to be applied - HTML or XML.

image-vpx-azure-appsecurity-deployment-13

  • Optionally, users can configure detailed application firewall profile settings by enabling the application firewall Profile Settings check box.

  • Optionally, if users want to configure application firewall signatures, enter the name of the signature object that is created on the Citrix ADC instance where the virtual server is to be deployed.

Note:

Users cannot create signature objects by using this StyleBook.

  • Next, users can also configure any other application firewall profile settings such as, StartURL settings, DenyURL settings and others.

image-vpx-azure-appsecurity-deployment-14

For more information on application firewall and configuration settings, see Application Firewall.

  • In the Target Instances section, select the Citrix ADC instance on which to deploy the load balancing virtual server with the application firewall.

Note: Users can also click the refresh icon to add recently discovered Citrix ADC instances in Citrix ADM to the available list of instances in this window.

  • Users can also enable IP Reputation check to identify the IP address that is sending unwanted requests. Users can use the IP reputation list to preemptively reject requests that are coming from the IP with the bad reputation.

image-vpx-azure-appsecurity-deployment-15

Tip: Citrix recommends that users select Dry Run to check the configuration objects that must be created on the target instance before they run the actual configuration on the instance.

When the configuration is successfully created, the StyleBook creates the required load balancing virtual server, application server, services, service groups, application firewall labels, application firewall policies, and binds them to the load balancing virtual server.

The following figure shows the objects created in each server:

image-vpx-azure-appsecurity-deployment-16

  • To see the ConfigPack created on Citrix ADM, navigate to Applications > Configurations.

image-vpx-azure-appsecurity-deployment-17

Security Insight Analytics

Web and web service applications that are exposed to the Internet have become increasingly vulnerable to attacks. To protect applications from attack, users need visibility into the nature and extent of past, present, and impending threats, real-time actionable data on attacks, and recommendations on countermeasures. Security Insight provides a single-pane solution to help users assess user application security status and take corrective actions to secure user applications.

How Security Insight Works

Security Insight is an intuitive dashboard-based security analytics solution that gives users full visibility into the threat environment associated with user applications. Security insight is included in Citrix ADM, and it periodically generates reports based on the user Application Firewall and ADC system security configurations. The reports include the following information for each application:

  • Threat index. A single-digit rating system that indicates the criticality of attacks on the application, regardless of whether the application is protected by an ADC appliance. The more critical the attacks on an application, the higher the threat index for that application. Values range from 1 through 7.

The threat index is based on attack information. The attack-related information, such as violation type, attack category, location, and client details, gives users insight into the attacks on the application. Violation information is sent to Citrix ADM only when a violation or attack occurs. Many breaches and vulnerabilities lead to a high threat index value.

  • Safety index. A single-digit rating system that indicates how securely users have configured the ADC instances to protect applications from external threats and vulnerabilities. The lower the security risks for an application, the higher the safety index. Values range from 1 through 7.

The safety index considers both the application firewall configuration and the ADC system security configuration. For a high safety index value, both configurations must be strong. For example, if rigorous application firewall checks are in place but ADC system security measures, such as a strong password for the nsroot user, have not been adopted, applications are assigned a low safety index value.

  • Actionable Information. Information that users need for lowering the threat index and increasing the safety index, which significantly improves application security. For example, users can review information about violations, existing and missing security configurations for the application firewall and other security features, the rate at which the applications are being attacked, and so on.

Configuring Security Insight

Note: Security Insight is supported on ADC instances with Premium license or ADC Advanced with AppFirewall license only.

To configure security insight on an ADC instance, first configure an application firewall profile and an application firewall policy, and then bind the application firewall policy globally.

Then, enable the AppFlow feature, configure an AppFlow collector, action, and policy, and bind the policy globally. When users configure the collector, they must specify the IP address of the Citrix ADM service agent on which they want to monitor the reports.

Configure Security Insight on an ADC Instance

  • Run the following commands to configure an application firewall profile and policy, and bind the application firewall policy globally or to the load balancing virtual server.

add appfw profile <name> [-defaults ( basic or advanced )]

set appfw profile <name> [-startURLAction <startURLAction> …]

add appfw policy <name> <rule> <profileName>

bind appfw global <policyName> <priority>

or,

bind lb vserver <lb vserver> -policyName <policy> -priority <priority>

Sample:


add appfw profile pr_appfw -defaults advanced

set appfw profile pr_appfw -startURLaction log stats learn

add appfw policy pr_appfw_pol "HTTP.REQ.HEADER(\"Host\").EXISTS" pr_appfw

bind appfw global pr_appfw_pol 1

or,

bind lb vserver outlook –policyName pr_appfw_pol –priority "20"

  • Run the following commands to enable the AppFlow feature, configure an AppFlow collector, action, and policy, and bind the policy globally or to the load balancing virtual server:

add appflow collector <name> -IPAddress <ipaddress>

set appflow param [-SecurityInsightRecordInterval <secs>] [-SecurityInsightTraffic ( ENABLED or DISABLED )]

add appflow action <name> -collectors <string>

add appflow policy <name> <rule> <action>

bind appflow global <policyName> <priority> [<gotoPriorityExpression>] [-type <type>]

or,

bind lb vserver <vserver> -policyName <policy> -priority <priority>

Sample:


add appflow collector col -IPAddress 10.102.63.85

set appflow param -SecurityInsightRecordInterval 600 -SecurityInsightTraffic ENABLED

add appflow action act1 -collectors col

add appflow action af_action_Sap_10.102.63.85 -collectors col

add appflow policy pol1 true act1

add appflow policy af_policy_Sap_10.102.63.85 true af_action_Sap_10.102.63.85

bind appflow global pol1 1 END -type REQ_DEFAULT

or,

bind lb vserver Sap –policyName af_action_Sap_10.102.63.85 –priority "20"

Enable Security Insight from Citrix ADM

  1. Navigate to Networks > Instances > Citrix ADC and select the instance type. For example, VPX.

  2. Select the instance and from the Select Action list, select Configure Analytics.

  3. On the Configure Analytics on virtual server window:

    • Select the virtual servers that you want to enable security insight and click Enable Analytics.

    The Enable Analytics window is displayed.

    • Select Security Insight

    • Under Advanced Options, select Logstream or IPFIX as the Transport Mode

    • The Expression is true by default

    • Click OK

image-vpx-azure-appsecurity-deployment-18

Note:

  • If users select virtual servers that are not licensed, then Citrix ADM first licenses those virtual servers and then enables analytics

  • For admin partitions, only Web Insight is supported

After users click OK, Citrix ADM processes to enable analytics on the selected virtual servers.

image-vpx-azure-appsecurity-deployment-19

Note: When users create a group, they can assign roles to the group, provide application-level access to the group, and assign users to the group. Citrix ADM analytics now supports virtual IP address-based authorization. Customer users can now see reports for all Insights for only the applications (virtual servers) for which they are authorized. For more information on groups and assigning users to the group, see Configure Groups on Citrix ADM: Configure Groups on Citrix ADM.

Thresholds

Users can set and view thresholds on the safety index and threat index of applications in Security Insight.

To set a threshold:

  • Navigate to System > Analytics Settings > Thresholds, and select Add.

  • Select the traffic type as Security in the Traffic Type field, and enter required information in the other appropriate fields such as Name, Duration, and entity.

  • In the Rule section, use the Metric, Comparator, and Value fields to set a threshold. For example, “Threat Index” “>” “5”

  • Click Create.

To view the threshold breaches:

  • Navigate to Analytics > Security Insight > Devices, and select the ADC instance.

  • In the Application section, users can view the number of threshold breaches that have occurred for each virtual server in the Threshold Breach column.

Security Insight Use Case

The following use cases describe how users can use security insight to assess the threat exposure of applications and improve security measures.

Obtain an Overview of the Threat Environment

In this use case, users have a set of applications that are exposed to attacks, and they have configured Citrix ADM to monitor the threat environment. Users need to frequently review the threat index, safety index, and the type and severity of any attacks that the applications might have experienced, so that they can focus first on the applications that need the most attention. The security insight dashboard provides a summary of the threats experienced by the user applications over a time period of user choosing, and for a selected ADC device. It displays the list of applications, their threat and safety indexes, and the total number of attacks for the chosen time period.

For example, users might be monitoring Microsoft Outlook, Microsoft Lync, SharePoint, and an SAP application, and users might want to review a summary of the threat environment for these applications.

To obtain a summary of the threat environment, log on to Citrix ADM, and then navigate to Analytics > Security Insight.

Key information is displayed for each application. The default time period is 1 hour.

image-vpx-azure-appsecurity-deployment-20

To view information for a different time period, from the list at the top-left, select a time period.

image-vpx-azure-appsecurity-deployment-21

To view a summary for a different ADC instance, under Devices, click the IP address of the ADC instance. To sort the application list by a given column, click the column header.

Determine the Threat Exposure of an Application

After reviewing a summary of the threat environment on the Security Insight dashboard to identify the applications that have a high threat index and a low safety index, users want to determine their threat exposure before deciding how to secure them. That is, users want to determine the type and severity of the attacks that have degraded their index values. Users can determine the threat exposure of an application by reviewing the application summary.

In this example, Microsoft Outlook has a threat index value of 6, and users want to know what factors are contributing to this high threat index.

To determine the threat exposure of Microsoft Outlook, on the Security Insight dashboard, click Outlook. The application summary includes a map that identifies the geographic location of the server.

image-vpx-azure-appsecurity-deployment-22

Click Threat Index > Security Check Violations and review the violation information that appears.

image-vpx-azure-appsecurity-deployment-23

Click Signature Violations and review the violation information that appears.

image-vpx-azure-appsecurity-deployment-24

Determine Existing and Missing Security Configuration for an Application

After reviewing the threat exposure of an application, users want to determine what application security configurations are in place and what configurations are missing for that application. Users can obtain this information by drilling down into the application’s safety index summary.

The safety index summary gives users information about the effectiveness of the following security configurations:

  • Application Firewall Configuration. Shows how many signature and security entities are not configured.

  • Citrix ADM System Security. Shows how many system security settings are not configured.

image-vpx-azure-appsecurity-deployment-25

In the previous use case, users reviewed the threat exposure of Microsoft Outlook, which has a threat index value of 6. Now, users want to know what security configurations are in place for Outlook and what configurations can be added to improve its threat index.

On the Security Insight dashboard, click Outlook, and then click the Safety Index tab. Review the information provided in the Safety Index Summary area.

image-vpx-azure-appsecurity-deployment-26

On the Application Firewall Configuration node, click Outlook_Profile and review the security check and signature violation information in the pie charts.

image-vpx-azure-appsecurity-deployment-27

Review the configuration status of each protection type in the application firewall summary table. To sort the table on a column, click the column header.

image-vpx-azure-appsecurity-deployment-28

Click the Citrix ADM System Security node and review the system security settings and Citrix recommendations to improve the application safety index.

Identify Applications That Require Immediate Attention

The applications that need immediate attention are those having a high threat index and a low safety index.

In this example, both Microsoft Outlook and Microsoft Lync have a high threat index value of 6, but Lync has the lower of the two safety indexes. Therefore, users might have to focus their attention on Lync before improving the threat environment for Outlook.

image-vpx-azure-appsecurity-deployment-29

Determine the Number of Attacks in a Given Period of Time

Users might want to determine how many attacks occurred on a given application at a given point in time, or they might want to study the attack rate for a specific time period.

On the Security Insight page, click any application and in the Application Summary, click the number of violations. The Total Violations page displays the attacks in a graphical manner for one hour, one day, one week, and one month.

image-vpx-azure-appsecurity-deployment-30

The Application Summary table provides the details about the attacks. Some of them are as follows:

  • Attack time

  • IP address of the client from which the attack happened

  • Severity

  • Category of violation

  • URL from which the attack originated, and other details.

image-vpx-azure-appsecurity-deployment-31

While users can always view the time of attack in an hourly report as seen in the image above, now they can view the attack time range for aggregated reports even for daily or weekly reports. If users select “1 Day” from the time-period list, the Security Insight report displays all attacks that are aggregated and the attack time is displayed in a one-hour range. If users choose “1 Week” or “1 Month,” all attacks are aggregated and the attack time is displayed in a one-day range.

image-vpx-azure-appsecurity-deployment-32

Obtain Detailed Information about Security Breaches

Users might want to view a list of the attacks on an application and gain insights into the type and severity of attacks, actions taken by the ADC instance, resources requested, and the source of the attacks.

For example, users might want to determine how many attacks on Microsoft Lync were blocked, what resources were requested, and the IP addresses of the sources.

On the Security Insight dashboard, click Lync > Total Violations. In the table, click the filter icon in the Action Taken column header, and then select Blocked.

image-vpx-azure-appsecurity-deployment-33

For information about the resources that were requested, review the URL column. For information about the sources of the attacks, review the Client IP column.

View Log Expression Details

Citrix ADC instances use log expressions configured with the Application Firewall profile to take action for the attacks on an application in the user enterprise. In Security Insight, users can view the values returned for the log expressions used by the ADC instance. These values include, request header, request body and so on. In addition to the log expression values, users can also view the log expression name and the comment for the log expression defined in the Application Firewall profile that the ADC instance used to take action for the attack.

Prerequisites:

Ensure that users:

  • Configure log expressions in the Application Firewall profile. For more information, see Application Firewall.

  • Enable log expression-based Security Insights settings in Citrix ADM. Do the following:

    • Navigate to Analytics > Settings, and click Enable Features for Analytics.

    • In the Enable Features for Analytics page, select Enable Security Insight under the Log Expression Based Security Insight Setting section and click OK.

image-vpx-azure-appsecurity-deployment-34

For example, users might want to view the values of the log expression returned by the ADC instance for the action it took for an attack on Microsoft Lync in the user enterprise.

On the Security Insight dashboard, navigate to Lync > Total Violations. In the Application Summary table, click the URL to view the complete details of the violation in the Violation Information page including the log expression name, comment, and the values returned by the ADC instance for the action.

image-vpx-azure-appsecurity-deployment-35

Determine the Safety Index before Deploying the Configuration

Security breaches occur after users deploy the security configuration on an ADC instance, but users might want to assess the effectiveness of the security configuration before they deploy it.

For example, users might want to assess the safety index of the configuration for the SAP application on the ADC instance with IP address 10.102.60.27.

On the Security Insight dashboard, under Devices, click the IP address of the ADC instance that users configured. Users can see that both the threat index and the total number of attacks are 0. The threat index is a direct reflection of the number and type of attacks on the application. Zero attacks indicate that the application is not under any threat.

image-vpx-azure-appsecurity-deployment-36

Click Sap > Safety Index > SAP_Profile and assess the safety index information that appears.

image-vpx-azure-appsecurity-deployment-37

In the application firewall summary, users can view the configuration status of different protection settings. If a setting is set to log or if a setting is not configured, the application is assigned a lower safety index.

image-vpx-azure-appsecurity-deployment-38

Security Violations

View Application Security Violation Details

Web applications that are exposed to the internet have become drastically more vulnerable to attacks. Citrix ADM enables users to visualize actionable violation details to protect applications from attacks. Navigate to Security > Security Violations for a single-pane solution to:

  • Access the application security violations based on their categories such as NetworkBot, and WAF

  • Take corrective actions to secure the applications

To view the security violations in Citrix ADM, ensure:

  • Users have a premium license for the Citrix ADC instance (for WAF and BOT violations).

  • Users have applied a license on the load balancing or content switching virtual servers (for WAF and BOT). For more information, refer to: Manage Licensing on Virtual Servers.

  • Users enable more settings. For more information, see the procedure available at the Setting up section in the Citrix product documentation: Setting up.

Violation Categories

Citrix ADM enables users to view the following violations:

NETWORK Bot WAF
HTTP Slow Loris Excessive Client Connections Unusually High Upload Transactions
DNS Slow Loris Account Takeover** Unusually High Download Transactions
HTTP Slow Post Unusually High Upload Volume Excessive Unique IPs
NXDomain Flood Attack Unusually High Request Rate Excessive Unique IPs Per Geo
HTTP desync attack Unusually High Download Volume  
Bleichenbacher Attack    
Segment smack Attack    
Syn Flood Attack    

** - Users must configure the account takeover setting in Citrix ADM. See the prerequisite mentioned in Account Takeover: Account Takeover.

Apart from these violations, users can also view the following Security Insight and Bot Insight violations under the WAF and Bot categories respectively:

WAF Bot
Buffer Overflow Crawler
Content type Feed Fetcher
Cookie Consistency Link Checker
CSRF Form Tagging Marketing
Deny URL Scraper
Form Field Consistency Screenshot Creator
Field Formats Search Engine
Maximum Uploads Service Agent
Referrer Header Site Monitor
Safe Commerce Speed Tester
Safe Object Tool
HTML SQL Inject Uncategorized
Start URL Virus Scanner
XSS Vulnerability Scanner
XML DoS DeviceFP Wait Exceeded
XML Format Invalid DeviceFP
XML WSI Invalid Captcha Response
XML SSL Captcha Attempts Exceeded
XML Attachment Valid Captcha Response
XML SOAP Fault Captcha Client Muted
XML Validation Captcha Wait Time Exceeded
Others Request Size Limit Exceeded
IP Reputation Rate Limit Exceeded
HTTP DOS Blacklist (IP, subnet, policy expression)
TCP Small Window Whitelist (IP, subnet, policy expression)
Signature Violation Zero Pixel Request
File Upload Type Source IP
JSON XSS Host
JSON SQL Geo Location
JSON DOS URL
Command Injection  
Infer Content Type XML  
Cookie Hijack  

Setting up

Users must enable Advanced Security Analytics and set Web Transaction Settings to All to view the following violations in Citrix ADM:

  • Unusually High Upload Transactions (WAF)

  • Unusually High Download Transactions (WAF)

  • Excessive Unique IPs (WAF)

  • Account takeover (BOT)

For other violations, ensure whether Metrics Collector is enabled. By default, Metrics Collector is enabled on the Citrix ADC instance. For more information, see: Configure Intelligent App Analytics.

Enable Advanced Security Analytics

  • Navigate to Networks > Instances > Citrix ADC, and select the instance type. For example, MPX.

  • Select the Citrix ADC instance and from the Select Action list, select Configure Analytics.

  • Select the virtual server and click Enable Analytics.

  • On the Enable Analytics window:

    • Select Web Insight. After users select Web Insight, the read-only Advanced Security Analytics option is enabled automatically.

    Note: The Advanced Security Analytics option is displayed only for premium licensed ADC instances.

    • Select Logstream as Transport Mode

    • The Expression is true by default

    • Click OK

image-vpx-azure-appsecurity-deployment-39

Enable Web Transaction settings

  • Navigate to Analytics > Settings.

The Settings page is displayed.

  • Click Enable Features for Analytics.

  • Under Web Transaction Settings, select All.

image-vpx-azure-appsecurity-deployment-40

  • Click Ok.

Security violations dashboard

In the security violations dashboard, users can view:

  • Total violations occurred across all ADC instances and applications. The total violations are displayed based on the selected time duration.

image-vpx-azure-appsecurity-deployment-41

  • Total violations under each category.

image-vpx-azure-appsecurity-deployment-42

  • Total ADCs affected, total applications affected, and top violations based on the total occurrences and the affected applications.

image-vpx-azure-appsecurity-deployment-43

Violation details

For each violation, Citrix ADM monitors the behavior for a specific time duration and detects violations for unusual behaviors. Click each tab to view the violation details. Users can view details such as:

  • The total occurrences, last occurred, and total applications affected

  • Under event details, users can view:

    • The affected application. Users can also select the application from the list if two or more applications are affected with violations.

    • The graph indicating violations.

    Drag and select on the graph that lists the violations to narrow down the violation search.

    image-vpx-azure-appsecurity-deployment-44

    Click Reset Zoom to reset the zoom result

    • Recommended Actions that suggest users troubleshoot the issue

    • Other violation details such as violence occurrence time and detection message

Bot Insight

Using Bot Insight in Citrix ADM

After users configure the bot management in Citrix ADC, they must enable Bot Insight on virtual servers to view insights in Citrix ADM.

To enable Bot Insight:

  • Navigate to Networks > Instances > Citrix ADC and select the instance type. For example, VPX.

  • Select the instance and from the Select Action list, select Configure Analytics.

  • Select the virtual server and click Enable Analytics.

  • On the Enable Analytics window:

    • Select Bot Insight

    • Under Advanced Option, select Logstream.

    image-vpx-azure-appsecurity-deployment-45

    • Click OK.

After enabling Bot Insight, navigate to Analytics > Security > Bot Insight.

image-vpx-azure-appsecurity-deployment-46

  1.  Time list to view bot details

  2. Drag the slider to select a specific time range and click Go to display the customized results

  3. Total instances affected from bots

  4. Virtual server for the selected instance with total bot attacks

    • Total Bots – Indicates the total bot attacks (inclusive of all bot categories) found for the virtual server.

    • Total Human Browsers – Indicates the total human users accessing the virtual server.

    • Bot Human Ratio – Indicates the ratio between human users and bots accessing the virtual server.

    • Signature BotsFingerprinted BotRate Based BotsIP Reputation Botsallow list Bots, and block list Bots – Indicates the total bot attacks occurred based on the configured bot category. For more information about bot category, see: Configure Bot Detection Techniques in Citrix ADC.

  5. Click > to view bot details in a graph format.

image-vpx-azure-appsecurity-deployment-47

View events history

Users can view the bot signature updates in the Events History, when:

  • New bot signatures are added in Citrix ADC instances.

  • Existing bot signatures are updated in Citrix ADC instances.

Users can select the time duration in bot insight page to view the events history.

image-vpx-azure-appsecurity-deployment-48

The following diagram shows how the bot signatures are retrieved from AWS cloud, updated on Citrix ADC and view signature update summary on Citrix ADM.

image-vpx-azure-appsecurity-deployment-49

  1. The bot signature auto update scheduler retrieves the mapping file from the AWS URI.

  2. Checks the latest signatures in the mapping file with the existing signatures in ADC appliance.

  3. Downloads the new signatures from AWS and verifies the signature integrity.

  4. Updates the existing bot signatures with the new signatures in the bot signature file.

  5. Generates an SNMP alert and sends the signature update summary to Citrix ADM.

View Bots

Click the virtual server to view the Application Summary

image-vpx-azure-appsecurity-deployment-50

  1. Provides the Application Summary details such as:

    • Average RPS – Indicates the average bot transaction requests per second (RPS) received on virtual servers.

    • Bots by Severity – Indicates the highest bot transactions occurred based on the severity. The severity is categorized based on CriticalHighMedium, and Low.

    For example, if the virtual servers have 11770 high severity bots and 1550 critical severity bots, then Citrix ADM displays Critical 1.55 K under Bots by Severity.

    • Largest Bot Category – Indicates the highest bot attacks occurred based on the bot category.

    For example, if the virtual servers have 8000 block listed bots, 5000 allow listed bots, and 10000 Rate Limit Exceeded bots, then Citrix ADM displays Rate Limit Exceeded 10 K under Largest Bot Category.

    • Largest Geo Source – Indicates the highest bot attacks occurred based on a region.

    For example, if the virtual servers have 5000 bot attacks in Santa Clara, 7000 bot attacks in London, and 9000 bot attacks in Bangalore, then Citrix ADM displays Bangalore 9 K under Largest Geo Source.

    • Average % Bot Traffic – Indicates the human bot ratio.
  2. Displays the severity of the bot attacks based on locations in map view

  3. Displays the types of bot attacks (Good, Bad, and All)

  4. Displays the total bot attacks along with the corresponding configured actions. For example, if you have configured:

    • IP address range (192.140.14.9 to 192.140.14.254) as block list bots and selected Drop as an action for these IP address ranges

    • IP range (192.140.15.4 to 192.140.15.254) as block list bots and selected to create a log message as an action for these IP ranges

      In this scenario, Citrix ADM displays:

      • Total block listed bots

      • Total bots under Dropped

      • Total bots under Log

View CAPTCHA bots

In webpages, CAPTCHAs are designed to identify if the incoming traffic is from a human or an automated bot. To view the CAPTCHA activities in Citrix ADM, users must configure CAPTCHA as a bot action for IP reputation and device fingerprint detection techniques in a Citrix ADC instance. For more information, see: Configure Bot Management.

The following are the CAPTCHA activities that Citrix ADM displays in Bot insight:

  • Captcha attempts exceeded – Denotes the maximum number of CAPTCHA attempts made after login failures

  • Captcha client muted – Denotes the number of client requests that are dropped or redirected because these requests were detected as bad bots earlier with the CAPTCHA challenge

  • Human – Denotes the captcha entries performed from the human users

  • Invalid captcha response – Denotes the number of incorrect CAPTCHA responses received from the bot or human, when Citrix ADC sends a CAPTCHA challenge

image-vpx-azure-appsecurity-deployment-51

View bot traps

To view bot traps in Citrix ADM, you must configure the bot trap in Citrix ADC instance. For more information, see: Configure Bot Management.

image-vpx-azure-appsecurity-deployment-52

To identify the bot trap, a script is enabled in the webpage and this script is hidden from humans, but not to bots. Citrix ADM identifies and reports the bot traps, when this script is accessed by bots.

Click the virtual server and select Zero Pixel Request

image-vpx-azure-appsecurity-deployment-53

View bot details

For further details, click the bot attack type under Bot Category.

The details such as attack time and total number of bot attacks for the selected captcha category are displayed.

image-vpx-azure-appsecurity-deployment-54

Users can also drag the bar graph to select the specific time range to be displayed with bot attacks.

image-vpx-azure-appsecurity-deployment-55

To get additional information of the bot attack, click to expand.

image-vpx-azure-appsecurity-deployment-56

  • Instance IP – Indicates the Citrix ADC instance IP address

  • Total Bots – Indicates the total bot attacks occurred for that particular time

  • HTTP Request URL – Indicates the URL that is configured for captcha reporting

  • Country Code – Indicates the country where the bot attack occurred

  • Region – Indicates the region where the bot attack occurred

  • Profile Name – Indicates the profile name that users provided during the configuration

Users can also use the search text box and time duration list, where they can view bot details as per the user requirement. When users click the search box, the search box gives them the following list of search suggestions.

  • Instance IP – Citrix ADC instance IP address

  • Client-IP – Client IP address

  • Bot-Type – Bot type such as Good or Bad

  • Severity – Severity of the bot attack

  • Action-Taken – Action taken after the bot attack such as Drop, No action, Redirect

  • Bot-Category – Category of the bot attack such as block list, allow list, fingerprint, and so on. Based on a category, users can associate a bot action to it

  • Bot-Detection – Bot detection types (block list, allow list, and so on) that users have configured on Citrix ADC instance

  • Location – Region/country where the bot attack has occurred

  • Request-URL – URL that has the possible bot attacks

Users can also use operators in the user search queries to narrow the focus of the user search. For example, if users want to view all bad bots:

  • Click the search box and select Bot-Type

  • Click the search box again and select the operator =

  • Click the search box again and select Bad

  • Click Search to display the results

image-vpx-azure-appsecurity-deployment-57

Bot violation details

Excessive Client Connections

When a client tries to access the web application, the client request is processed in Citrix ADC appliance, instead of connecting to the server directly. Web traffic comprises bots and bots can perform various actions at a faster rate than a human.

Using the Excessive Client Connections indicator, users can analyze scenarios when an application receives unusually high client connections through bots.

image-vpx-azure-appsecurity-deployment-58

Under Event Details, users can view:

  • The affected application. Users can also select the application from the list if two or more applications are affected with violations.

  • The graph indicating all violations

  • The violation occurrence time

  • The detection message for the violation, indicating the total IP addresses transacting the application

  • The accepted IP address range that the application can receive

Account Takeover

Note: Ensure users enable the advanced security analytics and web transaction options. For more information, see Setting up: Setting up.

Some malicious bots can steal user credentials and perform various kinds of cyberattacks. These malicious bots are known as bad bots. It is essential to identify bad bots and protect the user appliance from any form of advanced security attacks.

Prerequisite

Users must configure the Account Takeover settings in Citrix ADM.

  • Navigate to Analytics > Settings > Security Violations

  • Click Add

image-vpx-azure-appsecurity-deployment-59

  • On the Add Application page, specify the following parameters:

    • Application - Select the virtual server from the list.

    • Method - Select the HTTP method type from the list. The available options are GETPUSHPOST, and UPDATE.

    • Login URL and Success response code - Specify the URL of the web application and specify the HTTP status code (for example, 200) for which users want Citrix ADM to report the account takeover violation from bad bots.

    • Click Add.

image-vpx-azure-appsecurity-deployment-60

After users configure the settings, using the Account Takeover indicator, users can analyze if bad bots attempted to take over the user account, giving multiple requests along with credentials.

image-vpx-azure-appsecurity-deployment-61

Under Event Details, users can view:

  • The affected application. Users can also select the application from the list if two or more applications are affected with violations.

  • The graph indicating all violations

  • The violation occurrence time

  • The detection message for the violation, indicating total unusual failed login activity, successful logins, and failed logins

  • The bad bot IP address. Click to view details such as time, IP address, total successful logins, total failed logins, and total requests made from that IP address.

image-vpx-azure-appsecurity-deployment-62

Unusually High Upload Volume

Web traffic also comprises data that is processed for uploading. For example, if the user average upload data per day is 500 MB and if users upload 2 GB of data, then this can be considered as an unusually high upload data volume. Bots are also capable to process uploading of data more quickly than humans.

Using the Unusually High Upload Volume indicator, users can analyze abnormal scenarios of upload data to the application through bots.

image-vpx-azure-appsecurity-deployment-63

Under Event Details, users can view:

  • The affected application. Users can also select the application from the list if two or more applications are affected with violations.

  • The graph indicating all violations

  • The violation occurrence time

  • The detection message for the violation, indicating the total upload data volume processed

  • The accepted range of upload data to the application

Unusually High Download Volume

Similar to high upload volume, bots can also perform downloads more quickly than humans.

Using the Unusually High Download Volume indicator, users can analyze abnormal scenarios of download data from the application through bots.

image-vpx-azure-appsecurity-deployment-64

Under Event Details, users can view:

  • The affected application. Users can also select the application from the list if two or more applications are affected with violations.

  • The graph indicating all violations

  • The violation occurrence time

  • The detection message for the violation, indicating the total download data volume processed

  • The accepted range of download data from the application

Unusually High Request Rate

Users can control the incoming and outgoing traffic from or to an application. A bot attack can perform an unusually high request rate. For example, if users configure an application to allow 100 requests/minute and if users observe 350 requests, then it might be a bot attack.

Using the Unusually High Request Rate indicator, users can analyze the unusual request rate received to the application.

image-vpx-azure-appsecurity-deployment-65

Under Event Details, users can view:

  • The affected application. Users can also select the application from the list if two or more applications are affected with violations.

  • The graph indicating all violations

  • The violation occurrence time

  • The detection message for the violation, indicating the total requests received and % of excessive requests received than the expected requests

  • The accepted range of expected request rate range from the application

Use Cases

Bot

Sometimes the incoming web traffic is comprised of bots and most organizations suffer from bot attacks. Web and mobile applications are significant revenue drivers for business and most companies are under the threat of advanced cyberattacks, such as bots. A bot is a software program that automatically performs certain actions repeatedly at a much faster rate than a human. Bots can interact with webpages, submit forms, execute actions, scan texts, or download content. They can access videos, post comments, and tweet on social media platforms. Some bots, known as chatbots, can hold basic conversations with human users. A bot that performs a helpful service, such as customer service, automated chat, and search engine crawlers are good bots. At the same time, a bot that can scrape or download content from a website, steal user credentials, spam content, and perform other kinds of cyberattacks are bad bots. With a good number of bad bots performing malicious tasks, it is essential to manage bot traffic and protect the user web applications from bot attacks. By using Citrix bot management, users can detect the incoming bot traffic and mitigate bot attacks to protect the user web applications. Citrix bot management helps identify bad bots and protect the user appliance from advanced security attacks. It detects good and bad bots and identifies if incoming traffic is a bot attack. By using bot management, users can mitigate attacks and protect the user web applications.

Citrix ADC bot management provides the following benefits:

  • Defends against bots, scripts, and toolkits. Provides real-time threat mitigation using static signature-based defense and device fingerprinting.

  • Neutralizes automated basic and advanced attacks. Prevents attacks, such as App layer DDoS, password spraying, password stuffing, price scrapers, and content scrapers.

  • Protects user APIs and investments. Protects user APIs from unwarranted misuse and protects infrastructure investments from automated traffic.

Some use cases where users can benefit by using the Citrix bot management system are:

  • Brute force login. A government web portal is constantly under attack by bots attempting brute force user logins. The organization discovers the attack by looking through web logs and seeing specific users being attacked repeatedly with rapid login attempts and passwords incrementing using a dictionary attack approach. By law, they must protect themselves and their users. By deploying the Citrix bot management, they can stop brute force login using device fingerprinting and rate limiting techniques.

  • Block bad bots and device fingerprint unknown bots. A web entity gets 100,000 visitors each day. They have to upgrade the underlying footprint and they are spending a fortune. In a recent audit, the team discovered that 40 percent of the traffic came from bots, scraping content, picking news, checking user profiles, and more. They want to block this traffic to protect their users and reduce their hosting costs. Using bot management, they can block known bad bots, and fingerprint unknown bots that are hammering their site. By blocking these bots, they can reduce bot traffic by 90 percent.

  • Permit good bots. “Good” bots are designed to help businesses and consumers. They have been around since the early 1990s when the first search engine bots were developed to crawl the Internet. Google, Yahoo, and Bing would not exist without them. Other examples of good bots—mostly consumer-focused—include:

    • Chatbots (a.k.a. chatterbots, smart bots, talk bots, IM bots, social bots, conversation bots) interact with humans through text or sound. One of the first text uses was for online customer service and text messaging apps like Facebook Messenger and iPhone Messages. Siri, Cortana, and Alexa are chatbots; but so are mobile apps that let users order coffee and then tell them when it will be ready, let users watch movie trailers and find local theater showtimes, or send users a picture of the car model and license plate when they request a ride service.

    • Shopbots scour the Internet looking for the lowest prices on items users are searching for.

    • Monitoring bots check on the health (availability and responsiveness) of websites. Downdetector is an example of an independent site that provides real-time status information, including outages, of websites and other kinds of services. For more information on Downdetector, see: Downdetector.

Bot Detection

Configuring Bot Management by using Citrix ADC GUI

Users can configure Citrix ADC bot management by first enabling the feature on the appliance. Once users enable, they can create a bot policy to evaluate the incoming traffic as bot and send the traffic to the bot profile. Then, users create a bot profile and then bind the profile to a bot signature. As an alternative, users can also clone the default bot signature file and use the signature file to configure the detection techniques. After creating the signature file, users can import it into the bot profile. All these steps are performed in the below sequence:

image-vpx-azure-appsecurity-deployment-66

  1. Enable bot management feature

  2. Configure bot management settings

  3. Clone Citrix bot default signature

  4. Import Citrix bot signature

  5. Configure bot signature settings

  6. Create bot profile

  7. Create bot policy

Enable Bot Management Feature

Follow the steps given below to enable bot management:

  1. On the navigation pane, expand System and then click Settings.

  2. On the Configure Advanced Features page, select the Bot Management check box.

  3. Click OK, and then click Close.

image-vpx-azure-appsecurity-deployment-67

Clone Bot Signature File

Follow the steps given below to clone bot signature file:

  1. Navigate to Security > Citrix Bot Management and Signatures.

  2. In Citrix Bot Management Signatures page, select the default bot signatures record and click Clone.

  3. In the Clone Bot Signature page, enter a name and edit the signature data.

  4. Click Create.

image-vpx-azure-appsecurity-deployment-68

Import Bot Signature File

If users have their own signature file, then they can import it as a file, text, or URL. Perform the following the steps to import the bot signature file:

  • Navigate to Security > Citrix Bot Management and Signatures.

  • On the Citrix Bot Management Signatures page, import the file as URL, File, or text.

  • Click Continue.

image-vpx-azure-appsecurity-deployment-69

  • On the Import Citrix Bot Management Signature page, set the following parameters.

    • Name. Name of the bot signature file.

    • Comment. Brief description about the imported file.

    • Overwrite. Select the check box to allow overwriting of data during file update.

    • Signature Data. Modify signature parameters

  • Click Done.

image-vpx-azure-appsecurity-deployment-70

IP Reputation

Configure IP Reputation by using Citrix ADC GUI

This configuration is a prerequisite for the bot IP reputation feature. The detection technique enables users to identify if there is any malicious activity from an incoming IP address. As part of the configuration, we set different malicious bot categories and associate a bot action to each of them. Follow the steps below to configure the IP reputation technique.

  • Navigate to Security > Citrix Bot Management and Profiles.

  • On the Citrix Bot Management Profiles page, select a signature file and click Edit.

  • On the Citrix Bot Management Profile page, go to Signature Settings section and click IP Reputation.

  • On the IP Reputation section, set the following parameters:

    • Enabled. Select the check box to validate incoming bot traffic as part of the detection process.

    • Configure Categories. Users can use the IP reputation technique for incoming bot traffic under different categories. Based on the configured category, users can drop or redirect the bot traffic. Click Add to configure a malicious bot category.

    • In the Configure Citrix Bot Management Profile IP Reputation Binding page, set the following parameters:

      • Category. Select a malicious bot category from the list. Associate a bot action based on category.

      • Enabled. Select the check box to validate the IP reputation signature detection.

      • Bot action. Based on the configured category, users can assign no action, drop, redirect, or CAPTCHA action.

      • Log. Select the check box to store log entries.

      • Log Message. Brief description of the log.

      • Comments. Brief description about the bot category.

  • Click OK.

  • Click Update.

  • Click Done.

image-vpx-azure-appsecurity-deployment-71

Auto Update for Bot Signatures

The bot static signature technique uses a signature lookup table with a list of good bots and bad bots. The bots are categorized based on user-agent string and domain names. If the user-agent string and domain name in incoming bot traffic matches a value in the lookup table, a configured bot action is applied. The bot signature updates are hosted on the AWS cloud and the signature lookup table communicates with the AWS database for signature updates. The auto signature update scheduler runs every 1-hour to check the AWS database and updates the signature table in the ADC appliance.

The Bot signature mapping auto update URL to configure signatures is: Bot Signature Mapping.

Note: Users can also configure a proxy server and periodically update signatures from the AWS cloud to the ADC appliance through proxy. For proxy configuration, users must set the proxy IP address and port address in the bot settings.

Configure Bot Signature Auto Update

For configuring bot signature auto update, complete the following steps:

Enable Bot Signature Auto Update

Users must enable the auto update option in the bot settings on the ADC appliance.

At the command prompt, type:

set bot settings –signatureAutoUpdate ON

Configure Bot Signature Auto Update using the Citrix ADC GUI

Complete the following steps to configure bot signature auto update:

  • Navigate to Security > Citrix Bot Management.

  • In the details pane, under Settings click Change Citrix Bot Management Settings.

  • In the Configure Citrix Bot Management Settings, select the Auto Update Signature check box.

image-vpx-azure-appsecurity-deployment-72

  • Click OK and Close.

For more information on configuring IP Reputation using the CLI, see: Configure the IP Reputation Feature Using the CLI.

References

For information on using SQL Fine Grained Relaxations, see: SQL Fine Grained Relaxations.

For information on how to configure the SQL Injection Check using the Command Line, see: HTML SQL Injection Check.

For information on how to configure the SQL Injection Check using the GUI, see: Using the GUI to Configure the SQL Injection Security Check.

For information on using the Learn Feature with the SQL Injection Check, see: Using the Learn Feature with the SQL Injection Check.

For information on using the Log Feature with the SQL Injection Check, see: Using the Log Feature with the SQL Injection Check.

For information on Statistics for the SQL Injection violations, see: Statistics for the SQL Injection Violations.

For information on SQL Injection Check Highlights, see: Highlights.

For information about XML SQL Injection Checks, see: XML SQL Injection Check.

For information on using Cross-Site Scripting Fine Grained Relaxations, see: SQL Fine Grained Relaxations.

For information on configuring HTML Cross-Site Scripting using the command line, see: Using the Command Line to Configure the HTML Cross-Site Scripting Check.

For information on configuring HTML Cross-Site Scripting using the GUI, see: Using the GUI to Configure the HTML Cross-Site Scripting Check.

For information on using the Learn Feature with the HTML Cross-Site Scripting Check, see: Using the Learn Feature with the HTML Cross-Site Scripting Check.

For information on using the Log Feature with the HTML Cross-Site Scripting Check, see: Using the Log Feature with the HTML Cross-Site Scripting Check.

For information on statistics for the HTML Cross-Site Scripting violations, see: Statistics for the HTML Cross-Site Scripting Violations.

For information on HTML Cross-Site Scripting highlights, see: Highlights.

For information about XML Cross-Site Scripting, visit: XML Cross-Site Scripting Check.

For information on using the command line to configure the Buffer Overflow Security Check, see: Using the Command Line to Configure the Buffer Overflow Security Check.

For information on using the GUI to configure the Buffer Overflow Security Check, see: Configure Buffer Overflow Security Check by using the Citrix ADC GUI.

For information on using the Log Feature with the Buffer Overflow Security Check, see: Using the Log Feature with the Buffer Overflow Security Check.

For information on Statistics for the Buffer Overflow violations, see: Statistics for the Buffer Overflow Violations.

For information on the Buffer Overflow Security Check Highlights, see: Highlights.

For information on Adding or Removing a Signature Object, see: Adding or Removing a Signature Object.

For information on creating a signatures object from a template, see: To Create a Signatures Object from a Template.

For information on creating a signatures object by importing a file, see: To Create a Signatures Object by Importing a File.

For information on creating a signatures object by importing a file using the command line, see: To Create a Signatures Object by Importing a File using the Command Line.

For information on removing a signatures object by using the GUI, see: To Remove a Signatures Object by using the GUI.

For information on removing a signatures object by using the command line, see: To Remove a Signatures Object by using the Command Line.

For information on configuring or modifying a signatures object, see: Configuring or Modifying a Signatures Object.

For more information on updating a signature object, see: Updating a Signature Object.

For information on using the command line to update Web Application Firewall Signatures from the source, see: To Update the Web Application Firewall Signatures from the Source by using the Command Line.

For information on updating a signatures object from a Citrix format file, see: Updating a Signatures Object from a Citrix Format File.

For information on updating a signatures object from a supported vulnerability scanning tool, see: Updating a Signatures Object from a Supported Vulnerability Scanning Tool.

For information on Snort Rule Integration, see: Snort Rule Integration.

For information on configuring Snort Rules, see: Configure Snort Rules.

For information about configuring Bot Management using the command line, see: Configure Bot Management.

For information about configuring bot management settings for device fingerprint technique, see: Configure Bot Management Settings for Device Fingerprint Technique.

For information on configuring bot allow lists by using Citrix ADC GUI, see: Configure Bot White List by using Citrix ADC GUI.

For information on configuring bot block lists by using Citrix ADC GUI, see: Configure Bot Black List by using Citrix ADC GUI.

For more information on configuring Bot management, see: Configure Bot Management.

Prerequisites

Users need some prerequisite knowledge before deploying a Citrix VPX instance on Azure:

  • Familiarity with Azure terminology and network details. For information, see the Azure terminology above.

  • Knowledge of a Citrix ADC appliance. For detailed information about the Citrix ADC appliance, see: Citrix ADC 13.0.

  • Knowledge of Citrix ADC networking. See: Networking.

Azure Prerequisites

This section describes the prerequisites that users must complete in Microsoft Azure and Citrix ADM before they provision Citrix ADC VPX instances.

This document assumes the following:

  • Users possess a Microsoft Azure account that supports the Azure Resource Manager deployment model.

  • Users have a resource group in Microsoft Azure.

For more information on how to create an account and other tasks, visit Microsoft Azure documentation: Microsoft Azure Documentation.

Limitations

Running the Citrix ADC VPX load balancing solution on ARM imposes the following limitations:

  • The Azure architecture does not accommodate support for the following Citrix ADC features:

    • Clustering

    • IPv6

    • Gratuitous ARP (GARP)

    • L2 Mode (bridging). Transparent virtual server are supported with L2 (MAC rewrite) for servers in the same subnet as the SNIP.

    • Tagged VLAN

    • Dynamic Routing

    • Virtual MAC

    • USIP

    • Jumbo Frames

  • If users think that they might have to shut down and temporarily deallocate the Citrix ADC VPX virtual machine at any time, they should assign a static Internal IP address while creating the virtual machine. If they do not assign a static internal IP address, Azure might assign the virtual machine a different IP address each time it restarts, and the virtual machine might become inaccessible.

  • In an Azure deployment, only the following Citrix ADC VPX models are supported: VPX 10, VPX 200, VPX 1000, and VPX 3000. For more information, see the Citrix ADC VPX Data Sheet.

  • If a Citrix ADC VPX instance with a model number higher than VPX 3000 is used, the network throughput might not be the same as specified by the instance’s license. However, other features, such as SSL throughput and SSL transactions per second, might improve.

  • The “deployment ID” that is generated by Azure during virtual machine provisioning is not visible to the user in ARM. Users cannot use the deployment ID to deploy Citrix ADC VPX appliance on ARM.

  • The Citrix ADC VPX instance supports 20 Mb/s throughput and standard edition features when it is initialized.

  • For a XenApp and XenDesktop deployment, a VPN virtual server on a VPX instance can be configured in the following modes:

    • Basic mode, where the ICAOnly VPN virtual server parameter is set to ON. The Basic mode works fully on an unlicensed Citrix ADC VPX instance.

    • Smart-Access mode, where the ICAOnly VPN virtual server parameter is set to OFF. The Smart-Access mode works for only 5 NetScaler AAA session users on an unlicensed Citrix ADC VPX instance.

Note:

To configure the Smart Control feature, users must apply a Premium license to the Citrix ADC VPX instance.

Azure-VPX Supported Models and Licensing

In an Azure deployment, only the following Citrix ADC VPX models are supported: VPX 10, VPX 200, VPX 1000, and VPX 3000. For more information, see the Citrix ADC VPX Data Sheet.

A Citrix ADC VPX instance on Azure requires a license.  The following licensing options are available for Citrix ADC VPX instances running on Azure. Users can choose one of these methods to license Citrix ADCs provisioned by Citrix ADM:

  • Using ADC licenses present in Citrix ADM: Configure pooled capacity, VPX licenses, or virtual CPU licenses while creating the autoscale group. So, when a new instance is provisioned for an autoscale group, the already configured license type is automatically applied to the provisioned instance.

    • Pooled Capacity: Allocates bandwidth to every provisioned instance in the autoscale group. Ensure users have the necessary bandwidth available in Citrix ADM to provision new instances. For more information, see: Configure Pooled Capacity.

    Each ADC instance in the autoscale group checks out one instance license and the specified bandwidth from the pool.

    • VPX licenses: Applies the VPX licenses to newly provisioned instances. Ensure users have the necessary number of VPX licenses available in Citrix ADM to provision new instances.

    When a Citrix ADC VPX instance is provisioned, the instance checks out the license from the Citrix ADM. For more information, see: Citrix ADC VPX Check-in and Check-out Licensing.

    • Virtual CPU licenses: Applies virtual CPU licenses to newly provisioned instances. This license specifies the number of CPUs entitled to a Citrix ADC VPX instance. Ensure users have the necessary number of Virtual CPUs in Citrix ADM to provision new instances.

When a Citrix ADC VPX instance is provisioned, the instance checks out the virtual CPU license from the Citrix ADM. For more information, see: Citrix ADC Virtual CPU Licensing.

When the provisioned instances are destroyed or de-provisioned, the applied licenses are automatically returned to Citrix ADM.

To monitor the consumed licenses, navigate to the Networks > Licenses page.

Using Microsoft Azure subscription licenses: Configure Citrix ADC licenses available in Azure Marketplace while creating the autoscale group. So, when a new instance is provisioned for the autoscale group, the license is obtained from Azure Marketplace.

Supported Citrix ADC Azure Virtual Machine Images

Supported Citrix ADC Azure Virtual Machine Images for Provisioning

Use the Azure virtual machine image that supports a minimum of three NICs. Provisioning Citrix ADC VPX instance is supported only on Premium and Advanced edition. For more information on Azure virtual machine image types, see: General Purpose Virtual Machine Sizes.

The following are the recommended VM sizes for provisioning:

  • Standard_DS3_v2

  • Standard_B2ms

  • Standard_DS4_v2

Port Usage Guidelines

Users can configure more inbound and outbound rules n NSG while creating the NetScaler VPX instance or after the virtual machine is provisioned. Each inbound and outbound rule is associated with a public port and a private port.

Before configuring NSG rules, note the following guidelines regarding the port numbers users can use:

  1. The NetScaler VPX instance reserves the following ports. Users cannot define these as private ports when using the Public IP address for requests from the internet. Ports 21, 22, 80, 443, 8080, 67, 161, 179, 500, 520, 3003, 3008, 3009, 3010, 3011, 4001, 5061, 9000, 7000. However, if users want internet-facing services such as the VIP to use a standard port (for example, port 443) users have to create port mapping by using the NSG. The standard port is then mapped to a different port that is configured on the Citrix ADC VPX for this VIP service. For example, a VIP service might be running on port 8443 on the VPX instance but be mapped to public port 443. So, when the user accesses port 443 through the Public IP, the request is directed to private port 8443.

  2. The Public IP address does not support protocols in which port mapping is opened dynamically, such as passive FTP or ALG.

  3. High availability does not work for traffic that uses a public IP address (PIP) associated with a VPX instance, instead of a PIP configured on the Azure load balancer. For more information, see: Configure a High-Availability Setup with a Single IP Address and a Single NIC.

  4. In a NetScaler Gateway deployment, users need not configure a SNIP address, because the NSIP can be used as a SNIP when no SNIP is configured. Users must configure the VIP address by using the NSIP address and some nonstandard port number. For call-back configuration on the back-end server, the VIP port number has to be specified along with the VIP URL (for example, url: port).

    Note:

    • In Azure Resource Manager, a Citrix ADC VPX instance is associated with two IP addresses - a public IP address (PIP) and an internal IP address. While the external traffic connects to the PIP, the internal IP address or the NSIP is non-routable. To configure a VIP in VPX, use the internal IP address (NSIP) and any of the free ports available. Do not use the PIP to configure a VIP.

    • For example, if NSIP of a Citrix ADC VPX instance is 10.1.0.3 and an available free port is 10022, then users can configure a VIP by providing the 10.1.0.3:10022 (NSIP address + port) combination.

Citrix ADC VPX on Azure Deployment Guide

In this article