carmik

Are you referring to the local eset support in my country, or something else altogether?

I've followed to the best of my knowledge the information in https://help.eset.com/protect_deploy_va/11.0/en-US/va_upgrade_migrate.html#recommended in order to migrate from a CentOS 7-based VA to the new Rocky Linux-based one. On my old VA, and IIRC a couple of years ago we switched to extended security by creating custom certificate authorities and switching to SHA-256 communication. After pulling the database from the old VA, I've powered down the old VA and visited the (temporary) ip of the new server. I've entered my credentials there and the networking info (essentially the setup of the old server). Pressing submit does a VA reboot. After the boot process I'm greeted with an error in the console, stating that first time appliance configuration failed. Further below the following are mentioned: The log file /opt/appliance/log/appliance-configuration-log.txt: Setting issue ... Reading configuration ... Setting issue ... Configuring operating system password ... Configuring static IP for network adapter ... Connection 'lan0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2) Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3) Configuring hostname ... Performing initial NTP synchronisation and configuration ... 200 OK Starting database server ... Created symlink /etc/systemd/system/multi-user.target.wants/mysqld.service → /usr/lib/systemd/system/mysqld.service. mysqladmin: [Warning] Using a password on the command line interface can be insecure. Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety. Configuring database password ... mysqladmin: [Warning] Using a password on the command line interface can be insecure. Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety. Installing Server ... stty: 'standard input': Inappropriate ioctl for device ESET PROTECT on-prem Server Installer (version: 11.0.215.0), Copyright © 1992-2024 ESET, spol. s r.o. - All rights reserved. Extracting archive, please wait... Archive extracted to /tmp/tmp.iMArQdf9mL. Checking OpenSSL ... done [OpenSSL 3.0.7 1 Nov 2022] Reading previous installation settings ... failure Checking installed version... done Status of current installation is: NEW Checking database connection ... done Checking database user ... done Loading GUID ... done [GUID = c70c4a64-b7d1-41d0-bea1-6e60c55a08d2] Inserting root password ... done Skipping certificates generation. Skipping static groups synchronization scheduling. Stopping service... Preparing database upgrade ... done Upgrading database ... done Storing ports into configuration ... done Moving scripts from '/tmp/tmp.iMArQdf9mL/setup/Scripts' to /var/opt/eset/RemoteAdministrator/Server/Scripts/... done Moving ESET Modules from '/tmp/tmp.iMArQdf9mL/setup/Modules' to /var/opt/eset/RemoteAdministrator/Server/Modules/... done Creating 'config' directory path: /etc/opt/eset/RemoteAdministrator/Server Creating 'libs' directory path: /opt/eset/RemoteAdministrator/Server Creating 'data' directory path: /var/opt/eset/RemoteAdministrator/Server Creating 'Pki Cache' directory path: /var/opt/eset/RemoteAdministrator/Server/pki.eset.com/ Creating 'logs' directory path: /var/log/eset/RemoteAdministrator/Server Moving ReportTemplates from '/tmp/tmp.iMArQdf9mL/setup/ReportTemplates' to /var/opt/eset/RemoteAdministrator/Server/ReportTemplates/... done Moving LangData.dat to /var/opt/eset/RemoteAdministrator/Server/Localization/LangData.dat... done Extracting ReportPrinter files... done Creating startup configuration file /etc/opt/eset/RemoteAdministrator/Server/StartupConfiguration.ini ... done Creating config file /etc/opt/eset/RemoteAdministrator/Server/config.cfg ... done Backing up contents of /opt/eset/RemoteAdministrator/Server Copying files to target destination: /opt/eset/RemoteAdministrator/Server Copying installer to target destination: /opt/eset/RemoteAdministrator/Server/setup/installer_backup.sh File ownership set to: root:root Setting auto-start service... Generating Xauthority token... done Created symlink /etc/systemd/system/multi-user.target.wants/eraserver.service → /etc/systemd/system/eraserver.service. Installing SELinux policy... done Removed backup directory: /opt/eset/RemoteAdministrator/.Server-052709045 Product installed. Enabling port 2222 in firewall ... success success Enabling port 2223 in firewall ... success success Installing RDSensor ... ESET Rogue Detection Sensor Installer (version: 1.1.615.2), Copyright © 1992-2020 ESET, spol. s r.o. Extracting archive, please wait... Archive extracted to /tmp/tmp.vNuMNoKuP2. Generating GUID ... done [GUID = c05a4863-bdd3-4399-831c-19c5e36ae215] Checking installed version... done Status of current installation is: NEW Creating 'config' directory path: /etc/opt/eset/RogueDetectionSensor Creating 'libs' directory path: /opt/eset/RogueDetectionSensor Creating 'data' directory path: /var/opt/eset/RogueDetectionSensor Creating 'logs' directory path: /var/log/eset/RogueDetectionSensor Backing up contents of '/opt/eset/RogueDetectionSensor' Copying files to target destination: '/opt/eset/RogueDetectionSensor' Removed backup directory: '/opt/eset/.RogueDetectionSensor-315434814' Moving ESET Modules to /var/opt/eset/RogueDetectionSensor/Modules... done Moving nmap-os-db file to /etc/opt/eset/RogueDetectionSensor/nmap-os-db Moving vendors.txt file to /etc/opt/eset/RogueDetectionSensor/vendors.txt Creating config file /etc/opt/eset/RogueDetectionSensor/config.cfg ... done Setting auto-start service... Failed to get unit file state for rdsensor.service: No such file or directory Created symlink /etc/systemd/system/multi-user.target.wants/rdsensor.service → /etc/systemd/system/rdsensor.service. Installing SELinux policy... done Product installed. Installing managing agent ... stty: 'standard input': Inappropriate ioctl for device Initialized log file: /var/log/eset/RemoteAdministrator/EraAgentInstaller.log ESET Management Agent Installer (version: 11.0.503.0), Copyright © 1992-2023 ESET, spol. s r.o. - All rights reserved. Creating directories... Creating 'config' directory path: /etc/opt/eset/RemoteAdministrator/Agent Creating 'data' directory path: /var/opt/eset/RemoteAdministrator/Agent Creating 'Pki Cache' directory path: /var/opt/eset/RemoteAdministrator/Agent/pki.eset.com/ Creating 'logs' directory path: /var/log/eset/RemoteAdministrator/Agent Creating 'libs' directory path: /opt/eset/RemoteAdministrator/Agent Directories created The archive will be extracted to: /opt/eset/RemoteAdministrator/AgentInstallerData Extracting, please wait... The unpacked installer data will be moved to: /opt/eset/RemoteAdministrator/Agent Checking OpenSSL ... done [OpenSSL 3.0.7 1 Nov 2022] Checking installed version ... Status of current installation is: NEW New connection settings are 'hostname': '127.0.0.1', 'port': 2222 Checking server connection... Connection checked successfully. Getting certificate from server... It is not possible to authorize to ESET PROTECT Server with provided credentials. Cleaning up setup directories I can see some possible issues: 1) "Reading previous installation settings ... failure" <- why 2) "Status of current installation is: NEW" <- this is an upgrade, should it be stated here as new? 3) And of course the final lines: New connection settings are 'hostname': '127.0.0.1', 'port': 2222 Checking server connection... Connection checked successfully. Getting certificate from server... It is not possible to authorize to ESET PROTECT Server with provided credentials. Cleaning up setup directories '/opt/appliance/installers/Agent.sh --skip-license --cert-auto-confirm --export-fingerprint=/tmp/server_fingerprint_agent.txt --hostname='127.0.0.1' --port='2222' --replication-interval 'R/20 * * * * ? *' --create-ca --webconsole-hostname='127.0.0.1' --webconsole-port='2223' --webconsole-user='Administrator' --webconsole-password=*****' command failed with 1. Could the custom certificates of the old VA somehow be the cause of this? In my notes, I can see that I had kept a second password (key possibly) that was made during creation of the certificate authority a couple of years ago. The web page wizard did not provide any place to store that information as well.

