Zorp 3.3FR1 Administrator's Guide

A firewall is a network perimeter security device that is used to filter network traffic that is intended to pass through it in either direction according to some predefined rule set. Perimeter device means that the firewall is a boundary between two or more network segments and typically the only place where traffic from one of these network segments can — theoretically — can get to another one. Whether the traffic in question reaches its destination depends on the firewall — more exactly on the rules firewall administrators define. It is very important to note that firewalls do not necessarily sit between the Internet and some corporate intranet; in many cases firewalls are placed between segments of a company's own intranet or connect not just two but many networks.

Firewall devices have other roles, such as being the endpoint of Virtual Private Network (VPN) connections or hosting Intrusion Detection Systems (IDS), for example. These are legal and typical auxiliary tasks besides its original role, that is, filtering traffic. This filtering, however, is not an ad-hoc decision; the firewall is a device whose task is to implement the rules dictated by the IT Security Policy of the organization. In other words, firewalls can only be implemented successfully in organizations where a valid and effective IT Security Policy is in place.

Firewalls have undergone a significant evolution in terms of functionality, sophistication and the level of protection they can provide. Today two main branches of firewalls dominate the field: packet filters and application proxies. Although they are build with the same intent — to protect by filtering — they are fundamentally different technologies. For the understanding and successful administration of Zorp, which is an application proxy firewall it is very important to know how these two technologies work and how they differ from each other.

Packet filters always work at the packet level. Packets, which are basically IP datagrams, enter the packet filter on an interface and the same packets leave on another interface, depending on predefined rules. Packet filters analyze packet header information such as addressing, port numbers, protocol options. Rules that administrators create operate mainly on this information. A typical packet filter rule translated would look something like this: 'open port 80 on the internal interface of the firewall and let the internal clients access webservers on the Internet'.

Packet filters are fairly easy to understand for firewall administrators with a solid knowledge of TCP/IP. Traffic monitoring and analyzing software, sniffers help in analyzing what is going on on packet level. Originally, packet filters were unaware of TCP sessions, that is, they were unable to pair packets going out as a request and packets coming in as responses to that request. Therefore, to create a rule to permit, for example, web access for internal clients, two separate packet filter rules were needed: one that permitted traffic going out on port 80 and another one permitting traffic coming in on the dynamic port range, 1024-65535. This solution was both inconvenient and fairly insecure: it essentially opened wide the majority of TCP/UDP ports.

To eliminate this problem a new generation of packet filters were developed, the stateful packet filters. Stateful means that these packet filters are aware of the TCP sessions that the communicating parties build up using the 3-way TCP handshake mechanism. Using stateful packet filters it is sufficient to specify allowed traffic in one direction and the firewall — storing the session buildup and state information — automatically allows packets belonging to that same session in either direction.

Today almost all operating systems have a built-in stateful packet filter, some of which, like IPTables under Linux is quite sophisticated and allows for a lot of packet inspection and modification techniques. However, they can only investigate packet headers and make decisions based on this and on state information. Though some form of application filtering exists in advanced packet filters as well, this feature is very difficult to implement at this level. Due to the unreliable nature of IP protocol, packets arriving at the packet filter cannot be expected to be in correct order, packets lost in transit are retransmitted and thus must be handled accordingly, and so on. These problems together make it extremely difficult for packet filters to analyze streams of packets as complete communication sessions. Therefore, typical packet filters do not perform application filtering.

Attacks coming from the Internet today, however, are becoming ever more sophisticated and in most cases cannot be stopped by packet filters. They are targeting legal services that are allowed at the packet filter level, for example, a public webserver on port 80, and try to exploit vulnerabilities in the given services. Code Red and Nimda were typical examples for this type of attack: they sent malicious URI requests to web servers that, when processed by Microsoft IIS servers, resulted in buffer overflow situations and allowed for arbitrary code execution. Since packet filters can only investigate protocol header information like source and destination address and port number, which were correct in these attacks, they had no means to stop these worms. This level of protection can be realized by application proxy firewalls.

Application proxy firewalls work a level higher than packet filters and in general add more intelligence to the filtering process. Regardless of the level of their sophistication or their extra features, at a minimum they always form the end point of a communication flow and a starting point of another one. That is, when computers on different sides of an application proxy firewall start building up a communication channel between each other, they can only communicate directly with the application proxy. It is the application proxy that maintains the two different communication channels towards the parties and decides, based on its implementation or the rules specified, whether to communicate with either parties at all. This is in sharp contrast with packet filters that do not create new packets, just let through and possibly alter the original ones.

