Jump to content

Archived

This topic is now archived and is closed to further replies.

Mpeter

Misbehaving firewall - rules skipped, but not always

Recommended Posts

I've been trying to configure my firewall to my taste for some time already, but it seems I've difficulties setting it up properly. Recently I've reinstalled Eset in English language, so I can see if something is translated wrongly, and you can help easier this way too.
I assume, as your documentation states, that the rules are processed from the top to the bottom. I also assume that the first rule's action that fits a packet is applied to it, and evaluation of following rules will not happen. Please correct me if some of the assumptions are incorrect.

I use automatic mode, and I did not modify the hidden rules, or if I did I did so with an other setting which is not in the firewall section.
You can see my current rules on the first image.

Before following, please not the first and last rules:

  • the first one is there for testing purposes only. I'll talk about it below.
  • the last one is to notify me with a popup in the bottom left if there are any unexpected incoming connections, and also if rules are not working as I expect

I noticed the following anomalies:

  1. see the second rule from the end, named "Silent block Windows Connected Devices sync broadcasts". I placed it there so when a phone on my network communicates with the PC it's sync is set up with (it's an other one) then I won't get a notification about that. this service for some reason communicates with broadcasts through port 5050.
    Now take a look at the second picture. Here you can see that the above mentioned service's communication is not blocked by that rule, but rule evaluation is reaching the last rule, which blocks everything else and notifies me. My question is why doesn't the mentioned rule (2nd from the bottom) block the communication?
  2. If the first rule (named DNS deny) is turned on, DNS requests made with the nslookup command are blocked, but DNS requests made in any other way (Firefox browser (DOH is disabled), Windows service Dnsclient) are not, and I can even see them in a Wireshark capture, both the query and the response?
  3. see the third rule allowing any communication for qBittorrent. Sometimes I get log entries that the last rule (named Anything) blocks inbound communication for it. why isn't rule evaluation stop at the third rule, with the conclusion that this communication is allowed? that rule has an application filter, but the filter points to the executable that is trying to receive the connection.

Please note that the logs on the second image only include entries for the first point. This happens quite frequently if certain conditions met, and a few minutes earlier I deleted all networking logs to make sure they don't make any confusion.

If you need further information feel free to ask. If you provide instructions I can export these rules and upload them here so you can see a few details that are not seen in the list.

2020-01-04.png

2020-01-04 (1).png

Share this post


Link to post
Share on other sites

In order to investigate the issues, we would need advanced logs created as follows:
- enable advanced network protection logging in the advanced setup -> tools > diagnostics
- reboot the machine
- reproduce the issue
- disable logging
- collect logs with ESET Log Collector. Upload the generated archive here and provide more information about the issue that you reproduced along with information about devices and their IP addresses.

In the mean time, you can also try to display default firewall rules and put the custom rules above them to rule out any impact that they might have on evaluation.

Share this post


Link to post
Share on other sites
On 1/4/2020 at 5:45 PM, Mpeter said:

If the first rule (named DNS deny) is turned on, DNS requests made with the nslookup command are blocked, but DNS requests made in any other way (Firefox browser (DOH is disabled), Windows service Dnsclient) are not, and I can even see them in a Wireshark capture, both the query and the response?

Windows falls back to using mDNS, UDP port 5353, if it can't connect via normal DNS. Look for outbound port 5353  traffic in your Wireshark logs.

Share this post


Link to post
Share on other sites
On 1/4/2020 at 5:45 PM, Mpeter said:

I use automatic mode, and I did not modify the hidden rules, or if I did I did so with an other setting which is not in the firewall section.

Unless your user rules were moved to the top of the existing firewall rule set; i.e. above any existing Eset default rules, the default rules will override any of your user created rules. Most notably, your DNS block rule.

