Many of our customers need to meet regulatory compliance for their sensitive applications that deal with healthcare or financial data such as HIPPA or PCI-DSS for instance. These compliance requirements often specify the need for IDS/IPS to prevent data theft. To meet these needs VMware introduced Distributed Intrusion Detection System (IDS) with NSX-T 3.0. They later expanded with Distributed Intrusion Prevention System (IPS) in NSX-T 3.1.

 

IDS/IPS in NSX: How it works

The NSX Distributed IDS/IPS engines originated in Suricata, a well-known and broadly respected open-source project. NSX builds on Suricata by giving the IDS/IPS engines a runtime environment, including networking I/O and management functionality.

NSX co-locates the IDS/IPS functionality with the distributed firewall, leading to a single-pass design for traffic inspection. All traffic passes through the firewall first, followed by IDS/IPS inspection depending on configuration. This co-location of IDS/IPS functionality with the firewall also simplifies the expression and enforcement of network security policies.

The NSX Distributed IDS/IPS engines are housed in user space and connected to the firewall module that resides in the hypervisor's kernel. An application communicates with another application by sending traffic to the hypervisor, where the firewall inspects the traffic. Subsequently, the firewall forwards the traffic to the IDS/IPS module in user space.

For details on the IDS/IPS Architecture and Use Cases please check the NSX Security Reference Guide.

Signatures

NSX pulls signatures from multiple security providers like the recently acquired Lastline,  DELL's SecureWorks and Trustwave.

Signatures can be updated automatically or on demand, in case your NSX Manager has an internet connectivity. If you run in a dark site, or just for any other reason your manager doesn't have internet connectivity, uploading an offline signature bundle is possible via API call.

Signatures can be enabled based on severity. A higher severity score indicates an increased risk associated with the intrusion event. Severity is determined based on the following:

• Severity specified in the signature itself
• CVSS (Common Vulnerability Scoring System) score specified in the signature
• Type-rating associated with the classification type

IDS detects intrusion attempts based on already known malicious instruction sequences. The detected patterns in the IDS are known as signatures. You can set a specific signature alert/drop/reject actions globally, or by profile.

 

Actions

• Alert - An alert is generated and no automatic preventative action is taken.
• Drop - An alert is generated and the offending packets are dropped.
• Reject - An alert is generated and the offending packets are dropped. For TCP flows, a TCP reset package is generated by IDS and sent to the source and destination of the connection. For other protocols, an ICMP-error packet is sent to the source and destination of the connection.

 

License

Distributed IDS/IPS feature is not available with the regular NSX-T license, it requires an addon NSX Distributed Threat Prevention license. I had to learn that the hard way:

I managed to obtain a NSX Distributed Threat Prevention license, so let's get started.

 

Enable IDS/IPS

 

STEP 1: In the NSX-T Policy UI navigate to Security --> Distributed IDS/IPS --> GET STARTED

 

STEP 2: My NSX-T Manager has an internet connection, so it immediately has found a new signature version available, which I am going to update to and also enable the Auto Update new versions, as per the recommendation.

NSX-T will automatically apply signatures to your hosts and update intrusion detection signatures by checking VMware's cloud-based service. Signatures are applied to IDS rules through profiles. By default, the NSX Manager checks for new signatures once per day. New signature update versions are published every two weeks, with additional non-scheduled 0-day updates.

 

STEP 3: Once the signatures are up to date, select the cluster, where you want to enable IDS/IPS and set it to Enabled:

 

STEP 4: Create Distributed IDS/IPS Profile.

You can stick with the default profile, which is set to include only the Critical Intrusion Severities (4430 out of 13529 at the moment of writing), however I will enable all severities (Low, High, Medium and Critical):

 

STEP 5: Create Distributed IDS/IPS Security Policy

IDS/IPS rules are used to apply the profile that we just created to selected applications/vms/traffic/. IDS/IPS rules are created in the same manner as distributed firewall rules and are being applied as filters to the vnic of the VMs, exactly as the DFW rules.

Please note DFW must be enabled and the traffic must be allowed by DFW to be passed through IDS rule. If a DFW rule blocks the traffic, then the IDS will not even evaluate it.

I have created "My production IDS/IPS policy":

 

Once again, Distributed IDS/IPS works in the very same way as the NSX-T Distributed Firewall (DFW), it uses the same NSX groups, the same distribution system, even the IDS and DFW rules are being evaluated by the same esxi module - vsip. Having that in mind, I am not going to spend any more time on this topic and will just create Any-Any rule to match all traffic that goes through my NSX switches (yes, IDS/IPS will not work on workload connected to non-NSX VDS switch, exactly as DFW, again). I will select the newly created "Production" IDS/IPS profile, then set Applied to to DFW (so all vNICs connected to NSX prepared switches get a copy of that rule applied). Next, I will set the mode to Detect & Prevent, so if the IDS detects any match to the Signatures, the IPS will kick in and block the traffic.

 

STEP 6: Create IDS/IPS Rule

 

STEP7: (Optional) Enable logging of the rule, to be able to monitor with vRealize Log Insight, or whatever syslog solution you use.

 

STEP 8: Let's validate we are getting IDS/IPS rules applied together with DFW rules.

 

Being in my lab, I don't have a great deal of DFW rules, still there are enough rules to illustrate how the IDS rules are being applied right after the DFW rules.

In the screenshot below we see the rules applied to filter nic-1276916-eth1-vmware-sfw.2, that filter is applied to eth1 of the x-red-web vm. Where PRE_FILTER rules are the rules applied in the INFRASTRUCTURE section of the DFW; FILTER (APP Category) rules are the rules from the APPLICATION section and last is the IDP rules section, where we can see the single rule together with the logging label that we created earlier.

 

Generating some IDS events

Now, after we have fully configured IDS/IPS NSX-T functionality let's test how it works.

I used a popular pentest tool to scan my overlay network for vulnerable machines and IDS immediately detected my attempt. The proof is below.

 

/var/log/dfwpktlogs.log

 

IDS/IPS UI

 

Thanks for reading.