Requirements
These are the general steps you should follow to configure a Syslog server destination on Strata Logging Service to send Firewall metadata to Lumu:
Deploy and Set Up Lumu VA
All the detailed steps and guidance to create, download and install a virtual appliance on your preferred hypervisor or Cloud solution are available in our documentation:
Create a self-signed certificate to support SyslogTLS communication with the Virtual Appliance
You must create a self-signed certificate with a supporting OCSP (Online Certificate Status Protocol) service and implement it into your Virtual Appliance to enable secure communication between your Strata Logging Service and your Virtual appliance. Here, you will find all the process that covers these steps:

If your organization uses an existing internal Certificate Authority (CA) ask your CA administrator to issue a certificate for your Virtual Appliance with the required extensions to support OCSP validation. If you want to use a third-party certificate, ensure it includes the OCSP responder section and it is issued to the Virtual Appliance.
Preliminary setup
Before you start to follow the steps depicted in the following sections, you must install the OpenSSL package. According to your Linux OS flavor, use your distribution package manager to install it. For this guide, we will assume an Ubuntu OS. Run the following command to install openssl:
sudo apt upgrade
sudo apt install openssl -y
Follow the on-screen instructions, if prompted, and complete the installation.
After installing OpenSSL, create a work directory for all the artifacts that will be used during this configuration by running this command:
Locate yourself into the created working directory, then create a configuration file for OpenSSL Use the following template to create the openssl.cnf file and modify it based on the proposed guidelines.
# OpenSSL root CA configuration file.
[ ca ]
default_ca = CA_default
[ CA_default ]
# Directory and file locations.
dir = /etc/pki/ca
certs = $dir/certs
crl_dir = $dir/crl
new_certs_dir = $dir/newcerts
database = $dir/index.txt
serial = $dir/serial
RANDFILE = $dir/private/.rand
# The root key and root certificate.
private_key = $dir/certs/ca.key
certificate = $dir/certs/ca.pem
# For certificate revocation lists.
crlnumber = $dir/crlnumber
crl = $dir/crl/ca.crl.pem
crl_extensions = crl_ext
default_crl_days = 30
default_md = sha256
name_opt = ca_default
cert_opt = ca_default
default_days = 375
preserve = no
policy = policy_strict
[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
string_mask = utf8only
# SHA-1 is deprecated, so use SHA-2 instead.
default_md = sha256
# Extension to add when the -x509 option is used.
x509_extensions = v3_ca
[ req_distinguished_name ]
commonName = Common Name
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
0.organizationName = Organization Name
organizationalUnitName = Organizational Unit Name
emailAddress = Email Address
# Optionally, specify some defaults.
countryName_default = XX
stateOrProvinceName_default = MyState
localityName_default =
0.organizationName_default = MyOrg
organizationalUnitName_default =
emailAddress_default =
[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection
[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS = VA_IP
authorityInfoAccess = OCSP;URI:http://OCSP_SERVER:OCSP_PORT
[ crl_ext ]
authorityKeyIdentifier=keyid:always
[ ocsp ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning
Replace:
OCSP_SERVER by the IP address or the FQDN of your OCSP responder server
OCSP_PORT by the port of your OCSP responder service
VA_IP by the Virtual Appliance public IP address

Ensure your OCSP responder server allows connections to the selected port.
You must prepare your Certificate Authority server by running the following commands:
BASE_DIR="/etc/pki/ca"
sudo mkdir -p "$BASE_DIR" "${BASE_DIR}/certs" "${BASE_DIR}/newcerts" "${BASE_DIR}/private" "${BASE_DIR}/ocsp"
sudo touch "${BASE_DIR}/index.txt"
echo '1000' | sudo tee "${BASE_DIR}/serial" > /dev/null 2>&1
Now, you are ready to follow the next configuration sections.
Create a Certificate Authority (CA)
To create a Certificate Authority, you must run the following command on your device:
openssl req -new -x509 -extensions v3_ca -keyout "${BASE_DIR}/certs/ca.key" -out "${BASE_DIR}/certs/ca.pem" -days 3650 -config openssl.cnf
Follow the on-screen instructions following these guidelines:
Enter and confirm a PEM pass phrase when requested. Save it for further usage.
Enter a distinctive Common Name, like My Internal CA.
Enter your Country Name (2 letter code).
Enter your State or Province Name.
Enter your Locality Name or city. You can leave this field blank.
Enter your Organization Name.
Enter your Organizational Unit Name. You can leave this field blank.
Enter your Email Address. You can leave this field blank.
When finished, you will have these files:
Create your Virtual Appliance certificate
Now that you have set your internal Certificate Authority, let’s issue your Virtual Appliance signing request and generate your Virtual Appliance digital certificate. To issue your VA signing request, run the following command on your device:
openssl req -new -nodes -out va.csr -keyout va.key -config openssl.cnf
Follow the on-screen instructions and these guidelines:
Enter a distinctive Common Name. This name must match the VA IP address.
Enter your Country Name (2 letter code).
Enter your State or Province Name.
Enter your Locality Name or city. You can leave this field blank.
Enter your Organization Name. Ensure this is the same as the organization name defined when creating your Certificate Authority.
Enter your Organizational Unit Name. You can leave this field blank.
Enter your Email Address. You can leave this field blank.
When finished, you will have these files:
You must share the case with your internal Certificate Authority (CA). The internal CA will sign this request to generate the VA certificate. To sign the signing request, run this command in the internal CA server:
openssl ca -in va.csr -out va.pem -keyfile "${BASE_DIR}/certs/ca.key" -cert "${BASE_DIR}/certs/ca.pem" -config openssl.cnf -extensions server_cert
Follow the on-screen instructions and enter the pass phrase for the Certificate Authority key created before. You will see the certificate information:
Review that the information matches with the signing request and your Virtual Appliance (the commonName value must match your Virtual Appliance IP address). After checking all the information, press the y key and then Enter. Again, press the y key and then Enter. Now, you will have a new file, va.pem. This file is the digital certificate for your Virtual Appliance.

All va files (va.csr, va.pem, and va.key) must be stored safely. These files will be needed later to set up the Virtual Appliance and the Strata Logging Service.
Create an OCSP responder service
Strata Logging Service must be able to validate the digital certificate. You must configure an OCSP responder service on the device and port defined in the openssl.cnf configuration file, in the OCSP_SERVER and OCSP_PORT fields. To create an OCSP responder service you must:
In the following sections, you will be instructed on how to do each of the above.
Create the OCSP responder service certificate
You must issue a Certificate Signing Request and ask your recently created internal certificate authority to sign it. To create the Certificate Signing Request, run the following command in your device:
openssl req -new -nodes -out "ocsp.csr" -keyout "${BASE_DIR}/ocsp/ocsp.key" -config openssl.cnf
Follow the on-screen instructions following these guidelines:
Enter a distinctive Common Name. You can use something like OCSP Responder.
Enter your Country Name (2 letter code).
Enter your State or Province Name.
Enter your Locality Name or city. You can leave this field blank.
Enter your Organization Name. Make sure this is the same as the organization name defined when you created your Certificate Authority.
Enter your Organizational Unit Name. You can leave this field blank.
Enter your Email Address. You can leave this field blank.
When finished, you will have these files:
You must share the ocsp.csr with your internal Certificate Authority (CA). The internal CA will sign this request to generate the VA certificate. To sign the signing request, run this command in the internal CA server
openssl ca -in ocsp.csr -out "${BASE_DIR}/ocsp/ocsp.pem" -keyfile "${BASE_DIR}/certs/ca.key" -cert "${BASE_DIR}/certs/ca.pem" -config openssl.cnf -extensions ocsp
Follow the on-screen instructions and enter the pass phrase for the Certificate Authority key created before. You will see the certificate information:
Review that the information matches with the signing request. After checking all the information, press the y key and then Enter. Again, press the y key and then Enter. Now, you will have a new file, ocsp.pem. This file is the digital certificate for your OCSP responder service.
Run the OCSP responder service
Now you are ready to run your OCSP responder service. Create the following script file into the server you used to sign the OCSP responder Certificate Signing Request, your internal CA.
#!/bin/bash
# Responder daemon
SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
cd "${SCRIPT_DIR}"
# Check if the process exists
if [[ -f "pid.pid" ]]; then
PID=$(cat "pid.pid")
if [ -z "$PID" ] || [ -d /proc/$PID ] ; then
echo "[!] Process is already running. Exiting"
exit 1
fi
fi
sudo nohup openssl ocsp -index /etc/pki/ca/index.txt -port OCSP_PORT -rsigner /etc/pki/ca/ocsp/ocsp.pem -rkey /etc/pki/ca/ocsp/ocsp.key -CA /etc/pki/ca/certs/ca.pem -text -out /tmp/ocsp.log > /dev/null 2>& 1 &
pid=$!
# Store the PID to avoid duplication
echo $pid > "pid.pid"
Before saving, modify the OCSP_PORT by the port number your OCSP responder service will use. Ensure your OCSP responder server allows inbound connections to the selected port. You can save this file as ocsp_responder.sh. Then, modify its permissions to make it an executable script file by running this command:
chmod u+x ocsp_responder.sh
We recommend adding a line to the OCSP server crontab file to ensure that the OCSP responder service recovers from unexpected behaviors. Run the following command to add the job line.
line="*/5 * * * * /opt/ca/ocsp_responder.sh"
(crontab -u $(whoami) -l; echo "$line" ) | crontab -u $(whoami) -
If you need to check the operation of the OCSP responder service, you will find a log file in the /tmp/ocsp.log file.
Set up a Lumu VA Firewall Log Collector
Go to the Lumu Virtual Appliance and refresh the VA Collectors settings by running the command lumu-appliance collectors refresh. If the appliance is running, it must be stopped in order to continue the setup process.
Example of screen when setting up a Firewall Collector
Select the option Palo Alto Prisma Access Cloud CSV, then input the following data:
Protocol type: Select the TCP option. Strata Logging Service uses TCP protocol to send Syslog data.
Port number: Provide a number between 1024 and 65535, inclusive.
To implement the TLS communication between the Strata Logging Service and the Virtual Appliance, you must:
Prepare your Virtual Appliance
Copy the certificates into your Virtual Appliance
Modify your Virtual Appliance configuration to use the certificates
In the next sections, you will be instructed on how to run each step.
Prepare your Virtual Appliance
You must prepare your virtual appliance to copy the digital certificates and change your configuration files to allow it to process Syslog over TLS communications. Log in to your Virtual Appliance and follow these steps:
1. Stop your Virtual Appliance services by running this command:
lumu-appliance stop
2. Identify your Virtual Appliance version by running this command:
lumu-appliance -v
The version string is at the end of the line
Welcome to LUMU Virtual Appliance…3. Create a folder for placing the certificates by running this command:
mkdir -p /home/applianceadmin/lva_VA_VERSION/stack/log_collector_certs
Before running this command, replace the VA_VERSION with the version collected in step 3. For this case, VA_VERSION will be 4.0.4. It should look like this:mkdir -p /home/applianceadmin/lva_4.0.4/stack/log_collector_certs
4. Backup the main docker-compose.yml file by running this command:
cp /home/applianceadmin/lva_VA_VERSION/stack/docker-compose.yml /home/applianceadmin/lva_VA_VERSION/stack/docker-compose.yml.bck
Remember to replace the VA_VERSION with the string extracted in step 3.5. Add a new volume mapping to your new certificate path from step 3 by editing your docker-compose.yml file. Look for the volumes section under the log_collector configuration block. This block looks as follows:
Add this line in the volumes section:
- "./log_collector_certs/:/opt/logstash/certs/"

Remember to keep the spaces at the beginning of the line. If you miss the spaces when adding the configuration line, the VA will not start.
Your volumes section must look as follows:
Copy your certificates to your Virtual Appliance
Copy your va files (va.pem and va.key) and your CA public certificate (ca.pem) created on the Create a Certificate Authority (CA) and Create your Virtual Appliance certificate sections to the folder created on Step 3 of Prepare your Virtual Appliance. You can use the secure copy client of your preference.
Modify your Virtual Appliance configuration to use the certificates
Now, you must modify your Palo Alto Prisma Access collector configuration file input to implement the TLS reception with the copied certificates. Edit the file indicated at the end ot the step Set up a Lumu VA Firewall Log Collector. The collector configuration files are located in the following folder:
/home/applianceadmin/lva_VA_VERSION/stack/log_collector_pipeline/COLLECTOR_ID-000.cfg
Change the VA_VERSION for the value extracted in step 2 of the Prepare your Virtual Appliance section and the COLLECTOR_ID value according to the Set up a Lumu VA Firewall Log Collector result. Open the configuration file with the editor of your preference. Modify the input configuration section to look as follows:input {
tcp {
port => 1540
mode => "server"
type => "syslog"
ssl_enabled => true
ssl_certificate_authorities => "/etc/logstash/certs/ca.pem"
ssl_certificate => "/etc/logstash/certs/va.pem"
ssl_key => "/etc/logstash/certs/va.key"
ssl_client_authentication => "none"
}
}
Save your configuration file and start your appliance.
You must configure your Strata Logging Service to send Palo Alto Prisma Access logs to the Virtual Appliance. This requires that you forward logs to a Syslog Server. Follow these steps to do it.
1. Sign in to the application hub and select the Strata Logging Service,.
2. In the
Strata Logging Service window, head to the left navigation pane and click on the
Log Forwarding menu.

If you are using Strata Cloud Manager to manage Strata Logging Service, click on Settings > Strata > Logging Service > Log Forwarding.
3. In the
Log Forwarding window, click on the
Plus (+) icon to add a new Syslog forwarding profile.
4. Fill in the data into the New Syslog profile window. Follow these guidelines.
a. Enter a distinctive Name(1) for the profile.
b. Enter your Virtual Appliance public IPv4 address in Syslog Server(2). Ensure that the value here matches the Subject Alternative Name (SAN) of the certificate installed on your Virtual Appliance
c. Enter the Port(3) you configured in your Virtual Appliance.
d. Select the Facility(4) to match LOG_USER.
e. In the Server Authentication(5) section upload your CA certificate if you used a self-signed certificate. If you are using a third-party certificate you can skip this.
f. Click on the Test Connection(6) button to ensure Strata Loggins Service can communicate with your VA. Any issues must be resolved to proceed with the rest of the configuration.
g. After validating the Syslog connection, click on the
Next(7) button.
5. In the following screen, fill in the data based on these guidelines:
a. In the FORMAT(1) field, select the CSV option.
b. Leave the DELIMITER(2) value in COMMA: “,”.
c. Click the Add(3) button under the FILTERS section and add the following filters:
| Log source | Log type | Filter |
| Firewall logs | url | All logs |
| Firewall logs | threat | All logs |
| Firewall logs | traffic | All logs
|
d. When finished, save your changes by clicking on the Save button.