Jump to content

itman

Most Valued Members
  • Content Count

    6,469
  • Joined

  • Last visited

  • Days Won

    174

Everything posted by itman

  1. Actually, that's the zipped version. Both HTTP and HTTPS eicar.com versions can be downloaded here: http://2016.eicar.org/85-0-Download.html . In any case, Eset detects both on attempted download. Looks like there is a problem - again - with the AMTSO test download web site.
  2. The most common detection of this on VT is Gen:Variant.MSILPerseus.195746. That is it's a generic detection which as a rule, yield higher false positive detection's. The only main stream AV products detecting are BitDefender and Symantec. Others, most notably Kaspersky, do not detect it. Overall, it appears this download is OK. That said, anyone using cracked software these days is in essence playing Russian roulette as far as ending up with something undesirable on your device.
  3. The problem with using the Network Wizard is it creates "permissive" rules. I question the IPv4 rule it created. As it stands now, the rule is allowing all inbound traffic from the router regardless of application being used. I would say this is a no-no.
  4. Were these firewall rules generated as a result of opening Network Wizard and selecting the Unblock tab? The first rule I have no clue since the screen shot is in German. What is the protocol used in English please. Also you have marked out the remote connection data which is required to make a determination. The second rule appears to be for inbound multicast traffic in which the Remote section should be "Trusted Zone." Problem is Eset firewall already has a default rule for this. Remove the mark-out so the detail is shown.
  5. It depends on where and what app is initiating the communication. If the patching app runs on the server and it is using port 123 to send outbound traffic to the clients, then the Local port 123 needs to be specified on the client firewall rule. The Direction rule setting is In, If the patching app runs on the client and it is using port 123 to send outbound traffic to the server, then remote port 123 needs to be specified assuming the server expects to receive inbound traffic from the clients using port 123. The Direction rule setting is Out. If continuous inbound and outbound traffic between clients and server is desired, then best to specify port 123 both in Local and Remote rule setting. The bottom line here it is the app that controls port assignments. In normal outbound traffic, a random port is selected for Local use and a specific port/s for Remote use. An inbound firewall is not needed in most cases since most network traffic is stateful. In other words when the inbound traffic response is had from a previous outbound request, it will use the same Local port assigned from the outbound request. Now if the server initiates the patching activity on the clients, the clients must specify a specific Local port; e.g. 123, since that inbound communication is not stateful; i.e. it did not originate from the client. My advice is set up the firewall rule on one client device and test server patching to that device. Adjust client firewall rule settings as needed until you achieve successful patching on that device with resultant response back to server of this state if so desired. Finally and important is all my statements to date assume all devices involved in patching activities reside within the local network. If you are attempting to patch a client device external to the local network, you have to employ the appropriate network protocol to do so; e.g. RDP, or preferably to use a VPN. If RDP is used, the Eset firewall has default rules in place to handle that activity. In this instance, the server IP address would have to be added to the Eset firewall Trusted Zone of each external client device. Also, use of port 123 is N/A if RDP is used. Additionally, RDP is the preferred server to client access method within local networks,
  6. One thing you can verify is what your existing C:\Users\%username%\AppData\ folders permissions are. As shown in the below screen shot, the limited admin account I run under has Full Control:
  7. This makes no sense whatsoever. I have all settings set to the highest level, Aggressive, and have never seen the behavior described manifest. I am running under the default limited admin account in Win 10.
  8. Thinking about this a bit more and assuming client device patching is originating from the server, no Eset firewall rules need to be created on the client devices. By default and assuming their Eset firewall filtering mode is set to Automatic, all outbound traffic from the client devices is allowed. Creating non-application based outbound traffic from the clients to the server is a security risk. If a client was infected, the attacker could can access to the server via port 123.
  9. First note that port 123 is used by Windows for time synchronization: http://www.tcp-udp-ports.com/port-123.htm . Next note that Eset has a default firewall rule to allow this activity; i.e. protocol UDP, remote and local port 123, for application, svchost.exe. The above said, your rule would be coded as: Direction - Both Protocol - TCP & UDP Local - Application - whatever you are using for this patch activity. Port - 123 Remote - Port - 123. IP address - IP address of the server. The above rule will allow all inbound and outbound TCP/UDP traffic on port 123 to and from the patch server by whatever process; i.e. .exe, performing the patching activity. Note that this rule must exist on every client device where patching activity is being performed. If patching activity is being run from the server, eliminate any application reference in the client firewall rules. Also note that with Direction of "Both" being specified on the client rules, the clients have access to the server via port 123. If this is not desired, change the Direction to "In" on the client rule. This will allow the server to access the clients but prevent the clients from accessing the server.
  10. Please specifically explain what your are trying to monitor via Eset firewall rule/s.
  11. @Marcos already answered this. The answer is no. Eset does not change file permissions. Yes. Note however there are other third party security apps such as VoodooShield that uses Win icacls.exe process to perform such activity. Much worse, it doesn't fully revert the permission modifications it made when it is uninstalled.
  12. Normal Internet network traffic is outbound. For example, some app requests requests a remote connection. For example, a browser HTTPS connection uses remote port 443. The local random port chosen by the app for this communication is in the Ephemeral port range: https://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html Once the app network traffic is received at the remote destination, it in turn sends outbound traffic from its local port 443 to the Ephemeral local port on your device that was previously assigned by the app. In other words, you receive this remote initiated network communication as inbound network traffic. Normally one will not worry about settings in the Local firewall rule section. If you refer to Eset's default firewall rules, settings for the Local section are predominately specified for protocols reserved for local subnet use.
  13. It appears to me that somehow all subdirectories under C:\Users\%username%\AppData\ have been changed to full Admin level access. This would explain why you are receiving the same Win access alerts with Eset uninstalled. Note that on Win 10, the default account setup runs as a Local Limited Admin. This means you run normally under Standard User account privileges and the OS issues a UAC prompt to allow for escalation to full Admin privileges as required.
  14. Assuming you are referring to an inbound traffic restriction, you would specify the IP address in the Remote firewall rule section. This will only allow inbound traffic from the IP address to a port specified in Local firewall rule section. Note: the Eset firewall ruleset is executed from top to bottom. If there is an existing firewall rule; default or user created, that references the Local port specified and that rule is prior to the rule being created, that inbound traffic will be allowed. Likewise, an existing application based rule that does not explicitly reference any local ports will allow inbound traffic to the above specific Local port if the app sends outbound traffic from that port.
  15. Version 10: https://support.eset.com/en/kb3678-is-my-eset-product-supported-eset-end-of-life-policy-home-products#ess Note: The last Smart Security version compatible to Win XP was ver.9. That version is no longer supported.
  16. The web is full of articles about Win 10 Update service "mysteriously" setting itself back to its default manual - triggered setting. Refer to this like article on methods to keep it permanently disabled: https://www.thewindowsclub.com/windows-10-update-enables-even-turning-off/ . Eset software itself could care less if Win Updating is enabled or not.
  17. To begin, IP address 1.1.1.1 is not an internal local subnet address. Do you mean 192.168.xxx.xxxx for example?
  18. When Eset Home/Office profile is selected, local subnet IP addresses are automatically populated to the Trusted Zone. Eset firewall default rules will used this Trusted Zone as applicable depending on the local subnet traffic being monitored. Under normal local network configurations, no IP addresses need or should be added to the Trusted Zone.
  19. More security crazy is a PC used for gaming would access the Internet w/o a secure router connection.
  20. Yes, this is the SSDP Win service I previously referenced. Is your ISP AT&T and are you using one of their provided gateway/routers? If so, who is the manufacturer of the router.
  21. Is IP address, 10.0.0.245, the IP address assigned to your router? Most of the blocked network traffic shown by Network Wizard is the result of SSDP activity. Most routers have UDP activated. The router is using SSDP; i,e, UDP protocol via port 1900 to discover devices on the network. If you are using the Eset firewall Public profile, the above inbound network traffic will be blocked by default. If this is desired behavior, you have the following choices in regards to eliminating inbound SSDP network traffic on the device: 1. Disable UDP on the router. Could bust something. 2. Disable Win SSDP service startup. 3. Create an Eset firewall rule to allow inbound UDP protocol traffic. Local settings are port 1900 with Application set to C:\Windows\System32\svchost.exe. Remote settings are IP address 10.0.0.245. 4. Let Network Wizard auto create the firewall rule by selecting the Unblock tab. Then modify the created rule to conform to the specification stated in 3).. Namely, add the IP address given to the rule's Remote IP address setting. Note: If the router has been hacked, allowing inbound port 1900 UDP traffic from it could allow an attacker remote control of your device. All such inbound traffic needs to be restricted to the local network. Allowing inbound port 1900 UDP traffic from the IP address associated with the router is a potential security risk as such.
  22. Do you expect Eset just to remove the macro code and leave the attachment as is? Don't know of any security solution that can do that.
  23. Prior to a new Proctor session, I will recommend this. Set up a webcam session with a friend or family member. Leave the session open at least as long as when the prior Proctor session terminated. If this new session terminates after let's say an hour, I have a suspicion what might be the problem.
  24. Maybe not. Below is what I received in FireFox when accessing Eset's listed business partner in Romania:
  25. Eset has a knowledge base article on how to set up Webcam access rules rules here: https://support.eset.com/en/kb7071-create-and-edit-webcam-rules-in-eset-windows-home-products . Basically it just entails setting up which apps; e.g. Skype.exe, are allow access to the WebCam device. It also appears that whatever app was being used for this Proctor session was not an issue pertaining to Eset's Webcam protection since you stated the session was active for over an hour prior to being terminated. At the beginning of the Proctor session, Eset's WebCam protection should have displayed an alert to Allow or Deny access to whatever app was running that was trying to access the Webcam. Assumed is Allow was selected. From this point on, the app being used by the Proctor session is allowed unrestricted access to the WebCam. It really appears that somehow whatever app that was using the Webcam was terminated or malfuctioned. This in turn would have caused the Webcam to stop functioning and the screen to go black. Another possibility is the Webcam session was terminated on the Proctor's device end by possibly a network issue or a malfunction on his device. Likewise, a network issue on your device might have caused the connection to be terminated.
×
×
  • Create New...