NetScaler has long had the ability to take network traces and analyze it in tools like WireShark. Network traces can be captured in standard tcpdump format or a NetScaler specific format. The NetScaler specific format has additional connection information that makes it easier to troubleshoot issues. For a long while, NetScaler engineers used a modified WireShark version (previously called Ethereal) to view and analyze NetScaler traces.

Recently, our developers contributed this patch to the open source Wireshark development and the next version (1.3.0) of Wireshark will include the ability to understand NetScaler format packet traces. In the interim, the modified Wireshark version is available for download at CTX122313. This version will work on Windows. The article also shows how you can use the NetScaler traces to use the additional data.

To capture a network trace on the NetScaler, you need to log in to the command line interface and get into the shell (by typing shell).
To capture a trace in the NetScaler format, type in
#nstrace.sh -sz 0

-sz 0 captures the full packet. With no argument (default), only the first 164 bytes of the packet are captured.

You can also use the GUI to capture traces (under System/ Diagnostics).
#nstrace.sh -help
details the other options available.

Upload the file to using ftp, scp etc and analyze using the modified Wireshark.

To capture traces in the tcpdump format,
#nstcpdump.sh
(Most standard tcpdump options are supported)

A new whitepaper describing the XML firewall features available in NetScaler version 9.x is available here.
It includes a concise summary of the feature capabilities and the types of applications that the Application firewall can secure. Security is a core component of the Application Delivery Controller (ADC) platform. For a broad overview of the security related features available in the NetScaler, get Citrix NetScaler - A Comprehensive Application Security Solution.

ICA Proxy for XenApp using NetScaler AGEE.

Citrix NetScaler, a member of the Citrix Delivery Center™, is a purpose-built web application delivery solution that accelerates application performance up to five times while improving security and reducing web infrastructure costs. Access Gateway™, a member of the Citrix Delivery Center, is an only SSL VPN to securely deliver any application with policy-based SmartAccess control. Access Gateway, Enterprise Edition (AGEE) runs on the Citrix NetScaler.

Citrix XenApp™, also a member of the Citrix Delivery Center™ product family, is the industry's de facto standard for delivering Windows-based applications with the best performance, security and cost savings.

By centralizing applications and data in secure datacenters, IT can reduce the costs of management and support, increase data security and facilitate business continuity.

We at Citrix are often asked how to deploy a NetScaler AGEE in front of a XenApp server farm, to proxy application delivery over the ICA protocol, securely. The NS SGEE secures XenApp delivered applications by serving as a proxy for those applications. NS AGEE proxies the ICA connections delivered from XenApp, and then wraps those applications with HTTPS or SSL to secure the traffic before it leaves your organization.

This is possible by following the steps in the deployment guide. This guide is specific to the NetScaler Access Gateway Enterprise Edition (AGEE), which is different hardware & software from the Citrix Access Gateway Standard Edition (AGSE).

Download the deployment guide.

Its Powerful Citrix Developer Network!

Secure Selected Pages

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.

In situations where you want to make sure that for some selected pages only the secure server is used, the following can be used.
Apache rewrite:

RewriteCond %{SERVER_PORT} !^443$ 
RewriteRule ^/?(page1|page2|page3|page4|page5)$  https://www.example.com/%1 [R,L]

AppExpert rewrite example 1:

Add responder action res_redirect redirect  '"https://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol_redirect '!CLIENT.TCP.DSTPORT.EQ(443)&&HTTP.REQ.URL.REGEX_MATCH(re/page[1-5]/)'  res_redirect
Bind responder global pol_redirect 100 END

AppExpert rewrite example 2:

Add patset pat1
Bind patset pat1 page1
Bind patset pat1 page2
Bind patset pat1 page3
Bind patset pat1 page4
Bind patset pat1 page5
Add responder action res_redirect redirect  '"https://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol_redirect '!CLIENT.TCP.DSTPORT.EQ(443)&&HTTP.REQ.URL.CONTAINS_ANY("pat1")'  res_redirect
Bind responder global pol_redirect 100 END

Tap into the power of AppExpert!

When we talk about the Citrix Delivery Center, we are talking about an end-to-end application delivery infrastructure solution. A solution which represents a family of Citrix product lines: Citrix XenServer, Citrix XenApp, Citrix NetScaler and Citrix XenDesktop. It also represents products that add integrated security, management and networking functions, products such as: Citrix Access Gateway, Citrix Branch Repeater and Citrix Desktop Receiver. Overall, the Citrix Delivery Center gives customers the power to adopt virtualization that meets their specific requirements. Customers can choose to optimize delivery of their Web Applications, Windows Applications, Desktop Delivery, Data Center Optimization - individually or in combination. How about all of them?

So how did we do it....First we virtualized every Citrix Delivery Center component and the backend SAP NetWeaver application servers using Citrix XenServer. Then we showcased what a remote SAP NetWeaver user would experience accessing the SAP NetWeaver Portal via Citrix Delivery Center while focusing on the high availability/fault tolerant solutions Citrix and Marathon provide. Finally, we simulated a complete failure in the primary site and used the combined NetScaler Global Server Load Balancing feature in conjunction with Marathon's everRun DR product to failover SAP to a secondary data center.

Let's go through the steps that describe the demonstrated user experience:

• Remote SAP NetWeaver Portal user securely connects to the SSL VPN provided by Citrix Access Gateway Enterprise Edition.
• All connections from the remote user client are accelerated using Citrix Branch Repeater Plug-in.
• Remote user is seamlessly presented with the Citrix Web Interface website with on-demand access to virtual desktops, applications, bookmarks and other corporate resources.
• From the Citrix Web Interface page, the remote user launches a virtual Windows XP desktop hosted by Citrix XenDesktop. This desktop is a private virtual image of Windows XP running within a secure data center and maintained from a centralized Windows XP image provisioned dynamically with Citrix Provisioning Server.
• From the secure virtual Windows XP desktop, the remote user launches a published SAP NetWeaver Portal delivered by Citrix XenApp. The published NetWeaver Portal application is separated from the virtual Windows XP Operating System allowing optimal user performance.
• As the remote user navigates the application, all SAP NetWeaver Portal connections pass through a Citrix NetScaler configured to optimize SAP NetWeaver Portal application delivery.

We also demonstrated the following high availability and recoverability solutions provided by Citrix XenServer and Marathon everRun software:

• Level 1: XenServer delivers out-of-the-box high availability, including cost-effective core failover, recovery and restart capabilities for SAP applications running in the virtual environment.
• Level 2: Marathon everRun VM delivers high availability of component-level fault tolerance, eliminating downtime caused by I/O component failures and guaranteeing recovery from system failures.
• Level 3: Marathon everRun VM's Lockstep Technology delivers continuous availability from system-level fault tolerance, eliminating data loss, downtime and transaction loss.
• Disaster Recovery: Marathon everRun DR provides a robust and flexible remote disaster recovery solution providing automated and reliable long-distance protection for critical data and applications, in this case, SAP.

Each piece of the demonstration was broken down into small video segments for this blog. The first video features the Citrix Delivery Center environment for SAP from top to bottom including the remote user login, virtual desktop access, and SAP NetWeaver Portal launch. Then a complete site failure is simulated and the secondary site recovery is shown using Marathon's everRun DR solution with Citrix NetScaler's Global Server Load Balancing feature.

Stay tuned for a detailed reference architecture and video blogs on different High Availability scenarios including everRun VM also demonstrated at SAP Co-Innovation Lab.

Here's the video:

Redirecting a URI to a new format

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.

Let's say, for example, that you've got a set of working URLs that look like this: /index.php?id=nnnn. However, you'd really like to change them to /nnnn and make sure search engines update their indexes to the new URI format. First, you'd have to redirect the old URIs to the new ones so that search engines update their indexes, but you still have to rewrite the new URI back to the old one so that the index.php script would run.

Example: The trick here is to place into the query string a marker code that will not be seen by visitors. We redirect from the old link to the new format only if the "marker" is not present in the query string. Then we rewrite the new format link back to the old format, and add a marker to the query string.

Apache rewrite:

RewriteCond %{QUERY_STRING} !marker 
RewriteCond %{QUERY_STRING} id=([-a-zA-Z0-9_+]+) 
RewriteRule ^/?index\.php$ %1? [R,L] 
RewriteRule ^/?([-a-zA-Z0-9_+]+)$  index.php?marker&id=$1 [L]

AppExpert rewrite:

Add responder action act_redirect redirect 'HTTP.REQ.URL.PATH.BEFORE_STR("index.php")+HTTP.REQ.URL.QUERY.VALUE("id")' -bypassSafetyCheck yes
Add responder policy pol_redirect '!HTTP.REQ.URL.QUERY.CONTAINS("marker")&& HTTP.REQ.URL.QUERY.VALUE("id").REGEX_MATCH(re/[-a-zA-Z0-9_+]+/) && HTTP.REQ.URL.PATH.CONTAINS("index.php")' act_redirect
Bind responder  global pol_redirect 100 END
Add rewrite action act1 replace 'HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' '"index.phpmarker&id="+HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' -bypassSafetyCheck yes
Add rewrite policy pol1 '!HTTP.REQ.URL.QUERY.CONTAINS("marker")'  act1
Bind rewrite global pol1 100 END

Tap into the power of AppExpert!

Creating Extensionless links

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.

Sometimes you may want to support extension less links, either to hide extensions from end users or to make URLs easy to remember.

Example 1: add .php extension to all requests

Apache rewrite:

RewriteRule ^/?([a-z]+)$ $1.php [L]

AppExpert rewrite:

Add rewrite action act1 insert_after 'HTTP.REQ.URL' '".php"'
Add rewrite policy pol1 'HTTP.REQ.URL.PATH.REGEX_MATCH(re#^/([a-z]+)$#)' act1
Bind rewrite global pol1 100

Example 2: if we have a mixture of both .html and .php files, the following can be used

Apache rewrite:

RewriteCond %{REQUEST_FILENAME}.php -f 
RewriteRule ^/?([a-zA-Z0-9]+)$ $1.php [L] 
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^/?([a-zA-Z0-9]+)$ $1.html [L]

AppExpert rewrite:
Here HTTPCallout would be used, script file_check.cgi hosted on 10.102.59.101 is used to check wether provided argument is avalid file name or not.

add HTTPCallout Call_html
add HTTPCallout Call_php
set policy httpCallout Call_html -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")'  -urlStemExpr '"/cgi-bin/file_check.cgi"'   -parameters query=http.req.url+".html"
set policy httpCallout Call_php -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")'  -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url+".php"
Add patset pat1 
Bind patset pat1 .html
Bind patset pat1 .php
Bind patset pat1 .asp
Bind patset pat1 .cgi
Add rewrite  action act1 insert_after 'HTTP.REQ.URL.PATH'  '".html"'
Add rewrite  action act2 insert_after "HTTP.REQ.URL.PATH"  '".php"'
Add rewrite policy pol1 '!HTTP.REQ.URL.CONTAINS_ANY("pat1") && SYS.HTTP_CALLOUT(Call_html)' act1
Add rewrite policy pol2 '!HTTP.REQ.URL.CONTAINS_ANY("pat1") && SYS.HTTP_CALLOUT(Call_php)' act2
Bind rewrite global pol1 100 END
Bind rewrite global pol2 101 END

Tap into the power of AppExpert!

Blocking Inline Images

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.

Assume you have under http://www.quux-corp.de/~quux/ some pages with in lined GIF graphics. These graphics are nice, so others directly incorporate them via hyperlinks to their pages. you don't like this practice because it adds useless traffic to your server.

Example : You can restrict the cases where the browser sends a HTTP Referer header.

Apache rewrite:

RewriteCond %{HTTP_REFERER} !^$                                  
RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$ 
RewriteRule .*\.gif$        -                 [F]

AppExpert rewrite:

Add patset pat1
Bind patset pat1 .gif
Bind patset pat1 .jpeg
add responder action act1 respondwith '"HTTP/1.1 403 Forbidden\r\n\r\n"'
add responder policy pol1 '!HTTP.REQ.HEADER("Referer").EQ("") && !HTTP.REQ.HEADER("Referer").STARTSWITH("http://www.quux-corp.de/~quux/")&&HTTP.REQ.URL.ENDSWITH_ANY("pat1")' act1
bind responder global pol1 100

Tap into the power of AppExpert!

Blocking Robots

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.

You can block a really annoying robot from retrieving pages of a specific webarea. This way you can ease up the traffic at some directories.

Example : This could be done by using a rule set which forbids the URLs of the web area /~quux/foo/arc/. This could also be accomplished by matching the User-Agent HTTP header information. In this example, the ip address to be blocked is 123.45.67.8 & 123.45.67.9.

Apache rewrite:

RewriteCond %{HTTP_USER_AGENT}   ^NameOfBadRobot.*      
RewriteCond %{REMOTE_ADDR}       ^123\.45\.67\.[8-9]$
RewriteRule ^/~quux/foo/arc/.+   -   [F]

AppExpert rewrite:

add responder action act1 respondwith '"HTTP/1.1 403 Forbidden\r\n\r\n"'
add responder policy pol1 'HTTP.REQ.HEADER("User_Agent").STARTSWITH("NameOfBadRobot")&&CLIENT.IP.SRC.EQ(123.45.67.8)&&CLIENT.IP.SRC.EQ(123.45.67.9) && HTTP.REQ.URL.STARTSWITH("/~quux/foo/arc")' act1
bind responder global pol1 100

