zhladik

Thanks for info, I got little messy feedback from customers about problematic versions. But if I understand, fix simply reverts NODEJS to exclusion of TLS check? So state will be not optimal for javascript security, So some help for manual config accommodation will help I hope. I recommended switching on explicit check of node.exe, but we not yet tested slowdown penalty for data heavy applications...

At end of last week ESET released Internet Protect module V1475 (also may be 1475.1 have same problem ?) which caused big mass problems to NodeJS based applications including Github Testing tools etc. Topic is discused In this forum thread https://forum.eset.com/topic/40702-eset-ssl-protection-produces-an-invalid-certificate-chain-for-nodejs-apps which is accessible without registration but with broken Captcha so it is almost impossible to write to the thread. Reason of breaking of NODEJS is moving Node.exe based application to area of implicit TLS inspection. To be able to do it Eset must inject local special certificate CA to list of trusted CA certificates. Usually it is handled by Windows Certificate storage or by explicit handle of well known browsers or other handled apps. But NodeJS uses hard-coded CA list (?) and ESET overlooked this problem. Fix in V1476 of module probably simply removes nodejs from filtered TLS. But it is NOT SECURE SOLUTION. I suppose ESET tried to add filtering because malware uses javascript very often. So there is very usable to inspect TLS communication from secured computer. So as there is cookbook about manual adding of "ESET Filter CA" to list of trusted CA's let's switch TLS checking on even after fixed version revert implicit exclusion of nodejs TLS check. There is possible to use automatic script for export and add CA, I will send script to github repo https://github.com/the-last-byte/ESET-NPM-Breakage-Fix . So use it is good step to improve nodejs security. After this you can switch ESET Explicitly on check of node.exe.

Thanks for info. I looked for proper ulr's for on filed download and BTW I discovered the existence of a Full Package (4x bigger than normal one - nt64_full.msi vs nt64.msi). This can be usable on an infected PC disconnected from the Internet (?) Script for download on field on customer site with wget:

Thank you for quick answer. Yet one question: Can you please publish URL for downloading of this version installation package? May be also other older version download possibilities will be usable.

I got an automatic program update from 10.0.2034.0 to 10.0.2045.0 (I found that I configured the prerelease version update channel). But - after installation, it shows the link to the info page with old release notes of 10.0.2034.0. And nowhere on the web and this forum is info about this release. I think pushing any version without info is very bad idea, even for prerelease channel versions. Please push developers to publish pre-release info BEFORE enabling installation next time and post actual version info here... Even on testing PC is nice to know what changed and what to check for . Bad feelings is magnified by the publish date collision with MS patch Tuesday.., I was afraid of the quick hotfix of MS compatibility problems.

