Instant Citrix Security How-to

The Citrix NetScaler and Access Gateway are one and the same device but with different licenses. The Access Gateway functionality can be enabled with the Access Gateway universal license. The universal license, by default, enables five users to connect concurrently. Additional concurrent user licenses can be obtained for the number required (for example, a 100-user license).

Before the task begins, please make sure you have configured NetScaler with the Netscaler IP address, that is for management purposes (it will prompt in the initial configuration), and without which you will not be able to access the device. Also, the latest NetScaler devices come with two management interfaces; take care to not plug them into the same virtual local area network (VLAN), which would cause loops and broadcast storms.

Inbound Internet traffic to your network should be avoided at all costs; hence it is always recommended to set up NetScaler in a DMZ zone that is isolated from the trusted network (your internal network) and the Internet. It acts as a buffer zone between two enemies and does not allow direct contact between them.

This can be achieved by physically locating the web servers that will be accessed by the public network in a different subnet and by blocking any traffic from going beyond the DMZ to the trust zone, or by configuring the internal and DMZ subnets in two different VLANs, or having NetScaler's legs in two boats—one in DMZ and the other in the trust network. We shall discuss each of these options in the following recipes:

LB-Basic_LB_Topology

We will now be configuring the DMZ and internal zone in different VLANs:

By default, NetScaler assigns monitors to each of the services configured; load balancing, by default, is the least connection.

Please note to configure Subnet-IPs (SNIPs) while creating multiple VLANs and bind them to the respective VLANs.

We will now configure SNIP/MIP.

Go to System | Networking | IP (here you can see all the types of configured and configurable IPs):

A multi-hop DMZ setup has several layers of firewall protection that provide extra security to the internal network. It divides the DMZ into two stages, hence two access gateways need to be deployed in this scenario, one for each stage:

The first recipe is pretty straightforward and has NetScaler in the DMZ and the server farm in the internal network. The VIP will be configured with a public IP and we can further restrict its access to the Internet by applying ACLs and also making use of external authentication.

In the second option, the access gateway in the first DMZ receives the client connections and redirects these connections to the web interface in the second DMZ. The access gateway in the second DMZ is a proxy that allows ICA traffic to traverse the second DMZ, to reach the backend server farm.

This section dwells on a few miniscule must-know facts on the Citrix NetScaler and its deployment.

Licenses

In the NetScaler Configuration Utility GUI under System | Licenses, there will be a tick mark for all the licenses that are activated in the box. Features that are not enabled but have licenses would be shown as Capture_notenabled:

Capture_notenabled.

