From 5bdee20eb2cf3d4207181850c636e9a02b500bae Mon Sep 17 00:00:00 2001
From: Joe Amendolara Let’s pinpoint the right candidate VPC where would be possible to enable the Egress Control. Contents
1. Objective
2. Topology#
Go to CoPilot > Cloud Fabric > Gateways > Spoke Gateways and select the aws-us-east-2-spoke1 GW, then click on the VPC/VNet Route Tables tab, then select any of the Private RTBs from the Route Table
field.
You will notice that any private RTBs has its own CIDR pointing to local and the three RFC1918 routes pointing to the Aviatrix Spoke Gateway.
@@ -408,19 +408,19 @@SSH to the aws-us-east-2-spoke1-test1 instance from your laptop. Refer to your POD portal or alternatively, you can retrieve the Public IP from the CoPilot’s Topology.
Then from the aws-us-east-2-spoke1-test1 instance SSH to the aws-us-east-2-spoke1-test2 instance.
Retrieve the Private IP of the aws-us-east-2-spoke1-test2 from the Topology
Go to CoPilot > Security > Egress > Egress VPC/VNets and click on "Enable Local Egress on VPC/VNets"
, then select the aws-us-east-2-spoke1 VPC and click on Add.
Go to CoPilot > Cloud Fabric > Gateways > Spoke Gateways and select the aws-us-east-2-spoke1 GW, then click on the VPC/VNet Route Tables tab, then select any Private RTBs from the Route Table field.
-curl www.football.com
Let’s now check whether the Spoke Gateway could gather NetFlow data after generating the aforementioned curl commands, or not.
Go to CoPilot > Security > Egress > Overview (default)
-You will notice the Message "No Data Found"
. You have successfully activated your egress control without disrupting anything that is sitting on the private subnet, nevertheless, if you want to get the NetFlow information, you need to apply a Distributed Cloud Firewall RULE
, such that you can start evaluate the behaviour of the Private Subnet and get a good understanding of what domains have been reached out from the private subnet.
"Begin using Distributed Cloud Firewall"
, then click on "Begin"
.
-After having enabled the DCF, two Rules will get generated, automatically:
Greendfield-Rule
DefaultDenyAll
= EXPLICIT DENY
Greendfield-Rule
= ALLOW EVERYTHING
DefaultDenyAll
= it’s an EXPLICIT deny
The first rule essentially allows all kind of traffic.
-First and foremost, you have to identify the public subnet where the aws-us-east-2-spoke1-test2 instance resides.
-Go to CoPilot > Cloud Resources > Cloud Assets > Virtual Machines and search for the aws-us-east-2-spoke1-test2 instance on the search field on the right-hand side.
From the outcom you have to pinpoint the Availability Zone
.
Now that you know in what Availability Zone
the private workload resides, you need to select the VPC/VNets & Subnets
TAB and filter out based on the aws-us-east-2-spoke1 VPC.
Identify the Private Subnet
that belongs to the us-east-2a
AZ and copy the corresponding IP Address CIDR
value!
Go to CoPilot > Groups and click on the "+ SmartGroup"
button.
Afterwards, click on the arrow icon inside the "+ Resource Type"
button and select "IP / CIDRs"
.
Ensure these parameters are entered in the pop-up window "Create SmartGroup"
:
Go to CoPilot > Security > Distributed Cloud Firewall > Rules (default tab) and create a new rule clicking on the "+ Rule"
button.
Insert the following parameters
@@ -633,10 +633,10 @@Action: Permit
Do not forget to click on Save In Drafts.
-Click on the Commit button and the rule previously created will work in watch/test mode due to the fact that the enforcement
was turn off.
If the Enforcement slider is On (the default), the rule is enforced in the data plane. If the Enforcement slider is Off, the packets are only watched. This allows you to observe if the traffic impacted by this rule causes any inadvertent issues (such as traffic being dropped).
-Now delete the Greenfield-Rule:
@@ -659,16 +659,16 @@The deletion of the Greenfield-Rule will also cause the deletion of the DefaultDenyAll, because the Egress-Rule was not enforced on the data path, which in turn means that there will be an Invisible Deny Rule
installed on the bottom.
Go to CoPilot > Security > Distributed Cloud Firewall > Monitor and you will see the corresponding logs.
-Important
However, on the SSH client, you will NOT see any outputs, this is because the Rule was not enforced in the Data Path, therefore the traffic is dropped.
Go to CoPilot > Security > Egress > Overview (default)
Now you have finally the egress observability with a full list of domains hit by the EC2 instance inside that private subnet.
-Furthermore, go to CoPilot > Security > Egress > Monitor and from the "VPC/VNets"
drop-down window, select the aws-us-east-2-spoke1 VPC.
You will get a granular Layer 7 visibility that allows you to get a good understanding of how the egress traffic has been consumed and also allows you to help make decisions on how to potentially optimize that.
@@ -728,10 +728,10 @@Let’s move towards a posture where only specific egress domains are in place.
Go to CoPilot > Groups > WebGroups and click on "+ WebGroup"
button.
Create a WebGroup with the following parameters:
@@ -742,10 +742,10 @@Domains/URLs: www.wikipedia.com
Do not forget to click on Save.
-Go to CoPilot > Security > Distributed Cloud Firewall > Rules, click on the pencil button on the right-hand side of the Egress-Rule
.
Now remove the WebGroup "All-Web"
and then select the WebGroup "two-domains"
.
Turn ON the Enforcement
knob.
Do not forget to click on Save In Drafts and then Commit your changes!
-Important
Anywhere (0.0.0.0/0) = Default Route
Publlic Internet = NON-RFC1918 routes
Anywhere (0.0.0.0/0) = Represents all CIDR ranges or IP addresses.
Publlic Internet = Represents non-RFC 1918 IP ranges, or the public Internet
Now you have effectively activated the ZTNA approach.
@@ -788,20 +788,20 @@After committing the changes, the Egress-Rule will be applied to the data path and moreover, the DefaultDenyAll
rule will show up again at the very bottom.
Go to CoPilot > Security > Egress > Monitor and select the Live View from the "Time Period"
field, then select the aws-us-east-2-spoke1 VPC from the "VPC/VNets"
drop-down window.
Only the first two curl commands will be successful!
-You will notice almost instanteously that only www.aviatrix.com and www.wikipedia.com are allowed. Traffic towards www.espn.com and www.football.com will be immediately dropped.
-Let’s now test the IDS feature (i.e. Intrusion Detection System).
Go to CoPilot > Security > Distributed Cloud Firewall > Rules and click on the "+ Rule"
button.
Create a new DCF Rule with the following parameters:
@@ -852,17 +852,17 @@Proceed clicking on the Commit button.
-Note
You will be asked to type again the student password!
-curl -sSL https://raw.githubusercontent.com/0xtf/testmynids.org/master/tmNIDS -o /tmp/tmNIDS && chmod +x /tmp/tmNIDS && /tmp/tmNIDS
The last command will show up a simulator from whom you will be able to launch an attack for testing the "Suricata IDS"
.
Before launching the attack, edit the new DCF rule, clicking on the pencil icon beside the Inspect-DNS rule.
Insert the following parameters and do not forget to click on Save In Drafts:
@@ -917,24 +917,24 @@Now click on the Commit button.
-From the EC2 instance aws-us-east-2-spoke1-test2, type 5 and click enter for launching a malicious attack, specifically the attack will try to establish a connection towards a TOR server.
-Now go to CoPilot > Security > Distributed Cloud Firewall > Detected Intrusions, and you will be able to find indicators that detected that attempt to contact a TOR server, through a DNS request.
@@ -942,17 +942,17 @@If you do not see the logs immediately, click on the refresh button
-Click on any Timestamps to get additional insight on that specific attack.
-