In an Enterprise network, SASE Orchestrator supports collection of SASE 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 SASE 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 SASE 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 SASE 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 Profile Firewall.
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 SASE Orchestrator allows forwarding logs to a syslog server that has TLS support. The 5.0 release allows the SASE 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 SASE Orchestrator can now allow revocation information input from an Operator that can be fetched manually or via an external process. The SASE 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 SASE Orchestrator fetches that CRL information regularly and uses it when validating the connection.
System Properties
Secure syslog forwarding begins with configuring the SASE Orchestrator syslog forwarding parameters to allow it to connect with a syslog server. To do so, the SASE Orchestrator accepts a JSON formatted string to accomplish the following configuration parameters, which is configured in System Properties.
- log.syslog.backend: 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> Activate or Deactivate Syslog forwarding. Please note that this parameter controls overall syslog forwarding even if secure forwarding is activated.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 allows secure syslog forwarding with default settings. To configure it please see the following secure Options 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
, SASE Orchestrator fetches CRL information which is embedded into provided CAs. Default:true
rejectUnauthorized:
<boolean> If not false, the SASE 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> SASE 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>
SASE 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 SASE 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 SASE Orchestrator can optionally accept an array CRL distribution points URI in "http" protocol. The SASE Orchestrator does not accept any "https" URIcrlPollIntervalMinutes:
<number> if fetchCRLEnabled is not set false, the SASE 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 SASE 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 activated 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 SASE 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 SASE Orchestrator generates an Operator event.
Logging
If the option "fetchCRLEnabled" is set true, the SASE Orchestrator will try to fetch CRLs. If an error occurs, the SASE Orchestrator raises an event and displays in the Operator Events page.