Components of Zorp

Zorp consists of individual components; this modularity results in great flexibility. A typical Zorp gateway consists of the following components:

• Zorp: Zorp is the application-level proxy gateway itself, inspecting and analyzing all connections.
• Zorp Management System (ZMS): The central server managing the components of Zorp. ZMS stores the settings of all components (the implementation of the security policy) in a database, and generates the configuration files needed by the other components. More information
• Zorp Management Console (ZMC): Graphical user interface for ZMS; the administrators use this application to manage the system. More information
• Zorp Authentication System (ZAS): The component implementing the authentication of network connections. It mediates the authentication information between Zorp and the user database (e.g.: Microsoft Active Directory). More information
• Zorp Content Vectoring System (ZCV): Content vectoring framework with several different modules (e.g.: virus- and spamfilters). It can inspect the data part of the traffic, even in encrypted channels. More information

Top

Zorp Management System (ZMS), Zorp's easy-to-use, central management system provides a uniform interface to configure and monitor the elements used in perimeter defense: Zorp gateways, content vectoring servers, as well as clusters of these elements.

How the management system works

The administrator uses the graphical interface (Zorp Management Console, ZMC) to edit the configuration files stored on ZMS. ZMS stores the configuration of all components in an XML database. The administrator saves the changes of the configuration to ZMS. ZMS generates the configuration files into the format understood by the different devices, and downloads them to the proper device (firewall, content vectoring server, etc.). The devices communicate only with ZMS; they are not directly accessible from ZMC.

The graphical user interface

Zorp Management Console (ZMC) is a graphical user interface to administrate ZMS and the managed devices. All configuration tasks can be performed easily with ZMC - even without Linux administration skills.

Multisite management

Different, even completely independent groups of Zorp devices can be managed from the system. That way devices located on different sites, or at different companies can be administered using a single interface.

Monitoring

ZMS can continuously monitor the operation, load, and other parameters of the managed devices. The received status information is immediately available on the user interface; automatic alerts warn the administrator of critical problems. All monitoring data can be stored in a database and displayed in graphical form or as tables.

Supported platforms - ZMS and ZMC

ZMS can be installed on a machine running Zorp, but - especially when using several devices - it is recommended to separate the roles and use a dedicated machine to run ZMS. ZMS runs on ZorpOS in both cases.

The ZMC graphical user interface is available on the following operating systems:

• Microsoft Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7
• GNU/Linux (Ubuntu Lucid Lynx)

Top

The Zorp Authentication Server (ZAS) can authenticate all connections passing the network gateway. Network authentication aims to authenticate all connections initiated by the users to restrict access of certain services only to the authorized personnel. In contrast with the common practice that identifies the user with the IP address of his computer, the solution provided by Zorp identifies and audits the complete network traffic on the user level. Both inband (authentication within the protocol) and outband (authentication outside the protocol) is supported. The advantage of outband authentication is that it can be used with any protocol and authentication method, making it easy to implement single sign on that is transparent to the users.

ZAS in a nutshell

ZAS is not an authentication database, but a middleware that mediates the authentication between Zorp and an existing database that stores the user information. That way network authentication is easy to implement and integrates smoothly with the already established infrastructure. When a client tries to access a service (i.e. initiates a new connection) that requires authentication, the Zorp firewall forwards the authentication data (e.g.: username, password, etc.) to the user database via ZAS. Access to the service is granted only if the authentication is successful.

Supported databases

• LDAP (Microsoft Active Directory, POSIX, Novell Directory Services / Novell eDirectory)
• PAM
• RADIUS
• Apache htpasswd file
• Built in ZAS database
• TACACS

Supported methods

• username/password
• S/Key
• CryptoCard RB1
• LDAP binding
• GSSAPI/Kerberos5
• x.509 certificate

Single sign on

The Zorp Authentication Agent application and the Kerberos protocol together provide an effective single sign on solution where the user has to authenticate only once - the system automatically handles all later authentications. A further advantage of outband authentication is that it enables the use of strong authentication methods (e.g.: hardware token) with protocols that support only weak methods (e.g.: username/password).

