The heart of the PNS–based firewall solution is the firewalling software itself, which is a set of proxy modules acting as application layer gateways. PNS is an application proxy firewall. For details on the architecture of PNS itself, see Section 2.2, The concepts and architecture of PNS firewalls.

PNS must be installed on an Ubuntu-based operating system (Ubuntu 18.04 LTS) which installs automatically when booting from the PNS installation media.

The Management Server (MS) handles the configuration tasks of the entire solution. Your firewall administrators use the Management Console (MC) application on their desktop to access MS and modify the configuration of your firewalls. MS is the central command center of the solution: it stores and manages the configuration of PNS firewall hosts.

The real power of MS surfaces when more than one PNS firewalls have to be administered: instead of configuring the different firewalls individually and manually, you can configure them at a central location with MS, and upload the configuration changes to the firewalls. Because MS stores the configuration of every firewall, you can backup the configuration of your entire firewall system. In case of an emergency, you can restore the configuration of every firewall with a few clicks.

Technically, MS does not communicate directly with the PNS host: all communication is done through the PNS Transfer Agent application, which is responsible for transporting configuration files to the managed hosts, running MS-initiated commands, and reporting the firewall configuration and other related information to MS. The PNS Transfer Agent is automatically installed on every PNS host. The communication is secured using Secure Socket Layer (SSL) encryption. The communicating hosts authenticate each other using certificates. For more information, see Section 13.1.1.5, Configuring authentication settings.

Communication between the agents and MS uses TCP port 1311. If PNS and MS is installed on the same host, communication between the transfer agent and the MS server uses UNIX domain sockets.

By default, the MS host initiates the communication channel to the agents, but the agents can also be configured to start the communication, if required.

The Management Console (MC) is the graphical interface to Management Server (MS). A single MS engine can manage several different PNS firewalls. MC is designed so that almost all administration tasks of PNS can be accomplished with it and therefore no advanced Linux skills are required to manage the firewall.

Figure 2.2. Communication between MC, MS, and PNS

MC can be installed on the following platforms:

PNS can authenticate every connection: it is a single sign-on (SSO) authentication point for network connections. During authentication, PNS communicates with the Authentication Agent (AA) application that runs on the client computers.

However, PNS does not have database access for authentication information such as usernames, passwords and access rights. It operates indirectly with the help of authentication backends through an authentication middleware, the Authentication Server (AS). To authenticate a connection, PNS connects to AS, and AS retrieves the necessary information from a user database. AS notifies PNS about the results of the authentication, together with some additional data about the user that can be used for authorization.

Figure 2.3. The operation of AS

AS supports the following user database backends:

AS supports the following authentication methods:

CF is not a content vectoring engine, it is a framework to manage and configure various third-party content vectoring modules (engines) from a uniform interface. PNS uses these modules to filter the traffic. These modules run independently from PNS. They do not even have to run on the same machines. PNS can send the data to be inspected to these modules, along with configuration parameters appropriate for the scenario. For example, a virus filtering module can be used to inspect all files in the traffic, but different parameters can be used to inspect files in HTTP downloads and e-mail attachments. Also, different scenarios can use a different set of modules for inspecting the traffic. Using the above example, HTTP traffic could be inspected with a virus filter, a content filter, and all client-side scripts could be removed. E-mails could be scanned for viruses using the same virus filtering module (but possibly with stricter settings), and also inspected by a spam filtering module.

Figure 2.4. Interaction of PNS and CF

The examples demonstrated on Figure 2.5, Content vectoring scenarios in CF can be translated to the CF terms defined in the previous paragraph as follows:

Figure 2.5. Content vectoring scenarios in CF

This is only a basic example, further router rules could be used to optimize the decisions (for example, there is not much sense in trying to remove client-side scripts in non-HTML files that are downloaded, and so on). Similarly, another rule group corresponds to the SMTP scenario, with a scanpath including a virus filtering and a spam filtering module instance.

The whole process is summarized in the following procedure.

