Now that you have the opportunity to take a look at some of those screenshots
and the
configuration that's currently in place, let's take a look together at this
environment
that's leveraging those screenshots and identify why in the world is IPS not
functioning or
picking up traffic between two VMs in the same segment.
So let's begin our checking by going to the security tab and the left under
policy management.
Let's click right here on ID/IPSM malware prevention.
If it wasn't configured at all, we get the wizard right here that says, "Hey, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If it wasn't configured at all, we get the wizard right here that says, "Hey,
do you
want to set this up?"
But based on the snocking the wizard, that would appear that it's enabled.
So let's click right here on settings for ID/IPSM and scroll down.
And here it's enabled for gateway services.
That means we can go ahead and apply a policy for ID/IPSM to gateway A or
gateway B. However,
if we scroll up a little bit, it is currently not enabled for our host
transport node.
So that means our ESXi hosts that want to be part of the implementation of ID/
IPSM to
be used as part of a distributed rule, they won't be able to do it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
be used as part of a distributed rule, they won't be able to do it.
So I'm going to go ahead and enable that right now and click on yes, because
that's
really what we want to solve the customer's problem.
We want the ability to have ID/IPSM distributed rules.
And that way we can identify and control the traffic right there on a single
segment between
two VMs on that segment.
So with the policies as part of a gateway, the traffic would have to go through
the
gateway.
And that wouldn't match for traffic between two VMs that are on the same exact
overlay
segment.
So now that we verify that we have it enabled, let's take a look at our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now that we verify that we have it enabled, let's take a look at our
profiles.
So we have two profiles, the default and the one we actually put together in
our previous
videos.
So our ID/IPSM profile looks like it's including everything.
Fantastic.
So now if we go to gateway rules, we can see where it's applied.
So let me go ahead and collapse the left hand side here.
And let me make this a little bit bigger.
So here in this policy is called ID/S on gateway A.
If we expand that.
Finally, this is being applied to gateway A as shown right up here.
And we have one rule called use our profile and the conditions are from
anywhere to anywhere WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
anywhere to anywhere
any service.
Please use our ID/IPSM profile.
And that is applied to our tier one gateway and it's in detect only mode.
So the fact that it's in detect only isn't a huge problem because the customer
is complaining
it was traffic between two VMs on the same segment.
So this entire rule right here being applied to a gateway wouldn't even match
on traffic
between two individual VMs on the same segment.
So although this is in place, what we really need to look at is the distributed
rules right
here.
So we'll click on distributed rules and currently we have nothing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll click on distributed rules and currently we have nothing.
And that is why we're not seeing any ID/IPSM events between two VMs on the same
segment
because there's no distributed rule currently in place.
So let's add one.
We'll click on add policy.
We'll call it our ID/S distributed policy and then let's create a rule in that
policy.
We'll call this use our profile and then for the conditions for the security
profile,
we'll click on the pencil and we'll choose our profile and then click on apply.
And then it's in detect only so we can do detect here or detect and prevent WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then it's in detect only so we can do detect here or detect and prevent
either way
is great.
So I'll leave it for detect it that way.
We won't be unintentionally denying initial traffic if we have a false positive
and with
that in place we'll click on publish.
And then as a test we could go to two VMs on the same segment, generate some
traffic that
in our baselines we've identified is going to be triggered as intrusion events
and verify
that they show up.
So the two things we did here is first of all we made sure under settings that
we had
enabled our cluster with host A and host B so they could support distributed WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
enabled our cluster with host A and host B so they could support distributed
rules for
ID/IPS.
And then secondly we made sure that we had a distributed rule that was
currently applied.
And once we select the distributed rules tab those rules will show up right
here.
And as I mentioned furthermore we'd want to go ahead and test this with some
known traffic
that causes a match on the ID/IPS function just to make sure this rule, this
now a distributed
rule is working correctly.
So thank you for joining me in this video and in this skill regarding using IDS
and
IPS services inside of NSX.
And I look forward to seeing you my friend in another skill very very soon. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I look forward to seeing you my friend in another skill very very soon.
Until then I hope this has been informative and I'd like to thank you for
viewing.
[BLANK_AUDIO]