Application proxies do not pass unaltered packets from one of their interfaces to another one. They do not work with packets at all. Although it is true that packets enter and leave the firewall, by the time the application proxies get involved with the communication flow these packets have been dissembled and handled by kernel components of the underlying operating system. Application proxies leave packet management to the kernel-level services and as an input they get continuous data streams. This way they only need to focus on application data. These data streams contain application-specific control information, such as HTTP request headers, and end user/process data. Based largely on this information, the direction of traffic and the rules defined application proxies then decide what to response to the incoming data stream. If, based on the rule set specified by a given application proxy, the incoming data stream is acceptable for service, the proxy component initiates the establishment of a new communication channel towards another machine — possibly, but not necessarily the computer the requesting party originally wanted to talk to.

Application proxies analyze the data stream they get according to their preset and administrator specified settings. In Zorp application proxies (except for the Plug proxy) always check Requests for Comments (RFC) conformance. RFCs are documents defining various Internet-related protocols and services. For more information on them, see Appendix 3, Further readings. RFCs clearly define what is actually allowed within the scope of the given service or protocol and how should the parties using the given protocol/service communicate with each other. For example, in case of HTTP there is a limit on the length of URLs supplied in a client request and the character set that can be used in those URLs.

As a general rule, application proxies mainly focus on the actual data part of the communication, the real content, unlike packet filters that focus on protocol header fields.

Application proxy firewalls may seem superior to packet filters, still, they should not replace packet filters everywhere where network security is implemented on a professional level. Indeed, with their protocol and data stream analysis capabilities application proxy firewalls provide a significantly higher level of security than packet filtering ones, but at some performance cost.

Packet filters and application proxies differ in the following three main aspects:

Zorp is not just a service component to be installed on top of a user–preconfigured operating system, but a complete solution rather, that features its own operating system, ZorpOS. It is a hardened, Ubuntu Linux-based operating system that contains only those components and packages that are essential for the operation of the firewall machine and many other hardening steps are also in effect, like the removal of setuid and setgid bits, for instance. In addition to the core components, it has some custom parts as well such as the firewall software. Although this is a fully functional operating system, it is not meant to be used as an ordinary server or workstation system, its primary function is to provide a secure and stable foundation for the firewall (and ZMS host) platforms.

ZorpOS is dedicatedly developed for Zorp. The Zorp firewalling solution is only complete together with ZorpOS.

Using ZorpOS has many advantages over having an off-the-shelves Linux distribution installed.

All application proxy firewall products have a packet filtering component. Starting from Zorp 3.3, packet filtering is handled by the kzorp kernel module. When Zorp starts, it sends all information about the traffic permitted to pass the gateway (i.e., configured services, zones, and dispatchers) to the kzorp module.

Packet-filtering services are completely handled in the kernel.

Application-level services (also called proxy services) are handled on two levels: the kzorp kernel module receives and accepts the connections (this was handled by listeners and receivers in earlier Zorp versions, but these objects have been merged into a single entity called Dispatcher), while all other functionality is performed by Zorp in the userspace.

For both service types the kzorp kernel module makes the client-side access control (DAC) decision. Both service types can be configured from a uniform interface using ZMC.

Handling packet filtering in the kernel has the following important consequences:

Proxying can take two basic forms.

In case of nontransparent proxying clients are aware that they do not talk to the actual server but a proxy machine instead; this solution usually requires some client-side setup before communication is possible. Supplying proxy settings in Web browsers is a good example for this setup requirement. In some cases entire software modules must be installed on the clients which is not always feasible or optimal.

With transparent proxying, however, both the client and server sides of the communication are totally unaware that there is a proxy component involved; all the information that can be gained from protocol headers, for example, show that they directly talk to each other. In case of transparent proxying no client side setup is required.

Zorp uses the TPROXY kernel module for achieving transparency. For more information on TPROXY, see Section 8.8, Proxy classes.

Although not strictly a firewall task, most application proxy firewalls today are bundled with Virtual Private Network (VPN) support. Zorp uses Openswan (the most widely accepted IPSec implementation) to support native Linux IPSec solutions, and also supports OpenVPN (an SSL-based VPN solution). OpenVPN is more user friendly, but somewhat less supported by other systems, that might cause interoperability issues. Using Zorp it is possible to establish both transport and tunnel mode VPN channels. Tunnel authentication is possible with X.509 certificates and with preshared keys. IPSec settings can be negotiated manually or using Internet Key Exchange (IKE). Zorp's VPN solution is compatible with most other vendors' VPN technologies.

Native proxies or otherwise known as native services are responsible for providing a limited number of server–like features in Zorp, or more exactly, in ZorpOS. Their use is optional and depends on the needs and security requirements of the given organization; the use of Network Time Protocol (NTP) and Bind is recommended, while Postfix is useful for managing mail traffic from various firewall components locally.

They are called native because they come bundled with ZorpOS and are available by default. They are implementations of the actual Linux services of the same names. These services are intended to provide networking services that are either hard to implement with application proxies (or at the packet filter level) or provide services for the firewall itself. For enhanced security they can optionally be jailed into a chrooted environment.

