In this demo,
we will learn how to leverage on VyOS to roll out a network
segmentation and segregation strategy.
In this scenario, we will use the VLANs and firewall as technical enablers.
Let me describe with a functional diagram the current scenario.
We have three separate subnets.
Dedicated to the main three groups of endpoint: users,
applications, and databases.
Traffic generated from each of the three groups is
carried by means of dedicated VLAN.
VLANs are then extended to the router interface.
Each VLAN is terminated over a dedicated sub‑interface,
each sub‑interface is the gateway for the related subnet.
Then, as usual, VyOS router has a second interface,
which is used as uplinked to internet.
Finally, let me show you a matrix,
which clarifies which are the traffic flows allowed
and not allowed within the scenario.
For example, a user can talk to application and browse to internet,
while application can talk to the user only if the user initiated the
traffic flow and obviously can talk to databases.
For the sake of simplicity, I did not specify here any protocol and port.
So keep in mind that we are talking about plain IP connectivity.
Let me also describe how you can set up a home lab for
practicing with VyOS in the current scenario.
We have a laptop configured with VMWare workstation 16,
with our VyOS router and a virtual machine,
Ubuntu based.
Both items are equipped with two interfaces.
Then we have three containers,
which simulate our three different endpoints: users,
application, and databases.
Traffic from containers is managed over dedicated VLAN
over VMWare Vmnet0 virtual network.
The three subnets plus VLANs are extended to the VyOS interface.
Let's start creating the proper configuration for handling this scenario.
Please note that all configuration will be done by means of Python scripts.
The first thing we have to do is to create Ethernet 1 sub‑interfaces.
I have created a pretty simple Python script where the three main
commands used to create sub‑interfaces are present.
Please note the IP‑addressing schema and VLAN
associated to the different subnets.
We run the script, and we receive success as a response.
Then we have to create favorable policy.
Given the fact that we have to run several commands,
I broke down the configuration in three Python scripts.
Let's start with USERS_POLICY.
First, we have three commands, which create network‑group definitions,
useful to make the configuration more easy to read.
Then we have the default policy,
which states that packet which do not have a match
with any rules that are dropped.
Then we have rule 10, which prevents traffic from users to databases,
rule 20, which allows traffic from users to applications,
and finally, rule 30, which allows traffic to internet.
Final command applies this policy to Ethernet
sub‑interface in the incoming direction.
We run the script, and we receive success as a response.
The second script creates the application policy set.
Rule 20,
which drops traffic from application to users if traffic
is originated on the application side, rule 30,
which allows traffic to the internet and to the databases.
Finally,
the rule‑set is applied to Ethernet 1 sub‑interface into the incoming direction.
We run the script, and we receive success as a response.
Last script is related to database user policy. It is the shortest.
Traffic towards databases is accepted only if part of an already
established traffic flow, otherwise traffic is dropped.
We run the script, and we receive success as a response.
Let's do some testing with the three containers to confirm that the current
configuration coherently implements our security requirements.
We create our three Docker networks.
Please note that the parameter ipvlan, which we discussed the in previous
module, and also note that each network is bound to interface ens37 by
means of a specific VLAN. Then we run three containers playing the role of
users, application, and databases.
Now we open a shell to the user container.
We do something to confirm that we can reach application. We
do not reach database, and we reach internet. Now we open a
shell to the application container.
We do some ping to confirm that we do not reach users. Traffic is
allowed only if generated from the user's side.
We do reach databases, and we reach internet as expected.
Now we open a shell to the database container.
We do not ping user, we do not reach application, and we do
not reach public internet as expected.
This confirms that our segmentation and segregation
strategy has been put in place.
Please note that all configuration could have been
done by means of a single API call,
thus confirming the potentiality of the programmatic approach.