Some highly confidential applications cannot tolerate the possibility of any remote connection or exploit. Machines that require this level of security are usually kept in access restricted rooms and often built without network cards. This type of configuration is a recommended best practice for credential originating systems such as a root certificate authority where the compromise of the root keys would put all certificates and applications that were signed by that authority at risk.

Although some of Oracle VM's features such as High Availability and Master Failover are not available without a network, peer Oracle VM Servers and shared storage, the product can be configured for single-node service where VMs can provide these secure applications using a local text console, host networking and/or a shared disk to access them.

If host based network security and traffic restriction is needed between virtual machines on the same host, the ebtables application can provide Ethernet frame filtering across the Linux based bridges.

Guidelines for the no network connection model:

An isolated local network consists of servers that are connected in an environment which has no connection to any other network. In this model, there is zero network connectivity to a larger internal network or the Internet. Since there is no potential for remote exploits from a large number of unknown sources, this environment provides well defined physical, network and security characteristics.

By definition, access to this configuration is limited to personnel with access to the trusted admin hosts (including Oracle Enterprise Manager or Oracle VM Manager) on the closed, local network. Threats consist of an accidental "convenience" connection being made to other networks or a trusted admin installing an unsigned package or application that may introduce a malware agent.

Guidelines for the isolated local network model:

A Trusted Internal Network is a well maintained, trusted and probably small internal network where network traffic is unrestricted to and from the cluster subnet. While this configuration provides advantages of access to a company's infrastructure, services and storage, it also introduces a few threats. Most of these are not malicious, and normal internal safeguards such as an Intrusion Detection Systems, anti-virus software and active network monitoring typically address rogue employees or bot infestations that may attempt to disrupt the network. Human error via network and new admin mistakes are the most common causes of cluster service outages.

Guidelines for the trusted internal network model:

A default Oracle Linux install has the iptables firewall enabled. However, a best practice for network filtering is to use an additional external firewall device. This permits separation of control (network administrator control of network access, use of globally administered and audited rules), and relieves the Oracle VM dom0 of the potentially high CPU load that can be created by implementing packet filter rules. In order to use Oracle VM Manager on a system with iptables enabled you can either open the ports used by Oracle VM Manager, or open all ports by disabling iptables. The latter is not advised in the absence of an external firewall devices because it removes network protection.

The web browser connection to Oracle VM Manager requires ports 7001, 7002 and 15901. Oracle VM Serversconnect to Oracle VM Manager using ports 7001, 7002, and optionally 54321 and 54322 for remote API access.

Oracle VM Manager, in turn, connects to the Oracle VM Servers through port 8899 for Oracle VM Agent communication, and port 5900 and up for secure VNC tunneling to virtual machines (one port per VM). Be sure to open the necessary ports on the different firewalls that may be installed between different parts of your network. Additional information and a diagram can also be found in Section 2.1, “Oracle VM Pre-Installation Tasks”.

When using iptables, ensure that the service is running on each node and that at least the default policy and ruleset are present in the file /etc/sysconfig/iptables:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j DROP
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j DROP
-A INPUT -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5900:5950 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8002 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8003 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8899 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 7777 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

An untrusted internal network has the characteristics of being loosely maintained, unmonitored, readily compromised from the outside or from ongoing and uncorrected malware infested workstations on the inside.

In this model, the dom0 admin control and VMs have been partitioned into separate VLANs where traffic flow is controlled by a 3 zone router/firewall. The firewall policy is to allow the admin network to make outbound connections to anywhere, but blocks inbound connections from the untrusted internal network. Firewall policies to the VM network would depend on the application but should only expose service ports to the internal network that are needed. A signature driven Intrustion Detection System is an option on the VM network to monitor for traffic patterns that indicate an attack is underway.

This model views any traffic from the internal network as potentially hostile. Additional hardening of this network can be done by implementing hardware or iptables based firewalls and policies on the admin and dom0 hosts that block inbound traffic. The dom0 firewall rules can also be enhanced to reject peer dom0 traffic on all ports except OCFS2 (7777), Oracle VM Agent (8899), and the Xen administration ports (8002 and 8003).

Guidelines for the untrusted internal network model:

The most challenging model for securing a network connected host is placing VM based services directly on the Internet. In this case, great care must be taken to insure that the environment won't be compromised through a wide variety of penetration techniques and exploits from a large, diverse and aggressive set of threats.

Even on an untrusted internal network without intrusion detection, internal users are known quantities and typically aware that they are being monitored, so they generally do not tend to be abusive or even overly curious. In contrast, the Internet provides virtual anonymity for malicious individuals, criminal gangs and hostile, well equipped governments. With an anonymous cloak, probing and attacking high profile network segments with automated tools that run 24/7 is a standard procedure. On perimeter firewalls, aggressive penetration attempts on the ssh, mysql, oracle, netbios and smtp service ports can typically be measured in "attacks per second".

There are a variety of topologies to provide zone isolation that can help to repel attacks and mitigate the effects of a successful intrusion event. The following describes some basic approaches.

Guidelines for network models involving Internet facing services: