Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


tmuster2k last won the day on June 30 2016

tmuster2k had the most liked content!

Profile Information

  • Location

Recent Profile Visitors

1,478 profile views
  1. any other recommendations? Customer is no VPN so is there any other option for Agent to connect other than what is relayed in >>hxxp://support.eset.com/kb3304/ ??
  2. I get this question from time to time regarding remote clients connecting over the internet. Is there anything to worry about with this port open to the internet? Any other verbiage would be good so I can provide details.
  3. The previous response is not valid. ESET ENDPOINT Security has Web Control which has category blocking. This can be enabled and managed via policy using ERA/ESMC or locally for smaller environments.
  4. I have run into this multiple times when customers do installs over the top using All in one installer. If you just run the MSI for agent or for EEA/EES/EFS over the top it will install no problem. Also if you do push install over the top via ERA/ESCM it will work.
  5. Basically, what I would like to do is lock down the system as much as possible so that if an attack does occur, I have layers of security for the attacker to break through. In other words, I would like to whitelist individual applications to use system resources instead of blacklisting, which seems to be ESET's default approach. The firewall is the easiest to work with in that regard. If I were using iptables, my rules might look like: :INPUT DROP [2:80] :FORWARD DROP [0:0] :OUTPUT DROP [8:903] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A OUTPUT -m owner --uid-owner 0 -j ACCEPT The difference between those iptables chains and what I would want to implement is the OUTPUT whitelist being application specific, rather than user specific. This would require an attacker migrate to (or exploit) a network allowed process before being able to gain a shell into my system. Therefore, the next step is to lock down process migration. I would like to apply a similar whitelist policy to HIPS rules, allowing only programs that need access to specific resources to have them. If that can be done, even if someone runs a backdoor executable on my system, they won't be able to migrate to a process necessary to carry out the rest of the attack. That covers most defenses. What would be left would be vulnerabilities in ESET, physical attacks, vulnerabilities in allowed applications, phishing, etc. There is a problem with this approach in that all OS processes would need to be manually whitelisted so as to avoid breaking the OS. However, this does allow restricting things like Cortana from working, which might be desirable. How would I implement a system like this in ESET's policies for Windows and Linux? Windows Firewall settings make sense enough. However, the HIPS rules are missing the same up and down arrows that are present on the firewall UI. The same applies to the Linux Firewall Profile Rules as well. Below are screenshots showing the missing buttons. Also if there is any online documentation that anyone can suggest would be most helpful as well.
  • Create New...