In the previous section we described the initial configuration as generated by the configuration script during the first boot after the installation of Kernun UTM. In this section we will demonstrate how to modify the configuration. We will make the following changes:
enable dns-proxy;
enable http-proxy;
restrict HTTP to a subset of the internal network;
allow only the HTTP method
GET.
First of all, we want to permit the HTTP traffic. As the transparent mode of the proxy is used, the clients connect directly to servers. Therefore, the clients must be able to resolve server addresses, which is why we need to enable DNS as well. The following steps produce a working configuration with the required changes.
Start the GUI and connect to Kernun UTM, as described in Section 1.1, “Kernun GUI Launcher”. If Kernun UTM is running the unmodified initial configuration, you will see the GKAT window with only a few components running, as depicted in Figure 4.21, “The Kernun UTM running the initial configuration”.
Select in the menu to open the configuration.
In the left-hand part of the configuration window, look for a line containing
hidden dns-proxy DNS. Select the line with the left mouse button, then click the right mouse button to open the context menu and select . The line will change todns-proxy DNS.Repeat the same action for the line containing
hidden http-proxy HTTP.Select the line
acl INTOKand then select from the context menu. In the Create Item/Section dialog, selectaclas the type of the section and set the section's name, for exampleNET1_DENY. You have created a new global ACL.Now select the newly created ACL and use from its context menu repeatedly to add the
from,service, anddenyitems.Select the
fromitem. In the right-hand part of the configuration window you can see the current value of the item, which is the empty set. Add a new value to the set by clicking on the button . Enter the address (with mask) of the subnet that is to be denied, for example,[192.168.10.128/25].Select the
serviceitem. Using , addHTTPto the list.Now we have the new ACL denying access from a subnetwork ready. However, as the ACLs are checked in sequence and the first matching is used, we must exchange our two ACLs. This can be done in several ways. One possibility is to select
acl NET1_DENYand click on in its context menu.Finally, we want to restrict the
HTTPproxy to allow only theGETmethod. Open thehttp-proxy HTTPsection by clicking on the small plus sign. Select therequest-acl ALL2line.Add a
request-method { GET }item to this ACL in the same way as when you modified values inacl NET1_DENY.The configuration should now correspond to Figure 4.22, “The modified configuration”.
Save, generate, and apply the configuration by selecting . The Commit configuration window is displayed, as depicted in Figure 3.17, “Configuration commit dialog”.
Click to enter a RCS log message with a description of the change you have made.
The configuration is saved to Kernun UTM, recorded as a new version in the RCS file, the low-level configuration files are generated and applied (copied to the locations where Kernun UTM components will look for them).
The Synchronize system with configuration window is displayed, as depicted in Figure 4.23, “Activation of the new configuration”. It informs you that components
DNSandHTTPhave been reconfigured and need to be started for the new configuration to take effect.Click in the synchronization dialog to finish the reconfiguration; Kernun UTM now contains running DNS and HTTP proxies, see Figure 4.24, “Reconfigured Kernun UTM is running”.
Now you can switch to the Log page of the Proxies node in the GKAT window. If you start a Web browser on a machine in the internal network and try to access a Web server in the external network, you will see proxy log messages appearing.
The process of adding new TCP proxies can be simplified even more using two wizards (for general information on wizards, see Section 1.4.6, “Configuration Wizards”). When creating a TCP proxy, you first need to decide whether you want to enable the connection of clients in the internal network to a server in the external network (the server must have a public IP address and the clients connect to this address), or whether you have a server in the internal network (with a private IP address) and clients from the external network will connect to Kernun UTM, which will forward them to the server. The Kernun GUI provides one wizard for each of the alternatives. The following subsections describe the creation of sample proxies in both cases.
As we have said before, a proxy needs to be created in order to allow
communication from the internal to the external network. The proxy should be
transparent, which means that clients in the local network would not be aware of the fact
that they do not connect directly to the server. The TCP proxy to external network wizard
will lead you through the creation of the transparent TCP proxy.
In this example, we will configure the transparent tcp-proxy
to allow some privileged local clients to shop on www.ebay.com.
First of all, you need to delete or hide the
tcp-proxy HTTPS from the initial configuration,
because it would collide with the proxy we want to create. Then
select to start the wizard.
On the first page, you are asked to choose the
tcp-proxy section name, the interface
to the network that contains the clients and the port of the service that is
supposed to use the proxy. In our example, we choose the INT
interface and the 443 port, as shown in
Figure 4.25, “TCP proxy general network settings”.
On the second page, you define the clients in the internal network
that are allowed to connect using this proxy and the servers in the external
network, to which the clients may connect, in the form of either IP addresses
or host names. If you already have an appropriate ACL created in the
configuration, you may select the Use existing accepting ACL
radio button and then choose the ACL to be used for this proxy. As we do not
have any usable ACL in the system, however, we choose to create a new
one, and set its name and the IP address of the privileged client that is
allowed to log in to the ebay.com server. The configuration is
depicted in Figure 4.26, “TCP proxy ACL settings”.
The third page contains more advanced connection settings, including several connection timeouts and a limit of the number of proxy children. If you do not fill in any of these fields, the corresponding item will not be included in the resulting configuration. Since we know that there will be no problems with the traffic load, we leave all the limits empty. In order to get more detailed traffic examination outputs, we choose to monitor the proxy (which i.a. produces graphs of the proxy usage, see Figure 3.8, “Graphs page”) and to generate proxy statistics (see Figure 5.26, “Statistics browser window”). The filled page is shown in Figure 4.27, “TCP proxy miscellaneous settings”.
Finally, the last page (Figure 4.28, “TCP proxy recapitulation”) shows
the recapitulation of the wizard settings in the form of the text configuration
that is to be added to the main system configuration. There is also the
outcome of system verification of the configuration with the created proxy.
You can click Finish to commit the proxy into the configuration,
Back to return and modify the wizard settings, or
Cancel to close the wizard and discard all the settings.
Besides the above-mentioned wizard for a transparent proxy,
the Kernun GUI also provides a wizard for a non-transparent tcp-proxy.
In this case, clients connect to to a specified port at Kernun UTM, which
forwards the communication to a server behind it. This is useful when
creating servers without a public IP address in the internal network (which
is a recommended practice). We will create an IMAP4S proxy that will
allow employees at home connect to a mail server in the internal company network behind
Kernun UTM and read their mail. The wizard is very similar to the
Section 3.1.1, “TCP Proxy to Server in External Network” wizard; actually, only the second page
differs.
On the first page, we choose the proxy name, the interface on which
it is supposed to listen (this time, it is the external interface
EXT) and the port for secure IMAP4, 993.
On the second page, we similarly define the ACL, with a slight difference
in the process of its creation. We only define restrictions concerning
clients, as they always connect to Kernun UTM.
After choosing the ACL, we need to specify where to plug the
communication in (in our case the IP address of the IMAP4S server) and the port
it listens on. This is specified in a single field as
[192.168.10.7] : 993. Furthermore, we want the server to receive
packets with the original client's IP address (rather than that of Kernun UTM), so we
check the Client source address check box. The second
page is shown in Figure 4.29, “Non-transparent TCP proxy ACL settings”.
The last two pages are the same as in the transparent proxy wizard.
