As we continue our journey in hardening our Cisco iOS
devices, meaning making them more secure than their default
configurations, we're now going to focus on the data plane.
That's like a user like Bob, who is sending traffic
through the network, not to a network device,
but through the network, for some network service.
And as we continue the data plane discussion,
we're going to use the Cisco iOS hardening guide once again,
and then we have this section for General Data Plane
Hardening, and it has these options.
Now in the documents itself, you expand those,
it will take us to the details for each of them. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it will take us to the details for each of them.
So if an attacker is sending network traffic
into our infrastructure or at our network devices
with an attempt to cause harm, any time
we can drop that traffic or stop that
from being processed by the CPU or stop that traffic
from making further into our network, that's a win.
And source routing is when we are including options in the IP
header which indicate OK, the next hop should be this,
the next hop should be that.
It's like a guided missile.
We don't want the attacker to control or attempt
to control which direction in our infrastructure
a packet will be forwarded and sent. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a packet will be forwarded and sent.
So IP source routing, we'd want to disable that.
It's disabled by default on most iOS devices.
ICMP redirects, which we talked about over
on the control plane, if you don't
need that functionality or those features,
you could disable it, and disable or limit
IP directed broadcasts.
So that is also disabled on most iOS devices by default.
So if this is the, let's say this guy is connected
to the 10.10.1.0 network with a 24-bit mask,
and the attacker sends a packet to 10.10.1.255, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and the attacker sends a packet to 10.10.1.255,
that would be an example of a directed broadcast with
the intent for the attacker to have this router route that
packet here and then like fireworks just explode that
as a broadcast for the entire network segment based on this
last octet being 255.
Routers have that disabled by default.
But if for some reason somebody wanted to enable it,
that's a bad idea.
So that's why this in the general data plane hardening.
Some of these options go back many, many versions
when they were on by default. And that
may be why they're still included in this hardening WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
may be why they're still included in this hardening
guide.
In the previous sections regarding hardening,
it referred to access control list as an option,
and that still is applicable here.
Filtering packets on the data plane,
and that can include filtering packets of certain protocol
types like ICMP or fragments that we
don't want to allow to go into our network,
or filtering out IP packets based on options.
So we have several different ways
of dropping packets that have options,
and an ACL is yet another one.
And then we have a whole section for anti-spoofing protections.
So let's imagine that this attacker sources a packet from WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's imagine that this attacker sources a packet from
10.10.1., and we'll call it 50.
So if he sources a packet from that,
and he's sending it to 10.10.2.50,
so the router gets the packet.
It looks at the destination address and says,
oh, I know how to get there, it's all cached.
It re-encapsulates, does the [INAUDIBLE] it needs to,
and forwards it on to the destination at .50.
But the router isn't checking the source address.
He's just focusing on the destination address
when he's making forwarding decisions.
But we can actually change his behavior.
One of those ways is Unicast RPF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
One of those ways is Unicast RPF.
Unicast RPF, reverse path forwarding check,
basically says this.
When this packet comes in, the router
takes an extra moment to take a look at the source address.
And it says, OK, myself, if I was
going to forward a packet to that source
address, which interface would I use?
Would it be this one here?
The one it came in on?
And if the answer is no, the interface will be over here,
the router says with this RPF check enabled,
I'm dropping this packet.
Because this source address doesn't
seem to be coming in on the same interface which I would
use to reach that network.
And there are several options for that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And there are several options for that
as well, including saying, OK Mr. R1,
if you have that route anywhere in your routing table it's OK.
Because we are going to have some situations where there's
asymmetrical routing, where traffic
goes one way through the network and replies
go back a different path.
So again you'd want to check this and test
this in your environment before you
say, oh, that's a great idea, let's it everywhere.
Because if you're stopping legitimate traffic
it's no longer a really great security
feature because it's impacting our business that we want
accomplished on that network.
And other features that help stop spoofing
would include IP Source Guard, port security, dynamic ARP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
would include IP Source Guard, port security, dynamic ARP
inspection, and anti-spoofing ACL.
So an anti-spoofing ACL would be something like, OK,
we're going to deny anything, says the router,
that's coming from 10.10.2 network,
and we'll apply that inbound right here,
except we do that for the entire infrastructure.
And that way with this ACL, any traffic that
is appearing to come from one of our internal networks,
if it shows up as a source address here,
the ACL can drop it and not even allow it into our network.
And then we have further discussions here
about limiting CPU impact of the data plane. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
about limiting CPU impact of the data plane.
This is the same concept as far as the control plane.
We simply want to make sure that any traffic where
the CPU itself on the router or the device,
where it has to get directly involved and process it,
we want to make sure it's not malicious or bogus traffic
that's just trying to take that CPU or that device
down and not make it serviceable.
So once again here it lists control plane protection.
We have filtering based on IP options,
filtering traffic based on TTLs being
too low to succeed through our network,
and just killing them at the edge.
And regarding traffic identification and traceback, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And regarding traffic identification and traceback,
NetFlow is a fantastic tool, not just for capacity planning
and looking for problems, but also security issues.
If we notice that, hey, all of a sudden we
have like 10 times the amount of traffic
every midnight going out to some country
that may not be friendly, we could
identify that with NetFlow and then take action.
So becoming aware of what's going on on our network
and having systems that inform us is critical.
And then regarding access control for the data plane,
we have lots of options for implementing access control.
We have VLAN maps and port-based ACLs and layer 2 ACLs WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We have VLAN maps and port-based ACLs and layer 2 ACLs
is based on Mac addresses.
And we also have, for security we have private VLANs.
So we have separate videos on private VLANs
as a great way of taking one IP address space
and controlling what traffic between ports in that address
space are allowed to communicate.
And another option I'd also add here as
far as hardening our devices would be the use of VRF-Lite.
Because with VRF-Lite, you can also segment routing tables
so that if you want to have a certain group of users
never reach another part of the network, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
never reach another part of the network,
if you put them in a separate routing table,
you don't need an access list.
Because users who are part of a VRF
called 1 and other users who are part of a VRF called 2,
they'll never be able to route between each other
unless we do some things like route leaking.
But by default we don't need an access control list or anything
else because these VRFs, these routing tables
are completely separate from each other.
So that's yet another great technique
for hardening and making our environments more
secure without the need for ACLs because we're completely
separating the routing tables between the two groups. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
separating the routing tables between the two groups.
In this video our focus has been on hardening Cisco iOS devices
with a specific focus on the data plane.
In the next video, I'd like to share with you a checklist
that we can use as we're building our policy regarding
how we want to harden these devices.
And we'll take a look at that checklist
in detail in the next video.
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you
and I'd like to thank you for viewing.