PNS uses strongSwan to support native Linux IPSec solutions, and also supports OpenVPN (an SSL-based VPN solution). PNS supports both transport and tunnel mode VPN channels. Tunnel authentication is possible with X.509 certificates and with pre-shared keys (PSK). IPSec settings can be negotiated manually, or using Internet Key Exchange (IKE).

Figure 2.6. Virtual Private Networks

Native services provide a limited number of server-like features in PNS. Their use is optional and depends on the needs and security requirements of your 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.

These services are called native because they are installed with PNS and are available by default. They are implementations of the actual Linux services of the same names. These services provide networking services that are either difficult to implement with application proxies (or at the packet filter level) or provide services for the firewall itself. For more information on these services, see Chapter 9, Native services.

PNS supports multi-node (2+) failover clustering, as well as load balance clusters (most load balance configurations use external devices). Clustering support must be licensed separately. PNS supports the following failover methods:

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

PNS runs on Ubuntu-based operating systems. Currently it supports Ubuntu 18.04 LTS. You can either install the PNS packages on an existing Ubuntu server installation from the official APT repositories, or use our installation media to install a minimal Ubuntu 18.04 LTS server and the PNS packages.

A firewall controls which networks and hosts can be accessed, and who can access them. To create traffic rules, first you must accurately define the networking environment of PNS, then you can apply access control on the traffic. This can be achieved using zones and rules.

Zones consist of one or more IP subnets that PNS handles together. By default, there is only a single zone: the IP network 0.0.0.0/0, which practically means every available IP addresses (that is, the entire Internet). You can organize zones into a hierarchy to reflect your network, or the structure of your organization.

Although zones consist of IP subnets and/or individual IP addresses, zone organization is independent of the subnetting practices of your organization. For example, you 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. For details on zones, see Section 6.2, Zones.

The first line of network defense is a packet filter that blocks traffic based on the IP address or TCP/UDP port number of the source (that is, the client) or the destination (that is, the server) of the connection. That way, more thorough analysis, such as traffic inspection or content vectoring is performed only on traffic that is permitted at all. This technology using both packet filtering and application proxying together is called multilayer filtering.

In PNS, packet filtering is handled by the kzorp kernel module, therefore packet filtering services are completely handled on the kernel level. When PNS starts, it sends all information about the traffic permitted to pass the gateway (that is, the list of configured services, zones, firewall rules, and so on) to the kzorp module.

Application-level services (also called proxy services) are handled on two levels:

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 MC.

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

PNS is a proxy gateway. It separates the connection between the client and the server into two separate connections: one between the client and PNS, and another between PNS and the server. PNS receives the incoming client connection requests, inspects them, and transfers them to the server. PNS also receives the replies of the server, inspects them, and replies to the client instead of the server. That way PNS has access to the entire network communication between the client and the server, and can enforce protocol standards and the security policy of your organization (for example, permit only specific clients to access the server, or enforce the use of strong encryption algorithms in the connection).

Proxying can take two basic forms:

The traffic in a connection usually consists of two parts:

The protocol proxies of PNS analyze and filter the control part of the traffic, but — in most cases — ignore the payload. (The antivirus and spam-filtering modules of CF inspect the payload.) PNS proxies can thoroughly inspect the protocol headers to ensure compliance to the protocol, disable the use of prohibited options, and so on. PNS can handle commonly used protocols, including:

Every protocol proxy can handle the SSL/TLS encrypted version of the protocol, and inspect the embedded traffic, giving control over HTTPS, SMTPS, and other connections.

For more information on supported protocols and for a complete list of proxies, see Proxedo Network Security Suite 1.0 Reference Guide.

The default settings of the protocol proxies of PNS ensure that the traffic complies to the relevant RFC for the given protocol. To provide flexibility, and to solve a wide variety of custom scenarios, you can customize the proxies and change their parameters to best suit your environment and your security requirements. For example, you can:

In addition, the proxies in PNS are fully scriptable, and can be programmed in Python to perform any custom functionality. For information on customizing proxies, see Section 6.6.1, Customizing proxies, and Proxedo Network Security Suite 1.0 Reference Guide.

