Figure 4.4. The global level of the initial configuration file

The global level of the initial configuration file is depicted in Figure 4.4, “The global level of the initial configuration file”. It begins with three standard include files^[18]. The first file, samples/include/products.cml, defines variables usable as the system.product item. See Section 3, “Licensing” for more information about Kernun product specification in the configuration. The second file, samples/include/crontab.cml, defines variables usable as the contents of the system.crontab and system.periodic-conf sections. The third file, samples/include/root-servers.cml, contains a list of root DNS servers. Then, several shared-dir and shared-file sections specify files that are copied from the configuration directory to their target locations when the configuration is applied. The configuration can be edited on one Kernun UTM and then applied remotely to another. In this case, the shared files and directories are copied from the system where the configuration is edited to the system where it is applied.

The rest of the sample configuration is the system fw section. It defines a single Kernun UTM system. The configuration of a standalone Kernun UTM usually contains only one system section. If several alternative configurations are used or several systems are configured from one place (e.g., in high-availability clusters), more than one system sections can be defined.

Figure 4.5. Various system-level definitions

First, the type of the Kernun product is specified (Figure 4.5, “Various system-level definitions”) using one of standard product variables from samples/include/products.cml. The product specification controls which components can be configured. During the application of the configuration, a check is made that the product installed on the target system matches the specification. See also Section 3, “Licensing” for a more detailed explanation of the product specification in the configuration. The system parameters start with host and domain names. The configuration of actions executed periodically by the cron (8) daemon and by the periodic (8) command is defined in the sections crontab and periodic-conf. These sections are filled in by the application of variables defined in crontab.cml.

Figure 4.6. Definitions of network interfaces

The following part of the system section, displayed in Figure 4.6, “Definitions of network interfaces”, contains the settings of two network interfaces, connected to the internal (INT) and external (EXT) network, respectively. Two values are specified for each interface: the name of the network interface device as used by the operating system (item dev), and the IP address with the network mask (item ipv4). Note that interface is a repeatable section, so it can occur more than twice. For example, a demilitarized zone network can be connected via a third interface in a more complex network topology.

Figure 4.7. Definitions of various network parameters

The system section then defines further network-related parameters, see Figure 4.7, “Definitions of various network parameters”. Domain name resolution parameters are set in the section resolver. In the initial configuration, the only item in this section selects a DNS server. There may be several resolver sections. The section that is used globally for resolutions performed by Kernun UTM components is chosen by use-resolver. Each proxy can use the global resolver, or the resolver setting can be overridden for the proxy using a use-resolver section local to the proxy configuration section. In the initial configuration, the global resolver is shared by all proxies. Note that the resolver is used for address resolution performed by Kernun UTM itself. If clients in the internal network should have access to the DNS, which is usually the case, either a DNS server can be configured in the internal network, or the clients can resolve via a Kernun UTM dns-proxy.

The routes subsection defines static routes. In the sample configuration, only the default route to a router in the external network is specified. The use-services item selects a shared-file^[19] that will be copied into /etc/services. It defines port numbers assigned to various network services. The last network-related parameter is a list of root DNS servers, section ns-list. It is set by the application of the section variable ROOT-SERVERS defined in the included file root-servers.cml.

Figure 4.8. An SSH server for administrative access

Kernun UTM is usually administered remotely via the network. The administrator connects to Kernun UTM using SSH, either directly in order to obtain a shell command line, or via the GUI, which uses SSH internally. Therefore, an SSH server for administrator's access should be defined in the configuration. The initial configuration contains a single SSH server section called ssh-server SSHD, see Figure 4.8, “An SSH server for administrative access”. It listens on the standard SSH port 22 on the internal network interface only. Hence the administrator can connect to the Kernun UTM from the internal network only. If access from the external network is desired, the SSH server must be reconfigured to listen on the external interface as well.

The server allows password-based authentication of non-root users. It is used for the initial download of the root's SSH key using the special keygen account, as described in Section 5.2, “Initial Configuration”. The root can log in to Kernun UTM with the SSH keys listed in section ssh-keys. By default, this section contains the key generated by the initial configuration process and accessible via the keygen account.

Figure 4.9. The server for handling locally-originated mail

Kernun UTM generates some e-mail messages locally, mainly as the output of periodic actions executed by cron (8). These messages are delivered to the address provided in the admin item by the mail server configured in the local-mailer section, see Figure 4.9, “The server for handling locally-originated mail”. The default local mailer configuration refers to the standard file master.cf selected by a global shared-file parameter.

