Hydro 2 Posted December 21, 2017 Posted December 21, 2017 Product: ESET Internet Security 11.0.159.0, Firewall module 1372 (20171027) OS: Windows 10 Enterprise v1709 64-bit Firewall is set to "Interactive mode". No custom rules have been created yet. Windows application tries to access the internet. EIS displays "Outbound network traffic" popup. So far so good. However, when choosing "Create rule and remember permanently" -> "Deny", the application is still able to access the internet! A valid Deny rule will be created, but it is ignored the first time! Subsequent connections are refused, as expected. When choosing "Ask every time" -> "Deny" instead of creating a rule, the outbound connection is refused, as expected. Problem seems to occur with all Windows applications, including telnet (outbound TCP). Did not test with inbound traffic yet. Is anyone else experiencing this?
Administrators Marcos 5,458 Posted December 21, 2017 Administrators Posted December 21, 2017 I was unable to reproduce it. Try the following: - remove all custom rules and have the firewall in automatic mode - launch the browser and clear the cache completely - quit the browser and make sure it's not among running processes - switch the firewall to interactive mode - launch the browser and attempt to open an arbitrary website - when the interactive mode dialog pops up, keep clicking Deny. Is the website eventually displayed though?
ESET Insiders stackz 115 Posted December 21, 2017 ESET Insiders Posted December 21, 2017 4 hours ago, Hydro said: However, when choosing "Create rule and remember permanently" -> "Deny", the application is still able to access the internet! A valid Deny rule will be created, but it is ignored the first time! Subsequent connections are refused, as expected. I am able to reproduce this behaviour in interactive mode. Win7x64 EIS 11.0.159.0 Firewall module 1372 (20171027)
Hydro 2 Posted December 22, 2017 Author Posted December 22, 2017 Tried different things, including Marcos' suggestions, but the issue persists. I think this is a bug in the firewall. Easiest way to reproduce: run "telnet ad.doubleclick.net 80" (or similar) from a cmd prompt, with the firewall in interactive mode, so that EIS will display an "Outbound network traffic" popup. If you click "Ask every time" -> "Deny", the connection is blocked, as expected. Normal behaviour. However, if you click "Create rule and remember permanently" -> "Deny", a connection is established! Very undesirable behaviour. (to terminate the telnet http connection, press Escape)
Hydro 2 Posted December 23, 2017 Author Posted December 23, 2017 For those who don't have telnet enabled on their machine, it's also possible to test with the following Powershell command: Test-NetConnection -ComputerName ad.doubleclick.net -Port 80
Hydro 2 Posted December 27, 2017 Author Posted December 27, 2017 The latest pre-release version of EIS 11.0.159, with Firewall module 1373 (20171206), is also affected. When a new Deny rule is being created from the "Outbound network traffic" popup, the firewall does not block the initial outbound connection! Steps to reproduce: 1. Set the EIS firewall to Interactive mode 2. Open Powershell from the Windows start menu and run the following command: Test-NetConnection -ComputerName bing.com -Port 80 3. Choose "Create rule and remember permanently" -> "Deny" from the EIS "Outbound network traffic" popup The Test-NetConnection cmdlet will now display "TcpTestSucceeded : True", which means the firewall leaks traffic! (Subsequent outbound connections from Powershell are being blocked however, so the newly created Deny rule is respected by the firewall -- just not for the initial outbound connection) Is anyone else, besides Stackz and me, experiencing this issue? In EIS or perhaps in ESSP?
Hydro 2 Posted January 4, 2018 Author Posted January 4, 2018 (edited) Currently at Firewall module 1373.1 (20180103), but the EIS firewall still leaks outbound traffic when a new deny rule is created in interactive mode, regardless of the application and regardless of the network adapter being used. In essence, the EIS firewall driver seems to be functioning correctly, because when I click “Deny” with the “Ask every time” or “Remember until applications quits” option, the outbound traffic is being blocked, as expected. Existing deny rules are also functioning as expected. However, the EIS firewall fails to block traffic when I click “Deny” with the “Create rule and remember permanently” option (regardless of whether the rule is edited before saving). The newly created rule will block traffic for all subsequent connections that match the rule, but the initial connection (that triggered the “Outbound network traffic” dialog in the first place), is always allowed! This is 100% reproducible on my notebook. I think this is a bug in the EIS interactive deny logic. Perhaps introduced when the “Edit rule before saving” functionality was added? Product: EIS 11.0.159.0 (with pre-release updates enabled) OS: Windows 10 Enterprise v1709 x64 (10.0.16299.125) Edited January 4, 2018 by Hydro added screenshot
itman 1,803 Posted January 4, 2018 Posted January 4, 2018 1 hour ago, Hydro said: The newly created rule will block traffic for all subsequent connections that match the rule, but the initial connection (that triggered the “Outbound network traffic” dialog in the first place), is always allowed! I believe the Eset firewall alert is "expiring" before you actual save the rule. When this happens, Eset will auto allow the action associated with the alert. Open Eset GUI. Select Advanced setup -> User Interface -> Desktop Notifications -> Duration. Increase the current value shown there. See if this solves the issue.
Hydro 2 Posted January 5, 2018 Author Posted January 5, 2018 2 hours ago, itman said: I believe the Eset firewall alert is "expiring" before you actual save the rule. Even when creating the rule within 1 of 2 seconds (selecting option “Create rule and remember permanently” and then pressing the Deny button), the initial connection is never blocked (TcpTestSucceeded result is always True). The issue occurs regardless of the user timing, regardless of the network adapter (ethernet or wifi, docked or not) and regardless of the application. It also occurs with a clean install of EIS, with default settings (except for the firewall filtering mode, which is set to Interactive mode).
itman 1,803 Posted January 5, 2018 Posted January 5, 2018 OK. I duplicated it so it looks like a bug - possibly. Might have something to do with the way Eset interfaces with the Win firewall in Win 10 1709. I don't recollect having this occur previous to 1709.
Most Valued Members peteyt 396 Posted January 5, 2018 Most Valued Members Posted January 5, 2018 11 hours ago, Hydro said: Even when creating the rule within 1 of 2 seconds (selecting option “Create rule and remember permanently” and then pressing the Deny button), the initial connection is never blocked (TcpTestSucceeded result is always True). The issue occurs regardless of the user timing, regardless of the network adapter (ethernet or wifi, docked or not) and regardless of the application. It also occurs with a clean install of EIS, with default settings (except for the firewall filtering mode, which is set to Interactive mode). Might be best to open a support ticket
itman 1,803 Posted January 5, 2018 Posted January 5, 2018 I will also add this issue has noting to do with Eset firewall mode. Mine is currently set to allow all outbound traffic. When I did my verification test, I created an ask rule for outbound traffic to IP address 204.79.197.200. I then connected to www.bing.com via my browser. When the "ask" rule triggered, I then selected "Deny" with the option to create a rule to block the browser outbound traffic. The connection to www.bing.com was still allowed however.
Administrators Marcos 5,458 Posted January 8, 2018 Administrators Posted January 8, 2018 We've eventually pinpointed the issue. It will be addressed by the firewall module which will be put on pre-release update servers next week.
Most Valued Members cyberhash 201 Posted January 18, 2018 Most Valued Members Posted January 18, 2018 On 08/01/2018 at 4:57 PM, Marcos said: We've eventually pinpointed the issue. It will be addressed by the firewall module which will be put on pre-release update servers next week. Any news on this yet @Marcos ?
Recommended Posts