Thank you Marcos. One more question that's keeping me from proceeding with the migrate procedure. According to a VA-to-VA migration, the instructions to follow are these ones: https://help.eset.com/protect_deploy_va/11.0/en-US/va_upgrade_migrate.html#recommended Now in these instructions and assuming that we intend to keep the same IP address, how does one go with pulling the database, as required in step 3? If both old and new VA are alive, then they should obviously have different IP addresses at the start of this process, at least until one of them is shut down. So, how should one set up the ip of the new VA, up to and including step 3 of the guide? I presume that one sets up the new VA with a different IP address up to and including step 3, and does the configuration to the IP details of the old server in step 4?

We have around 1000 clients on an ESET VA that was upgraded from time to time, reaching version 11.0.199.0. Further details: Update module 1085 (20231103) Translation support module 2003 (20240402) SysInspector module 1283 (20220614) SSL module 1082 (20231106) Push Notification Service module 1137 (20240208) Configuration module 2109.2 (20240213) The VA runs under ESXi. We want to do a migration to the new VA offered, keeping all data intact (ip address, name server etc). Our current setup had advanced security (SHA256 etc) implemented some time ago. In https://help.eset.com/protect_install/91/en-US/migrated_database_same_ip.html it is mentioned that "When migrating a database, you must migrate between instances of the same ESET PROTECT version. See our Knowledgebase article for instructions to determine the versions of your ESET PROTECT components. After completing database migration, you can perform an upgrade, if necessary, to get the latest version of ESET PROTECT." Is the DB version of the new VA architecture the same as the one we have?

