Jump to content

itman

Most Valued Members
  • Content Count

    8,150
  • Joined

  • Last visited

  • Days Won

    197

Everything posted by itman

  1. Based on my testing and issues encountered when using SS 9, I have no desire to reinstall in the near future. Will my SS 8 license key work for the Endpoint 6 product? Additionally the Endpoint 6 product has features I need and that are missing in the SS product such as full wildcard support for filenames in HIPS rules.
  2. WIN 7 x64 SP1, IE 11, Eset Smart Security 8.0.319.0 This is a first. I run the firewall in interactive mode. I also have had no issues with the firewall alerting me of connection activity; until today that is. I also frequently check my WIN 7 security audit logs. I saw 20+ blocked outbound connections from IE to this IP address 63.245.216.133 using port 81 in my WIN 7 security audit log. The URL for that IP is zlb3.pub.phx1.svc.mozilla.com. I also use Thunderbird as my e-mail client. I believe I was reading an e-mail from a known personal source around the time of this outbound act
  3. I would recommend that you purchase a router with a good built-in firewall. Just ensure it has IDS protection; most do. This way any IDS attacks are stopped at the router before they even reach your PC. Also, hardware firewalls are much harder to hack and bypass. Repeated port scanning like you are experiencing is usually a prelude to a major attack on your system. -EDIT- From a posting over at www.bleepingcomputer.com, Didier Stevens who is a security guru confirms what I previously posted: If your machine was the target of a port scan, I guess your machine has a public IP addres
  4. You should first try to determine why you're getting port scanned in the first place. Do you connect to the Internet using a router or a router/modem combo with an integrated firewall? That device should prevent any kind of port scanning activity. Do you use a third party DNS provider like VeriSign, Norton, Google, etc.? How could i do that? I'm just using internet as usual. Not using anything special. just a browser. Not using any third party DNS provider. Just like you said it seems like a known spamming source. I just have to figure out how to block that IP in ESS9.
  5. You should first try to determine why you're getting port scanned in the first place. Do you connect to the Internet using a router or a router/modem combo with an integrated firewall? That device should prevent any kind of port scanning activity. Do you use a third party DNS provider like VeriSign, Norton, Google, etc.?
  6. A known spamming source. An interesting read here: hxxp://dnsamplificationattacks.blogspot.com/2013/06/ecatel-big-source-of-directedatasia.html I would just permanently block that IP address and be done with it.
  7. Thanks for the confirmation. My testing of ver. 8 HIPS rule based memory protection shows it is very good. For example, it has blocked reflective dll injection attempts into both active and suspended protected processes. I haven't tested it against process memory "hollowing" methods yet.
  8. Actually there is a simple solution to the rule ordering issue in ver. 9. Modify the HIPS GUI to allow rules to be positioned manually by the user. Most HIPS's past and present have this feature. Also add the same feature to the firewall.
  9. Yes, I stated that previously. Can't give you screen shots since I no longer have ver. 9 installed. Someone on Wilder's stated the same behavior also exists on ver. 8 where dup. rules were created in learning mode. I never ran learning mode on ver. 8 so can't vouch for that. Of much greater concern to me is the rules behavior change where all allow rules no longer precede all block rules.
  10. Will add that I have just encounter the exact opposite situation to the previous screen shots I posted. That is the issuing root CA cert. is displayed for the web page but path details show that the actual root CA is Eset's! So I can summarize that I have seen every conceivable permutation and combination in the handling of browse root certifications for the SSL protocol scanning in ver. 9. Since I don't trust this release anymore, I will be restoring my system back to ver. 8 from an image taken previous to the ver. 9 install. I consider ver. 8 to be a "rock solid" product. My adv
  11. And it gets more bizarre. Here is a screen shot that shows Eset's root cert. is used on this web page: However in reality, it is not as shown in this screen shot of the actual certificate path to the root:
  12. Will also add "the hit and miss" SSL protocol scanning issue is also occurring for my incoming Thunderbird encrypted e-mail. Some times it scans it and sometimes it doesn't as evidenced by what is shown in Eset's "statistics" for e-mail scanning.
  13. Ok, thanks. However, the firewall alert should not be showing DHCP, i.e. ports 67 and 68 for IPv4, for the service used.
  14. I just started getting an inbound network alert on this at boot time: Time;Event;Source;Target;Protocol;Rule/worm name;Application;User 10/26/2015 2:03:12 PM; Decision on allowing communication delegated to user; Source 137.135.12.16:443; Destination 192.168.1.XX:49158; TCP; Allow communication for svchost.exe/Dhcp;C:\Windows\System32\svchost.exe;NT AUTHORITY\LOCAL SERVICE First, I know of any known instance why DHCP would use port 443. Is this possibly a bug by Eset? IP 137.135.12.16 resolves to either Microsoft or Eset. Also, this appears not to be a stateful connection since
  15. I have been running ver. 9 HIPS in learning mode for two days. Thought I would do that and then switch to interactive mode after a while since I can no longer create meaningful custom rules with this version. Guess what? In learning mode, the HIPS has started creating duplicate rules! And yes, I did verify that they were indeed duplicates. So eventually switching to interactive mode after the learning period is worthless since I will be getting constant alerts for processes that were already defined. So it is obvious no one at Eset has every tested all the features of the HIPS prior to
  16. Yes, the SSL protocol scanning issue is intermittent. One time when starting IE11, my home page, att.yahoo.com, will show the Eset root cert.. On most occasions it will not. Ditto for other HTTPS web site; no Eset root cert.. Also tried changing scan setting for IE from auto to scan with no change in behavior. Eset root cert. is properly installed in IE's root CA store.
  17. You might want to create a separate topic for this issue.
  18. When I installed ver. 9, Eset asked me to logon to the Anti-Theft site . Since I have an existing Eset logon and password that was created from the ver. 8 install, I used that. After the ver. 9 installation completed, I have no issues with an Anti-Theft warning. It is disabled in Eset and the warning message is indeed enabled. So the best I can speculate is perhaps this feature somehow requires an Eset logon and password although it is disabled? Go figure?
  19. Update - I have decided to "play" with ver. 9 since I had already installed it. Exported my old settings for reference. Uninstalled the ver. 9 over ver.8 install and reinstalled ver. 9 fresh. Presently running HIPS in learning mode and will switch to interactive mode in a few days. Then I will see if I can try to incorporate some of my old custom rules. Doubt that will be possible since it appears that all rules are added at the bottom of existing rules ignoring their allow or block status. A real bummer for me since I had some real tight rules in ver. 9. Also this "fresh" install did
  20. I found the problem and it's pretty ugly. Also proves to me Eset hasn't thoroughly tested this version. Under ver. 8, allow rules executed before blocked rules. I don't know if that was because the rules were arranged in alphabetical order and executed top to bottom, etc.. In version 9, blocked rules appear interspersed with allow rules in what appears to be some random order? This issue coupled with SSL protocol scanning not working properly is the last straw for me. I will be restoring the image I took prior to ver. 9 install and plan on staying on that ver. until Eset gets their a
  21. I don't think a reinstall would help. Later yesterday, the HIPS was creating duplicate/multiple rules for the same process and activity. If it doesn't settle down today, I am going back to ver. 8. I really hate the ver. 9 interface anyway. Like others have said, modification of rules and the like in this version appear to have been made intentionally hidden and difficult. I really don't need that kind of grief and aggravation in a security product.
  22. Appears this is definitely an issue with VeriSign certificates. For example, Google search uses Eset's root cert. Also when I was using ver. 8, I would experience periodic IE 11 lock ups which I could never nail down. Now, I strongly suspect the issue was SSL protocol scanning conflicting with Versign's validation of root certificates. Presently, any site with a Versign root certificate is overriding use of Eset root cert.
  23. No, still SSL Protocol scanning issues it appears. VeriSign is my DNS provider and it appears they are overriding Eset's cert. on sites where they issued the cert. Issue manifests for instance when returning back to my home page which is att.yahoo.net for example.
  24. No way I am doing a clean install and have to recreate all my firewall and HIPS rules from scratch. I would go back to ver. 8 first. So far, no more HIPS alerts so I am hoping these initial ones were a fluke.
  25. Under ver. 8 .319, I set HIPS to Smart mode and created my own rules. Since I installed ver. 9, I am getting HIPS alerts for actions that already have existing rules. I suspect it may be related to when multiple program source application entries exist for a single target program. Or Smart mode no longer works like it did under ver. 8 with user rules added?
×
×
  • Create New...