WEBVTT

1
00:00.000 --> 00:00.630 align:middle line:84%


2
00:00.630 --> 00:03.630 align:middle line:90%
As we continue our journey
in hardening our Cisco iOS

3
00:03.630 --> 00:06.600 align:middle line:90%
devices, meaning making them
more secure than their default

4
00:06.600 --> 00:09.870 align:middle line:90%
configurations, we're now going
to focus on the data plane.

5
00:09.870 --> 00:12.180 align:middle line:90%
That's like a user like
Bob, who is sending traffic

6
00:12.180 --> 00:14.340 align:middle line:90%
through the network,
not to a network device,

7
00:14.340 --> 00:17.160 align:middle line:90%
but through the network,
for some network service.

8
00:17.160 --> 00:19.230 align:middle line:90%
And as we continue the
data plane discussion,

9
00:19.230 --> 00:22.170 align:middle line:90%
we're going to use the Cisco
iOS hardening guide once again,

10
00:22.170 --> 00:24.360 align:middle line:90%
and then we have this section
for General Data Plane

11
00:24.360 --> 00:26.463 align:middle line:90%
Hardening, and it
has these options.

12
00:26.463 --> 00:28.380 align:middle line:90%
Now in the documents
itself, you expand those,

13
00:28.380 --> 00:30.670 align:middle line:90%
it will take us to the
details for each of them.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:28.380 --> 00:30.670 align:middle line:90%
it will take us to the
details for each of them.

14
00:30.670 --> 00:33.570 align:middle line:90%
So if an attacker is
sending network traffic

15
00:33.570 --> 00:36.870 align:middle line:90%
into our infrastructure
or at our network devices

16
00:36.870 --> 00:39.060 align:middle line:90%
with an attempt to
cause harm, any time

17
00:39.060 --> 00:41.070 align:middle line:90%
we can drop that
traffic or stop that

18
00:41.070 --> 00:43.650 align:middle line:90%
from being processed by the
CPU or stop that traffic

19
00:43.650 --> 00:46.260 align:middle line:90%
from making further into
our network, that's a win.

20
00:46.260 --> 00:49.140 align:middle line:90%
And source routing is when we
are including options in the IP

21
00:49.140 --> 00:51.723 align:middle line:90%
header which indicate OK,
the next hop should be this,

22
00:51.723 --> 00:52.890 align:middle line:84%
the next hop should be that.

23
00:52.890 --> 00:54.210 align:middle line:84%
It's like a guided missile.

24
00:54.210 --> 00:56.730 align:middle line:90%
We don't want the attacker
to control or attempt

25
00:56.730 --> 00:59.000 align:middle line:90%
to control which direction
in our infrastructure

26
00:59.000 --> 01:01.290 align:middle line:90%
a packet will be
forwarded and sent.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
00:59.000 --> 01:01.290 align:middle line:90%
a packet will be
forwarded and sent.

27
01:01.290 --> 01:04.050 align:middle line:90%
So IP source routing,
we'd want to disable that.

28
01:04.050 --> 01:07.590 align:middle line:90%
It's disabled by default
on most iOS devices.

29
01:07.590 --> 01:10.050 align:middle line:90%
ICMP redirects, which
we talked about over

30
01:10.050 --> 01:12.080 align:middle line:90%
on the control
plane, if you don't

31
01:12.080 --> 01:13.830 align:middle line:90%
need that functionality
or those features,

32
01:13.830 --> 01:16.260 align:middle line:90%
you could disable it,
and disable or limit

33
01:16.260 --> 01:18.120 align:middle line:84%
IP directed broadcasts.

34
01:18.120 --> 01:21.700 align:middle line:90%
So that is also disabled on
most iOS devices by default.

35
01:21.700 --> 01:23.910 align:middle line:90%
So if this is the, let's
say this guy is connected

36
01:23.910 --> 01:28.210 align:middle line:90%
to the 10.10.1.0 network
with a 24-bit mask,

