ungleich-staticcms/content/u/blog/how-to-build-an-openstack-alternative-step-2-secure-the-network/contents.lr

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
    }
```