I'm running ESET Protect on-premises for some years now. The server is a VA, updated to the latest version over time. Over the last months I'm having the exact same problem as described in the following thread (unfortunately closed). Studying the thread, I can see that our Apache version is probably affected: # httpd -v Server version: Apache/2.4.6 (CentOS) How can we upgrade apache alone, without breaking the VA?

(bump) Anyone from ESET care to discuss this?

(bump) Anyone from ESET care to join in?

Using an ESET VA for years now. We've got a x.y.64.0/22 private address reserved for our clients, with the gateway residing on x.y.64.1. Obviously, the range of this network is x.y.64.0 - x.y.67.255. We've got a rule Network gateways . IP gateway ≠ (not equal) x.y.64.1 and a dynamic group based on it. Still, we see some (not all) systems in this dynamic group having ip addresses like x.y.65.z, x.y.66.z, x.y.67.z, for which we have confirmed that the gateway is x.y.64.1 and, hence, should not appear in this dynamic group. We presume that the rule actually somehow involves an assumption for a /24 mask (which is not the case here) which explains why there are no systems having addresses like x.y.64.z. We reported the issue to the local ESET distributor, insisting to file this as a bug, but only mitigations have been provided (ie specify subnets, instead of the gateway address). This is a very low priority issue for us, so we have not taken any mitigating actions, but we'd appreciate if you investigated this issue and, possibly, fixed it in a future version.

Addendum: reporting the issue to the organization IT HQ did not help a lot. I've been asked to insert the ESET root certificate via the MMC and not using the installer. Two things: 1) where can I get the certificate itself to try that out? 2) I presume that the installer simply calls a cert management command to get the job done, which is not contrary to Microsoft recommendations, correct? In other words, can someone from ESET verify that the certification installation is done per MS guidelines? Even better, by which way (I'm definitely going to be asked about that).

I'm working as the IT responsible for an organization in a large WAN. ESET endpoint security is installed and TLS filtering is enabled mainly to scan secure HTTP/POP-3 traffic. Things worked just fine, until some changes in the WAN infrastructure took place. Specifically, the WAN traffic is now intercepted and scanned for malware/DLP. In order for that to be done, the IT department handling centrally the WAN has provided a root CA to be installed on all client systems, in order for them to be able to access the internet. We've installed that with a group policy and most of the time things just work as they did: if I try to see the certificate of a page, I'm informed that the root certficate is the ESET one. However, now on occasion trying to access a page throws a certificate error in the browser. Doing a refresh seems to work just fine. Additionally, some site utilizing templatres/code from other sites behave in a funny way: for example JS code does not seem to be working. Finally, we've seen a case where the same https site shows not only the ESET cert, but also a Digicom one or the cert corresponding to the central WAN. I'm figuring here that there are two certificates trying to prevail which one is going to do MITM decryption. Are the above mentioned issues expected in a setup like ours?

