Jump to content

kapela86

Members
  • Posts

    190
  • Joined

  • Last visited

Everything posted by kapela86

  1. Marcon explained in his first answer, but you didn't understand it. Whatever you run using "Run command task" it is executed using "SYSTEM" account, so if you specify there in reg command to edit HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper, then it is acually changing "HKEY_USERS\S-1-5-18\Control Panel\Desktop\Wallpaper". A proper way to change it is using Group Policy in Active Directory (your windows computers need to have Pro edition and connected to that active directory)
  2. On https://support-eol.eset.com/en/policy_business/os_support_policy_win.html page someone used wrong order on Windows 10 versions, I'm talking about "Windows 10 Support Chart" and this: Can you change it to proper ones: Notice that I changed build number for 22H2 to correct one because someone used Win11 build number. Windows 11 versions are also wrong, can you fix it?
  3. It's nice that you added "free storage space" in Protect v10, I can see this information on updated clients in their "Details" subpage, but you can't generate report with that information as there is no such column to choose when editing template. Can you add this in future update?
  4. Solved. The problem was that some computers had old policy settings for Management Agent and some new, but I didn't force all those settings. And to answer @RagnarLK7 question, if you force this to go through proxy then Remote Host will show proxy IP
  5. Some background: We have 100+ clients, most of them are local LAN/WIFI clients and few are remote clients. We have ESET PROTECT VA and I set it up so clients connect to it using hostname (e.g "esetprotect.ourdomain.com"). On our local DNS servers I setup this hostname to point to LAN IP of our PROTECT VA, and on external DNS servers I pointed that hostname to WAN IP. Recently I made small change so that every client would use a proxy that is by default on PROTECT VA and I used hostname for proxy server. Proxy is only available on LAN IP and It's working fine, local clients use it for updates and when external clients try to connect, they can't and then use direct connection to eset update servers. And the issue is: I recently noticed in ESET PROTECT that for some clients the column "Remote Host" shows LAN IP of PROTECT VA instead of real client's LAN IP. This didn't happen when they weren't using proxy. I think it's some kind of bug in PROTECT.
  6. Thanks for explanation. I still think it would be viable to change update procedure. Eset should detect that it can't connect to proxy and switch to direct connection immediately. That way the whole process should be much faster, I know that 99,99% of users won't notice the difference.
  7. But this is not a problem with "ESET can't connect to update server", it a problem with "ESET can't connect to proxy server". ESET should be aware that it can't connect to proxy server, but as it seems right now (like you explained) it doesn't know it and assumes it can't connect to update server and tries another one. From my perspective, it's a design flaw that can be called a bug.
  8. We have ESET PROTECT VA and we're using it's proxy without issues. I wanted to do some experiment. Using iptables on server i blocked connections from my IP to port 3128 so my PC can't connect to proxy. I wanted to check if ESET Endpoint Security (v9.1.2051.0) would really use direct connection. And what I found out during testing was very weird. When I clicked on "Check for updates", it would try to connect to proxy for ~4 minutes and after those 4 minutes it would connect directly to eset servers and update just fine. I think that 4 minutes are much too long, especially since it receives "ICMP Destination unreachable (Port unreachable)". Here's a screenshot from wireshark, you can see it constantly tries to connect to proxy, receives Destination unreachable and tries again, and again, and again, and again, instead of just doing direct connection after first failed attempt. Can you tell me something about this behavior? Is this as intended? Can it be changed? Will you classify it as a bug and fix it?
  9. You're going too far with this, it's a bug ESET PROTECT, not Endpoint/Server Security. And it's probably only display bug, because I see RDP.Attack.Bruteforce entries in Detections.
  10. When I click EDIT on a rule that has action set to "Deny" it shows "Allow" in Edit dialog. It shows like that in default rules and in custom rules.
  11. Still, my statement stands, you could consolidate/unify (don't know the correct word) version numbers.
  12. I use ESET PROTECT VA, I saw notification about update in Help menu, I ran it, it didn't mention to what version I am updating, I updated it anyway, after update I went to About and I see this: ESET PROTECT (Server), Version 9.1 (9.1.2301.0) ESET PROTECT (Web Console), Version 9.1 (9.1.292.0) So I went to https://support.eset.com/en/kb3690-which-version-of-eset-remote-administrator-or-eset-security-management-center-server-and-related-components-do-i-have and it's not there! I mentioned something like this already in but let me tell you something else: START USING PROPER CONSOLIDATED VERSION NUMBERS! Even though main "ESET PROTECT" version is 9.1.18.0, it's components versions are a total mess. Components versions should use main version as a base, so instead of Linux agent having 9.0.2141.0 and windows agent having 9.0.1141.0 they both should have 9.1.18.0 and if you updated them then they should have 9.1.18.1 etc. Starting with 9.2 you could really change this.
  13. And let me tell you another thing, I set up those same rules for Endpoint Security and it's applied on few computers in our organization, and it works, they report back those blocked urls.
  14. We currently have 8.0.12011.0. I'm 100% sure that in some previous version (6.x or 7.x) I was able to set "*" in "Web access protection > List of blocked addresses" and then in "Allowed" list I would add those that we want to allow. And it was working fine, it reported those blocked and didn't report on those allowed, I set it up with bunch of allowed urls and it was working fine. I updated to 8.x quite some time ago and just now I noticed that blocked urls (not on allow list) are not logged in "Filtered websites" and not reported back to ESET Protect. I did some testing and noticed that ESET doesn't allow to set "*" url with Logging Severity "Information" or "Warning". We have a RDS server that we only allow specific urls to visit and I was using ESET for this, but now when a new url is blocked I won't know about it! Why did you change it and why I can't force it how I want?
  15. You reminded me of "Request Configuration". I can manually request configuration on every PC, it will be tedious but still better than manually checking every PC. I checked and it shows both local andpolicy firewall rules (although on one list without knowing what is what, but that's not a problem).
  16. Is there a way to create report of local rules from every computer ? Because I added some rules on some PC and I don't want to remove them by overwriting, so I will need to add them using another policy first.
  17. I created a company wide policy in Protect and it's applied to every PC With Endpoint Security. I has many different setting, one of them are few firewall rules. I also created custom installer and in "Security Product -> Configuration policy" I selected that policy for installer. When I use that installer to install ESET, then everything from this policy is applied as intended, but those firewall rules are added as local rules, and when that ESET connects and grabs policy settings from Protect, then we end up with duplicate rules, one set from local and one set from policy. 1. Is this intended behavior? 2. Can I somehow remove local rules remotely? I have 100+ computers, I really don't want to remove them manually .
  18. Every time ESET Endpoint Security detects and removes viruses in e-mail attachments it then logs it to event log But then it gets reported to ESET Protect 4 times! Can you please fix it?
×
×
  • Create New...