Unit 5: Access Control Lists 5.1 Access Control Lists ACL Demos 2

ABOUT THESE VIDEOS

In these videos, you’ll see another way to write a Standard ACL, as well as a look at an Extended ACL.

During the videos, you may want to refer to these illustrations:

Lab Topology

Router 1 Routing Table

Router 2 Routing Table

 

Configuring and Testing a Second Standard ACL

>> Now let's change our ACL to a more specific one.
Just blocking traffic from a single host, 10.1.0.2 and not the entire 10.1.00/16 subnet.
[silence]
I've removed the previous access list 1 and rebuilt it with two statements.
The first looks for a 32 bit match in the IP address 10.1.0.2.
Leaving a wildcard mask in a standard ACL statement means all 32 bits must match.
It's the equivalent of a wildcard mask of 0000
or placing the keyword host before the IP address.
The second statement matches all packets that are not matched by the first statement.
I haven't removed the application of the ACL from interface F0/1.
So the new access list 1 is now automatically applied to interface F0/1
as an outbound list taking the place of the previous access list 1.
From 10.1.0.1, let's once again send the ping to 10.3.0.1.
The ping goes through.
But now after changing my machine's IP address to 10.1.0.2 and sending a ping to 10.3.0.1,
the access control list kicks in and once again, filters the traffic.

 

Configuring and Testing an Extended ACL

Extended ACLs should be placed as close as possible to the source of traffic
because granular filtering is possible, and this prevents letting a packet consume bandwidth,
and processing power, just to be denied later closer to the destination.
It's better to block traffic sooner than later.
Standard ACLs don't allow us to do that, but extended ACLs certainly do.
That's why we're going to be working on router one this time.
In this example, we're going to block HTTP traffic
from ten one zero one headed for ten three zero one.
I don't even need an Apache Web server to be up on running on ten three zero one
for this demo to work, just Wireshark.
We are already in global configuration mode.
So, let's go ahead and configure our extended ACL.
[silence]
Extended ACL statements, like standard ACL statements, begin with access dash list,
then comes a number, this time between one hundred
and one hundred ninety-nine, which specifies an extended ACL.
We're using one oh one.
Then either the word permit or deny, deny in this case.
Following that is a protocol.
By specifying TCP here, we're at this point including anything encapsulated
in a layer four TCP segment.
We're going to loosen that restriction shortly.
Next comes the source IP address and wildcard mask, ten one zero one,
with the wildcard mask of quad zero in this case.
Then the destination IP address and wildcard mask ten three zero one,
with the wildcard mask of quad zero in this case.
Up until this point, any TCP related traffic from ten one zero one headed
for ten three zero one will be blocked.
At the end of the statement, we see the operator EQ equals followed by a port number of eighty.
This means, no, not all TCP traffic will be blocked,
just TCP traffic that has a destination port of eighty.
If this one-line ACL was applied to an interface at this point,
it would block every single piece of traffic.
Packets that don't meet the first statement would match an implicit deny IP any any found
that the bottom of every extended ACL.
So we're going to make sure that doesn't happen, in a similar way that we ended our standard ACL.
Permit IP any any means permit any protocol in the TCP IP suite.
The first any refers to any source IP address and wildcard mask.
The second any refers to any destination IP address and wildcard mask.
Since extended ACLs require a protocol, source IP address, and destination IP address,
we have to write the final line like this.
The only optional parameter for an extended ACL is port.
Now it's time to apply our extended ACL to an interface.
[silence]
We've applied this extended ACL as an inbound ACL on interface F zero slash one,
which is the default gateway of host A. That's as close to the source as you can get.
When traffic leaves host A, ten one zero one, and heads into its default gateway,
the traffic is outbound from the network, but inbounds to the router.
On ten one zero one, I've opened up a browser, and I'm going to try to communicate
with ten three zero one, over port seventy-five.
Port seventy-five is closed on ten three zero one,
which is why we are seeing this message in the browser.
In Wireshark, I've been capturing with a display filter
of IP dot ater equals equals ten three zero one.
We can see that in hopes of going through the TCP three-way handshake,
ten one zero one sends many sins to ten three zero one,
with a destination port of seventy-five.
Ten three zero one sends an RST in response to each of the many sins sent by ten one zero one,
with a source port of seventy-five.
Sound familiar?
We just did the equivalent of a port scan through the browser.
Remember closed ports will always respond to a sin with an RST.
Now on ten one zero one, I'm going to have the browser send traffic
to the default port of eighty of ten three zero one.
There is no message in the browser.
It's just hanging.
In Wireshark, once again, with a display filter of IP dot ater equals equals ten three zero one,
we can see that ten one zero one is attempting the TCP three-way handshake
to ten three zero one, sending sins with a destination port of eighty.
But look at the difference, the traffic is filtered by int F zero slash one,
ten one zero ninety-nine, the default gateway of ten one zero one,
it never gets off the local network.
Therefore, ten three zero one never sends an RST.
It never even gets the SYN.
Our ACL filter TCP traffic from ten one zero one to ten three zero one over port eighty.
Success!

转载于:https://www.cnblogs.com/sec875/articles/10028664.html