WEBVTT

1
00:00.000 --> 00:03.400
So based on our game plan, our next step is to set up fully qualified domain

2
00:03.400 --> 00:05.280
name filtering in NSX.

3
00:05.280 --> 00:08.480
Now to do that, we need to actually have a couple of rules to pull that off.

4
00:08.480 --> 00:09.360
Number one,

5
00:09.360 --> 00:14.000
we have to set up a rule that tells NSX to analyze and pay attention to the

6
00:14.000 --> 00:16.160
details regarding DNS.

7
00:16.160 --> 00:20.160
And so we're going to do that with a rule looking for the service. So in this

8
00:20.160 --> 00:21.200
case, let's use UDP

9
00:21.200 --> 00:26.000
port 53 for the traditional flavor of a DNS request, which would use UDP port

10
00:26.000 --> 00:27.760
53. And at the application

11
00:27.760 --> 00:31.610
layer, we'll tell it with a context profile to pay attention to DNS and we'll
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:27.760 --> 00:31.610
layer, we'll tell it with a context profile to pay attention to DNS and we'll

12
00:31.610 --> 00:32.720
allow that traffic.

13
00:32.720 --> 00:36.840
So that gives NSX the opportunity to start effectively eavesdropping and paying

14
00:36.840 --> 00:37.520
attention to what's

15
00:37.520 --> 00:40.820
really going on as part of those DNS requests. So we'll create that rule first

16
00:40.820 --> 00:41.520
because it's a

17
00:41.520 --> 00:44.510
prereq and then we'll follow it up with another rule that says, "Hey, if our

18
00:44.510 --> 00:45.360
clients are using

19
00:45.360 --> 00:50.310
HTTPS," so we'll look at it at layer four with TCP going to the well known port

20
00:50.310 --> 00:51.680
of 443,

21
00:51.680 --> 00:56.590
and also with the application layer looking for HTTPS and going to a specific

22
00:56.590 --> 00:57.520
URL, then we'll go

23
00:57.520 --> 01:00.760
ahead and say we want to reject that. So for this rule, it'd be allow that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
00:57.520 --> 01:00.760
ahead and say we want to reject that. So for this rule, it'd be allow that

24
01:00.760 --> 01:02.080
traffic for the DNS

25
01:02.080 --> 01:07.920
inspection. And then for this rule, we'll set the action to reject. Also, as a

26
01:07.920 --> 01:09.040
quick test before

27
01:09.040 --> 01:13.220
we implement our new rules, let's just verify that DNS is still working. So we

28
01:13.220 --> 01:14.320
'll do a dig for

29
01:14.320 --> 01:22.160
www.cisco.com. That looks great, or we can do an NS lookup for www.cisco.com.

30
01:22.160 --> 01:31.200
Let's also do a curl-i for HTTPS colon slash slash and www.cisco.com. Just to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:22.160 --> 01:31.200
Let's also do a curl-i for HTTPS colon slash slash and www.cisco.com. Just to

31
01:31.200 --> 01:31.920
verify that all

32
01:31.920 --> 01:36.170
has worked, fantastic. Let's also go to a browser and just verify that we can

33
01:36.170 --> 01:37.680
get to cisco.com.

34
01:37.680 --> 01:42.000
So here, let's go to cisco.com and that looks good. And we also go ahead and

35
01:42.000 --> 01:42.800
create a bookmark for

36
01:42.800 --> 01:46.290
that to make it easier in the future. And it's important to know that sometimes

37
01:46.290 --> 01:46.960
browsers

38
01:46.960 --> 01:50.410
cache information. So if we set up a rule, for example, in the future, says we

39
01:50.410 --> 01:51.920
can't go to cisco.com

40
01:51.920 --> 01:55.440
with fully qualified domain name filtering. And it appears like it's working.

41
01:55.440 --> 01:55.920
You might want to

42
01:55.920 --> 01:59.440
close the browser or clear the cache. And then to go ahead and try it again,

43
01:59.440 --> 01:59.840
just to make sure

