NSX L2 to L4 Firewall: The VMware NSX DFW can enforce security policy from L2 (Data Link Layer) to L4 (Transport Layer).

With L2 we can create DFW rules base on the MAC address or L2 protocol like: ARP,RARP,LLDP.

L3/L4 security rules can be enforced with a source/destination IP address or TCP/UDP ports.

VMware have list of 3-Party vendor (constantly growing list)

Default Policy:

The DFW enforce L2 rules before L3.

L2 Default policy: Fresh DFW installations will have a default policy, Which is a L2 policy with Source: Any, Destination: Any, Action: Allow

L3 Default Policy:

We have a default L3 policy with Source: Any, Distention: Any, Action: Allow

DFW Exclusion functionality:Working on daily tasks with firewalls can sometimes lead to a situation where you end up blocking your access to the firewall management.Regardless of the vendor you are working with, this is very challenging situation.The end result of this scenario is that you are unable to access the firewall management to remove the rules that are blocking you from reaching the firewall management!

Think of a situation where you deploy a distributed firewall into each of your ESX hosts in a cluster, including the management cluster where you have your vCenter server located.

And then you change the default rule from the default “Allow” value to “Block” (as shown below):

What you’ve done by implementing this rule, can be shown in the following figure:

Like the poor guy above dropping himself from his tree, by implementing this rule, you have blocked yourself from managing your vCenter.

Resilience:

OR: How can we protect ourselves from this situation?

Put your vCenter (and other critical virtual machines) in an exclusion list.Any VM on that list will not receive any distributed firewall rules.Go to the Network & security tab Click on NSX Manager

Exclusion VM list 1

Double click on the IP address object. In my example it is 192.168.110.42

Click on Manage:

Go in the “Exclusion List” tab and click on the green plus button.

Choose your virtual machine.

That’s it! Now your VC is excluded from any enforced firewall rules.

Exclusion VM list 6

Restoring default firewall rules set:

We can use the NSX Manager REST API to revert to the default firewall rules set to overcome a mistake when we do not yet have access to the VC.

Perform a configuration backup at this stage.By default the NSX Manager is automatically excluded from DFW, so it is always possible to send API calls to it.Using a REST Client or cURL:

https://addons.mozilla.org/en-US/firefox/addon/restclient

Submit a DELETE request to:

https://$nsxmgr/api/4.0/firewall/globalroot-0/config

After receiving the expected code status “204” we will revert to the default DFW policy with default rule set to allow.

Now we can access our VC! . As we can see, we reverted to the default policy, but don’t panic as we saved the policy.

Click on the “Load Saved Configuration” button.

Load Saved Configuration before the last Saved.

Note: Every time we push dFW policy NSX automaticly save the policy. We have limit of 50 versions.

Accept the warning by click Yes.

Now we have our last policy before we blocked our VC, it’s loaded but not applied.

We will need to change the last Rule from Block to Allow to fix the problem.

And Click “Publish the Changes”.

It’s not possible to disable the DFW functionality per vNIC, Exclusion List only allows to disable DFW functionality per VM.

The following list is automatically excluded from DFW functions, by default: The NSX Manager, NSX Controllers, Edge Service Gateway and Service VM (PAN FW for instance).

NSX and Application Level Gateway (ALG):

Application Level Gateway (ALG) is the ability of a firewall or a NAT device that can either allow or block applications that uses dynamic ephemeral ports to communicate. In the absence of ALG, it could be a nightmare for security and network administrators with the options of trade off between communication and security. A network administrator can suggest opening a large number of ports which would pose security threat for the network or the given server while a security administrator can suggest blocking all other ports except the known ports which again breaks the communication.

ALG reads the network address found inside the application payload and opening respective ports for preceding communication and also synchronizing data across multiple sessions across different ports. For example: FTP uses different ports for session initiation/control connection and actual data transfers. An ALG would manage any information passed on the control connection as well as data connection in the above case.

NSX-v acts as ALG for few protocols such as FTP, CIFS, ORACLE TNS, MS-RPC, SUN-RPC.

NSX DFW logs:In NSX we have three different log types: System Events, Rule Events and Audit Messages and host Flows.

NSX Manager System Events

NSX Manager System Events are related to NSX operation like: FW configuration applied, Fail to publish FW configuration, Filter created, Filter deleted, VM added to Security Group.

For each System event have severity level:

INFORMATIONAL("Informational"),

LOW("Low"),MEDIUM("Medium"),MAJOR("Major"),CRITICAL("Critical"),HIGH("High")

To view the NSX System Events Go to Network & Security -> NSX Managers Click on the NSX Manager IP address -> Monitor -> System Events

Here is example for Critical event polled by NSX manager.

This event indicate vShiled-Statefull-Firewal demon went down on ESXi host id “host-38”.

We can view system event from the ESXi host itself. Here is example for FW configuration events can be view vShiled-Statefull-Firewal.log. this event cuase by policy push from the NSX manager to ESXi host. The file location is: var/log/vShiled-Statefull-Firewal.log

Example for output:

2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] Received vsa message of RuleSet, length 672015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] Processed vsa message RuleSet: 67

2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] L2 rule optimization is enabled2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] applying firewall config to vnic list on host host-102015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] Enabling TCP strict policy for default drop rule.2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] sending event: applied vmware-sfw ruleset 1425955389291 for vnic 500e519a-87fd-4acd-cee2-c97c2c6291ad.0002015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] successfully saved config to file /etc/vmware/vShiled-Statefull-Firewal/vsipfw_ruleset.dat2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] Sending vsa reply of domain-c7 host host-10: 0

NSX Manager Audit Events:

This log contains all the events related to: Admin login, FW configuration changes (pre and post change of the DFW rule).

To view the Audit Events Go to Network & Security -> NSX Managers Click on the NSX Manager IP address -> Monitor -> Audit Logs.

Here is Example for User “bob” login to system:

ESXi DFW host Rules Messages:

This log contains all the events related to: The DFW has dedicated log file (introduced in version 6.1) to view start/termination session and drop/pass packets. This logs contains the rule id associated vCenter objects.

File name is: dfwpktlogs.log

File location on the ESXi host: /var/log/dfwpktlogs.log

A log example: more /var/log/dfwpktlogs.log

2015-03-10T03:22:22.671Z INET match DROP domain-c7/1002 IN 242 UDP 192.168.110.10/138->192.168.110.255/138

1002 is the DFW rule-id

domain-c7 is cluster ID in the vCenter MOB.

192.168.110.10/138 is the source IP

192.168.110.255/138 destination IP

To view the Log filled we need to enable the “Log” option field.

By default when we create DFW rule there is no logging enabled. Logging occurs only after we enable the Log field on the firewall rules table

In order to see “Allow” or “Block” packet in the DFW logs files we need to change the “Log” field from “Do not log” to “Log”.

In the following example we’re changing the last rule id 1002 from “Do no log” to “Log”:

In the next example for DFW log event we will see the results of a ping from my Control VM Management IP 192.168.110.10 to 172.16.10.12:

~ # tail -f /var/log/dfwpktlogs.log | grep 192.168.110.10

2015-03-10T03:20:31.274Z INET match DROP domain-c27/1002 IN 60 PROTO 1 192.168.110.10->172.16.10.12

2015-03-10T03:20:35.794Z INET match DROP domain-c27/1002 IN 60 PROTO 1 192.168.110.10->172.16.10.12

Live Flows:

With DFW we have ability to view live flows. These flows are pulled by the vShiled-Statefull-Firewal from the VSIP kernel module and aggregated appropriately. The NSX Manager pulls “normal” flows from vShiled-Statefull-Firewal every 5 minutes and “realtime” flows every 5 secs.

Enable the Flow Monitoring by clicking on “Flow Monitoring” -> Configuration and click on the Enable. Global Flow Collection should change to green, “Enabled” status

To View the vNIC flow go to “Live Flow” tab and browse for a specific VM and vNIC.

Click the start button

Live flow will show up in the screen. The refresh Rate is 5 second.

From ESXi host the vShiled-Statefull-Firewal.log file we can see the related events:

2015-03-18T03:20:01Z vShiled-Statefull-Firewal: [INFO] Received vsa message of FlowConfiguration, length 120

2015-03-18T03:20:01Z vShiled-Statefull-Firewal: [INFO] Processed vsa message FlowConfiguration: 120

2015-03-18T03:20:01Z vShiled-Statefull-Firewal: [INFO] Loaded flow config: [120]

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] Received message in request queue of topic FlowRequest

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] Received vsa message of FlowRequest, length 52

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] Processed vsa message FlowRequest: 52

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] rmqRealTimeFlowDataRetrieve started

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] Done with configuring start of real time flows

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] rmqRealTimeFlowDataPush started

Service Composer:Service Composer helps you to provision and assign network and security services to applications in a virtual infrastructure.

You map these services to a security group, and the services are applied to the virtual machines in the security group

Security groupWith NSX DFW we have the ability to group vCenter elements such as VM’s to container called security groups. Base of this security groups we can built DFW rules. The of what vSphere object can be part of the security group can be dynamic or static.

Security group can be consume directly in to firewall tab without use the service composer.

Security Group = (Dynamic Inclusion + Static Inclusion) - Static Exclusion

Creating Security groups base of VM name example:

