Connecting the world…

http

Citrix Secure Gateway via https-only

Configuring a Citrix Secure Gateway (CSG) server is simple, but provides a powerful solution to access resource from remote locations. CSG is an application installed on a DMZ server. Mostly I also configure the Citrix WebInterface on the same server. The CSG instance listens on TCP/443 and the WI instance listens on TCP/80. To improve the user friendliness of the solution you have to configure a redirect. This redirect changes the protocol from the unsecure http protocol to the secure https protocol. It also redirect the user to the correct login portal, like redirecting http://portal.booches.nl to https://portal.booches.nl/Citrix/XenApp/auth/login.aspx. The HTML code for the redirect is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Refresh" content="1 ;URL=https://portal.booches.nl/Citrix/XenApp/auth/login.aspx" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <title>Citrix Secure Gateway-Booches</title>
</head>
<body>  
<p>
        Please click <a href=’https://portal.booches.nl/Citrix/XenApp/auth/login.aspx’>here</a> if you are not automatically redirected.
</p>
</body>
</html>

This configuration requires you to allow the http and https protocols from the internet to the server. When accessing the login page the remote user connects to the CSG instance over https and the CSG instance connects to the WI instance over http. A customer noticed that a user could change the login URL from https to the unsecure http. This means that the remote user connects directly to the WI instance and bypasses the CSG instance. This behavior is not allowed and also unsecure, because username and password are sent clear text over the internet.

I wanted to change this behavior so the user isn’t allowed to connect over http to the login page, but the default redirect from http to https should still be allowed. I looked at solutions on the internet to redirect all IIS traffic from http to https, but this introduced some problems and errors. In the end I simply configured IP Address and Domain Restriction on the /Citrix/XenApp virtual directory. Only the CSG instance needs to connect to the WI instance, so the IP restrictions only allow the localhost and the server IP address. I also changed the default behavior to deny all unspecified clients.

csg-wi-ip

NBAR and smart filtering

NBAR (Network Based Application Recognition) is a cool Cisco tool to identify and classify content flowing through a router. You can identify applications as mission critical, business-related, non-critical or unwanted. Once these mission critical applications are classified they can be guaranteed a minimum amount of bandwidth, policy routed, and marked for preferential treatment. Non-critical applications including Internet gaming applications and MP3 file sharing applications can also be classified using NBAR and marked for best effort service, policed, or blocked as required.

In the following example you will see how to block access to YouTube and block the extension .exe. I will block the content when it tries to “enter” the router on the internal interface Vlan1. To start with you need to enable NBAR on the interface.

RTR#configure terminal
RTR(config)#interface Vlan 1
RTR(config-if)#ip nbar protocol-discovery

Create a class-map to identify the content which needs to be blocked.

RTR#configure terminal
RTR(config)#class-map match-any cm-blocked-content
RTR(config-cmap)#match protocol http url “*.exe”
RTR(config-cmap)#match protocol http host “*youtube*”

The following step involves creating a policy-map to block the traffic matching the previous class-map.

RTR#configure terminal
RTR(config)#policy-map pm-blocked-content
RTR(config-pmap)#class cm-blocked-content
RTR(config-pmap-c)#drop

You can also police or shape the identified content so it cannot “consume” all the available bandwidth. The final steps is to apply the policy-map to the internal interface in the input direction.

RTR#configure terminal
RTR(config)#int Vlan 1
RTR(config-if)#service-policy input pm-blocked-content

To verify the operation of NBAR you need to try to browse to the YouTube website or download a file with the .exe extension. Check the operation with the show policy-map interface vlan 1 command, like shown below.

RTR#sh policy-map interface vlan 1 input

Vlan1

 Service-policy input: pm-blocked-content

  Class-map: cm-blocked-content (match-any)
   228 packets, 121574 bytes
   5 minute offered rate 0 bps, drop rate 0 bps
   Match: protocol http url “*.exe”
    9 packets, 7090 bytes
    5 minute rate 0 bps
   Match: protocol http host “*youtube*”
    24 packets, 12813 bytes
    5 minute rate 0 bps
   drop

  Class-map: class-default (match-any)
   111703 packets, 12021043 bytes
   5 minute offered rate 33000 bps, drop rate 0 bps
   Match: any
RTR#

From now on your users aren’t able to browse to YouTube or download .exe files over HTTP. With NBAR you can also block a specific content type, like streaming  media. I use WireShark to retrieve the content-type I would like to block. By following the TCP stream from a WireShark session you can find the exact content-type or other useful information.

Use the match protocol http mime command to classify a content-type. In MIME type matching, NBAR classifies the packet that contains the MIME type and all subsequent packets, which are sent to the source of the HTTP request. This means that the corresponding policy-map should be applied inbound (input) on the external interface or outbound (output) on the internal interface. For MIME type matching, the MIME type can contain any user-specified text string. A list of the Internet Assigned Numbers Authority (IANA)-supported MIME types can be found here.

ISA 2006 Authentication over HTTP

I implemented different ISA 2006 Reverse Proxy servers in conjunction with Microsoft Exchange 2003 or Windows Exchange 2007.

Today I configured ISA 2006 with Exchange 2007. I configured the Reverse Proxy server as I did always. And the connection from outside the network works perfectly. On the internal Exchange server I configured Basic and Integrated Authentication on the OWA virtual directory. The problem is that internal users now automatically log in to their webmail box when entering the URL from the Exchange server.

This is not the desired configuration, because internal users should be able to open other people’s mailboxes by logging in as that user. The customer also has an ISA 2006 on the internal network for forwarding proxy purposes.

I decided to publish Exchange 2007 on the internal ISA 2006 server as well. The configuration should use Form Based Authentication (FBA) over HTTP. After configuring and trying the connection, the user can’t access the ISA logon page. In the logging you find that Authentication over HTTP isn’t allowed.

Error Code: 403 Forbidden. ISA Server is configured to block HTTP requests that require authentication. (12250)

This is a default setting in ISA 2006 which can be disable. To allow Authentication over HTTP go to the Listener configuration. Go to the Authentication tab and Select Advanced. In the next tab enable the option Allow client authentication over HTTP. This option enables the using FBA over HTTP.