Network Introspection

Loading...

En provenance du cours de VMware

Networking and Security Architecture with VMware NSX

notes

VMware

Networking and Security Architecture with VMware NSX

notes

This 8 week online course equips learners with the basics of network virtualization with VMware NSX. To get the most of this course, you should have familiarity with generic IT concepts of routing, switching, firewalling, disaster recovery, business continuity, cloud and security. At the end of the course, you will be able to: • Understand network virtualization basics • Describe NSX business value and use cases • Explain how NSX is different from traditional networking • Summarize networking and security solution architecture with VMware NSX around these key areas: + Micro-segmentation + Automation with OpenStack + Automation with VMware vRealize Automation + Disaster Recovery and Business Continuity + Operational Transformation • Demonstrate understanding through hands-on experience • Develop a learning plan for network virtualization certification If you are new to network virtualization, download our Network Virtualization for Dummies guide. http://learn.vmware.com/36350_NSX_ITAutomation_Reg?src=af_5acfd24cebb90&cid=70134000001YR9b

À partir de la leçon

Security Solutions with VMware NSX

This module dives into VMware NSX as a security platform that provides a defensive in depth solution. The content compares traditional security solutions with the in-kernel firewall provided by VMware NSX. In addition, this module covers application behavior monitoring and the ecosystem of partners that integrate with VMware NSX to provide a comprehensive security solution.

Introduction to NSX Security Ecosystem7:22

Network Introspection13:54

Guest Introspection11:13

Rencontrer les enseignants

Chris McCain
Director of Product Management
Networking & Security

Let me talk a little bit more about network introspection.

So, networking introspection as I mentioned earlier,

really enables advanced network security surfaces for the software-defined data center.

It leverages the VM or surface insertion platform,

and specifically NetX or network extensibility.

So, the goal of network introspection is to prevent

lateral threat propagation of threats in

the software-defined data center by adding on

additional controls beyond what is natively delivered by the distributed firewall.

With these additional controls,

I mean features like next generation firewall,

IPS ideas, layer seven firewall,

URL filtering and those kind of features.

Those can be layered on,

and they can be applied at The Venus of

every VM similar to what we do with the distributed firewall.

So, similar to the distributed firewall,

the network introspection will deliver application centric,

distributed advanced network protection,

which means that when you provision a new application you can not only have

the distributed firewall policy applied a

right there with the application at provisioning time,

but also the actual next generation firewall policy

enforced right away at the same time the application is being provisioned.

We also provide selective redirection of policy based on security groups.

What this means is that you don't have to redirect all of your traffic

from the distributed firewall to the partner for events surfaces,

but you can be very selective.

For example, in a typical three-tier application customers often choose to

redirect traffic coming into the web tier to a next generation firewall,

and have all the other traffic in-between

the application tiers handled by the distributed firewall.

As I mentioned earlier as well,

another main benefit is that we share security groups from NetX,

from V center with the Partner Manager.

So, in your partner you can leverage those security groups in the policy.

Domain use cases for network introspection as I mentioned are layer seven inspection,

IPS ideas, and those are applied typically to both workloads as well as VDI environments.

Imagine in VDI, where you have users accessing desktops that typically require

your typical perimeter firewall features such as

euro filtering and application control and visibility.

Now let me talk a little bit about the process of how to actually

deploy these third-party network introspection surfaces.

There's a couple of prerequisites,

the first thing of course you will not need to have Vcenter.

You need to deploy as NSX-V. You'll need to actually

deploy a partner management console or a Partner Manager,

and then you'll need to obtain a partner OVA

which will be the OVA that gets deployed on the host,

where you deploy the partner surface.

Once you've done that, once you've met the prerequisites,

you can start with the actual surface onboarding.

The first thing in an onboarding is actually deploying the partner management console.

Once you've deployed the partner management console,

you can register that console with NSX manager.

Once that is done, the surface for example

