540 likes | 555 Views
An Introduction to the New Security Features of Citrix MetaFrame Secure Access Manager. Tommy Walker, Systems Engineer Bob Schaeffer, Systems Engineer Citrix Systems. Non Disclosure Agreement.
E N D
An Introduction to the New Security Features of Citrix MetaFrame Secure Access Manager Tommy Walker, Systems Engineer Bob Schaeffer, Systems Engineer Citrix Systems
Non Disclosure Agreement • This presentation is confidential. By virtue of your relationship with Citrix, you are bound to retain in confidence all information in this presentation.
Under Construction This product is still under development. Names, Features and Functionality may change before the product is shipped.
Internet Secure Gateway Today Internet Explorer and ICA Client MetaFrame XP Server Farm Secure Gateway STA Web Interface 3rd Party Auth
Agenda • SSL/TLS Support • Logon Agent • Gateway Client • Deployment Scenarios • Secure Gateway Management • Error Logging
SSL/TLS Support • SSL V3.0 and TLS V1.0 secure protocols supported • Secure connections now include between • ICA Client and Web Server/Logon Agent • ICA Client and the Secure Gateway • Secure Gateway and the Secure Gateway Proxy • Secure Gateway and the, Authentication Service • Secure Gateway and the Secure Ticketing Authority • Secure Ticket Authority and the Logon Agent • Logon Agent and 3rd Party Authentication
SSL/TLS Support • ICA connections are relatively persistent While • HTTP connections are typically transient connections
SSL/TLS Support • Why do we care…… • The key generation phase of the SSL/TLS handshake • Is a computationally intensive operation • MetaFrame Secure Access Manager makes use of session ID reuse • This reduces the requirement to generate a new key pair for each connection
Cipher Suites Supported • RSA_WITH_3DES_EDE_CBC_SHA • RSA_WITH_RC4_128_SHA • RSA_WITH_RC4_128_MD5 • Remove weak cryptography • Meet government requirements for the use of FIPS 140 certified cipher suites
Logon Agent • The Logon Agent is a web based login service responsible for displaying a login page and processing the login requests. • Implemented as server based ASP scripts • Hosted on a Microsoft IIS 5 or 6 servers
Logon Agent • Ships with two logon page templates • one using basic username, password and domain • basic authentication integrated with RSA SecurID • Customizable logon page templates • Third party forms based authentication schemes can be added
Logon Agent Process • The Logon Agent presents a HTML logon page to the user • User Credentials Collected • The Logon Agent first validates the SecurID • The SOAP protocol passes the credentials to the Authentication Service
Logon Agent Process • Upon authentication • Authentication Service returns a session cookie • A redirection URL • A number of cookies required by the MetaFrame Secure Access Manager • The Logon Agent formats the data returned by the Authentication Service • Forwards the formatted response to the client web browser
Internal and External Web Access • A VPN or Reverse Proxy is commonly used to access your internal web content • A VPN requires extensive client setup • A reverse proxy does not handle all situations • A URL generated by a client side script, applet or control • An Alternative…
Gateway Client • MetaFrame Secure Access Manager utilizing the Gateway Client allows access to all or some internal web content located on the corporate intranet • The Gateway Client is an ActiveX component
Gateway Client • Downloaded to and hosted by the client web browser after user authentication • The Gateway Client reads the proxy settings of the host web browser when it is launched • It inserts itself between the web browser and the client side proxy • If no client side proxy is detected • The Gateway Client acts like a client side proxy
Gateway Client • The client intercepts the HTTP or HTTPS traffic and encapsulates via the CGP protocol • It determines whether the URL request is for an internal or an external site • Internal site • the client side component redirects the traffic through the Secure Gateway to the correct site • External site • the client side component allows the request to be resolved by the client locally.
Gateway Client • What if my device cannot download the Gateway Client? • Internet Café • Small Handheld Devices • When the Client is not present, the Secure Gateway allows only authenticated requests to the MetaFrame Secure Access Manager to pass through the Secure Gateway
Access Control Lists • The Access Control List (ACL) has been extended • The Network Administrator defines the ACL on the Gateway • The ACL is used by the Gateway to determine if a request to connect to a server can be honored • Server name, port and protocol are required in the ACL • The Gateway will discard the connection otherwise
Access Control Lists • One Access Control List (ACL) for all outgoing connections from the Gateway • Incoming connections have an ACL for each interface (only one configuration though) • There is effectively a single ACL for all incoming connections to the Gateway • The ACL is used on the Secure Gateway Proxy to restrict connections to Gateway only
Server Access List • The Server Access List is a subset of the Access Control List • This is defined by the Administrator using the Access Management Console (AMC) • The Server Access List defines which web servers may be accessed using the HTTP(S) protocols
Internet Internet Explorer and ICA Client MetaFrame XP Server Farm Secure Gateway STA Web Interface 3rd Party Auth Single DMZ Deployment • The Secure Gateway is deployed in a single-staged DMZ • The Gateway accepts connections from the Internet via an external facing firewall • Makes connections directly to the resource requested • This was the Secure Gateway v1.x deployment model
Single DMZ Deployment • Logon Agent is installed on the same server as the Secure Gateway • The connection is typically not encrypted in this situation • IIS server should be locked down to allow access from the Secure Gateway only
Internet Single DMZ Design MetaFrame XP Server Farm Internet Explorer and ICA Client Secure Gateway MetaFrame Secure Access Manager Logon Agent Authorization Service + STA HTTP(S) ICA 3rd Party Auth
Internet Single DMZ Design with Gateway Client MetaFrame XP Server Farm Internet Explorer and ICA Client Secure Gateway Gateway Client Internal Web Servers MetaFrame Secure Access Manager Logon Agent Authorization Service + STA HTTP(S) ICA 3rd Party Auth
Internet Single DMZ Design MetaFrame XP Only MetaFrame XP Server Farm Internet Explorer and ICA Client Secure Gateway Web Interface STA HTTP(S) ICA 3rd Party Auth
Double DMZ Deployment • A double-hop deployment is where a Secure Gateway and Secure Gateway Proxy are deployed in a multi-staged DMZ • The Secure Gateway accepts client connections on one side • The Secure Gateway cannot make a direct connection to the requested resource • The resources requested by the client are sent to the Secure Gateway Proxy
Double DMZ Deployment • The Secure Gateway Proxy passes the requested resources via SOCKS V5 • The default listener port for the Secure Gateway Proxy is 1080 • This request can also be encrypted with SSL • The Secure Gateway Proxy is a mode of the Secure Gateway
Double DMZ Deployment • The Login Agent currently does not use proxying for its connections • It is deployed in the second stage DMZ • The Logon Agent and Web Interface server are accessed by the Gateway through a single hop • It also allows the Logon Agent and the Web Interface server to access the Authentication Service, STA and MetaFrame server through a single hop
Internet Double DMZ Design with Gateway Client MetaFrame XP Server Farm Internet Explorer and ICA Client Secure Gateway Proxy Secure Gateway Gateway Client Internal Web Servers MetaFrame Secure Access Manager Authorization Service + STA Logon Agent HTTP(S) ICA/Secure ICA 3rd Party Auth
Internet Double DMZ Design with MetaFrame XP Internet Explorer and ICA Client MetaFrame XP Server Farm Secure Gateway Proxy Secure Gateway STA Web Interface HTTP(S) ICA/Secure ICA 3rd Party Auth
Secure Gateway Management • The Secure Gateway Management features are centralized in a MMC Snap-In • The snap-in allows an administrator through a single management console to: • Monitor active HTTP connections • Monitor and control active ICA connections • Display Gateway configuration • Display Gateway Performance Monitor counters • Launch Gateway Configuration Utility
Secure Gateway Management and the STA • The STA XML protocol has been modified • This change is used to uniquely identify ICA connections in the Gateway session manager • The STA XML protocol now includes an extended data (XData) element • This contains an escaped XML document with the following data elements inside it • Server Address (MetaFrame address and port) • Username • User Domain • Application Name • Protocol
Secure Gateway Management • The Secure Gateway Management MMC Snap-in presents a list of all current sessions. • The following information is provided for each entry (session) in the list: • Client IP Address • Server IP Address • User Name • Domain • Application Name (ICA only)
Secure Gateway Management Cont. • Bytes Count To Client • Bytes Count From Client • Bytes Count To Server • Bytes Count From Server • Time Established • Time Elapsed • Time Idle
Performance Monitor Counters • Total Successful Connections • Total Successful Connections (HTTP) • Total Successful Connections (ICA) • Total Failed Connections • Failed Connections (Timed Out) • Failed Connections (SSL Error) • Failed Connections (Server Connect Error) • Failed Connections (STA or AS Error) • Failed Connections (ACL Rejected)
Performance Monitor Counters • Total Bytes from Gateway to Client • Total Bytes from Client to Gateway • Pending Connections • Total Active Connections • Active ICA Connections • Active HTTP(S) Connections • Active Other Connections • Peak Active Connections • Peak Bytes/Sec from Gateway to Client
Performance Monitor Counters • Peak Bytes/Sec from Client to Gateway • Last Client Connect Time • Longest Client Connect Time • Total Successful Ticket Validations • Total Failed Ticket Validations • Total Successful Validations (Requests) • Total Successful Validations (Cached) • Total Failed Validations
Error Logging • Four levels of logging by the gateway will be collected: • FATAL • ERROR • WARNING • INFORMATIONAL