VMware NSX-T 2.4 Security Update

I'm gonna put the but one of the technical product manager for NSX business in it the plan is to cover and a sixty security update for inner city data center release via ramming first ten minutes I'll cover the slide where where I'm going to talk about the basic micro segmentation as well as some of the enhanced security controls we plan to have for this release then followed by the demonstration of the new features so I will take around two to thirty minutes that's the plan the first thing first micro segmentation most of you are aware of this use case this is one of the key use K for use case for nsx security essentially it provides these privileged access model for a zero trust model for our customers data center essentially nsx enables this by having a distinct logical segment at the v-neck level and having a security control on it it could be the VMS or the containers you can have the perimeter firewall around it from the data path perspective it is enforced on the virtual NIC both from the container perspective or the VM perspective and it's done in the kernel hypervisor that way you get the line rate throughput for firewalling as well which essentially means if you add more compute node it adds the firewall capacity as you add a compute capacity to a data center that's one of the key advantage of having distributed firewall which is done in the kernel from the consumption perspective it's a single pane of glass which has the majority again not only for the micro segmentation for the VMS or containers even for the cloud instances you can manage security policies right from the single pane of glass which is nsx manager we are going to showcase that as well as photos demo we have setup on Prem setup as well as a six cloud instances both in our sure and AWS I'm going to demo that as well and also we have some of the logical concerns like grouping and the tagging which helps you to simplify further policy definition and also it helps you to have or dynamic policy configuration so that way it simplifies not only the day one operation in the day two cases as well it helps you to in case of any security event if you have to modify any configuration it helps a lot when you have a tagging and the grouping construct which could be a static or a dynamic way again I'm going to demonstrate that as well from the network topology perspective it's agnostic the micro segmentation is agnostic to that you can have this in a brownfield environment or a greenfield environment when I say brownfield and greenfield essentially you can have a VLAN backed networking or isolation with the micro segmentation or hourly based networking and micro segmentation and other aspect is you can have any kind of application topology late or late tree topology unlike in traditional deployment where you would have a firewall at the layer three boundary and 22 that firewall and get it back and send it to the destination segment or destination workload in this case everything is done on the virtual neck that Wade sent force closer to the your workload so that's about the basic micro segmentation so one of the other construct we want I want to call out here is nsx the tags we had this in nsx for vSphere I just wanted to call out a little bit so that you understand how we group the workload and how we use that group in the policy to simplify further so in this slide the vertically we have two deployment like production workload and the development workload then horizontally we have two applications so in an a sixty managed cluster you can have multiple tags associated with your workload why do we need it so if you have thousands of VMs that means thousands of firewall rules you would be programming right so how do you grip group these workloads thousands of VMs hundreds of application tens of Dawn's or a tenant's you may have if at all you have to group any particular tenant or application or application tier this is the way you can do it this is one of the way which you can have a tax to your workload then define a group if this tag exists then this will be part of this particular group so accordingly you can define a policy for that that particular application tier application zone or a tenant so in this case I have multiple tags even you can have a Linux Windows that kind of a tag as well so essentially it simplifies overall grouping and the way you define the policy so that's about the basic which we all always had on a 640 a sir I just wanted to give a refresher now let's talk about some of the new enhancements we have done are in NSX T from the security perspective the first thing is context-aware firewalling which essentially means now you can have the policy definition based on the layer seven this is one of the context we look at in the packet so that it can enforce it so what does it mean natively it's a layer 3 or layer 4 based the firewall in nsx essentially for example if you have a web traffic essentially will be opening up the port 80 or 443 depending on secure or insecure the channel you may have with the web application so with this essentially you can look at the layer 7 what application is running on that without this that same port can be misused to run some other application if you want it could be used for FTP or I mean I'm just saying it could be used for other application as well this will enforce that on this particular port this particular application needs to run so that's that's what we are bringing in as part of this particular feature in addition to this we also can get into the metadata of the TLS for example TLS has multiple versions right one at odhh 1.1 1.2 1.3 so you can restrict your application to use certain TLS version just for compliance season right so most of our customers wants to use TLS 1.2 as a minimum motion they don't want to allow anything below that so you can restrict that using TLS 1.2 in the policy definition I will show that as part of the demo but you can you can use this feature to do that in addition one more level down you can also choose ciphers associated with that TLS 1.2 so that way you can look into the layer 7 aspect of the packet and enforce the policy accordingly what I'm sorry on the app on the app attributes side of what you're providing for HTTP version 1.2 but what sort of performance it back is this gonna have on the system in terms of what you're looking at for throughput and forwarding table is it since it's all distributed I understand that it's not a problem with local VM to handle it but obviously you're gonna have some impact in terms of how deep you dig into the packet payload are you really only it's just more in terms of like low balanced service inspection or what what are you using to actually get through and look at that I'm what are the parameters are you're looking at I know I understand you can do LDAP but are you actually doing all that with a specific user with a particular ID with it like how deep is it going yeah so the way it works is essentially we look at the initial handshake within four to five packets we would get to know that a whether it's a you know HTTP or HTTPS so immediately we will program the the context table in the data path so there won't be any performance impact as such but we will be identifying their application within four packets of handshake so I mean you're going deep enough that you could like if you have a surface principle role that's logged in the ad you can actually tell that it's only that surface principle role that's doing that ask or that request I know we can detect only the application ID we don't look beyond that other than this TLS version and ciphers but possibly we can do it but at this point this is what is supported but there is no performance impact because within four packets we do it then we program the kernel and everything is done in color after that and are you doing that in the firewall slot or are using one of the earlier slots to figure that out so it's the same slot dfw so they just take care of everything right there and we look into this earlier the program the flow table and forward the packet okay second thing is the context again the user based policy you can have this is mainly used in virtual desktop environment or ideas such environment where you can define policy based on the user group so we have integration with the Active Directory so whereby we pull all the user group from there then we call it in the the policy as a source then you can define policy for that particular group for example if I have to take example of a medical center or Hospital you may have doctors you will have contractors you will have pharmacists you will have HR to pay them so you may have a different access policy for each of this the group and age of each of this group may have a different application for which they need access to write so for example HR app needs to be accessed by HR but not for the doctors doctors app needs to be accepted doctor but not HR so you need that kind of access policy in place right so in that case you can leverage this particular feature to do that especially in the ideas such case when multiple users are logged into the same what virtual machine and they get a virtual desktop out of it so essentially from the networking perspective they're using the same IP packet out right so that way from the network perspective you are getting the same IP for multiple users who belong to different user group but still we can leverage this particular feature use a session based the policy to restrict the access based on the security admins configuration how does that work I mean so you have 20 users logged in at the same box I mean they all of this out typically there's not gonna be any user identifiable information thing it's this user sending the traffic from the box how do you differentiate to know that a user you know user a is go trying to go here and as loud user B is not like how does the traffic get identified so mainly there's main one component is on the desktop or virtual machine in to have a vm tools which and with the network introspection or connection the driver which allow us to know that a this particular guy logged in and that guy as this security identify then we programmed that in the context APIs and then we accordingly be dropping something in the header then or something else something in the in the data as it goes through from the VMware tools itself we do not change anything in the packet itself talk about many login we identify that login event when you create of any started session we intercept that will identify our other models in the DFW that programs the data path before you send a packet out then it intercepts everything is in I know it's just a metadata tag that's yeah I get that so it's the controller actually is managing the idea that this flow is being created by this user from inside the virtual machine doesn't modify the data of that's being passed along at all but once it exits the machine then you do something with it where's the policy enforced so like in some system the policies had forced the very end of the flow like when tries to exit the fabric or where it tries to or as this get applied as soon as it tries to hit the first node yeah it is done in the DFW layer not within the virtual machine okay everything is done in the the DFW slot as you were saying so nobody hits the hypervisor the policy before it did yeah otherwise in the kernel it doesn't mean it yep is that something you guys are gonna extend into like AWS workspaces or anything like that that you're looking at in this release we do not have anything like that only for on Prem workload but it is yeah so that the the third feature we are going to have is FPD and URL whitelisting essentially it's very straightforward what feature it is but the use case is more of if at all your for example what your desktop needs to use cloud resources for you know email or storage like Microsoft Reno SharePoint office.com all those things you can define a policy based on the domain name instead of any IP subnet or IPS because you do not have I piece of this the public domains it can change instead you are define the policy on fqdn that way we can filter out any traffic based on that particular configuration or you may have a development team which needs to X is the Amazon for s3 bucket right they may be storing something or getting something from there you can define a policy to allow all the Amazon traffic for this developer virtual desktop environment or this particular part and that kind of stuff we can do with this particular feature we are having as part of this release I'm going a little fast just in the interest of time but if you have any question please stop me okay this is last feature I will talk about then we'll go to a demo or this is again natively on nsx we have micro segmentation with enhance controls layer seven the user session based policy then if you want to leverage beyond that or if you have a use case for which you need to have the traditional firewall which you may be used to it should be followed though checkpoint and other vendors you can leverage and a60 service insertion capabilities to have that especially for IPS or ID is that kind of feature which is not natively available and a sixty you can leverage service insertion capabilities and one of the other thing is this particular service insertion caplets mainly required for some of the workloads like dmz workloads or a pca workloads or high power compliance the mandates that you need to have a layer seven of a more advanced layer seven firewall to be inserted between the zones or between the application tiers and we do both east-west as well as a north-south service insertion when I say not so that means we insert that as part of tier 0 or tier 1 when as the east-west means essentially it you do it at the virtual neck just after distributed firewall we intercept the package reader the traffic based on user configuration and then you have we learned from our earlier edition and sx/4 vSphere where we had that where service VM will go on every host right if you hundred host in your cluster that mean 100 VM you have to manage licensing lifecycle management so some feedback we got from the customer and the field is a we need service in such a one is for specific workloads like DMC piece here and other stuff so what we have done is we have to deployment option one is as it is like an Essex for vSphere you can have it in every host if you that is your requirement or we have a dedicated cluster that you can deploy few VMs then we can redirect the traffic to that VM based on your configuration and entire internal plumbing is done by an a6 manager you don't have to worry you just have to click click or call a a PA we will take care of this we call it a service plane all that traffic going here uses a nsh standard base header and the Geneva and capsulation Affairs has to go out of the host so essentially it can be extensible in future for you know physical firewall as well as well but currently we support these two model as a deployment so is is that equivalent your dedicated services cluster is that equivalent to an edge cluster no this you can I mean you're talking about no edge cluster is totally different from this is a V Center cluster we are talking about okay essentially ESX host that's what I meant so then licensing cos envy like you said you have to license the the third party on every react installed on every single host so you're saying I can have a non prepared cluster in terms of the third party and I can still offer services there and it's just going to do a genève over to the dedicated services cluster and then send it back yep oh yeah sorry right I'm sorry I meant yes okay I'm with you from the prepared term yes hi Paula mist okay we got ya anyway so that is the to deployment options we have currently for this for two different use cases based on customer feedback so does that mean I cannot have service insertion in a KBM because you just said it had to be a vSphere cluster yeah at this point we support based only on the vCenter cluster okay okay go ahead so with that I will want the demo so essentially for this demo I'll act like the security admin for a small hospital or Medical Center where I need to deploy the micro segmentation policy for my virtual desktop environment again I have multiple groups of users HR doctors and contractors I'll be taking to user user groups and I'll stay the micro segmentation policies using the new capabilities we have before that I'll just walk you through some of the stuff again I would not go through the all the cool stuff Demi's short again it applies to security as well when it comes to the monitoring giving the configuration snapshot all the you know health of the all the configuration we have as you can see here okay so yeah this is the the UI which you already saw this if I do go to the security configuration as a security admin you always go to the Security tab here and you have all the options to configure distributed firewall network introspection endpoint protection essentially the guest introspection capabilities again here's the cool view of what we have already again I have 34 groups essentially grouping the workload which could be based on any criteria you may use and these are the policies I have gateway policies represents the edge or a gateway policies for north-south traffic which you configure it on the tier 0 and also there are some cool stats here around what are the services used in the existing firewall policy so that you get a sense of what is running in the Sen SX cluster so it helps you to overall you know get a feel of it as a new admin or as an existing admin you get a feel of it so just refresher on the grouping again if you go to the inventory essentially as they may the puja everyone mentioned you can manage different type of workloads using the same nsx manager single pane of glass so what I in in this context when you go to the inventory and click on the virtual machine it lists us all the virtual machines on all the host managed by NSX which includes the AWS it includes ru all those workloads show up here including the containers it will show up here a for example can you see properly there or maybe ok so I can search here and I have few apps running the AWS so we have some AWS apps here as you can see one of the key thing about AWS instance this is you know or any instances we have you can tag those workloads as I was take talking right with respect to Azure and AWS it comes with all the existing tags from the cloud provider like cloud you could have some of the default tags like AWS region eight of this availability zone and also user configured attacks you may have in the AWS itself which you can bring it in here as soon as you connect to the B PC right so that's the one thing you can do and then you can group these workloads using that tax right on the nsx manager you may have a separate policy for all the instances in AWS separate policy for something energy or something in the on-prem right so you can group it accordingly and we just you know you use the tag to the group these workloads as a one group and use that in the policy to deploy micro segmentation policy there in order to edit particular attack for particular workloads you can just type it in here and you can have multiple tags like if this could be a production app one maybe app tier web I'm just giving all the tags then you can use the these tags to build your grouping and groupings could be static or dynamic as you can see I have some configuration here if I've visibility as well group definition could be you know virtual machine tag equals to or a logical switch tag equals to the voice name voice version all those capabilities built into and a sixty as well we had it in a in a 6-4 vSphere we are continue to have this as part of final 60 as well now in V though it came from the V Center database so given this as cross hypervisor if I'm going to move it to something that's known oddly Center backed what happens to that because it was an issue in V with multiple sites with local security groups where you end up you know killing the traffic any issues with that here some we do support I know multi hypervisor here right we are not much dependent on V Center as such we get it right from the ESX itself so there is no much defendants II with the V Center as such what's gonna happen when I move that workload or if I have the workload running in KBM and it's another part of the workload running in vSphere in I guess is it going to populate that host that VM name and then both sides will be able to know what the other VM names are because of Ennis XT is the common denominator there yes because we installed the agent as part of the host preparation which has a capability to get all the active VMS on that particular host k vm r is six we are not dependent on v center to give that information so that way we have inventory of all the things including the containers which you know that is other thing along with the cloud instances as well okay I can make some okay now coming to the the security policies you go to distributed firewall so first thing we have done is we have improvised on the layout here earlier we used to have one single table however now we have the multiple categories we have two starting with the emergency which essentially aligns with our customer best practices because they deploy emergency rule on top then which could be for current training some post when vulnerability is found or a compromise or some IPS you want to just deny this because if they are bad actors then infrared cheer category essentially this is for typical DNS ntp which is essentially same IP or service for all the workloads in your data center why to repeat the configuration put it in one place top of the table is taken care their environment you may have multiple zones production test or development what should be the the connectivity criteria between these zones typical its drop everything between the zones so you can define such policies right up front here so how does it help essentially earlier you have to insert the policies in a right position otherwise you may just scrub the entire configuration right so here it's intuitive in the way that you know you know that a these are the environment related configuration you will come here and define a rule or you can add one more section within that particular category so more of a simplifying the overall consumption with respect to organizing the rules in your DFW table right and it's always enforced from left to right if you see this way emergency infra environment application if you want to see the entire firewall table which is program in the data path you are seeing it here right again if you can see the category is mentioned here as part of this and finally the application category is the main one where you will define all your application related firewall rules or sections into a web to adapt to DB all those things comes here and I have three apps running HR app which I'm going to use then similarly medical record app similarly a cloud the play plane spotted app which is running in the Amazon so these are the rules within that section is there any kind of automatic rules that are created on that east-west traffic when you spin up a new app it knows that you're gonna be accessing that database go ahead and kind of create that rule and allow that traffic or are these things that you're just gonna have to kind of build to know your apps as you're deploying yeah then I know it's a to answer to a question how do you for file your application right so by default you have you know blacklist or whitelist from the firewall perspective no rule set up then you need to identify the the flows between the app tiers one of the way you can do is you can enable this logging capabilities here like if I go to the blacklist with logging all right so essentially whenever the traffic hits the that particular route it sends a log to your log collector there you can identify the day you want though you are a network admin or a security admin you can identify that between these two here this is the protocol used without talking to your application person right so that is a one way of doing things but we are building you know a different way to how you can streamline this application profiling and come up with the you know option or recommendation to our customers and Essex for vSphere has that currently where you can monitor the flow and then we recommend it for you the grouping as well as a micro segmentation policies but oh and we'll have this on this platform as well inferior the flagship way of application profiling which most of our customers uses either using logging mechanisms you could use you could lock to log inside or a lot of our customers are investing and we realize network insight which we call Bernie to basically help them profile applications we have a third product in the VMware product family called AB defense which is going to use machine learning to suggest rules which should be populated in the table that will go in at the process level so there's gonna be three ways to do things and a scan but he mentioned the fourth way would be we would continue to enhance this platform as well so what's the product you just mentioned to help automate micro segmentation rule creates called v-- it's uh it's not a product to automate rule creation it's a product to profile your applications very familiar with Vernie but when I worked on NSX projects and micro segmentation we worked with NSX architects and it was like an eight-hour level of effort per VM so is there any way to kind of cut that down and take all of that Network insight that you get from Vernie and automatically automatically create rules in NSX we are working on some projects we have nothing concrete to share yet once we have something concrete will communicate with the community great so a question for you is how how do you determine a rule does a redirection to one of the you know the integrations so coming come again sorry I was you said two minutes I just know so with the network integration I'm sorry the network introspection hmm and V you had a rule set that once it matched you could say redirect where is that here for the redirection so what this is the last place where you put in those policy so it's in a separate section section yeah it says totally intercepted after disputed firewall in the pipeline you will define the policy here okay and where is it or is there a distributed firewall exclusion list because there is in DFW or is there in these fears or one here as well yeah we do have it here in this one so like I mentioned in my presentation we are actually simplifying the workflows so we have the wizard intuitive workflows where you can go and create network and security topologies and you still have the advanced networking insecurity where all your nerd knobs are if you want to do advanced things yeah so this is where you have it that wasn't in 2/3 was it no in in in Torah 3 we only had the advanced networking and security all the tabs you see on the left side are new intuitive workflows which we have built so think about the advanced networking in security as your old tool at 3 classic mode I'm just trying to come up with a policy for this virtual desktop environment Marez these are two apps the front end for mrs then i have HR app this is the front end so and this is the Active Directory group which I am using it here as you can see this is a doctor group as you can say distinguished the group name is here which is synced from the Active Directory and then I'm creating I'm just copying drag and drop all these things works here and all else and you can use the profile this is where you use the the TLS versions to restrict the traffic ok this one or you can create new context here TLS 1.2 set attribute here that's it say wait and use it here similarly you can use the fqdn filtering here I already have it in the interest of time essentially yeah so essentially you can pick I'm picking all the Microsoft calm or Google SharePoint for this particular user that's it and I will reject all other traffic from these users okay so essentially what allows me to do is again this is the Active Directory user group in the source and these are the app VMs then these are the TLS version which is a layer seven firewalling and this is FGD and whitelisting where you specify some of the domain names and rest of the traffic will be rejected so now I'll just go to the this particular IDS's session so both have the same IP because it's on the same VM this is a remote desktop environment and if I come here and this is the this is our HR person Janet and this is the dr. John and I can access the HR app whereas here I should not be able to access it but I should be able to access the medical record app here however I should not be able to access this one but office is common because I need to work write emails and all those things same goes to dr. as well and other stuff you know you can enable it as you want

Channel: Tech Field Day

Views: 2,105

Rating: 5 out of 5

Keywords:

Id: uJo5xv6AduI

Length: 33min 54sec (2034 seconds)

Published: Wed Feb 27 2019