diff --git a/content/u/blog/how-to-build-an-openstack-alternative-step-2-secure-the-network/contents.lr b/content/u/blog/how-to-build-an-openstack-alternative-step-2-secure-the-network/contents.lr
new file mode 100644
index 0000000..b79c832
--- /dev/null
+++ b/content/u/blog/how-to-build-an-openstack-alternative-step-2-secure-the-network/contents.lr
@@ -0,0 +1,112 @@
+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
+    }
+```
diff --git a/content/u/blog/uncloud-next b/content/u/blog/uncloud-next
index 4fc701b..8cbd582 100644
--- a/content/u/blog/uncloud-next
+++ b/content/u/blog/uncloud-next
@@ -1 +1,6 @@
 - how to secure the network
+- rate limiting
+- automating
+- trigger / postgres / etcd
+- metadata!
+- building vm images!