Merge "Typo fix: remove multiple whitespace"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
c9dff59c18
|
|
@ -2,10 +2,10 @@ Multi Tenancy Networking Protections in XenServer
|
|||
=================================================
|
||||
|
||||
The purpose of the vif_rules script is to allow multi-tenancy on a XenServer
|
||||
host. In a multi-tenant cloud environment a host machine needs to be able to
|
||||
host. In a multi-tenant cloud environment a host machine needs to be able to
|
||||
enforce network isolation amongst guest instances, at both layer two and layer
|
||||
three. The rules prevent guests from taking and using unauthorized IP addresses,
|
||||
sniffing other guests traffic, and prevents ARP poisoning attacks. This current
|
||||
sniffing other guests traffic, and prevents ARP poisoning attacks. This current
|
||||
revision only supports IPv4, but will support IPv6 in the future.
|
||||
|
||||
Kernel Requirements
|
||||
|
|
@ -22,43 +22,43 @@ the proper version of XenServer to recompile the dom0 kernel.
|
|||
XenServer Requirements (32-bit dom0)
|
||||
====================================
|
||||
|
||||
- arptables 32-bit rpm
|
||||
- arptables 32-bit rpm
|
||||
- ebtables 32-bit rpm
|
||||
- python-simplejson
|
||||
|
||||
XenServer Environment Specific Notes
|
||||
XenServer Environment Specific Notes
|
||||
====================================
|
||||
|
||||
- XenServer 5.5 U1 based on the 2.6.18 kernel didn't include physdev module
|
||||
support. Support for this had to be recompiled into the kernel.
|
||||
support. Support for this had to be recompiled into the kernel.
|
||||
- XenServer 5.6 based on the 2.6.27 kernel didn't include physdev, ebtables, or
|
||||
arptables.
|
||||
- XenServer 5.6 FP1 didn't include physdev, ebtables, or arptables but they do
|
||||
have a Cloud Supplemental pack available to partners which swaps out the
|
||||
kernels for kernels that support the networking rules.
|
||||
kernels for kernels that support the networking rules.
|
||||
|
||||
How it works - tl;dr
|
||||
====================
|
||||
|
||||
iptables, ebtables, and arptables drop rules are applied to all forward chains
|
||||
on the host. These are applied at boot time with an init script. They ensure
|
||||
all forwarded packets are dropped by default. Allow rules are then applied to
|
||||
on the host. These are applied at boot time with an init script. They ensure
|
||||
all forwarded packets are dropped by default. Allow rules are then applied to
|
||||
the instances to ensure they have permission to talk on the internet.
|
||||
|
||||
How it works - Long
|
||||
===================
|
||||
|
||||
Any time an underprivileged domain or domU is started or stopped, it
|
||||
gets a unique domain id (dom_id). This dom_id is utilized in a number
|
||||
gets a unique domain id (dom_id). This dom_id is utilized in a number
|
||||
of places, one of which is that it is assigned to the virtual
|
||||
interface (vif). The vifs are attached to the bridge that is attached
|
||||
to the physical network. For instance, if you had a public bridge
|
||||
interface (vif). The vifs are attached to the bridge that is attached
|
||||
to the physical network. For instance, if you had a public bridge
|
||||
attached to eth0 and your domain id was 5, your vif would be vif5.0.
|
||||
|
||||
The networking rules are applied to the VIF directly so they apply at the lowest
|
||||
level of the networking stack. Because the VIF changes along with the domain id
|
||||
level of the networking stack. Because the VIF changes along with the domain id
|
||||
on any start, stop, or reboot of the instance, the rules need to be removed and
|
||||
re-added any time that occurs.
|
||||
re-added any time that occurs.
|
||||
|
||||
Because the dom_id can change often, the vif_rules script is hooked into the
|
||||
/etc/xensource/scripts/vif script that gets called anytime an instance is
|
||||
|
|
@ -66,11 +66,11 @@ started, or stopped, which includes pauses and resumes.
|
|||
|
||||
Examples of the rules ran for the host on boot:
|
||||
|
||||
iptables -P FORWARD DROP
|
||||
iptables -P FORWARD DROP
|
||||
iptables -A FORWARD -m physdev --physdev-in eth0 -j ACCEPT
|
||||
ebtables -P FORWARD DROP
|
||||
ebtables -A FORWARD -o eth0 -j ACCEPT
|
||||
arptables -P FORWARD DROP
|
||||
arptables -P FORWARD DROP
|
||||
arptables -A FORWARD --opcode Request --in-interface eth0 -j ACCEPT
|
||||
arptables -A FORWARD --opcode Reply --in-interface eth0 -j ACCEPT
|
||||
|
||||
|
|
@ -82,37 +82,37 @@ arptables -A FORWARD --opcode Request --in-interface "vif1.0" \
|
|||
arptables -A FORWARD --opcode Reply --in-interface "vif1.0" \
|
||||
--source-ip 10.1.135.22 --source-mac 9e:6e:cc:19:7f:fe -j ACCEPT
|
||||
ebtables -A FORWARD -p 0806 -o vif1.0 --arp-ip-dst 10.1.135.22 -j ACCEPT
|
||||
ebtables -A FORWARD -p 0800 -o vif1.0 --ip-dst 10.1.135.22 -j ACCEPT
|
||||
ebtables -A FORWARD -p 0800 -o vif1.0 --ip-dst 10.1.135.22 -j ACCEPT
|
||||
ebtables -I FORWARD 1 -s ! 9e:6e:cc:19:7f:fe -i vif1.0 -j DROP
|
||||
|
||||
Typically when you see a vif, it'll look like
|
||||
vif<domain id>.<network bridge>. vif2.1 for example would be domain 2 on the
|
||||
vif<domain id>.<network bridge>. vif2.1 for example would be domain 2 on the
|
||||
second interface.
|
||||
|
||||
The vif_rules.py script needs to pull information about the IPs and MAC
|
||||
addresses assigned to the instance. The current implementation assumes that
|
||||
addresses assigned to the instance. The current implementation assumes that
|
||||
information is put into the VM Record into the xenstore-data key in a JSON
|
||||
string. The vif_rules.py script reads out of the JSON string to determine the
|
||||
IPs, and MAC addresses to protect.
|
||||
string. The vif_rules.py script reads out of the JSON string to determine the
|
||||
IPs, and MAC addresses to protect.
|
||||
|
||||
An example format is given below:
|
||||
|
||||
# xe vm-param-get uuid=<uuid> param-name=xenstore-data
|
||||
# xe vm-param-get uuid=<uuid> param-name=xenstore-data
|
||||
xenstore-data (MRW):
|
||||
vm-data/networking/4040fa7292e4:
|
||||
{"label": "public",
|
||||
"ips": [{"netmask":"255.255.255.0",
|
||||
"enabled":"1",
|
||||
"ip":"173.200.100.10"}],
|
||||
"ips": [{"netmask":"255.255.255.0",
|
||||
"enabled":"1",
|
||||
"ip":"173.200.100.10"}],
|
||||
"mac":"40:40:fa:72:92:e4",
|
||||
"gateway":"173.200.100.1",
|
||||
"gateway":"173.200.100.1",
|
||||
"vm_id":"123456",
|
||||
"dns":["72.3.128.240","72.3.128.241"]};
|
||||
|
||||
vm-data/networking/40402321c9b8:
|
||||
{"label":"private",
|
||||
"ips":[{"netmask":"255.255.224.0",
|
||||
"enabled":"1",
|
||||
"enabled":"1",
|
||||
"ip":"10.177.10.10"}],
|
||||
"routes":[{"route":"10.176.0.0",
|
||||
"netmask":"255.248.0.0",
|
||||
|
|
@ -122,10 +122,10 @@ vm-data/networking/40402321c9b8:
|
|||
"gateway":"10.177.10.1"}],
|
||||
"mac":"40:40:23:21:c9:b8"}
|
||||
|
||||
The key is used for two purposes. First, the vif_rules.py script
|
||||
The key is used for two purposes. First, the vif_rules.py script
|
||||
reads from it to apply the rules needed after parsing the JSON.
|
||||
Second, because it is put into the xenstore-data field, the xenstore
|
||||
is populated with this data on boot. This allows a guest agent the
|
||||
is populated with this data on boot. This allows a guest agent the
|
||||
ability to read out data about the instance and apply configurations
|
||||
as needed.
|
||||
|
||||
|
|
@ -135,7 +135,7 @@ Installation
|
|||
- Copy host-rules into /etc/init.d/ and make sure to chmod +x host-rules.
|
||||
- Run 'chkconfig host-rules on' to add the init script to start up.
|
||||
- Copy vif_rules.py into /etc/xensource/scripts
|
||||
- Patch /etc/xensource/scripts/vif using the supplied patch file. It may vary
|
||||
- Patch /etc/xensource/scripts/vif using the supplied patch file. It may vary
|
||||
for different versions of XenServer but it should be pretty self explanatory.
|
||||
It calls the vif_rules.py script on domain creation and tear down.
|
||||
- Run '/etc/init.d/host-rules start' to start up the host based rules.
|
||||
|
|
@ -143,4 +143,3 @@ Installation
|
|||
JSON is in place.
|
||||
- You can check to see if the rules are in place with: iptables --list,
|
||||
arptables --list, or ebtables --list
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue