2,253
edits
Changes
m
Robot: Automated text replacement (-VEs +containers)
This document consists of two parts. The first is setting up a firewall (using iptables) on the HN, which will restrict traffic to the VEscontainers. The effect would emulate, as far as the VEs containers and their customers are concerned, an external hardware firewall controlled by the sysadmin. The second is setting up a firewall that protects the HN itself but still allows traffic to the VEscontainers, thus allowing individual VEs containers to define their own iptables.
While the firewalls shown here can be accomplished using iptables manually (or using Fedora core's iptables service), the methods presented here are especially modular and easy to modify. This is important when you have 20+ VEs containers and a lot of other things to be doing...
The scripts and pathnames given here are for Fedora Core 6, though they can probably be applied to most similar SysV-like systems with little modification.
== A little background ==
On our systems, we use the HN to provide privileged services which are not appropriate for access by the VEscontainers. For example, the HN acts as a backup server, runs Nagios for health monitoring, has a webserver for managing the 3ware RAID controller, etc. The VEs containers are leased to customers, who can't entirely be trusted, especially if they get hacked. As such, our scenario is one in which the HN must be protected from all access (even from the VEscontainers) except for a few trusted hosts (e.g. my home-office).
The exception to this is the nameserver, which we want open to the world. We use it as a caching nameserver for our VEs containers and also to host DNS for a few customer domain.
== Setting up a HN-based firewall ==
This setup emulates (to the VEs containers anyway) an external hardware firewall. It protects the HN from any access and then defines what services and ports are allowed/banned for individual VEscontainers. This leaves the firewall controlled by the site administrator, not be individual VEs containers and the hackers who've gotten into them. ;)
First off, let's disable Fedora's existing <code>iptables</code> service:
# This script sets up the firewall for the INPUT chain (which is for the HN itself)
# and then processes the config files under /etc/firewall.d to set up additional rules
# in the FORWARD chain to allow access to VEscontainers' services.
. /etc/init.d/functions
# the IP used by the hosting server itself
THISHOST="192.168.0.1"
# services that should be allowed to the HN; services for VEs containers are configured in /etc/firewall.d/*
OKPORTS="53"
# hosts allowed full access through the firewall, to all VEs containers and to this server
DMZS="12.34.56.78 90.123.45.67"
</pre>
As you can see, you can now add and edit the configurations for individual VEs containers very easily. This method proves a lot easier to manage than Fedora's iptables-config mechamism!
== Setting up a firewall that allows per-VE configuration ==
This setup configures iptables on the HN to disallow access to all hosts, including the VEscontainers. However, it allows all traffic into the VEs containers so they may define their own iptables rules and therefore manage their own firewall.
<code>This content is missing. You are invited to fill it in, if you get to it before I do. :)</code>