44
01:59.840 --> 02:03.700
you're not playing from cached information. So between the curl at the CLI and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
01:59.840 --> 02:03.700
you're not playing from cached information. So between the curl at the CLI and

45
02:03.700 --> 02:04.880
the browser here,

46
02:04.880 --> 02:09.280
we have a couple of great ways of verifying access currently with DNS and also

47
02:09.280 --> 02:10.480
with web access to

48
02:10.480 --> 02:14.600
cisco.com. All right, so we minimize that, let's go ahead and create the

49
02:14.600 --> 02:16.080
application layer rule

50
02:16.080 --> 02:20.090
saying we want to look for an analyzed DNS traffic. So to do that, I'm going to

51
02:20.090 --> 02:20.880
create a brand new

52
02:20.880 --> 02:26.070
policy. So we'll click here on add policy. And let's call this FQ DN filtering.

53
02:26.070 --> 02:27.200
If we click the gear,

54
02:27.200 --> 02:30.880
we can use the defaults here for TCP strict and stateful. We'll click on cancel
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

54
02:27.200 --> 02:30.880
we can use the defaults here for TCP strict and stateful. We'll click on cancel

55
02:30.880 --> 02:31.440
, we'll leave those

56
02:31.440 --> 02:35.390
defaults in place. And let's create a new rule. So if we're going to do the

57
02:35.390 --> 02:36.480
fully qualified domain

58
02:36.480 --> 02:40.400
name filtering, we first have to have the rule to allow basic DNS inspection.

59
02:40.400 --> 02:41.440
So to do that with

60
02:41.440 --> 02:45.560
the fully qualified domain name filtering policy selected, we'll click on add

61
02:45.560 --> 02:46.560
rule, which will add

62
02:46.560 --> 02:50.920
a rule to this policy. So we'll go ahead and call this DNS layer seven

63
02:50.920 --> 02:52.400
inspection. And again,

64
02:52.400 --> 02:55.430
we're doing this because it's a prerequisite if we want to do fully qualified

65
02:55.430 --> 02:56.000
domain name

66
02:56.000 --> 02:59.940
filtering. So DNS layer seven inspection. And for the source and destination, I

67
02:59.940 --> 03:00.240
'm just going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
02:59.940 --> 03:00.240
'm just going to

68
03:00.240 --> 03:04.390
leave it wide open. So any DNS requests that are going through the NSX

69
03:04.390 --> 03:05.840
distributed firewall

70
03:05.840 --> 03:09.330
are going to be seen and processed by this rule, which is going to go ahead and

71
03:09.330 --> 03:10.240
permit the traffic.

72
03:10.240 --> 03:13.280
And let me go ahead and collapse the left hand side gives a little more room.

73
03:13.280 --> 03:13.680
And so for this

74
03:13.680 --> 03:17.650
rule, I'm going to go ahead and do the layer seven DNS inspection based on any

75
03:17.650 --> 03:18.480
source, any

76
03:18.480 --> 03:22.530
destination, and for services at layer four, I'm going to go ahead and click on

77
03:22.530 --> 03:23.120
the pencil,

78
03:23.120 --> 03:27.620
type in DNS on the filter press enter. And we have several options here. So we

79
03:27.620 --> 03:28.960
have DNS TCP,

80
03:28.960 --> 03:34.320
that's TCP with this station port 53. We have DNS is coming in back from a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
03:28.960 --> 03:34.320
that's TCP with this station port 53. We have DNS is coming in back from a

81
03:34.320 --> 03:35.360
server for TCP and

82
03:35.360 --> 03:40.240
UDP. And for my lab here, I'm only using the traditional flavor of DNS requests

83
03:40.240 --> 03:41.440
with UDP to

84
03:41.440 --> 03:45.470
the well known part of 53. So I'm going to just choose DNS dash UDP. So you

85
03:45.470 --> 03:46.320
could use more if you

86
03:46.320 --> 03:49.790
need them. But for my lab demo, I'm just going to match on that layer for

87
03:49.790 --> 03:51.120
information transport

88
03:51.120 --> 03:55.150
protocol UDP going to the well known part of 53 and clicking on apply. And then

89
03:55.150 --> 03:55.840
for the context

90
03:55.840 --> 03:59.630
profile, I want to go ahead and do the analysis of actual application layer

91
03:59.630 --> 04:00.960
information for DNS.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
03:59.630 --> 04:00.960
information for DNS.

92
04:00.960 --> 04:05.600
So click on the pencil there to edit the context profile. And we'll type in DNS

93
04:05.600 --> 04:06.480
in the filter.

94
04:06.480 --> 04:10.950
And there happens to be a beautiful context profile already set up for us for

95
04:10.950 --> 04:11.360
DNS,

96
04:11.360 --> 04:15.120
which is basically saying it's at the application layer to querying of a DNS

97
04:15.120 --> 04:17.120
server over TCP or UDP.

98
04:17.120 --> 04:20.330
We'll click on apply. So here in our rule, we have in the services column, we

99
04:20.330 --> 04:21.840
click on DNS UDP.

100
04:21.840 --> 04:25.360
We're only looking at layer four for UDP going to the well known part of 53.

101
04:25.360 --> 04:26.080
Again, if you need

102
04:26.080 --> 04:29.480
more, you'd add more, but my lab that's all I'm using. And then at the

103
04:29.480 --> 04:30.560
application layer,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

103
04:29.480 --> 04:30.560
application layer,

104
04:30.560 --> 04:34.160
we're also inspecting and analyzing. And that's why we have DNS here in the

105
04:34.160 --> 04:35.360
context profile,

106
04:35.360 --> 04:39.960
looking for the app DNS. And that's being applied by default to the distributed

107
04:39.960 --> 04:40.400
firewall.

108
04:40.400 --> 04:44.120
And for the action, we want to allow that. So check this out. Currently, it's

109
04:44.120 --> 04:44.960
set to allow,

110
04:44.960 --> 04:49.390
we'll click on publish. If we brought in our client, for example, and we open

111
04:49.390 --> 04:50.640
up a command line,

112
04:50.640 --> 04:57.190
and we did a dig, for example, for www.vmware.com. No problem whatsoever,

113
04:57.190 --> 04:58.320
because being allowed.

114
04:58.320 --> 05:02.630
So if we hear in our rule said, you know what, we want the action to be reject,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

114
04:58.320 --> 05:02.630
So if we hear in our rule said, you know what, we want the action to be reject,

115
05:02.630 --> 05:03.200
which because

116
05:03.200 --> 05:06.720
this UDP is not going to send a TCP reset, but it will drop the traffic anyway.

117
05:06.720 --> 05:07.440
So I guess we

118
05:07.440 --> 05:10.720
could say drop as an example, then we click on publish to push that out. So

119
05:10.720 --> 05:11.680
then if we bring this

120
05:11.680 --> 05:15.100
client back and hit the up arrow key and press enter, now that DNS request is

121
05:15.100 --> 05:16.480
not working, because

122
05:16.480 --> 05:22.590
we're looking for UDP port 53 at layer four, and at the application layer, we

123
05:22.590 --> 05:23.520
're looking for a DNS

124
05:23.520 --> 05:26.620
request. And if we see that, we're going to drop the traffic. And that's what's

125
05:26.620 --> 05:27.280
happening right

126
05:27.280 --> 05:30.810
here. So I'll go ahead and set that back to allow, click on publish. And I just
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
05:27.280 --> 05:30.810
here. So I'll go ahead and set that back to allow, click on publish. And I just

127
05:30.810 --> 05:31.360
want to remind you

128
05:31.360 --> 05:36.040
this rule that we just implemented is to allow the NSX environment to take a

129
05:36.040 --> 05:37.360
deeper look into those

130
05:37.360 --> 05:41.880
DNS requests, because then we can leverage that for other services, including F

131
05:41.880 --> 05:42.880
QDN filtering.

132
05:42.880 --> 05:45.970
So now that it is set back to allow, let's verify it works once again. So we'll

133
05:45.970 --> 05:47.120
go back to our client,

134
05:47.120 --> 05:51.440
hit the up arrow key, and sure enough, now DNS request work, no problem.