Editing Setting up an iptables firewall

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
This document consists of two parts. The first is setting up a firewall (using iptables) on the [[HN]], which will restrict traffic to the containers. The effect would emulate, as far as the 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 containers, thus allowing individual containers to define their own iptables.
+
This document consists of two parts. The first is setting up a firewall (using iptables) on the HN, which will restrict traffic to the containers. The effect would emulate, as far as the 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 containers, thus allowing individual 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+ containers and a lot of other things to be doing...
 
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+ containers and a lot of other things to be doing...
Line 10: Line 10:
  
 
The exception to this is the nameserver, which we want open to the world. We use it as a caching nameserver for our containers and also to host DNS for a few customer domain.
 
The exception to this is the nameserver, which we want open to the world. We use it as a caching nameserver for our containers and also to host DNS for a few customer domain.
 
== Simple firewall configuration independent of IP addresses: vzfirewall ==
 
 
<code>Vzfirewall</code> tool allows you to open/close ports for incoming connections with no dependencies to foreign IP addresses. E.g. you may allow a hostname <code>release.prod.example.com</code> to connect to port 5432 of VE 1234 and leave all other ports closed by modifying <code>1234.conf</code> file adding multiline <code>FIREWALL</code> directives into it:
 
 
<pre>
 
...
 
PRIVVMPAGES="300000:300000"
 
HOSTNAME="example.com"
 
...
 
FIREWALL="
 
    ...
 
    # Allow access to PostgreSQL port only from release.prod
 
    # and release.test machines. You may use domain names here.
 
    [5432]
 
    release.prod.example.com
 
    release.test.example.com
 
    ...
 
"
 
</pre>
 
 
You must then run <code>vzfirewall -a</code> on your hardware node to apply changes made in <code>*.conf</code>.
 
 
Note that it is recommended to use hostnames instead of IP addresses here, so the configuration is persistent for VE movements to different IP-address: you just need to run <code>vzfirewall -a</code> again after movement. It is also reboot-safe, as the rules are applied to <code>/etc/sysconfig/iptables</code> (at RHEL systems).
 
 
Vzfirewall and its documentation are available at [http://en.dklab.ru/lib/dklab_vzfirewall/ http://en.dklab.ru/lib/dklab_vzfirewall/].
 
 
== An alternative from the author of Shorewall ==
 
 
For those who might find the solution provided in this wiki article unsatisfactory (for whatever reason), the creator of Shorewall (Tom Eastep) has written a nice article explaining how to use Shorewall on an OpenVZ host node to manage the host node, containers, and more... with quite a complex setup as an example.  The article IS NOT an introduction to Shorewall for beginners, so some pre-existing knowledge and understanding of Shorewall may be required.
 
 
Shorewall and OpenVZ by Tom Eastep - http://www.shorewall.net/OpenVZ.html
 
 
See also this OpenVZ Forum posting - http://forum.openvz.org/index.php?t=msg&goto=16406&
 
  
 
== Setting up a HN-based firewall ==
 
== Setting up a HN-based firewall ==
Line 59: Line 25:
 
#!/bin/sh
 
#!/bin/sh
 
# firewall      Start iptables firewall
 
# firewall      Start iptables firewall
# chkconfig: 2345 97 87
+
# chkconfig: 2345 08 92
 
# description:  Starts, stops and saves iptables firewall
 
# description:  Starts, stops and saves iptables firewall
 
# This script sets up the firewall for the INPUT chain (which is for
 
# This script sets up the firewall for the INPUT chain (which is for
Line 65: Line 31:
 
# /etc/firewall.d to set up additional rules in the FORWARD chain
 
# /etc/firewall.d to set up additional rules in the FORWARD chain
 
# to allow access to containers' services.
 
# to allow access to containers' services.
# http://wiki.openvz.org/Setting_up_an_iptables_firewall
 
  
 
. /etc/init.d/functions
 
. /etc/init.d/functions
Line 157: Line 122:
 
     ;;
 
     ;;
 
esac
 
esac
</pre>
 
 
Note: This will only allow access to the HN from the hosts/networks defined in SEGMENT. If you'd like to open up the OKPORTS on the HN to everybody, you can remove the ''-s $SEGMENT'' parameters from the iptables commands under the "Firewall: Allowing access to HN" section. The modified lines would look like this:
 
 
<pre>
 
iptables -I INPUT -j ACCEPT -d $THISHOST --protocol tcp --destination-port $port
 
iptables -I INPUT -j ACCEPT -d $THISHOST --protocol udp --destination-port $port
 
 
</pre>
 
</pre>
  
Line 191: Line 149:
 
</pre>
 
</pre>
  
And there you go.  
+
And there you go. Go ahead and start the firewall and check its status:
 
 
Note: You can only put one IP address inside the CTIP variable, but if your container has multiple IP addresses you can create a copy of the file for each IP address.
 
 
 
Go ahead and start the firewall and check its status:
 
 
<pre>
 
<pre>
 
service firewall restart
 
service firewall restart
Line 202: Line 156:
  
 
As you can see, you can now add and edit the configurations for individual containers very easily. This method proves a lot easier to manage than Fedora's iptables-config mechamism!
 
As you can see, you can now add and edit the configurations for individual containers very easily. This method proves a lot easier to manage than Fedora's iptables-config mechamism!
 
To make the firewall service automatically start when the HN boots, run
 
<pre>
 
chkconfig --add firewall
 
</pre>
 
  
 
=== Debian Notes ===
 
=== Debian Notes ===
Line 225: Line 174:
 
This setup configures iptables on the HN to disallow access to all hosts, including the containers. However, it allows all traffic into the containers so they may define their own iptables rules and therefore manage their own firewall.
 
This setup configures iptables on the HN to disallow access to all hosts, including the containers. However, it allows all traffic into the containers so they may define their own iptables rules and therefore manage their own firewall.
  
<pre>
+
<code>This content is missing. You are invited to fill it in, if you get to it before I do. :)</code>
iptables -P FORWARD ACCEPT
 
