Phydeauxdawg

When a user types in an address incorrectly, I get a Threat Alert triggered for the incorrect url, containing HTML/Refresh.BC trojan. Example, I type in hxxp://www.eset5.comwhich doesn't' exist, I get the threat notice. How do I stop this?

Disregard this, I was testing a lot of network monitoring software. This file is to allow linux hosts to run commands on windows servers, one of them must have put it there. I deleted the files and the errors went away.

Getting a lot of these notices from all my file servers this morning. 9/2/2016 8:23:01 AM - Module Startup scanner - Threat Alert triggered on computer XXXXXXXXX: C:\Windows\winexesvc.exe contains a variant of Win32/Winexe.B potentially unsafe application. Signature is at 14058. So far only the servers (ESET File Security 6.3.12010.0) are affected.

Mine starts two scans so yes I have the same/similar issue. My scheduled job is supposed to start at 9am but starts after I login at 8am.

Go to about:config search for security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha Set them both to false. ESET will definitely have to address their certificate in a future patch.

I have two dynamic groups, one that has old agents and one that has old anti-virus. It simply queries the installed versions and returns those computers not matching a certain version. I have a task that executes each time a client joins the dynamic group for old antivirus, but I can't assign a server task to a dynamic group for the old agents task. How do I accomplish this? The new computers show due to the active directory sync. I am trying to make the process as automated as possible.

Is it possible to schedule a monthly on-demand scan? Previously the workaround was to put in 44640 minutes, now the greatest I can go is 9999 minutes, which is just short a week. Scanning every week is overkill.

Follow step II in this KB article hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3637&actp=search&viewlocale=en_US&searchid=1425404913962 There isn't anything you need to do on the server, a proxy server just does that, it proxies (caches) requests from clients. So when client A requests an update, it goes to the proxy server and asks for a file from eset.com The proxy server will check it's own cache to see if it already has it and deliver it to the client. If it doesn't, it grabs it from eset.com, caches it, and distributes it to the client. So when Client B requests the same file, it should already be cached. This is a different process from the 5x version where it had a mirror of the updates. It's a similar process but less involved on the server side.

I should also note there isn't any additional configuration necessary, Apache will cache any request it sees so most subsequent requests pull from its cache rather than the internet.

All I did was run "/opt/apache/bin/apachectl start" I then checked the log files in the same location and it shows a lot of accesses from client computers for update checks as well as software upgrades (I pushed out a client upgrade). Watching my webfilter traffic shows that there is a great reduction in the number of clients accessing eset.com. It isn't easy to discern if all traffic had stopped as some use IP addresses instead of *.eset.com. No idea why, must be random from the client end. We still need someone from ESET to create this KB article on this to determine if it's the best practice. I haven't had time yet but from past experiences it's not difficult to create this as a "service" so it can be started on boot.

There isn't a KB article about HTTP proxy for Centos or the appliance but the appliance already has it installed, it just needs to be started.

I couldn't find one either, though I don't think there's anything special about eset's version, just find a setup guide on apache http proxy. For what it's worth, if you're running the appliance, it's already installed in /opt/apache. Just start using "/opt/apache/bin/apachectl start". You also have to open a port in the firewall (3128). Perhaps someone from ESET can clarify how to make it start on boot in addition to a permanent entry for iptables? "iptables -A INPUT -i eth0 -p tcp --dport 3128 -j ACCEPT" works until reboot. Editing /etc/iptables isnt' permanent either.

hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3637&actp=search&viewlocale=en_US&searchid=1425404913962 hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3639&actp=search&viewlocale=en_US&searchid=1425404913962

The included policies have several predefined settings for maximum security, balanced security, etc.

I fixed my own issue by looking at the server installation log under /var/log/eset/RemoteAdministrator/EraServerInstaller.log. Below is my command: ./Proxy-Linux-x86_64.sh --db-admin-password='password' --db-admin-username=root --db-driver='MySQL ODBC 5.3 Unicode Driver' --db-hostname=127.0.0.1 --db-name=era_proxy_db --db-port=3306 --db-type='MySQL Server' --db-user-password='password' --db-user-username=era --cert-path=/root/proxy.pfx --cert-password='certpassword' --cert-auth-path=/root/authority.der Also make sure you create a certificate for the proxy and export it to your machine from the web interface.

I've installed the appliance and successfully upgraded it by granting super user privileges to era (grant SUPER on *.* to era@'localhost' identified by 'eraadmin';). I upgraded the server, agent and web console. Now I want to install the proxy on the same machine if it's possible. This is the command I use: ./Proxy-Linux-x86_64.sh --db-hostname=localhost --db-admin-username=root --db-admin-password='password' --db-user-username=era --db-user-password='eraadmin' --skip-license --hostname=era --port=2222 --cert-path=/root/proxy.pfx --cert-auth-path=/root/authority.der --cert-password='certpassword' Of course replace the admin-password and cert-passwords as appropriate. It fails connecting to the database, "Error: Admin connection not working. Unable to continue." I can successfully get into mysql using the user 'era' (mysql -u era -p) and the same password as the console. Root has the same password as well. No combination seems to work. For reference I'm following page 48 of the User Guide.

I had the same issue. You need to update the web console as well. Download era.war and copy it to /var/lib/tomcat6/webapps

These are the steps that I took: 1. Download the Agents locally to a share on a server with Everyone read permissions to avoid security issues. (Go to www.eset.com, Downloads, Business, Remote Administrator 6, Standalone Installers, Select Agent, get both 32-bit and 64-bit) 2. Create a new Dynamic Template (Admin->Dynamic Templates). Under Expression, use Installed Software.Application Name = ESET Remote Administrator Agent AND Installed Software.Application version (not equal) 6.1.365.0 3. Create a new Dynamic Group (Computers -> gear -> New Dynamic Group) Choose Template->Choose Existing and pick the template we just created. 4. Create a new Client Task (Admin->Client Tasks->Operating System->Run Command) Choose Target->Dynamic Group just created in 3. Choose Trigger->Trigger Type->Joined Dynamic Group Trigger. Go to Settings->Command line to run->\\Server\share\ESETAgent.bat Below is the contents of ESETAgent.bat. It checks for 32-bit vs 64-bit and thus doesn't require separating computers. @echo off If defined ProgramFiles(x86) ( msiexec /qr /i "\\server\share\Agent_64.msi" ALLUSERS=1 REBOOT=ReallySuppress P_CONNECTION_CHOSEN=Host P_HOSTNAME=Our_Hostname P_PORT=Our_Portnumber ) else ( msiexec /qr /i "\\server\share\Agent_32.msi" ALLUSERS=1 REBOOT=ReallySuppress P_CONNECTION_CHOSEN=Host P_HOSTNAME=Our_Hostname P_PORT=Our_Portnumber ) Replace Our_Hostname and Our_Portnumber with your values.

I tried installing the shell scripts on the appliance version and it fails with a similar permissions issue as well.

Try just username, remove the domain\username