Today, network traffic often uses more than a single protocol: it embeds another protocol into a transport protocol. For example, HTTPS is HTTP protocol embedded into the Secure Socket Layer (SSL) protocol. SSL encrypts HTTP traffic and many firewalls simply permit encrypted traffic pass without thorough inspection. This is not an optimal solution from a security aspect, and PNS has a better solution to this problem: it decrypts and inspects the SSL traffic, and passes the data stream to an HTTP proxy to inspect it. 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 traffic, for example, to perform virus filtering in HTTPS, or spam filtering in POP3S traffic.

The configuration tree lists the configurable components of a PNS system. Whenever you select an item in the configuration tree, the main workplace displays the configurable parameters of the selected item. The configuration tree is organized hierarchically and this hierarchy maps the management philosophy of PNS.

Figure 3.5. Configuration tree in MC

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

In the most basic scenario, where MS is installed on the PNS machine, there is only one machine listed. Note that in this case the name that appears here is the name of the MS host entered during installation. Under each host, a varying number of configuration components are listed.

By default two components are available for each host:

Because the MS_Host in this example is a Management server too, 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 detail in Section 3.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.

3.2.1.2. Host

A Site is composed of one or more Hosts. Hosts can be the following items:

• PNS firewalls,

• CF hosts,

• AS hosts, and

• MS-managed hosts.

At the very minimum setup, when PNS and MS are installed on the same machine, there is one Host registered for the given Site. The number of PNS firewall nodes per Site is only limited by the number of licenses purchased. With the exception of Zone and PKI settings, configuration parameters are always per Host.

To display system statistics for a Host component (MS or PNS), click on the name of the Host. The statistics are displayed under the Host tab. The following statistics are available:

• Processor

• Load average

• Uptime

• Memory usage: RAMand SWAP

• Only on PNS hosts:

  • The version number of PNS

  • The number and status of running PNS Instances, Processes and Threads

• The validity and size of the product licenses (PNS, MS, and so on) available on the host. MC displays a warning if a license expires soon, and an alert e-mail can be configured as well. For details on configuring e-mail alerts for license expiry, see Procedure 11.3.8.8, Monitoring licenses and certificates.

  Note
  To access license information from the command line, login to the host and enter: /usr/lib/zms-transfer-agent/zms_program_status hoststat

Figure 3.6. Host statistics

The statistics are automatically refreshed every 30 seconds by default.

Tip
Although host statistics can seem a less important, auxiliary service, it is extremely useful when firewalls operate under continuous heavy load and you want to optimize resource allocation.

Most of MC is occupied by the main workspace where you can manage the various components of the Configuration tree. The majority of configuration tasks are performed here. The contents of this pane depends on which component you select in the configuration tree.

You can add new administratice components to the host at the bottom part of the main workspace.

If you select a different Host in the Configuration tree, the contents of the main workspace change too.

Although most options of the menu bar are available as buttons on other parts of the MC 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 MC part where they appear.

3.2.3.7. Status bar

The bottom line of MC is called the status bar. When working with configuration components it can be used to check whether changes have already been Committed or there are Unsaved changes. By checking the status, you can determine whether what you see on the MC interface is the same as the information currently stored in the MS configuration database (committed status) or not.

Figure 3.12. The Status bar

When you login to MS through MC, first an SSL encrypted channel is built, then firewall configurations currently stored in the MS database are downloaded into MC. When you finish doing configuration changes they are committed back into the MS database. At this point no changes are made to the firewall(s); only the database on the MS 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 PNS 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 menus or the buttons in the Button bar. The number of buttons visible varies based on the component that you have selected in the Configuration tree.

Figure 3.13. The Button bar

3.3.2.1. Commit and Revert

The Commit changes and Revert changes buttons are always visible, at the minimum.

Commit is used when you finish a (set of) configuration changes and want zo save these changes to the XML database of MS.