Tap into the power of AppExpert!

Browser Dependent Content

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.

At least for important top-level pages it is sometimes necessary to provide the optimum of browser dependent content, i.e. one has to provide a maximum version for the latest Netscape variants, a minimum version for the Lynx browsers and an average feature version for all others.

Example : We will act on the HTTP header "User-Agent". The following config does the following: If the HTTP header "User-Agent" begins with "Mozilla/3", the page foo.html is rewritten to foo.NS.html and the rewriting stops. If the browser is "Lynx" or "Mozilla" of version 1 or 2 the URL becomes foo.20.html. All other browsers receive page foo.32.html. This is done by the following rule set:

Apache rewrite:

RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/3.*
RewriteRule ^foo\.html$         foo.NS.html          [L]
RewriteCond %{HTTP_USER_AGENT}  ^Lynx/.*         [OR]
RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/[12].*
RewriteRule ^foo\.html$         foo.20.html          [L]
RewriteRule ^foo\.html$         foo.32.html          [L]

AppExpert rewrite:

Add patset pat1
Bind patset pat1 Mozilla/1
Bind Patset pat1 Mozilla/2
Bind patset pat1 Lynx
Bind Patset pat1 Mozilla/3

add rewrite action act1 insert_before 'HTTP.REQ.URL.SUFFIX' '"NS."'

add rewrite action act2 insert_before 'HTTP.REQ.URL.SUFFIX' '"20."'

add rewrite action act3 insert_before 'HTTP.REQ.URL.SUFFIX' '"32."'


add rewrite policy pol1 'HTTP.REQ.HEADER("User-Agent").STARTSWITH_INDEX("pat1").EQ(4)' act1

add rewrite policy pol2 'HTTP.REQ.HEADER("User-Agent").STARTSWITH_INDEX("pat1").BETWEEN(1,3)' act2

add rewrite policy pol3 '!HTTP.REQ.HEADER("User-Agent").STARTSWITH_ANY("pat1")' act3

bind rewrite global pol1 101 END
bind rewrite global pol2 102 END
bind rewrite global pol3 103 END

Tap into the power of AppExpert!

Old to New External URL Rewrite

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.

Assume that you have recently renamed the page foo.html to bar.html and now want to provide the old URL for backward compatibility. But this time you want the users of the old URL to see new one, i.e. their browsers Location field should change too.

Example : The following rules can force an HTTP redirect to the new URL which leads to a change of the URL in the users browser:

Apache rewrite:

RewriteEngine  on
RewriteBase    /~quux/
RewriteRule    ^foo\.html$  bar.html  [R]

AppExpert rewrite: (There are two ways to do this)

add responder action act1 redirect 'HTTP.REQ.URL.BEFORE_STR("foo.html")+"bar.html"' -bypassSafetyCheck yes

add responder policy pol1 'HTTP.REQ.URL.ENDSWITH("/~quux/foo.html")' act1

bind responder global pol1 100

add responder action act1 redirect 'HTTP.REQ.URL.PATH.BEFORE_STR("foo.html")+"bar.html"+HTTP.REQ.URL.AFTER_STR("foo.html")' -bypassSafetyCheck yes

add responder policy pol1 'HTTP.REQ.URL.PATH.CONTAINS("foo.html")' act1

bind responder global pol1 100

Tap into the power of AppExpert!

Old to New Internal URL Rewrite

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.

Assume you have recently renamed the page foo.html to bar.html and now want to provide the old URL for backward compatibility. Actually you want users of the old URL to not recognize that the pages were renamed.

Example : Rewrite the old URL to the new one internally via the following rule, let the base directory be /~quux/.

Apache rewrite:

RewriteEngine  on
RewriteBase    /~quux/
RewriteRule    ^foo\.html$  bar.html

AppExpert rewrite: (There are two ways to do this)

add rewrite action act1 replace 'HTTP.REQ.URL.AFTER_STR("/~quux").SUBSTR("foo.html")' '"bar.html"'

add rewrite policy pol1 'HTTP.REQ.URL.ENDSWITH("/~quux/foo.html")' act1

bind rewrite global pol1 100

Add rewrite action act1 replace 'HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' '"bar.html"'

Add rewrite policy pol1 'HTTP.REQ.URL.PATH.CONTAINS("foo.html")' act1

Bind rewrite global pol1 100

Tap into the power of AppExpert!

Time Dependent Rewriting

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.

We can rewrite a URL based on time.

Example : Changing the request foo.html to foo.day.html or foo.night.html according to time.

Apache rewrite:

RewriteCond   %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond   %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule   ^foo\.html$             foo.day.html [L]
RewriteRule   ^foo\.html$             foo.night.html

AppExpert rewrite:

Add rewrite action act1 insert_before 'HTTP.REQ.URL.PATH.SUFFIX(\'.\',0)' '"day."'

Add rewrite action act2  insert_before 'HTTP.REQ.URL.PATH.SUFFIX(\'.\',0)' '"night."'

add rewrite  policy pol1 'SYS.TIME.WITHIN(LOCAL 07h 00m,LOCAL 18h 59m)' act1

add rewrite policy pol2 'true'  act2

bind rewrite global pol1 101

bind rewrite global pol2 102

Tap into the power of AppExpert!

Failed URL Redirect

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.

In case the current url is not valid & the request needs to be redirected to another web server, the following steps could be taken.

Example : We will check weather the request filename exists on the server or not, in case it fails then redirection is done to another webserver (for example, webServerB.com). In the case of AppExpert, HTTPCallout is used to check the presence of the file on the server by running a script file_check.cgi on the server. The returned value from HTTPCallout is used to validate the policy.

The Script file_check.cgi takes the url as the argument, checks for its presence on the server & returns True or False accordingly.

Apache rewrite:

RewriteCond   /your/docroot/%{REQUEST_FILENAME} !-f
RewriteRule   ^(.+)      http://webserverB.com/$1 [R]

AppExpert rewrite: (There are two ways to do this)

add HTTPCallout Call

set policy httpCallout Call -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")'  -urlStemExpr '"/cgi-bin/file_check.cgi"'   -parameters query=http.req.url.path -headers Name("ddd")

add responder action act1 redirect '"http://webserverB.com"+HTTP.REQ.URL' -bypassSafetyCheck yes

add responder policy pol1 '!HTTP.REQ.HEADER("Name").EXISTS  &&  !SYS.HTTP_CALLOUT(call)' act1

bind responder global pol1 100

add HTTPCallout Call

set policy httpCallout Call -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")'  -urlStemExpr '"/cgi-bin/file_check.cgi"'   -parameters query=http.req.url.path -headers Name("ddd")

add responder  action act1 respondwith  '"HTTP/1.1 302 Moved Temporarily\r\nLocation: http://webserverB.com"+HTTP.REQ.URL+"\r\n\r\nHTTPCallout Used"' -bypassSafetyCheck yes

add responder policy pol1 '!HTTP.REQ.HEADER("Name").EXISTS  &&  !SYS.HTTP_CALLOUT(call)' act1

bind responder global pol1 100

Tap into the power of AppExpert!

Structured Homedirs

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.

Some sites with thousands of users usually use a structured homedir layout, i.e. each homedir is in a subdirectory which begins for instance with the first character of the username. So, /~foo/anypath is /home/f/foo/.www/anypath while /~bar/anypath is /home/b/bar/.www/anypath.Following rules could be used to implement this.

Apache rewrite:

RewriteRule   ^/~(([a-z])[a-z0-9]+)(.*)  /home/$2/$1/.www$3

AppExpert rewrite:

Add rewrite action act1 replace 'HTTP.REQ.URL'  '"/home/"+ HTTP.REQ.URL.AFTER_STR("~").PREFIX(1)+"/"+ HTTP.REQ.URL.AFTER_STR("~").BEFORE_STR("/")+"/.www"+HTTP.REQ.URL.SKIP(\'/\',1)'  -bypassSafetyCheck yes

Add rewrite policy pol1  'HTTP.REQ.URL.PATH.STARTSWITH("/~")' act1

Bind rewrite global pol1 100

Tap into the power of AppExpert!

Move Homedirs to Different Web Server

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.

There are cases when you want to redirect requests for homedirs on one web server to another web server. The typical use case for this arises when establishing a newer web server which will replace the old one over time. i.e. you need to redirect all the requests for a particular homedir to another web server.

Example : Let the hostname for new webserver be newserver.

Apache rewrite:

RewriteRule   ^/(.+)  http://newserver/$1     [R,L]

AppExpert rewrite: (There are two ways to do this)

Add responder  action act1 redirect '"http://newserver"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol1 'HTTP.REQ.URL.REGEX_MATCH(re#^/(.+)#)'   act1
Bind responder global pol1 100 END

Add responder  action act1 redirect '"http://newserver"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol1 'HTTP.REQ.URL.LENGTH.GT(1)'   act1
Bind responder global pol1 100 END

Tap into the power of AppExpert!

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!