Influencing the quality of service (QoS)

Zorp's dynamic decisions make it possible to assign connections of different quality to the users or user groups. For example, the bandwidth and other parameters of the connection can be modified based on the result of authentication, the client application used, the address of the target server, etc.

Top

Thorough and deep-level filtering of the network traffic became essential because of spam, viruses, trojans, and other malicious contents. This task is performed most conveniently at the network perimeter, as all traffic to and from the Internet must pass this point. The Zorp Content Vectoring (ZCV) framework - building on the Zorp application-level gateway - can analyze more than 10 traditional and embedded protocols, and natively supports high availability and load balancing. ZCV also helps to filter encrypted protocols (HTTPS, POP3S, etc.) that are used to download malicious codes with increased frequency.

ZCV in a nutshell

The Zorp application-level gateway inspects only the protocol-specific part of the traffic; ZCV examines the content. ZCV is not a content-vectoring engine, but a framework that provides a uniform interface to manage and configure several content-vectoring modules, like virus- and spamfilters. Zorp passes the data to be examined to ZCV, along with parameters like traffic type, etc. ZCV forwards the data to the content-vectoring modules, so the actual content filtering is performed independently from Zorp, and can even be performed on separate machines. This architecture supports content-vectoring clusters as well.
ZCV can be configured to examine the data with different modules, or with different configuration of a module, based on the parameters of the inspected connection or file. The same module with different parameters can inspect different services, for example, a virus filtering module can examine all files passing the firewall in HTTP traffic, and all e-mail attachments - with different settings. Different types of files or traffic can be inspected with different groups of modules. In the above example, the HTTP traffic can be inspected with a virusfilter and a content-vectoring module, and all client-side scripts can be removed, while the same virusfilter module (possible with different settings) and a spamfilter can examine the e-mails.

Trickling

ZCV supports the so-called trickling to avoid timeouts and increase user-satisfaction. This means that the proxy can send small bits of data to the client, who feels that the data is coming steadily, but slowly. Trickling can start while the file is being downloaded, consequently the trickled data cannot be filtered for viruses. Theoretically, this may allow a virus to get through undetected. To avoid this situation, ZCV calculates the size of the trickled data from the size of the downloaded file. Since the trickled file is incomplete, the chance of a working virus reaching the client is negligible.

Quarantining

Files that the content-vectoring modules reject as infected or spam are usually deleted. As this is not always acceptable, temporarily the data must be stored in a safe location, until it is determined whether they contain any important information. Sometimes a file is important even if it is infected, because disinfection is not always possible and can also damage the file. Also note that the virus- and spamfilters are not unfailing, and occasionally reject "innocent" files or e-mails.
All ZCV modules use a common quarantine. The size of the quarantine is flexibly adjustable based on the number, size, or date of the files in the quarantine. Such rules can be assigned to the different types of quarantined files based on the metadata stored about the file (e.g.: type of infection, used protocol, sender of the e-mail, etc.).

Supported modules

With the help of ZCV, Zorp can filter over 10 protocols for viruses, including encrypted protocols like HTTPS and POP3S.

Currently ZCV supports the following modules:

1. Virus filtering modules
   1. ClamAV (www.clamav.net)
   2. NOD32 (www.nod32.com)
   3. VirusBuster (www.virusbuster.hu)
2. Spam filtering modules
   1. SpamAssassin (spamassassin.apache.org/)
   2. Commtouch (www.commtouch.com)
3. An URL classification and filtering module for HTTP and HTTPS, allowing you to control what kind of content is available for users accessing the Internet. Each URL is categorized based on the supplied database. Access to the URL can be allowed or rejected based on the category of the URL.
4. An HTML filtering module capable of filtering JavaScript, ActiveX, Java, and Cascading Style Sheets (CSS) - in addition to general content filtering.
5. A general stream filtering module (sed) capable of filtering and manipulating the strings in data streams.
6. A general e-mail header filtering module (mail-hdr) capable of filtering and manipulating e-mail headers.