Revert serves the opposite purpose: before committing changes to the MS database, it is possible to clear, to undo them in MC.

Note
It is very important to remember that Revert is limited to MC, it cannot clear configuration changes that are already committed to the MS database. Those changes can be undone by performing a new round of changes in MC and then committing these changes again.

Both Commit and Revert are component–focused controls. This means that before you select another component from the Configuration tree, you must commit the changes in the current component, otherwise they are lost. In such cases, MC displays the following warning:

Figure 3.14. Warning: commit changes before leaving the component

3.3.2.3. Control service

Under Control service, you can Reload or Restart services so that they re-read the new configuration files that are already on the corresponding PNS firewalls after a successful Commit / Upload cycle.

Restarting or Reloading the given service depends on the type of service (some cannot be reloaded, only restarted) and the intended outcome.

After clicking Control service, the following actions are available:

Figure 3.15. The service control dialog

Note
Besides Restart and Reload, there are also Start and Stop functions available here to start or stop services.

3.3.2.4. View and Check current configuration

View current configuration and Check current configuration are both used to retrieve information on the current state of the PNS firewall(s).

View current configuration displays the configurations of the component selected in the Configuration tree on the selected host. This information comes from the MS configuration database, which is not necessarily the same as the actual settings on the selected host – when changes are already committed, but not yet uploaded. For example, if you select the MS_Host > Networking component and then click View current configuration, you will see the following:

Figure 3.16. Networking configuration on MS_Host

It is a file-by-file listing of the active configuration on the selected host. Note that it is not necessarily the same configuration that is stored in the MS database: after a commit but prior to an upload event they can differ significantly. To query this difference, click Check current configuration. Using the Linux diff utility by default, it compares configurations stored in the MS database with the configurations currently active on the selected host.

Figure 3.17. Checking current configurations

The differences are marked in red, otherwise you see the normal output of diff, with + and – signs designating data from the host and from the database, respectively. The diff command can be replaced with another utility of your choice under the Management Server component. For details, see Chapter 13, Advanced MS and Agent configuration.

3.3.2.5. Files

Configuration files: 

Files provides further information and configuration options of the files and attributes described in the output window of Check current configuration and the diff command.

Files serves two purposes.: It provides vital information about which configuration files a component (of the Configuration tree) uses and gives chance to modify the properties of the listed files.

For example, in case of the Networking component, the list of used files is the following.

Figure 3.18. Files used by the Networking component

Apart from the name and location of files, you can retrieve information about owner, owner group, access rights and file type parameters. The Manage column is very important and has a corresponding checkbox immediately below the file listing: this can be used to control what files MS manipulates on the host machine, if needed.

Note
It is not recommended to take files out of the authority of MS, because it can severely limit the effectiveness of MS–based administration. However, it is possible to do it, if you deselect the checkbox under the Manage column.

File settings: 

To modify the properties of a file, click on the file in the list. The following subwindow opens.

Figure 3.19. Changing file properties

Warning
There must be a solid reason for changing these properties and you must be prepared for the possible consequences of such actions. A good understanding of Linux is recommended before making changes in file properties.

Consider different if these properties change: 

The third part of the window is for configuring the work of the comparison utility, which is diff by default. You can define what file properties you are interested in when checking for changes.

Figure 3.20. Configuring diff conditions

Tip
Checking for configuration file differences is beneficial from a security aspect too: it is an additional tool for making sure nobody has altered critical files on the firewall.

Postprocess script: 

At the bottom of the Configuration tab, you can specify a postprocess command that is run after the corresponding configuration file is uploaded to the firewall host. Some services rely heavily on this option. For example, Postfix that runs / usr/sbin/postmap %f as a postprocess command to transport virtual domains and set various access restrictions are properly.

Scripts tab: 

Configuration files under Linux are re-read during service reloads or restarts. These actions are performed by running the corresponding scripts exclusively from the /etc/init.d directory. The Scripts tab of the Files window provides an interface where you can check starting scripts and alter and fine-tune them with special Pre upload and Post upload commands. With simple components, such as Networking, these options are rarely used, but in some cases might prove especially useful.

