Yes, EPO is one of those (few) sources that can ONLY send TLS encrypted Syslog data - LogPoint is listening for that on port 6514 by default. You somehow managed to send the encrypted traffic as if it was unencrypted data to LogPoint, and that’s also why the test connection failed.

I have used encrypted Syslog from EPO successfully with LogPoint - but you are right, the certificates need to align. There are two ways to achieve this - either you persuade the EPO server to use the LogPoint certificate when sending, or you configure the LogPoint Syslog receiver to use whatever certificates the EPO server is using to send data.

LogPoint’s TLS certificates live on the system in /opt/immune/etc/remote_connection/certificates - you can copy them from there and configure your EPO server to use those. Because they are LogPoint’s, it should then receive and decrypt that data happily.

Alternatively, you can copy the EPO server’s certificate for LogPoint to use for its Syslog connection. You might need root access, Support would be able to help you with that if necessary.

1. Copy EPO servers ssl certificate and ssl key files to some location in logpoint server, i.e. /opt/immune/storage/syslog_certificates

2. Change file permission for ssl.key to 600 (chmod 600 /opt/immune/storage/syslog_certificates/ssl.key) and ownership to loginspect:loginspect (chown -R loginspect:loginspect /opt/immune/storage/syslog_certificates/ssl.*).

3. Add the following json entry to file /opt/immune/storage/lp_services_config.json

{
  "syslog_collector": {
    "ssl_certfile": "/opt/immune/storage/syslog_certificates/ssl.crt",
    "ssl_keyfile": "/opt/immune/storage/syslog_certificates/ssl.key"
  }
}

5. Regenerate system config: /opt/immune/bin/lido /opt/immune/installed/config_updater/apps/config-updater/regenerate_all.sh

6. Configure your source to use the new certificate created above.

And I agree with anyone that would now say it’d be much nicer if this could be configured through the LogPoint GUI. I am happy to report that this is coming (I believe in the next version), but you are unfortunately a tiny bit too early for that.

Hi Nils,

thanks for your quick response. It is much appreciated.

Based on your confirmation that there is indeed something wrong with the encryption settings we dug a little further.

First, we imported the LP certificates into the Certification Store on the Windows Server running the ePO. Still no success. But doing a packet capture on the ePO server, we could see that its indeed trying to establish a TLS 1.2 connection with the LP, but it fails !!

As far as i could find out the error 40 seems to indicate that there is not a cipher available both nodes can agree upon. This is odd as the ePo sends following list to the LP

And the OpenSSL version on the LP supports some of these ciphers:

Therefor the only explaination i have is that the syslog config on the LP disables some of these ciphers or uses a different library than OpenSSL. I tried to find the config used by the Syslog collector under /opt/immune/storage/lp_services_config.json (as you mentioned it in your post), but my LP installation does not have this file.

Do you know how i can activate the ciphers in the config of the Syslog collector in LP ? I now think the problem is “only” with the supported ciphers on the LP, and has nothing to do with the certificates.

Andre 

I never had to change the ciphers and always had to just supply the correct certificate in one of the directions and things started working - but I haven’t tried since LogPoint 6.11 was released, where the underlying Ubuntu 20.04 has updated OpenSSL to 1.1.1f, which is what the Syslog Collector has been built against. This version deprecated TLSv1 and TLSv1.1. So perhaps it used to work because of our support for deprecated ciphers. But the Ciphers you listed should be the ones the Syslog Collector supports, and if they align with the EPO ones then I don't know why the two wouldn’t talk.

What port is that on? There has been a change depending on what LogPoint version you came from - some listen for secure Syslog on port 515, and newer installs listen on 6514. 

If the /opt/immune/storage/lp_services_config.json file doesn’t exist yet you can create it from scratch, only containing the lines above. Probably worth doing the same chmod / chown on it then for the key files.

I’d start with that and supply the certificates to LogPoint and then see what happens. If that still doesn’t yield success, I suggest opening a Support ticket.

Hi Nils,

i did a sslscan on the LP and can now confirm that there are very few accepted ciphers for encrypted Syslog on LP 6.11.1. For TLS1.2, which is what ePo server supports, there are only three accepted ciphers, none of them is supported by ePO.

I connected via openssl to port 6514, send some text and indeed, it was visible as a readable log in Logpoint. 

So, i think we pinpointed the problem being the list of accepted ciphers, and not with the certificates.

Leaves the question: Is there a way to configure the Syslog daemon to change the list of accepted ciphers or should i open a support ticket ?

Thanks for your help. 

We are probably now in the territory of a Support ticket being best, as we will probably need a configuration change. Feel free to reference this thread and to add me on cc when raising the ticket, I’ll be intrigued to know the outcome and am happy to help along whenever I can.

This is a known problem (at least in the meantime ) and according to LP-support a fix is proposed for the upcoming version of LogPoint. There is an “internal Jira-ticket” which I do not have access to.

Just wanted to say that the issue has been fixed in LogPoint 6.12.0. After the update the LP support had to activate some of the ciphers supported by ePo, and now we are able to see the content of the logs.

Yes, thanks for pointing that out. We cannot activate the older Ciphers by default as they are not considered safe anymore, but there is now an option to turn them back on to support ePO, at least until McAfee updates the ciphers they support. If anyone has this issue they should contact Support, as there are some changes to be made to the configuration files.

Hello,

I have the same problem with ciphers, for one remote device which send encrypted logs via syslog TCP 6514, the log-collector complains about: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher

The available ciphers on remote device are (OpenSSL notation):

• DHE-RSA-AES128-GCM-SHA256
  DHE-RSA-AES256-GCM-SHA384
  DHE-RSA-AES128-SHA256
  DHE-RSA-AES256-SHA256
  AES128-GCM-SHA256
  AES128-SHA256
  AES256-GCM-SHA384
  AES256-SHA256

How can I add the new ciphers into log-collector machine knowing that above workaround is not valid anymore, the file “/opt/immune/storage/lp_services_config.json” does not exists.

I suggest working with Support to identify what Ciphers you need and whether they can enabled after the fact...

thank you Nils, I will open a ticket to support team

one more question:

What this error means (is present on collector’s syslog service ‘current’ log file) ? What is wrong on device which send logs ?

ERROR e56399:tls_server.c:158] Error from TLS bufferevent: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error; dev_ip=x.x.x.x