37
01:28.210 --> 01:33.402 align:middle line:90%
and the attacker sends
a packet to 10.10.1.255,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:28.210 --> 01:33.402 align:middle line:90%
and the attacker sends
a packet to 10.10.1.255,

38
01:33.402 --> 01:35.610 align:middle line:90%
that would be an example of
a directed broadcast with

39
01:35.610 --> 01:38.070 align:middle line:90%
the intent for the attacker
to have this router route that

40
01:38.070 --> 01:41.790 align:middle line:90%
packet here and then like
fireworks just explode that

41
01:41.790 --> 01:44.640 align:middle line:90%
as a broadcast for the entire
network segment based on this

42
01:44.640 --> 01:46.380 align:middle line:84%
last octet being 255.

43
01:46.380 --> 01:48.340 align:middle line:90%
Routers have that
disabled by default.

44
01:48.340 --> 01:50.940 align:middle line:90%
But if for some reason
somebody wanted to enable it,

45
01:50.940 --> 01:51.720 align:middle line:84%
that's a bad idea.

46
01:51.720 --> 01:54.360 align:middle line:90%
So that's why this in the
general data plane hardening.

47
01:54.360 --> 01:56.610 align:middle line:90%
Some of these options go
back many, many versions

48
01:56.610 --> 01:58.205 align:middle line:90%
when they were on
by default. And that

49
01:58.205 --> 02:00.330 align:middle line:90%
may be why they're still
included in this hardening
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
01:58.205 --> 02:00.330 align:middle line:90%
may be why they're still
included in this hardening

50
02:00.330 --> 02:00.890 align:middle line:84%
guide.

51
02:00.890 --> 02:03.030 align:middle line:90%
In the previous sections
regarding hardening,

52
02:03.030 --> 02:05.700 align:middle line:90%
it referred to access
control list as an option,

53
02:05.700 --> 02:07.710 align:middle line:90%
and that still is
applicable here.

54
02:07.710 --> 02:09.853 align:middle line:90%
Filtering packets
on the data plane,

55
02:09.853 --> 02:12.270 align:middle line:90%
and that can include filtering
packets of certain protocol

56
02:12.270 --> 02:14.850 align:middle line:90%
types like ICMP or
fragments that we

57
02:14.850 --> 02:17.310 align:middle line:90%
don't want to allow to
go into our network,

58
02:17.310 --> 02:20.585 align:middle line:90%
or filtering out IP
packets based on options.

59
02:20.585 --> 02:21.960 align:middle line:90%
So we have several
different ways

60
02:21.960 --> 02:23.730 align:middle line:90%
of dropping packets
that have options,

61
02:23.730 --> 02:25.710 align:middle line:84%
and an ACL is yet another one.

62
02:25.710 --> 02:28.680 align:middle line:90%
And then we have a whole section
for anti-spoofing protections.

63
02:28.680 --> 02:32.130 align:middle line:90%
So let's imagine that this
attacker sources a packet from
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

63
02:28.680 --> 02:32.130 align:middle line:90%
So let's imagine that this
attacker sources a packet from

64
02:32.130 --> 02:36.180 align:middle line:84%
10.10.1., and we'll call it 50.

65
02:36.180 --> 02:38.150 align:middle line:90%
So if he sources a
packet from that,

66
02:38.150 --> 02:41.920 align:middle line:90%
and he's sending
it to 10.10.2.50,

67
02:41.920 --> 02:43.170 align:middle line:84%
so the router gets the packet.

68
02:43.170 --> 02:44.620 align:middle line:90%
It looks at the destination
address and says,

69
02:44.620 --> 02:46.632 align:middle line:90%
oh, I know how to get
there, it's all cached.

70
02:46.632 --> 02:48.840 align:middle line:90%
It re-encapsulates, does
the [INAUDIBLE] it needs to,

71
02:48.840 --> 02:51.178 align:middle line:90%
and forwards it on to
the destination at .50.

72
02:51.178 --> 02:53.220 align:middle line:90%
But the router isn't
checking the source address.

73
02:53.220 --> 02:54.720 align:middle line:90%
He's just focusing on
the destination address

74
02:54.720 --> 02:55.950 align:middle line:90%
when he's making
forwarding decisions.

75
02:55.950 --> 02:57.617 align:middle line:90%
But we can actually
change his behavior.

76
02:57.617 --> 03:00.010 align:middle line:90%
One of those ways
is Unicast RPF.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

76
02:57.617 --> 03:00.010 align:middle line:90%
One of those ways
is Unicast RPF.

77
03:00.010 --> 03:02.580 align:middle line:90%
Unicast RPF, reverse
path forwarding check,

78
03:02.580 --> 03:03.420 align:middle line:84%
basically says this.

79
03:03.420 --> 03:05.070 align:middle line:90%
When this packet
comes in, the router

80
03:05.070 --> 03:08.000 align:middle line:90%
takes an extra moment to take
a look at the source address.

81
03:08.000 --> 03:10.530 align:middle line:90%
And it says, OK,
myself, if I was

82
03:10.530 --> 03:12.420 align:middle line:90%
going to forward a
packet to that source

83
03:12.420 --> 03:14.247 align:middle line:90%
address, which
interface would I use?

84
03:14.247 --> 03:15.330 align:middle line:84%
Would it be this one here?

85
03:15.330 --> 03:16.290 align:middle line:84%
The one it came in on?

86
03:16.290 --> 03:19.510 align:middle line:90%
And if the answer is no, the
interface will be over here,

87
03:19.510 --> 03:21.660 align:middle line:90%
the router says with
this RPF check enabled,

88
03:21.660 --> 03:22.890 align:middle line:84%
I'm dropping this packet.

89
03:22.890 --> 03:25.050 align:middle line:90%
Because this source
address doesn't

90
03:25.050 --> 03:27.570 align:middle line:90%
seem to be coming in on the
same interface which I would

91
03:27.570 --> 03:28.687 align:middle line:84%
use to reach that network.

92
03:28.687 --> 03:30.270 align:middle line:90%
And there are several
options for that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
03:28.687 --> 03:30.270 align:middle line:90%
And there are several
options for that

93
03:30.270 --> 03:33.000 align:middle line:90%
as well, including
saying, OK Mr. R1,

94
03:33.000 --> 03:35.640 align:middle line:90%
if you have that route anywhere
in your routing table it's OK.

95
03:35.640 --> 03:37.590 align:middle line:90%
Because we are going to have
some situations where there's

96
03:37.590 --> 03:39.210 align:middle line:90%
asymmetrical routing,
where traffic

97
03:39.210 --> 03:41.250 align:middle line:90%
goes one way through
the network and replies

98
03:41.250 --> 03:42.670 align:middle line:84%
go back a different path.

99
03:42.670 --> 03:44.430 align:middle line:90%
So again you'd want
to check this and test

100
03:44.430 --> 03:46.080 align:middle line:90%
this in your
environment before you

101
03:46.080 --> 03:48.840 align:middle line:90%
say, oh, that's a great
idea, let's it everywhere.

102
03:48.840 --> 03:50.917 align:middle line:90%
Because if you're stopping
legitimate traffic

103
03:50.917 --> 03:52.500 align:middle line:90%
it's no longer a
really great security

104
03:52.500 --> 03:55.380 align:middle line:90%
feature because it's impacting
our business that we want

105
03:55.380 --> 03:57.000 align:middle line:84%
accomplished on that network.

106
03:57.000 --> 03:58.860 align:middle line:90%
And other features
that help stop spoofing

107
03:58.860 --> 04:02.040 align:middle line:90%
would include IP Source Guard,
port security, dynamic ARP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
03:58.860 --> 04:02.040 align:middle line:90%
would include IP Source Guard,
port security, dynamic ARP

108
04:02.040 --> 04:04.770 align:middle line:90%
inspection, and
anti-spoofing ACL.

109
04:04.770 --> 04:07.360 align:middle line:90%
So an anti-spoofing ACL
would be something like, OK,

110
04:07.360 --> 04:09.990 align:middle line:90%
we're going to deny
anything, says the router,

111
04:09.990 --> 04:12.733 align:middle line:90%
that's coming from
10.10.2 network,

112
04:12.733 --> 04:14.400 align:middle line:90%
and we'll apply that
inbound right here,

113
04:14.400 --> 04:16.480 align:middle line:90%
except we do that for the
entire infrastructure.

114
04:16.480 --> 04:19.500 align:middle line:90%
And that way with this
ACL, any traffic that

115
04:19.500 --> 04:22.079 align:middle line:90%
is appearing to come from
one of our internal networks,

116
04:22.079 --> 04:23.820 align:middle line:90%
if it shows up as a
source address here,

117
04:23.820 --> 04:26.672 align:middle line:90%
the ACL can drop it and not
even allow it into our network.

118
04:26.672 --> 04:28.380 align:middle line:90%
And then we have
further discussions here

119
04:28.380 --> 04:30.820 align:middle line:90%
about limiting CPU
impact of the data plane.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
04:28.380 --> 04:30.820 align:middle line:90%
about limiting CPU
impact of the data plane.

120
04:30.820 --> 04:33.330 align:middle line:90%
This is the same concept as
far as the control plane.

121
04:33.330 --> 04:35.640 align:middle line:90%
We simply want to make
sure that any traffic where

122
04:35.640 --> 04:38.340 align:middle line:90%
the CPU itself on the
router or the device,

123
04:38.340 --> 04:40.590 align:middle line:90%
where it has to get directly
involved and process it,

124
04:40.590 --> 04:43.170 align:middle line:90%
we want to make sure it's not
malicious or bogus traffic

125
04:43.170 --> 04:45.330 align:middle line:90%
that's just trying to take
that CPU or that device

126
04:45.330 --> 04:47.190 align:middle line:90%
down and not make
it serviceable.

127
04:47.190 --> 04:50.040 align:middle line:90%
So once again here it lists
control plane protection.

128
04:50.040 --> 04:52.380 align:middle line:90%
We have filtering
based on IP options,

129
04:52.380 --> 04:54.390 align:middle line:90%
filtering traffic
based on TTLs being

130
04:54.390 --> 04:56.130 align:middle line:90%
too low to succeed
through our network,

131
04:56.130 --> 04:58.020 align:middle line:90%
and just killing
them at the edge.

132
04:58.020 --> 05:00.420 align:middle line:90%
And regarding traffic
identification and traceback,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

132
04:58.020 --> 05:00.420 align:middle line:90%
And regarding traffic
identification and traceback,

133
05:00.420 --> 05:03.990 align:middle line:90%
NetFlow is a fantastic tool,
not just for capacity planning

134
05:03.990 --> 05:06.150 align:middle line:90%
and looking for problems,
but also security issues.

135
05:06.150 --> 05:07.900 align:middle line:90%
If we notice that,
hey, all of a sudden we

136
05:07.900 --> 05:10.200 align:middle line:90%
have like 10 times
the amount of traffic

137
05:10.200 --> 05:12.300 align:middle line:90%
every midnight going
out to some country

138
05:12.300 --> 05:14.220 align:middle line:90%
that may not be
friendly, we could

139
05:14.220 --> 05:16.990 align:middle line:90%
identify that with NetFlow
and then take action.

140
05:16.990 --> 05:19.410 align:middle line:90%
So becoming aware of what's
going on on our network

141
05:19.410 --> 05:22.060 align:middle line:90%
and having systems that
inform us is critical.

142
05:22.060 --> 05:24.570 align:middle line:90%
And then regarding access
control for the data plane,

143
05:24.570 --> 05:27.430 align:middle line:90%
we have lots of options for
implementing access control.