The licenses can be downloaded from My Citrix (http://citrix.com/downloads).

To configure AAA on NetScaler, you need to start by creating an SSL certificate-key pair and bind it to the AAA vserver (the certificate request and the key can be generated on NetScaler and submitted to the Certificate Authority, also knows as CA, to receive the cert-key pair). The AAA vserver should then be associated with any traffic-management vserver (load balancing [LB] or content switching [CS]). DNS needs to be configured to assign hostnames to both the AAA vserver and the traffic management vserver; please note that both the hostnames should be in the same domain, while creating the cert-key pair uses the appropriate domain in the subject name. (Self-signed certificates will not work for AAA, as they are used for testing purpose only.) The procedure of configuring a cert-key request and binding it to a vserver and the DNS configuration will be shown in detail in the following sections of this chapter.

The AAA functionality can be used for simple traffic management as well as for virtual private network (VPN) functionality!

Triple A comes across as an important feature of the Citrix Netscaler, as it can be used from a simple load balancing environment to VPN, coupled with a wide range of external authentication types. In this section, we shall see how to set up a AAA vserver from scratch that can be bound to a LB or Content Switching vserver:

A step-by-step working of the client to server authentication through Netscaler will be shown using HTTP headers (an HTTP header trace taken on the IE browser was used for the setup here):

After the authentication is successful, the client gets redirected back to the LB vserver. This time, the AAA sends a cookie to the client so that the subsequent requests from the client would contain the same cookie. NetScaler looks at the cookies and directs the request to the appropriate backend service (according to the LB method configured). At any point in time, the following screenshot shows the CLI command, which when entered will show the number of active users connected:

The following diagram is a pictorial representation of the authentication request between the LB and AAA vserver:

This section will throw some light on debugging the external authentication issue.

Tips and troubleshooting

There are a few common issues that could be listed for for AAA:

• The certificate has to be trusted; if you are connecting with a security exception, AAA will not work. Another important note would be to check for certificate expiry.

• The NSC_TMAA cookie should be preserved by the browser for successive transactions by the client in either the same or different browsers. This can be verified by taking an ethereal or wireshark capture on the client machine.

• When there are multiple applications that need to be accessed in the same session and each of them open a new connection, the client might face an issue of authenticating multiple times. The same holds true if the browser is not able to preserve the cookie. In such conditions, there is an option on NetScaler to enable persistent cookies. This setting is available globally or can be restricted to only certain traffic policies that are be bound to the AAA vserver.

The following is a CLI command to enable persistent cookie setting on NetScaler for AAA traffic:

>set tm sessionParameter -SSO ON -httpOnlyCookie NO -persistentCookie ENABLED -persistentCookieValidity 30 [GLOBAL SETTING]

The following is a CLI command to enable a debug for AAA(CLI):

>shell
#cd /tmp
#cat aaad.debug [This command would enable aaad debug,to stop its press Ctrl+Z]

The following screenshot shows the debug logs for a successful authentication:

The surge protection feature of NetScaler is enabled either globally or at service level. This feature controls the number of simultaneous connections made by NetScaler to the backend server farm. Surge protection is enabled by default and hence for scenarios where surge protection is not necessary it needs to be disabled. Surge protection should not be enabled when the Use Source IP (USIP) mode is enabled because with the USIP mode the number of backend connections will increase, as the original client IP will be shown as the source IP, and hence connection re-use is ruled out. Therefore, when more and more connections form, surge protection will get aggressive and not work as expected.

Setting up surge protection on NetScaler is a very simple procedure. As discussed before, it is enabled by default on the NetScaler GUI. It can be found under System | Settings | Global System Settings:

By default, two values are set:

At service level, we have the surge protection checkbox under Advanced | Settings | Surge Protection:

It is important to keep the server functioning at a normal capacity, as overloading it may result in undesirable results, such as application crashes and unavailability of resources for clients. NetScaler's basic functionality is connection multiplexing between the client and server (per request based). Hence, whenever a new connection is made and surge protection is enabled, it would check for any free existing connection to the servers; if not, then according to the max client and max request value set at the service level, the connection will be served or put in the surge queue.

The length of the surge queue will decrease if any existing connection in the backend becomes free.

This section deals with certain tidbits that will come in handy with respect to surge protection.

If the rate at which requests hit NetScaler increase exponentially, the surge queue will become longer, hence it will be necessary to flush the surge queue. The following are a few simple network management protocol OIDs that retrieve the length of surge queue at the vserver level:

When the surge queue length becomes long and affects the availability of resources to the users, you can flush the surge queue with the following CLI command:

root@ns> flush ns surgeQ [-name <name>] [-serverName <serverName> <port>] 

We will start with the packet flow of NetScaler and where content switching comes into play. The following diagram is self-explanatory (it is not the entire packet flow to the receiver's endpoint; the focus here is only to CS and LB):

The content switching vserver can be used for HTTP/HTTPS/TCP and UDP protocols, and it can direct it only to another vserver, not to the backend service directly.

If you want to avoid the preceding condition, the following CLI command will help you achieve it (by default, the value is disabled):

root@ NetScaler> add cs vserver <name> <serviceType> (<IPAddress>)  [-stateupdate ( ENABLED | DISABLED )]

Content switching can be done based on the following client attributes:

Similarly, server-side differentiations can also be made based on the following attributes:

Citrix also has an additional feature (starting from NetScaler version 9.3) that dynamically selects the load balancing feature based on any criteria or condition provided in the CS action/policy:

>add cs action <name> -targetLBVserver <string-expression>
>add cs policy <policyName> -rule <RULEValue> -action <actionName>

The policy is then bound to the CS vserver

>set cs vserver CSVserver -caseSensitive ON

The load balancing vserver bound to the CS vserver need not have any IP address configured unless it is used in a different access as well.

We shall focus on a few case studies that we commonly come across, and that can be solved with the help of content switching:

Case 1: Customer ABC accesses an online shopping portal and gets redirected to a secure connection at the payment gateway. For this scenario, an HTTP LB vserver is used and is bound to the CS vserver, which is on HTTPS:

The configuration in the preceding screenshot shows that a CS policy as well as a responder policy is bound to the CS vserver named testVserver.

The CS policy works on directing the traffic to the target LB vserver (if there are no CS policies bound at all, it goes to the default LB vserver; this default LB vserver should be configured on the CS Vserver). The responder policy, if bound to the CS vserver works on HTTP requests before matching any CS policy.

The configuration is verified by using show cs vserver <vserver name>. A packet capture taken on NetScaler will clearly show the redirect from HTTP to HTTPS as <HTTP 302>.

If there is any traffic that doesn't match any specific CS policies that are bound, then it uses the default policy. If there is no default policy, the user will get an error – HTTP 1.1 Service Unavailable error message.

Case 2: The customer Star Networks has a single web application that contains two domains, namely www.starnetworks.com and www.starnetworks.com.edu and has a content switching setup, which works fine when accessing www.starnetworks.com, but throws an error when accessing www.starnetworks.com.edu.

This happens because the peceding domains are not the same; they are different and the certificate that is bound to the CS vserver would be of type www.starnetworks.com only. To resolve this issue, we can bind multiple certificates to the CS vserver with the Server Name Indication (SNI) option enabled. The SNI option can be enabled in the SSL Parameters tab (this would pop up only if the SSL protocol is chosen while creating the vserver).

The CLI command to enable SNI is as follows:

>bind sslvserver star_cs_vserver -certkeyname    -SNICert
> bind sslvserver star_cs_vserver -certkeyname     -SNICert

For each domain added, NetScaler will establish a secure channel between itself and the client. With this solution, you can avoid configuring multiple CS vservers.

Case 3: A Customer has a large pool of IP subnets that needs categorizing, and it would be a next to impossible task to configure that number of content switching policies; how does he go about deploying this scenario?

The solution is as follows:

The working of NetScaler in all three preceding scenarios is that it analyzes the incoming traffic directed to the CS VIP and parses through the bound CS policies, if any. If a match is found, it goes to the target LB vserver. If there are any other policies that are bound (for example, a responder policy or a rewrite policy), then the responder policy gets executed even before the CS policy is executed (since responder policies are usually applied to the HTTP requests).However, rewrite policies can be bound either at the CS or LB level, depending on whether the request or response needs to be modified.

To recap what we have seen in the case studies mentioned before, the first case helps us to do a simple redirect from HTTP to HTTPS using a responder policy bound at the CS level. The second case shows us how multiple certificates with the SNI option are used to solve domain differences that would otherwise cause issues. The final case study shows us the basic but handy setting to map IP address ranges to target load balancing vservers. An important thing to note – there are scenarios where the vserver and the services that are bound to them may be different ports altogether (for example, HTTP LB VIP would be listening on port 80, but the services would be on port 8080). In such cases, the redirectPortRewrite feature should be enabled.

This section concentrates on tidbits and troubleshooting techniques:

The most common problems faced without zombie cleanup is a drop in traffic, and slow responses and requests (page timeouts). This also could lead to high CPU usage, since the idle and inactive connections that are not cleaned up would only lead to unwanted usage of the resources. DOS attacks can be saved for a different chapter altogether, but certain types of attacks can be prevented using the zombie cleanup feature of NetScaler.

The time interval to be set in the zombie process is as follows:

root@ns>set ns timeout -zombie 140   (By default zombie timeout is 120)

In the GUI interface, it is under System | Change timeout values. At each level of configuration (that is, at the vserver, service, and server level) a client timeout can be configured to notify the zombie process to kick in once the timeout has expired.

For example, at the vserver level this command sets the time up to which NetScaler leaves the connection in the re-use pool:

root@ns>set vserver PacktLB_vserver -cltTimeout 120

Once the connections are in the re-use pool, the zombie timer kicks in and cleans up the connections once the timer has expired. There is a knob to disable the zombie cleanup:

set service "PACKT_service" -maxreq 1

This setting disables connection multiplexing as well. There would be a one-to-one mapping between the client and server.

Therefore, this setting in NetScaler is enabled by default for an interval of 120 seconds; it can be customized to suit our requirement, though in most cases it is recommended to leave it at default.

NetScaler can be set up in many different ways for GSLB, some of which are listed as follows:

Starting from NetScaler version 10, even with static proximity configured, there is an option to override the static mapping of location database with a specific DNS policy, and action to direct the traffic coming from a specific Local DNS (LDNS) server, or network to specific gslb services. Follow the next screenshot to statically configure the IP address and location database on GUI.

On the Configuration Utility panel, go to GSLB | Location to create static location entries:

The setup entails a main site that processes traffic all the time and a disaster recovery site that comes up when the main site goes down. The entire GSLB algorithm is DNS-based. The GSLB configuration can be used for the following:

The Citrix NetScaler Metric Exchange Protocol (MEP) is a channel of communication between NetScaler devices across various geographical locations; it works on TCP port 3011 and, to be secure, port 3009. It is a NetScaler proprietary protocol and is used in GSLB to monitor the health of the sites. There are also the typical monitors that are bound to the load LB vserver.

With MEP and monitors enabled, the health of the remote sites can be measured from the monitors. But if monitors are not enabled, then the health of the site is measured with the help of MEP. The CLI command to enable MEP is as follows:

root@ns>set gslb site Packtsite -metricExchange  ?
 ENABLED
 DISABLED

The site metrics, the network metrics, and persistence information are shared between the GSLB sites only if the MEP is enabled. An important note is to check if the feature is enabled before you get started with the GSLB configuration. If you are going with the static proximity type of GSLB, then you would need to load the location database on the NetScaler device. To verify whether the database is properly loaded, issue the show locationparameter command and check the current static entries. If the incoming traffic does not match any entry in the location database, then the request is processed using the round robin method.

We will focus on a few case studies, most commonly seen in GSLB.

Case 1: The three critical aspects for GSLB are the Gslb site, Gslb vserver, and Gslb service. The site address references NetScaler at each location. These three aspects are interlinked to make it easier for the traffic to be sent to the right location.

For example, there are two sites in this recipe, main and DR. You will have to repeat the configuration on both the devices:

The IP address that is used here can be a MIP or SNIP address.

Case 2: The previous section shows the basic GSLB setup. In this case study, we will see the Dynamic proximity process, where NetScaler chooses the site that has the least Round trip time (RTT). For the first time alone, NetScaler chooses a site using the round robin method and then begins its RTT calculation using the following three steps in the same order sequentially:

In the event that ICMP is blocked mid-way before reaching the site (anywhere on the Internet), it uses the second method listed (that is, DNS query), and finally a TCP handshake is used for the RTT calculation if the DNS query also does not give a response. This procedure is depicted in the next screenshot.

The RTT table can be viewed in the Configuration Utility tab under GSLB | LDNS Entries. If RTT shows as 0, then the time taken is less than one millisecond and if RTT shows as T-out then it indicates that the destination is unreachable. If all three preceding methods fail, it will take the backup LB method configured.

We can also use the static location database that maps the IP address range to the location area. This database is then loaded on the appliance. When the client's LDNS requests the site IP address from NetScaler, which acts as the ADNS, NetScaler parses through this location database to determine the location of the client's LDNS IP address, and then sends the nearest site IP address to the client. This method is called Static Proximity:

The CLI command to configure dynamic proximity is as follows:

>set gslb vserver packtGSLB -lbMethod MethodType
>set gslb vserver packtGSLB –lbMethod RTT

The RTT is calculated between the LDNS of the client and the site IP address.

In both the case studies, NetScaler first receives the DNS request in case it is acting as the ADNS for that particular domain, and according to the LB algorithm set, it directs the response either to itself or another NetScaler situated in a different geographical location. In this recipe, since we are only focusing on disaster recovery, the main site will continue to process traffic until it goes down.

The GSLB local and remote site is used for the Metric Exchange Protocol (MEP) communication to share the status and health of the sites. When configuring sites on NetScaler, there is an option for the public IP address. This can be left blank if there is no firewall in the picture that does any NAT translation.

To check if the configuration is accurate, run the following command:

root@ns# host www.packttest.com 172.16.1.6

The output will be similar to the following:

Using domain server: 
Name: 172.16.1.6
Address: 172.16.1.6#53 

The aliases are:

www.domain.com has address 171.12.12.33.

The following image shows the flow of GSLB at its basic level:

This section concentrates on tidbits and troubleshooting techniques:

Half-open TCP SYN connections are what constitute a DOS attack. A half-open TCP connection (as shown in next image) is a state wherein it is stuck before the three-way handshake is completed (SYN-SYN/ACK-ACK). NetScaler defends such attacks by not allocating any memory for all the SYN requests hitting NetScaler. Instead, it sends a cookie to each client that requests the connection and allocates memory only after the FINAL ACK message containing the same cookie is received. While NS uses this mechanism of inserting cookies into the new TCP connections, the old ones are not interrupted.

This DOS attack prevention does not need anything to be explicitly enabled:

Brute force, slow post, and zero window attacks can be stopped on NetScaler with the help of the rate-limiting feature. Priority queuing can also be used to defend against DOS attacks:

The preceding screenshot shows the zero-window packet in wireshark and legitimate clients in cases where the receive buffer is full and will send zero-window packets to the sender. How does NetScaler differentiate between a legit and an attack? This depends upon the number of concurrent small-window connections at a time and also on the MSS size (DDOS). The defense mechanism kicks in when the number of concurrent small-window connections are more than the number configured. If the attack has less than the number of simultaneous connections configured, then there is the zombie cleanup that kicks in when the connections move to the re-use pool.

This configuration can be fine-tuned more by setting the action that NetScaler takes for the DOS attack:

root@ns> add responder policy httpdospol "HTTP.REQ.URL.CONTAINS("www.packttest.com") && SYS.CHECK_LIMIT(\"httpdos_limit_ident\")" RESET

This responder policy can be bound globally. According to this policy, NetScaler would reset all the connections that come within the time interval. This reset action can also be changed to log a message to the user that says the limit has been reached and try again later:

root@ns>add responder action dos_act respondwith "\"Exceeded the maximum number of retries\r\n\r\n\""

Priority queuing of NetScaler helps in defending against DOS attacks by prioritizing the traffic hitting NetScaler; this can be done by filtering the traffic according to certain criteria and then prioritizing it. At a maximum, three priority queuing policies can be bound to a load-balancing Vserver. While configuring priority queuing, the priority, threshold, and weight needs to be specified along with an implicit action.

Each priority queuing policy can be set based on priority and weight:

>add pq policy packtPQpol -rule HTTP.REQ.URL.CONTAINS("/networktest")
-priority 1 -weight 30 [-qDepth <positive_integer> | -polqDepth <positive_integer>]

This policy will filter traffic based on URLs that contain networktest, give it priority 1, and assign a weight of 30. Weight should be set for efficient functioning, because without weights only the higher priority requests will continue getting served and the lower priority requests will be kept on the back burner. To avoid this situation, we go for weighted queuing where, for example, the three important departments in an organization—Engineering, IT, and Finance—can be configured as follows for serving traffic with priority queuing:

Engineering: Priority 1-Weight 30
IT                 : Priority 2-Weight 20
Finance        : Priority 3-Weight 10

From this configuration, after 30 requests have been served in Engineering, the packet flow will move on to serve 20 requests of IT, and so on in a cycle. This way, the Finance department is not completely ignored until there is nothing to serve for Engineering and IT.

From the preceding CLI command, we see an option to specify either queue depth or policy queue depth; the difference between the two is that the first option specifies the value of the total number of requests waiting to hit a particular vserver to which the policy is bound, and the latter specifies the total number of waiting clients belonging to the policy.

The HTTP DOS policies are also configured with something called qdepth and client detect rate. The queue depth, as mentioned before, would be the maximum number of connections placed in the surge queue at a time and the client detect rate would be the percentage of traffic before which the HTTP DOS policy should be applied.

Even for the client detect rate option, please note that an optimum percentage should be chosen for sending the JavaScript challenge responses. If the percentage is too high, it would flood the upstream routers or switches.

Distributed denial-of-service (DDOS) attack gets past the initial stages of defense, because it sends the complete HTTP header intact with all the information necessary to the server and then slows down, sending a few bytes per few seconds. Priority queuing can help in avoiding these attacks.

Before implementing any DOS protection, it is safe to monitor the traffic characteristics and so on. Also, instead of just enabling the DOS protection feature, and so on, and leaving it at default, it is recommended to fine-tune the setting according to your network topology.

We had a pre-sequel to the attack prevention in the previous recipe, touching only on the first line of defense; in this recipe we will discuss the app firewall module in a little more detail.

In the Configuration Utility, there is a checkbox for learning. Hence, before you set the box to production, you need to first gather a sample of the actual traffic hitting NetScaler and then enable blocking.

The HTTP referer headers are used to denote the previous page they were sourced from, and this can be exploited to get access to websites by masquerading as though coming from a valid website—it is similar to spoofing. In the App Firewall module, there is a feature called Start URL, where we can validate the referer header, if present. As shown in the following screenshot, Block, Learn, Log, and Stat are the actions that can be configured against each of the features.

There are two types of profiles that can be configured on the APP Firewall:

The difference between the two of them is that the Learn checks will not be enabled by default in the basic profile. Since the security checks all operations on the HTTP responses, it requires resources to retain and compare the information it sent previously to the users:

Learned Violations can be seen and altered according to the organization's requirements as shown in the preceding screenshot. Starting with NetScaler version 10, using the CEF (Common Event Format) logs, one can decide whether to deploy by clicking on Logs... or not.

Also in a high-availability setup, the learned data can be propagated to the secondary device, so it would help in a seamless failover (only on NetScaler version 10).

In this section, we are going to see how Start URL and the Cross Site scripting prevention work with NetScaler App Firewall:

Under the Learning Tab of the App Firewall profile, clicking on Start URL will show us the list of scripts it has learned from the traffic hitting the NetScaler:

With this data, we can select what is needed to be deployed. Once deployed, it creates a white list of URLs, which are obtained from all the responses during the user session. This functionality is called the URL closure and can be enabled under the Start URL feature (Go to the Security Checks tab of the App Firewall profile):

A simple setup is used to demonstrate the Start URL protection as shown in the preceding screenshot.

This protection can be tested by creating a query in the URL, for example, http://www.packttest.com, which is an LB VIP created with Netscaler. This URL is listed in the white list with the Start URL feature; however, http://www.packttest.com/?<script>alert(hi)</script> is not, and should be blocked as this is injecting a script along with the URL. To test this feature, we need to enable the Block checkbox in the Security Checks tab of the profile.

We could see the protection happening from the ns.log, after accessing the preceding URL:

When there is a violation of the rules, it is logged in the NetScaler BSD shell under /var/log/ns.log:

Here, along with the timestamp, we can see the URL being accessed as well as the <blocked> action taken by the App Firewall.

After learning and deploying a certain rule, we can see the rule in the running config:

>show run | grep packtpro
bind appfw profile packtpro -startURL "^http://www\\.packttest\\.com/$"

The second part of the testing is to check whether the same profile works with a CSRF attack.

The CSRF (Cross-Site Request Forgery) attacks work on logged-in user sessions, modifying the HTTP request. NetScaler adds a unique token to the forms that are sent to the users and validate the token on subsequent requests and responses between client and server.

The same setup and configuration used in the preceding demo is used here. We are going to test the site by using any link or URL on the webpage and add a script or query to the link while accessing, for example, the same VIP as used before, http://www.packttest.com, which opens up the web page, clicking on a link or URL on the web page http://www.packttest.com/citrix_products_netscaler.html?<script>alert(hi)</script>.

As we can see in the following screenshot, the ns.log has a log message stating that the packet is blocked due to a tag validation failure:

As always, it also displays the URL that is being accessed (outlined in the preceding screenshot).

Here is a HTTP header trace to show the transactions between NetScaler and the client:

GET /Test.xml?<script>alert(hi)</script> HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3)
Accept-Encoding: gzip, deflate
Host: www.packttest.com
Connection: Keep-Alive
Cookie: citrix_ns_id=SQIoGifoC0oF+GaOVYl3cCJDKTQA000

HTTP/1.1 200 OK
Pragma: "no-cache"
Content-Length: 99
Connection: close
<html>
<head>
      <title>THIS PAGE IS BLOCKED BY CITRIX APPLICAITON FIREWALL
    </title>
  </head>
</html>

As we can see in the preceding header, the session is already established and hence we see the cookie in the GET request of the client containing citrix_ns_id=SQIoGifoC0oF+GaOVYl3cCJDKTQA000.

NetScaler gracefully terminates the connection with a 200 OK message, as can be seen from a wireshark capture taken on NetScaler (see the following screenshot). The FIN and PUSH flags are highlighted in the screenshot.

There are other functionalities, such as masking the credit card numbers and other safe objects while sending responses to the users. The safe objects are configurable on NetScaler, such that when traffic hits the NetScaler, the App Firewall module checks for any safe object pattern in the requests and responses:

Role-based access control

Role-based access control is a feature that is used to control the admin access rights to NetScaler. We can configure the command policy to add/remove commands, show commands or restrict commands, to users. A predefined command policy is shown in the following screenshot:

The CLI command to configure a test user:

CLI>add system cmdPolicy test ALLOW "(^\\S+\\s+serviceGroup.*)|(^\\S+\\s+vserver.*)"

The Citrix App Firewall module comes in at both the request- and response-side processing of traffic. After the content switching or LB vserver (whichever is configured as client facing), the App Firewall module parses through the packets to check for anomalies. Similarly at the response side after SSL decryption, rewrite (if any) content filtering and then App Firewall before sending the response to the client.

In the How to do it... section of this recipe, we saw the configuration setting for defense against Start URL and CSRF attacks. The AppFw first learns the URLs passing through it using the Learning module before we deploy the rules according to our requirement. We would be able to see the rules learnt by the AppFw in the Managed Learned Rules.

In the Role-based access control section, we saw how to control the management access of NetScaler for different users at different levels. We would be able to restrict them based on read-only commands, read/write commands, superuser commands, and so on.

App Firewall needs to be used with utmost planning as it is resource intensive. In sites where Integrated Caching and App firewall is used, CPU usage will tend to be on the higher side. All NetScaler MPX series that have 4 GB of RAM are capable of handling both caching and App Firewall implementation. Typically, the Application Firewall sits in front of the caching module and the best part about this is it does not require remodeling one's network; instead it is similar to adding on the existing network, making it more secure.

In this section, we will see the new features available in NetScaler's latest versions and also a few known issues.

Basic versus smart access: these are the two modes provided by Access Gateway to the users. The difference between the two modes is that basic has unlimited ICA connections and only a platform license is required; for smart access, both Platform and universal licenses are needed. The smart access mode allows full VPN connectivity, EPA, clientless VPN, and so on, while using Citrix Receiver to access the applications through the VPN.

AGEE acts as an ICA proxy for XenApp and XenDesktop; it seals the traffic with HTTPS before it is sent to the client. Only full SSL certificates signed by a trusted certificate authority (CA) are required by the AGEE Vserver for the VPN to work; self-signed certificates cannot be used.

EPA (endpoint analyses) scans can be configured on the Access Gateway to implement security on hosted desktops and applications, and user access can be controlled based on this.

Consider the cases discussed in this section:

Case 1

First we are going to set up the VPN in basic mode access:

1. Set up an AGEE Vserver, bind the appropriate SSL certificate to it, and select the access mode as basic.

   SSL is the only protocol available while configuring the AGEE Vserver.

   

   If there is a root and intermediate certificate for the server certificate obtained, they also need to be loaded onto the box and linked to each other.

   The following screenshot shows the server certificate linked with the intermediate root CA, which in turn is linked to the root CA certificate:

   

2. Configure bookmarks and FTP share links to local intranet sites and applications.

3. Under Access Gateway, go to Global Settings.

   There will be four tabs namely Network Configuration, Security, Client Experience, and Published Applications.

   Under Network Configurations, there is an option to set the DNS IP, which enables you to use any internal FQDN, and advanced options on the same tab let you configure how to use IIPs (Intranet IPs), and so on.

   The Security tab has a default operation, ALLOW/DENY, that can be set, and advanced options where we can restrict the users based on EPA scans and policies.

   Under the Client Experience tab, options such as SplitTunnel (which has two options, ON or OFF, that define whether the traffic from the client should completely go through the tunnel or use both the VPN tunnel and local inter-network), Session, and Client idle timeout, and an option to specify a homepage (optional) are available. Single sign-on to web applications and client cleanup prompt (prompts when logging out of VPN) are also available.

   Published Applications are also available to set ICA proxy to ON or OFF and to set the web interface link address. The ICA proxy settings come into the picture, when deciding between full, clientless, and full-client VPN.

4. Access the fully qualified doman name (FQDN) specified in the certificate, using HTTPS, and make sure you do not get the security warning. If you do get, please check if the certificates are loaded in your local machine along with the intermediate certificate, if any (Go to Start | Run and type mmc). After loading the certificates, please verify that the certificates can be seen under Tools | Internet Options | Content | Certificates.

An intranet IP (IIP) pool can be configured, if you require the client connecting with only the range of IP addresses specified:

This IIP pool can be set in Global Settings or under AGEE Vserver | Intranet IPs. The preceding screenshot shows the Intranet IP configuration and the following screenshot shows the Global Settings page. The Intranet IP is used to assign IP address to the users connecting to the VPN. If the range of IP addresses is exhausted by the users, either an IP address can be reclaimed from a user who is in a logged off state or there is a setting that allows MIP to be used as IIP when no other address is available:

So, instead of global settings, if customized per user or per application, we can configure session profile and policy under Access Gateway | Policies | Session.

add vpn url test test "http://10.105.225.201"
add vpn intranetApplication Remote-Desktop TCP 10.105.225.216 -destPort 3389 -interception PROXY -srcIP 127.0.0.1 -srcPort 3389
add vpn intranetApplication Test-1.1.1.1 ANY 1.1.1.1 -destPort 1-65535 -interception TRANSPARENT
add vpn vserver packtAGvserver SSL 10.105.225.206 443 -appflowLog DISABLED
add vpn sessionAction testpro -splitTunnel ON -defaultAuthorizationAction ALLOW -SSO ON -clientlessVpnMode OFF -clientlessModeUrlEncoding TRANSPARENT -clientlessPersistentCookie ALLOW

CLIENT.REG(HKEY_LOCAL_MACHINE\\Software\\Symantec\\Norton\
AntiVirus_Version).EXISTS

The following diagram shows the working of CAG in smart access mode:

In smart access mode, after the authentication of the client, the Access Gateway will forward the authentication to the web interface (this is configurable during the site creating process, where you require the authentication to take place at the CAG or WI). The XenApp services' site that is created will appear to the user when he/she is met with all the eligibility criteria (scan).

How this works is briefly explained in the following steps:

In this section, we will see a few tips and important points to remember while deploying Access Gateway Enterprise Edition.

Collecting events and faults of devices on a regular basis can be done with the help of the CC, although NetScaler also has a basic level monitoring applet from which we can view the connections per second under load balancing, content switching, and so on.

The ports that are needed to be open between the CC server and NetScaler are as follows:

The discovery process of the CC as well as the event logs of a device is automatic.

In this section, we will start with monitoring done on NetScaler and continue further with how to enable discovery automatically in the command center.

On the Netscaler Configuration Utility, there are three tabs: Configuration, Monitoring, and Reporting Dashboards.

The SNMP part of the config on NetScaler is simple and straightforward:

Now let's discuss the Citrix CC—an alternate Citrix solution provided at a much higher level and a Citrix standard for easily managing multiple devices. One can run the CC as a Windows discovery process. How you go about configuring it to automatically discover NetScaler, other Access Gateway and App firewall devices is discussed in the following steps:

The discovery process starts after adding the devices to the map. The discovery works based on hostname or IP address set in the map.

We can view the status of the discovery process in the CC under the Citrix Network tab. Click on the name of the map configured, and under the map, click on the Discovery status.

The NetScaler MPX devices, such as 10500, 12500, and 15500, are rate limited per the license purchased, meaning there is a limit on the number of packets per seconds. SNMP traps can be configured to send a trap message when the threshold is exceeded.

The Monitoring tab of the NetScaler shows the number of connections, the number of TCP Est server connections, resource utilizations, and so on.

The following screenshot shows a sample screen showing the number of connections established for an LB vserver:

Similarly, CPU and memory utilizations on the device can also be seen on the Monitoring and Reporting pages. The difference between the Monitoring and Reporting pages is that the Monitoring page provides runtime statistics whereas the Reporting page helps collect data for a particular period that can be set to start from the previous hour to the previous year.

The discovery process in the CC is as follows:

This section will deal with a few tidbits on SNMP and the Citrix CC: