Jump to content

ESET Protect 8.0.2216.0 On Debian 10-64x / SSL issues


Recommended Posts

Hey ESET Forums!

I've been trying to deploy ESET Protect on Debian 10 x64 for a few days now. I believe I'm ALMOST there. I've got the Server, MySQL, ODBC, Tomcat9, AGENT, and WEBApp installed.

It works after following the Linux Deployment guide, there are a few gotchas in the ODBC installation on Debian, the instructions cover Ubuntu fine, but for Debian, you just have to untar the ODBC and drop the libraries manually where they need to go then refresh with ldconfig. 

My problem is, that after following the install the default instance of Tomcat9 that ESET uses is then un-encrypted and listening on port 8080.

It still works! 

I then struggled to insert a self signed certificate into the running Tomcat9 instance.

It would be helpful if ESET could write up instructions for the masses on doing this. First off Tomcat9's certificate structure is mind melting with keytool. There are a LOT of gotchas with the certificate process. 

Well I FINALLY was able to install a self signed certificate into the Tomcat9 instance, and signed in ONCE and couldn't believe how overjoyed I was at overcoming that hurdle!

On a second sign in, however, I started getting all sorts of hairy errors in the console such as: Failed to Obtain License syncronization status, Failed to load tags, etc!

The whole thing is broken now! 

The tomcat9 logs have a ton of critical errors like this: 

[2021-02-11 16:01:04] [crit] Error executing GraphQL request!
[2021-02-11 16:01:04] [crit] graphql.GraphQLException: No valid query found in request
[2021-02-11 16:01:04] [crit]     at graphql.kickstart.servlet.GraphQLPostInvocationInputParser.getGraphQLInvocationInput(GraphQLPostInvocationInputParser.java:44)
 

Now I have a feeling that this is all certificate related, and somehow the connections to the MySQL DB are now sandbagged because of my self signed certificate.

My questions are as follows: Does the tomcat9 instance that ERAServer uses, need to use the ERA generated certificates which are NOT-installed initially by ERA Protect Server install script? 

How can I use my own certificate to secure the tomcat9 instance after installing?

Are the certificate alias names, or keyAlias names in the tomcat9 keystore somehow relevant to how ERAServer and need to be set to specific names to have it work?

Lastly how can I recover this install? I've been banging my head against a wall for a while trying to secure tomcat9 with TLS on 8443!

Additionally I'd like to add that the ESET documentation for the Linux install could be improved if they could expound on topics such as:

1) tomcat9 server.xml gotchas

There's a lot of confusion about what kind of server instance or connection facility tomcat uses. Is it NIO, NIO2, APR. 

A little writeup on the proper server.xml Connector directive would be helpful! I found a KB6721 for ESET Remote Administrator 7.X for Windows, but it wasn't relevant for my install.

I know why this information is so sparse, because the whole tomcat9 framework is vast and there are SO many conventions, a blurb about what ESET recommends for their tomcat9 instance would be helpful. 

For instance I spent hours looking up certificate imports against the keystore only to realize that tomcat9 now uses PCKS12 instead of JKS etc!

ESET firming up their directives standards as it applies to tomcat9 with detailed instructions and pitfalls would be helpful!

Thank you!

 

 

Link to comment
Share on other sites

Hey ESET and Forum folks.

I'm going through the install again with a fine toothed comb, and VERY CAREFULLY reading the documentation.

I believe I have somehow MISSED a TINY little step somewhere which is clobbering this install. I'm back at a fully functional ESET Protect Server with WebConsole install and everything is working.

I also believe that I somehow clobbered something ESET needs, when I dove deep into tomcat9's SSL/TLS howto.

I'm going to use a server.xml <Connection entry patterned after the KB6721 settings, and I'm going to put the PKCS12 keystore under /etc/tomcat9/.keystore and see if I can make this happen.

I'll report back with my findings and specifically where I think I went wrong on the last go-around.

 

Link to comment
Share on other sites

Hello ESET Forums,

I'm pretty sure now after several installs that what I'm experiencing is a memory exhaustion issue with tomcat9/java. Specifically with Java's GraphQL library which is what builds I'm guessing these large multi paged queries to the webconsole. 

My virtual machines have 2CPUs and 2GB of ram with swap. What I'm seeing is that the second I add TLS/SSL into the mix, the GraphQL/Java process grows beyond what the process likes in terms of speed and then none of the queries work any longer. Without TLS the GraphQL/Java process has JUST enough working set memory without having to bother with TLS so it all works.

I don't plan on ever managing more than 250 computers with this ERAServer, would ESET have any tips on optimizing Tomcat9 for tiny installations with LESS than 1000 computers? 

I saw the tech article about sizing recommendations and tried the tomcat9 option detailed here:

b.Decrease memory usage (low performance systems): JAVA_OPTS="-Xms256m -Xmx2048m"

Unfortunately it still bombs. ;)

Any help would be appreciated!

Edited by streamlan
Link to comment
Share on other sites

Same GraphQL errors on a VM with 2 processors and 4GB of RAM. 

I believe this is some sort of Tomcat9/JVM issue in Debian, because it's now happening on a system which meets all the requirements for ESET's Recommended server size for a 10,000 machine deployment.

I'm going to open a trouble ticket with ESET, as I'm under the gun in getting a customer using this new server.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...