www.fridu.net

While they are many available firewall for Linux, none of them are really designed for virtualization. Obviously it is alway possible to hack an existing one to fit your need, but VM-firewall has been designed to support virtualization in a Internet hosted environment, it runs the same rules for Xen, OpenVZ and VirtualBox. The goal of VM-Firewall if to provide to virtualization administrator the same facility has the one provided by an intelligent router in a traditional architecture, it is particularly useful for people who have multiple IP addresses that they want to forward on different virtual machines.

Disclaimer

Anything I wrote here was done outside of my professional work context and  none of my current/past employers/customers have participate or even be consulted for this work. Fridu is 100% part of my free time, and everything including hosting is funded on our pocket money and used to support non commercial friend organizations. While I think I have the technical background to design a smart architecture (cf:my profile). I nevertheless do not guaranty that it will work for you, or even that you will agree with me. I still hope it may help some of you and I would be more than happy to incorporate improvement if ever you have some.

Architecture

When running virtualization in a hosting environment, the main issue is the lack of access to networking infrastructure. Usually you get access to a limited number of public IP, with no DHCP and/or ARPA facilities. This imposes your virtualization infrastructure to be completely invisible from your provider's router. For this reason VM-firewall does not expose virtual machines directly to physical interface, but leverages virtual network interfaces, iptables and routing capabilities to map data stream to a given VM.

• For input initiated stream: VM-firewall maps an external IP+port to a given destination VM+port. VM receives the original Internet source IP addresses and can very easily applies their own network  access control. Note: one given VM may received internet stream from more than one external IP addr (which does not mean it is a good idea)
• For output initiated stream: VM-firewall groups VM into zones, Then based on zones internal IP addresses and attached virtual network interface, it reverses map VM's internal IP to chosen external IP address. Outgoing stream are handle through a simple NAP operation, the only difference with a simple NAT as your home aDSL modem/router is that depending on the selected zone, your parquet will appear as coming from a different public IP. Note that as external public IP address selection is based on zone local network internal IP+virtual-NIC, for a given VM, outgoing stream can  only NAT one public IP addr.

VM-Firewall uses 3 class of objets.

• zones: virtual machines are grouped into zones. A configuration have two or more zones: a dummy one named "none" for the hypervisor, and one to many for virtual machines. Typically the number of zones is equivalent to the number of external IP addresses+1(for hypervisor). Each zone may contend one to many virtual machines. zone is a set of virtual machines that shared a unique:
  • virtual network interface
  • local virtual network mask
  • external IP address
• application: inside a zone it defines a port-forwarding for external data stream to internal virtual machines. An application takes as input a port and as destination a virtual machine's virtual network's IP+port.
• tuning: optional values that allow you to enforce some global policies at zone level. Tuning may be used to prevent a zone to send SMTP traffic, or to limit SSH access from a given network, etc.

Configuration

Introduction

Config file can either be a flat file or a directory containing one to many *.conf rules. VM-firewall uses a two passes architecture: first pass reads every config files and loads them into tables, second pass scans those tables and generates iptables rules. This two pass model provides a lot of flexibility to configuration syntax, it:

• decorelates configuration syntax from iptables structure
• validates configuration independently of file order
• generates easy to read/understand iptables rules
• allow a lot of debugging tools

Zones

In a traditional ISP zones defines a group of servers attached to a specific VLAN. Real ISP typically have 5 to 10 zones [ex: common services, database, messaging, etc]. Many of us should be more than happy with one or two zones. If you have two external IP addresses you may want two zones, this because nating for outgoing traffic is attached a given zone. For each zone we must define:

• The external NIC                       (required is your zone host Internet application)
• The external IP address           (one NIC support many IP)
• The internal virtual interface    (your bridge for: Xen, vmWare, virtualbox and vnet for OpenVZ)
• The Internal IP address.           (traffic for the zone is routed through this interface)

