From a45317ab0238d6cf0be01143b08e064b37ed87cb Mon Sep 17 00:00:00 2001 From: Nico Schottelius Date: Sun, 12 Jan 2020 00:23:11 +0100 Subject: [PATCH] add new unpublished blog article --- .../contents.lr | 112 ++++++++++++++++++ content/u/blog/uncloud-next | 5 + 2 files changed, 117 insertions(+) create mode 100644 content/u/blog/how-to-build-an-openstack-alternative-step-2-secure-the-network/contents.lr 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!