ERA Error Log

[8bit 0]

I've pushed out the new agent installation .bat file to several PC's in our organization and they are able to update their virus definitions but I'm unable to 'see' them from my ERA. DNS, firewall, etc does not appear to be the issue.

Any help would be greatly appreciated. I've modified the server.city for security reasons.

 

SchedulerModule	2018-Jul-06 19:09:28	Received message: RegisterSleepEvent
AutomationModule	2018-Jul-06 19:10:03	Trigger: Tick ALLOWED [UUID=00000000-0000-0000-7006-000000000001, TYPE=REPLICATION].
AutomationModule	2018-Jul-06 19:10:03	Task: Executing task [UUID=00000000-0000-0000-7005-000000000001, TYPE=Replication, CONFIG=scenarioType: REGULAR linkData { dataLimit: 1024 isDisabled: false connections { host: "server.domain" port: 2222 } }].
CReplicationModule	2018-Jul-06 19:10:03	CReplicationManager: Processing client replication task message
CReplicationModule	2018-Jul-06 19:10:03	CReplicationManager: Initiating replication connection to 'host: "server.domain" port: 2222' (scenario: Regular, data limit: 1024KB)
SchedulerModule	2018-Jul-06 19:10:03	Received message: GetRemainingTimeByUserDataRequest
NetworkModule	2018-Jul-06 19:10:03	Received message: CreateConnectionRequest
NetworkModule	2018-Jul-06 19:10:03	Attempting to connect to endpoint: 192.168.1.22
NetworkModule	2018-Jul-06 19:10:03	Socket connected.
NetworkModule	2018-Jul-06 19:10:03	Socket connection (isClientConnection:1) established for id 9971
NetworkModule	2018-Jul-06 19:10:03	Sending: VerifyUserRequest
CAgentSecurityModule	2018-Jul-06 19:10:03	Verifying certificated user from host server.domain
CAgentSecurityModule	2018-Jul-06 19:10:03	Creating replication server user
NetworkModule	2018-Jul-06 19:10:03	Receiving: VerifyUserResponse
NetworkModule	2018-Jul-06 19:10:03	Connection closed by remote peer for session id 9971
NetworkModule	2018-Jul-06 19:10:03	Forcibly closing sessionId:9971, isClosing:0
NetworkModule	2018-Jul-06 19:10:03	Removing session 9971
NetworkModule	2018-Jul-06 19:10:03	Closing connection , session id:9971
CReplicationModule	2018-Jul-06 19:10:03	CReplicationManager: Replication (network) connection to 'host: "server.domain" port: 2222' failed with: Connection closed by remote peer for session id 9971
CReplicationModule	2018-Jul-06 19:10:03	CReplicationManager: Skipping fail-over scenario (missing last success replication link data)
CSystemConnectorModule	2018-Jul-06 19:10:28	StatusLog_PERFORMANCE_USER_STATUS: "Rows":[{"symbols":[{"symbol_type":453,"symbol_data":{"val_int":[1]}},{"symbol_type":447,"symbol_data":{"val_uuid":[{"uuid":"82970732-dd7e-4ea5-a99a-124016afdc88"}]}},{"symbol_type":454,"symbol_data":{"val_time_date":[{"year":2018,"month":7,"day":6,"hour":19,"minute":10,"second":28}]}},{"symbol_type":456,"symbol_data":{"val_res_id":[508906757892866568]}}]}]
SchedulerModule	2018-Jul-06 19:10:28	Received message: RegisterSleepEvent
AutomationModule	2018-Jul-06 19:11:03	Trigger: Tick ALLOWED [UUID=00000000-0000-0000-7006-000000000001, TYPE=REPLICATION].
AutomationModule	2018-Jul-06 19:11:03	Task: Executing task [UUID=00000000-0000-0000-7005-000000000001, TYPE=Replication, CONFIG=scenarioType: REGULAR linkData { dataLimit: 1024 isDisabled: false connections { host: "server.domain.com" port: 2222 } }].
CReplicationModule	2018-Jul-06 19:11:03	CReplicationManager: Processing client replication task message
SchedulerModule	2018-Jul-06 19:11:03	Received message: GetRemainingTimeByUserDataRequest
CReplicationModule	2018-Jul-06 19:11:03	CReplicationManager: Initiating replication connection to 'host: "server.domain.com" port: 2222' (scenario: Regular, data limit: 1024KB)
NetworkModule	2018-Jul-06 19:11:03	Received message: CreateConnectionRequest
NetworkModule	2018-Jul-06 19:11:03	Attempting to connect to endpoint: 192.168.1.22
NetworkModule	2018-Jul-06 19:11:03	Socket connected.
NetworkModule	2018-Jul-06 19:11:03	Socket connection (isClientConnection:1) established for id 9972
NetworkModule	2018-Jul-06 19:11:03	Sending: VerifyUserRequest
CAgentSecurityModule	2018-Jul-06 19:11:03	Verifying certificated user from host server.domain
CAgentSecurityModule	2018-Jul-06 19:11:03	Creating replication server user
NetworkModule	2018-Jul-06 19:11:03	Receiving: VerifyUserResponse
NetworkModule	2018-Jul-06 19:11:03	Connection closed by remote peer for session id 9972
NetworkModule	2018-Jul-06 19:11:03	Forcibly closing sessionId:9972, isClosing:0
NetworkModule	2018-Jul-06 19:11:03	Removing session 9972
NetworkModule	2018-Jul-06 19:11:03	Closing connection , session id:9972
CReplicationModule	2018-Jul-06 19:11:03	CReplicationManager: Replication (network) connection to 'host: "server.domain" port: 2222' failed with: Connection closed by remote peer for session id 9972

[MartinK 378]

Unfortunately from client logs, it is not clear why it is not able to connection. Connection is closed by ERA Server during SSL/TLS handshake. This might be caused by rejected client certificate - are you using default certificates, or have you created new AGENT certificates with specific hostname? I would recommend to check logs on ERA Server, as they might indicate why connection are rejected.

[8bit 0]

We can mark this post as solved. I did as you suggested MartinK and checked the server logs and the problem appears to have been caused by the certificate I created for the Agent Installation. If I used the IP of the ERA server or FQDN the client's connect to ERA was closed but if I used an * it worked like a charm. 

I found a similar thread today where a few people had the exact same issue but no resolution was provided.

As long as I can use the cert where I inserted the * and it works, I would say this thread should be marked Solved.

Thank you for your help!

[MartinK 378]

47 minutes ago, 8bit said:

As long as I can use the cert where I inserted the * and it works, I would say this thread should be marked Solved.

Thank you for your help!

Using non-asterix host for AGENT certificate is not recommended because it may cause problems as you encountered, especially in environment where reverse-DNS resolving does not work, or results are not of expected value. What actually happens when AGENT connects:

• client's IP address is reverse-resolved. If there is no DNS entry, IP address is used.
• resolved client's hostname is compared with Host value in it's certificate, and it has to match in order to proceed with connections.

where critical is first part, where IP address as resolved/seen by ERA might be completely different than is IP address of client machine, for example in case client is behind NAT, or it is connecting through internet/VPN. This is why using such certificate requires advanced knowledge of network, otherwise results might be confusing. That is why I would use such hardened certificate only in environment where IP/DNS names are static, for example such certificates could be used for AGENT installed on server machines.

 

When creating ERA Server certificate, it is different -> hostname signed in certificate Host fields, and hostname where clients are connecting are both under ERA administrator's control, and it should be used to prevent possible man-in-the-midle attacks on Agent->Server communication.

[8bit 0]

Our setup is ~200 devices that all exist on our LAN on multiple subnets. 

If I understand you correctly, if I'm only connecting agents to our ERA on our LAN, then using a certificate may be overkill? Servers should use them regardless.

Am I understanding you correctly?

Also,