For more information on these services, see Chapter 11, Native services.

Logging firewall activities is a crucial task that is usually regulated by the companies' IT Security Policy. All competitive firewall products must provide advanced logging capabilities, a task that Zorp solves using BalaBit's state-of-the-art and widely respected syslog-ng technology. Syslog-ng is a replacement for Unix/Linux original syslog utility with more features, configuration and fine-tuning options. Syslog-ng is a separate product from Zorp and is available for most Linux and Unix platforms.

For more details, see Chapter 9, Logging with syslog-ng.

In large enterprise environment it is often required to cluster two or more firewall nodes together for high availability purposes. Zorp supports multi-node (2+) fail-over clustering. Load-balance clusters are also supported, but such configurations usually require external devices as well. Clustering support must be licensed separately.

For more information see Chapter 15, Clusters and high availability.

Traffic that can be filtered out based on IP and TCP/UDP header information can be blocked at the packet filter level. Likewise, it is possible to forward traffic at the packet filter level without sending it to user-mode application proxies for analysis. For such traffic, Zorp operates like an ordinary packet filtering firewall. Although this may seem a downgrade, in practice traffic forwarding at the packet filter level may be desirable or even the only choice for special protocols that cannot be proxied. Zorp provides a number of built-in, protocol-specific proxy classes for the most typical protocols, and it has a generic proxy as well to be used for protocols not supported by the built-in proxies. Still, there may be protocols, typically non-TCP/UDP or bulk traffic that are not supported even by this generic proxy, in which case the only choice is to forward them at the packet filter level. Packet filter level forwarding is not recommended, unless it is absolutely unavoidable.

Application proxies provide a higher level of security. Packet filters are the first line of defense; they can be used to block unwanted traffic. What is not blocked by default, on the other hand, should be filtered by the appropriate application proxies.

Application-level services inspect the traffic on the protocol (Layer 7 in the OSI model) level. For protocols supported natively by Zorp it is a logical choice to use the dedicated proxy components instead of simply deciding things at the packet filter level. Even for protocols not having a dedicated proxy, Zorp provides a generic proxy, called PlugProxy that — although it does not perform special data analysis — can be used to proxy the traffic in question.

A firewall must always provide a mechanism to control which networks and network nodes are accessible and from where (networks and machines) they are accessible. In other words, in order to create traffic rules, the networking environment of the firewall must be defined accurately. Then, if all the elements of the networking environment are in place, access control can be applied on them. This type of access control is provided by the concept of Zones in Zorp.

By definition Zones consist of one or more IP subnets that are to be handled together from an administrative aspect. This aspect is completely up to you or your systems' security regulations. By default there is only a single Zone defined as the IP network 0.0.0.0/0 which practically means every available IP addresses (i.e., the Internet). Zones can be organized into a hierarchy which becomes important when we discuss policy inheritance.

Although Zones consist of IP subnets and/or individual IP addresses, zone organization is independent of the subnetting practices of the company and can follow an arbitrary logic, thus helping in mapping the human, administrative regulations in place to an actual firewall configuration. For example, we can define a zone that contains the 192.168.7.0/24 subnet and it can have a subzone with IP addresses from the 10.0.0.0/8 range, and the single IP address of 172.16.54.4/32. Since Zones are the Zorp specific representations of the organizations security hierarchy in terms of network access, their design should be deducible from the organization's IT Security Policy. Therefore, ideally you define zones before the very first access policy is created but networking reconstructions or smaller changes are common in any company so you are likely to return to zone creation and configuration when needed.

For more information on zones, see Section 8.4, Zones.

A good firewall product while maintains the highest level of security achievable it should cause as few inconveniences for users as possible. This is usually provided by transparency.

Transparency means that the existence and operations of the firewall are totally invisible for the end user, and no client–side configuration is necessary. A non–transparent firewall, on the other hand, typically requires some client–side setup: either an entire client–side software component is needed, or special settings are necessary such as configuring a proxy server address and port number in the web browser. Since the client–side remains untouched, transparent proxying usually has lower TCO, especially when the number of clients is high and/or network reconstructions happen frequently. Transparency is very important on the server side, too, that is servers contacted by the firewall in response to client requests are also unaware that they are actually visited by the firewall and not by the original clients.

The primary goal of traffic filtering with Zorp is to know about and account for every bit passing through the firewall. A significant measure of application proxies is how skilled they are in analyzing the data they receive. Apart from checking the given protocol header for prohibited options, for example FTP PUTs, they should apply fine grained analysis on the data in question. Zorp has outstanding abilities on this field; checking full RFC compliance of protocol information automatically prevents a large number of attacks from reaching internal targets (Code Red and Nimda worms).

Zorp has dedicated proxies for a number of frequently used protocols/traffic types, including:

Some protocols, like HTTP and FTP are supported with more than one special purpose proxies.

For more information on supported protocols and for a complete list of proxies, see the Zorp Reference Guide available at http://www.balabit.com/support/documentation/.

The built-in, dedicated proxies operate according to the hard-coded default security configurations which, at a minimum, means full RFC compliance for the given protocol. However, often there are specific security or configuration needs that cannot be satisfied by default configurations. For these scenarios Zorp provides proxy customization options which means that a broad range of protocol–specific options (like HTTP header content modifications/limitations in case of HttpProxy) are available. These options are fully configurable via ZMC. For information on, see Zorp Reference Guide.

In addition to changing preset properties, proxy configurations in Zorp are fully customizable: they can be programmed, (scripted) to perform an arbitrary number of custom functions.

Many types of Internet traffic today use more than a single protocol, usually in embedded form. A good example is HTTPS: this is Secure Socket Layer (SSL) protocol with standard HTTP protocol embedded in it. SSL encrypts HTTP traffic and most firewalls simply let this encrypted traffic pass through without serious inspection. This is not an optimal solution from a security aspect and Zorp has a much better solution to this problem: it has a proxy for SSL traffic and it is possible to embed (“stack”) other proxies into it, because proxies can pass data streams to each other. This modular architecture (that is, proxies can be stacked into each other, or even chained together for sequential protocol analysis) allows for sophisticated inspection of complex communications, like virus filtering in HTTPS, POP3 traffic.

Several possible proxy combinations are possible, allowing for a more complete control over traffic passing through the firewall. This ability to build complex filtering systems from proxy modules makes Zorp unique on the application proxy firewall market.

The ZorpOS operating system can be auto-booted from the Zorp CD-ROM and the installation starts automatically.

After booting from the CD-ROM, the installer menu is displayed. The menu is visible both from a local terminal and from a serial console, allowing remote installations.

Select one of the available installation modes:

During normal configuration the installation steps follow each other automatically; in Expert mode they are displayed as a list.

After the kernel has been loaded, the installer displays the End-User License Agreement.

The following options useful for troubleshooting are also available from the installer menu:

The End-User License Agreement must be accepted before the actual installation is started. The complete text of the EULA is also available in Appendix 4, Zorp Application Level Gateway End-User License Agreement. After reading and understanding the license accept its terms and conditions.

Zorp has an easy-to-use text-based installer requiring only a keyboard (mouse is not needed nor supported by the installer). Navigation between the different options of a screen is possible using the cursor buttons. Selected actions (e.g., Go back or Continue) is highlighted in red. When multiple selection is possible use space to select/deselect a given item (e.g., when selecting the Zorp modules to be installed).

Select the region or country from the list where the installed machine will be located.

Expert mode: Select your locale. Additional locales can also be selected.

Expert mode: Select the type (PS2, USB, or no keyboard) of the keyboard used.

Select the layout of the keyboard used.

The installer tries to detect the CD/DVD drive containing the Zorp Installation disk.

Expert mode: Select which kernel modules to load from the ones that were detected as matching your hardware. If requested, the installer can prompt when a module that is accepting load-time parameters is about to be loaded, enabling the customization of the given module.

Expert mode: Configure hdparm if you want to optimize CD-ROM access. Leave the field blank to continue without using hdparm.

This step is available in expert mode only. Most components are loaded automatically, the ones listed here are low priority and are optional. Select the ones you wish to load. Dependencies will be loaded automatically.

The installer detects the available hard disks automatically. The next step of the installation is to prepare, partition and format the hard disk(s). The minimal storage capacity required by Zorp is 1GB.

Partitioning can be performed either automatically or manually. Automatic partitioning is described below, for the details of manual partitioning, see Section 4.9, Manual partitioning.

Automatic partitioning utilizes the total capacity of a single hard disk. The hard disk is partitioned as follows:

The default filesystem used by ZorpOS is ext3. In order to use another filesystem, partitioning must be performed manually.

Please note that automatic partitioning partitions only a single hard disk; any additional disks have to be partitioned manually.

Select the time zone corresponding to your location.

Expert mode: Set the system clock. If the hardware clock of the computer is set to GMT, hit OK.

Provide and verify passwords for the root (superuser) account and a normal user account. The full name of the user with the normal account is also required.

Add the normal user account you have just created to the /etc/sudoers account. This step is required if you want to manage Zorp remotely using SSH.

In this step the base components of ZorpOS are copied to the hard drive. Depending on the hardware, this can take several minutes.

Expert mode: Select the kernel to be installed from the list of available kernel images. Zorp 3.3 installs the 2.6.17 or the 2.6.22 version of the Linux kernel.

The Zorp modules to be installed can be selected on the following screen. The following modules are available on the installation media:

For further information on the different modules see the Introduction chapter of the Zorp Installation Guide and the relevant chapters of the Zorp Administration Guide.

Below are some guidelines about which modules should be installed on the different types of machines.

After choosing the modules to be installed hit Continue.

Several services of Zorp run in chrooted jails. When the jailed services are updated, it is necessary to update the jails as well. This can be (and is recommended to be) performed automatically by ZorpOS. However, if the jail configurations have been manually modified, automatic updates should be disabled, because they will not preserve the manual changes.

Zorp uses Postfix as a native service for handling emails. A mail transferring agent (MTA) must be installed on the machine at least for delivering the locally generated messages.

The basic operation of mail handling on the host should be specified. The following options are available:

Set the name that should appear in the domain part of outgoing mail (i.e., after the @ sign).

zorp-utils includes tools used by Zorp: zavupdate is a tool that updates the databases of the virus filtering engines. In this step these tools are configured. zavupdate has the following options:

The section below describes the configuration options of the Nod32 virus filtering module.

Provide the username and password received from your distributor. If not available at the time of installation, it can be entered later by issuing the dpkg-reconfigure nod32ls command, or by manually editing the /etc/nod32/nod32.auth file.

The databases of the Nod32 module can be instantly updated from the official Nod32 webserver if the machine being installed has network access. Otherwise, an update can be manually initiated by issuing the zavupdate command.

Configure the e-mail notification sending of the Zorp Management Server monitoring subsystem. Provide the e-mail address of the administrator who will receive the notifications.

Openswan is an IPSec implementation used in Zorp for building VPN connections.

The section below describes the configuration options of Zorp Management Server.

