Sensor APIs
APIs to manage sensors.
Overview
Network Detection and Response Sensor or NDR Sensor is a passive, out-of-band virtual appliance that is deployed in data centers to monitor network traffic from non-NSX virtual machines, bare metal servers , and other physical or non-virtualized environments. The NDR Sensor inspects network traffic in real time to identify and classify potential threats, including malicious file transfers (for example, executables, documents), suspicious flow events (for example, abnormal traffic patterns, protocol anomalies), and IDS-based detections for known network intrusions and exploits. These events are then forwarded to the Network Detection and Response correlation engine for advanced analysis, contextual enrichment, and threat correlation across the environment.
NDR Sensor APIs
NDR Sensor APIs are defined using the OpenAPI standards. Clients interact with the API using RESTful web service calls over the HTTPS protocol. Unless otherwise noted, request and response bodies are encoded using JSON, and must conform to the JSON schema associated with each method. The content type of each request and reply is "application/json" unless otherwise specified.
Request Authentication
Basic authentication is used for all Security Services Platform APIs and for the features running on the platform.
To authenticate a request using HTTP Basic authentication, the caller's credentials are passed using the 'Authorization' header. The header content should consist of a base64-encoded string containing the username and password separated by a single colon (":") character, as specified in RFC 1945 section 11.1.
For example, to authenticate a request using the credentials of user admin with password admin, include the following header with the request:
The following cURL command will authenticate to the SSP Ingress using basic authentication and will issue a API request:
USERNAME is the user to authenticate as,
PASSWORD is the password to provide, and
SSP is the IP address or host name of the Security Services Platform (SSP)
For example:
Note: the -k argument instructs cURL to skip verifying the ssp's self-signed X.509 certificate. It is more secure to verify that the server's certificate is signed by a Certificate Authority (CA) that you trust. To do that, omit the -k argument and use the --cacert <ca-file> option, where <ca-file> is a PEM-formatted file containing the CA certificate to trust.
For example:
Additional cURL examples below use the -k flag, but you can always substitute the --rootca <ca-file> argument for additional security.
In the above examples, USERNAME may be:
- A local user name. For example, "admin".
- A remote user name, of the form "user@domain", for example, "[email protected]". The domain must match a domain for a configured VIDM identity source or a configured LDAP identity source.
Request Failures
It is possible for any request to fail. Errors are reported using standard HTTP response codes. The below table defines the HTTP Status codes these APIs may return
| Status Code | Description | Reason |
| 200 | Ok | API executed successfully. Check the response payload |
| 204 | No Content | API executed successfully. No response payload |
| 400 | Bad Request | If the request is not valid |
| 401 | Unauthorized | Unauthorized user |
| 403 | Forbidden | User is forbidden to perform the operation. |