You are here

Use of Solaris 10 Zones

Affects version(s): 
4.0
4.1-10
4.1-11
4.2

This article explains how Airlock uses Solaris 10 zones for more security, and their implications on network configuration.

One of the major changes from Airlock 3.5 to Airlock 4.0 was the replacement of the underlying operating system, from Solaris 8 to Solaris 10. Solaris 10 not only allows Airlock to be installed on a wide range of x86-machines, it also provides an enhanced set of mechanisms that can be used for increased system security. One of these mechanisms are Solaris 10 zones, also known as Solaris Containers. This article explains how Airlock takes advantage of Solaris zones, as well as what restrictions the current implementation of Solaris zones puts on Airlock as a network device.

Airlock 4.1-11 and 4.2 have a reorganized zone concept. These versions only have the global and the ext zone - this reorganization was done due to solve the described networking issues. Information which is only valid for 4.1-10 is marked by colored text and *:

* affects only 4.1-10

Separation of HTTP Processing and Airlock Management

Solaris 10 zones, or simply "zones" from now on, as used by Airlock, increase resistance against system intrusion and manipulation attacks. Airlock 4.0 uses five zones to separate different processing units. Inter-zone communication is only possible either via the network stack or through file system mounts, and they need to be set up explicitly.

The zones can be categorized into two classes:

  • Web zones: the functionality of these zones is restricted to tasks that focus on processing of HTTP requests and responses.
  • * Configuration and management zones: they provide functionality for configuration and management of Airlock.

Web zones and management zones are strictly separated because no network routes are set up to allow any network communication between them. Also, subtrees of the file system where configuration files and binaries are located are only writeable in one management zone, but are read-only in the zones where access to these files is necessary.

Zone descriptions

You can check what zones are running on Airlock by using the command line command 'zoneadm':


root@airlock:/[50] # zoneadm list -cv
ID NAME STATUS PATH
0 global running /
15 ext running /zone/ext
* root@airlock:/[36] # zoneadm list -cv
ID NAME STATUS PATH
0 global running /
1 int running /zone/int
2 auth running /zone/auth
3 mgt running /zone/mgt
4 mgt_ext running /zone/mgt_ext
5 log running /zone/log
9 ext running /zone/ext

The zone "log" is new in Airlock 4.1-10 and harbors the log viewer. We will now quickly step through the list of zones and explain for each what its purpose is. But be aware that Ergon keeps the right to modify internals of Airlock at any time as is deemed necessary to assure proper and secure functioning and improve functionality of Airlock. This documentation is mainly intended to give you a better understanding of Airlock.

  • global-zone: ssh-access to Airlock and configuration tasks that need access to hardware drivers -> network configuration and failover mechanism.
  • ext-zone (web): listener processes such as Apache for HTTP requests and the SSL VPN endpoint run in this zone. Also a part of the failover mechanism is located in this zone.
  • * int-zone (web): Zone for the security gateway that filters and processes HTTP requests. If you log into this zone by 'zlogin int', you can use curl and and telnet to manually check the back-end network.
  • * auth-zone (web): container for web applications deployed on Airlock, such as the Airlock Authentication Service or the SSL VPN applet provider
  • * mgt (management): Airlock Configuration Center
  • * mgt_ext (management): connector to Configuration Center, management of Airlock-hosted web applications and log viewer
  • * log (management): log message processing and log viewer engine

Zone issues

Manual zone manipulation

As a general rule, undocumented system manipulations of Airlock on the command line are strongly discouraged by Ergon. This is particularly valid for manipulations of Airlock's zones. Zone configuration and changes in the state of zones are dynamically performed by scripts that also properly set up network interfaces and routes and mount necessary file system parts.

* Consequences for networking

Zones can only be assigned logical network interfaces, and a logical network interface always belongs to one single zone at any given time. This condition basically requires an IP address per zone that needs to handle network connections. To limit Airlock's need for IP addresses in the back-end and management networks, a set of only internally visible IP addresses is used, which isare translated to and from the corresponding IP addresses that are visible outside of Airlock whenever a network packet crosses Airlock's system boundary. The defaults for internal IP addresses are 1.1.x.1.

Unfortunately, this translation works only for IP packets on the network layer, but not for ARP packets that directly use the link layer. This has some important consequences for the network environment of Airlock: When an implicit ARP request is generated by a logical interface that uses an internal IP address, the ARP request carries the internal IP address as a payload. It was observed that this may trigger some firewalls and routers to behave in an undesirable way for the involved physical interface of Airlock.

To alleviate the problem with improper ARP requests, a series of measures are taken in Airlock:

  • First and most importantly, Airlock explicitly generates ARP broadcasts with a corrected payload for routers and some other hosts that are used in the configuration of Airlock. If ARP responses for these are received, the ARP table is automatically updated and no implicit ARP request needs to be generated.
  • During system boot and reconfiguration of Airlock, no IP addresses are published by Airlock, to prevent improper ARP broadcasts. Due to a weakness in ARP configuration handling on Solaris 10 though, there are still a couple of ARP broadcasts that slip through during system boot and publish the internal IP addresses.

Note: Affected by this ARP issue is mostly Airlock's configuration and management network. Most web requests and responses that enter and leave Airlock are exempt from this IP address translation, as the web listener and the security gate directly use the IP addresses that have been configured for Airlock's Virtual Hosts and the back-end interface.
So, if you configure the back-end network interface to be on a separate physical interface, and do not use the Web application container provided by Airlock, your Airlock should be safe from ARP issues when processing HTTP requests.

Knowledge Base Categories: