hiker86

known issue on Mac's as of 6.8.400.0, support pointed me to this thread collected some logs and took screenshots. He will let me know what the developers say. Looks like this was reported back in January, based on the thread above.

wow that is an awesome reply thank you. I agree I don't really want users to be able to control the profile or rules -- defeats the purpose of an endpoint security product. That being said, it looks like that assumption is baked into EES, there is no option to pick an adapter/network interface in that client. makes sense really. thanks again for your input, works pretty much like I would expect just wanted to makes sure I wasn't missing something

Hi @Marcos, thank you for your reply. I realize my post was a bit long, but as mentioned I raised a support ticket a few days ago and so far support has not been able to resolve the issue. Logs say "no usable rule found". I think the next step is live chat/screen sharing with support, but I was hoping someone in the community would have an idea of how to solve this. On Macs we don't get the "Trusted" profile either -- this was pointed out by the support personnel I am in contact with. I will post back if I find another solution or if support is able to help solve this.

I'm using dynamic assignment based on SSID right now. I was just wondering if a user could manually sent a different profile.

Hi, is there a way to let users manually select a firewall profile to use in the ESET endpoint security client interface? I don't see a way to do it, but it was asked by one of our Directors. thanks!

Hi, My company just purchased ESET in January, on my recommendation. I am new to the product but have used Sophos, Symantec, McAfee, and others in previous companies. ESET endpoint security is blocking connections to localhost and 127.0.0.1 for services running on the endpoint. We are pretty much all developers/system engineers so we constantly run docker or other products as we test solutions so there is good reason for doing this. I have already added the rule: Status: ALLOW Protocols: ALL Direction: TO/FROM IP address: 127.0.0.1,::1 this does not work. I've tried it in multiple profiles (public, work, home) to see if there were other rules/settings that changed between the profiles and the same problem occurred on each profile the only workaround I can figure out is to ensure all services are exposed on all interfaces ('0.0.0.0') instead of loopback/localhost and then make sure the endpoint falls into a profile that allows all local network connections. this essentially makes all services running on an endpoint exposed to the network which is not ideal. We are a consulting company so we frequently go on client networks both physically and via remote access vpn with all different levels of security. I would prefer not to expose these just as a matter of practice. Is there another way to achieve connections to services running locally? Surely this should be easily configured....if anyone has suggestions, I would welcome them. Context: I am primarily responsible for setting this up and I am stuck on this issue. I have found, interestingly that if you create a vm in VirtualBox and use a bridged adapter ESET does NOT block any of the connections -- seems like a complete loophole. I can access anything exposed from a VM on the endpoint from that computer or any computer on the network even when 'vboxnet1' falls into an untrusted network (vboxnet1 interface isn't used for bridged connections in VirtualBox) AND the wireless also falls into an untrusted network (IE. profile does not have the rule to allow all local network connections), which is the bridged adapter. Yet, I can't make localhost connections. Advice on this issue would be helpful. I have already reached out to support which has not yielded results as of yet so I thought the community might have an idea. ESET Support Personnel, Devs, and Moderators: we need a way to make rulesets that target more than just IP addresses. We ned to be able to to zone <--> zone (profile) rules and interface <--> interface rules. example: State: Allow what: ALL Direction: In/Out Interface (from/to): en0 Interface (from/to): lo0 etc... I understand the security implications of that, it would allow anything running on loopback adapter to filter through the wireless network adapter w/o any additional firewall intervention. that's basically how a SOCKS proxy works. yes malware could be written to abuse rules like that, thats what IPS/heuristics is use to prevent.