144
05:27.430 --> 05:31.020 align:middle line:90%
We have VLAN maps and
port-based ACLs and layer 2 ACLs
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

144
05:27.430 --> 05:31.020 align:middle line:90%
We have VLAN maps and
port-based ACLs and layer 2 ACLs

145
05:31.020 --> 05:32.450 align:middle line:84%
is based on Mac addresses.

146
05:32.450 --> 05:34.970 align:middle line:90%
And we also have, for security
we have private VLANs.

147
05:34.970 --> 05:37.080 align:middle line:90%
So we have separate
videos on private VLANs

148
05:37.080 --> 05:40.170 align:middle line:90%
as a great way of taking
one IP address space

149
05:40.170 --> 05:43.540 align:middle line:90%
and controlling what traffic
between ports in that address

150
05:43.540 --> 05:45.550 align:middle line:90%
space are allowed
to communicate.

151
05:45.550 --> 05:47.220 align:middle line:90%
And another option
I'd also add here as

152
05:47.220 --> 05:52.350 align:middle line:90%
far as hardening our devices
would be the use of VRF-Lite.

153
05:52.350 --> 05:55.360 align:middle line:90%
Because with VRF-Lite, you can
also segment routing tables

154
05:55.360 --> 05:58.020 align:middle line:90%
so that if you want to have
a certain group of users

155
05:58.020 --> 06:00.300 align:middle line:90%
never reach another
part of the network,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

155
05:58.020 --> 06:00.300 align:middle line:90%
never reach another
part of the network,

156
06:00.300 --> 06:02.500 align:middle line:90%
if you put them in a
separate routing table,

157
06:02.500 --> 06:03.990 align:middle line:84%
you don't need an access list.

158
06:03.990 --> 06:06.510 align:middle line:90%
Because users who
are part of a VRF

159
06:06.510 --> 06:10.140 align:middle line:90%
called 1 and other users who
are part of a VRF called 2,

160
06:10.140 --> 06:12.210 align:middle line:90%
they'll never be able to
route between each other

161
06:12.210 --> 06:14.043 align:middle line:90%
unless we do some things
like route leaking.

162
06:14.043 --> 06:16.680 align:middle line:90%
But by default we don't need an
access control list or anything

163
06:16.680 --> 06:19.350 align:middle line:90%
else because these VRFs,
these routing tables

164
06:19.350 --> 06:21.708 align:middle line:90%
are completely separate
from each other.

165
06:21.708 --> 06:23.250 align:middle line:90%
So that's yet another
great technique

166
06:23.250 --> 06:25.167 align:middle line:90%
for hardening and making
our environments more

167
06:25.167 --> 06:28.320 align:middle line:90%
secure without the need for
ACLs because we're completely

168
06:28.320 --> 06:30.810 align:middle line:90%
separating the routing tables
between the two groups.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
06:28.320 --> 06:30.810 align:middle line:90%
separating the routing tables
between the two groups.

169
06:30.810 --> 06:34.350 align:middle line:90%
In this video our focus has been
on hardening Cisco iOS devices

170
06:34.350 --> 06:36.985 align:middle line:90%
with a specific focus
on the data plane.

171
06:36.985 --> 06:39.360 align:middle line:90%
In the next video, I'd like
to share with you a checklist

172
06:39.360 --> 06:42.540 align:middle line:90%
that we can use as we're
building our policy regarding

173
06:42.540 --> 06:44.220 align:middle line:90%
how we want to
harden these devices.

174
06:44.220 --> 06:45.845 align:middle line:90%
And we'll take a look
at that checklist

175
06:45.845 --> 06:47.420 align:middle line:84%
in detail in the next video.

176
06:47.420 --> 06:49.210 align:middle line:90%
So I'll see you there
in just a moment.

177
06:49.210 --> 06:51.420 align:middle line:90%
Meanwhile, I hope this has
been informative for you

178
06:51.420 --> 06:54.550 align:middle line:90%
and I'd like to thank
you for viewing.