112 lines
3.1 KiB
Markdown
112 lines
3.1 KiB
Markdown
title: How to build an OpenStack alternative: Step 2, secure the network
|
|
---
|
|
pub_date: 2020-01-12
|
|
---
|
|
author: ungleich virtualisation team
|
|
---
|
|
twitter_handle: ungleich
|
|
---
|
|
_hidden: no
|
|
---
|
|
_discoverable: no
|
|
---
|
|
abstract:
|
|
Let's secure the VM network
|
|
---
|
|
body:
|
|
|
|
In the second step of building an OpenStack alternative we have a look
|
|
on how to secure the network.
|
|
|
|
In the first step we described [how to setup a
|
|
protoype](how-to-build-an-openstack-alternative-step-1).
|
|
|
|
Note: the name of our OpenStack alternative is
|
|
**uncloud**.
|
|
|
|
## Securing the network - of what?
|
|
|
|
Users should be able to do what they want and not limited in their
|
|
actions. On the other hand, users should be unable to disturb other
|
|
users.
|
|
|
|
## General policy: no firewall
|
|
|
|
So for most of the user created traffic there should not be a firewall
|
|
rule on the virtualisation stack. Users should be free to configure
|
|
their own policies on the VM.
|
|
|
|
## Network types
|
|
|
|
Before applying any security mechanism, we have to think about what
|
|
kind of networks can exist in a cloud environment. We see two types of
|
|
networks:
|
|
|
|
* shared networks - more than one customer is in this network
|
|
* private networks - only one customer has access in this network
|
|
|
|
## Filtering IP address management packets
|
|
|
|
So when we share a network, we don't want one customer to be able to
|
|
assign IP addresses to other customers. Instead IP addresses should
|
|
only be assigned from the operator.
|
|
|
|
This means that we need to prevent rogue
|
|
|
|
* [Router advertisements (IPv6)](https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol)
|
|
* [DHCPv6](https://en.wikipedia.org/wiki/DHCPv6) server answers
|
|
* [DHCPv4](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) server answers
|
|
|
|
In our prototype we are using [nftables instead of
|
|
iptables](https://ungleich.ch/en-us/cms/blog/2018/08/18/iptables-vs-nftables/)
|
|
for firewalling, but the rules can be translated from one to another
|
|
firewall system.
|
|
|
|
To drop router advertisements, we can use the following rule:
|
|
|
|
```
|
|
icmpv6 type nd-router-advert drop
|
|
```
|
|
|
|
To drop DHCPv6 server answers we can use
|
|
|
|
```
|
|
ip6 version 6 udp sport 547 drop
|
|
```
|
|
|
|
And finally to prevent DHCPv4 server anwers, we use
|
|
|
|
```
|
|
ip version 4 udp sport 67 drop
|
|
```
|
|
|
|
Note: while uncloud does not use IPv4 or DHCPv4 to the VMs, a rogue
|
|
DHCPv4 server might still trick other VMs into assigning themself an
|
|
IPv4 address. So we also need to block this one.
|
|
|
|
## Filtering MAC and IP spoofing
|
|
|
|
A VM should not be able to spoof the
|
|
[MAC address](https://en.wikipedia.org/wiki/MAC_address) or
|
|
IP address of another machine. We can achieve this by adding a chain
|
|
specific for each VM network interface:
|
|
|
|
```
|
|
chain vm1 {
|
|
ether saddr != 02:00:f0:a9:c4:4e drop
|
|
ip6 saddr != 2a0a:e5c1:111:888:0:f0ff:fea9:c44e drop
|
|
}
|
|
```
|
|
|
|
This way any incorrect mac address and any incorrect IPv6 source
|
|
address will be blocked. If a customer requested a network for the VM
|
|
(/64 or /48 for instance), it can easily be prepended to the vm1 specific
|
|
chain:
|
|
|
|
```
|
|
chain vm1 {
|
|
ip6 saddr 2a0a:e5c1:111:cafe::/64 accept
|
|
ether saddr != 02:00:f0:a9:c4:4e drop
|
|
ip6 saddr != 2a0a:e5c1:111:888:0:f0ff:fea9:c44e drop
|
|
}
|
|
```
|