Jump to content

nasty firewall issue in EIS 11.0.159 (interactive mode)


Recommended Posts

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?
 

Link to comment
Share on other sites

  • Administrators

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?

Link to comment
Share on other sites

  • ESET Insiders
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)

 

Link to comment
Share on other sites

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)
 

Link to comment
Share on other sites

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
 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • 2 weeks later...

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)

image.png.b72900537346e61265772cf580655995.png

Edited by Hydro
added screenshot
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

image.png.7df06c7961db6e693af321a71886dcee.png

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Most Valued Members
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).

image.png.7df06c7961db6e693af321a71886dcee.png

Might be best to open a support ticket

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Administrators

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.

Link to comment
Share on other sites

  • 2 weeks later...
  • Most Valued Members
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 ?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...