Download (pdf)

Actually, it is often the same problem that has to be addressed. If a network cannot be trusted to carry the information or if application servers need protection against malicious traffic and attacks, it does not matter whether we are talking about a corporate network or the Internet.
We normally don’t place servers directly on the Internet without protection, and similarly when the internal network becomes too large or some information is too sensitive, the internal network should not be trusted either.
The AppGate system protects the traffic, authenticates users and authorises traffic as well as protects application servers from hostile traffic regardless of whether the network is the Internet or an internal network.

The DMZ is probably a good place to put the AppGate server. But please be aware of that traffic separation may be a good idea on the DMZ. If all servers on the DMZ can see all traffic being transported on the network, it is possible, for example from a compromised web server, to see all the traffic on the DMZ including traffic from the AppGate server to internal application servers. A solution may be to use switches or VLAN technology to separate traffic, or to give the AppGate server a direct connection to the internal network.

No, the AppGate server contains firewall functionality and can protect itself. If there is a firewall or a router already in place, it can act as an additional level of protection although it is not necessary.
The AppGate server can even be configured to allow arbitrary IP traffic between the networks it is connected to. This means, for example, that it is possible to allow a web server on a protected network to access another server outside this network, for example a database server, through the AppGate system. This can be cost saving since additional equipment to control this traffic is not needed.

The AppGate server is not a substitute for a firewall between a corporate network and the Internet since a firewall normally performs different tasks, such as to filter incoming and outgoing e-mail and web traffic. The AppGate system can, however, act as a “screening router” which in some instances is a substitute for a conventional firewall.

Yes. The security of the AppGate system does not depend on the underlying transmission technology and the traffic is encrypted all the way between the client and the AppGate server. The built-in encryption in WLANs encrypts only the traffic in the air and not the whole transport path. The AppGate server will, in addition, require all users to be properly authenticated before any access is granted.

The log files are very detailed. They show all user activities, when logged in, from where, from what kind of system, what role was selected, what services were activated and when, etc. It is also possible to get extended information about several application protocols such as for FTP and NetBIOS about what files were transferred, even including all data if desired.

Yes. It is possible to specify that one category of users should have access to, for example, www.company.com/sales and another category to www.company.com/support. This functionality relieves web servers from having to do user authorization and can save both work and equipment.

The AppGate server can offer a virtual printer to all application servers. All printouts are stored on the AppGate server and when a user who owns a printout logs in, it can be automatically downloaded to the user’s workstation and sent to a local printer without user interaction. There is a product sheet available that describes the secure local print module.

Yes, the AppGate server keeps a list that tells where to search for user accounts. It searches all servers until the user account is found. A typical list can be: internal database; an external LDAP server; an RSA Authentication Manager (formerly named ACE server, used for SecurID authentication); and finally an Active Directory server.
Users may also be given the choice to use one or more authentication methods, and the available services may then depend on what method is being used.

Yes, it is easy to specify how groups found in AD or LDAP should be mapped into AppGate user roles. This is very convenient in situations where user administration and rights management should be separated from the details about what services each category of users should have access to. The AppGate database then tells how each category of users should be mapped into various services.

Throughput varies depending on the selected cryptosystem, key length, type and nature of the traffic and number of simultaneous users. Except for 3-DES (which is slower than the rest), the total throughput through the server is relatively independent of the cipher selected. Therefore, selection of cipher should not be based on performance but on what cipher and key length is suitable in each environment. By default, AES with 128-bit keys is used.

Client performance is almost never an issue. The AppGate server can be a bottleneck when number of users becomes very large or when large amount of traffic should be handled, in which case an AppGate cluster may be necessary to use. However, in almost all environments, experience has shown that it’s either the available network capacity or the application servers that limit performance, not the AppGate servers. Remember that AppGate servers only encrypt and decrypt traffic but application servers have to perform calculations, access disks and generate all that traffic.

A typical round-trip delay between a client and an application server behind an AppGate server is less than a millisecond. Transmitting 512 bytes back and forth between two workstations through an AppGate server takes in the order of a millisecond which is comparable to a normal router. Thus, a user will not feel that “a server or the network is slow” even though all network traffic is encrypted.

