Tutorial examples of classic policies
The following examples describe useful examples of classic policy configuration for certain Citrix ADC features, such as Citrix Gateway, application firewall, and SSL.
This document includes the following details:
- Citrix Gateway Policy to Check for a Valid Client Certificate
- Application Firewall Policy to Protect a Shopping Cart Application
- Application Firewall Policy to Protect Scripted Web Pages
- DNS Policy to Drop Packets from Specific IPs
- SSL Policy to Require Valid Client Certificates
Citrix Gateway policy to check for a valid client certificate
The following policies enable the Citrix ADC to ensure that a client presents a valid certificate before establishing a connection to a company’s SSL VPN.
To check for a valid client certificate by using the command line interface
-
Add an action to perform client certificate authentication.
add ssl action act1 -clientAuth DOCLIENTAUTH -
Create an SSL policy to evaluate the client requests.
add ssl policy pol1 -rule "REQ.HTTP.METHOD == GET" -action act1 -
Add a rewrite action to insert the certificate issuer details into the HTTP header of the requests being sent to web server.
add rewrite action act2 insert_http_header "CertDN" CLIENT.SSL.CLIENT_CERT.SUBJECT -
Create a rewrite policy to insert the certificate issuer details, if the client certificate exists.
add rewrite policy pol2 "CLIENT.SSL.CLIENT_CERT.EXISTS" act2Bind these new policies to the Citrix ADC VIP to put them into effect.
Application firewall policy to protect a shopping cart application
Shopping cart applications handle sensitive customer information, for example, credit card numbers and expiration dates, and they access back-end database servers. Many shopping cart applications also use legacy CGI scripts, which can contain security flaws that were unknown at the time they were written, but are now known to hackers and identity thieves.
A shopping cart application is particularly vulnerable to the following attacks:
- Cookie tampering. If a shopping cart application uses cookies, and does not perform the appropriate checks on the cookies that users return to the application, an attacker could modify a cookie and gain access to the shopping cart application under another user’s credentials. Once logged on as that user, the attacker could obtain sensitive private information about the legitimate user or place orders using the legitimate user’s account.
- SQL injection. A shopping cart application normally accesses a back-end database server. Unless the application performs the appropriate safety checks on the data users return in the form fields of its Web forms before it passes that information on to the SQL database, an attacker can use a Web form to inject unauthorized SQL commands into the database server. Attackers normally use this type of attack to obtain sensitive private information from the database or modify information in the database.
The following configuration will protect a shopping cart application against these and other attacks.
To protect a shopping cart application by using the configuration utility
-
Navigate to Security > Application Firewall > Profiles, and then click Add.
-
In the Create Application Firewall Profile dialog box, in the Profile Name field, enter shopping_cart.
-
In the Profile Type drop-down list, select Web Application.
-
In the Configure Select Advanced defaults.
-
Click Create and then click Close.
-
In the details view, double-click the new profile.
-
In the Configure Web Application Profile dialog box, configure your new profile as described below:
-
Click the Checks tab, double-click the Start URL check, and in the Modify Start URL Check dialog box, click the General tab and disable blocking, and enable learning, logging, statistics, and URL closure. Click OK and then click Close.
Note that if you are using the command line, you configure these settings by typing the following at the prompt, and pressing ENTER:
set appfw profile shopping_cart -startURLAction LEARN LOG STATS -startURLClosure ON -
For the Cookie Consistency check and Form Field Consistency checks, disable blocking, and enable learning, logging, statistics, using a similar method to the Modify Start URL Check configuration.
If you are using the command line, you configure these settings by typing the following commands:
set appfw profile shopping_cart -cookieConsistencyAction LEARN LOG STATSset appfw profile shopping_cart -fieldConsistencyAction LEARN LOG STATS -
For the SQL Injection check, disable blocking, and enable learning, logging, statistics, and transformation of special characters in the Modify SQL Injection Check dialog box, General tab, Check Actions section.
If you are using the command line, you configure these settings by typing the following at the prompt, and pressing ENTER:
set appfw profile shopping_cart -SQLInjectionAction LEARN LOG STATS -SQLInjectionTransformSpecialChars ON -
For the Credit Card check, disable blocking; enable logging, statistics, and masking of credit card numbers; and enable protection for those credit cards you accept as forms of payment.
- If you are using the configuration utility, you configure blocking, logging, statistics, and masking (or x-out) in the Modify Credit Card Check dialog box, General tab, Check Actions section. You configure protection for specific credit cards in the Settings tab of the same dialog box.
- If you are using the command line, you configure these settings by typing the following at the prompt, and pressing ENTER:
set appfw profile shopping_cart -creditCardAction LOG STATS -creditCardXOut ON -creditCard <name> [<name>...]For <name> you substitute the name of the credit card you want to protect. For Visa, you substitute VISA. For Master Card, you substitute MasterCard. For American Express, you substitute Amex. For Discover, you substitute Discover. For Diners Club, you substitute DinersClub. For JCB, you substitute JCB.
-
-
Create a policy named shopping_cart that detects connections to your shopping cart application and applies the shopping_cart profile to those connections.
To detect connections to the shopping cart, you examine the URL of incoming connections. If you host your shopping cart application on a separate host (a wise measure for security and other reasons), you can simply look for the presence of that host in the URL. If you host your shopping cart in a directory on a host that handles other traffic, as well, you must determine that the connection is going to the appropriate directory and/or HTML page.
The process for detecting either of these is the same; you create a policy based on the following expression, and substitute the proper host or URL for
<string>.REQ.HTTP.HEADER URL CONTAINS <string> <!--NeedCopy-->-
If you are using the configuration utility, you navigate to the application firewall Policies page, click the Add… button to add a new policy, and follow the policy creation process described in “To create a policy with classic expressions using the configuration utility” beginning on page 201 and following.
-
If you are using the command line, you type the following command at the prompt and press Enter:
add appfw policy shopping_cart "REQ.HTTP.HEADER URL CONTAINS <string>" shopping_cart
-
2. Globally bind your new policy to put it into effect.
Because you want to ensure that this policy will match all connections to the shopping cart, and not be preempted by another more general policy, you should assign a high priority to it. If you assign one (1) as the priority, no other policy can preempt this one.
Application firewall policy to protect scripted web pages
Web pages with embedded scripts, especially legacy JavaScripts, often violate the “same origin rule,” which does not allow scripts to access or modify content on any server but the server where they are located. This security vulnerability is called cross-site scripting. The application firewall Cross-Site Scripting rule normally filters out requests that contain cross-site scripting.
Unfortunately, this can cause Web pages with older JavaScripts to stop functioning, even when your system administrator has checked those scripts and knows that they are safe. The example below explains how to configure the application firewall to allow cross-site scripting in Web pages from trusted sources without disabling this important filter for the rest of your Web sites.
To protect Web pages with cross-site scripting by using the command line interface
-
At the command line, to create an advanced profile, type:
add appfw profile pr_xssokay -defaults advanced -
To configure the profile, type:
set appfw profile pr_xssokay -startURLAction NONE -startURLClosure OFF -cookieConsistencyAction LEARN LOG STATS -fieldConsistencyAction LEARN LOG STATS -crossSiteScriptingAction LEARN LOG STATS$" -
Create a policy that detects connections to your scripted Web pages and applies the pr_xssokay profile, type:
add appfw policy pol_xssokay "REQ.HTTP.HEADER URL CONTAINS ^\\.pl\\?$ || REQ.HTTP.HEADER URL CONTAINS ^\\.js$" pr_xssokay -
Globally bind the policy.
To protect Web pages with cross-site scripting by using the configuration utility
-
Navigate to Security > Application Firewall > Profiles.
-
In the details view, click Add.
-
In the Create Application Firewall Profile dialog box, create a Web Application profile with advanced defaults and name it pr_xssokay. Click Create and then click Close.
-
In the details view, click the profile, click Open, and in the Configure Web Application Profile dialog box, configure the pr_xssokay profile as shown below.
Start URL Check: Clear all actions.
- Cookie Consistency Check: Disable blocking.
- Form Field Consistency Check: Disable blocking.
- Cross-Site Scripting Check: Disable blocking.
This should prevent blocking of legitimate requests involving Web pages with cross-site scripting that you know are nonetheless safe.
-
Click Policies, and then click Add.
-
In the Create Application Firewall Policy dialog box, create a policy that detects connections to your scripted Web pages and applies the pr_xssokay profile:
- Policy name: pol_xssokay
- Associated profile: pr_xssokay
Policy expression: “REQ.HTTP.HEADER URL CONTAINS ^.pl\?$ -
Globally bind your new policy to put it into effect.
DNS Policy to drop packets from specific IPs
The following example describes how to create a DNS action and DNS policy that detects connections from unwanted IPs or networks, such as those used in a DDOS attack, and drops all packets from those locations. The example shows networks within the IANA reserved IP block 192.168.0.0/16. A hostile network will normally be on publicly routable IPs.
To drop packets from specific IPs by using the command line interface
-
To create a DNS policy named pol_ddos_drop that detects connections from hostile networks and drops those packets, type:
add dns policy pol_ddos_drop 'client.ip.src.in_subnet(192.168.253.128/25) || client.ip.src.in_subnet(192.168.254.32/27)' -drop YES'For the example networks in the 192.168.0.0/16 range, you substitute the IP and netmask in ###.###.###.###/## format of each network you want to block. You can include as many networks as you want, separating each CLIENT.IP.SRC.IN_SUBNET(###.###.###.###./##) command with the OR operator.
-
Globally bind your new policy to put it into effect.
SSL policy to require valid client certificates
The following example shows an SSL policy that checks the user’s client certificate validity before initiating an SSL connection with a client.
To block connections from users with expired client certificates
-
Log on to the command line interface.
If you are using the GUI, navigate to the SSL Policies page, then in the Data area, click the Actions tab.
-
Create an SSL action named act_current_client_cert that requires that users have a current client certificate to establish an SSL connection with the Citrix ADC.
add ssl action act_current_client_cert-clientAuth DOCLIENTAUTH -clientCert ENABLED -certHeader "clientCertificateHeader" -clientCertNotBefore ENABLED -certNotBeforeHeader "Mon, 01 Jan 2007 00:00:00 GMT" -
Create an SSL policy named pol_current_client_cert that detects connections to the Web server that contain a query string.
add ssl policy pol_current_ client_cert 'REQ.SSL.CLIENT.CERT.VALIDFROM \>= "Mon, 01 Jan 2007 00:00:00 GMT"' act_block_ssl -
Bind your new policy globally.
Because this SSL policy should apply to any user’s SSL connection unless a more specific SSL policy applies, you may want to assign it a low priority. If you assign it a priority of one thousand (1000), that should ensure that other SSL policies are evaluated first, meaning that this policy will apply only to connections that do not match more specific policy criteria.