Go to Network & Security -> Service Composer -> Security Groups

Dynamic inclusion:A list of dynamic options for inclusion.

In the example below we chose “VM name” for any VM contains the word “web”:

Static Inclusion:We can select the object type that we want to (permanently) include as part of this security group.

With static inclusion we can create nested security groups.

Nested groups are group inside groups.

In the following example we will not exclude any object:

Static exclusion:We can select what is the object type we want to permanently exclude as part of this security group.

Summary of Security Group:

We can view the security group object members from the “Security Groups” tab.

In our example, the “Web Servers” security has two VM’s: web-sv-01 and web-sv-02a and this group membership is handled dynamically because the criteria is that they have “web” as part of their VM name.

If a new VM, called “web-sv-03a” is being created in this vCenter it will automatically be part of this security group.

Security policy using security groups:We can create a firewall rule that leverage this new security group:

Source can be any and destination will be the “Web Servers” security group.

The service can be one L4 service or group of services, here we chose HTTPS.

We can apply this policy to any cluster running NSX “Distributed Firewall”.

We can apply this policy on security groups, which will result in the rule (policy) applied only to VMs that are part of this security groups.

The security rule:

vSphere environments are dynamic by nature. When new VMs join (or leave) a security group (ex. “Web Servers”) the vCenter will update his database and as a result an update notification will be sent to the NSX manager. This notification will trigger a list of updates to the VMs that are part of this security group due to being part of the “Applied To”. Security administrator do not need to constantly update the policy rules for every time new VMs join or leave the network. NSX firewall policy can automatically reflect these changes and this is the reason using vCenter objects is so powerful

Security tag:To keep the virtualization flexibility, without compromise security, VMware invented security tag.

By adding new tag attribute to VMs we can apply security policy. Adding or removing tag to VM can be done dynamically by automation, 3-Party or even manual.

We can use the example we used above in which we created a security group called “Web Servers”, but rather than use a VM name containing “web” as the criteria for this VM group membership, we can attach a security tag to this VM.

Create Manual Security tag:

Create the security tag name:

We have a user defined security tag with 0 VM count:

Manual apply Security Tag:

Select the “web servers” security tag name and right click.

Filter “web” from the list and choose “web-sv-01a” and “web-sv-02a” from list:

Now we can modify the “Web servers” security policy to use a dynamic including criteria:

After this changed we have two VM count with security tag “web servers”.

The security groups “Web server’s” contains the VM names: “web-sv-01a” and “web-sv-02a”.

In the VM’s summary page we can see the security tags that are applied to this VM and to which security group this VM belongs. From the “web-sv-01a” example:

Security Policy:Using security policy we can create templates containing DFW policy approved security admin this is “how you want to protect” your environment, then apply this on security groups “WHAT you want to protect”. Security policy may contain traffic redirection rules to 3rd-party vendors for service chaining.

Security policy is part of the service composer building blocks.

We can apply a security policy to more than one security group.

In the example below we apply “Web Security Policy” to both “Security Group 1” and Security Group 2”.

A different option is to apply two different security policies to same security groups.

This can result in a contradiction between the policies.

For example we apply “Security Policy 1” and “Security Policy 2” to “WEB Security Groups”:

The security policy precedency will be with a “Weight” value, configured by the security admin.

In the following example we demonstrate this when we create two different security policies: “Allow ICMP SP” and “Allow HTTP SP” and apply both to the previously created security group “Web Servers”.

Create “Allow ICMP SP”:

In create “Firewall Rules”: The “Weight” is 4300

The related action is “Allow” The source filled is: any Destination is: “Policy Security Groups”.

The following is the interesting part: Due to the fact that this security policy works as a template we may reuse it for different security groups and our goal is to avoid tying this template to a specific security group.

Service: ICMP ECHO Request, ICMP ECHO Replay.

Ready to compute and click “Finish”:

At the firewall tab we can note that at this stage:

We have not applied this security policy to any security groups and so this policy has not been activated yet. We can see it as the gray policy in the firewall tab.

There is no security group in the designation:

Create “Allow WEB SP” is the same way:

Notice that the “Weight” field is 1300, which is lower than the previous “Allow ICMP SP” 4300.

Cerate the “WEB” rule (same flow as above):

The firewall policy order shows “Allow ICMP” before “Allow WEB”

Now we apply both security policies on the same security group, using “Apply Policy”:

Choose “Allow ICMP Security Policy”:

And do the same for the second security policy called “Allow WEB SP”.

In the “Security Policy” tab view we can see the results of this action:

From the “Firewall” tab we can see that now we have two activated service composer security rules.

In the service composer canvas view we have an excellent summery of the security services which were applied to the security group: