-: Okay.
So, let's have a look at our network ACL's.
To do so, I will go on the left hand side
and there's network ACL's.
And for our sub for VPC,
we have a network ACL here.
This is the default, NACL.
So, it's very important to notice this.
And currently it's default.
So, it's associated with four subnets.
So, we have inbound rules and outbound rules.
And then if we look at the inbound rules,
we allow all traffic on all parts everywhere.
And then there's the last row which was denied,
but it doesn't ever get to effect
because this one goes into effect before.
And then for the outbound rules the same.
So, remember the default, NACL,
always has all traffic,
inbound and outbound authorized,
and the default is going to be associated
with any subnets you're going to create,
hence the name default NACL.
So, now let's go ahead
and have a place or to do so,
I'm going to go into my EC2 instances,
my NAT instance.
Sorry, my Bastion host.
And I'm going to start a HTTP server on it to connect to it.
So, to do so let's connect into our instance,
let's connect,
and I'm going to install HTTPD.
So sudo, yum, install, minus Y, HTTPD.
Then we're going to start the web server.
So I will do,
system,
CTL,
sudo,
system CTL,
enable HTTPD,
and then sudo, system CTL, start HTTPD.
Let's clear the screen.
And then we're going to echo "hello world" into our
var/www/html/index.html
and we'll have sudo for this command.
So let's do sudo,
su,
echo,
hello world into again, this file.
So, this should work right now, so let's try it.
Okay.
So, now the other thing we have to do
is we need to make sure that the Bastion host
has this public instance has HTTP enabled
for the security group.
So, right now we only have 4 22.
So, therefore in the security group rules,
I'm going to edit the inbound rules
and I'm going to add a rule for HTTP
and then from anywhere,
save this rule.
Perfect.
So back into our instance, this is our bastion host,
and I can just click on this IP address right here.
Copy it, open it in a new tab
and I get, "hello world."
So, this is good.
We are able to connect into our server
and it replies "hello world" to us.
So, let's have a look at network ACL's now.
So, if I look into this default NACL,
and look at the inbound rules,
what I'm going to do is I'm going to edit these rules.
And currently we allow all traffic from anywhere, okay,
but we're going to add a new rule.
And the rule number is going to be rule 80
and the type is going to be HTTP,
and it's going to come from anywhere
and we are going to deny it.
So, let's save these changes
and we can sort them by rule number.
So, as you can see,
this rule has precedence over that rule.
So, what do you think is going to happen?
Well, now that we have enabled this inbound rule,
that blocks HTTP traffic.
If I go back to my EC2 instance and refresh this page,
I'm getting, you see, an infinite loading.
So, that means that yes,
there's a timeout
and the NACL acted as a firewall
and blocked my request.
But if I edit my inbound rules
and now the rule number is 140.
Okay, and save this again.
And look again at the inbound rules,
as you can see now,
rule 140 happens after rule 100
and there's a denial.
So, what do think is going to happen?
Well, if I go back and refresh,
I'm accessing my EC2 instance.
So, what's happening is that even though
there was an explicit deny rule,
happening here,
because the rule number 100 had higher precedence
and allowed that specific traffic in,
then it works.
Okay. So, as we can see,
this shows the very important aspects
around the rule numbers. Okay.
And similarly,
I want to show the statelessness of the NACL.
So, if I go into outbound rules
and there's this rule right here,
that allows everything right now,
if I edit it and instead do deny,
well, what is going to happen?
The inbound rule is going to allow my traffic,
but the outbound rule shouldn't.
So, let's go back into my instance, refresh this,
and you can see I'm getting this infinite loading,
because well, my NACL does not allow return traffic,
because it was not explicitly specified in my NACL,
that return traffic was allowed.
So, what's really important to notice is that this is true,
regardless of if the security group of my EC2 instance
did, in fact, allow port 80 in, okay.
So, NACL's and security groups work hand-in-hand together.
And if the security group rules look fine,
that doesn't mean that the network ACL's are fine.
So, this is something else to check
in case of network issues.
So, let me revert this to allow
and do another demo.
Okay, so I'm back into my instance.
This is working now.
And so if we look at the security group rules here,
as we can see, port 80 is allowed on everywhere.
And for outbound rules,
it says allow from everywhere as well,
but let's edit this security group.
So, for the inbound rules, I will not change them.
So, I will keep HTTP on,
but for the outbound rules,
I'm going to edit this rule
and I'm going to just remove it.
And as you can see, now,
we don't allow any outbound from the security group,
but the security group is stateful.
That means that if the traffic is initiated from the outside
and is allowed inbound,
then the return traffic will be authorized as well.
So, let's prove it,
even though there is no outbound rule.
If I refresh this page,
as you can see, this is working,
I can access my EC2 instance.
But if my EC2 instance
was trying to initiate a connection,
for example, not here.
If my EC2 instance was trying to initiate
a connection to Google account, for example,
it would be denied because,
well, there's no outbound rule that specifically allows it.
But if it did allow it,
then the return traffic would be allowed because again,
security groups are stateful,
whereas NACL's are stateless.
So, to make things, everything work again.
And once you have all HTTP from anywhere allowed,
and this is going to restore
these outbound rules on my EC2 instance, okay.
So, it's very important for you to notice
the difference between EC2 security groups
and network ACL's.
But hopefully this was a good demo.
I hope you liked it.
And I will see you in the next lecture.