The server that handles local mail is Postfix-configured so that it does not listen for any incoming network connections. It handles only mail sent by the mail (1) command. The administrator's e-mail address is set as an alias for the root user in /etc/aliases.

Kernun UTM utilizes both the packet filter and application proxy firewalling technologies. The use of application proxies is preferred, because it provides a higher level of security and finer control of the network traffic. The network traffic is therefore passed through Kernun UTM mainly via proxies that handle individual application protocols.

Figure 4.10. Hidden proxies and a global ACL

It is possible to enable proxies for several frequently used network protocols in the initial configuration. However, in order to maintain better control over the network traffic it is advisable not to enable any proxy when the initial configuration script creates the configuration of a newly installed Kernun UTM, but rather to selectively enable and configure the proxies later, when the administrator connects to Kernun UTM via the GUI. The part of the configuration that is directly related to proxies is shown in Figure 4.10, “Hidden proxies and a global ACL”. Note that all proxy sections are hidden, so that proxy parameters are defined, but have no effect and the hidden proxies are not started^[20].

Proxies can be non-transparent or transparent, see Section 7, “Networking in Proxies” for more details. By default, all proxies in the initial configuration except dns-proxy are configured as transparent, which enables the use of clients in the internal network without any reconfiguration.

Access control in proxies is driven by access control lists (ACLs). Each proxy has one or more layers (phases) of ACLs. Individual phases are consulted at specific moments during the processing of the network communication.

For example, in http-proxy, there are three phases of ACLs: the session-acl sections are consulted when a new connection from a client is accepted. They make early decisions based on values, such as the client's IP address. The second phase, request-acl, is checked after the HTTP request is received from the client. Its actions can depend e.g. on the request URI or on the values of some request headers. The third phase, doc-acl, is applied when the HTTP reply headers are received. On the other hand, tcp-proxy, which handles only the TCP data stream without deeper understanding, has a single ACL phase, session-acl.

The ACLs that belong to one phase are tested sequentially. The input conditions of every ACL section are evaluated and the first ACL, for which all the conditions are true, is selected. The chosen ACL can accept or deny the session, thus effectively allowing it to continue or terminating it. Various parameters that affect further handling of the session by the proxy can be set by the ACL. If no matching ACL is found, the session is terminated.

ACLs can be located at two different places in the configuration. Global ACLs defined in the system section belong to the first phase (session-acl). Each global ACL has a service item containing the list of proxies, to which it is applicable. The initial configuration contains one global acl INTOK that applies to all proxies and accepts sessions originated from clients in the internal network, as can be seen in Figure 4.10, “Hidden proxies and a global ACL”. Note that sessions initiated by clients in the external network do not match the from condition of acl INTOK and there is no other ACL that could match, hence these sessions are denied^[21]. Local ACLs are defined in the configuration sections of individual proxies. Each such ACL applies only to the proxy, in which it is defined. Phase one (session-acl) ACLs in a proxy are merged with the global ACLs that have this proxy in their service lists. For each session-acl in a proxy there must be a global ACL with the same name.

Figure 4.11. DNS Proxy

In a typical scenario, the DNS proxy provides the domain name resolution service for clients behind Kernun UTM. It is defined by its particular dns-proxy section which resides in the system section. In this example, the listen-on section specifies that the DNS proxy will listen non-transparently on the internal interface on port 53. This means that clients from the internal network must set the IP address of Kernun UTM's internal interface as their DNS server in order to use this proxy. The chroot-dir item specifies that the process will be chrooted to the directory /usr/local/kernun/root, see chroot(8).

The requests-table-size and sockets-table-size items are obligatory for dns-proxy. Every domain name resolution request is stored in a table that contains all the necessary information. The size of this table is specified by the requests-table-size item. It is recommended to reserve slightly more items than the estimated number of parallel requests. Besides the number of requests, the number of simultaneously opened sockets is monitored as well. This maximum must be specified by the sockets-table-size item. See dns-proxy(5) for details.

dns-proxy needs at least one request-acl section providing details on what traffic is permitted or not, and the way it should be dealt with. In this example, the accept item specifies that request-acl RESOLVE describes an accepting request-acl. This means that this section defines the positive case — the conditions, under which the request is accepted. Then query * resolve ROOT-SERVERS directs the proxy to use the ROOT-SERVERS to resolve all the requests. Further on, it is defined that all the respective replies from the ROOT-SERVERS are permitted to be returned to the clients.

