|
0:00:13
|
In our next section with the transparent firewall, we are going to take a look at the ARP spoofing protection
|
|
0:00:19
|
and the MAC address
|
|
0:00:21
|
learning disbaling
|
|
0:00:24
|
and again where the ARP spoofing is designed to prevent the case
|
|
0:00:27
|
towards someone is sending what is known as the ?? ARP
|
|
0:00:31
|
or an unsolicitated ARP reply
|
|
0:00:34
|
in order to poison the IP address to MAC address mapping
|
|
0:00:38
|
of someone that is one that particular segment
|
|
0:00:42
|
Now in this particular case when we are looking at the diagram
|
|
0:00:45
|
what we would want to do
|
|
0:00:47
|
with the MAC address protection or the ARP protection
|
|
0:00:50
|
is to make sure that the IP address of router3
|
|
0:00:54
|
actually correctly corressponds to whatever the MAC address that is assigned to its length
|
|
0:00:59
|
and the same with router4
|
|
0:01:02
|
So if we look at the command line
|
|
0:01:04
|
on router3 and router4
|
|
0:01:06
|
and we look at the show interface
|
|
0:01:11
|
actually lets look at the show IP address breif first
|
|
0:01:15
|
and the particular interface in question is
|
|
0:01:18
|
fast ethernet 0/1
|
|
0:01:20
|
So if we look at the show interface
|
|
0:01:23
|
fast ethernet 0/1
|
|
0:01:26
|
it says the burned in MAC address
|
|
0:01:28
|
is 0014
|
|
0:01:31
|
f2ifd9e9
|
|
0:01:34
|
Now this is what
|
|
0:01:35
|
if we are to look at router4
|
|
0:01:37
|
and look at the
|
|
0:01:39
|
show ARP
|
|
0:01:42
|
this is what the router4 should be resulting router3's MAC address to
|
|
0:01:48
|
So what we are trying to do with this feature
|
|
0:01:51
|
is to prevent the case
|
|
0:01:53
|
where someone sends an ARP reply
|
|
0:01:56
|
for this address
|
|
0:01:58
|
with a different MAC address
|
|
0:02:00
|
to try to redirect the traffic to them at layer 2
|
|
0:02:04
|
which again is known as a layer 2 man in the middle attack or a mim attack
|
|
0:02:10
|
so from the ASA's perspective, it means to know
|
|
0:02:12
|
what are the particular addresses of router3 and router4
|
|
0:02:16
|
from a layer 3 point of view
|
|
0:02:18
|
So what are the IP addresses
|
|
0:02:20
|
and how do they corresspond to
|
|
0:02:22
|
there MAC address mappings
|
|
0:02:25
|
So we need to take note of these to begin with
|
|
0:02:28
|
Now if we look at the ASA
|
|
0:02:30
|
and look at the show
|
|
0:02:34
|
show ARP
|
|
0:02:36
|
Hey, right now we see that there is nothing in the
|
|
0:02:39
|
the secure entries, because we don't have the feature configured
|
|
0:02:42
|
if we show run all arp
|
|
0:02:45
|
Hey, do you don't think that we have in there is just a basic timeout for arp
|
|
0:02:48
|
for our own local arp cache
|
|
0:02:51
|
but we don't have any other secure entries are configured
|
|
0:02:55
|
So lets say now that we want to
|
|
0:02:57
|
check arps on the inside interface
|
|
0:03:01
|
and I need to know specifically what are the addresses that we are going to check
|
|
0:03:05
|
Now, we know that the router4 is on the inside
|
|
0:03:08
|
Router3 is on the outside
|
|
0:03:10
|
So for the inside link we need this IP address to map to this MAC address
|
|
0:03:15
|
and on the outside router3's respectively
|
|
0:03:19
|
So for arp on the inside
|
|
0:03:22
|
the ip address is router4's
|
|
0:03:27
|
the MAC address or the hardware address is this one
|
|
0:03:33
|
then for the outside
|
|
0:03:35
|
we have the mapping of router3's
|
|
0:03:38
|
IP address to its MAC address
|
|
0:03:43
|
So now we need to decide
|
|
0:03:46
|
if there is a match
|
|
0:03:49
|
against these two addresses the arps are going to be allowing
|
|
0:03:52
|
but what happens if there is not a match
|
|
0:03:55
|
Do we want to allow other arps
|
|
0:03:57
|
to go accross the segment
|
|
0:04:00
|
or do we want to deny them
|
|
0:04:03
|
So, first lets look at the case where
|
|
0:04:05
|
we are just using these static mappings, or when we look at the show arp
|
|
0:04:09
|
we see the specific secure entries that we have configured
|
|
0:04:14
|
So as long as these address are valid
|
|
0:04:16
|
we should be able to send traffic between
|
|
0:04:19
|
router3 and router4 on that LAN
|
|
0:04:22
|
and again this is assuming that we allow the inspection
|
|
0:04:26
|
or of the inside in traffic as well
|
|
0:04:29
|
So at the ACL thats on the inside interface inbound, I need to allow the ICMP
|
|
0:04:34
|
and likewise I will need to allow
|
|
0:04:36
|
my TCP traffic in as well
|
|
0:04:40
|
We could see that there is no problem with the transport
|
|
0:04:43
|
Now if I were to go to my interface here
|
|
0:04:46
|
on router4 which is fast ethernet 0/0
|
|
0:04:50
|
and if I were to change the MAC address
|
|
0:04:53
|
to something that the ASA does not agree with
|
|
0:04:58
|
So lets say I just changed it by 1
|
|
0:05:00
|
character, it normally ends
|
|
0:05:02
|
with a 0 or change this to 1
|
|
0:05:06
|
if we look at the arp cache now
|
|
0:05:09
|
router4 has a new entry for itself, its says my address is now 37b1
|
|
0:05:14
|
as opposed to 37b0 as before
|
|
0:05:18
|
and we should see now when we try send traffic
|
|
0:05:21
|
through the ASA
|
|
0:05:23
|
that this arp
|
|
0:05:25
|
is ultimately going to be denied
|
|
0:05:27
|
Now we may need to clear
|
|
0:05:30
|
the cache
|
|
0:05:33
|
arp and both of them
|
|
0:05:37
|
and
|
|
0:05:40
|
show arp, so actually is allowing the resolution
|
|
0:05:43
|
what I need to do is
|
|
0:05:45
|
I tell to not flood the
|
|
0:05:49
|
the request that I am not matching
|
|
0:05:54
|
so I all also need ?? which is the arp
|
|
0:05:57
|
inspection, so arp inspection, I need it on the inside
|
|
0:06:03
|
I want to enable it
|
|
0:06:06
|
and arp inspection on the
|
|
0:06:08
|
the outside
|
|
0:06:10
|
So I am doing it bidirectionally
|
|
0:06:12
|
by now clear the cache
|
|
0:06:25
|
router4 still has its
|
|
0:06:28
|
.1 address or the d1 address
|
|
0:06:31
|
and lets also look at the debug arp
|
|
0:06:34
|
on the two routers, so we can actually see
|
|
0:06:36
|
the resolution between them
|
|
0:06:40
|
So on 4 lets say clear arp
|
|
0:06:42
|
this is going to refresh the cache
|
|
0:06:46
|
So I send an arp request
|
|
0:06:48
|
for router
|
|
0:06:50
|
3's address
|
|
0:06:51
|
and I got a resolution back in
|
|
0:06:54
|
router
|
|
0:06:55
|
3 likewise sent a request for me
|
|
0:06:59
|
and this was received back in
|
|
0:07:01
|
So the
|
|
0:07:02
|
the asa is running the inspection
|
|
0:07:06
|
but the key is that its not
|
|
0:07:08
|
not flooding the entries that it doesn't match
|
|
0:07:12
|
So what I need to say
|
|
0:07:13
|
in addition to this, is that
|
|
0:07:17
|
I don't want to flood
|
|
0:07:22
|
any of the unknown entries
|
|
0:07:40
|
So we can see now, when router4 is
|
|
0:07:42
|
requesting the mapping for router3's address
|
|
0:07:46
|
the ASA is dropping it in the middle
|
|
0:07:48
|
because this is one that is
|
|
0:07:51
|
not matching
|
|
0:07:53
|
the manual entries that it has, because there is a
|
|
0:07:56
|
there is a mismatch between the
|
|
0:07:58
|
IP address and the MAC address
|
|
0:08:00
|
versus what the ASA actually has configured
|
|
0:08:04
|
so it means that I am not going to flood
|
|
0:08:06
|
those other addresses
|
|
0:08:08
|
now what it should also prevent as well
|
|
0:08:12
|
is if I had a different
|
|
0:08:14
|
IP address
|
|
0:08:16
|
but the correct map address
|
|
0:08:18
|
so if I were to go to this link again
|
|
0:08:21
|
and
|
|
0:08:23
|
I am going to remove the MAC address
|
|
0:08:25
|
change, so no MAC address
|
|
0:08:27
|
but I am going to change my IP
|
|
0:08:29
|
So its something else, to 172.16
|
|
0:08:32
|
.34 lets say .5
|
|
0:08:35
|
what was 4 before
|
|
0:08:42
|
So now if ping 172.16.34.3
|
|
0:08:49
|
I am sending the arp request for router3
|
|
0:08:53
|
if we look at router3
|
|
0:08:55
|
we see that we do not
|
|
0:08:57
|
we are not receiving it in for 4
|
|
0:09:02
|
So its actually doing two separate operations
|
|
0:09:05
|
its making sure that the IP address
|
|
0:09:07
|
is bound to the correct MAC address
|
|
0:09:10
|
and its making sure that the correct
|
|
0:09:12
|
MAC address is bound to the IP address
|
|
0:09:15
|
So its bidirectional
|
|
0:09:17
|
Now its only going to work bidirectionally though
|
|
0:09:20
|
if we add this keyword on - no flood
|
|
0:09:22
|
Hey, this means that for the
|
|
0:09:23
|
unknown entries, the once that do not match this
|
|
0:09:26
|
where we are going to filter the arps
|
|
0:09:30
|
Now what this is not going to prevent though
|
|
0:09:34
|
is someone
|
|
0:09:35
|
not even needing to use the
|
|
0:09:37
|
arp process to begin with
|
|
0:09:39
|
So lets say
|
|
0:09:41
|
that on router4 now
|
|
0:09:43
|
we are going to just create a static arp entry
|
|
0:09:46
|
where we already know what router3's MAC address is supposed to be
|
|
0:09:51
|
So I am router4, will say
|
|
0:09:53
|
arp
|
|
0:09:56
|
that ip address, that MAC address
|
|
0:10:01
|
and this is
|
|
0:10:03
|
an arpa type MAC address
|
|
0:10:07
|
then on
|
|
0:10:09
|
router3
|
|
0:10:12
|
I would need to do the
|
|
0:10:14
|
the reverse mapping for router4
|
|
0:10:17
|
we will say arp
|
|
0:10:21
|
that particular ip address maps to this MAC address
|
|
0:10:31
|
Now from router4
|
|
0:10:33
|
when I send traffic
|
|
0:10:35
|
to router3 so ping 172.16.34.3
|
|
0:10:41
|
actually that is telnet
|
|
0:10:48
|
we could see that this traffic is allowed through
|
|
0:10:51
|
So key point here is that with the apr inspection
|
|
0:10:54
|
its not doing a
|
|
0:10:55
|
packet level filter percent
|
|
0:10:57
|
its simply looking at the
|
|
0:10:59
|
payload of the address resolution protocol request
|
|
0:11:04
|
now what I did here for the second portion, by doing the static aprs
|
|
0:11:08
|
on router4 and router3
|
|
0:11:12
|
I eliminate
|
|
0:11:13
|
eliminated their need to even send the arp request to begin with
|
|
0:11:17
|
because router4 already knows what the MAC address that corressponds to 3 is
|
|
0:11:21
|
and likewise 3 knows with the MAC address that corressponds to 4 is
|
|
0:11:27
|
Now if I were to remove this static mapping
|
|
0:11:36
|
remove the static mapping
|
|
0:11:38
|
we should see that now the traffic flow
|
|
0:11:41
|
is not going to work
|
|
0:11:43
|
because 3 is trying to arp for 4
|
|
0:11:48
|
the reply
|
|
0:11:50
|
that router4 is sending back to 3
|
|
0:11:54
|
does not match with what the ASA
|
|
0:11:57
|
has in its table
|
|
0:11:59
|
So its the correct MAC address, it is the
|
|
0:12:01
|
37b0
|
|
0:12:04
|
but we are replying with the ip address .5
|
|
0:12:08
|
ASA is saying to this
|
|
0:12:09
|
MAC address that really supposed to be the .4 address
|
|
0:12:13
|
So its bidirectional, the ip address to MAC address mapping security
|
|
0:12:17
|
but then also the IP address to the MAC address mapping
|
|
0:12:24
|
but again the issue is that it doesn't prevent this, if someone just
|
|
0:12:26
|
overrides the arp process
|
|
0:12:30
|
its not going to be able to be filter this traffic
|
|
0:12:32
|
because its not a data plane filter process, not a packet filter
|
|
0:12:36
|
its a payload filter of arp
|
|
0:12:41
|
Now this problem is what is solved by MAC address learning feature
|
|
0:12:47
|
Now what we could say
|
|
0:12:49
|
On the asa, if we look at the
|
|
0:12:52
|
show
|
|
0:12:55
|
show MAC address table
|
|
0:12:57
|
inside
|
|
0:12:59
|
and outside
|
|
0:13:03
|
if I know specifically what are the
|
|
0:13:05
|
individual MAC addresses
|
|
0:13:08
|
that are supposed to be on the segment
|
|
0:13:10
|
So if I know router3's address and I know router
|
|
0:13:13
|
4's address
|
|
0:13:16
|
I can specify
|
|
0:13:18
|
that on the inside
|
|
0:13:20
|
this is the only MAC address that is supposed to exists
|
|
0:13:24
|
and then likewise on the outside
|
|
0:13:26
|
this is the only address that is supposed to be exists
|
|
0:13:32
|
this is with the MAC address table
|
|
0:13:35
|
static command
|
|
0:13:37
|
so I could say on the inside
|
|
0:13:41
|
the MAC address of router4, we will look at the show arp
|
|
0:13:45
|
this should be the only one, that is allowed in the
|
|
0:13:48
|
CAM table or the MAC address table
|
|
0:13:51
|
for transparent firewall
|
|
0:13:53
|
then likewise if we look at the
|
|
0:13:56
|
MAC address of router3
|
|
0:14:03
|
this MAC address is going to be
|
|
0:14:06
|
statically on the outside
|
|
0:14:10
|
then I am going to disable
|
|
0:14:14
|
the ability for its learn new addresses on the inside
|
|
0:14:18
|
and to learn new addresses on the outside
|
|
0:14:21
|
so this is stopping that flooding procedure
|
|
0:14:24
|
that your normal transparent bridge is doing
|
|
0:14:26
|
when a frame comes in and it doesn't know what the destination MAC address is
|
|
0:14:30
|
it normally treats that like a broadcast
|
|
0:14:33
|
So, its known as an unknown unicast
|
|
0:14:35
|
where unknown unicast are treated like broadcast
|
|
0:14:38
|
these two statements, MAC learn inside disable, MAC learn outside disable
|
|
0:14:43
|
thats what stopping this behaviour
|
|
0:14:46
|
So now this means
|
|
0:14:48
|
that if
|
|
0:14:48
|
Some did have the wrong MAC address
|
|
0:14:52
|
even if the
|
|
0:14:54
|
MAC address
|
|
0:14:55
|
to IP address mapping was static
|
|
0:14:58
|
So lets say now that
|
|
0:15:00
|
I am listening
|
|
0:15:03
|
router4 has the MAC address
|
|
0:15:06
|
that is abcd
|
|
0:15:10
|
1234
|
|
0:15:13
|
5678
|
|
0:15:16
|
hey this one is valid, so lets say
|
|
0:15:22
|
lets make a base on their from, lets say
|
|
0:15:25
|
this address been able to change some of the digit, so its ends with
|
|
0:15:29
|
abcd
|
|
0:15:35
|
if we look at the show
|
|
0:15:38
|
show run include arp
|
|
0:15:42
|
router4 has the static mapping for 3
|
|
0:15:44
|
So this is how we are getting around the arp filter
|
|
0:15:47
|
of the ASA
|
|
0:15:50
|
then likewise on the way back
|
|
0:15:53
|
router3
|
|
0:15:56
|
is going to have a static mapping for
|
|
0:16:01
|
static mapping for router4
|
|
0:16:04
|
hey, so now they know each others MAC addresses, without having to do
|
|
0:16:07
|
the layer 3 to layer 2 resolution with arp
|
|
0:16:13
|
normally
|
|
0:16:15
|
this would then be able to avail
|
|
0:16:17
|
that arp filter
|
|
0:16:21
|
but now since the asa is saying, I will not allow to associate
|
|
0:16:24
|
new MAC addresses on the interfaces
|
|
0:16:28
|
when this packet goes from 4 to 3
|
|
0:16:32
|
then 3 tries to send it back to 4
|
|
0:16:36
|
the asa doesn't have that MAC address on the CAM table
|
|
0:16:39
|
So the packet is going to be dropped
|
|
0:16:42
|
Now on router3, if we look at the
|
|
0:16:45
|
the debug IP ICMP
|
|
0:16:49
|
and send the ping
|
|
0:16:51
|
we see that the packet is getting from
|
|
0:16:53
|
4 to 3
|
|
0:16:56
|
because the ASA, it already knows, what the MAC address of router3 is
|
|
0:17:00
|
yes I didn't changed that
|
|
0:17:02
|
So the packets comes in
|
|
0:17:04
|
it consults the MAC address table or the CAM table
|
|
0:17:07
|
So its the MAC address of router3 is reachable on the link, so it sends it out.
|
|
0:17:12
|
router 3 sense the reply
|
|
0:17:15
|
its using the MAC address of router4
|
|
0:17:20
|
but the ASA does not have these address
|
|
0:17:23
|
in the CAM table, in the MAC address table
|
|
0:17:30
|
now could even go a step further than this
|
|
0:17:33
|
and filter out arp completely
|
|
0:17:38
|
which we could do with a
|
|
0:17:40
|
layer 2 ether type filter
|
|
0:17:44
|
Now we will talk about some additional ways to do this when we get into layer2 security as well
|
|
0:17:49
|
you can actually apply this to filter catalyst IOS
|
|
0:17:53
|
to say that I have a segment that is
|
|
0:17:56
|
a completely secure from both a layer 2 and a layer 3 arp
|
|
0:18:01
|
and MAC address spoofing protection
|
|
0:18:04
|
where I know exactly whats the IP address, whats the MAC address
|
|
0:18:08
|
I am going to disable MAC learning
|
|
0:18:10
|
but then I am also going to filter the arp
|
|
0:18:12
|
protocol completely
|
|
0:18:14
|
and the way that you would match this
|
|
0:18:17
|
is that in an access list
|
|
0:18:21
|
that is
|
|
0:18:23
|
on ethertype list
|
|
0:18:25
|
to that we are matching in the layer 2 protocol type code
|
|
0:18:29
|
the ethertype for IP arp
|
|
0:18:33
|
is 0/a06
|
|
0:18:38
|
So it actually uses a different layer 2
|
|
0:18:40
|
protocol or a different ethertype
|
|
0:18:43
|
for IP arp versus IP itself
|
|
0:18:46
|
where IP is
|
|
0:18:48
|
0/800
|
|
0:18:50
|
IP arp is 0/806
|
|
0:18:53
|
So if the ASA is configured to actually drop these frames
|
|
0:18:57
|
then there is no way that the devices on the inside
|
|
0:19:00
|
would be able to do an arp resolution for the devices on the outside
|
|
0:19:04
|
or vice-versa
|
|
0:19:05
|
it would be solely based
|
|
0:19:08
|
on the
|
|
0:19:10
|
the static arp entries
|
|
0:19:12
|
that the ASA has
|
|
0:19:14
|
and the
|
|
0:19:16
|
static MAC addresses
|
|
0:19:21
|
which is the
|
|
0:19:24
|
MAC address
|
|
0:19:25
|
mac address -[dash] table
|
|
0:19:29
|
So it knows not only
|
|
0:19:32
|
what is the layer 3
|
|
0:19:33
|
to layer 2 resolution or arp
|
|
0:19:36
|
but also knows specifically where
|
|
0:19:38
|
that particular MAC address is supposed to be located
|
|
0:19:42
|
So once router4
|
|
0:19:45
|
agrees that this is
|
|
0:19:47
|
my correct IP address
|
|
0:19:49
|
that is 172.16.34.4
|
|
0:19:54
|
and I am not modifying the
|
|
0:19:56
|
MAC address, so its back to what the default is
|
|
0:20:01
|
we should we now, the ASA is going to allow the traffic through
|
|
0:20:05
|
because its conforming both to
|
|
0:20:07
|
the
|
|
0:20:09
|
arp request filter
|
|
0:20:12
|
and to the actual MAC addresses that are in the CAM table
|
|
0:20:18
|
Now again documentation wise under the ASA
|
|
0:20:23
|
8.0 configurations
|
|
0:20:26
|
this is going to be under configuring the firewall
|
|
0:20:29
|
then configuring arp inspection and bridging parameters in
|
|
0:20:32
|
transparent mode
|