When creating a cert I've tried entering the ERA server's IP (static) and server name to no avail. How do I properly setup the cert? I found a guide in the ESET knowleadgebase but it was scarce on details. 

Thank you again for the excellent support!

[MartinK 378]

1 hour ago, 8bit said:

Our setup is ~200 devices that all exist on our LAN on multiple subnets. 

If I understand you correctly, if I'm only connecting agents to our ERA on our LAN, then using a certificate may be overkill? Servers should use them regardless.

Am I understanding you correctly?

I will give you simple example where limiting AGENT certificate to specific hostname/IP address makes sense: Imagine you have critical server (S1) in your infrastructure managed by ERA, and attacker (someone with administrator privileges) is able to copy whole system, or at least whole AGENT configuration. Technically it would enable attacker to deploy it's own server (S2) and connect it to ERA. In case there would be specific DNS name / IP address specified in AGENT certificate, attacker won't be able to connect it's server to ERA without affecting network, which might be problem (for example in case attacker has access only to different subnet).

 

Adding multiple values should be easy, for example following configuration:

should tie ERA to it's IP address 192.168.0.128 and specific private and public hostname. Only AGENTs configured to connect to one of these 3 values (exactly) will be able to connect.

[8bit 0]

Thank you again Martin for your help.

I'm about to pull my hair out at this point trying to create a basic Peer Cert using server name or IP. I keep getting the following error message:

"Failed to get installers: Specified certification authority certificate was not found"

I've tried the CA that was setup during installation and a new CA I created to no avail. I have another installer using a Peer cert with * for hosts and it works - 7 clients using it right now.

I'd like to use a more secure certificate than using a wildcard but for some reason I'm hitting a wall. I've searched this forum and the ESET knowleagebase and found some helpful info but nothing I do allows me to create an installer bat file successfully when I use anything but a wildcard of *

Any ideas?

[8bit 0]

Id like to start from scratch in regards to my CA and Peer Certs. What's the best course of action to do this?

I plan to push out a new Agent installer for all devices once I have this working.

Thanks for any help you can provide.

 

[MartinK 378]

15 hours ago, 8bit said:

Thank you again Martin for your help.

I'm about to pull my hair out at this point trying to create a basic Peer Cert using server name or IP. I keep getting the following error message:

"Failed to get installers: Specified certification authority certificate was not found"

I've tried the CA that was setup during installation and a new CA I created to no avail. I have another installer using a Peer cert with * for hosts and it works - 7 clients using it right now.

I'd like to use a more secure certificate than using a wildcard but for some reason I'm hitting a wall. I've searched this forum and the ESET knowleagebase and found some helpful info but nothing I do allows me to create an installer bat file successfully when I use anything but a wildcard of *

Any ideas?

So you can actually create peer certificate, just creating installers fails? When installer is requested, current SERVER's certificate (as is in SERVER configuration) is fetched, and respective CA certificate that were used to sign this certificate will be searched in ERA -> and this seems to fail. CA certificate used to sign SERVER certificate currently in use is present in ERA? Is it actually available for current ERA user in terms of access permissions?

[8bit 0]

Martin,

It's now working! I went back and created a new CA then went to settings and changed the default certificate to the newly created cert. That allowed me to created the install .bat file and so far, agents are connecting to my ERA.

Thank you for your help!

[8bit 0]

I may have spoke too soon.

My peer certs along with installers that contain a wildcard of * work but the certs and installers that use an IP address do not and all of the PC's that I've tested have access to the ERA server via IP address.

 

[MartinK 378]

10 hours ago, 8bit said:

I may have spoke too soon.

My peer certs along with installers that contain a wildcard of * work but the certs and installers that use an IP address do not and all of the PC's that I've tested have access to the ERA server via IP address.

 

In case SERVER's certificate contains only IP address, AGENT not only need network access to SERVER, but it has to be configured to use IP address to connect to SERVER. This means that when installing AGENT, you have to explicitly specify that AGENT should be connecting to IP and port, where IP must match exactly, and the same is for hostname.