Jump to content

Marcos

Administrators
  • Posts

    36,111
  • Joined

  • Last visited

  • Days Won

    1,439

Posts posted by Marcos

  1. We don't know if disabling integration with AMSI and re-enabling it works. If it does but there's a problem after the next restart, this will be addressed in the next hotfix / service update of Endpoint v11 which will be available in approximately 2 months (we've released update 11.0.2044 just recently).

    Administrators can temporarily disable the appropriate application status via a policy so that the error is not reported locally on endpoints.

  2. 7 hours ago, Microbe said:

    ESET NOD32 Antivirus - See the attached file. You are correct It's weird because when i was trying to collect the logs using ESET Log Collector this error appeared. i followed your instructions. You can check it now

    Additional information:

    1. We've tried to use Hotspot, but still have exist 

    2.  2 devices are now affected by the issue. 

    If you need any furtuer logs just let me know

    Was the computer connected only through a cable? Logging was enabled for 3 seconds and 99% of the communication was via UDP:

    image.png

  3. 41 minutes ago, Microbe said:

    I found that my normal weekly scans had been scanning Archives, so I disabled that in all these latest scans as you suggested, and I guess that’s what made a big difference. I’ll make sure Archives remain disabled in future weekly scans, thanks.

    If the user has disk images and other big archives in a specific folder(s) on a disk, it'd be better just not to select this folder(s) in scan targets rather then disabling archive scanning completely.

    41 minutes ago, Microbe said:

    I noticed that the standard Smart Scan profile, by default, scans Runtime Packers, but based on the info you sent, I tried disabling that in today’s first scan as well. Then I wondered what difference it would have made if it had been enabled like in a normal Smart Scan, so I enabled it in the next scans to see how much time that added on etc. It nearly doubled the scan time! and increased the number of scanned objects by 1,279,000! so it would certainly be a bonus to exclude Runtime Packers as well as Archives. Please just confirm though that there’s no loss of system security if weekly malware scans don’t scan Runtime Packers, Gil

    Unlike archives, runtime packers are used to compress executable and make them smaller. Such files are unpacked in memory upon execution. Therefore it is not wise to disable runtime packers although the files should be still scanned / unpacked by advanced heuristics.

    41 minutes ago, Microbe said:

    When Runtime Packers were included, the scan found a variant of “EFI/CompuTrace.A” in the UEFI Partition, which has been showing up in weekly scans for some time now, but from what I can find, that doesn’t seem to be an issue of concern. Is that correct?

    As far as EFI/Computrace is concerned, we recommend creating a detection exclusion (https://support.eset.com/en/kb6567). However, you can try upgrading the UEFI firmware to the latest version available in case the vendor has removed CompuTrace in the mean time.

    41 minutes ago, Microbe said:

    I tried turning off Advanced Heuristics in today’s first scan too, to test a minimalist strategy, but I guess if it’s enabled by default in a Smart Scan, I probably shouldn’t turn that off. So I enabled it again in the other scans. Should Advanced Heuristics be enabled in weekly malware scans, ?

    Advanced heuristics is crucial for detection of malware. Disabling it would deteriorate detection capabilities by a great extent. It's always turned on by default except scan on execution.

    41 minutes ago, Microbe said:
    1. One other thing I thought may have been impacting the run-time of weekly scans was that the “Preserve Last Access Timestamp” setting was ON. It seems it’s OFF as the default in a Smart Scan profile, and I thought that might have a bearing on the process used by Smart Scan, so I’ve turned that off for all of these latest scans. Should Preserve Last Access Timestamp stay off? and would that have made any difference anyway?

    This setting is there mainly for backup programs that might consider files changed after scanning if the timestamp was not preserved.

    41 minutes ago, Microbe said:

    To be able to properly experience the benefit of “Smart” scanning, the third scan used identical parameters to the second scan, and it was run straight after the second scan (with only an annoying but unavoidable auto Windows Update happening between the two). “Enable Smart Optimization” was definitely selected in both scan profiles.

    The latter scan still took 6.5 hours, which was only 10% quicker than the previous one … so something still doesn’t feel right about “Smart” Scanning. Shouldn’t the Smart Scan have excluded almost all of the objects scanned just prior? The scans were run back-to-back, so surely the last scan should have been much, much quicker than the previous one as a Smart Scan because the digital signatures, time-stamps etc would have shown the files were clean and hadn’t been changed between the scans. Can you help me understand this please ? It seems to be a key potential performance issue.

    Complete disk scans will always take time and won't complete in a few minutes. If modules have been updated between two scans, the cache will be cleared. Otherwise it could happen that previously undetected malware for which a detection has been added in the last update would not be detected if the file was not re-scanned. With Smart optimization enabled many files will be skipped, especially those signed by Microsoft. The good news is that with v17.1 we will bring multi-thread scanning which should improve scan times on modern systems with multiple-core CPUs.

  4. The following procedure should make the communication work:

    1, Ensure that Advanced security is disabled, otherwise:
    A) Click More > Settings > Connection and click the toggle next to Advanced security.
    B) Click Save to apply the setting.
    C) Close the Console and restart the ESET PROTECT server service.
    D) Wait a few minutes after the service is started and log in to the Web Console.
    Afterwards, when Advanced security is disabled, proceed with further steps:

    2.Verify if all computers are still connecting and no other problems have occurred.

    3.Click More > Certification Authorities > New and create a new CA. The new CA is automatically sent to all client computers during the next Agent - Server connection.

    4.Create new peer certificates signed with this new CA. Create a certificate for the agent and the server (you can select it in the Product drop-down menu in the wizard).

    5.Replace your current ESET PROTECT server certificate with the new one.

    6.Create a new ESET Management Agent policy to set up your agents to use the new agent certificate:

    A) In the Connection section, click Certificate > Open certificate list and select the new peer certificate.

    B) Assign the policy to computers where you want to use the advanced security.

    C) Click Finish.

    7. Wait until all Agents have replicated and obtained new policy.

    8. Run a repair installation over ESET Inspect as described here: https://help.eset.com/ei_deploy/2.0/en-US/?get_the_certificate_from_esmc.html
    Customer can go through first steps of repair as pre-filled from original installation, and then in above mentioned point they need to create new certificate based on correct CA.

    9. After repair is finished, observe and confirm whenever Inspect console and Connectors are able to communicate, and if data from Inspect are able to reach PROTECT console.
    In case Connectors won't be able to communicate with Inspect console, re-installation of Connectors using PROTECT tasks may be necessary. This may not occur, so please, proceed based on observation.

    10. Re-enable Advanced security in PROTECT console and restart the service.

×
×
  • Create New...