a next-generation fireball surface will appear in the surface catalog of NSX.

Once you've done that, you can then choose pick that partner surface,

and deploy it to select clusters in your environment.

Then once you've done the deployment,

we get to surface consumption.

Surface consumption basically means how am I going to use the surface,

what traffic will I redirect to this next generation firewall, to this IPS.

So, in order to do that, you can create security groups.

Security groups can be created based on security tags for example,

in order to have a very dynamic policy,

and then you can create a redirection policy which you then apply to the security groups,

and select which traffic should be steered to

which of our network introspection services.

Then of course once you've done that on a continuous basis,

you want to monitor the surface,

we provide alerting mechanisms to identify if something is not going to wait shoot,

but a third-party service.

We also enable rapid redeployment of a partner surface if that would be required.

So, let's have a brief look here at

the architecture of how we implement network introspection.

You are using the VM ware service insertion platform.

As I mentioned on the previous slide,

the first thing you will need to do in order to deploy

a network introspection service is to deploy the partner service manager.

Once you've done that, the partner Surface Manager will create a catalog in NSX manager,

and you'll be able to deploy the actual service on a cluster.

Once you do that, when you choose to do that all of the hosts in

the clusterable get the partner surface VM deployed on it.

This part of the surface VM has a couple of

built-in components that allow it to receive data,

to receive packets from the VMware surface insertion platform.

That all happens through the VMCI channel

which is a proprietary channel on the hypervisor.

Between every VM's Phoenix and a distributed switch,

we have something called IO chains.

IO chains are basically slots that allow us to

insert specific surfaces in between the VM,

and the actual distributed switch.

One of these IO chains is used by the distributed firewall,

that slot number two there's in total 16 slots available.

Slot number four through slot number 11 are available for network introspection surfaces.

So, let me quickly walk you through some packet flow here.

Let's say that we have a packet being originated from the VM that you can see here.

First all, the packet is goning to go through the IO chain,

and it's going to go through slot two at which

the distributed firewall matches the packet against distributed firewall rules.

If the flow is allowed,

if the packet is allowed by distributed firewall rule,

the packet is sent back onto the IO chain,

and is then validated against redirection roles.

If the packet matches a redirection rule,

the packet is then redirected to the specified network introspection surface.

For example all next generation firewall,

the packet is processed again,

and if the packet is allowed it's sent back or it's sent on his way to the destination.

So, that was a quick overview of the architecture.

Now, let me talk about a couple of common design patterns.

This slide shows one of the most common micro-segmentation design patterns.

Of course, as you've learned micro-segmentation really allows

customers to segment every workload from every other workloads,

regardless of the underlying network topology.

If you look at this diagram,

you can see that we have two VLANS here connected

to an ESG connected to an edge surfaces gateway.

Can say that the VLAN on the top for example,

this might represent the web VLAN and all of

the VMs that are connected to that VLAN may for example be web VMs,

could represent our web tier.

Let's imagine for this exercise here,

that the VMs at the bottom are connected to an application VLAN.

Now, all the VMs on the web,

and the VMs on the application vVLAN are VMs that don't belong to the same application.

So, there's multiple applications that are on the same vVLAN.

With micro-segmentation, we can of course isolate these VMs from each other,

and we can enforce what we call controlled communication,

which means that we can specify that a VM for application one,

the web tier should only be able to talk to

the application tier for that particular application on a specific port.

So, that's our core micro-segmentation use case on VLAN back networks,

doesn't require any changes to the network,

and it's all implemented using the distributed firewall that

sits at the venuc of every virtual machine.

Now, on top of that with surface insertion,

we can also selectively choose to redirect traffic to a partner service.

This is for example, we can choose any traffic going in or out

of the web tier to be redirected to a partner service,

while any traffic going to or in between

other theories should be handled natively by the distributed firewall.

This was another design pattern,

and this is pretty similar,

but here we're also using network virtualization.

So, network virtualization allows us to virtualize and deliver not just the security,

but also the networking at the time the application is provisioned.

So, that enables complete independency from the underlying physical network,

and also from a security perspective here,

this use case is exactly the same as before,

so the distributed firewall is enforced at the Venuc of every VM,

and at the same venuc we have the ability to

selectively steer traffic to our partner service.

So, now that we've seen the architecture,

we've seen a couple of common deployment patterns,

let me talk a bit about some commonly use cases.

Advanced security for selective application tiers is one of

the main use-cases customers use network introspection for,

and this is what I mentioned earlier, right?

So, customers want to selectively apply layer seven surfaces like

IPS ideas or next generation firewall to a select set of traffic,

interesting traffic for example,

traffic going into the web tier.

So, we enable that with NSX, with redirection roles.

Multi-tenancy is another common use case,

and with service insertion we support the ability to create

multiple surface profiles which can then be applied to a different tedency.

So, you can basically create a one next generation firewall policy,

create another next generation firewall policy on the partner surface,

and then within NSX,

you can specify that for each tenant traffic

should be steered to a different security policy.

DMZ anywhere is another common use case for network introspection.

This is somewhat similar to the first use case in a sense that

the DMZ anywhere customers can choose to make

any workload regardless of where it lives in the environment at DMZ tier,

and then selectively choose if or if not

network introspection should be applied to that DMZ tier.

Remote and branch office perimeter is another use case.

NSX cannot be deployed only in the data center,

but can also be deployed in other locations such as remote and branch office.

Typically in a remote and branch office when customers

leverage technologies such as SD one,

they're also introducing a new network perimeter.

The internet now becomes the local metric perimeter at a branch for

steering all the traffic across from the branch to the main office.

So, because the internet now becomes the new perimeter,

customers typically need next generation firewall surfaces,

and this is another use case for surface insertion with NSX.

Then the last one on the list here is advanced security for VDI.

I mentioned this use-case earlier as well.

Imagine a VDI environment where users access their desktops.

Typically an end-user needs functionality like bureau filtering for example.

You want to limit which categories of urls your users are able to access,

and for that you also need network introspection,

you need a next generation firewall surface that can be

selectively applied to desktops even based on user groups using NSX.

So, let me look at an example here of

advanced security for select application or application tiers.

One thing that you can do with NSX is you can apply security tags.

Security tags make your security policy dynamic.

A security tag can be applied using automation to

a workload or to an application when that application is being provisioned.

Based on a security type being applied a VM

will then become a member of a particular security group

and a representative security policy will then be applied to that group.

So, looking at a quick example here,

this is actually based on something that one of our customers did,

is they had a requirement to specifically apply

surface insertion or a layer seven firewalling to specific applications.

They had grouped their applications or using

network overlays or looking at distributed logical rather here,

but they had grouped their workloads into specific logical switches

based on the confidentiality level of those applications,

and the data that those applications handle.

In case of this customer,

they had four logical switches representing this level of confidentiality,

there's logical switch one that represents confidential,

logical switch two is internal,

logical switch three are public applications,

and logical switch four are non-production applications.

Now, the security requirement for this customer was

to ensure that all the traffic coming in or

going out of the logical switch one to

confidential applications should pass through an X generation firewall.

On top of that, they had an additional requirement.

Any traffic coming into a web tier of an application,

coming into a web server of an application

regardless of which logical switch that application in,

should also pass by a layer seven firewall.

So, in order to do that,

they've applied security tanks to each

of the workloads at the moment the workload is deployed.

So, through automation, when a workload is deployed,

and that workload is a web server,

a web server security tag is uploaded at VM,

sent to database server or an application server.

Then they've created steering policies,

you can see on the left is steering policy that it redirects all traffic coming into

the confidential logical switch to the next generation firewall.

On the right you can see a steering policy that redirects all traffic

coming into any VM that has that web server security tag applied to it,

redirect that as well to the next generation firewall.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2018 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play