Adhara-CS
-
Posts
13 -
Joined
-
Last visited
Posts posted by Adhara-CS
-
-
Hi all,
We are trying to make the ERA server and agents to run as dynamically as possible, by that we mean:
We do have several group of users that don't have the right to the same ESET products and do have different policies applyed...
Therefore we:
- Generate a peer certificate per user group
- Create a new dynamic group template per group
- Create a new dynamic group (per group) and apply the group's template
- To finish we generate an agent live installer for each user group
That way, each agent live installer has a different certificate for each group, and so: each new agent is directly connected to ERA and computer is set in the correct group (thanks to the dynamic template that is matching the peer certificate serial number).
Well the problem is that this is theory and doesn't work !
The problems we encounter:
- When the peer certificate has a password, the agent live installer setup never ends (we don't know why, we tried it on WIndows 7, 8 and 8.1)
- When the peer certificate has no password, the agent live installer works but afet er setup the new computers are still in the "Lost & Found" directory of ERA
Here is what how we did it:
Here we allready have a peer certificate per group !
Create a new dynamic group template:
- In the Web Console, navigate to Admin > Dynamic Group Templates > Click on "New Template" (down on the left).
- Click on Basic to roll out the settings page
- Enter a Name and a Description for the group template [company name - Peer Certificate detection]
- Click on Expression to roll out the settings page
- Select "+ Add rule" > click on "Peer Certificate" > "Serial number" and click on "OK"
- Back in 'Expression', paste the Peer Certificate serial number.
- Click on finish (down left of the page).
Create a new dynamic group:
- In the Web Console, navigate to Computers and click on "All" (in the left "Computers" menu bar) > New Dynamic Group.
- Click on Basic to roll out the settings page
- Enter a Nam and a Description for the group [company name]
- Click on Template to roll out the settings page
- Select choose existing and select the template you just created.
- Click on finish (down left of the page).
Create a agent live installer:
- To generate setup scripts In the Web Console, navigate to Admin > (under in the left menu) "Agent Live Installers":
- Server hostname: <OUR_SERVER_URL>
- Peer certificate: ERA certificate
- ERA certificate: Select the Peer Certificate you just created
- To finish click on "Get installers"
We really need this to work as we cannot go on moving computers in groups and setting policies for hundred or thousand computers manually.
PS: It seems to work, but only when the dynamic group is directly under "ALL", bu not when the dynamic group is in a "Static group"
Which doesn't fit our needs !
If someone has a clue about the problem, he/she will be welcome...
Thank you
-
Okay,
Thank you for the information !
-
Well, finally it doesn't seems that good !
We just noticed errors in the log file:
2015-03-23 11:01:22 Error: CReplicationModule [Thread 7f0ecd7fa700]: CStepProcessor: Replication slave stopped replication during initialization with reason: UNKNOWN_ORIGIN 2015-03-23 11:01:22 Error: CReplicationModule [Thread 7f0ecd7fa700]: CReplicationManager: Failure of scenario (type=Regular, task_id='00000000-0000-0000-7005-000000000001', link='Automatic replication (REGULAR)' (00000000-0000-0000-7007-000000000001), current_step= [], current_step_phase=, remote_peer=host: "OUR_DOMAIN" port: 2222, remote_peer_type=3, remote_peer_id=XXXXX, remote_realm_id=)
Does anyone knows what that replication process is about ?
-
Hi,
It finally works, here is explanation of what we noticed:
In the "Peer Certificates" web page, you have by default 3 certificates:
- Server Certificate
- Agent Certififcate
- Agent Certificate for server assisted installation
When using "Agent Certificate for server assisted installation" or a certificate that we had generated through web-conosle we did have the problem described previously.
But when using the standard "Agent Certificate" it works fine ! So there is really a difference between those certificates.
This means that for the ERA server itself, the "Agent Certificate for server assisted installation" seems not to work...
The remainig question is why didn't it work with another certificate generated and signed by the ERA CA..?
Best regards,
-
Hi,
This server certificate is set in ERA server configuration. We just tried to restart, but it didn't help.
Yes, that is also what we also what we understood of the problem... It is just like the peer certificate didn't match the server's certificate !
The /etc/ssl/era/Certification Authority BLABLABLA public key.der and other certs(agent.pfx, server.pfx) cert were created with the use of the webconsole.
The differences between test and production only reside in the network:
- Test uses 192.168.1.0/24 / production uses 172.16.0.0/16
- Test: Clients and server are in the same network / Production: Clients and server are on different networks (but I don't think this changes anything).
- Both run on a VM with Debian 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64
We are trying with another certificate right now (also generated with the CA in the webconsole).
-
Hi,
We will debug the situation with the points you described and keep you informed over here in this topic.
If needed we will send you the logs in Private Message.
Thank you,
-
Hi,
Thank you for your reply.
Yes, our server cetificate has been signed with the /etc/ssl/era/Certification Authority BLABLABLA public key.der file...
We also tried to use the same cetificate than the one used for client computers deployment, we still have the same error !
We have another era server on which we don't use the domain name... (only the IPs, it is all on an private network).
And we don't get that error... (all setup steps are exactly the same).
Any clue ?
-
Hi all,
As it is important to also manage the server on which "ERA Server" is installed, we are trying to install ERA Agent (on the same machine).
Our ERA server works fine, we allready hae a certain number of devices connected and managed, but when we setup this Agent it doesn't work.
For information: This Topic concerns installation on a Debian Server.
This is how we proceed:
We manually dowload (and put on the server):
- Peer certicate
- CA public key
We download the agent and make it executable:
wget hxxp://download.eset.com/download/ra/v6/standalone-installers/agent/Agent-Linux-x86_64.sh chmod +x Agent-Linux-x86_64.sh
Then we run setup:
./Agent-Linux-x86_64.sh \ --skip-license \ --cert-path="/etc/ssl/era/Certificate Export CN=Agent at _ BLABLABLA.pfx" \ --cert-password="" \ --cert-auth-path="/etc/ssl/era/Certification Authority BLABLABLA public key.der" \ --hostname="OUR_ERA_DOMAIN" \ --port=2222
The agent setup ends-up fine.
But in the Agent log file we do have several suspect lines:
2015-03-19 12:20:09 Information: ERAG1ClientConnector [Thread 7ff332b6c700]: <CONNECTOR_MODULE> exception N3Era10Connectors17G1ClientConnector20no_installed_productE occurred at /mnt/builds/jenkins/workspace/ERA/release_6.1/37a27c02/src/Products/RemoteAdministrator/Src/Connectors/ERAG1ClientConnector/Agent/ProductOfflineConfiguration/UnixProducts.cpp:160. Product not installed. 2015-03-19 12:20:10 Information: CAgentSecurityModule [Thread 7ff3227fc700]: Agent peer certificate with subject 'CN=Agent at *, BLABLABLA' issued by 'CN=OUR_ER_DOMAIN, BLABLABLA' with serial number 'XXXXX' is invalid now 2015-03-19 12:20:14 Information: CReplicationModule [Thread 7ff3157fa700]: CReplicationManager: Processing client replication task message 2015-03-19 12:20:14 Information: CReplicationModule [Thread 7ff3157fa700]: CReplicationManager: Initiating replication connection to 'host: "OUR_ERA_DOMAIN" port: 2222' (scenario: Regular, data limit: 1024KB) 2015-03-19 12:20:14 Information: NetworkModule [Thread 7ff3147f8700]: Received message: CreateConnectionRequest 2015-03-19 12:20:14 Information: Kernel [Thread 7ff332b6c700]: Used memory after modules start-up is 43680 KB 2015-03-19 12:20:16 Error: CAgentSecurityModule [Thread 7ff3227fc700]: Certificated user verification failed with: NodVerifyCertificateChain failed: NodVerifyTrustResult: 6, NVT_NotTrustedRoot, X509ChainStatus: 0x10000, X509CSF_PartialChain 2015-03-19 12:20:16 Error: NetworkModule [Thread 7ff320ff9700]: Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations., ResolvedIpAddress:OUR_ERA_IP, ResolvedHostname:, ResolvedPort:2222 2015-03-19 12:20:16 Error: NetworkModule [Thread 7ff320ff9700]: Protocol failure for session id 1, error:Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations. 2015-03-19 12:20:16 Error: CReplicationModule [Thread 7ff3157fa700]: CReplicationManager: Replication (network) connection to 'host: "OUR_ERA_DOMAIN" port: 2222' failed with: Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations.
Reading this, there seems to be an error occuring when the agent tries to connect to server (as they are on same machine this is quite strange).
We don't understand why it is said that our "ERAG1ClientConnector" is invalid now... What is that connector and can it possibly be outdated ?
We tried to change the "hostname" setting during agent setup to the public or private IP and even localhost but then we have another error that indicates that certifcate and IP doesn't match (plus the actual one).
Any tips are welcome.
-
Hi all,
We are deploying the ERA 6 package on LInux (Debian 7).
The ERA server is working fine (it is installed and runs without errors), to start we would like to install the webconsole on the same server (this will be split later on).
As we are talking about security, we wanted to have the webconsole running over HTTPS, therefore this is what we did for the web console:
Downloading the era JAVA package:
wget hxxp://download.eset.com/download/ra/v6/standalone-installers/webconsole/era.war
Setup the Java packages:
sudo apt-get install openjdk-6-jdk
Setup the Apache Tomcat web server (version 6 and newer):
sudo apt-get install tomcat7
Copy the era.war file into the tomcat application folder:
sudo cp era.war /var/lib/tomcat7/webapps/
Restart the tomcat service to deploy era java file (autodeploy is active):
sudo /etc/init.d/tomcat7 restart
Install the library libtcnative (used by tomcat APR for the SSL/TLS):
apt-get install libtcnative-1
Then, changed following lines in /etc/tomcat7/server.xml:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="200" enableLookups="true" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" SSLEnabled="true" SSLProtocol="TLSv1" SSLCertificateFile="OURCRT.crt" SSLCertificateKeyFile="OURKEY.key" SSLCertificateChainFile="OURPEM.pem"/>
Uncommenting following line to enable the SSLEngine:
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
Apply changes, restarting tomcat with:
sudo /etc/init.d/tomcat7 restart
Here the webconsole works over SSL/TLS on port 8443 !
As we want to use the standard 443 port for https, we did create an IPTABLES rule to redirect port 443 to 8443:
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443
As we want to make the manager as default web app of the server, we need to add following lines to file /etc/tomcat7/server.xml inside the <Host> section:
<Context path="" docBase="era"> <WatchedResource>WEB-INF/web.xml</WatchedResource> </Context>
Apply changes, restarting tomcat with:
sudo /etc/init.d/tomcat7 restart
As IPTABLE rules are not persistent and will be deleted when server restarts, we need to install a program that will allow us to save them and make them persistent.
Install iptables-persistent:sudo apt-get install iptables-persistent
It will ask you if you want to save actual rules, select "Yes" twice and go on. This program will have created the directory /etc/iptables/ where we will store the saved rules.
Right here the webconsole is working, answering to web requests on https://OURIP/(that redirects to /webconsole automatically).
The login screens appears (well at least the graphical parts) but the little loading GIF turns for minutes (we usually need to wait 15 to 20 minutes) before showing the fields and buttons !
After the long wait the login screen appears and works fine (the CPU load goes back to nearly nothing) and the webconsole works as it should.
Looking to the logs, there seems to be no errors or warnings (not in tomcat catalina, not in eset logs), but CPU load goes up to 100%(long live Java) on one of the cores of the VM...!
The VM on which this is all running has a dual core 2,8GHz CPU with 4GB of RAM, which seems to fit the needs (according to documentation).
We are really stuck here has we have no idea where the problem comes from... It can come from the era webconsole code as from the tomcat server but we really have no clue !
If anyone can help us out, any idea is welcome.
-
Hi michalp..
Indeed, that was the problem ! The previous unsuccessfull installation may be the root cause.
May be it should be added in the Agent installation documentation errors documentation.
Thank you very much !
-
Hi,
We just checked if the sqlite database of the Agent really exists:
And it exists at:
/var/opt/eset/RemoteAdministrator/Agent/data.db
But we have no idea about how to check the:
it is corrupted or it is not ERA database
Best regards,
-
Hi all,
We are actually deploying the ERA 6 server on our Linux Debian 7.8 server to manage our licenses but we do have some troubles.
The ERA server and Web console have been installed succesfully. By that we mean that installation has ended without any problem and that we can use the web console (and generate the needed certificates).
But next step is to setup an agent on the server itself (as it seems to be needed), and that's were we actually do have problems.
From web console we donwloaded the "Agent Certificate" and the "Certificate Authority Public Key" that were generated at server installation (those that are allready listed).
Then we just run following Agent-Setup command specifying the agent certificate and CA public Key:
./Agent-Linux-x86_64.sh \ --skip-license \ --cert-path="/PATH/Certificate Export CN=Agent at _ C=US.pfx" \ --cert-auth-path="/PATH/Certification Authority CN=Server Certification Authority C=US public key.der" \ --cert-password= \ --hostname=SERVERIP \ --port=2222
Note, the pre-generated Agent Cert has no password, therefore we leave the password field blank.
But the installation fails with following error:
Database status is 'DB_INVALID'. Database cannot be upgraded, because it is corrupted or it is not ERA database.
Searching through log file, those are the last lines:
2015-03-04 10:37:23 Information: Installer: Reading database status... 2015-03-04 10:37:23 Information: DbCheckStatus: Action invoked with: --cert-auth-content "" --cert-auth-path /PATH/Certification Authority CN=Server Certification Authority C=US public key.der --cert-auth-temp-path "" --cert-content "" --cert-password ********** --cert-path /PATH/Certificate Export CN=Agent at _ C=US.pfx --cert-temp-path "" --cert-to-check-password ********** --cert-to-check-path /PATH/Certificate Export CN=Agent at _ C=US.pfx --computer-added-uuid "" --computer-group-choice DEFAULT --connection-chosen host --current-version 6.1.450.0 --db-connectors-dir /opt/eset/RemoteAdministrator/Agent/setup --db-path /var/opt/eset/RemoteAdministrator/Agent/data.db --db-scripts-dir /opt/eset/RemoteAdministrator/Agent/setup/Database --db-type SQLite --db-upgrade "" --era-lib-dir /opt/eset/RemoteAdministrator/Agent/ --hostname SERVERIP --installed-version 6.1.450.0 --log-sequence-id "" --modules-dir /var/opt/eset/RemoteAdministrator/Agent/Modules/ --port 2222 --product-guid GUID --product-name Agent --replication-interval "" --server-cert-temp-path "" --webconsole-hostname "" --webconsole-password ********** --webconsole-port 2223 --webconsole-user Administrator 2015-03-04 10:37:23 Information: Entering function: std::string Era::Setup::Common::CustomActions::CDatabaseReader::GetDatabaseStatusForEmbeddedDB(const string&, const string&, const string&) 2015-03-04 10:37:23 Information: Entering function: std::string Era::Setup::Common::CustomActions::CDatabaseReader::GetDatabaseStatus(const string&, const string&, const string&, std::stringstream&, std::vector<std::basic_string<char> >&) 2015-03-04 10:37:23 Information: DbCheckStatus: Set output property: P_DB_STATUS = DB_INVALID 2015-03-04 10:37:23 Information: DbCheckStatus: Return code: 0 2015-03-04 10:37:23 Information: Installer: Parsed output property: arg_db_status=DB_INVALID 2015-03-04 10:37:23 Information: Installer: Database read successfully. 2015-03-04 10:37:23 Information: Installer: Database status is 'DB_INVALID' 2015-03-04 10:37:23 Information: Installer: Database status is 'DB_INVALID'. Database cannot be upgraded, because it is corrupted or it is not ERA database.
As we can see there seems to be a problem with the database... But which one ?
Regarding following line in the logs, we assume that the Agent has its own database (an sqlite one):
--db-type SQLite
But we have no idea on what to do to debug this situation...
If someone has any idea or steps to find out what is wrong here, we would be very pleased.
Best regards,
G.
[Help/Advice] Full 100% CPU load problems with Tomcat7 and login webpage very slow
in ESET PROTECT On-prem (Remote Management)
Posted
Hi,
We did try following:
1. Update Java to the latest version
This didn't affect the CPU or RAM consumption.
2. Assign more RAM for Java, we found on other forums that high PCU consumption was caused by lack of memory.
This didn't affect the CPU consumption neither
3. change the port for connector from 8443 to to save resources for port redirection.
The CPU consumption for the redirection is so low that it didn't change either
4. try to disable autodeploy and do it manually
We couldn't do this as the concerned ERA is allready in production
5. do you have issues with http traffic as well or just with https?
As we are working on security, there is just no HTTP at all ! (disabled in tomcat)
But we found out that regarding the place from which we did connect (and the available bandwith) it did impact the behavior.
We don't get why but the longer it takes for the client's side (browser) to load the app, how more CPU is consumes on server...