Solved

Problem adding McAfee ePo server via Syslog


Userlevel 1
Badge

We configured our McAfee ePO (5.10) server to send its logs to a syslog server and configured it in the LP accordingly. Yet, when using the “Test Syslog” Feature in McAfee ePO, the test failed. Nonetheless, we are receiving logs from the server, but they only contain gibberish.

 

LP raw logs

 

This is as far as i think not a problem with normalization, as a tcpdump also shows the log payload not being human readable.

tcpdump

I already tried to change the charset min the log m,collection policy from utf_8 to iso8559_15 and ascii, to no avail. 

 

I found following McAfee (KB87927)  document, which says:

ePO syslog forwarding only supports the TCP protocol, and requires Transport Layer Security (TLS). Specifically, it supports receivers following RFC 5424 and RFC 5425, which is known as syslog-ng. You do not need to import the certificate used by the syslog receiver into ePO. As long as the certificate is valid, ePO accepts it. Self-signed certificates are supported and are commonly used for this purpose.

 

So my current guess it that the test connection failed as the ePO is expecting the LP to encrypt the traffic, which it does not do. Yet it still started to send the LP encrypted logs (but what cert does he use), therefore the gibberish.

 

Hence my question, did anyone manage to successfully retrieve usable logs from a McAfee ePO server using Syslog, or might have any suggestion what is wrong with my configuration ?

icon

Best answer by Reinhard Vielhaber 8 September 2021, 14:59

View original

12 replies

Userlevel 4
Badge +7

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.

Userlevel 1
Badge

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 

Userlevel 4
Badge +7

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.

Userlevel 1
Badge

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. 

 

Userlevel 4
Badge +7

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.

Userlevel 1
Badge

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.

Userlevel 4
Badge +7

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.

Userlevel 4
Badge +7

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 [56399: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

 

 

Reply