(bump) I should add that almost all of my (Windows) endpoints are at versions 9.1.2600.0/9.1.2603.0.

This is related to the following thread, posted half a year ago: .. in which it was mentioned that "... regarding security products, auto-updates are not enabled yet to my (@MartinK) knowledge, as there has been an hotfix release very recently to target issues that prevented global deployment. I've been encountering a similar situation. Server has been at the latest version for some time now. Agents have been gradually been automatically updated to 10.x, but not the security products themselves. Is the auto-update issue regarding security products still unsolved?

I owe you one, thanks again for your efforts.

I'm feeling I'm running around hoops here, this should be an easy and fast procedure, regardless of where you've purchased the software. I'm frankly considering switching to the either the free Bitdefender or the equivalent product to NOD32 (ie no internet security/total security bloat). Thanks for your help though mate, you really tried to help me out here.

I did not say I was unable to login. I said that I am unable to get an upgrade quote. On PC after logging in there was a button under the right part of the page, close to the auto renewal button. Pressing that threw the error in my previous post. Edit: I'd paste a screenshot from my mobile, but I receive an error when trying to login.

Thank you for doing that. Unfortunately, I'm still not offered an upgrade quote, citing the fact that I've bought the license from a partner yada yada yada...

A week has passed, any update on this?

Thanks mate!

I'm using a spam-ready email address for forums and such ID: 3AS-H4H-PWN

Under which category in web control do windows updates fall?

Yep, that did the trick! EDIT: Come to think of it, this a solution to a different problem. Ie having a block all web policy and nothing else (either no allow pages or a very small number). @Marcos's response is more on par with the OP problem. EDIT2: Approach seems to be blocking windows upates. Dang!

Just got time to re-visit this. Before going on I've stumbled into a passage of text in https://help.eset.com/ees/9/en-US/idh_page_setting_parental.html stating that: [quote]In case you want to block all webpages and leave only certain available, use URL address management.[/quote] The answer is in https://help.eset.com/ees/9/en-US/idh_config_epfw_scan_http_address_list.html and I must say this is an elegant one (but rather hidden in an obscure place). Will try it and get back.

Apart from my job function where I am the admin for around 160 endpoint security licenses with liveguard (out of the 2000 for the entire organization) I'm personally been buying eset for my family systems. Mostly 5-user/1yr Internet Security licenses, bought from Amazon.de https://www.amazon.de/-/en/dp/B07H5XLB29/ref=dsvrt_myd_asin_block The price of the package has become ludicrous to be honest, rising to around 50 euros for the package, considering I used to be able to buy it at 28-33 euros tops... Buying from reputable sources is a must, considering the scams that are ongoing (ebay etc). So I've been trying to find better prices. Even though I'm buying licenses from the German ebay, I'm using them in Greece. I tried to get a quote for a renewal, after visiting the relevant Greek ESET page at https://shop.esetgr.com/renew/?lang=el and received the following message (translated from Greek): "Incorrect data. Please try again. The information you entered does not match a license. Please go back to the previous step and check the details of the license you have entered." IIRC I had contacted the Greek support for the license and they told me that they could not "see" it. Do note that the license is happily entered on my.eset.com. Trying to ask for a renewal for the same license on the German ESET renewal page at https://buy.eset.com/de/cart/login I received a (translated) "partners mismatch dialog content" countdown from 5 to 0 and then the same again from the start. How the heck am I supposed to be able to find where I should ask for a quote? Are there other mechanisms in place?

Yes, this might work thanks.

Can't make this step happen, that's the problem. I've created a single rule (which is a block-all one) like this one: ΅What am I missing?