Normally a zone is connected to Internet through a public IP, nevertheless you may want to have an "admin" zone dedicated to internal services (ex: DHCP, LDAP, Backup, ...)  that you isolate from Internet. A zone receives traffic from:

• Incomming Internet traffic is DNAT to the internal IP/Port providing the service
• Outgoing Internet traffic is NAT to appear as coming from your external IP
• VPN is fully routed within the admin network

Default behaviour

• not to accept any traffic from Internet
• allow any traffic from the VM to the outside
• Internal and VPN traffic are unlimited in both direction.

Note: zones do not define security inside your VM. If needed each VM can define it own access rules (firewall, apache acl, ...). Security provided by your zone is more or less equivalent of LAN and port locking  as provided by intelligent switch/routers (Alteon, Cisco, ...)

Application

As said previously default zone behavior is to lock any traffic from Internet. When hosting applications you want some Internet traffic to be routed from the external NIC to your VMs. For each given application, WM-firewall is doing tree things:

• open given port/proto on external interface for the given IP (in case you have more than one IP on your NIC)
• forward incoming traffic to the internal VM using DNAT functionality
• NAT outgoing traffic to to hide your Internal VM IP addr make it appear as coming from a public IP address.

For each application we have to provide

• NAME a Label that should be unique in each file,
• ZONE this is zone as defined previously, it will define you external IP address and your internal netmask.
• EXT the external port/proto your application is listening. Be careful not to overlap your listening port, this especially when two zones are using the same external IP address.
• INT your internal IP address and port, as obviously nothing force you to present the same port internally and externally.

Tuning

Optional zone access control parameters, that  most of you will probably ignore, expect if you're realy sure you need it, start without. Nevertheless they are cases where not only you want to control external traffic, but you also want to control internal traffic. For example let's say that one of your zone is used by student for admin security labs, while some others are used for real "in production" university applications. You may want to restrict SSH access even from the internal LAN/VPN to your "in production zone". Equally, you may want to forbid peer to peer or SMTP outgoing from some zones. Tuning is important as soon as you cannot trust the admin of a given virtual machine, this even if this guy has root passwd for his own VM or even the full set of VM in a given zone. You as the hypervisor admin want to make sure than what ever any VM admin is doing you keep control or the global platform.

Tuning  applies in between opening application port and closing iptables chain of a given zone, this to assert that default action for incoming packets is "drop". Tuning iptable are applyied directly on zone Internal interface (ex: Xen Bridge, OpenVZ vnet) and can thus lock any traffic before it get the chance of behing evaluated for routing. You can use tuning rules to limit incoming/outgoing traffic, rules will affect both external an internal LAN.

Command line syntax

The parser is only a very basic shell script, and while my goal was to make the config file as simple as possible I did not spend much time in tracking lexical/grammatical errors. For this reason before going in production you MUST check that both you and my parser have the same understanding of your rules. This is especially important if you run a remote machine as locking your external interface may prevent you from accessing to your machine. General syntax is "Fridu-firewall.script command option-1=xxx ... option-n=..."

The parser will first read all your rules and then depending on your command will generate the adequate iptables.

• Fridu-firewall.script display    ;# config as understood by parser [should be used after each rules update]
• Fridu-firewall.script test          ;# start firewall and stop it automatically after 180s
• Fridu-firewall.script start         ;# build iptables and activate firewall
• Fridu-firewall.script stop         ;# delete every zone table and leave all your ports open with routing active
• options:

1. config=file|directory    ;# overwrite default config
2. debug=1       ;# only design to debug the script
3. verbose=1    ;# step by step verbose mode
4. dummy=1     ;# generate rules but do not apply them
5. dump=file     ;# dump the iptable to a file

• ex: Fridu-firewall.script start dump=/tmp/my-iptables [Start firewall and dump a copy of rules in /tmp/my-iptables]
• ex: Fridu-firewall display config=/etc/sysconfig/Fridu-firewall/samples/Fridu-firewall-Guru.config
  

Action section

This is optional, and hopefully most of you wont need it Action section is not handle directly by VM-firewall script, it is only a convenient place for addon functions, you would like to start with firewall boot from /etc/init.d time, as:

• bridge creation
• special rules to allow one zones to talk to the other
• allow VPN traffic
• etc.

Any shell  command can be used, action is either "start" or "start", as stopping a firewall before shutting down a machine is quite useless, is a special action is needed most of you should only implement the "start" part of it.

Example-XEN:

Warning: In order to use VM-firewall with Xen you need to update Xen's network script, check full article [here]

• allow VPN(tun+) to/from traffic to zone(xen-br+)
• allow zones to zones traffic ( -i xen-br+ -o xen-br)

Example-OpenVZ:

For further information check OpenVZ-Proxmox and VM-firewall post [here]

• allow to/from VPN traffic(tun+) to zones virtual interface (vnet+)
• allow zones to zones traffic (-i venet+ -o venet+)
• hack to map IP-two ssl port to internal 563 openvpn TCP port (this because SSL on IP-one is used for web applications)

Example VirtualBox

For further information on VirtualBox and VM-firewall check [here]

• create a bridge for virtual box and map local virtual address onto it
• create a Tun network interface for each virtual machine and add them into the bridge
• at stop time delete the bridge [just to prove it works :)]

QuickStart & Debug

Sample config and debug explanation are locate on a dedicated page [here]

Bugs/Limits

Parser is bash based and very primitive.It is very sensitive to "strings", especially labels/names of rules must be in pure basic alphanumeric characters. This is because parser build a shell variable with each label, which explain why label are so restrictive. As a result "MyZone or MY_Zone" is OK when "My-Zone or My:Zone" is not.

When using shared shell variables  (ex: for PUBLIC-IP, Virtual-Interface names, ...) make sure that  your "1st-defintion.conf"  configuration file owning those variables is readed before the config using it [*.conf are readed is alphabetic order] In case of doubt use "Fridu-firewall start dummy=1 verbose=1  dump=/tmp/iptables" verify that the file owning shared variables definition is readed 1st, and if needed "vi  /tmp/iptables" to verify that variables where effectivly expended.

Download installation

FW-firewall is written on bash shell, and should work out of box on any Linux distribution. After download the easiest way of to copy a sample config that is close of yours, to copy it in a private directory and then to customize it to your need. This behind done, You can install VM-firewall and select your own rules as default config.

1. Downloaded VM-firewall from (here)
2. (cd /opt; tar -xzf VM-Firewall-*.tgz)
3. cd /opt/VM-Firewall
4. cp ./fw-rules/ChoosenTemplate ./fw-rules/my-$HOSTNAME
5. ./install template=my-$HOSTNAME
6. edit config in ./fw-rules/my-$HOSTNAME
7. Fridu-firestart display
8. Fridu-firewall test timeout=180
9. Fridu-firewall start

Note:

• installation does not copy files, but link distribution to well know location (/usr/sbin for commands and /etc/default | /etc/sysconfig for configurations). As a result "/opt/VM-Firewall" should not be deleted after installation, and building your config in /opt/FW-firewall/fw-rules or in /etc/sysconfig/Fridu-firewall is equivalent.
• Autoboot: a startup script is placed in /etc/init.d and activate firewall at boot time. Two init.rc templates are provided one for Debian, the other one for SLE.
• Default config: is defined by FWCONFIG=xxxx in either /etc/default/Fridu-default (debian,ubuntu) or /etc/sysconfig/Fridu-default (opensuse, redhat, ...).  FWCONFIG should point on a template directory inside "fw-rules" directory. You can overload default value with "config=xxx" option, nevertheless init.d only start default configuration. Note that install.sh will set default template, if specifyed at installation time. To control/verify your default config use: "Fridu.firewall display"

Example of display command

-