Sentinel Data connector Syslog CEF is a feature that allows you to collect data from various sources using the Common Event Format (CEF) or Syslog protocols and send it to Azure Sentinel, a cloud-native security information and event management (SIEM) solution. By using this connector, you can integrate your existing security tools and devices with  Sentinel and gain more visibility and insights into your network and security events.

Ingest syslog and CEF messages to Microsoft Sentinel – AMA | Microsoft Learn

The connection using this method happens over TCP/UDP 514 which is in plain text. 

However, some sources may require a secure connection to transmit data using Syslog over TLS (Transport Layer Security). This ensures that the data is encrypted and authenticated between the sender and the receiver. In this article, we will show you how to configure TLS for Syslog on a Linux machine and connect it to Azure Sentinel using the Sentinel Data connector for CEF.

There are two scenarios where there will be a need to establish encrypted connection between data sources and Syslog CEF log collector.

Third party data sources mandate use of TLS connection to send syslog events.
Customer wants to leverage TLS connection to secure data over public Internet.

For example, if we look at existing Sentinel data connector for Mcafee ePO(McAfee ePolicy Orchestrator (ePO)), it talks about deploying Linux machine with Syslog and then deploying the OMS agent.  But Mcafee ePO mandates use of TLS connection between Mcafee ePO and Syslog collector. The Sentinel data connector does not guide on using TLS connection and related configuration.

Configuration TLS for Syslog

To address this requirement , you have to configure syslog collector  to accept TLS connection from data sources like Mcafee ePO by following the below steps.  This example is based on GnuTLS. 

Install the necessary packages, such as rsyslog-gnutls, on the Linux machine.

———————————————————————————–

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

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

———————————————————————————–

Note : On RHEL system you must have an active subscription to RHN or you can configure a local offline repository using which “yum” package manager can install the provided rpm and it’s dependencies.

Generate or obtain the necessary certificates and keys for TLS.

To create a self-signed certificate for secure transfer of syslog, we will use certtool which is part of GnuTLS

Generate the private key

————————————————————————————

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

Generating a 2048 bit RSA private key…

[root@node ~]# ls -l

total 4

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

————————————————————————————

Now create the (self-signed) CA certificate itself. This command queries you for a number of things. Use appropriate responses. When it comes to certificate validity, keep in mind that you need to recreate all certificates when this one expires. So it may be a good idea to use a long period, eg. 3650 days (roughly 10 years). You need to specify that the certificates 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 a self signed certificate…

————————————————————————————

Please enter the details of the certificate’s distinguished name. Just press enter to ignore a field.

Validate the newly created key.

————————————————————————————

[root@node       ~]# ls -l

total 30

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

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

————————————————————————————

Note: ca-key.pem is a private key of certificate authority and ca.pem is a public key that we are going to distribute to the other nodes.

Generate machine certificate

In this step, we generate certificates for  the machine. The certificate identifies the machine to the remote peer.
Here –outfile reflects the name of the server that’s going to use the private key i.e. node-key.pem for us. This way it is easier to identify the key and the mapped node name.

————————————————————————————

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

** Note: Please use the –sec-param instead of –bits

Generating a 2048 bit RSA private key…

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

Generating a PKCS #10 certificate request...

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

Now validate the node-key.pem which we have created.

————————————————————————————

[root@node ~]# ls -l

total 60

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

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

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

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

Configure the /etc/rsyslog.d/rsyslog.conf file to enable TLS by specifying the path to the certificates and keys, and setting the appropriate parameters for the Syslog input module.

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

# make gtls driver the default

$DefaultNetstreamDriver gtls

# certificate files

$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 anon

$InputTCPServerRun 6514  # start up listener at port 10514

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

Restart the rsyslog service to apply the changes.

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

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

———————————————————————————–

Verify that the Syslog server is accepting TLS connections by sending test logs from a data source using Syslog over TLS.

You can test by using openssl command as shown below sample output.

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

[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
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = IN, CN = NODE2.example.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 C = IN, CN = NODE2.example.com
verify return: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); sigalg: RSA-SHA256
   v:NotBefore: Dec 21 11:27:11 2023 GMT; NotAfter: May  6 11:27:20 2051 GMT
—
Server certificate
—–BEGIN CERTIFICATE—–
MIIEmTCCAwGgAwIBAgIUZdKmTPtXQHMfmzI914efcqT0WZIwDQYJKoZIhvcNAQEL
TS1TT0MxJTAjBgNVBAMTHEFNQVBVTkNPTDAzLnRlY2htYWhpbmRyYS5jb20xKzAp
BgkqhkiG9w0BCQEWHGdzb2NzdXBwb3J0QHRlY2htYWhpbmRyYS5jb20wIBcNMjMx
MjIxMTEyNzExWhgPMjA1MTA1MDYxMTI3MjBaMDQxCzAJBgNVBAYTAklOMSUwIwYD
—–END CERTIFICATE—–
subject=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
—
Acceptable 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 Types: RSA sign, ECDSA sign
Requested Signature Algorithms: 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
Shared Requested Signature Algorithms: 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 signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: DH, 2048 bits
—
SSL handshake has read 2367 bytes and written 625 bytes
Verification error: unable to verify the first certificate
—
New, TLSv1.2, Cipher is DHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES128-GCM-SHA256
    Session-ID: 26844E8D6AF21FBFFA63654EDCD2052546EDB90A7B9B723A248E9C71B98FB26A
    Session-ID-ctx:
    Master-Key: CD0707D7E5671FAC435170A6745D7E87CFDED1C5A1821CDAF1F68AA3B731204D13D1A4F709484B1052CA06E63C6FCB74
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1704374155
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes
————————————————————————————-

​Microsoft Tech Community – Latest Blogs –Read More