iptables -F FORWARD
 
</pre>
 
 
 
This will remove all rules for the FORWARD chain so all packets can pass back and forth between containers and the outside world.
 
  
 
If you want to use a firewall inside a container, please load these modules BEFORE starting the container:
 
If you want to use a firewall inside a container, please load these modules BEFORE starting the container:
Line 240: Line 184:
  
 
If you do not, you will get an error like this: "iptables: No chain/target/match by that name"
 
If you do not, you will get an error like this: "iptables: No chain/target/match by that name"
* Note: xt_tcpudp module seem to be included in the kernel packages of Debian 6, but not of CentOS 6.
 
 
If you want to use stateful firewall rules (and you should!) you will also need to make sure that 'ipt_state' is in the 'IPTABLES' option in your vz.conf file:
 
 
<pre>
 
IPTABLES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state"
 
</pre>
 
 
Also make sure the 'xt_state' module is loaded on the host:
 
 
<pre>
 
modprobe xt_state
 
</pre>
 
 
 
Above information is outdated, to enable iptables you need to make sure that CT.conf(CT - id of your container, 100 for example) contains following line:
 
 
<pre>
 
NETFILTER="full"
 
</pre>
 
 
When this done, you should reboot your container and iptables should work properly.
 
  
 
== See also ==
 
== See also ==
  
 
* [[Traffic accounting with iptables]]
 
* [[Traffic accounting with iptables]]
* [http://www.readymakers.com/blog/how-to-enable-iptables-in-openvz-container/ How to enable IPtables in OpenVZ container] (Frank Taveras) - Lack of modprobe modules on HN.
 
  
 
[[Category: Networking]]
 
[[Category: Networking]]

Please note that all contributions to OpenVZ Virtuozzo Containers Wiki may be edited, altered, or removed by other contributors. If you don't want your writing to be edited mercilessly, then don't submit it here.
If you are going to add external links to an article, read the External links policy first!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)