NSX IDS Configuration workflow:
Enabling NSX IDSP
To enable distributed IDSP for standalone hosts or clusters where traffic passes through NSX virtual network segments – VLAN-backed and overlay.
Note:
- The prerequisite for IDSP to work is to have traffic pass through the NSX DFW. If a DFW rule blocks traffic, NSX IDSP will not see the traffic.
The configuration flow to enable NSX-distributed IDS/IPS is as follows:
Security > [Policy Management] IDS/IPS & Malware Prevention > Settings > Shared
Within the Define Scope for Malware Prevention & IDS/IPS Deployment, select the cluster to which IDS will be enabled. Toggle the IDS/IPS button to On. NSX IDPS should now be enabled on the cluster selected in the previous action.
The command in the table below can be used to validate the status of the IDS engine on the ESXi hosts within the IDS-enabled cluster
[admin@esxi-01a:~] nsxcli -c get ids status
NSX IDS Status
----------------------------------------------------------
Status: enabled
Uptime: 21671 (0 days 06:01:11)
Once NSX IDS/IPS is enabled, the next step is to create a profile linked to NSX IDS/IPS rules.
Distributed NSX IDS/IPS Profiles
IDS/IPS Profiles are used to group signatures, which can be applied to selected applications. Using custom IDS/IPS profiles, you specify the IDS signatures you want to include or exclude for detection based on their severity, attack type, attack target, CVSS, and affected products.
Signatures can be enabled based on the severity rating of the signature. A higher score indicates an increased risk associated with the intrusion event. The severity is determined based on the following:
- Severity specified in the signature itself
- CVSS (Common Vulnerability Scoring System) score is specified in the signature
- Type-rating associated with the classification type
The configuration flow to Create/Edit and NSX-distributed IDS/IPS Profile is as follows:
Security > [Policy Management] IDS/IPS & Malware Prevention > Profiles
When defining the Profile, the Intrusion severity you want to include or exclude can be added or removed. In addition, the Filter intrusion signatures by Attack Type allows you to define custom profiles for granular control. Attack Type, Attack Targets, CVSS and Products Affected can be incorporated into the Profile.
Creating granular workload-specific profiles reduces noise and false positives in your environment.
You configure the IDS signatures that you want to include or exclude for detection based on their severity and more granular criteria:
- Attack Types: Categorizes signatures by attack techniques such as Trojan activity or attempted denial of service (DoS). The types align with the MITRE ATT&CK framework.
- Attack Targets: Broad category of possible attack targets such as IoT, mobile clients, or networking equipment.
- CVSS: Include or exclude signatures based on their CVSS score range (none, low, medium, high, and critical).
- Products Affected: Signatures specific to vulnerable applications or operating systems.
Globally disabled signatures are not available for inclusion in profiles.
You can also click the Manage signatures for this profile link to disable individual profile signatures that might not be relevant to your workloads or to override the global action configured for a given signature.
Suspicious IDS signatures are used to detect traffic anomalies in the network.
Note:
- At this point in time, the implementation strategy is to enable a default policy that will be applied to all workloads in the cluster as the day-one IDS/IPS position. Refinements will occur over time as the SecOps team familiarizes themselves with the platform and picks up on workload types that should have associated custom IDS/IPS profiles.
- To change the action for a specific signature, the Manage signature for this profile facility allows you to define custom actions for the component signatures, i.e., Alert, Drop, or Reject
Distributed NSX IDS/IPS Rules
IDS/IPS rules are used to apply a Profile to selected applications, workloads, and traffic. IDS/IPS rules are created in a similar way to DFW rules. First, an IDS/IPS policy is created, then rules are defined as part of the policy.
The configuration flow to Create/Edit and NSX IDS/IPS Distributed Rules is as follows:
Security > [Policy Management] IDS/IPS & Malware Prevention > Distributed Rules
IDS/IPS rules within the IDS/IPS policy can be associated with sources, destinations, and services, just like DFW rules. The Rule’s mode can be set to either Detect Only or Detect & Prevent.
The IDS Profile specifies the group of signatures against which the traffic is matched. The mode determines the action that is taken when a signature is triggered.
The following modes are available for an IDS/IPS rule:
- Detect Only: Regardless of the global or per-signature action, only alerts are generated, and no preventive action is taken. This mode is equivalent to an intrusion detection system.
- Detect & Prevent: The action that is specified for the given signature either globally or at the profile level is taken (alert, drop, reject). The action that is specified at the profile
level overrides the action configured globally. This mode is equivalent to an inline intrusion prevention system.
When configuring IDS/IPS rules, do not use the drop action in a rule that is configured with a security profile that includes suspicious-level signatures. With this configuration, you guarantee that any abnormal traffic is inspected.
Like distributed firewall rules, IDS/IPS rules are evaluated from top to bottom. You must place the most hit rules at the top to avoid the unnecessary evaluation of subsequent rules.
NSX IDS/IPS rules must specify one IDS/IPS profile per rule and be stateful. Layer 7 attributes (APP IDs) are not supported.
The output in the table below illustrates an IDS/IPS profile assigned to a vNIC in conjunction with the DFW rules.
[admin@esxi-01a:~] nsxcli -c get firewall : 394bbcd4-608f-4e3c-bff0-886c6fb56472 ruleset rules
NSX IDS Engine Profile Stats
----------------------------------------------------------
VIF UUID : 394bbcd4-608f-4e3c-bff0-886c6fb56472
Rule count: 1
Rule 4072 inout protocol any from any to any with ids profile b72557be-d82a-49b0-bdc8-31f340272e1c idp_detect;
To view the status of the NSX IDS/IPS profile associated with the rule highlighted in the table above, run the following command:
[admin@esxi-01a:~] nsxcli -c get ids engine profilestats b72557be-d82a-49b0-bdc8-31f340272e1c
NSX IDS Engine Profile Stats
----------------------------------------------------------
Profile ID: b72557be-d82a-49b0-bdc8-31f340272e1c
Total Alerts: 0
Total Drops: 0
Total Packets: 323199
Total Rejects: 0
Configuring IDS/IPS Signatures
On the IDS/IPS tab, you can configure and manage signatures under Settings
If the Auto Update new versions (recommended) check box is selected, signatures are automatically applied to the ESXi hosts after downloading them from the cloud. The signatures are stopped at the listed version if the check box is not selected.
Global Intrusion Signature Management
With Global Intrusion Signature Management, you can override the default action for a given signature and globally disable signatures irrelevant to your environment.
If a signature is disabled globally, it is removed from custom profiles. You cannot include the disabled signature in newly created custom profiles.
All signatures are preconfigured with a default VMware-recommended action. You can override this action globally or per profile.
The following actions are available:
- Alert: This action is typically used in new deployments or for new signatures.
- Drop and Reject actions are commonly used in the following circumstances:
- High-fidelity signatures with no false positives
- High-impact exploits
- After a signature is deployed in alert-only mode
Dropping a packet is a silent action without notification to the source and destination systems. Rejecting a packet is a more graceful way to deny a packet because it sends a destination unreachable message to the sender. Rejecting the packet is also faster because the action occurs.