Jump to content

itman

Most Valued Members
  • Content Count

    6,245
  • Joined

  • Last visited

  • Days Won

    173

Everything posted by itman

  1. Reflecting on my previous above Eset history posting a bit, I always viewed this as an Eset screw up. The way things should work when firewall Interactive is enabled are as follows: 1. Network Wizard is internally disabled since it is non-applicable. 2. An Eset default Ask rule as described previously is auto generated at the end of the existing rule set. As with all Eset default firewall rules, the only thing modifiable would be the Event log setting. 3. Any firewall rules created thereafter in Interactive mode would always be created prior to the generated default Ask rule. When Interactive mode is changed to another mode, the above actions would be reversed; Network Wizard enabled and default Ask rule deleted.
  2. Are you trying to enter your PIN here? You have to use the password associated with default local admin account; not the PIN number. If you never created this password previously, when asked for it safe mode don't enter anything into the password field. Just press the Enter key to continue the boot procedure. If this doesn't work, try the following:
  3. A bit of Eset history here. As I recollect, this above noted end of rule set Ask rule used to be generated automatically when the firewall was set to Interactive mode. Eset eliminated the rule when it added the Network Wizard feature; a feature I really don't care for.
  4. The only way I know of to log blocked network connections when the firewall is set to Interactive mode is to create an Ask rule to monitor any network inbound and outbound traffic for any protocol. Set the Event log level to Diagnostic - maybe. I am not sure that the Diagnostic level will write a log entry for manually responded to Ask level rules but I believe it does so for blocked activity. Otherwise, you will have to experiment with the other logging level options. The restriction with the above is the created Ask rule must always be at the end of the existing rule set. Which means every time a new firewall rule is created, this Ask rule must also be manually moved to the end of the existing rule set.
  5. That option still exists. But enabling it will cause everything to be written to all log files.
  6. One other point about Eset's exploit protection. It is limited in scope in what it protects as noted below. Also in reality, it does not focus on CVE noted vulnerabilities. As such and in regards to application software outside of the scope noted, I would not rely on Eset's exploit protection in regards to application software vulnerabilities. https://www.eset.com/int/about/technology/
  7. As far as the not patched local privilege escalation vulnerabilities, I would say the answer is no. As best as I can determine, no official CVE's have been issued for these. Eset's exploit protection protects against CVE recorded vulnerabilities. Ref.: https://www.cvedetails.com/vulnerability-list/vendor_id-10/product_id-33528/HP-Support-Assistant.html Note that the above CVE reference shows 5 vulnerabilities associated with Support Assistant. Three of these show they have been mitigated and two as partially mitigated. I can't however determine if any of these CVE's are directly related to the unmitigated vulnerabilities noted in the original posted article. As far as HP Support Solutions Framework, nothing has been listed since 2015. Ref.: https://www.cvedetails.com/product/31497/HP-Support-Solution-Framework.html?vendor_id=10
  8. At this point, I would say that something in Windows Security Center is corrupted preventing Eset from properly registering there. Also whatever the issue is, it appears that Eset is indeed being initialized in WSC correctly but Eset is not recognizing this and is creating the log entries being observed. Another possibility is there is an issue for some reason with Eset's ELAM driver. Win 10 verifies that this driver is loaded and functioning properly and this activity is factored into WCS initialization processing. There also might a permissions issue in regards to Eset being able to access WSC settings, possibly in the Registry, to properly initialize itself in WSC. I have searched for articles on how to repair WSC and have come up empty. There are articles on how to reset Windows 10 security settings back to default that you might want to try. The final alternative is to run a Win 10 Repair which will keep all your files in place. You will however have to reinstall all your apps including Eset.
  9. Correct. But you can't enable the Controlled Folder Access option if you are using a third party AV solution. WD has to be the active real-time solution in order to enable the Controlled Folder Access option.
  10. Appears to be the setting indicated in the below screen shot. Also, enabling this will most likely create log entries for all network activity; not just blocked connections:
  11. https://d4stiny.github.io/Several-Critical-Vulnerabilities-on-most-HP-machines-running-Windows/ I personally would opt for the uninstall option.
  12. You should be able to uninstall the version of Smart Security on the laptop via the way you uninstall any other app. Namely, open Control Panel -> Programs -> Uninstall a program. Reboot after the uninstall is completed. Then download the current version of Smart Security as done previously and install it on the laptop.
  13. Assuming you're using Win 10, refer to this article: https://support.microsoft.com/en-us/help/4028379/windows-10-how-to-use-remote-desktop . This also only applies to client to client PC connections. To utilize full RDP connectivity in a client to server scenario, you need to have Win 10 Professional or above installed. The Win 10 Home version does not support full RDP connectivity. An alternative here is to determine if your workplace allows remote connection via a VPN connection.
  14. I really don't don't know what you are referring to here. Windows Defender Controlled Folders option only applies if Windows Defender is the active real-time protection solution. If you have Eset installed, it is the active real-time solution and should be reflected as such in Windows Security Center. Activating the Windows Defender Periodic scanning option does not enable the Controlled Folders feature. In regards to this: I have never seen like setting. I do suspect however it might be indicative of both Eset and Windows Defender real-time scanning being enabled which should not happen if Eset was properly installed.
  15. Sadly, this issue isn't restricted to fake certs.. Legit certs. have been stolen. The attackers then proceed to sign their malware code with them. In a couple recent incidents, stolen/misappropriated driver certs. were used. Now you can't get better than that. Win 8.1/10 Secure boot will protect you here but you need to have the hardware to support it. Bottom line - anyone in "the security know" will flat out state the whole certificate concept is completely broken. But that's a topic for wilderssecurity.com or malwaretips.com posting and discussion.
  16. The above malware reference also brings up the issue if this move by FireFox/Eset to defer to the Win root CA store is the most secure thing to do?
  17. @Marcos , is Eset Online Scanner Quarantine file retained after it's associated directory is removed? If so, Eset Online Scanner Quarantine could be reinstalled. Then the previous Quarantined item restored. Reboot and see if that resolves the slow startup issue.
  18. It really appears everything is OK with Windows Security Center and Eset's registration of itself within. I would think that this flickering you are observing is more related to an issue with your graphics card/chip. Or possibly an issue with the driver/s it is using.
  19. Interesting. Appears the Eset cert. in the Win root CA store got corrupted somehow. Never seen that one before. However, there are malware that have been known to deploy certmgr.msc; e.g. https://thehackernews.com/2018/07/cryptocurrency-mining-ransomware.html . Maybe something escaped your VM with all the malware testing you do?😬
  20. This is the standard display from Firefox when a third part root certificate is being used. It has always been displayed as such. You probably just never checked the HTTPS certificate status previously. -EDIT- The message display is slightly different now that FireFox is now deferring to the Win root CA store; i.e. security.enterprise_roots.enabled.
  21. That's strange. Really don't know why a License key would be required for an uninstall. Here's a link on how to both use and download the Eset uninstaller tool for whatever Win version you have installed: https://support.eset.com/en/kb2289-uninstall-eset-manually-using-the-eset-uninstaller-tool . Note this must be run in Win Safe mode. Note: If this is a Win XP device, the OS needs to be upgraded to use any current Eset product. Once that hopefully successfully completes, boot back into normal Win startup mode. Download the current version of Smart Security Premium from here: https://www.eset.com/int/home/smart-security/download/ and install it. Then use the upgraded License key you purchased to activate it.
  22. Based on the screenshot you posted here: https://forum.eset.com/topic/23125-certificate-issues-for-firefox-740-64bit/?do=findComment&comment=111963 and per @SeriousHoax previous reply to you, Eset's cert. is being used by FireFox w/o issue. So I really don't know what leads you to believe it is not.
  23. I have a theory of what is going one here. It manifests when multiple Eset root CA certificates exist in the Windows root CA certificate store. Eset's root CA certificate is signed with a private key. That key is stored somewhere in the directories Eset creates at installation time. Whatever Eset certificate FireFox is extracting from the multiple ones stored in the Windows root CA certificate store has a private key that does not match the one currently stored in the applicable Eset directory. Hence use of the certificate extracted is rejected by FireFox. I would assume that the latest dated Eset root certificate in the Windows root CA certificate store is the one being used by the current Eset installation but there is no guarantee that is the case. Refer to the below screen shot: 1. Open Eset GUI and navigate to Web and Email settings. 2. Open SSL/TLS settings. 3. Under Root Certificate section, mouse click on "View certificate." 4. Mouse click on the Details tab. 5. Scroll down to a line named Thumbprint. Mouse click on it which will duplicate the value to the box below it. Copy that thumbprint value and save it somewhere. 6. Exit the Eset GUI. 7. Enter certmgr.msc in Win 10 desktop Search bar. 8. Open certmgr. Then open Trusted Root Certification Authorities -> Certificates. 9. Now compare the prior saved Eset cert. thumbprint to the thumbprint of all Eset certificates shown. 10. When a match on thumbprint is found, keep that certificate and delete all the other Eset certificates present. 11. Exit certmgr. At this point, FireFox should only access the remaining Eset root certificate in the Win root CA store and there should be no longer any private key issues with FireFox's use of that certificate.
  24. "To add more confusion to the mix," my FireFox updated to ver. 74.0.1.
×
×
  • Create New...