Eset firewall rules are executed in top to bottom rule order. You will have to "unhide" the Eset default firewall rules and move your user DNS rule to above the Eset default rules. Preferably your should disable the default Eset DNS rule if it exits, and place your user DNS rule prior to the default one. Finally, don't be surprised if many Windows necessary outbound communications such as Windows and Store updates and like are borked because of this.

Share this post


Link to post
Share on other sites

Thank yor for all of your responses.

On 1/8/2020 at 2:49 PM, Marcos said:

In order to investigate the issues, we would need advanced logs created as follows:
- enable advanced network protection logging in the advanced setup -> tools > diagnostics
- reboot the machine
- reproduce the issue
- disable logging
- collect logs with ESET Log Collector. Upload the generated archive here and provide more information about the issue that you reproduced along with information about devices and their IP addresses.

In the mean time, you can also try to display default firewall rules and put the custom rules above them to rule out any impact that they might have on evaluation.

I'll try this, but first I'll go through the other 2 answers.

On 1/8/2020 at 3:14 PM, itman said:

Windows falls back to using mDNS, UDP port 5353, if it can't connect via normal DNS. Look for outbound port 5353  traffic in your Wireshark logs.

I've blocked DNS (port 53, TCP and UDP) on direction "out" again. nslookup does not work as expected, but after starting a Wireshark capture there are still queries and responses going on port 53 as you can see here. DNS queries triggered by Firefox (e.g. by loading a page) get through too. I'll try what happens when I move rules above the hidden ones.

On 1/8/2020 at 4:42 PM, itman said:

Unless your user rules were moved to the top of the existing firewall rule set; i.e. above any existing Eset default rules, the default rules will override any of your user created rules. Most notably, your DNS block rule.

Eset firewall rules are executed in top to bottom rule order. You will have to "unhide" the Eset default firewall rules and move your user DNS rule to above the Eset default rules. Preferably your should disable the default Eset DNS rule if it exits, and place your user DNS rule prior to the default one. Finally, don't be surprised if many Windows necessary outbound communications such as Windows and Store updates and like are borked because of this.

As I said in the original post, I'm blocking DNS for testing purposes, as it is used so much that if it gets blocked properly then it will be easy to see

Share this post


Link to post
Share on other sites
1 hour ago, Mpeter said:

I've blocked DNS (port 53, TCP and UDP) on direction "out" again. nslookup does not work as expected, but after starting a Wireshark capture there are still queries and responses going on port 53 as you can see here.

Most shown are internal local subnet addresses: https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml . Note that Eset does internal proxy activities for DNS and other traffic which they won't elaborate on.

1 hour ago, Mpeter said:

DNS queries triggered by Firefox (e.g. by loading a page) get through too. I'll try what happens when I move rules above the hidden ones.

I don't know what you mean here. If you are blocking all outbound DNS port 53 traffic, FireFox shouldn't be able to connect to anything. Blocking this hidden Eset DNS processing will weaken Eset's security protection. Ditto for other possible network traffic that Eset internally monitors via UDP proxy means. You need to duplicate Eset's existing firewall rule for ekrn.exe and place that rule prior to your DNS block rule. 

My advice is leave Eset's existing default firewall rules in place unless you fully understand all the effects of overriding them.

Share this post


Link to post
Share on other sites

As a test I created a firewall rule to block outbound TCP/UDP to remote port 53. I moved this rule to the top of existing rule set.

I opened FireFox and it did partial load its home web page but wouldn't perform any subsequent DNS resolution. I believe what was shown on the home page was loaded from FireFox's cache. I could not connect to any web site thereafter. Note that I do use FireFox DoH feature but that only kicks in after a connection to your ISP server is made.

Next. I opened IE11. It failed to load its home page entirely.

At this time, my Ethernet network connection went down completely.

So as far as I am concerned, Eset's firewall is working as expected in regards to blocking any DNS resolution activities.

-EDIT- Forgot to mention that not only was DNS activity blocked but also ekrn.exe port 53 outbound traffic blocked as I posted previously about.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...