On several customers Win 10 installations I found some FW rules after upgrade 9.1.20560.0 to 10.0.2034.0 replaced by Strict Disable Rules without label (on cfg XML export labeled as IDS_CONFENG_GENERAL_UNTITLED_LABEL) Those rules disables all incoming TCP/UDP. It seems that upgrade replaced some rules not labeled as learned. New rules by wide disable settings also shields all rules in lower order in rules table. I was not yet verified this by reproducing on clean Windows I believe that reproducinf scenario is: - W10 with 9.x (in PCs it was probably from V8.x upgraded also). - Switch Fw to Interactive mode - Start some app which forces ESET Dialog for rule creation - upgrade to V10.x - check if rule was changed to Disable all incoming TCP/UDP May be it destroys only rules for exe binaries which are uninstalled, or served by other rules?. Lot of similar rules untouched, some replaced.But main disaster is made by shielding subsequent rules. May be there is some inconsistency inherited from older EES versions (Generally errors alerts about rules table problems is very long time persisitng BUG 😕 ). I will fill tickets ASAP, but before I will try to reproduce it on clean system. So for other users hit by this BUG - remove unlabeled FW rules, or if it is possible - better solution: clean Rules table and switch to learning mode. (cleaning of rules table is little (almost hidden) grey 180deg turn arrow icon (in V10 I see it is more contrast one used - great!)

Maybe I am wrong, But it seems that each several years someone of update files mirrors goes to inconsistent state with missing files. Now We got every several hours from some of about 150 EES clients (latest 9.1.2057.0 version) Error message about this. All update related settings in default state... So it seems that ESET does not use any consistency check script for update servers network? Or Update distribution scripts leaves incomplete copies accessible on some server? I tried to solve it on phone support, but they want to catch Log dumps. But error repeats rarely, so I can not catch it. I see that exactly same problem appeared several years ago: Probably somebody in Eset fixed by hand after few weeks mirrors inconsistency? But it is not solution. Solution is consistency check script of mirrors to avoid even rare occurrence...

But Firewall is simple rules table, If I tried to add rule for Application (Yes I know to move it to start of table), it did not unblock. Historicaly Eset FW is not nice piece of code. And it seems new developers are not able handle old code very well 😞 It is probably hooked some weird way to HIPS. And BTW - there must be somewhere table of blocked Apps - but nobody knows how to access it. And probably in several latest updates some developers tries to clean relations and screwed things totaly....

This is very old problem - It appears on different apps changes randomly but not very often. Result is always same. App is silently blocked, no rule in FW helps. Only fix is exception rule for app change detection . Eset module (HIPS - no Firewall - i just got confirmation from support person) detects app change (and valid singing of app does not help). A writes somewhere deep in eset on some inaccesible table that app must be blocked. last week i met it on 4 machines blocking Chrome, Today it appeared on Firefox... BTW I asked several times in different forums about ESET buglist or fixlist, Anybody here knows url of FIes/Bugs descrion on Eset produkts?

But just again - there are new files few minutes now - 8.1.2031.0. No announcement - binary name without version from fixed url and of course sha checksums changes without warning. Only check of install binary signing helps to trust. I thing faster (automated?) sync version number with kb3040 page will be nice. Thanks....

Sorry for bad subforum - right one is "ESET Endpoint Products". But question is quite general... Remote managements handles repository versions Info, but parsing metadata is not easy....

Hi all, As Marcos mentioned in this forum - new version of EES just released. Because I wrote scripts for automated checking of new version I got alert about it but not via version page - https://support.eset.com/en/kb3040-check-for-the-latest-version-of-your-eset-business-products, but via hash checking alerts. There is till now still old version info. Binary URL is constant link to the latest binary https://download.eset.com/com/eset/apps/business/ees/windows/latest/ees_nt64.msi. I know about metadata file on https://repository.eset.com/ but it is complex binary/json mix with all ESET products including localized versions. Is there any simpler way to get the latest version number from ESET repos/sites? Thanks Zdenek Hladik

Hello, We got to troubles with very slow Internet banking pages of "Komercni Banka". So I found option for adding web site to list of controlled pages with option where to show page - In common or in secured browser. But this does not work! Probably of precedence of hardcoded banks list? I don't understand why this function (several years implemented on home grade variants of ESET AV) is crippled this way in business variants. On home product there are three option use/ask/don't use. Here is "ask" option omitted and custom list is overloaded by hardcoded list of banks... So there is only option to switch off secure browsing at all until EST/KB solves problems...

Update: it seems now problem is fixed and last files have right date and will refresh all caches... But it is good to know - dont trust ESET update mechanism (complicated, unefective and fragile) - if long time from last update passed - try to clean caches and check updates version on ESET pages: hxxp://www.virusradar.com/en/update/info/

Hello, Today evening (about 18:20 GMT) there something wrong happened to date setting on servers for generation of control files for virus database updates. From this time RAR files have datestamp 2 days shifted to past. Date of packed config files is correct (in fact update.ver is RAR archive containing also update.ver file but text formated (BTW screwed idea!). As result update.ver stops to propagate to ESET products. I did not check all versions but at mimimum V5 and V6 products are afected. ESET products will not update until someone fixes timestamp or until file date goes over last downloaded file with correct date (2 days!!). Because updates directories structure (also very crazy - each release does have new numbered directory - big proxy bandwith waste), there will be names inconsitence which can can cause error 1106 on ESET client. temporary solution: ==================== clear all caches in path (Antivir, PROXY servers) Because in past I made actualization scripts (before ESET released own) I have lot of experience with this vasting and unreliable schema :-(