In a recent announcement at RSA Conference, VMware moved further into the security sector with the announcement of Service – Defined Firewall. Along with evolution of digital transformation where organizations are looking for solutions to increase employees productivity, organizations are looking for solutions to provide business productivity applications on the employee devices along with security. With the approach, Business applications are changing rapidly from a traditional framework to a distributed architecture. These business applications now might consist of many distinct services running on heterogeneous workloads that are networked might be networked together. This networking between the heterogeneous workloads results in the increase of complexity and size of the application attack surface.
Key issues in Application Security
As new applications architectures are distributed across both private and public clouds, network teams are struggling to find ways to ensure security and automation for an application driven network. The key issues they see are
Increased Attack Surface – New Applications are now comprised network between set of distributed services running across private and public clouds as well as in VMs, containers, and on bare-metal hosts. They are no longer a simple monolithic stack on a single server that can be easily secured. This explosion of services on the network has significantly increased the attack surface of an organization.
Rapid Application Change – Application developers are continually making changes to applications and deploying new services, which in turn require changes to security policies on a regular basis.
How VMware Solution Defined Firewall works?
The VMware Service-defined Firewall solution takes a new approach and is designed specifically to mitigate threats inside a Data Center or a Cloud Network. Instead of focusing on the ways to scrutinize an unknown organizations, using Service-Defined firewall organizations can now focus on securing ways to secure the assets that organizations know well and the applications they developed. VMware Service – Defined firewall combines the capabilities of VMware NSX network virtualization platform and VMware Security product App Defense. VMware NSX provides network and application visibility and VMware App Defense protects the workloads by monitoring their intended state.
Perimeter firewall solutions generally filters traffic coming from the unknown host but won’t be able to help much to filter East-West traffic within perimeter where deep contextual understanding of traffic is required. Perimeter firewalls lack deep understanding of application topology, host insights and know good behavior of application. Secondly, perimeter firewalls primarily rely on port block to control the traffic which can cause serious performance challenges while controlling East – West traffic.
The VMware Service-Defined Firewall helps accomplishing this with the following capabilities:
Provides a deep application visibility and control by having a deep visibility into application services and their behavior along with application topology. As VMware Service – Defined Firewall is built directly into the vSphere Hypervisor, it alleviates the need for additional agent to be installed.
Leveraging App Verification Cloud VMware Service Defined Firewall analyses known good application behavior across VMware footprint. It helps customers to quickly profile their own applications behaviors and create the best policies for enforcement. It intelligently configure and adapt security policies in case of any changes in application services.
To deliver ubiquitous protection, you can deploy VMware Service Defined Firewall wherever application may be running. It works with bare metal, virtual machine (VM), and container-based application environments, and will support hybrid cloud environments such as VMware Cloud on AWS (Amazon Web Services) and AWS Outposts in the future.
To validate the effectiveness of the VMware Service-defined Firewall, VMware teamed with Verodin, a leader in enabling organizations to measure, manage, and improve their cybersecurity effectiveness. VMware leveraged Verodin’s Security Instrumentation Platform (SIP) to validate that the VMware Service-Defined Firewall can effectively identify and stop threats whether they are known or unknown. While running the solution in both Detect and Prevent mode, the VMware Service-Defined Firewall detected or prevented 100 percent of the malicious attacks used in the Verodin test sequence.
VMware NSX SSL VPN-Plus allows remote users to access private networks behind a NSX Edge Gateway. You can access applications and servers running in the private network. Below is a diagram is taken from the NSX Admin Guide of the clients connect to the private network and also the support operating systems for the SSL VPN client:
To configure network access SSL VPN-Plus. Login to vCenter Web Client and go to “Network and Security”
Click on NSX Edge. Double click on Edge Gateway Services account
Click on SSL VPN-Plus Tab.
Create an IP Pool for the client connecting via VPN.
Add the Private Network you want to allow user connecting over VPN.
Select the Authentication Server Type.
Start the SSL VPN Service
Open the browser and browse external IP address over https. https://<External_IP_Address_of_ESG>
Verify the communication from VPN Client to internal network.
This concludes the configuration of SSL VPN-Plus on a VMware NSX Edge Gateway Services router. Hope this will be informative for you. Please share if you find worth sharing it. Thanks for Reading!!!
Spoofing also referred to as ARP Spoofing is a practice attacker use to penetrate networks. They spoof legitimate traffic on a network so that it appears to be coming from the trusted source on the network.
VMware NSX SpoofGuard keeps track of the ARP addresses to IP addresses and if there is any change in them. Leveraging VMware NSX SpoofGuard, VMware NSX can block the system automatically if there is an unexpected change of IP address to ARP address.
You can configure SpoofGuard either in Automatic or Manual mode:
Automatically trust IP assignments on their first use – Configuring this mode will automatically trust the first IP address reported to the NSX Manager. This mode is not recommended to be configured in a DHCP environment as IP addresses are dynamic and will change dynamically.
Manually inspect and approve all IP assignment before use – Configuring this mode will prevent all traffic by default will present the set of IP addresses discovered for approval by users.
Configuring SpoofGuard Policy
Login to vSphere Web Client and click on “Network and Security”
Click on SpoofGuard
Choose the appropriate mode, Automatically or Manual
Select the appropriate “Object Type”
As we configured mode as Manual select the VM and approve the IP Address
Click on App IP to add the additional IP Address.
Click on “Clear Approved IP” if you want to clear the approved IP Addresses.
This concludes the configuration of SpoofGuard policy in VMware NSX environment. SpoofGuard policy provides an automated way to get virtual machine blocked in case of any spoof. Hope this would be informative for you. Do share if you find this worth sharing it. Thanks for Reading!!!
You can configure a VMware NSX edge to relay name resolution requests from clients to external DNS servers. Once configured VMware NSX Edge Services Gateway (ESG) will forward name resolution request from clients to an external DNS Server. An ESG will relay client application requests to the DNS servers to fully resolve a network name and cache the response from the servers
In this blog, I will show you how to configure the DNS servers on the NSX edge.
Log in to the vSphere Web Client. Click Networking & Security
Click NSX Edges. Double-click onNSX Edge.
Click on Configuration –> DNS Configuration
Click Enable DNS Service to enable the DNS service. Type the IP Address of External DNS Server. Configure “Cache Size” and “Enable Logging” in case required
Post configuration NSX edge will relay the name resolution requests for any VM’s traffic that flow through it, to the configured external DNS servers.
This concludes the configuration of an external DNS server on Vmware NSX Edge Gateway Servies Router. Hope this will be informative for you. Please share if you find worth sharing it. Thanks for Reading!!!.
One of the services that the NSX Edge provides is IP address pooling and one-to-one static IP address allocation and external DNS services. NSX Edge listens to the internal interface for DHCP requests and uses the internal interface IP as the default gateway for clients.
In VMware NSX Edge DHCP service comply to the following guidelines:
Listens on the NSX Edge internal interface for DHCP discovery.
Uses the IP address of the internal interface on NSX Edge as the default gateway address for all clients and the broadcast and subnet mask values of the internal interface for the container network.
In this post, I’ll show you how to configure
DHCP on the NSX Edge to provide IP addresses to clients on a logical switch.
DHCP on the NSX EDGE to provide IP Address to the clients connected to Distributed Logical Router(DLR) and DLR configured as DHCP Relay Server.
This concludes the demonstration of configuring DHCP Services on VMware NSX Edge Router. Hope this will be informative for you. Please do share if you find worth sharing it. Thanks for Reading!!!
Dynamic Routing provides the necessary forwarding information between Layer 2 broadcast domains. There are 3 types of Dynamic Routing supported by VMware NSX OSPF, BGP, and IS-IS. NSX Edge supports OSPF, an interior gateway protocol that routes IP packets only within a single routing domain. It gathers link state information from available routers and constructs a topology map of the network. OSPF routing policies provide a dynamic process of traffic load balancing between routes of equal cost. An OSPF network is divided into routing areas to optimize traffic. An area is a logical collection of OSPF networks, routers, and links that have the same area identification. Areas are identified by an Area ID.
Logical Switches are no more different than the physical switches in the network. Similar to physical switches, It allows you to create a broadcast domain and isolate the Virtual Machines in the network. Once you create a logical switch is new distributed port group gets added on a distributed switch. The reason why we say it logical because a unique VNI (VXLAN Network Identifier) get associated to it to overlays the L2 network. Logical switching enables the extension of an L2 segment / IP subnet anywhere in the fabric independent of the physical network design. Endpoints, either virtual and physical, can connect to logical segments and establish connectivity independently from their physical location in the data center network.
The NSX Controller cluster controls logical switches and maintains information about virtual machines, ESXi hosts, logical switches, and VXLANs. All logical switches created within the transport zone inherit VMware NSX transport zone settings.
Logical Switch – Key Points
Logical Switch in an NSX Environment is a virtual network segment which is a distributed port group tagged with a unique VNI on a distributed switch.
Logical Switch can span distributed switch by associating with a port group in each distributed switch.
All hosts that are part of the same vDS supports VMotion.
A distributed port group is automatically created on all the VTEPs (ESXi hosts) that are part of the same underlying Transport Zone once you add a Logical Switch
A Virtual Machine vNIC then connects to each Logic Switch as appropriate.
This concludes the demonstration of creating a logical switch and connecting virtual machines vNIC’s to it. Hope this will be informative for you. Please do share if you find worth sharing it. Thanks for Reading !!!.
In the Previous post, We have discussed configuring VXLAN on ESXi hosts. In this post, We will discuss creating Segment Id and transport Zones. You must create a pool of segment ID in an NSX Environment to isolate your network traffic.
Introduction to Segment ID
Segment ID in an NSX environment determines the maximum number of logical switches that can be created in your infrastructure. Segments ID’s will be used by logical segments for VXLAN Network Identifiers (VNI). A segment ID is like a VLAN ID but for a VXLAN. A VLAN ID can only range from 1 to 4094 but Segment ID can range between 1 to 16,777,215. VMware has decided to use Segment ID starting from 5000 to avoid confusion between VLAN ID & Segment ID.
Starting with the NSX 6.2, segment ID range planning is required in order to enable cross-VC connectivity. It is recommended to keep the segment ID unique for each NSX domain to leverage cross-VC capabilities in NSX 6.2 release; this will help avoid the requirement of the renumbering of segment IDs.
A VMware NSX Transport Zone defines the boundary of which VMware NSX Logical switch (VXLAN’s) can be extended across. The ESXi hosts part of a Transport Zone communicate with each other over a VXLAN Tunnel Endpoint (VTEP) connection. In an NSX Environment, we can have one or more transport zone depending on our requirements. A single host cluster can belong to multiple transport zone and a Single Transport zone can span multiple vSphere Clusters. Basically, Transport Zone dictates which cluster and therefore which VM’s can participate in a particular network.
This video demonstrates the steps to create a New Transport Zone & Defining pool of Segment ID’s in an NSX environment. Hope this will be informative for you. Please share if you find worth sharing it. Thanks for Reading !!!