itman
-
Posts
12,199 -
Joined
-
Last visited
-
Days Won
321
Posts posted by itman
-
-
18 minutes ago, BeanSlappers said:
Yes and still the same thing.
Something must be wrong with your FireFox installation. Again, it works fine for me on FF 67.4.
-
On 6/29/2019 at 12:51 PM, snowyowl said:
I choose allow and create the rule, well I am then alerted by ESET that it failed to create the rule and remains stuck with the popup notification.
Refer to this Eset Knowledgebase article: https://support.eset.com/kb2352/
Prior to creating the allow rule, click on the "Advanced" text located on the bottom right hand side of the alert window. Make sure the only thing checkmarked for the outbound Skype rule is the program path location.
I suspect the default rule Eset is generating might be IP address/port specific or like this and Skype is connecting each time using different ones.
-
The first alert screen shot was posted for Chrome. The second screen shot in English is for IE11. As far as the IE11 alert, it should not have been generated since go.microsoft.com web site has a valid certificate.
It appears that something is not right with your Eset installation. The installation should have installed the Eset root CA certificate in the Windows root CA certificate store. IE11 uses the Windows root CA certificate store. This also probably is the reason for the Chrome certificate alerts you are receiving.
If you have made custom changes to Eset settings, use the Eset Export feature to save those. Then uninstall Eset, reboot, and then reinstall Eset. Use the Eset Import feature to reestablish your custom settings if they were previously Exported. Now check if these previous certificate alerts reappear.
-
58 minutes ago, nlklinh said:
The strange thing is 192.168.1.105 isnt my IP after i checked my IPv4 address
Are you using a proxy server to access the Internet? Are you using a VPN?
-
Unfortunately, most can't interpret your screen shot since it's in Polish.
-
If you examine the Eset alert, it states that a server connection is being made to a device on your internal network; i.e. 192.168.1.105. Furthermore, the certificate ID appears to be a registry key location. Really never seen anything like this.
First, verify that 192.168.1.105 is your Windows assigned IP address. Open a command prompt window and enter the following:
ipconfig /all
Search for "IPv4 Address ..............." What is displayed there should be 192.168.1.105.
-
7 hours ago, Hijin25 said:
If it is advisable not to use the tool, it should only be accessible after a detection.
The problem with the tool is it will show only the area where Win settings have been alerted; not what the specific change was.
Here's an example. On my Win 10 build, I modified system restore settings to do so only for the drive it is installed on; not for all the drives I have installed. When I run the tool, it only informs me that a change has occured to System Restore settings. If I run the tool, system restore will be reset to run all my drives.
Bottom line - if you are one that makes custom mods. to Win settings, this tool will remove all your custom settings.
-
12 hours ago, BeanSlappers said:
Then if that affects it, then eset should fix it, because all these are supposed to work together.
Did you verify if Parental Controls is disabled, Eset shows an alert for AMTSO phishing test using FireFox 67.x?
-
1 minute ago, BeanSlappers said:
Works correctly with parental controls (except for image search) and nothing is in the exclusion as well.
I have Parental Controls disabled since I don't use the feature. So this might be a factor in the non-detection. Temporarily disable it and retest to see if Eset now pops up an alert and blocks it.
-
12 minutes ago, BeanSlappers said:
Im using firefox 67 and the page https://www.amtso.org/check-desktop-phishing-page/ and it does not block it.
It does for me. See the above screen shot I posted. I also just retested with the same result, Eset detects it.
Do you have SSL/TLS scanning enabled?
-
The purpose of the tool is to correct changes made by malware after a detection has been found. The tool should not be used in day to day use to verify if Win default settings are correct.
As far as not noticing changes to your desktop and the like, most of the tool's changes would be "invisible;" like changes to Win utility processes; e.g. system restore, or registry changes.
-
I will also add that there currently exists much confusion about penetration testing and AV lab testing.
Penetration testing entails the testing of vulnerabilities that exist:
1. At the external network perimeter.
2. Within the internal network.
3. For the operating system and application software installed on devices within the internal network.
Point 1). is the area most overlooked by SMBs. Most enterprise environments employ dedicated network devices; i.e. appliances to monitor the perimeter of the external network for breeches. These appliances are quite expensive and do require dedicated personnel to monitor them. The point to emphasize is this is the level most effective in preventing unwanted network intrusions.
AV labs test AV security software solutions against known malware internal network breeches. It should be noted that even the best behavioral methods available today are ineffective against never before seen malware behavior exploiting an unknown OS or app vulnerability. This is because the behavior detection methods are conditioned upon previously known malware behavior.
I am reminded of the analogy that that absolute security of any type is possible, but at the cost of making the object protected unusable for its intended purpose. Or stated another way, maximum security is the point where desired usability is not adversely affected.
-
25 minutes ago, dMn said:
I made no changes
this message comes only after install when it sets up after that no more warning messages comes
in the ui everything is green they are protected
Then and again, I wouldn't worry about those messages.
-
I believe I saw a similar message the last time I manually installed ver. 12; possibly after I imported my previously exported settings. Also, I periodically get these alerts when creating properly formatted manual rules on occasion.
If the HIPS is functioning properly after Eset installation and/or your manual rules are properly created in the HIPS, I would just ignore these Eset messages.
-
On 6/28/2019 at 7:58 PM, cutting_edgetech said:
I'm beginning to wonder if my router even has SPI. I can't find anything that says it does.
QuoteEnterprise-Level Security and Fire-wall
The GT784WN includes WPA and WPA2 encryption, and the ability to assign unique IDs to each wireless gateway to prevent hacking. It also includes a fully customizable firewall with Stateful Packet Inspection, denial of service protection, content filtering, intrusion detection, and additional encryption to prevent unwanted visitors from accessing your network.
https://www.actiontec.com/wp-content/uploads/2017/02/ActiontecGT784WNncsdatasheet.pdf
It appears there is no user manual with detailed setting explanations. The best I could find is: https://setuprouter.com/router/actiontec/gt784wnv/manual-1341.pdf . I ran into the same issue with my AT&T provided router. I had to do web research to determine the actual mfg. of the router and determine their equivalent model number. With that information, I was able to download an user manual with settings options and details.
Also there is a Verizon version of this router; if that is what you have. That version's firmware might have been modified to prevent end users from accessing the detailed protection settings options.
-EDIT- Here's a web site that shows all setting screen shots for the Verizon model: https://setuprouter.com/router/actiontec/gt784wnv/screenshots.htm .
The firewall has four settings; NAT, low, medium, and high. Click on the firewall screen shot for further details. Note the following. The default firewall security level is set to "Off". Suspect this results in only NAT being shown? I believe you may have disabled NAT in its stand-alone setting since it is not compatible with VPN? It appears the low - high firewall settings control what Win network protocols(services) and their corresponding ports are monitored.
I don't believe if the firewall is off, it would affect SPI. However, disabling NAT would expose the actual sending port used by Windows.
One thing I don't like is this router has the ability to support remote GUI andTelnet login to the router. I believe there have been multiple remote attack instances against Actiontec routers using this feature. Make sure it's preferably disabled or strong password used.
In theory, a firewall with SPI and NAT should block most unwanted inbound external network traffic. Also, SPI only works for stateful protcols; namely TCP. UDP and ICMP for example are stateless protocols. Most routers will block incoming unsolicited ICMP pings by default. So UDP is the protocol that needs attention and can be blocked effectively by simply disabling unnecessary services that use it such as UPnP.
If the router has default password of "Admin," change it to sometime more secure.
-
What is the router make and model number?
-
I agree with what @Marcos has posted.
The report is a 6 page executive summary devoid of any specific details. Assuming the vendor used the Mitre matrix for exploit reference, they most likely used known POC exploits against known vulnerabilities. The best way to protect against vulnerabilities is applying in a timely fashion, vendor provided OS and app software patches/updates. Then there is the known and documented fact that many vulnerabilities are never exploited; only a small percentage are. I have strong suspicions that the exploits used in this test fall into the catagory of POC developed but never actually employed "in-the-wild."
It is fairly obvious that Cymulate is recommending an "anti-exec" solution as far as the monitoring inbound external network traffic. This is only doable on a gateway device if the concern is willing to dedicate the system knowledgeable resources to monitor such activity. Based on postings on this forum, this certainly is not case frm the corp. sourced postings I have seen. BTW - this approach is certainly possible using custom Eset Firewall and HIPS rules. I for one, employ them.
-
8 minutes ago, cutting_edgetech said:
The only thing my router ever logs as being blocked is some IPV6 address, and I have IPV6 disabled on my Network Adapter.
You finally mentioned that you are using a VPN. As such, you are in essence bypassing the router's firewall. This is one reason I have never considered VPN use.
-
1 hour ago, Marcos said:
Could you try disabling submission of statistical information to see if submission of such files stops? I'm not sure but it could be files with statistical information.
All that type stuff is already disabled.
Do me a favor. Have someone look that that file and see what it contains. I have a hunch on what is going on and it involves Microsoft uploading data via ftp port 21. In the meantime, I am disabling WD periodic scanning and see it this stops Eset detecting this file.
-
This just started recently:
Time;Module;Event;User
6/22/2019 4:35:46 PM;ESET Kernel;File 'ESET_5D0E710A.tis.log' was sent to ESET for analysis.;SYSTEMTime;Module;Event;User
6/27/2019 11:07:39 AM;ESET Kernel;File 'ESET_5D14C01A.tis.log' was sent to ESET for analysis.;SYSTEMAppears to occur approx. one minute after a signature update. Also and interestingly, this started after I enabled Windows Defender periodic scanning.
I searched for this file via Win Explorer and it doesn't exist.
-
18 hours ago, cutting_edgetech said:
I have its settings configured for max security, but I can not block specific ports on my router unless it is one of the ports on the list of options for the router. Almost none of the vulnerable ports that belong to Windows services are on the list. I also can not block specific IP addresses on my router. My router does not state whether it uses SPI, which it would be a travesty if it does not!
Check the router's firewall log. If it is stateful, you should see numerous inbound connection blocked log entries.
You can also use the GRC Shields Up test here: https://www.grc.com/x/ne.dll?bh0bkyd2 to verify that all ports on the WAN side of the router are in a closed or stealth status. Stealth is the preferred status.
-
If you post the Cymulate report on a file sharing site, all on the forum could review it. Obviously, any device sensitive info should be removed/masked in the report.
Note that only Eset moderators can view any forum attachments.
-
16 hours ago, cutting_edgetech said:
I have to use the Network Wizard to get the IP addresses for attackers that get blocked due to there not being an allowed rule or an explicit deny rule for. It's the only way I can get them, and I only have 1 hour to do it before they are lost.
Let's back up a bit.
The Eset firewall is stateful. It will block any inbound connection:
1. That is not associated with a previous outbound connection.
2. Where an explicit block rule exists to prevent the inbound connection.
All the Network Troubleshooting Wizard shows in regards to the above no. 1). are connections that were blocked. There is no need to create additional user firewall rules to handle these stateful blocked inbound connections. This is why they are not logged , eventually time out, and no longer are displayed by the Wizard. There is also the risk that by manually creating firewall rules to block this activity, they are not properly created.
Earlier versions of Eset did not have the Network Wizard. Hence the user was totally unaware of the above activity; just as if they they would be if using a router with a stateful firewall. As a rule, router firewalls log all blocked activity which allows the user to be aware of this activity for forensic purposes. On any given day, my router's firewall log contains dozens of blocked inbound connections; primarily port 23, Telnet, attempted access. The Network Wizard's primarily purpose in this context is to provide the ability for example, to inform and create an allow rule for some internal network legitimate inbound connection that was blocked for some reason.
I assume Eset does not log stateful activity blocked inbound connections to prevent the Network Connections log from becoming too large. Another reason would be not to be "bombarded" in this forum with never ending questions about these firewall stateful blocked log enties.
One suggestion to Eset you might request in like forum topic section is Eset provide an option for the Network Connection log where all Network Wizard blocked connections are logged. Similar to like HIPS logging capability, this option would be disabled by default.
-
One additional comment about Eset's Network Trouble Shooting Wizard. You should not be relying on this as your primary method to block unwanted inbound network traffic. The Wizard was actually designed primarily to automated firewall rule creation for internal apps that are being blocked for some reason. And as far as I am concerned, it creates very permissive rules.
If your router does not employ a stateful firewall that will block any incoming unsolicited network traffic, you should seriously consider purchasing one that does. The router is the point where you want to block any unwanted inbound traffic.
False positives detection on website video players?
in Malware Finding and Cleaning
Posted
Ublock won't detect this stuff unless you enable JavaScript blocking. This is turn will break most web sites you access.
Eset's protection alone is adequate to protect you against web site Javascript malware.