The ROOT-SERVERS item is defined in the sample file samples/include/root-servers.cml, which is included in the configuration using the include keyword. This file contains the definition of the $ROOT-SERVERS variable, which defines the ns-list section — a list of DNS root servers. In order to apply that definition, it is necessary to include the $ROOT-SERVERS keyword in the configuration.

Finally, dns-proxy must be referenced by at least one system ACL. In this example, the access to the DNS proxy is granted for all clients from the internal network.

Figure 4.12. HTTP Proxy

http-proxy is the proxy daemon for HyperText Transfer Protocol (RFCs 1945, 2616). It supports version 0.9, 1.0 and 1.1 HTTP clients and version 1.0 and 1.1 HTTP servers. The proxy also supports secure communication via the SSL/TLS protocols.

In the example depicted in Figure 4.12, “HTTP Proxy”, http-proxy is configured to listen on the internal network interface on port 80 in the transparent mode, and on port 3128 in the non-transparent mode; see Section 2.5, “Application Proxies and ACLs” for details about transparency. Again, the proxy is configured by chroot-dir to be chrooted into /usr/local/kernun/root/, see chroot(8).

The document-root item defines the root directory of the error document set. In this example, it refers to DOCROOT — the shared-dir section defined at system is a list of path items designating directories for further use. Note that the relative path (i.e., one that does not start with “/”) is in fact relative to /usr/local/kernun/conf.

http-proxy uses three-phase ACLs.

In this simple example, http-proxy is configured not to use authentication (auth none). You might have noticed that we did not specify the accept item in session-acl INTOK, nor did we restrict the IP range of clients that can use http-proxy. The reason is that we only specify the acl section INTOK that we defined earlier. In fact, FIREWALL.HTTP.INTOK is a local copy of FIREWALL.INTOK, and we have particularized this local copy. Finally, request-acl and doc-acl are configured to accept any request or document, respectively. However, CONNECT method requests are limited to port 443 to allow SSL/TLS connections only.

See dns-proxy(5) for details.

Figure 4.13. FTP proxy

ftp-proxy provides the proxy service for File Transfer Protocol (RFC 959) and its extensions. For crucial commands, it behaves like a server for the client and vice versa, with full syntax and semantics verification. Commands that have no impact on the session state are only recognized and simply forwarded to server.

The simple configuration of ftp-proxy is quite similar to the simple configuration of http-proxy (see Section 2.7, “HTTP Proxy”). In the example at Figure 4.13, “FTP proxy”, it is configured to listen on the internal network interface on port 21 in the transparent mode and chrooted into /usr/local/kernun/root/ (see chroot(8)). No restrictions are configured, so everyone (from the internal network — as specified in the INTOK acl) is allowed to use the ftp-proxy. As usual, the ftp-proxy FTP must be present in some ACL; in this case, it is referenced in the service list in the INTOK definition.

ftp-proxy uses three-phase ACLs.

For more information about ftp-proxy, see ftp-proxy(8) and ftp-proxy(5).

Figure 4.14. Proxies HTTPS and SSH

Both HTTPS and SSH protocols are handled by the generic tcp-proxy, because they use encrypted communication and Kernun UTM therefore cannot understand the protocol data. The configurations of tcp-proxy HTTPS and tcp-proxy SSH are almost identical, see Figure 4.14, “Proxies HTTPS and SSH”. They differ only by the port they listen on—the port number is 443 for HTTPS and 22 for SSH.

Both proxies listen for clients connecting transparently via the internal interface of Kernun UTM (section listen-on). The proxies run with identity of proxy-user kernun and are chrooted into directory /usr/local/kernun/root. They do not define any ACL, therefore the global acl INTOK applies to them unmodified.

smtp-proxy is the proxy daemon for Simple Mail Transfer Protocol (RFCs 2821, 2822, 2045 etc.). The SMTP protocol is used to send electronic mail from clients to mail servers as well as between mail servers. The task of smtp-proxy is to apply a security policy, check the incoming mail for correctness and then use some smtp-forwarder to queue and distribute mail. In other words, there must be an SMTP server (other than Kernun UTM) to deliver e-mail. The easiest way is to employ the common UNIX postfix daemon for this task. The configuration can be included in the Kernun UTM configuration and the proper configuration files for postfix are then generated automatically.

Figure 4.15. SMTP Proxy System Sections and Forward Agent

In the typical scenario depicted in Figure 4.15, “SMTP Proxy System Sections and Forward Agent”, postfix is configured to listen at Kernun UTM's loopback address and forward e-mails send to it by smtp-proxy, which listens at Kernun UTM's internal address. Note that under this settings mail does not arrive from the Internet to the internal network. We will explain an alternative scenario in the second part of this chapter.

The postfix program is configured from Kernun UTM by the agent section in smtp-forwarder. It must contain a master-cf item — an anchor to shared-file that contains the Postfix master.cf configuration file. There is a sample in samples/shared/postfix-master.cf. There also must be specified at least one server item in smtp-forwarder — an address, to which the mail is to be sent.

The proxy itself listens transparently on Kernun UTM internal address port 25 (as defined by the listen-on section). Besides the common chroot-dir item there must also be present a postmaster item, which defines the postmaster e-mail address, and a mail-pool item, which defines the directory used as temporary storage for incoming mails.

Figure 4.16. SMTP Proxy ACLs

smtp-proxy uses four types of ACLs on three levels:

The example in Figure 4.16, “SMTP Proxy ACLs” shows three different delivery-acl items. The first one (BAD-SENDER) refuses mail with incorrect senders (i.e., the MAIL FROM argument), the second one (BAD-RCPT) rejects mail with incorrect recipients and the last one (OTHER) accepts all other mail (that is, mail that matches neither of the preceding delivery-acls). The mail-acl and doc-acl items are configured to accept all e-mails.

During the delivery-acl phase, the correctness of all the commands (HELO, MAIL FROM and RCPT TO) and their arguments is checked and the proper decision is made.

Figure 4.17. SMTP Proxy Mail Filter

smtp-proxy checks the correctness of the mail headers and MIME structure. Mail that does not conform to the RFCs is rejected. However, many clients do not respect RFCs and if the security policy allows sending of such e-mails, you can instruct the proxy to correct or even pass them. We therefore add a mail-filter item, which handles the most common cases, to the session-acl item. For details on the particular entries, see smtp-proxy(8) and mod-mail-doc(5).

In the example depicted in Figure 4.17, “SMTP Proxy Mail Filter”, a reference to mail-filter is added into session-acl of smtp-proxy. The mail-filter itself is configured to:

2.10.1. Mail Server in the Internal Network

Figure 4.18. SMTP Proxy Mail Sever in the Internal Network

There can be a mail server in the internal network. This type of mail server usually serves as the SMTP forwarder for the internal network (that is, it forwards mail addressed outside the local network, and stores mail addressed to the internal network).

From Kernun UTM's point of view, the internal SMTP server sends some e-mails^[23] to the internal interface of smtp-proxy. Such mail is already handled by smtp-proxy configured sooner in this chapter. What is new is that there can be mail from the external network addressed to someone in the local network (precisely speaking, to the mail server in the internal network). Kernun UTM should therefore listen on the external interface, accept mail addressed to the internal network and forward it to the internal mail server. It is possible either to create another SMTP server, or to extend the existing one. The example in Figure 4.18, “SMTP Proxy Mail Sever in the Internal Network” shows the latter option:

Unlike other screenshots, the figure shows only the sections and items added to the configuration of the sample smtp-proxy. A new smtp forwarder INTERNAL, which forwards mails to the internal network (to the server 192.168.1.25), has been added. Then there is smpt-proxy SMTP configured to listen in the non-transparent mode on the external interface on port 25. Furthermore, there is new delivery-acl TO-INTERNAL, which accepts only e-mails for the selected domains (example.com) and delivers them via smtp-forwarder INTERNAL. Note that the order of the access control lists of the same type (delivery-acl in this case) is significant. When Kernun UTM looks for the delivery-acl to use, it follows the first matching one and then stops the search. The delivery-acl TO-INTERNAL section must be therefore created between the BAD-RCPT and OTHER sections configured earlier. The delivery-acl OTHER section has slightly changed; it now accepts only mail from the internal network. Note that from { ^system.INT.ipv4.net }; must be located at the beginning of the ACL, so that the entry conditions are kept before the action (accept in this case). Finally, the original delivery-acl OTHER was restricted to accept mail from the external network (which was not necessary until the second listen-on item was added).

The IMAP4 and POP3 protocols are used to access electronic mail that is stored on mail servers. Both make it possible for client e-mail programs to download mail and present it to the user. Unlike POP3, IMAP4 enables them also to upload mail to the mailbox on the IMAP4 server.

