For this demonstration,
we are going to look at why it can be important to create a decoy network,
and within that network,
deploy cloud services to see how an adversary might exploit those resources.
Then we will perform an assessment using Prowler that will look at
the configuration of your cloud environment,
specifically looking at services that may be exposed to the internet.
This is an important assessment,
as internet exposed services may be more vulnerable to attack from
any threat actor who has access to the internet.
So why create a decoy network?
Decoy networks can be an effective strategy that can give
security teams advanced warning your organization is being
targeted by threat actors.
They can also deflect attention away from your more
sensitive cloud environments.
A decoy network can be as simple or as complicated as you want,
and it very much depends on the needs of your organization,
and what your organization is the most afraid of.
This demo will not give a step‑by‑step guide to
creating a decoy network in the cloud,
because it really does vary on organizational requirements.
Also,
there are specific Pluralsight courses that cover
cloud infrastructure management.
Let's look at this high‑level design,
which includes some of the core components you would
expect to see in a decoy network.
Firstly, you may want to have a separate cloud account,
and this account is in no way connected with any business environments.
Next, you'll want a separate network.
Here this is represented by a virtual private cloud known as a VPC.
This VPC contains an internet gateway,
which means the network is routable to the internet,
and we need this so our threat actors can find the exposed internet services.
Within the VPC, you could have one or many networks divided into subnets,
and here I'm using one subnet.
And then within the subnet,
you can deploy as many cloud services as required. In this demo,
one of the decoy systems will be a Linux machine with SSH access.
Within your environment, you can have, for example,
a server with exposed database services, or a website that gives the
appearance of being the company human resource system.
When creating decoy systems,
you're only limited by your imagination. And then finally,
you're going to want some method to monitor.
This is usually done through logging events. Again,
logging and monitoring is outside of the scope of this
course, but I will demonstrate logging the connection
attempts to the decoy environment.
You can always monitor for more specific events,
like brute‑force password attempts against a fake HR system, or the
more relevant events based on your requirements.
Okay,
so now let's quickly review for awareness what an example
decoy system looks like within AWS.
This is a Linux system with SSH access,
but it can be anything you want. Looking at my EC2
instance here, we can see it's running.
It has a public IP address, and it's publicly discoverable on the internet.
This is within a VPC instance I have called DecoyNetwork,
and is using a subnet called DecoySubnet1.
Let's look at the security settings for this EC2 instance. I have created
a unique security group called decoyLinuxSSHInstances,
and within that group,
I'm allowing connections to services available on port 22,
and I am allowing any outbound traffic.
So that's the EC2 instance running as a decoy system. I want to
see who is trying to connect to the decoy system because this may
warn me of attackers. To do that,
I have enabled the VPC flow logs for the decoy network.
Those logs are being sent to my CloudWatch service,
and the logs are stored in a log group I have called decoyNetworkLogGroup.
From here, I can search and alert on the logs.
This example I'm using will generate a lot of traffic,
but more specific decoy systems can be created to generate specific
logging and alerting to your own requirements.
Now let's perform an assessment using Prowler. Prowler as an
assessment tool will identify potential security misconfigurations,
just like you've seen in the decoy network.
Prowler will alert on these misconfigurations so that security teams can
assess and take appropriate action to secure. Here, I'm running Prowler to
only check for exposed port 22 inbound access. Prowler will assess each of
the regions within my AWS account,
and you can see the results. Regions where security
misconfigurations are not found are shown as a pass.
One reason to limit an assessment to only the required checks
is that it reduces the time to complete.
Other assessments could be performed using Prowler,
but it's important to focus assessments on the needs of your business.
It's very easy to use Prowler as a tool,
but it's much more time consuming to read through all of the reports.
Thankfully, my example organization is really only concerned about SSH access.
So now we can see some of the results are highlighted in red as a fail.
This means a potential security misconfiguration has been identified.
The security team will need to verify the results, and maybe take
corrective action to update the security group rules.
Also listed in the results is a security group for the decoy network.
This is a useful verification of the Prowler tool,
and you need to make sure this is not corrected.
Otherwise,
the decoy network will no longer function if the security rules are removed.
Okay,
so that concludes this demonstration, how to defend and
assess for internet exposed services.
Next up, we'll look at performing an AWS benchmark assessment using Prowler.