Post to Twitter
Load Balancing Auto-Configuration for SAP using Workflow Studio and NetScaler
At the tail end of our certification process at SAP, Citrix engaged in a unique opportunity to make use of the SAP APIs, using Workflow Studio to auto-configure the Citrix NetScaler for Load Balancing. The way it works is, Workflow Studio polls the SAP API, reads the response, and then based on the results in the response, configures the NetScaler Load Balancing groups that map directly to the SAP servers running in the server farm.
SAP has a community group dedicated to the development of their APIs, please reference the latest blog post Catching Up with Deployment and Operations Automation, describes the SAP APIs.
The SAP Community Definition Group (CDG) - titled "PCDG 97 NetWeaver Infrastructure APIs for Network Solutions" - is focused on automation of network-application integrated configuration and operation. As the group title implies, the SAP NetWeaver technology platform includes APIs, which are used by the NetScaler ADCs (load balancers) to auto-configure themselves as proxies for multi-instance SAP application systems. Using Citrix Workflow Studio, the SAP APIs are polled on a regular basis so that the NetScaler ADCs can react to SAP application instance changes during production runtime.
If another application instance is brought up, let's say for providing more computing capacity for an increasing end-user load, or if an instance is brought down temporarily for maintenance, Workflow Studio communicates with the NetScaler ADC to adjust load balancing automatically without any manual administrator intervention. There is no more wait, or lengthy change management required to provision applications.
Workflow Studio, NetScaler and SAP API Use Cases:
Use Case 1: (auto-configure new SAP services).
Workflow Studio sends a URL request to the SAP Message Server, and receives a response. Workflow Studio parse's the response, looking for specific SAP generated patterns. WFS then uses this information to configure a Load Balancing Virtual Server inside of the Citrix NetScaler.
Use Case 2: (dynamic configuration).
Workflow Studio repeatedly queries the SAP API. WFS studio can determine hostnames, ip addresses, port numbers, and whether an SAP server is coming online or going down. When a SAP server comes online/goes down - WFS detects this change, and then takes action on the Citrix NetScaler, to add/remove the SAP service from the Load Balancing group - automatically.
Use Case 3: (graceful shutdown).
Workflow Studio queries the SAP API, determines a SAP server is going down, and based on the response, waits until all existing sessions have been retired, before removing the server from the Load Balancing group . During the shutdown period, no new sessions are added to that SAP server, providing a graceful shutdown of the SAP service. This way, there are no TCP resets sent to existing sessions. New logins are routed to a different server.
Read the SAP article here.
Tap into the power of AppExpert!
Securing Web Applications with an Application Firewall
I have been working with Application Firewalls for quite a few years - many times to protect web applications published in languages and character sets that I didn't understand. Frequently, I have seen these Application Firewall deployment projects get bogged down in pursuit of the perfect policy set.
I have also seen many situations in which this process and application changes actually break these applications.
The NetScaler Application Firewall deployment can also be subject to these issues since the appliance provides extensive application firewall features. Even with the learning capabilities, creating the ideal set of security policies for any application can be a trial and error process that can take significant time.
In this blog, I would like to share an implementation methodology that shortens the deployment, and helps avoid breaking the applications to be protected. Experience has shown that approaching the configuration of the Application Firewall in stages is the key to timely success. This methodology is effective for all types of applications and their needs.
To alleviate the time and risk of varying degrees of policy complexity, break the task into stages. That is, separate the policy configuration into groups of ascending risk. While some may raise the point that a simplified protection policy set is not complete, it must be remembered that protection stages will build upon each other, and will be better than allowing unfiltered access while all policies are in learning or logging/warning mode.
The benefit of staging is that a basic set of policies are made operational. Then, the following stages will consist of conducting a repeatable process of "policy tightening" procedures as required by the application.
Stage I
When configuring the NetScaler Application firewall policies, start with some of the basic protections. Activating the simple, generic policies almost never produce false positives. These typically include: 
- Protect against Cross Site Scripting (XSS) attacks
- Protect against SQL Injection attacks
- Protect against Buffer Overflow attacks
- Prevent Credit Card Leakage
- Prevent access to system files
- Alter the contents of the server headers
Activating these policies will typically not break applications. As such, a small user community - with etc/hosts overrides - can be used to validate the configuration over a fairly brief validation period.
More importantly, this is a great start. These policies create security effectiveness that can typically be rated as a level seven on scale of zero though nine (you can never get to a perfect "10" in security).
Stage II
The next stage will include applying policies that require more application validation to determine the application specific relaxation adjustments ("policy overrides").
But first, don't forget to ask yourself if this application actually requires tightened policies.
If so, Stage II protections should be sequenced - Cookie Tampering prevention should be blocked first. Then, move on to blocking tampering with the values of parameter and/or hidden form fields.
Start with cookie poisoning prevention ("Cookie Consistency"). It will be likely require the least number of relaxations. This will build on the Stage I successes most rapidly.
To do this, use the learning process to identify the cookies that are legitimately altered between the response and request process. Minimally, relaxations will be required for cookies that are set and modified by third party monitoring services. Again, because of the staging, this learning can happen while the basic policies are in place and actively applying their protection mechanisms.
If further tightening is required, focus on creating policies that prevent users from tampering with the values of parameter and hidden form fields. This is achieved by activating "Field Consistency" learning in the NetScaler application firewall. Depending on the architecture of the application or a frequent use of client side scripting, these policies carry a higher risk of blocking legitimate requests. These policies thus require a more extensive learning period and associated relaxation overrides.
It should also be noted that these Stage II policies and their relaxations do have a tendency to be susceptible to producing false positives as applications change, and should be re-evaluated in conjunction with major application changes.
Stage III and Beyond
If the application is contains super sensitive information, and undergoes frequent changes, further security configuration may be required.
Stage III typically involves enforcing field formats and enforcing user navigation paths. Adding restrictions to field input types, such as date formats, and more, will require further time for learning these application attributes. Be aware that these policies will also be more likely to be sensitive to application changes.
Enabling the "Start URL" facility allows users to access only the specifically stated URL types. Due to the flexibility inherent in application architectures, however, these restrictions may require modification to include additional request types present in a particular application.
Lastly, carefully consider activating "URL Closure" to control 
the flow of access by users. Enforcement of this policy set disallows users from navigating to locations not previously offered by an application response. These policies may require significant application validation if client side scripts modify URLs, or if FLASH objects contain links.
The above policies tend to bend the needle towards the nine level and will be more likely to cause false positives during policy refinement or when the application changes. Leaving these to Stage III, however, allows continued protection afforded by the policies of Level I and Level II during the refinement, however.
Summary
Personally, when I plan my application firewall deployments, I always attack 
the assignment in the phases outlined above. I focus on the quick return policies first. Then I take time to consider if the sensitivities of the specific application even warrant the extra effort of going all the way to Stage III. This last question can produce some interesting answers that pit my application security ideals against the practicalities driven by the depth of my current to-do list.
And then, of course, this staged approach may be completely ignored in situations in which a specific application just suffered from an attack through a specific Level III vulnerability. Such situations may warrant overriding the staged approach and focusing on addressing the impacted vulnerability immediately.
Also, don't forget to sign on to MyCitrix and download the Application Hacking Kit and actually try some of the most common application attacks on the BadStore application!
Canonical Hostnames
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
The goal of the following rule is to force the use of a particular hostname, in preference to other hostnames which may be used to reach the same site. For example, if you wish to force the use of www.example.com instead of example.com, you might use a variant of the following rules.
Example : changing example.com to www.example.com
Apache rewrite:
RewriteCond %{HTTP_HOST} !^www.example.com
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{SERVER_PORT} !^80$
RewriteRule ^/(.*) http://www.example.com:%{SERVER_PORT}/$1 [L,R]
RewriteCond %{HTTP_HOST} !^www.example.com
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://www.example.com/$1 [L,R]
AppExpert rewrite:
add responder action act1 redirect '"http://www.example.com:"+CLIENT.TCP.DSTPORT+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HOSTNAME.CONTAINS("www.example.com")&&!HTTP.REQ.HOSTNAME.EQ("")&&!HTTP.REQ.HOSTNAME.PORT.EQ(80)&&HTTP.REQ.HOSTNAME.CONTAINS("example.com")' act1 bind responder global pol1 100 END
add responder action act1 redirect '"http://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HOSTNAME.CONTAINS("www.example.com")&&!HTTP.REQ.HOSTNAME.EQ("")&&HTTP.REQ.HOSTNAME.PORT.EQ(80)&&HTTP.REQ.HOSTNAME.CONTAINS("example.com")' act1 bind responder global pol1 100 END
Tap into the power of AppExpert!
Canonical URLs
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler. On some Apache web servers there is more than one URL for a resource. Usually there are canonical URLs (which should be used and distributed as a best practive) and those which are just shortcuts, internal ones, etc. Independent of which URL was supplied with the request, the user should only see the canonical one URL in the response.
Example : converting URL /~user to /u/user.
Apache rewrite:
RewriteRule ^/~([^/]+)/?(.*) /u/$1/$2[R]
AppExpert rewrite:
Add responder action act1 redirect '"/u/"+HTTP.REQ.URL.AFTER_STR("/~")' -bypassSafetyCheck yes Add responder policy pol1 'HTTP.REQ.URL.STARTSWITH("/~") && HTTP.REQ.URL.LENGTH.GT(2)' act1 Bind responder global pol1 100
Tap into the power of AppExpert!
SAP certifies NetScaler v9.0 and Branch Repeater/WANScaler v4.5 solution
On 3/31/2009, SAP certified Citrix NetScaler v9.0 and Citrix Branch Repeater/WANScaler v4.5 as an integral solution to improve the delivery of the SAP applications. For SAP Portal, the Citrix NetScaler & Branch Repeater/WANScaler solution improved response time to clients. For downloads and backend operations from SAP Composite and ERP servers, response time was also improved.
SAP customers have hundreds of branch offices with a mixture of small and large offices, and a global distribution. It is important to have a solution which optimizes, simplifies and accelerates the delivery of the SAP applications. During certification testing it was proven that the NetScaler and Branch Repeater/WANScaler products improve performance of SAP applications through acceleration, provide security through HTTPS connections, and provide reliability & high availability through load balancing.
Read more about NetScaler here.
Read more about Branch Repeater/WANScaler here.
Tap into the power of AppExpert!
Rate Based Policy Enforcement:
New in NetScaler 9.0 are Rate-Based policies which can be used to control, limit and throttle traffic to various servers. Rate Based Policies use the advanced expression syntax found in the Policy Infrastructure (PI) format of the NetScaler, which is also new for 9.0.
You can monitor the rate of traffic that flows through virtual servers or other User defined entities that are associated with different virtual servers, including URLs, domains, and combinations of URLs and domains.
You can control Citrix NetScaler behavior based on the traffic rate, including throttling the traffic flow if it is too high, caching information based on the traffic rate, and redirecting traffic to a new load balancing virtual server based on the traffic rate. You can apply rate-based monitoring to HTTP and DNS requests. You configure traffic rate limit identifiers to monitor the rate of traffic. These identifiers can include filters, known as rate limit selectors, to restrict monitoring (for example, based on IP addresses or subnets). You specify traffic rate limit identifiers in rules for advanced policies in any feature where these identifiers may be useful, including Rewrite, Responder, DNS, and Integrated Caching.
Rate-based monitors can be based on the number of HTTP or DNS requests, number of packets, transactions or amount of bandwidth being used. This is useful for preventing overloads on a network, preventing security attacks, and diverting traffic once it reaches a certain watermark.
More on Rate-Based Policy Enforcement can be found in the NetScaler Traffic Management Guide.
Tap into the power of AppExpert!
The Reporting tool of Citrix NetScaler provides built-in reports that display statistics collected by the nscollect utility. You can also create and customize reports. The reports use charts to display the statistics. You can modify the charts and add new charts. You can also modify the operation of the nscollect utility and stop or start its operation.
You can import log data from a different NetScaler, or from a previous time period on the same NetScaler, across different software releases.
Read more about Reporting in the NetScaler Administration Guide.
Compression
TCP Connections
SSL Offload
Bandwidth
CPU & Memory
Tap into the power of AppExpert!
Cost Savings, Green Benefits and Improved Server Management.
Citrix Systems, Inc. (NASDAQ: CTXS), the global leader in application delivery, recently announced that leading enterprise resource planning (ERP) manufacturer SAP AG will be virtualizing an estimated 500 servers with Citrix® XenServer™ by the middle of 2009. SAP has also deployed Citrix® XenApp™ application virtualization technology to deliver applications to both SAP employees and external partners. In addition, SAP expects to receive the benefits that a combined XenServer and XenApp solution provides - such as streaming standardized workload images and superior management functionality - which the company anticipates will generate a 35 percent savings in terminal server costs.
SAP was looking to consolidate its server infrastructure and also wanted to create a much more flexible and dynamic computing architecture. Following an extensive test of XenServer, the company decided to move forward with a multi-stage roll-out of the server virtualization solution onto 500 servers, initially in the company's Saint Leon Rot, Germany office. In the next phase of the project, the servers that power the worldwide training centers will be virtualized, followed by the project management division with several hundred development, test, and support environments. After the server virtualization project in Germany is complete, the roll-out will continue at the end of 2009 to SAP's offices in Asia and the United States.
SAP has also deployed Citrix XenApp application virtualization technology to deliver more than 40 applications, including Microsoft Office and the SAP Business Suite software, to its entire user base. In total, there are more than 50,000 end users who access the XenApp infrastructure to work on tasks such as product development and support.
Its powerful AppExpert!
Integrating IWSVA 3.1 with Citrix NetScaler
Trend Micro InterScan Web Security Virtual Appliance 3.1 (IWSVA 3.1) is both a horizontally scalable (increasing capacity through additional servers) and vertically scalable (increasing capacity through CPU / memory or disk improvements) product and thus has clear options for increasing capacity and lowering latency.
However, IWSVA 3.1 does not offer built-in load balancing or high availability functionality in the standalone product. Customers desiring this functionality in the standalone IWSVA 3.1 solution must incorporate a third-party product to meet these needs.
The Citrix NetScaler is a powerful solution that matches the performance capabilities of the IWSVA 3.1 application while providing the key business continuity and load distribution functionality that enterprise environments require. Here are some recommended configurations when using IWSVA 3.1 with Citrix NetScaler:
- Citrix NetScaler placed in Transparent mode. This configuration does not require any endpoint browser modifications. This simplifies deployments.
- Trend Micro IWSVA 3.1 in Forward Proxy Mode. Although Citrix NetScaler in transparent mode provides endpoint transparency, you must still place IWSVA 3.1 in forward proxy mode for this functionality to work. This means that all upstream devices will see the MAC and IP addresses of the scanning IWSVA 3.1, not those of the endpoint. This may affect some gateway firewall rules or other applications. Citrix requires an identifying path to distribute load and so cannot aggregate traffic across multiple IWSVA 3.1s while the IWSVA 3.1 cluster is in Forward Proxy mode.
- Citrix NetScaler using "Source IP" persistence. Persistence takes precedence over a configured Load Balancing policy. This ensures that specific endpoints pass through to the same IWSVA when state information is available.
- Citrix NetScaler using the "Least Connections with LRTM" load balancing algorithm. If your environment does not require specific state continuity (in other words, it is acceptable to allow endpoints to pass through any available IWSVA 3.1 for scanning), this algorithm monitors the current number of connections on all IWSVA instances and forwards the incoming requests to the IWSVA with the fewest busy connections.
Its powerful AppExpert!
Entity Templates
An entity template simplifies configuration by providing a set of configured defaults for a policy, service, action, or other configuration entity. After you create an entity template, it can be reused with specific instances of entities of the same type. For example, an entity template created for Load Balancing, can be used to create the same load balancing configuration on the same load balancer, or can be used on a different NetScaler or NetScalers to create the same load balancing configuration.
Entity Templates are most helpful when you have built your configuration for an entity such as load balancing and want to duplicate it across the organization's load balancers without having to re-type all of the configuration commands. In fact, the entity template manager, will allow you to prompt for certain configuration parameters to be input by the user, such as IP Address and port number, at the time of import, which might be specific to a certain locality.
Application Templates
The NetScaler includes the ability to create and manage application templates that provide the administrator a way to configure the NetScaler to handle application-specific traffic without directly configuring NetScaler entities. An application template is a reusable bundle of application's configuration information and can be exported after creation for use on other NetScalers. Also, these templates can be created once and then re-used across multiple NetScalers.
Application vs. Entity Templates
Entity Templates simplify configuration by providing a set of configured default for a specific configuration entity, such as load balancing, rewrite or content switching.
Application Templates simplify configuration by providing configuration details for all entities for an Application, such as Sharepoint, SAP, Oracle, or other web based applications. Application Templates are more comprehensive and contain configuration details for caching, compression, load balancing, ssl offload, rewrite, filtering, responder and application firewall. For one application you might have several policies in each of these categories that are saved into an Application Template.
Both Entity and Application Templates can be exported and imported for ease of use across different NetScalers. All of the configuration policies, including all expressions, pattern sets and policy labels are exported with the Entity or Application Template - once you define your policies, you don't have to define them again.
Watch how easy this is:
Tap into the power of AppExpert!
EasyCall Conferencing
One of the larger expenditures for enterprises is the cost of voice communications, specifically conference calling. Most enterprises use an outside vendor to host the conference calling capabilities for global communications between internal employees and external participants. You can completely do away with that cost with EasyCall Conferencing. Here is how it works...
EasyCall Conferencing, which is a feature of EasyCall, allows EasyCall users to quickly set up ad-hoc conferences by sending participants an EasyCall Conferencing URL. Participants join a conference call simply by clicking a URL instead of having to dial a conference phone number and complex access codes. The calls are hosted on the EasyCall Gateway, providing toll-free access at much lower cost than commercial audio conference services.
To enable external users to join EasyCall Conferences, join requests must be proxied to the EasyCall Gateway from the internet as the EasyCall Gateway is always installed inside the corporate firewall. This is similar to many web applications that require protected external access, and the HTTPS proxy is simple to configure on the Citrix Netscaler to provide the necessary SSL Offloading and Content Filtering.
The Citrix NetScaler System provides continuous service availability through application-level protection by blocking attacks and delivery of the EasyCall application securely. The Citrix NetScaler Content filtering prevents unwanted requests from reaching the EasyCall Gateway.
The EasyCall Conferencing configuration template for the NetScaler policies is provided free of charge right here on our community website. Just import it, and your NetScaler is setup for EasyCall Conferencing.
Together, the EasyCall Gateway and NetScaler provides a low-cost, non-recurring charge, to host global conference calls with your own equipment, making it easy for participants to join just by clicking a URL ... no cryptic meeting codes or passwords.
Download the EasyCall Conferencing / NetScaler Deployment Guide Guide.
Download the EasyCall Conferencing - NetScaler AppExpert Configuration Template.
Watch how easy this is:
How it will look in your network:
Download the EasyCall Virtual Appliance here.
Get the NetScaler here.
Tap into the power of AppExpert!
HTTP Callouts
New in NetScaler 9.0 is the ability to perform a callout using HTTP to an external server. An HTTP Callout is a means to process incoming packets on the NetScaler using an external service that can be a virtual server on the NetScaler itself, a back-end server, or an third party service.
Traditionally, the NetScaler used to verify these packets internally using in-built policies but with specialized services being available for validation, they can be integrated with the NetScaler using this feature.
An HTTP callout will consist of a NetScaler policy expression that can send a simple HTTP request to an external service, wait for the response and then parse the response to produce a simple result. The result will then be used like any other policy expression evaluation result.
The HTTP callout expression:
SYS.HTTP_CALLOUT(<name of HTTP Callout>)
To define the HTTP callout:
set policy httpCallout <name>
[-IPAddress < ip_addr|ipv6_addr>]
[-port <port>]
[-vServer <string>]
[-returnType <returnType>]
[-httpMethod ( GET | POST )]
[-hostExpr <string>]
[-urlStemExpr <string>]
[-headers <name(value)> ...]
[-parameters <name(value)> ...]
[-fullReqExpr <string>]
[-resultExpr <string>]
Where:
-returnType must be one of TEXT, NUM or BOOL.
-IPAddress IP address of the server to which callout is made
-port Port of the server to which callout is made
-vserver must be one of the vservers added using the "add lb/cs/cr vserver" command. The service type of the vserver must be HTTP.
-httpMethod could be GET or POST.
-hostExpr Complex PI string expression for value of the Host header.
-urlStemExpr Complex PI string expression for generating the URL stem.
-headers Every header name must have a corresponding value. These headers will be inserted in the request. Header name is string. Header values are Complex PI Expressions.
-parameters Every parameter name must have a corresponding value. These parameter names are put in the URL query if the request has a GET method or they are put in the body if the request has a POST method. One must not rely on the order in which the parameters are inserted. Parameter name is a string. The parameter values can be computed using Complex PI String expressions. The parameter values will be URL encoded.
-fullReqExpr A complex PI String expressions computes the entire request. It is the user's responsibility to provide a well formed and sane HTTP request. The system will not do any sanity checking. If full request is specified then none of the other arguments can be specified.
HTTP callouts are available with HTTP or TCP Content Switching, Responder and Rewrite functionality.
The basic communication flow for HTTP callout is:
1. User sends request
2. Policy sends HTTP request to an external service
3. Result used like any other policy evaluation result
4. Available for multiple features
HTTP Callout Deployment Scenarios
The examples in this section illustrate how to use HTTP callouts to perform various tasks. In all cases, the NetScaler performs a callout to an external server where a callout agent is configured to respond to the request from the NetScaler based on the data that is present on the external server.
This section describes how to configure HTTP callouts in the following scenarios:
1. Filter clients based on an IP blacklist.
2. Fetch and update content on the fly using Edge Side Includes (ESI) markup language.
3. Authenticate users and control access to resources.
4. Filter Outlook Web Access (OWA) spam.
Filtering clients based on an IP blacklist
HTTP callouts can be used to block requests from clients that are blacklisted by the administrator. This list of clients can either be a publicly known blacklist or one that is maintained specifically by the administrator or a combination of both.
The source IP address of the incoming client request is checked against the external pre-configured blacklist and based on whether the IP address has been blacklisted or not, the transaction is either blocked by the NetScaler or the NetScaler continues to process the transaction normally.
The HTTP callout feature facilitates this by allowing the NetScaler to communicate with the external server that maintains a database of such blacklisted IP addresses.
The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.
ESI support for fetching and updating content dynamically
Edge Side Includes (ESI) is a markup language for edge-level dynamic Web content assembly. It helps in accelerating dynamic Web-based applications by defining a simple markup language to describe cacheable and non-cacheable Web page components that can be aggregated, assembled, and delivered at the network edge.
Using HTTP callouts on the NetScaler, you can read through the ESI constructs and aggregate or assemble content dynamically.
The following outlines the requirements to implement this configuration:
1. Enable Rewrite on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Rewrite action to replace the ESI content with the callout response body.
4. Bind the Rewrite action to a Rewrite policy.
5. Bind the Rewrite policy globally on the NetScaler.
Access Control and Authentication
In high security environments, it may be mandatory to externally authenticate a user before a resource is accessed by clients. On the NetScaler, you can use HTTP callouts to externally authenticate a user based on supplied credentials. There are different ways that authentication credentials might be supplied; the client could be sending the user name and password in HTTP headers in the request, or, the credentials could be fetched from the URL or the HTTP body.
The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.
OWA-based spam filtering
Spam filtering is the ability to dynamically block emails that are not from a known or trusted source or has inappropriate content. Spam filtering requires business logic that indicates a particular kind of message is a spam.
Using HTTP callouts, you can take out any portion of the incoming message and check with the configured external callout server that has the rules to detect if the message is a legitimate email or spam. In case of a spam email, the sender will not be notified that the email is marked as spam because it will only alert spammers to modify their messages.
The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.
Read about the Citrix Application Switch with Version 9.0 here.
Try the Citrix Application Switch with Version 9.0 here.
Tap into the power of AppExpert!
An easy step up to IPv6
IPv6 has been available on NetScaler since April 2007, but only to select customers, and with a limited feature set.
Today, with NetScaler version 9.0, the IPv6 feature set is complete, with support for IPv6 communication all the way back to the application servers that the NetScaler is protecting and optimizing. Now that the IPv6 feature has matured, it has been released with the latest version of software! NetScaler version 9.0 includes IPv6 communication to the application servers, and all the usual tools use for troubleshooting will be present, such as ping6, traceroute6, etc.
The "IPv4 Dinosaur" may well be a term used in the future to describe a site which doesn't have an IPv6 representation on the internet. It's not a label one would want if they consider themselves to be keeping up to date with the latest and greatest technologies, as that of the Citrix NetScaler Application Switch.
Do keep in mind, running an IPv6 ONLY network, is probably still an arms length away and not very easy to migrate to. What would be required is a hybrid approach - and this is where NetScaler version 9.0 can provide a quick solution.
It is possible to use IPv6 communication from the internet to your NetScaler, and then use IPv4 from the NetScaler to the application servers. This will provide an IPv6 presence on the internet for your external website, without having to use time, resources, and budget to rebuild your entire environment right away.
Think of this as IPv6 offload, if you will. The fact that the application and back end systems are running IPv4 will be fully hidden from the end user. You can then, in your own time, port your back end infrastructure over to IPv6 step by step, making testing and roll-back a cinch.
Of course, full IPv6 end-to-end communication is equally important, especially for those government accounts which require this box to be checked-off for any new hardware going into the racks. This is the newest part of this feature, which is also now available in NetScaler version 9.0.
Read about the Citrix Application Switch with Version 9.0 here.
Try the Citrix Application Switch with Version 9.0 here.
Tap into the power of AppExpert!
NetScaler supports the chaining of Intermediate SSL Certificates
Up to 10 Chained Certificates to be exact, one Server Certificate and nine CA Certificates.
Verisign recently posted an advisory stating the discontinuance of Unchained SSL Certificates, and that all Verisign SSL Certificates issued after Dec 11, 2008 will be chained to Root CAs to align with security best practices - Read the advisory here.
Chaining of Certificates is done with Intermediate Certificates. What are Intermediate Certificates?
They sit in the middle, between the Public Trusted Certificate Authority (CA) and your Server, in our case the Citrix NetScaler.
The Citrix NetScaler Application Switch supports the chaining of SSL Certificates just for this very purpose, and to show how easy it is to obtain an SSL Certificate from a Trusted Certificate Authority, such as Verisign, and install it into the Citrix NetScaler, we developed the following deployment guide to walk you through the process.
Verisign Certificate Authority w/ Citrix NetScaler SSL Deployment Guide.
Not very long ago I published a series on how to become an Application Expert. Citrix NetScaler 9.0 makes it easier with AppExpert Templates. NetScaler AppExpert Templates - introduced in NetScaler 9.0 - provide an application-centric view of the NetScaler system's policy configurations. From a single place within the GUI (AppExpert -> Applications) NetScaler administrators can: 1) Configure the various AppExpert features the NetScaler is fronting, 2) View which NetScaler functional modules (e.g., compression, caching, application firewall) are optimized and active for a given application unit.
Additionally, AppExpert Templates allow you to drill down and see which individual NetScaler policies are active, and what policies are inactive but available, by application component and NetScaler module. From this same view, individual policies can be created, activated and deactivated.
AppExpert Templates can be downloaded, imported, modified and exported AppExpert Templates page of the Citrix Community Website. Administrators can download AppExpert Templates built by Citrix, Citrix Partners and members of the NetScaler community from the Citrix Community Website. These templates are easily imported into any NetScaler running NetScaler 9.0 or higher, jump starting the configuration and deployment process. Templates developed in-house can be easily exported and shared within your organization, or posted back to the Citrix Community Website for others to view and improve.
See the new AppExpert Templates page here!
Tap into the power of AppExpert!
NetScaler 9 is officially here. Well, actually, it's officially announced. It won't be officially available to download from mycitrix.com until November 27th. Yes, I know that's Thanksgiving. However, Citrix is a global company, and what better way to prove it than to post the NetScaler 9 code on a major US holiday? And, there is a chance that it might show up a day or two before the 27th.
NetScaler 9 is a pretty big release. Looking at the detailed feature tracker, it contains over 350 new features and feature enhancements. I'm not going to go through all of them in this post, because that's what release notes are for. However, I do want to highlight some of the major new features that folks seem to be most excited about, and point you to some additional resources on this site that go into a bit more detail on some of them.
I like to think that NetScaler acts as the bridge between the network and the applications that run on it, making each of them work better with the other. NetScaler 9 furthers this. A lot of the new capabilities and features making NetScaler more application-saavy than it already is. This is not to say that there aren't any hardcore networking enhancements in NetScaler 9, because there are a lot of them. These include everything from end-to-end support for IPv6 to enhancements to our GSLB functionality to the ability to tunnel IP within IP.
But in the end our networks are there to run applications, and it's the new AppExpert features in NetScaler 9 that seem to be generating the most interest.
AppExpert Templates make a given application the "first class citizen" within NetScaler. They do this by encapsulating everything about a NetScaler configuration that is specific to a given application, including:
- The different application components (e.g., pages, files, archives, Web Services) NetScaler is managing
- The various NetScaler entities and settings (e.g., VServers/VIPs, load-balancing algorithms, health checks, persistence methods, SSL offload settings) defined for these application components
- The specific NetScaler policies (e.g., caching, compression, application firewall, rewrite) used for the application
All of this is presented in a way that puts the application front and center, and configuration and policy changes can be made from there as well. So, while today understanding the entire NetScaler configuration for Microsoft SharePoint (for example) involves moving around between the various NetScaler GUI tabs, with AppExpert Templates everything is centralized in one place.
AppExpert Templates can be imported and exported as well, so they make it pretty easy to move app-specific configurations between different systems. More broadly, several folks have told us that this, and the general look and feel of AppExpert Templates, will help with knowledge transfer within their organizations. You can see an example of the Microsoft SharePoint template being imported and then applied here.
If you go here when NetScaler 9 becomes available in a couple of weeks, you'll be able to download AppExpert Templates we've already built. And, as you'll quickly notice, AppExpert Templates aren't static. The underlying infrastructure makes it really easy for you tweak a template to your own specific needs, or to improve the template by adding to it. Hopefully, you'll all post any improvements and modifications you make back to the community site so that others can benefit. And definitely look for additional AppExpert Templates to be made available by us, but Citrix partners, and hopefully by other NetScaler users.
With AppExpert rate controls, we've integrated the concept of data rate into the core NetScaler policy infrastructure. This allows building policies that are only triggered when a defined data rate is exceeded. And since it's integrated with the core policy infrastructure, it can be used with the various NetScaler functional modules (e.g., content switching, responder), so you're not limited to just dropping traffic as an action.
There's a number of ways folks have told us they're going to use AppExpert rate controls. Of course straight-up rate limiting (e.g., DNS rate-limiting, limiting traffic originating from a single subnet) is one example. Ensuring a given resource (e.g., anything from a VServer to a specific URL) isn't overwhelmed by requests is another. Two specific examples are:
- One customer allows some of its partners to scrape its website so the partners can republish content on their own sites. However, the customer wants to ensure that overly aggressive scraping by the partners doesn't overwhelm the website and degrade the site's performance. AppExpert rate controls can be used to limit how much scraping each partner can do. This same approach could be used to ensure that websites that publish APIs -- so that partners can do mashups, for example -- aren't overwhelmed by any particular partner's use of the API.
- Another example is a customer that was having problems with a couple of users FTPing a few too many large files at the same time. By using AppExpert rate controls to build an expression around bandwidth consumed per sourceIP, they can drop any additional FTP requests coming from a sourceIP (aka a user) that already has too much FTP activity. A more generalized use could also do something along the lines of limiting the amount of concurrent file downloading for a given SharePoint site, to ensure that downloads don't drown out other SharePoint (or other application) activity.
AppExpert service callouts make NetScaler policies extensible, and will allow you to integrate logic or functionality available in other systems and applications into NetScaler policies. Specifically, using an AppExpert service callout, a policy can send (over HTTP or HTTPS) any part of an incoming request to an external service. The result returned by the external service is then used like any other policy evaluation result.
As an example, one beta customer has an application that identifies and tracks IP addresses that are scraping its site's content. No, this is not the same customer that is interested in AppExpert rate controls. In earlier case, scraping is encouraged, they just needed to control it. In this case, the scraping of content amounts to theft, and the customer want to prevent as much of it as possible. Unfortunately, the IP addresses doing scraping change constantly (hence the reason they had to build an app), so statically defining them within the policy itself isn't practical. However, a service callout can query the application in real-time, and NetScaler then uses the response to either pass or drop the request.
Other use cases customers have mentioned include:
- Passing content to an external transformation engine
- Integration with UDDI or other directory services
- Geo-targeting or other token-based switching decisions, where the logic for the content switch is available in an external application
NetScaler 9 has the first availability of the XML technology we acquired from QuickTree last year. New XML protections in the NetScaler Application Firewall module will now be able to inspect and protect XML as well as HTML traffic. In addition to protecting XML-based applications from attack, this can also be used to ensure that incoming XML traffic conforms to various standards (e.g., XML syntax, schema, WSDL validation). With XML, sometimes "bad" traffic isn't malicious but is just a mistake. Either way, the XML capabilities in the app firewall will catch it.
We've had the ability to rewrite payloads within the TCP header or payload since NetScaler 8.0. However, in NetScaler 9.0 we've added a URL transformation 'mini-module' to our generalized rewrite functionality specifically for rewriting HREFs. While this function is often thought of in the context of either SSL VPN or application firewall, it has uses beyond these as well. For example, onboarding apps acquired through M&A activity, simplifying change management or "Akamai-zing" graphics content.
Again, NetScaler 9.0 is big release. There is a lot more than the app-centric things mentioned above. There is a pretty comprehensive What's New in NetScaler 9 writeup here for those of you that want a more comprehensive overview.
Updated November 12, 2008:
I received a question via comments asking about Access Gateway Enterprise enhancements. As many of you know, Access Gateway Enterprise is in essence another module in NetScaler. So, all Access Gateway Enterprise functionality is included in NetScaler, which is why NetScaler is such a great solution for Citrix XenApp and XenDesktop. There are definitely enhancement to Access Gateway Enterprise in NetScaler 9. At a high level, they are:
- Support for IPv6 XenApp Client Connections
- Single sign-on to file shares, so your users won't get get as annoyed by as many authentication prompts (unless you want them to be)
- Full clientless access to Microsoft SharePoint 2003 and 2007 so users can access SharePoint sites from any browser
- Historical charting which allows you to see trend data on system activity
Citrix Systems is closing the gap on the Number 1 Load Balancer for Web Applications. They are certainly a leader and not going to relent on the pace. Check out the Gartner Magic Quadrant. Further proving a commitment to Application Delivery, Citrix teamed with Akamai to extend Application Delivery from the datacenter into the cloud. Combining Akamai's efficiency in the cloud with Citrix's efficiency in the datacenter provides the ultimate in global acceleration of applications.
Citrix & Akamai Load Balancing Deployment Guide.
Tap into the power of AppExpert!
Read about the Citrix Load Balancer here.
Buy the Citrix Load Balancer here.
WAN Load Balancing by Elfiq Networks is a perfect fit for the Citrix WanScaler WAN Optimization Engine product. The Citrix NetScaler already performs Server Load Balancing on inbound connections, and can even perform Link Load Balancing on outbound connections. However, when it comes to managing link resiliency directly at the WAN Links, at layer 2, this is where Elfiq shines. The Elfiq Layer 2 implementation allows the insertion of the Elfiq unit between the firewall and the primary link router without any change to their configuration for an easy deployment. For private WAN Links, Elfiq will redirect packets to all links at Layer 2 on a per session basis. Another great advantage with Elfiq is the low price point to get this type of functionality. When connectivity is being deployed to multiple sites with multiple links, Elfiq SitePathMTPX can be used with IPSec VPN Tunnels and VoIP along side of enterprise applications for greater performance and resilience.
Citrix & Elfiq Networks Deployment Guide!
WAN Failover Video Tip:
WAN Load Balancing Video Tip:
The St.Bernard iPrism works with Citrix's Application Virtualization platform - XenApp, and works quite well. Seen as a perfect complement to each other the Citrix NetScaler and XenApp products were tested with the St.Bernard iPrism Web Filter. Both companies offer architectures of one-arm (out-of-band) and two-arm (in-band) deployments. At Citrixlabs in Santa Clara, CA, USA, we tested both the out-of-band and in-band configuration of the iPrism Web Filter. We loved the fact that the iPrism is auto-discovered by the management software, so no console cable was needed.
With NetScaler:
We deployed the iPrism Web Filter behind the NetScaler in our proof of concept datacenter in Santa Clara, CA, USA, and configured the NetScaler for NAT (Reverse NAT) for outbound connections to the Internet. NAT is often performed by the Firewall. The Web Application Firewall, also part of the Citrix NetScaler, was configured for protection of inbound security threats to websites and web applications.
The iPrism was configured to monitor outbound traffic from the internal subnet of 172.16.104.0/24, and block all traffic to offensive websites, and monitor traffic to all other websites. The Real-Time monitor in iPrism gave us a detailed report on the users and IP Addresses that were going out to which sites on the internet. We could see who was accessing what, and which content was being blocked. Particularly nice, was the fact that the iPrism automatically authenticated each user to the Citrixlabs domain controller, every time they surfed a new website, without them knowing it. This was very useful for keeping a tight grip on security and for compliance reporting.
With XenApp:
The powerful value is in the integration with XenApp. We plugged the iPrism in as an in-line device, and configured it to work with Citrix XenApp©, formerly known as Citrix Presentation Server. One of the key questions that will arise in this situation is with all of those Citrix XenApp thin clients logging into the XenApp and then launching browsers to the internet, how does iPrism keep track of them. By adding the XenApp IP Address to the iPrism configuration, the users are tracked using "Session Based Authentication" - this catches each individual user and IP Address in each browser session and in the reports. We were impressed by this and determined the iPrism to be an excellent fit into a datacenter outfitted with Citrix.
Citrix & St.Bernard Deployment Guide!
Network Diagram:
Watch this video tip:
Load Balancing
A crucial piece of knowledge to being an Application Expert is providing availability and offload of the backend servers across any TCP port number. Most web applications run on port 80 and 443. Some enterprise applications use custom ports. Either way, if you want to optimize the performance and keep clients connected when one of the servers or applications starts to fail, you will need a Load Balancer such as the Citrix Application Switch.
Load balancing allows you to distribute incoming requests to a particular virtual server (vserver or VIP) evenly across several backend physical servers. This is also known as Server Load Balancing (SLB). The virtual server runs load balancing algorithms within the Citrix Application Switch.
A vserver consists of a combination of an IP address, port, and protocol that accepts incoming the traffic. The vserver is bound to a number of physical services running on physical servers in the backend server farm. Typical physical servers range from apache web servers to high-end enterprise applications such as SAP and Oracle.
The way it works is a client sends a request to the virtual server, which selects a physical server in the backend server farm and directs the request to the selected physical server. Load balancing allows the Citrix Application Switch to choose the physical server with the lowest load and greatest available resources and directs the incoming request to that server. The Citrix Application Switch can select from many different algorithms for balancing the load, the most common being Round Robin.
Different virtual servers can be configured for different sets of physical services, for example TCP and UDP services. The Citrix Load Balancer supports protocol/application specific vservers for HTTP, HTTPS, FTP, SSL, SSL BRIDGE, SSLTCP, NNTP, DNS, SIP and SNMP services.
To with with your understanding and first time configuration, this deployment guide speaks directly to configuring Load Balancing and SSL Offload on a Citrix Application Switch. It was developed for the SAP Application, but the concepts apply to any Web Application.
Citrix Load Balancing Deployment Guide.
Watch this Load Balancing Tip:
Tap into the power of AppExpert!
Read about the Citrix Load Balancer here.
Buy the Citrix Load Balancer here.