2.11.1. IMAP4 Proxy

Figure 4.19. IMAP4 Proxy

imap4-proxy is the proxy daemon for Internet Message Access Protocol version 4rev1 (IMAP4rev1), as defined by RFC 3501. The proxy supports secure communication via the SSL/TLS protocols.

The proxy is configured in the imap4 section. In the sample configuration depicted in Figure 4.19, “IMAP4 Proxy”, the proxy-user and chroot-dir items define the operating-system-level user, under which the proxy should run, and the directory, to which it should be chrooted. The proxy listens transparently for requests at Kernun UTM's internal address at port 143 and, again, the proxy must be referenced by at least one ACL in the system section.

The mail-pool item defines the directory, in which e-mails are temporarily stored by the proxy. Note that this directory must be created manually by the administrator and that it must be writable by proxy-user. Note also that the directory can be the shared by smtp-proxy, imap4-proxy and pop3-proxy (or by any combination of them).

imap4-proxy uses three-phase ACLs. The first phase, session-acl, is checked once for each client connection. It permits or denies client access and sets some connection parameters. The second phase, command-acl, is also checked once for each connection, but it can be selected according to the client certificate if SSL/TLS is enabled by session-acl. Various parameters can be set in command-acl, e.g., the permitted sets of IMAP4 commands and capabilities, timeouts, SSL/TLS on the server connection. The third-phase ACLs are used only if mail processing is enabled in command-acl. Two types of these ACLs exist. mail-acl is checked once for each transferred e-mail. It defines the rules of the acceptance or rejection of the mail according to its content and antivirus/antispam test results. doc-acl is checked once for each document (MIME part) of a mail. It defines document processing, e.g., filtration or replacement by a fixed file. See mod-mail-doc (5).

In this example, command-acl COMMOK defines that no mail scanning is to be performed on either downloaded or uploaded e-mails. The item no-mail-scanning means, in this context, that the mail is not even opened. Were the no-mail-scanning item absent, the mail would be stored and unfolded to headers and attachments, etc., and various tests could be performed on any part. This alternative will be discussed in Section 15, “Antivirus Checking of Data” and Section 16, “Antispam Processing of E-mail”.

2.11.2. POP3 Proxy

Figure 4.20. POP3 Proxy

pop3-proxy is the proxy daemon for Post Office Protocol version 3 (RFCs 1939, 2449, 1734). The proxy supports secure communication via the SSL/TLS protocols.

The proxy is configured in the pop3 section. In the sample configuration depicted in Figure 4.20, “POP3 Proxy”, the proxy-user and chroot-dir items define the operating-system-level user, under which the proxy should run, and the directory, in which it should be chrooted. The proxy listens transparently for requests at Kernun UTM's internal address at port 110 and, again, the proxy must be referenced by at least one ACL in the system section.

The mail-pool item defines the directory, in which the mails are temporarily stored by the proxy. Note that this directory must be created manually by the administrator and that it must be writable by proxy-user. Note also that the directory can be the shared by smtp-proxy, imap4-proxy and pop3-proxy (or by any combination of them).

pop3-proxy uses three-phase ACLs. The first phase, session-acl, is checked once for each client connection. It permits or denies client access and sets some connection parameters. The second phase, command-acl, is also checked once for each connection, but it can be selected according to the client certificate if SSL/TLS is enabled by session-acl. Various parameters can be set in command-acl, e.g., the permitted sets of POP3 commands and capabilities, timeouts, SSL/TLS on the server connection. The third-phase ACLs are used only if mail processing is enabled in command-acl. Two types of these ACLs exist. mail-acl is checked once for each mail transferred from the server to the client. It defines rules of the acceptance or rejection of the mail according to its content and antivirus/antispam test results. doc-acl is checked once for each document (MIME part) of a mail. It defines document processing, e.g., filtration or replacement by a fixed file. See mod-mail-doc(5).

In this example, the no-mail-scanning item in command-acl COMMOK defines that no mail scanning is to be performed. In this context, as the POP3 protocol is intended only for download of e-mails, it means that the downloaded mail is not even opened. Were the no-mail-scanning item absent, the mail would be stored and unfolded to headers and attachments, etc., and various tests could be performed on any part. This alternative will be discussed in Section 15, “Antivirus Checking of Data” and Section 16, “Antispam Processing of E-mail”.