How to secure Syslog with USM Anywhere

August 6, 2020 | Chris Johnson

One of the requests we often get is how to securely forward logs to the USM sensor. To forward logs securely, the one component that is required is an SSL certificate. By default, USM has a self-signed certificate that will allow sending secure logs over port 6514. Some platforms, such as Palo Alto Networks, require publicly signed certificates by default. In this blog, we will walk through the process of generating a publicly signed certificate for use with USM.

Generating a certificate – step by step process

To begin, the first thing that is required is a certificate signing request (CSR). Normally, this will be generated on the machine which the certificate will be installed. In our case, we are looking to install the certificate on a USM sensor which we do not have shell access. So, from a machine with openssl, the first thing we will do is generate a private key which will be used to generate the CSR.

It is important to note, the hostname used for your keys and certs will be the ones used for public access in your external DNS. The keys and certificates are private and should not be shared with any unnecessary parties and should only be installed on the machine where the certificate is used.

Run the following command, replacing the with the hostname of your machine to generate your private key.

openssl genrsa -out .key 2048

Once you have generated the key, the next step will be to generate the CSR. To do this, run the following command:

openssl req -new -sha256 -key .key -out .csr

When generating the CSR, you will be asked to provide some information

Common Name

The fully qualified domain name for the host where the certificate will be installed. This is the public facing FQDN

Organization Name

Legal name of the organization

Organization Unit

Branch of the organization making request

City / Locality

City where organization is located (do NOT abbreviate)

State / Province

State where organization is located (do NOT abbreviate)

Country / Region

Two letter ISO abbreviation for country

If you wold like to combine the two previous commands and create a new key along with the CSR, run the following command:

openssl req -out .csr -new -newkey rsa:2048 -nodes -keyout .key

Now that you have generated your key and CSR, you are to purchase your publicly signed certificate. You can purchase SSL certificates through a broker such as SSL2Buy or SSLShopper, or purchase them directly through a certificate authority such as GoDaddy or DigiCert.

Once you have purchased and received your certificate, you will get a bundle back from the vendor with all of the relevant files. In some cases, you will receive a CA certificate (or certificate bundle) and host certificate, while in others, you may receive multiple certificates. In my particular instance, I received a bundle that has the following files:

  • .crt - Host certificate
  • SectigoRSADomainValidationSecureServerCA.crt - CA certificate
  • USERTrustRSAAAACA.crt - Intermediate 1 certificate
  • AAACertificateServices.crt - Intermediate 2 certificate

It is important to know what you received from the servicer because, depending on what you received, you may have to concatenate certificates to build a certificate chain. Since our servicer has provided the CA cert and two intermediate certs separately, we will need to concatenate these into a certificate chain. The order of these is important for USM to parse them properly. To create the certificate chain, open a new file and copy the contents of each certificate starting with the Intermediate 2 (or your largest intermediate) and work your way back to the CA. It is also important to note that you will need to include -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- as you copy and paste each cert into the file.

-----BEGIN CERTIFICATE-----

Intermediate 2

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

Intermediate 1

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

CA certificate

-----END CERTIFICATE-----

Once you have copied all of the certificates into the file and created a certificate chain you can save the file -chain.crt

Now that you have all the pieces to configure your sensor, the next step is to install the certificate on your sensor. To do this, log into the USM user interface and navigate to Data Sources → Integrations → Sensor Apps → Syslog Server. Once on the syslog server page select the appropriate sensor in the upper right corner.

Now that you have selected the sensor, copy the contents of of -chain.crt and paste into the CA Certificate field. Copy .crt and paste it into the Server Certificate field. Finally, copy .key and paste it into the Server Private Key field and click save. You have now installed your public certificate on your USM agent. The last step is to ensure you have a public DNS record that points to the public IP address of the sensor.

To verify you are receiving logs you can navigate to one of two pages. For the first option, navigate to Data Sources → Sensors and select the sensor which you configured for TLS. Once the page loads, click on the Syslog Configuration tab where you will see Syslog TLS. Assuming logs are being forward and the proper policies are in place to receive the logs, you should now be seeing “Packets Received” increment.

securing syslog

The other option is to navigate to Data Sources → Integrations → Sensor Apps → Syslog Server. Once on ensure you select the correct sensor in the upper right hand corner. Once you have selected the correct sensor, navigate to the bottom where you will see statistics for Syslog TLS. Not only will you see the number of packets incrementing, but you will also see the IP that is sending the logs.

securing syslog approach

That’s it. You have now configured your sensor to receive secure syslog using TLS encryption. If you run into any problems, the first thing to validate is that you are forwarding logs to the public name or IP address of the sensor. If that is correct, ensure you have policies set up on your firewall that NAT the public IP address to the private IP address and allow port 6514 or 6515.

Chris Johnson

About the Author: Chris Johnson

Chris has been in the networking and security field for almost 20 years. In the first half of his career he was in operations working for some of the largest Telecommunication providers. After moving to the Bay Are in 2009, he transitioned to technical product management where he hoped to bring much of his operational experience to product development. After spending 5+ years with Juniper, he jumped into startup mode where he did sales and DevOps, including building out cloud infrastructures. Prior to coming to ATT, Chris was a Technical Product Manager where he worked with Cloud Service Provider to integrate and monetize the VMware Portfolio.

Read more posts from Chris Johnson ›

TAGS: syslog

‹ BACK TO ALL BLOGS

Get price Free trial