The previous section presented the fundamental technology and outlined the operation by going through the steps in a normal user session.
This section will simply present the major features to give a more complete picture of what an AppGate system can do.
The client can temporarily suspend the communication with the server. This is useful for unreliable connections like GPRS or if the client computer changes IP address (e.g. a laptop moving to another location).
To reduce the amount of traffic sent or received, data compression may be enabled in the client. On very slow connections this may also improve the response times.
The client can be configured to use a local proxy to reach out from a local network and onward to an AppGate server.
If SSH hosts keys are not known beforehand, a scheme with X509 certificates can be used.
AES128, AES256, Blowfish, 3DES and RC4.
A client computer running an X Window server can display remote X applications via the encrypted tunnel.
The client can send keep-alive packets to maintain a connection through proxies.
The AppGate system differentiates between user account establishment and user authentication. As an example, a user account may be found to exist if an appropriate LDAP record is found; this user may then be authenticated toward a SecurID server or with a certificate.
User accounts may be searched for in a number of sources:
The AppGate internal user database.
From any LDAP-compatible directory such as Active Directory. Multiple LDAP sources may be used, and attributes in the user record may specify AppGate roles and allowed authentication methods.
Radius, SecurID and Certificate. These are primitive and somewhat limited sources for account establishment, but can be useful in some cases.
The AppGate system supports a wide range of authentication methods:
Password: Plain passwords are used for authentication. Passwords are stored and managed in the AppGate user database.
LDAP: The AppGate system can use a connection to an LDAP based directory as a password type of authentication.
Radius: The common client-server security protocol best known for providing remote authentication and access.
RSA SecurID: Short-time passwords generated by a small hand-held token. The AppGate system talks to an RSA Ace server using the RSA native protocols.
Certificate: Uses any X.509 certificate, including certificates issued by Verisign and SmartTrust, for authentication. On the client side, the user certificates can be retrieved from MS-CAPI, PKCS#11, MS Explorer Certificate Store, Mozilla/Firefox Certificate Store or directly from files in PEM, DER or PKCS#12 encoded formats. One can upload CA certificates to the AppGate as well as configure revocation policies.
A large number of popular smart cards, USB based and other certificate sources can be used via MS-CAPI or PKCS#11.
Kerberos: a non-interactive method where the client uses a Kerberos ticket to authenticate to the AppGate server. The client obtains the ticket from the local Key Distribution Center which is a Kerberos server. Microsoft Active Directory also works as a Kerberos server and can be used for AppGate authentication.
Note that the client must be able to talk to, and be authenticated by, the KDC before it can be authenticated by the AppGate server. This means that the KDC must be reachable without going through the AppGate server.
Entrust: Uses the Entrust Technologies PKI environment. Entrust certificates are used only for authentication.
Public key: Authentication through asymmetric key cryptography using DSA or RSA keys. This is useful for automated SSH connections.
CryptoCard: A token based challenge/response system that the AppGate system supports natively. The AppGate server communicates with the CryptoCard server via the Radius protocol.
The Entrust, LDAP, Radius, Kerberos, CryptoCard and SecurID methods all require third party products in addition to the AppGate system.
When an AppGate client connects to an AppGate Security Server, a Client Check may be performed. The Client Check can check for any type of state at the client side. E.g. check for a certain anti virus software, a certain hardware configuration, check that a specific process is running, a file exists or just about anything else.
The result of a Client Check is fed back to the AppGate Security Server and can be used as a factor in any Access rule.
An AppGate client can be instructed by the AppGate Security Server to activate a rule set in the AppGate Device Firewall. This rule set will last for the whole session. An Access rule can be used to verify that such a rule set is actually effective.
Two or more AppGate servers can be configured into a cluster. The main purpose of a cluster is to increase performance. A cluster may also reduce the risk that hardware failures causes the system to become unavailable.
Gives true IP connectivity from the client to the application server. It is able to give full network access and is able to handle protocols which are difficult or impossible using the Port Forward method.
The client can write entries to the hosts file in order to map host names to the special 127.0.0.x IP addresses that the Port Forward mechanism relies on.
This feature may also be used for IP tunneling if no internal DNS servers are available for the client.
The client can use multiple local IP addresses like 127.0.0.2 and 127.0.0.3 in order to handle Port Forwards for the same port number going to multiple servers.
The client GUI can be Localized for other languages.
The client contains a complete VT100 terminal emulator which can be used to connect to servers.
The technically oriented users can have a detailed view of IP addresses and port numbers to actually see what traffic is allowed.
Can pick up print jobs from the inside and print on locally attached printers.
The server can attach an HTTP header to HTTP traffic. The header will contain the authenticated user name.
The server can also route the HTTP traffic through a special "Web agent". The Web agent is a customized script located on the AppGate server which knows how to login a user to other web applications.
An AppGate server also answers questions for the standardized "ident" protocol.
The AppGate server can synchronize its time from an NTP server.
The AppGate log can be sent to an external syslog server.
The AppGate Appliance has two partitions, which can contain complete and different AppGate versions and operating systems. This is useful when upgrading and as a backup.
The AppGate console can be used to make a configuration backup of the server.
The AppGate server can send SNMP traps when certain criteria are met.
Using the console, it is possible to monitor each user session. It is also possible to terminate a specific user session.
The configuration files on the AppGate are stored in a plain-text format, which is open and documented - this makes it possible for customers to develop scripts and do other customizations. It is also possible to transfer files to and from the server using the AppGate console.
Other features of the AppGate system include: Idle timeout, Extensive password policies, Message Of The Day, Built-in web server for client deployment, and FTP, HTTP, telnet and NetBIOS proxies.