WEBVTT 00:00:00.940 --> 00:00:01.620 In this demo, 00:00:01.620 --> 00:00:03.570 we will learn how to leverage on VyOS to roll out a network 00:00:03.570 --> 00:00:08.560 segmentation and segregation strategy. 00:00:09.340 --> 00:00:15.370 In this scenario, we will use the VLANs and firewall as technical enablers. 00:00:15.370 --> 00:00:20.630 Let me describe with a functional diagram the current scenario. 00:00:20.630 --> 00:00:23.810 We have three separate subnets. 00:00:23.810 --> 00:00:28.300 Dedicated to the main three groups of endpoint: users, 00:00:28.300 --> 00:00:30.310 applications, and databases. 00:00:30.740 --> 00:00:33.960 Traffic generated from each of the three groups is 00:00:33.960 --> 00:00:36.620 carried by means of dedicated VLAN. 00:00:36.620 --> 00:00:40.460 VLANs are then extended to the router interface. 00:00:41.120 --> 00:00:44.440 Each VLAN is terminated over a dedicated sub‑interface, 00:00:44.440 --> 00:00:48.860 each sub‑interface is the gateway for the related subnet. 00:00:48.860 --> 00:00:52.990 Then, as usual, VyOS router has a second interface, 00:00:52.990 --> 00:00:56.920 which is used as uplinked to internet. 00:00:56.920 --> 00:00:58.870 Finally, let me show you a matrix, 00:00:58.870 --> 00:01:02.940 which clarifies which are the traffic flows allowed 00:01:02.950 --> 00:01:05.550 and not allowed within the scenario. 00:01:06.140 --> 00:01:10.610 For example, a user can talk to application and browse to internet, 00:01:10.610 --> 00:01:16.050 while application can talk to the user only if the user initiated the 00:01:16.050 --> 00:01:19.760 traffic flow and obviously can talk to databases. 00:01:19.960 --> 00:01:24.530 For the sake of simplicity, I did not specify here any protocol and port. 00:01:25.240 --> 00:01:29.350 So keep in mind that we are talking about plain IP connectivity. 00:01:31.340 --> 00:01:34.890 Let me also describe how you can set up a home lab for 00:01:34.890 --> 00:01:38.400 practicing with VyOS in the current scenario. 00:01:38.400 --> 00:01:43.100 We have a laptop configured with VMWare workstation 16, 00:01:43.100 --> 00:01:46.980 with our VyOS router and a virtual machine, 00:01:46.980 --> 00:01:47.710 Ubuntu based. 00:01:47.920 --> 00:01:51.260 Both items are equipped with two interfaces. 00:01:52.040 --> 00:01:53.860 Then we have three containers, 00:01:54.050 --> 00:01:57.970 which simulate our three different endpoints: users, 00:01:57.970 --> 00:01:59.860 application, and databases. 00:01:59.990 --> 00:02:04.050 Traffic from containers is managed over dedicated VLAN 00:02:04.320 --> 00:02:08.100 over VMWare Vmnet0 virtual network. 00:02:08.300 --> 00:02:13.550 The three subnets plus VLANs are extended to the VyOS interface. 00:02:15.440 --> 00:02:19.960 Let's start creating the proper configuration for handling this scenario. 00:02:20.840 --> 00:02:25.160 Please note that all configuration will be done by means of Python scripts. 00:02:26.440 --> 00:02:30.850 The first thing we have to do is to create Ethernet 1 sub‑interfaces. 00:02:31.740 --> 00:02:35.540 I have created a pretty simple Python script where the three main 00:02:35.540 --> 00:02:39.060 commands used to create sub‑interfaces are present. 00:02:39.740 --> 00:02:42.970 Please note the IP‑addressing schema and VLAN 00:02:42.980 --> 00:02:45.300 associated to the different subnets. 00:02:46.040 --> 00:02:49.760 We run the script, and we receive success as a response. 00:02:51.340 --> 00:02:53.690 Then we have to create favorable policy. 00:02:53.690 --> 00:02:56.880 Given the fact that we have to run several commands, 00:02:56.880 --> 00:03:00.660 I broke down the configuration in three Python scripts. 00:03:01.140 --> 00:03:03.540 Let's start with USERS_POLICY. 00:03:03.540 --> 00:03:09.140 First, we have three commands, which create network‑group definitions, 00:03:09.140 --> 00:03:12.660 useful to make the configuration more easy to read. 00:03:13.240 --> 00:03:14.650 Then we have the default policy, 00:03:14.650 --> 00:03:17.780 which states that packet which do not have a match 00:03:17.780 --> 00:03:19.660 with any rules that are dropped. 00:03:20.440 --> 00:03:25.070 Then we have rule 10, which prevents traffic from users to databases, 00:03:25.070 --> 00:03:29.630 rule 20, which allows traffic from users to applications, 00:03:29.630 --> 00:03:34.600 and finally, rule 30, which allows traffic to internet. 00:03:34.600 --> 00:03:37.990 Final command applies this policy to Ethernet 00:03:37.990 --> 00:03:41.350 sub‑interface in the incoming direction. 00:03:42.340 --> 00:03:45.960 We run the script, and we receive success as a response. 00:03:47.340 --> 00:03:50.870 The second script creates the application policy set. 00:03:50.870 --> 00:03:52.070 Rule 20, 00:03:52.070 --> 00:03:56.440 which drops traffic from application to users if traffic 00:03:56.450 --> 00:04:00.240 is originated on the application side, rule 30, 00:04:00.240 --> 00:04:04.050 which allows traffic to the internet and to the databases. 00:04:04.540 --> 00:04:05.010 Finally, 00:04:05.010 --> 00:04:10.060 the rule‑set is applied to Ethernet 1 sub‑interface into the incoming direction. 00:04:10.640 --> 00:04:14.260 We run the script, and we receive success as a response. 00:04:15.740 --> 00:04:21.720 Last script is related to database user policy. It is the shortest. 00:04:21.720 --> 00:04:27.130 Traffic towards databases is accepted only if part of an already 00:04:27.140 --> 00:04:31.550 established traffic flow, otherwise traffic is dropped. 00:04:32.140 --> 00:04:35.560 We run the script, and we receive success as a response. 00:04:36.440 --> 00:04:40.660 Let's do some testing with the three containers to confirm that the current 00:04:40.660 --> 00:04:45.380 configuration coherently implements our security requirements. 00:04:45.390 --> 00:04:47.980 We create our three Docker networks. 00:04:47.990 --> 00:04:52.780 Please note that the parameter ipvlan, which we discussed the in previous 00:04:52.780 --> 00:04:59.680 module, and also note that each network is bound to interface ens37 by 00:04:59.680 --> 00:05:05.170 means of a specific VLAN. Then we run three containers playing the role of 00:05:05.170 --> 00:05:07.550 users, application, and databases. 00:05:07.940 --> 00:05:10.550 Now we open a shell to the user container. 00:05:11.540 --> 00:05:16.560 We do something to confirm that we can reach application. We 00:05:16.560 --> 00:05:21.290 do not reach database, and we reach internet. Now we open a 00:05:21.290 --> 00:05:23.460 shell to the application container. 00:05:24.440 --> 00:05:29.120 We do some ping to confirm that we do not reach users. Traffic is 00:05:29.120 --> 00:05:32.260 allowed only if generated from the user's side. 00:05:32.940 --> 00:05:38.260 We do reach databases, and we reach internet as expected. 00:05:39.640 --> 00:05:42.250 Now we open a shell to the database container. 00:05:42.740 --> 00:05:48.280 We do not ping user, we do not reach application, and we do 00:05:48.280 --> 00:05:51.400 not reach public internet as expected. 00:05:51.550 --> 00:05:54.830 This confirms that our segmentation and segregation 00:05:54.830 --> 00:05:57.160 strategy has been put in place. 00:05:57.640 --> 00:06:00.440 Please note that all configuration could have been 00:06:00.440 --> 00:06:02.760 done by means of a single API call, 00:06:03.140 --> 00:06:07.250 thus confirming the potentiality of the programmatic approach.