TLS for Sentinel Syslog CEF Data connector(Secure Transfer of logs to Sentinel Log analytics workspa

Sentinel Data Connector Syslog CEF is a feature that allows you to collect data from a variety of sources using the Common Event Format (CEF) or Syslog protocol and send it to Azure Sentinel, a cloud-based security information and event management (SIEM) solution. This connector allows you to integrate your existing security tools and devices with Sentinel and gain more visibility and insight into network and security events.

Collecting syslog and CEF messages in Microsoft Sentinel – AMA | microsoft run

Connections using this method are over TCP/UDP 514 in plain text.

However, some sources may require a secure connection to transmit data using Syslog over Transport Layer Security (TLS). This encrypts and authenticates data between sender and receiver. This article shows how to configure TLS for Syslog on a Linux system and connect to Azure Sentinel using the Sentinel Data connector for CEF.

There are two scenarios where you need to establish an encrypted connection between a data source and the Syslog CEF log collector.

1. Third-party data sources must use TLS connections to send syslog events.
2. Customers want to protect their data over the public Internet by leveraging TLS connections.

For example, if we look at the existing Sentinel data connector for McAfee ePolicy Orchestrator (ePO), we’ll show you how to deploy Linux systems using Syslog and then deploy the OMS agent. However, Mcafee ePO requires the use of a TLS connection between Mcafee ePO and the Syslog collector. The Sentinel data connector does not guide you through using TLS connections and related configuration.

Configuring TLS for Syslog

To address this requirement, you must configure the syslog collector to allow TLS connections from data sources such as Mcafee ePO by following the steps below. This example is based on GnuTLS.

1. Install required packages such as rsyslog-gnutls on your Linux system.

————————————- ————- ——————–

[root@node ~]# yum -y install gnutls-utils

[root@node ~]# yum -y install gnutls-utils

————————————- ————- ——————–

Note: RHEL systems require an active subscription to RHN. Alternatively, you can configure a local offline repository where the “yum” package manager can install the provided rpm and its dependencies.

1. Generate or obtain the certificates and keys needed for TLS.

We use certtool, part of GnuTLS, to generate self-signed certificates for secure transport of syslog.

Generate private key

————————————- ————- ———————

[root@node ~]# certtool –generate-privkey –outfile ca-key.pem

Generating 2048-bit RSA private key…

[root@node ~]# ls -l

Total 4

-rw——— 1 root root 5813 Apr 16 14:12 ca-key.pem

————————————- ————- ———————

Now we create the (self-signed) CA certificate itself. This command queries several things: Use appropriate responses. Regarding certificate validity, keep in mind that if this certificate expires, you will need to regenerate all certificates. Therefore, it is recommended for long-term use. That’s 3650 days (about 10 years). You must specify that the certificate belongs to an authority. The certificate is used to sign other certificates.

————————————- ————- ———————

[root@node ~]# certtool –generate-self-signed –load-privkey ca-key.pem –outfile ca.pem

Generating self-signed certificate…

————————————- ————- ———————

Enter details about the unique name of your certificate. To ignore a field, simply press Enter.

Verify the newly generated key.

————————————- ————- ———————

[root@node       ~]# ls -l

Total 30

-r——— 1 root root 5813 Apr 16 14:12 ca-key.pem

-rw-r–r– 1 root route 1143 Apr 16 14:16 ca.pem

————————————- ————- ———————

Note: ca-key.pem is the certificate authority’s private key and ca.pem is the public key to be distributed to other nodes.

Generate machine certificate

At this stage we Create certificate For machines. A certificate identifies your system to remote peers.
where –outfile reflects the name of the server that will use the private key (e.g. node-key.pem). This makes it easier to identify keys and mapped node names.

————————————- ————- ———————

[root@node ~]# certtool –generate-privkey –outfile node-key.pem –bits 2048

** Note: Use –sec-param instead of –bits.

Generating 2048-bit RSA private key…

[root@node ~]# certtool –generate-request –load-privkey node-key.pem –outfile node3-request.pem

Creating PKCS #10 certificate request….

————————————- ————- ———

Now verify the node-key.pem we created.

————————————- ————- ———————

[root@node ~]# ls -l

Total 60

-r——— 1 root root 5813 Apr 16 14:12 ca-key.pem

-rw-r–r– 1 root route 1143 Apr 16 14:16 ca.pem

-rw——— 1 root root 5826 Apr 16 14:18 node-key.pem

————————————- ————- ———

1. Configure the /etc/rsyslog.d/rsyslog.conf file to enable TLS by specifying the path to the certificate and key and setting the appropriate parameters for the Syslog input module.

————————————- ————- ———

# Set gtls driver as default

$DefaultNetstreamDriver gtls

# Certificate file

$DefaultNetstreamDriverCAFile /etc/rsyslog-keys/ca.pem

$DefaultNetstreamDriverCertFile /etc/rsyslog-keys/node-cert.pem

$DefaultNetstreamDriverKeyFile /etc/rsyslog-keys/node-key.pem

$ModLoad imtcp # TCP listener

$InputTCPServerStreamDriverMode 1 # Run driver in TLS-only mode

$InputTCPServerStreamDriverAuthMode anonymous

$InputTCPServerRun 6514 # Start listener on port 10514

————————————- ————- ———

1. Restart the rsyslog service for the changes to take effect.

————————————- ————- ———

[root@node rsyslog.d]# systemctl restart rsyslog

————————————- ————- ——————–

1. Verify that your Syslog server accepts TLS connections by sending test logs from your data source using Syslog over TLS.

You can test this using the openssl command, as shown in the sample output below.

————————————- ————- ———

[root@Node1 ~]# openssl s_client -cipher DHE-RSA-AES128-GCM-SHA256 -connect NODE2.example.com:6514
Connected (00000003)
Depth=0 C = IN, CN = NODE2.example.com
Check error:num=20:Could not obtain local issuer certificate.
Return Confirmation:1
Depth=0 C = IN, CN = NODE2.example.com
Verification error:num=21:The first certificate could not be verified.
Return Confirmation:1
Depth=0 C = IN, CN = NODE2.example.com
Return Confirmation:1
—
certificate chain
0 s:C = IN, CN = NODE2.example.com
i:C = IN, ST = Maharashtra, L = Pune, O = Company Ltd, OU = SOC, CN = NODE2.example.com, emailAddress = gsocsupport@example.com
a:PKEY: rsaEncryption, 2048(bit); Segalg: RSA-SHA256
v:NotBefore: Dec 21, 2023 11:27:11 GMT; NotAfter: May 6, 2051 11:27:20 GMT
—
server certificate
—–Start Certificate—-
MIIEmTCCAwGgaAwiBAgiUZdKmTPtXQHMfmzI914efcqT0WZIwDQYJKoZIhvcNAQEL
TS1TT0MxJTAjBgNVBAMTHEFNQVBVTkNPTDAzLnRlY2htYWhpbmRyYS5jb20xKzAp
BgkqhkiG9w0BCQEWHGdzb2NzdXBwb3J0QHRlY2htYWhpbmRyYS5jb20wIBcNMjMx
MjIxMTEyNzExWhgPMjA1MTA1MDYxMTI3MjBaMDQxCzAJBgNVBAYTAklOMSUwIwYD
—–Certificate End—-
Title=C = IN, CN = NODE2.example.com
Issuer=C = IN, ST = Maharashtra, L = Pune, O = Company Ltd, OU = SOC, CN = NODE2.example.com, emailAddress = gsocsupport@example.com
—
Accepted client certificate CA names
C = IN, ST = Maharashtra, L = Pune, O = Company Ltd, OU = SOC, CN = NODE2.example.com, emailAddress = gsocsupport@example.com
Client certificate type: RSA signed, ECDSA signed
Requested signature algorithm: RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:0x07+0x08:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:0x08+ 0x08:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512:0x01+0x02:0x03+0x02
Share request signing algorithm: RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:RSA+SHA512:RSA -PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512
Peer Signature Digest: SHA256
Peer Signature Type: RSA-PSS
Server temporary key: DH, 2048 bits
—
The SSL handshake read 2367 bytes and wrote 625 bytes.
Verification error: Unable to verify the first certificate.
—
New TLSv1.2, cipher is DHE-RSA-AES128-GCM-SHA256.
The server public key is 2048 bits.
Secure renegotiation is supported.
Compression: None
Extensions: None
No ALPN negotiated
SSL session:
Protocol: TLSv1.2
Password: DHE-RSA-AES128-GCM-SHA256
Session ID: 26844E8D6AF21FBFFA63654EDCD2052546EDB90A7B9B723A248E9C71B98FB26A
session-id-ctx:
Master Key: CD0707D7E5671FAC435170A6745D7E87CFDED1C5A1821CDAF1F68AA3B731204D13D1A4F709484B1052CA06E63C6FCB74
PSK ID: None
PSK ID Hint: None
SRP Username: None
Start time: 1704374155
Timeout: 7200 (seconds)
Verify return code: 21 (unable to verify first certificate)
Extended Master Secret: Yes
————————————- ————- ———