In an Enterprise network, SD-WAN Orchestrator supports collection of SD-WAN Orchestrator bound events and firewall logs originating from enterprise SD-WAN Edge to one or more centralized remote Syslog collectors (Servers), in the native Syslog format. For the Syslog collector to receive SD-WAN Orchestrator bound events and firewall logs from the configured edges in an Enterprise, at the profile level, configure Syslog collector details per segment in the SD-WAN Orchestrator by performing the steps on this procedure.
Prerequisites
- Ensure that Cloud Virtual Private Network (branch-to-branch VPN settings) is configured for the SD-WAN Edge (from where the SD-WAN Orchestrator bound events are originating) to establish a path between the SD-WAN Edge and the Syslog collectors. For more information, see Configure Cloud VPN for Profiles.
Procedure
What to do next
For more information about Firewall settings at the profile level, see Configure Firewall for Profiles.
Secure Syslog Forwarding Support
The 5.0 release supports secure syslog forwarding capability. Ensuring security of syslog forwarding is required for federal certifications and is necessary to meet the Edge hardening requirements of large enterprises. The secure syslog forwarding process begins with having a TLS capable syslog server. Currently, the SD-WAN Orchestrator allows forwarding logs to a syslog server that has TLS support. The 5.0 release enables the SD-WAN Orchestrator to control the syslog forwarding and conducts default security checking such as hierarchical PKI verification, CRL validation, etc. Moreover, it also allows customizing the security of forwarding by defining supported cipher suites, not allowing self-signed certificates, etc.
Another aspect of secure syslog forwarding is how revocation information is collected or integrated. The SD-WAN Orchestrator can now enable revocation information input from an Operator that can be fetched manually or via an external process. The SD-WAN Orchestrator will pick up that CRL information and will use it to verify the security of forwarding before all connections are established. In addition, the SD-WAN Orchestrator fetches that CRL information regularly and uses it when validating the connection.
System Properties
Secure syslog forwarding begins with configuring the SD-WAN Orchestrator syslog forwarding parameters to allow it to connect with a syslog server. To do so, the SD-WAN Orchestrator accepts a JSON formatted string to accomplish the following configuration parameters, which is configured in System Properties.
- dendrochronological: Backend service syslog integration configuration
- log.syslog.portal: Portal service syslog integration configuration
- log.syslog.upload: Upload service syslog integration configuration
When configuring system properties, the following Secure Syslog Configuration JSON string can be used.
config
<Object>enable:
<true> <false> Enable or Disable Syslog forwarding. Please note that this parameter controls overall syslog forwarding even if secure forwarding is enabled.options
<Object>host:
<string> The host running syslog, defaults to localhost.- port: <number> The port on the host that syslog is running on, defaults to syslogd's default port.
- protocol: <string> tcp4, udp4, tls4. Note: (tls4 enables secure syslog forwarding with default settings. To configure it please see the following secureOptions object
- pid: <number> PID of the process that log messages are coming from (Default process.pid).
- localhost: <string> Host to indicate that log messages are coming from (Default: localhost).
- app_name: <string> The name of the application (node-portal, node-backend, etc) (Default: process.title).
secureOptions
<Object>disableServerIdentityCheck:
<boolean> Optionally skipping SAN check while validating, i.e. can be used if the server's certification does not have a SAN for self-signed certificates. Defaultfalse
.fetchCRLEnabled:
<boolean> If notfalse
, SD-WAN Orchestrator fetches CRL information which is embedded into provided CAs. Default:true
rejectUnauthorized:
<boolean> If not false, the SD-WAN Orchestrator applies hierarchical PKI validation against the list of supplied CAs. Default:true
. (This is mostly required for testing purposes. Please do not use it in production.)caCertificate:
<string> SD-WAN Orchestrator can accept a string that contain PEM formatted certificates to optionally override the trusted CA certificates (can contain multiple CRLs in openssl friendly concatenated form). Default is to trust the well-known CAs curated by Mozilla. This option can be used for allowing to accept a local CA that is governed by the entity. For instance, for On-prem customers who have their own CAs and PKIs.crlPem:<string>
SD-WAN Orchestrator can accept a string that contain PEM formatted CRLs (can contain multiple CRLs in openssl friendly concatenated form). This option can be used for allowing to accept a local kept CRLs. IffetchCRLEnabled
is set true, the SD-WAN Orchestrator combines this information with fetched CRLs. This is mostly required for a specific scenario where certificates do not have CRLDistribution point information in it.- crlDistributionPoints: <Array> The SD-WAN Orchestrator can optionally accept an array CRL distribution points URI in "http" protocol. The SD-WAN Orchestrator does not accept any "https" URI
- crlPollIntervalMinutes: <number> if fetchCRLEnabled is not set false, the SD-WAN Orchestrator polls CRLs every 12 hours. However, this parameter can optionally override this default behavior and update CRL according to provided number.
Configuring Secure Syslog Forwarding Example
{"enable": true,"options": {"appName": "node-portal","protocol": "tls","port": 8000,"host": "host.docker.internal","localhost": "localhost"},"secureOptions": {"caCertificate": "-----BEGIN CERTIFICATE-----MIID6TCCAtGgAwIBAgIUaauyk0AJ1ZK/U10OXl0GPGXxahQwDQYJKoZIhvcNAQELBQAwYDELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMQ8wDQYDVQQHDAZ2bXdhcmUxDzANBgNVBAoMBnZtd2FyZTEPMA0GA1UECwwGdm13YXJlMREwDwYDVQQDDAhyb290Q2VydDAgFw0yMTA5MjgxOTMzMjVaGA8yMDczMTAwNTE5MzMyNVowYDELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMQ8wDQYDVQQHDAZ2bXdhcmUxDzANBgNVBAoMBnZtd2FyZTEPMA0GA1UECwwGdm13YXJlMREwDwYDVQQDDAhyb290Q2VydDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwG+Xyp5wnoTDxpRRUmE63DUnaJcAIMVABm0xKoBEbOKoW0rnl3nFu3l0u6FZzfq+HBJwnOtrBO0lf/sges2/QeUduCeBC/bqs5VzIRQdNaFXVtundWU+7Tn0ZDKXv4aRC0vsvjejU0H7DCXLg4yGF4KbM6f0gVBgj4iFyIjcy4+aMsvYufDV518RRB3MIHuLdyQXIe253fVSBHA5NCn9NGEF1e6Nxt3hbzy3Xe4TwGDQfpXx7sRt9tNbnxemJ8A2ou8XzxHPc44G4O0eN/DGIwkP1GZpKcihFFMMxMlzAvotNqE25gxN/O04/JP7jfQDhqKrLKwmnAmgH9SqvV0F8CAwEAAaOBmDCBlTAdBgNVHQ4EFgQUSpavxf80w/I3bdLzubsFZnwzpcMwHwYDVR0jBBgwFoAUSpavxf80w/I3bdLzubsFZnwzpcMwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2xvY2FsaG9zdDo1NDgzL2NybFJvb3QucGVtMA0GCSqGSIb3DQEBCwUAA4IBAQBrYkmg+4x2FrC4W8eU0S62DVrsCtA26wKTVDtor8QAvi2sPGKNlv1nu3F2AOTBXIY+9QV/Zvg9oKunRy917BEVx8sBuwrHW9IvbThVk+NtT/5fxFQwCjO9l7/DiEkCRTsrY4WEy8AW1CcaBwEscFXXgliwWLYMpkFxsNBTrUIUfpIR0Wiogdtc+ccYWDSSPomWZHUmgumWIikLue9/sOvV9eWy56fZnQNBrOf5wUs0suJyLhi0hhFOAMdEJuL4WnYthX5d+ifNon8ylXGO6cOzXoA0DlvSmAS+NOEekFo6R1Arrws0/nk6otGH/Be5+/WXFmp0nzT5cwnspbpA1seO-----END CERTIFICATE-----","disableServerIdentityCheck": true,"fetchCRLEnabled":true,"rejectUnauthorized": true,"crlDistributionPoints": http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt
To configure syslog forwarding, see the following JSON object as an example (image below).
If the configuration is successful, the SD-WAN Orchestrator produces the following log and begins forwarding.
[portal:watch] 2021-10-19T20:08:47.150Z - info: [process.logger.163467409.0] [660] Remote Log has been successfully configured for the following options {"appName":"node-portal","protocol":"tls","port":8000,"host":"host.docker.internal","localhost":"localhost"}
Secure Syslog Forwarding in FIPS Mode
When FIPS mode is enable for secure syslog forwarding, the connection will be rejected if the syslog server does not offer the following cipher suites: "TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256." Also, independent from FIPS mode, if the syslog server certificate does not have an extended key usage field that sets "ServerAuth" attribute, the connection will be rejected.
Constant CRL Information Fetching
If fetchCRLEnabled is not set to false, the SD-WAN Orchestrator regularly updates the CRL information every 12 hours via the backend job mechanism. The fetched CRL information is stored in the corresponding system property titled, log.syslog.lastFetchedCRL.{serverName}. This CRL information is going to be checked in every connection attempt to the syslog server. If an error occurs during the fetching, the SD-WAN Orchestrator generates an Operator event.
If the fetchCRLEnabled is set to true, there will be three additional system properties to follow the status of the CRL, as follows: log.syslog.lastFetchedCRL.backend, log.syslog.lastFetchedCRL.portal, log.syslog.lastFetchedCRL.upload, as shown in the image below. This information will display the last update time of the CRL and CRL information.
Logging
If the option "fetchCRLEnabled" is set true, the SD-WAN Orchestrator will try to fetch CRLs. If an error occurs, the SD-WAN Orchestrator raises an event, as shown in the following image.