Some components, for example, Text Editor, can manage configuration files that are automatically reloaded. They cannot be restarted after a Commit. To set the status icon of these components to Running, selectConfiguration automatically runs on the Scripts tab.

Some components are related to or dependent upon each other, meaning that modifying one modifies the other too. If modifying a component affects another component, the status of this related component changes to Invalidated in the Configuration tree. MC automatically handles related components and all actions (Commit, Reload, and so on). 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 A, Packet Filtering for details on generating skeletons.

Most firewalls are administered by a group of administrators and not just by a single individual. In a PNS system each administrator can have their own MC console and administrators can be separated geographically. Regardless of their locations they administer the same set of PNS firewalls through a single MS host machine. Therefore, to avoid configuration errors caused by more than one administrator working with the same component simultaneously, a configuration lock mechanism ensures that a component's configuration can only be modified by a single administrator at a given time. Locking is per component: as soon as you change, for example, a setting in a component, the status bar displays the following string: Unsaved changes and that component is locked for you. Active locks can be viewed at Management > Locks:

Figure 3.21. Management > Locks - Viewing active locks

The Owner column can take two values:

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

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

Figure 3.22. Question on a locked 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 MS, meaning administrators can preregister for future locks while the current lock is active. Since there is no hierarchy among PNS administrators from MS'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 MC 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.

Figure 3.23. Status indicator icons and leds

Hovering the mouse cursor over a led or icon displays a tooltip with the full description of the status.

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

Figure 3.24. Selecting multiple components in the Configuration tree

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.

You can refer to components with 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 $ characters preceding and following their names.

$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, and so on. In PNS this feature is implemented through the Disable/Enable options of the local menus. To display the local menu of a rule or object, right-clicking on the object. For example, a packet filter rule that is only rarely used can be simply disabled when it is not required, 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 similarly to any other object. However, their validity (for example, the required parameters are filled, their name is unique, and so on) is checked only when they are enabled again.

The following objects can be disabled in the various MC components:

Host:

Packet filter:

Disabling a group automatically disables its childrens as well.

Application-level Gateway:

Networking:

Date and time:

Content vectoring:

AS:

Heartbeat:

IPSec VPN:

Mail transport:

MC displays information in several places as tables of entries having various parameters or meta-information. Such filter windows are used to display firewall rules, Application-level Gateway logs, active connections, and so on. The common properties and handling of these tables is summarized in this section.

Figure 3.25. A filter window

Filter windows consist of three main parts:

The actions available in the command bar are described at the documentation of the actual component using the filter window (for example, Log viewer).

Each entry of the table consist of a single row, with the various parameters displayed in labeled columns.

To filter the entries, use the filter bar located above the table. The Filter type specifies the column to search for the expression (string or regular expression) that you type in the field. To search, click Filter now. To restore the full list, click Clear. To create custom filter expressions, selecting the Advanced option as Filter type. The filter expressions can also be combined using the logical AND (if all criteria are met) and OR (if any criteria are met) operations. You can run custom filters once (click Ok), or you can bookmark them for repeated use (click Save).

Figure 3.26. Advanced filtering

Saved filters are also displayed in the Filter type combobox. To manage saved filters (delete, rename and edit), click Edit bookmarks.

Figure 3.27. Editing bookmarks

In some cases (for example, in the Log viewer), you can configure advanced filters to highlight the entries matching the filter expression. To configure highlighting, select Color matching 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 MC component lists the network interfaces available on the host, along with their type, IP addresses, and connected zones.

Figure 5.2. Network interface configuration

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

Rule(proto=6,
    dst_iface='eth0',
    service='test'
    )

Rule(proto=6,
    dst_iface='dyn',
    service='test'
    )

In some cases it can 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, PNS fully supports VLANs and MS provides a control for configuring it.

VLAN interfaces are named in the following manner:

ethx.n where

Figure 5.5. Configuring VLAN and alias interfaces

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 through 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 6.2, Zones. For more information on Spoof control in relation with packet filter rules, see Section A.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 configured:

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. The update frequency can be configured in Edit > Preferences > General > Program status. Status update can also be requested manually from the local menu of the interface. To do this, select the interface, right-click on it 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 through 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.

Figure 5.16. Adding new routing entries

The list of routing table entries can be sorted by all of its parameters (network, gateway, and so on) by clicking on the header of respective column. By default, the list is displayed according to the general listing policy of the routing tables, that is, 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.

Figure 5.17. The Filter bar

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

When the PNS 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 through 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.

By default, MC defines a zone called internet on every site. The internetcontains the the 0.0.0.0 and the ::0 networks with the 0 subnet mask. This zone means any network: every IP address not belonging to another zone belongs to the internet zone.

Figure 6.1. Zones

The internet zone is typically used in firewall rules where one side of the connection cannot be defined more exactly.

Zones are managed on the Site component in MC. The left side of the main workspace displays the zones defined on the site and their descriptions. IP networks that belong to the selected zone are displayed on the right side of the workspace.

Use the control buttons to create, delete, or edit the zone definitions and the IP networks. Use the arrow icons to organize the zones into a hierarchy (see Section 6.2.3, Zone hierarchies for details).

Zones can be organized into a tree, much like the directories of a file system. Define a topmost zone and with many subzones, each for administratively different parts of your networks. A zone and its subzone have parent-child relationship: child zones automatically inherit all properties and settings of their parents. For example, Zone A is the parent zone of Zone B, and all clients in Zone A may browse the web through HTTP. Zone B inherits this setting, so all clients of Zone B have unrestricted HTTP access.

To stop a zone from inheriting the properties of the parent zone, use a DenyService. For details on DenyServices, see Procedure 6.4.3, Creating a new DenyService.

Zones can be reorganized as needed.

Figure 6.5. Zones, inheritance, and DenyServices

To remove a child zone from the hierarchy, select the zone and click the left arrow.

Starting with PNS 5.0, you can directly use hostnames in zones. During startup, PNS automatically resolves these hostnames to /32 IP addresses, and updates them periodically to follow any changes in the IP addresses related to the hostname. When using hostnames in zones, note the following points and warnings:

To find a zone or a subnet, select the site in the configuration tree and click the Find button.

Figure 6.8. Finding zones and subnets

You can search for the name of the zone, or for the IP network it contains. When searching for IP networks, the only the most specific zone containing the searched IP is returned. If an IP address belongs to two different zones, the straitest match returns the most specific zone.

Instances of Application-level Gateway are groups of services that can be controlled together. A PNS firewall can run multiple instances of the Application-level Gateway process. The main benefits of multiple firewall instances are the following:

Instances usually handle traffic based on the protocol used by the traffic, the direction of the traffic, or a special characteristic of the traffic (for example, requires authentication). It is common practice to define an instance for all inbound traffic that handles all services accessible from the Internet, and another one for all traffic that the clients of intranet are allowed to use. Consider creating a separate instance for:

To manage Application-level Gateway instances, navigate to the Instances tab of the Application-level Gateway MC component.

Figure 6.9. Managing instances

The following information is displayed for each instance:

Hovering the mouse over an instance displays a tooltip with detailed information, including the number of processes running in the instance, as well as the number of running threads for each process.

Use the button bar below the instances table to manage and configure the instances.

To modify instance parameters, select Application-level Gateway > Instance > Edit parameters. The General tab has the following parameters:

Figure 6.12. General instance parameters

Instance parameters can be set on the tabs of the Edit Instance Parameters window. The Logging tab has the following parameters:

Figure 6.13. Instance parameters — logging

Instance parameters can be set on the tabs of the Edit Instance Parameters window. The Rights tab has the following parameters:

Figure 6.14. Instance parameters — rights

Instance parameters can be set on the tabs of the Edit Instance Parameters window. The Miscellaneous tab has the following parameters:

Figure 6.15. Instance parameters — miscellaneous