To redirect NSX Malware Prevention service virtual machine (SVM) log messages to a remote log server, you can log in to the SVM on the hosts of the vSphere host clusters that are activated for NSX Distributed Malware Prevention service, and configure remote logging by running NSX CLI commands.
Remote logging on NSX Malware Prevention SVMs is supported starting in NSX 4.1.2.
Currently, only log messages for the NSX Malware Prevention file analysis lifecycle events are redirected to the remote log server. Typically, file analysis starts when a file is downloaded on a workload VM that is protected by an NSX Malware Prevention security policy. The downloaded file is processed by various components and a verdict is returned. The results provided by important intermediate components are logged in the syslog file on the SVM.
- File intercepted
- Verdict cache hit
- File sent for local (static) analysis
- File sent for cloud (dynamic) analysis
- Verdict obtained
- Policy enforced
If you want to redirect log messages for SVM health monitoring events, including SVM resource consumption, such as CPU usage, disk usage, and memory usage, you can configure remote logging on the NSX Manager CLI. Alternatively, you can monitor these health events on the Alarms page of the NSX Manager UI. For more information about the NSX Malware Prevention health events, see the NSX Event Catalog.
- TCP
- UDP
- TLS (secure remote logging)
TCP has the advantage of being more reliable, whereas UDP has the advantage of requiring less system and network overhead. TLS protocol has additional overhead but provides encrypted traffic between the SVM and the remote log server.
Aria Operations for Logs protocols (LI and LI-TLS) are not supported for configuring remote logging on the SVM.
Prerequisites
- The VMware vCenter administrator must activate SSH access to the SVM on each host. For more information, see the Prerequisites section in Log in to the NSX Malware Prevention Service Virtual Machine.
- Familiarize yourself with the set logging-server CLI command. For more information, see the Malware Prevention Service VM documentation in the NSX Command-Line Interface Reference.
- If you want to specify the TLS protocol for configuring a remote log server, copy the server certificates, client certificates, and the client key to /var/vmware/nsx/file-store on each NSX Malware Prevention SVM by using the copy url <url> [file <filename>] CLI command.
In the following example, the copy command is run on the SVM. So, by default, the client-key.pem file from the source location is copied to /var/vmware/nsx/file-store on the SVM.
Example:svm> copy url scp://[email protected]:/home/user/openssl/client-key.pem The authenticity of host '1.2.3.4 (1.2.3.4)' can't be established. ECDSA key fingerprint is SHA256:abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '1.2.3.4' (ECDSA) to the list of known hosts. [email protected]'s password: client-key.pem 100% 1704 8.0KB/s 00:00
- To configure a secure connection to a remote log server, verify that the server is configured with CA-signed certificates. For example, if you have a Aria Operations for Logs server vrli.prome.local as the log server, you can run the following command from a client to see the certificate chain on the log server:
root@caserver:~# echo -n | openssl s_client -connect vrli.prome.local:443 | sed -ne '/^Certificate chain/,/^---/p' depth=2 C = US, L = California, O = GS, CN = Orange Root Certification Authority verify error:num=19:self signed certificate in certificate chain Certificate chain 0 s:/C=US/ST=California/L=HTG/O=GSS/CN=vrli.prome.local i:/C=US/L=California/O=GS/CN=Green Intermediate Certification Authority 1 s:/C=US/L=California/O=GS/CN=Green Intermediate Certification Authority i:/C=US/L=California/O=GS/CN=Orange Root Certification Authority 2 s:/C=US/L=California/O=GS/CN=Orange Root Certification Authority i:/C=US/L=California/O=GS/CN=Orange Root Certification Authority --- DONE