License keys can be downloaded from the BalaBit website using a MyBalaBit account (http://www.balabit.com/mybalabit/). The installer can copy them from a 3.5" floppy disk, an USB drive, or it can download them from a webserver using HTTP if network connection for the machine is available during the installation. Beside the license file(s), no online activation or similar is required.

Install the statically or dynamically linked version of the zms-transfer-agent.

apt-get install zms-transfer-agent (or zms-transfer-agent-dynamic)

Install the statically or dynamically linked version of the zms-monitor-agent .

apt-get install zms-monitor-agent (or zms-monitor-agent-dynamic)

Install the zms-engine.

apt-get install zms-engine

Install the zmc graphical administration tool to a client. zmc cannot be installed on a Zorp host.

apt-get install zmc

Other components can be installed similarly.

Start the installer for your platform:

To install ZMC from the command line, navigate to the directory where the installation package is located, and issue the ./zmc-<version_number>-linux-i386.run command.

The installer allows you to set the installation path, and optionally to install the Zorp Administrator's Guide and the Zorp Reference Guide.

Zorp Management Console installation starts simply by running zmc-setup-3.3.X.exe. Make sure you have Administrator privileges or the necessary rights to perform the installation.

After the setup wizard welcomes you, it is required to agree the End-User License Agreement (EULA). Please read it carefully before accepting it.

The following step is to define the installation path. By default the setup wizard offers "C:\Program Files\Zmc" but this can be modified.

During and after the installation process, you can monitor the files and drivers the setup wizard installed.

When the installation process is finished, Zorp Management Console can be started from Windows Start menu. The Windows version of ZMC automatically installs the HTML version of the Zorp Administrator's Guide and Zorp Reference Guide.

During the installation of the Satyr Client 3.3 the pre-configured Debian system will be amended with certain packages and their dependencies. If the dependencies are already installed or an online Debian repository is accessible the Satyr Client can be installed from the Zorp Install CD as well.

Insert the Zorp Installation CD into the CD-ROM and mount it. In the root of the Install CD you find an install.sh script, which can be used to install Satyr on the host. Do not use apt-cdrom to setup the sources.list as it will mix up the apt database.

Finally you need to install the necessary CA certificates into your /etc/satyr/ca/ directory. The Satyr client and the Satyr multiplexer will start automatically.

Satyr is available for Debian etch and Ubuntu 8.04 from the following repositories:

Make sure the following lines are in your /etc/apt/sources.list file:

deb https://USERNAME:PASSWORD@apt.balabit.com/zorp-os debian-etch/zorp-3.3FR1latest satyr

deb https://USERNAME:PASSWORD@apt.balabit.com/zorp-os ubuntu-hardy/zorp-3.3FR1latest satyr

Installation of Satyr client can be started by running satyr-setup-3.3.X.exe. The installation requires administrator privileges.

After Satyr Client setup wizard welcomes you, it is required to accept End-User License Agreement (EULA). Please read it carefully before accepting it.

The following step is to define the installation path. By default the setup wizard offers "C:\Program Files\Satyr Client", but this can be modified as needed. The Satyr client requires about 4MB of free disk space.

During and after the installation progress, you can monitor the files and drivers that the setup wizard installs.

When the installation process is finished, the Satyr client and the Satyr multiplexer will start automatically.

Finally you need to install the CA Certificate which was used to sign the firewall's certificate. You need to export the certificate in Definite Encoding Rules (DER) format from ZMS (using the Zorp Management Console) and install it under Satyr using addcert.exe, which is distributed with the Satyr Client. Please refer to the PKI chapter of the Zorp Administration Guide for further details.

To create a new partition, select the line indicating the free space of the hard disk and hit Enter, and select the Create a new partition option.

The following parameters of the partition have to be specified:

The exact use of the partition can be configured on the next screen.

After you have finished the configuration select Finish partitioning and write changes to disk from the main partitioning screen.

There is no required partitioning schema for ZorpOS: the number and size of partitions depend on the future role of the machine.

To modify an existing partition, select it from the main partitioning screen. A menu identical to the one discussed in Section 4.9.1, Creating a partition will appear, allowing you to modify the different parameters of the partition.

RAID (Redundant Array of Independent Disks) is a solution of combining multiple hard disks in order to achieve fault tolerance and/or high performance. ZorpOS supports three versions of RAID, RAID 0 (data striping), RAID 1 (mirroring), and RAID 5 (distributed data storage with distributed parity). RAID 0 and 1 require at least two hard disks, while RAID 5 needs at leasts three.

The configuration tree is the placeholder for the configurable components of a Zorp system. Whenever you select an item in the configuration tree, the main workplace changes and shows the configurable parameters of the selected item. The configuration tree is organized hierarchically and this hierarchy maps the management philosophy of Zorp.

The topmost item in the configuration tree is the Site's name that you have entered during ZMS host installation. There are usually one or more items below it: ZMS and/or Zorp hosts.

In the simplest scenario, where ZMS is installed on the Zorp machine there is only one machine listed. Note that in this case the name that appears here is the name of the ZMS host given during installation. Under each host, a varying number of configuration components are listed.

By default two components are available for each host:

Since the ZMS host is a Management server as well, it has a third component for configuring management server parameters.

Each site, host, and component has status icons or leds on its left; these are described in Section 5.3.6, Status indicator icons.

The number of components increases as you start the real work: many services have standalone configuration components that you have to add to the configuration tree to use them.

The forthcoming chapters deal with these components in detail.

Most of the graphical real estate in ZMC is occupied by the main workspace where various components of the component tree are managed. The majority of configuration tasks are performed here. The contents of this pane depends on which component is highlighted (active) in the configuration tree.

The bottom part of the main workspace when a host is highlighted in the configuration tree is the place where new administrative components can be added to the given host.

If you change focus in the configuration tree, the contents of the main workspace change as well.

Although most options of the menu bar are available as buttons on other parts of the ZMC window there are some special menu points that have no corresponding button in the main workspace. The buttons are described in the section which deal with the corresponding ZMC part where they appear.

When you log on to ZMS via ZMC, first an SSL encrypted channel is built, then firewall configurations currently stored in the ZMS database are downloaded into ZMC. When you finish doing configuration changes they are committed back into the ZMS database. At this point no changes are made to the firewall(s); only the database on the ZMS host is modified. It takes a separate action, an upload issued to actually propagate changes from the database down to the firewall(s). With this upload action the configuration changes get integrated into the configuration files on the Zorp machine(s). For final activation, a reload or restart (depending on the situation and the service being modified) is needed to activate the changes.

A complete configuration cycle consists of the following steps.

Most administration commands for the configuration tasks can be issued from either the various menus or by clicking a number of dedicated buttons. These buttons are grouped in a line under the menu bar in the button bar. The number of buttons visible varies based on the component selected in the configuration tree.

Some components are related to or dependent upon each other, meaning that modifying one modifies the other as well. A typical example is the Zorp and Packet Filter component: after modifying a listener, the skeleton of the Packet Filter must be regenerated: its status changes to Invalidated in the configuration tree. ZMC automatically handles related components, all actions (Commit, Reload, etc.); just select the Apply action for the dependent components checkbox in the confirmation dialog of the action.

When reloading or restarting a component related to the Packet Filter, the skeleton of the Packet Filter is automatically regenerated. See Appendix 1, Packet Filtering for details on generating skeletons.

ZMS now records the history of configuration changes into a log file. The logs include who, when modified which component of the Zorp gateway system. Component restarts and other similar activities are also logged, and the administrators can add comments to every action to make auditing easier. By default, ZMC displays a dialog to comment the changes every time the ZMS configuration is modified, or a component is stopped, started, or restarted. The changelogs cannot be modified later.

Every changelog entry includes the following information:

The behavior of the changelog window can be set in the Changelog section after selecting Edit > Preferences: it can be displayed after every action that can be recorded in the changelog (Commit), when the administrator closes ZMC (Quit), or it can be turned off (Never).

To review the existing changelog entries, select Management > Changelogs from the main menu. The appearing View Changelogs window contains two filter bars: one on the top of the window to search for changelog entries, and another one in the middle to use if a single changelog entry contains many actions(see Section 5.3.10, Filtering list entries for details).

Most firewalls are administered by a group of responsible persons and not just by a single, dedicated individual. In a Zorp system each administrator can have an own ZMC console and administrators can be separated geographically. Regardless of their locations they administer the same set of Zorp firewalls via a single ZMS host machine. Therefore, to avoid configuration errors caused by more than one administrator working with the same component simultaneously, a configuration lock mechanism is in place that ensures that a component's configuration can only be modified by a single administrator at a given time instant. Note that locking in ZMC is per component: as soon as for example you change, for example, a setting in a component, the status bar writes Unsaved changes and that component is locked for you. Active locks can be seen at the Locks item of the Management menu:

The Owner column can take two values:

Lock placement is automatic. The first administrator starting modifying a component's settings gets the lock. In the Active locks column the exact name of the locked component (Site/Host/Component) can be seen. Locks are cooperative, meaning any administrator can release any other administrator's locks by highlighting the desired component in the Lock management window and then clicking the Release button. The administrator whose lock is released this way is immediately notified in a warning dialog.

It is not possible to edit a component already locked by someone else because a warning dialog immediately appears upon trying to change anything inside the given component:

As soon as the locking administrator commits the changes the lock is released and the information box above disappears.

A component can be locked by multiple administrators at once; there is a lock queue mechanism implemented in ZMS, meaning administrators can preregister for future locks while the current lock is active. Since there is no hierarchy among Zorp administrators from ZMS's aspect and anyone can release anyone else's locks, it is crucial for administrators to cooperate well and respect each other's work – and each other's locks.

The Configuration tree in ZMC displays various indicators to provide a quick overview about the status of the managed sites, hosts, and components. Site and host-level status is indicated by leds, while icons are used to display component-level status information. Positioning the mouse cursor over a led or icon displays a tooltip with the full description of the status.

ZMC provides two graphical aids that can help administration when parts of a host's configuration settings need to be recreated on another host.

You have two options to refer to components involved in network configurations.

If you use links, you can manually enter IP addresses or select the link target from a drop-down menu. Using links has the advantage that future changes in the network setup does not influence the operability of the connection.

You can delete the existing links with the Unlink and Unlink as value options. If you choose Unlink it ceases the link connection totally, meaning that the link field is left empty while Unlink as value deletes the link but leaves the target IP address in the field which will then behave as a manually added address.

You can refer to components by variables. By using variables you change values appearing in several places at once. If you modify a variable, all corresponding values are changed. Variables are denoted with “$” signs preceding and following their names. For example, $autobind-ip$.

During the management and maintenance of the firewall host it is often useful to be able to temporarily turn off certain rules, policies, etc. In Zorp this feature is implemented via the Disable/Enable options of the local menus. (The local menu of a rule or object can be invoked by right-clicking on the object.) For example, a packet filter rule that is only rarely used can be simply disabled when it is not needed, to be enabled again when it is required. Disabled rules and objects are generated into the configuration file as comments with the # prefix.

Disabled objects can be edited, modified as any other object. However, their validity (e.g.: the required parameters are filled, their name is unique, etc.) is checked only when they become enabled. The following objects can be disabled in the various ZMC components:

Host: Quarantine cleanup rules.

Packet filter : Rules , Groups , Tables , and Chains can be disabled. Disabling a group automatically disables its childrens as well.

Zorp : Instances , Dispatchers , Policies (including matchers).

Networking : Interfaces and Routes can be disabled.

Date and time : NTP time servers can be disabled.

Content vectoring : Routers and rule groups can be disabled.

ZAS: Routers can be disabled.

Heartbeat: Resources can be disabled.

IPSec VPN: Connections can be disabled.

Mail transport : Listen interfaces , Transport maps, Virtual maps, Sender address restrictions, and Recipient address restrictions can be disabled.

ZMC displays information in several places as tables of entries having various parameters or meta-information. Such filter windows are used to display Zorp logs, active connections, etc. The common properties and handling of these tables is summarized in this section.

Filter windows consist of three main parts: a filter bar, a table showing the entries, and a command bar to perform various actions on the selected entries. The actions available in the command bar are described at the documentation of the actual component using the filter window (e.g.: Log viewer).

Each entry of the table consist of a single row, with the various parameters displayed in labeled columns. The entries can be sorted by clicking on the column headers. The order of the columns can be modified by simply dragging the column header to its desired place. The columns to be displayed can be selected from the local menu of the column headers.

The entries can be filtered using the filter bar located above the table. The Filter type combobox specifies the column to search for the expression (string or regular expression) typed into the textbox. Clicking the Filter now icon executes the search command, while Clear restores the full list. Selecting the Advanced option as Filter type opens up a dialog box where custom filter expressions can be created. The filter expressions can also be combined using the logical AND (if all criteria are met) and OR (if any criteria are met) operations. Custom filters can be run once (by clicking Ok), or can be bookmarked for repeated use (Save).

Saved filters are also displayed in the Filter type combobox, and can be managed (deleted, renamed and edited) by clicking the Edit bookmarks button.

In some cases (for example in the Log viewer), advanced filters can be set to highlight the entries matching the filter expression. Just select the Color matching checkbox and set the color of the highlighting.

The command bar offers various operations to display and export the logs of the host. The following operations are available:

The Interfaces tab of the Networking ZMC component lists the network interfaces available on the host, along with their type, IP addresses, and connected zones.

If you change interface settings, restart the modified network interface to activate the changes. Additionally, it may be required to temporarily stop an interface for security or maintenance reasons with the Actions button under the network interface listing.

In case of Zorp hosts there is one special interface in the list: dummy0. This interface is required by the TPROXY kernel module. For more information, see Section 8.8, Proxy classes. The unique IP address of dummy0 is $autobind-ip$ which refers to a system variable (actually to the 1.2.3.4 IP address). For more information on variables, see Section 5.3.8, Links and variables.

In some cases it may be useful to fine-tune the network for special purposes. For example for Virtual Local Area Network (VLAN) technology: many organizations use it for security and network traffic separation purposes. VLANs are logically separated components of physical networks. Logical separation means that although they are on the same physical network (otherwise known as broadcast domain) hosts on separate VLANs cannot communicate with each other unless a router is set up that provides the interconnection. Routing functions for VLAN, and VLAN creation in general, are typically performed by Layer 3 Ethernet switches. Provided that VLAN–capable network cards are installed in the machine, ZorpOS fully supports VLANs and ZMS provides a control for configuring it.

VLAN interfaces are named in the following manner:

ethx.n where

Using alias interfaces allows you to configure multiple IP addresses to a physical device. Alias interfaces are named in the following manner:

ethx:n where

An alias can be defined for existing physical and VLAN interfaces.

Spoof protection means that the packet filter module of a firewall checks to ensure that packets arriving on an interface have source IP addresses that are legal in networks reachable via that given interface and accepts only those packages that match this criterion.

For example, if eth0 connects to the Intranet(10.0.0./8) and it is spoof protected, the firewall does not accept datagrams on this interface with source IP addresses other than the 10.0.0.0/8 range. It does not accept datagrams with source IP address from the 10.0.0.0/8 range on interfaces other than eth0 either.

For further details on zones, see Section 8.4, Zones. For more information on Spoof control in relation with packet filter rules, see section Section 1.4.3.3, Spoof protection.

The bottom part of the Interfaces tab can be used to specify activation scripts, and various other parameters of the network interfaces. The following options can be set:

The state of the configured interfaces is indicated by leds of different colors before the name of the interface (Green — Up, Red — Down, Blue — Unknown). The state of the interface is automatically updated periodically; its frequency can be set in the Program status refresh section of the General tab under the Edit / Preferences menu. Status update can also requested manually from the local menu of the interface (right click and select Refresh state). Hovering the mouse over an interface displays a tooltip with status information and detailed statistics about the interface. The following status information is displayed:

The statistics about the traffic handled by the interface is divided into Received and Sent sections, relevant for the received/sent packets, respectively.

A route has the following parameters:

The above parameters are interpreted the following way: messages sent to the Address/Netmask network should be delivered via Gateway using Interface.

New entries into the routing table can be added by clicking the New button of the control bar; existing entries can be modified by clicking Edit. The updated routing tables take effect only after the new configuration is uploaded to the host, and the routing tables are reloaded using the Actions/Reload buttons of the control bar.

The list of routing table entries can be sorted by all of its parameters (network, gateway, etc.) by clicking on the header of respective column. By default, the list is displayed according to the general listing policy of the routing tables, i.e. the networks connecting via a gateway are listed after the directly connected networks.

The list can be filtered using the filter bar above the list. Type the search pattern into the textbox, specify the elements to be searched using the combobox on the left, and click Filter. The list will only display the routes matching the search criteria. Click Clear to return to the full list.

Routes can be temporarily disabled by right-clicking the selected route and selecting Disable from the appearing local menu.

When the Zorp host is administered via a terminal, the routes have to be entered manually by editing the /etc/network/static-routes configuration file. Each line of this file corresponds to a route, and has the following format:

interface_name to address/netmask via gateway metric [metric]

For the modifications to take effect, the routing tables have to be reloaded by issuing the /usr/lib/zms-transfer-agent/zms-routing params="reload" command.