It is easy to believe that hardware would be a simple way to increase the processing speed of the AppGate server, but it is actually cheaper to buy one more appliance box than adding special hardware for encryption. In addition, practical tests have shown that the time it takes to send a packet to the hardware, to initialise it with the user’s private session key and wait for it to complete, is about the same as encrypting the data packet in software (the average packet size is approximately 300 bytes).
However, hardware may speed up asymmetric key generation (i.e. the connection and authentication process), but this can again be solved with multiple hardware boxes when number of users become very large. (Some SSL solutions need to generate asymmetric keys each time an application connects to a server, not just when a user logs in. In this case, hardware acceleration is necessary. AppGate does not have this problem.)

An AppGate system can consist of one server (one box) possibly with several processors, or a cluster of servers sharing the load. In a multi-server environment, users are dynamically assigned a server to work with when they log in to the system. The selection is either done automatically by the client (recommended) where it randomly selects one server to connect to in the cluster. If that server does not respond, the clients will automatically, and invisibly to the user, try to connect to another server in the cluster.
This means that a server cluster with two machines will on average host 50% of the users each. Another advantage is that adding more servers to the cluster results in an almost linear increase of performance.
The servers in a cluster only share authentication and authorisation databases and the log system. Each server is rather independent of the other, thus an AppGate cluster can support virtually any number of users. Adding more processors or boxes to a system improves performance almost linearly. The only drawback is if a server crashes for example due to a hardware problem, then the users are logged out and have to reconnect to the system again. But this happens rarely and the linear scaling of the system when more boxes are added is a much more important feature of the system.
There is no upper limit on the number of users that can be defined in a system. Number of simultaneously active users is only limited by the number of servers available in a cluster. It is easy to build single systems for tens of thousands of simultaneously active users. It may also be worth mentioning that a cluster is administered as one entity, i.e. number of systems in the cluster does not affect how services and user rights are administered.

Yes. An AppGate server can have many network interfaces so an AppGate server can be connected many networks and accept connections from all. However, the server must have a “default route” for outgoing traffic which manually must be updated if that connection becomes unavailable.
A cluster of two AppGate servers can be used to avoid manual reconfiguration when two Internet connections are available. Each server is then connected to one Internet connection and will handle incoming connections from that network. The servers are administered as a normal cluster and all the clients on the Internet will automatically do load balancing and automatically try the other AppGate server if the first for some reason is not available. This is a very cost effective and simple method to build redundant systems with many incoming connections.

SSH version 2 is a standard protocol in the Internet world. It is an open protocol that many people have analysed exhaustively for vulnerabilities and has been in use for years. More information can be found on the IETF web pages: http://www.ietf.org/ids.by.wg/secsh.html

Very little. Only a small extra field is added denoting what tunnel the data belongs to. For normal sized packets this is negligible, and even for very small data packets, the normal TCP and IP headers are much larger. In addition, compression can make the final data packets being sent much smaller than without using the AppGate system.

Traffic can be compressed before encrypted and transmitted. Depending of the type of data, the total traffic load may decrease with up to 50% (for example for plain text such as web traffic). If network bandwidth is an issue, for example for home users or users using mobile devices, they will experience a performance boost. For users being charged for amount of data being transmitted, compression can decrease transmission costs as well.

The protocol demands mutual authentication of the server and the user (this is, for example, optional in SSL), it supports tunnelling (also missing in SSL), it is an application level protocol (as is SSL but not IPSec) and as such it is independent of operating system versions and service packs. It also runs on most systems and is able to handle NAT, network address translation.

Yes, but please note that UDP is often used to allow users to browse and see resources on a network, which, from a security point of view, is not always a very good idea. The AppGate NetBIOS proxy eliminates the need for UDP for Windows file sharing while simultaneously increasing security. This should minimise the need to use UDP in most installations.
If UDP is still needed, AppGate supports UDP through an optional IP Tunnelling Module which supports not just UDP but also offers many other features (please see the technical specifications for more details).

There are some fundamentally different ways to tunnel traffic using an AppGate client:

• Using standard tunnelling: all remote services are seen by the applications as if they were executing on the local machine, thus they can be accessed through the server name “localhost”.
• The AppGate client can dynamically store the names of accessible application servers in the hosts file (i.e. it writes an entry for the server and gives it the IP address 127.0.0.1), thus applications can access servers using their real names, not only through the name “localhost”. When the server is no longer available, the entry is removed. This mechanism is completely dynamic and invisible to the applications, thus they can refer to remote machines using their correct server names.
• The AppGate clients can also use unique IP addresses for remote hosts. Each host is given an address like 127.0.0.x where “x” is a unique number for each service or host the user has access to. This avoids port conflicts if many application servers want to use the same port number. This feature is by default enabled in clients as of version 6.0 and can manually be enabled in older clients.
• The AppGate client can make use of the IP Tunnelling module. When installed, it intercepts all traffic and is completely transparent. Note that all authentication, encryption, etc., is still performed by the AppGate client and that this module only adds another traffic interception mechanism to the system.

Yes, this is handled automatically by the SSH protocol. When the client and server negotiate session crypto-keys (using the Diffie-Hellman scheme), the client also verifies the AppGate server’s identity. This procedure is done in such a way that it is impossible for someone to act as a man-in-the-middle.

File sharing through the NetBIOS proxy is supported on most platforms. However, Windows 9x systems may due to a bug (or limitation) in the operating system experience problems when attempting to map network drives through the AppGate server. This occurs because the Windows 9x operating system is single threaded (DOS based) and applications, such as the AppGate client that encrypts traffic, may not always be given any CPU time. A similar problem exists with MacOS 9 and earlier with Apple Share, where the operating system scheduler does not give control back to the encryption process. (File sharing is of course fully supported in MacOS X.)

Yes, older clients can always be used together with newer servers (newer clients may not always be used against older servers). This makes it easy to upgrade server software without upgrading the client software. AppGate has the ambition to always support at least one major release-level back for the clients, for example to support all 6.x clients against all version 7 servers.

The applet can be configured to clean up after itself. The applet saves settings and can cache itself on the workstation for faster download, but it never stores any sensitive data. Web pages retrieved through the browser are placed in the browsers cache. It is also possible to configure the applet to clean the browsers cache when exiting if the browser is IE running under Windows.

There is a special version of the client available that can execute on these systems. The only difference is that it always checks the owner of the connecting application to make sure it matches the owner of the secure connection. If this was not done, all users on the terminal server would be able to use the remote resources. Unix and Linux clients can also perform these checks.

Yes, the applet is downloaded from the client when needed, but also the standard client is automatically updated when a new version becomes available on the AppGate server. This is done using the Java WebStart feature which is integrated in all newer versions of Java. It ensures that the users always have the latest client installed. It even automatically handles situations where different clients are needed to different AppGate servers, if that situation would occur. The administration console is updated in the same way. This makes it extremely easy to maintain the client software.
Client configuration can also be controlled by the server. It is possible to override all user settings and configure menus and other settings from the server.

Yes, all clients using the Secure Shell (SSH) protocol version 2 can be used even though non-AppGate clients will not have the same “active” GUI. Instead, the user gets a text-based interface and has to configure the SSH client manually. Also, non-AppGate clients might not be able to support all the authentication methods. Other features are also missing such as IP Tunneling support, cleint check functionality, host file writing, etc., so the user experience using these clients will not be the same.

The major component in an AppGate system is the AppGate server. MindTerm is “just” an SSH client written in Java for wide platform support and it has some nice features not found in other implementations. The AppGate Client is built on MindTerm technology but it does not require any manual configuration and is controlled and configured by the AppGate server. MindTerm can also be used as a stand-alone SSH client when connecting to non-AppGate SSH systems. MindTerm is also available as a library used by many OEM customers who need SSH support in their applications.

It is possible but not recommended for two reasons: first, from a security and maintenance point of view, the AppGate server should run as few extra applications as possible without interference of possible other software. Second, since the policy manager signs each new policy generated, it may significantly affect the performance of the AppGate Server if they share the same server box and many policies must be signed.

Yes. It should be protected as all other application servers with a firewall. A good and simple solution is to install the AppGate Personal Firewall on the policy server as well.

The personal firewall has a Check-Mark certification in the personal firewall category (and the AppGate system in the VPN category). When more certifications become ready, we will add them here as well.

Back to top