- Okay, so now let's take a look at a demo
of creating and applying a network access control list.
Here in the VPC console,
we have, we're taking a look at the subnets
that we created earlier.
And these are the two subnets
that belong to our web applications VPC.
And earlier, we enabled routing to the internet
for our load balancing subnet.
And again, if we take a look at that route table,
we'll see here that this is the subnet
that is routed to the internet.
And so we're going to build on that by creating
and applying a network access control list,
as a firewall for the subnet.
So let's go down to, down below here under security,
and we'll take a look at network access control lists.
And you'll see that we do have one,
and it is currently associated with two subnets.
And this one is the default
network access control list, or NACL.
And if we look at the inbound rules,
you can see that it allows
all traffic from everywhere, right?
So we're allowing all traffic on all protocols
on all ports from everywhere.
And if we look at the outbound rules,
we will see the same thing.
All traffic is allowed on all protocols, all ports,
from, going to anywhere,
within our VPC.
So we want to tighten the security around that.
And we're going to create
a NACL specifically for the load balancing subnet.
Now there are different ways that you could go about it.
If you have network engineers on your team,
and they have a particular way of doing things, that's fine.
What I'm showing you is the typical way that I go about
applying security at the network level.
So we're going to create a new one.
And here, I'm going to call this one public traffic.
(keyboard clicking)
Actually let's call it load balancing public traffic,
because we might end up creating other public subnets
for other purposes.
We may create another public subnet
specifically for Bastion hosts.
And then that would get its own NACL
to tailor the firewalls for those ports.
And you may have another public subnet specifically for
proxies or some other purpose.
But here, my approach,
and it's not the approach that you have to use,
but my approach is to
create a subnet for a functional purpose.
And this particular purpose is load balancing.
And then of course we will choose the VPC,
and that one we'll go web apps.
We'll go ahead and create that network ACL.
And here, you can see that
it is currently not associated with any subnets,
but we will do that here momentarily.
Let's first take a look at the rules.
You'll notice here that the only rules we have so far
is the only, the deny rule.
So creating a new
NACL is completely closed by default,
both inbound and outbound.
It's only the default NACL that allows
all inbound and all outbound.
So the default NACL
you could think of as being insecure, by default.
And Amazon does that because they realize that
a lot of users of VPC are perhaps not at a level where they
understand enough to go and make modifications to the NACL,
where they can more easily make those modifications
at the security group.
But Amazon does recommend
that we make use of NACLs and security groups.
And so it just takes a little more education.
So for our load balancing, inbound rules are really easy.
If we think about what our load balancer is doing,
what ports really need to be open,
inbound, from the internet?
So if we remember what we talked about earlier,
then, for our load balancer,
receiving traffic from the internet,
we really are only receiving on port 80 and 443.
But our load balancer, unless you're doing something
with some other kind of proxy or whatever,
the load, for web applications,
the load balancer really has no business,
it has no real need to listen on any other port, right?
If you're doing traditional web applications,
where your client is expecting
to be able to connect on port 80 and 443,
then that's what our load balancer will listen on.
It doesn't need to listen on port 22.
So we don't need port 22 to be open.
It's not going to listen on port 3306,
so we don't need that port to be open, right?
And so, we're going to say, let's start with rule 100.
And rules are evaluated in order,
starting from the lowest rule.
So you can always override a previous rule
by creating a new rule at a higher level.
So we're going to say, we're going to listen on
http, and we can scroll down here, http, from everywhere.
We want to be open to the entire internet,
if we are offering some type of a web application
available to the public at large.
And then we could add rule 110.
And the reason that I go to 110 is so that I have room
to place other sort of custom rules
between rule 100 and 110, in order to make,
if I need to make any kind of modifications
to block certain traffic.
And so there, we're going to go down here and choose https.
Again, coming from anywhere.
So we're allowing port 80 and 443
to come inbound from anywhere on the internet.
We'll go ahead and save that.
And so now you can see, if we follow these rules,
the first rule says that we allow port 80 from anywhere,
TCP, not UDP,
not ICMP,
but TCP port 80,
TCP port 443.
And then the fallback rule here, this asterisk,
if you were to look under the hood,
then the number for that would be 32768, right?
So that's as high as they go.
And so that just means
if it didn't match one of these two rules,
then, everything else is denied, right?
So that means port 22, port 3306, port 3389, 5432,
port 21, all of these things will be automatically denied.
So we've already closed the surface attack area.
And then of course, now we need to open outbound rules.
With NACLs, if we don't have any,
because NACLs are stateless, they don't recognize
responses as being responses, then we have to
explicitly open outbound rules.
So we'll go ahead and edit the outbound rules.
And if you remember what we talked about earlier,
in a previous discussion,
the load balancer will receive a request
on say port 80 or 443,
and then it will send a response back
on what we call an ephemeral port.
And if you read the documentation
on load balancers, elastic load balancers,
the load balance, the documentation will tell you
that the ephemeral range for that,
for the load balancer is
1024 through 65535.
Now for anyone who may have a background in networking,
and understand a bit more about ephemeral ports,
then you will know that there are different ranges
for different, and there are different standard ranges,
depending on what operating system that you're using, right?
Windows may have a particular range,
Ubuntu might have a particular range,
but none of that applies here.
The load balancer itself has its own range.
And it will send those responses out
on any one of these ports, 1024 through 65535.
And I suspect that Amazon opens such a wide range of ports
mainly to give the load balancer the ability to open
a larger number of simultaneous connections.
And so we are allowing outbound
TCP traffic on any of these ephemeral ports
to anywhere on the internet.
And we'll go ahead and save that.
And so, this destination here,
all zeroes, means all IP addresses,
including the 10.000, which is the range of our VPC.
So this rule actually satisfies two things.
It satisfies the need for the load balancer
to send responses back to our end user,
and it also satisfies the need for our load balancer
to initiate connections to our backend instances.
And so if you remember what we talked about earlier,
a common pattern is to have your backend instance
listen on a non-privileged port,
which is anything above 1023, right?
So anything below 1024 would be considered a privileged port
that would require root-level access to open, right?
So a common pattern is to have applications listen
on say port 8080, or port 3,000 or whatever,
and so, by doing that, this one rule
satisfies both of those needs.
And so now we've opened
just the ports that need to be opened
on the load balancing subnet.
So we'll go to subnet associations.
This is the last very important critical step
in enabling the protection of this NACL.
Right now that particular subnet has no protection.
So let's go ahead and do that.
And we're going to choose this one here,
the load balancing subnet.
We'll go ahead and choose that.
And there you go.
And so now, if we were to, we could go back
and verify that from the subnet's perspective.
If we go back to our subnets,
and we click on load balancing-a,
and then take a look at the network access control list,
we can see that the subnet does recognize that network ACL,
and that we're allowing port 80 and 443 inbound,
from anywhere,
we're allowing
ports 1024 through 655, from anywhere,
outbound, right?
So we can send responses and we can make connections.
But we forgot one thing, right?
For those of us who might be familiar with networking,
you probably recognize that we're missing one
here in our inbound
rules.
So if you remember what we talked about earlier,
if our load balancer is sending,
initiating connections to our backend instance
on say port 8080, our backend instance
will return a response
on an ephemeral port, right?
And so what that means
is that our load balancing network ACL
needs to allow those ephemeral ports inbound as well,
but only from the VPC, not from the internet,
but only from within the VPC.
Let's go back to that network ACL,
and click on inbound rules, right?
So again, just to clarify that,
make sure that we understand what's happening here,
because of this outbound rule,
the load balancer can initiate a new connection
to our backend instances on say port 8080 or port 3,000,
whatever non-privileged port
your applications happen to be running on.
And again, our backend instance will send a response
back to the load balancer on an ephemeral port.
And so we need to open those, right?
So let's go ahead and edit the inbound rules one more time.
We're going to add rule number 120, TCP, ports 1024
through 65535.
Now, in this particular case,
your application on that particular operating system
would determine the range of ephemeral ports.
So that range could be much smaller than this.
If you're using, depending on whether you're using
Ubuntu or Debian or Windows or whatever,
there could be a different range.
And so, it could be a range like
32768 through 60,000, right?
I would point you to the documentation
for that particular operating system.
But as a general rule of thumb,
we could assume that 1024 through 65535
are valid ephemeral ports, right?
And so, here we don't want these
to be open from the internet.
We only expect this
to receive inbound
from our VPC,
because the only ephemeral ports that we should be receiving
are coming from our backend instances,
which are inside our VPC.
And so, we will
put 10.000/16.
So what we're saying is,
ports, these ephemeral ports are allowed
to come into, inbound, into the subnet,
only if they originated from within the VPC.
So if somebody out there on the internet tries to get in
on one of these ephemeral ports,
those packets will be rejected, all right?
So we'll go ahead and save that.
All right, so again let's go back to the subnet,
and take a look at our load balancing subnet,
go to our network ACL, and here we go.
You can see that we have 80 and 443 from the internet,
ephemeral ports coming in from the VPC,
meaning our backend instances,
and down here we have ephemeral ports
going outbound to anywhere,
which means the internet and our VPC.
All zeroes mean every IP address,
including our VPC, all right?
So that's how we can create and apply
a network access control list, as a firewall for a subnet.