Written by Michael Ibarra, Security Engineer, Mid-Atlantic Region
March 7, 2023
Because almost no computer exchanges data directly with another, data is almost always passed through some layer 3 (routing-capable) interface. Any devices along that path handle the data being transmitted, which presents risk to data integrity. It should go without saying that we want that data to be secure; that is, arriving in the same state as when it left, without any unauthorized tamperig. One common way to satisfy this requirement is using encryption.
Encrypting data so the sender and receiver can understand it (but others in the transmission path cannot) requires an agreed-upon method; this is known as public key cryptography. Suppose two computers, Host A and Host B, want to exchange data securely. Each computer will use two components to encrypt and decrypt communication between them:
Host A's public key is shared with Host B, so Host B can use it to encrypt data. Host A receives encrypted data from Host B and uses its private key to decrypt it. (Host B also shares its private key with Host A, and the process is mirrored in the opposite direction.) This is called asymmetric encryption. Each computer uses a different public key, hence the name.
Host A still shares its public key with Host B, but instead of immediately sharing data and stopping there, Host B replies with a specific key both computers can use to decrypt each other's data. Instead of relying on a unique public key for encrypting data for each receiver, both computers share the same key. This is called symmetric encryption.
Host A and Host B must trust each other completely to exchange data securely, but if this trust is compromised (e.g., through a man-in-the-middle attack), then even the best encryption methods cannot safeguard against a case of masquerading identity. Computers can verify each other’s identities by inspecting their certificate authority (CA)-signed certificates, which have inherent credibility through a trusted chain of CAs.
Computers holding a forged certificate, or one issued by a non-trusted CA, will be ignored when they try to communicate with others on a network.
Performing this identity validation in both directions is known as mutual TLS (mTLS) authentication.
Log Exporter supports mTLS with the following stipulations:
NOTE: This document was written based on configuration tested with a Secure Management Server. If logs are stored on a dedicated log server, the configuration and steps should be adapted for that scenario.
The core requirements are:
The following sections offer three approaches for generating the required certificates:
Each of these scenarios is covered in detail below.
This procedure requires three separate systems:
cpopenssl genrsa -out client-sms-key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
......+++++
..................................+++++
e is 65537 (0x010001)
cpopenssl req -new -key client-sms-key.pem -out client-sms-req.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:10.5.1.100
Email Address []:.
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<redacted>
An optional company name []:.
NOTE: When prompted, enter values as desired or enter . to indicate the field is empty. The only required value is Common Name.
cpopenssl pkcs12 -inkey client-sms-key.pem -in client-sms-cert.pem -export \
-out client-sms-cert.p12
Enter Export Password:
Verifying - Enter Export Password:
NOTE: This command takes both the generated certificate (with an embedded public key) and the private key as inputs and generates a PKCS12 file. The resulting file contains the certificate, public key, and private key, and should be treated as a highly sensitive security asset.
NOTE: syslog-ng is used in these steps but any log server supporting mTLS should be compatible. Refer to your vendor's log server documentation for guidance on adapting the following steps.
openssl genrsa -out server-syslog-key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
...............................+++++
.......................................................................+++++
e is 65537 (0x010001)
openssl req -new -key server-syslog-key.pem -out server-syslog-req.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:10.5.1.192
Email Address []:.
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<redacted>
An optional company name []:.
NOTE: Refer to your destination log server's documentation for which fields to populate. Otherwise, when prompted, enter values as desired or enter . to indicate the field is empty.
This procedure requires three separate systems:
cpopenssl genrsa -out client-sms-key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
......+++++
..................................+++++
e is 65537 (0x010001)
cpopenssl req -new -key client-sms-key.pem -out client-sms-req.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:10.5.1.100
Email Address []:.
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<redacted>
An optional company name []:.
NOTE: When prompted, enter values as desired or enter . to indicate the field is empty. The only required value is Common Name.
openssl x509 -req -in client-sms-req.pem -CA cacert.pem -CAkey cakey.pem /
-CAcreateserial -out client-sms-cert.pem -days 365 -sha256
NOTE: Modify the CA certificate and private key file values to match your environment's configuration.
cpopenssl pkcs12 -inkey client-sms-key.pem -in client-sms-cert.pem -export /
-out client-sms-cert.p12
Enter Export Password:
Verifying - Enter Export Password:
NOTE: This command takes both the generated certificate (with an embedded public key) and the private key as inputs and generates a PKCS12 file. The resulting file contains the certificate, public key, and private key, and should be treated as a highly sensitive security asset.
NOTE: syslog-ng is used in these steps but any log server supporting mTLS should be compatible. Refer to your vendor's log server documentation for guidance on adapting the following steps.
openssl genrsa -out server-syslog-key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
...............................+++++
.......................................................................+++++
e is 65537 (0x010001)
openssl req -new -key server-syslog-key.pem -out server-syslog-req.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:10.5.1.192
Email Address []:.
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<redacted>
An optional company name []:.
NOTE: Refer to your destination log server's documentation for which fields to populate. Otherwise, when prompted, enter values as desired or enter . to indicate the field is empty.
openssl x509 -req -in server-syslog-req.pem -CA cacert.pem -CAkey cakey.pem /
-CAcreateserial -out server-syslog-cert.pem -days 365 -sha256
NOTE: Modify the CA certificate and private key file values to match your environment's configuration.
NOTE: The following steps were adapted from syslog-ng Open Source Edition 3.16 - Mutual authentication using TLS.
The following steps assume a directory structure of /etc/ssl/openssl.cnf.
mkdir /etc/ssl/CA
cd /etc/ssl/CA
mkdir certs crl newcerts private
touch serial index.txt
cp /etc/ssl/openssl.cnf /openssl.cnf
vi openssl.cnf
####################################################################
[ CA_default ]
dir = . # Where everything is kept
openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem -days 365 /
-config openssl.cnf
openssl req -nodes -new -x509 -keyout client-sms-key.pem -out client-sms-/
req.pem -days 365 -config openssl.cnf
openssl x509 -x509toreq -in client-sms-req.pem -signkey client-sms-key.pem /
-out tmp.pem
openssl ca -config openssl.cnf -policy policy_anything -out /
client-sms-cert.pem -infiles tmp.pem
rm tmp.pem
cpopenssl pkcs12 -inkey client-sms-key.pem -in client-sms-cert.pem -export /
-out client-sms-cert.p12
Enter Export Password:
Verifying - Enter Export Password:
NOTE: This command takes both the generated certificate (with an embedded public key) and the private key as inputs and generates a PKCS12 file. The resulting file contains the certificate, public key, and private key, and should be treated as a highly sensitive security asset.
openssl req -nodes -new -x509 -keyout server-syslog-key.pem -out /
server-syslog-req.pem -days 365 -config openssl.cnf
openssl x509 -x509toreq -in server-syslog-req.pem -signkey /
server-syslog-key.pem -out tmp.pem
openssl ca -config openssl.cnf -policy policy_anything -out /
server-syslog-cert.pem -infiles tmp.pem
rm tmp.pem
NOTE: The following steps were validated on Ubuntu 22.04 with Splunk 9.0.4 and assume Splunk is installed and running under /opt. Adapt the steps depending on where your installation resides. As well, all configuration has been done within the context of a non-privileged user account named splunk.
cd /opt/splunk/etc/apps
mkdir -p sms-tls/{certs,local}
openssl genrsa -out server-splunk-key.pem 2048
openssl req -new -key server-splunk-key.pem -out server-splunk-req.pem
openssl x509 -req -in server-splunk-req.pem -CA cacert.pem -CAkey /
private/cakey.pem -CAcreateserial -out server-splunk-cert.pem -days 365 -sha256
NOTE: Regardless of process used, make sure the private key file is not encrypted. At least on Splunk 9.0.4 with OpenSSL 3.0.2, there exists a bug that prevents decryption of the private key.
cat server-splunk-cert.pem server-splunk-key.pem >> /
server-splunk-cert-combined.pem
splunk@splunk-test:/opt/splunk/etc/apps/sms-tls/local$ nano inputs.conf
[SSL]
serverCert = /opt/splunk/etc/apps/sms-tls/certs/server-splunk-cert-combined.pem
sslVersions = tls,-tls1.0
requireClientCert = true
[tcp-ssl:6514]
splunk@splunk-test:/opt/splunk/etc/apps/sms-tls/local$ nano server.conf
[sslConfig]
serverCert = /opt/splunk/etc/apps/sms-tls/certs/server-splunk-cert-combined.pem
sslRootCAPath = /opt/splunk/etc/apps/sms-tls/certs/cacert.pem
sslVerifyServerCert = true
splunk@splunk-test:/opt/splunk/etc/apps/sms-tls$ tree ./
./
├── certs
│ ├── cacert.pem
│ ├── server-splunk-cert-combined.pem
├── local
│ ├── inputs.conf
│ └── server.conf
└── metadata
└── local.meta
cp_log_export add name splunk target-server 10.5.1.191 target-port 6514 /
protocol tcp format splunk
NOTE: All the arguments above are customizable; see the Reference section for guidance on syntax.
NOTE: Though you will be prompted, do not restart the Log Exporter service yet; proceed to configure TLS.
mkdir $EXPORTERDIR/targets/splunk/tls
vi $EXPORTERDIR/targets/splunk/targetConfiguration.xml
<transport>
<security></security>
<!--clear/tls-->
<!-- the following section is relevant only if <security> is tls -->
<pem_ca_file></pem_ca_file>
<p12_certificate_file></p12_certificate_file>
<client_certificate_challenge_phrase></client_certificate_challenge_phrase>
</transport>
<transport>
<security>tls</security><!--clear/tls-->
<!-- the following section is relevant only if <security> is tls -->
<pem_ca_file>/opt/CPrt-R81.20/log_exporter/targets/splunk/tls/cacert.pem</pem_ca_file>
<p12_certificate_file>/opt/CPrt-R81.20/log_exporter/targets/splunk/tls/client-sms-cert.p12</p12_certificate_file>
<client_certificate_challenge_phrase>p@55w0rd</client_certificate_challenge_phrase>
</transport>
NOTE: The challenge phrase is replaced with $Encrypted$ after the Log Exporter service is restarted.
cat $EXPORTERDIR/targets/splunk/targetConfiguration.xml
cp_log_export restart name splunk
cp_log_export status
cp_log_export show
index="main" 10.5.1.100
Log Exporter (Check Point SMS) logs:
Destination log server (Splunk) logs:
Packet capture (from Splunk’s perspective):
NOTE: These steps were validated on Ubuntu 22.04 using syslog-ng.
NOTE: The following steps assume a directory structure of /etc/syslog-ng.
cd /etc/syslog-ng
mkdir cert.d ca.d
cp serverkey.pem cert.d/server-syslog-key.pem
cp servercert.pem cert.d/server-syslog-cert.pem
cp cacert.pem ca.d/cacert.pem
openssl x509 -noout -hash -in ca.d/cacert.pem
root@syslog-ng:/etc/syslog-ng# openssl x509 -noout -hash -in ca.d/cacert.pem
9858a3e4
cd ca.d
ln -s cacert.pem 9858a3e4.0
Verify the new symbolic link:
root@syslog-ng:/etc/syslog-ng/ca.d# ls -l
total 4
lrwxrwxrwx 1 root root 10 Feb 23 11:18 9858a3e4.0 -> cacert.pem
-rw-r--r-- 1 root root 1204 Feb 23 11:11 cacert.pem
# Place this under "Sources"
source sms_tls_source {
network(ip(10.5.1.100) port(6514)
transport("tls")
tls( key-file("/etc/syslog-ng/cert.d/server-syslog-key.pem")
cert-file("/etc/syslog-ng/cert.d/server-syslog-cert.pem")
ca-dir("/etc/syslog-ng/ca.d"))
); };
log { source(sms_tls_source); destination(sms_tls_dest); };
# Place this under "Destinations"
destination sms_tls_dest { file("/var/log/syslog-ng/sms_tls_logs.log"); };
NOTE: The destination directory path must already exist. In this example, syslog-ng should be created with mkdir /var/log/syslog-ng.
NOTE: Modify ip(10.5.1.100) to match your SMS/log server's IP address.
systemctl restart syslog-ng
cp_log_export add name syslog-ng target-server 10.5.1.193 target-port 6514 /
protocol tcp format syslog
NOTE: All the arguments above are customizable; see the Reference section for guidance on syntax.
NOTE: Though you will be prompted, do not restart the Log Exporter service yet; proceed to configure TLS.
mkdir $EXPORTERDIR/targets/syslog-ng/tls
vi $EXPORTERDIR/targets/syslog-ng/targetConfiguration.xml
<transport>
<security></security>
<!--clear/tls-->
<!-- the following section is relevant only if <security> is tls -->
<pem_ca_file></pem_ca_file>
<p12_certificate_file></p12_certificate_file>
<client_certificate_challenge_phrase></client_certificate_challenge_phrase>
</transport>
<transport>
<security>tls</security>
<!--clear/tls-->
<!-- the following section is relevant only if <security> is tls -->
<pem_ca_file>/opt/CPrt-R81.20/log_exporter/targets/syslog-ng/tls/cacert.pem</pem_ca_file>
<p12_certificate_file>/opt/CPrt-R81.20/log_exporter/targets/syslog-ng/tls/client-sms-cert.p12</p12_certificate_file>
<client_certificate_challenge_phrase>p@55w0rd</client_certificate_challenge_phrase>
</transport>
NOTE: The challenge phrase is replaced with $Encrypted$ after the Log Exporter service is restarted.
cat $EXPORTERDIR/targets/rsyslog/targetConfiguration.xml
cp_log_export restart name syslog-ng
cp_log_export status
cp_log_export show
Finally, validate log delivery by checking the relevant log file contents on the syslog server (in this example, /var/log/syslog-ng/sms_tls_logs.log).
Log Exporter (Check Point SMS) logs:
Destination log server (syslog-ng) logs:
Packet capture (from syslog-ng’s perspective):
Log delivery using mTLS is supported, but Smart-1 Cloud must be treated as a client (source), requiring a signed certificate from a CA.
For the full set of configuration steps, refer to the section titled "Forwarding Events to SIEM" in the Smart-1 Cloud Admin Guide.
Validate a CSR:
openssl req -text -noout -verify -in csrfile.[pem|csr]
ica@ica:/etc/ssl/CA$ openssl req -text -noout -verify -in tmp.pem
Certificate request self-signature verify OK
Certificate Request:
Data:
Version: 1 (0x0)
Subject: C = US, O = CHKP-LAB, CN = 10.5.1.193
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<omitted>
Exponent: 65537 (0x10001)
Attributes:
(none)
Requested Extensions:
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
<omitted>
Validate a private key:
openssl rsa -in keyfile.[pem|key] -check
ica@ica:/etc/ssl/CA$ sudo openssl rsa -in private/cakey.pem -check
[sudo] password for ica:
Enter pass phrase for private/cakey.pem:
RSA key ok
writing RSA key
-----BEGIN PRIVATE KEY-----
<omitted>
-----END PRIVATE KEY-----
ica@ica:/etc/ssl/CA$ sudo openssl rsa -in serverkey.pem -check
[sudo] password for ica:
RSA key ok
writing RSA key
-----BEGIN PRIVATE KEY-----
<omitted>
-----END PRIVATE KEY-----
NOTE: serverkey.pem was created with -nodes, so it's considered plaintext. No passphrase is required to view the contents.
Validate a certificate:
openssl x509 -in cert.[pem|crt] -text -noout
ica@ica:/etc/ssl/CA$ openssl x509 -in cacert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
33:1c:17:aa:37:11:86:cd:9c:b2:db:1b:bb:82:35:55:9d:bc:86:71
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = CHKP-LAB, CN = 10.5.1.194
Validity
Not Before: Feb 23 01:26:19 2023 GMT
Not After : Feb 23 01:26:19 2024 GMT
Subject: C = US, O = CHKP-LAB, CN = 10.5.1.194
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<omitted>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
56:70:48:23:2E:CD:D2:9E:87:F8:13:BF:0B:89:67:8D:64:8C:10:F1
X509v3 Authority Key Identifier:
56:70:48:23:2E:CD:D2:9E:87:F8:13:BF:0B:89:67:8D:64:8C:10:F1
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
<omitted>
ica@ica:/etc/ssl/CA$ openssl x509 -in servercert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = CHKP-LAB, CN = 10.5.1.194
Validity
Not Before: Feb 23 01:37:50 2023 GMT
Not After : Feb 23 01:37:50 2024 GMT
Subject: C = US, O = CHKP-LAB, CN = 10.5.1.193
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<omitted>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
A2:55:4F:5E:D3:B7:8B:5C:C0:21:EF:4E:47:AA:A7:78:88:42:52:BD
X509v3 Authority Key Identifier:
56:70:48:23:2E:CD:D2:9E:87:F8:13:BF:0B:89:67:8D:64:8C:10:F1
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
<omitted>
Use the -dates operator to show the validity period:
$ openssl x509 -noout -dates -in ca.pem
notBefore=Jan 20 20:50:08 2023 GMT
notAfter=Aug 29 20:50:08 2028 GMT
Validate a PKCS12 file (format used by Check Point's Log Exporter for mTLS):
[Expert@ih-sms01:0]# cpopenssl pkcs12 -info -in log_exporter_source.p12
Enter Import Password: <redacted>
MAC: sha1, Iteration 2048
MAC length: 20, salt length: 8
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Bag Attributes
localKeyID: 58 BF A1 58 B2 AB F7 B0 43 05 4E C0 12 18 BD C0 D3 83 59 88
subject=C = US, O = Customer ABC, CN = 10.5.1.100
issuer=C = US, O = Check Point Software Technologies Ltd, CN = 10.5.1.85
-----BEGIN CERTIFICATE-----
<omitted>
-----END CERTIFICATE-----
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Bag Attributes
localKeyID: 58 BF A1 58 B2 AB F7 B0 43 05 4E C0 12 18 BD C0 D3 83 59 88
Key Attributes: <No Attributes>
Enter PEM pass phrase: <redacted>
Verifying - Enter PEM pass phrase: <redacted>
-----BEGIN ENCRYPTED PRIVATE KEY-----
<omitted>
-----END ENCRYPTED PRIVATE KEY-----
NOTE: The command used on Check Point appliances is cpopenssl.
Syntax for cp_log_export command:
cp_log_export add name <Name> [domain-server {mds | all}] target-server /
<HostName or IP address of Target Server> target-port <Port on Target Server> /
protocol {udp | tcp} format {syslog | splunk | cef | leef | generic | json | /
logrhythm | rsa} [<Optional Arguments>]
| User | Count |
|---|---|
| 5 | |
| 5 | |
| 5 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
Thu 21 Nov 2024 @ 02:00 PM (MST)
Denver North: Infinity External Risk Management and Harmony SaaSMon 25 Nov 2024 @ 02:00 PM (EST)
(Americas) AI Series Part 3: Maximizing AI to Drive Growth and EfficiencyTue 26 Nov 2024 @ 03:00 PM (CET)
Navigating NIS2: Practical Steps for Aligning Security and ComplianceTue 26 Nov 2024 @ 05:00 PM (CET)
Discover the Future of Cyber Security: What’s New in Check Point’s Quantum R82Mon 25 Nov 2024 @ 02:00 PM (EST)
(Americas) AI Series Part 3: Maximizing AI to Drive Growth and EfficiencyTue 26 Nov 2024 @ 03:00 PM (CET)
Navigating NIS2: Practical Steps for Aligning Security and ComplianceTue 26 Nov 2024 @ 05:00 PM (CET)
Discover the Future of Cyber Security: What’s New in Check Point’s Quantum R82Thu 21 Nov 2024 @ 02:00 PM (MST)
Denver North: Infinity External Risk Management and Harmony SaaSTue 03 Dec 2024 @ 10:00 AM (GMT)
UK Community CNAPP Training Day 1: Cloud Risk Management WorkshopWed 04 Dec 2024 @ 10:00 AM (GMT)
UK Community CNAPP Training Day 2: Cloud Risk Management Workshop
