Firewall inconsistency

[local 0]

A while ago I complained about ESET firewall not having FQDN in alerts ; I was told it is not possible.

Now it seems like is implemented :

 

however, once the rule is created, only the IP is displayed , not the www. Is very difficult almost impossible to review your rules later on , if only the IP is displayed.

So why the FQDN is not saved in the rule, once it has been determined????

[itman 1,804]

5 hours ago, local said:

So why the FQDN is not saved in the rule, once it has been determined????

What is going on here is Eset is just resolving the IP address to the domain URL associated with it in the displayed alert.

Again note that all firewalls including the Windows one are IP address based. The reason?

1. Multiple IP addresses are usually associated with a given domain.

2. These IP addresses frequently change depending on what DNS server is being used.

For a firewall to use a URL, it would first have to first establish all IP addresses associated with that URL. It would then have to apply a given rule to all those IP addresses. Then there is the issue of actual and accurate DNS resolution every time it is performed. Bottom line - "you're tilting at windmills" here.

[local 0]

1 hour ago, itman said:

What is going on here is Eset

OK, if resolving the IP to domain is accurate when an alert is being displayed , why the info is not preserved in the rule????

If it is not accurate , why presenting the info in the first place? (on alert)

We cannot have it both ways....

[itman 1,804]

1 minute ago, local said:

OK, if resolving the IP to domain is accurate when an alert is being displayed , why the info is not preserved in the rule????

All that Eset is doing for the alert is using one of the many IP address-to-domain URL and vice-a-versus web sites, or equivalent, to display the URL. There is no way on those sites to extract all IP addresses shown. 

[local 0]

11 minutes ago, itman said:

All that Eset is doing for the alert is using one of the many IP address-to-domain URL and vice-a-versus web sites,

So, you are saying that the alert may not be accurate?

[Marcos 5,458]

It shouldn't be a problem at runtime since the web access protection can provide the firewall with the hostname that has resolved to the IP address, however, if the hostname was used in a rule at a later time it wouldn't work as expected I assume.

Example:
You receive an interactive firewall dialog about communication with 216.58.201.78, web access protection would tell the firewall there has been a communication with maps.google.com that resolved to this address recently. A firewall rule would be created for maps.google.com which would, however, internally translate to a firewall rule for the above IP address.

Such rule wouldn't work the next time since maps.google.com could resolve to a different IP address from subnet 216.58.201.0/24. Moreover, it could be that you would like to block access to youtube.com that would resolve to an already allowed IP address:

Name:    youtube.com
Addresses:  2a00:1450:4014:800::200e
          216.58.201.78

Name:    maps.google.com
Addresses:  2a00:1450:4014:800::200e
          216.58.201.78

As a result, there would be 2 conflicting rules. A permissive rule for 216.58.201.78 and a blocking rule for the same IP address.

[itman 1,804]

To what @Marcos just posted, I will add this. What happens when DNS "hiccup's" on the resolution process?

Refer to the screen shot in my posting here: https://forum.eset.com/topic/22586-fortinet-dnsweb-filter-blocking-eset-forum/?do=findComment&comment=109560 . I am using DNS over HTTPS with Clouldfare DNS servers. The fallback when there is a problem is to DNS over TLS using my ISP servers. It also happens that when the resolution is done by my ISP DNS servers, it is borked in some fashion with results not being what is expected as shown in the screen shot.

Again firewalls do not contain advanced resolution capability. The more ambiguous the objects that they are basing their decisions on are, the more likely that the decision made will be in error. Additionally, use of any IP addresses in firewall rules should only be done on an exception and interim basis for all the reasons stated. The primary reason for allowing the IP address specification in firewall rules is for local subnet use.

Edited February 22, 2020 by itman

[local 0]

1 hour ago, Marcos said:

if the hostname was used in a rule at a later time it wouldn't work as expected I assume.

But, when I review the firewall rules, 1month from now,  how I am suppose to remember that I allowed this svchost.exe because was related to Windows update , if in the rule is just an IP ????

[itman 1,804]

40 minutes ago, local said:

But, when I review the firewall rules, 1month from now,  how I am suppose to remember that I allowed this svchost.exe because was related to Windows update , if in the rule is just an IP ????

I don't know why you're monitoring oubound svchost.exe traffic in the first place. Paranoia, I guess.

Instead of worrying about IP addresses, just create outbound firewall rules for svchost.exe for these two services assuming you are running Win 10 :

• wuauserv
• WaasMedicSvc

Edited February 22, 2020 by itman

[local 0]

1 hour ago, itman said:

why you're monitoring oubound svchost.exe

some applications are using svchost.exe to connect to the internet. A benign example is Adobe X pro, which will check for updates, even though you block the updater of Adobe.

Similarly, a malware can use svchost.exe to communicate outside.

The purpose of a firewall is to monitor everything; why use a firewall if you ignore the alerts or blindly select "allow" ????

[itman 1,804]

1 hour ago, local said:

Similarly, a malware can use svchost.exe to communicate outside.

Actually if this is the case, the malware installed a malicious service. It will then use this service to install other malware like a backdoor. It will then use that backdoor to establish a remote connection to the device. In other words, svchost.exe is not being used for outbound communication from the device.

Additionally most of today's malware are using other "living off the land" Windows trusted processes such as infrequently used utility processes and script processes for their outbound communication these days.

[local 0]

On 2/22/2020 at 6:56 PM, itman said:

Actually if this is the case, the malware installed a malicious service

I just gave you an example of a non-malicious item (Adobe) using svchost.exe to check for updates. The firewall should be able to alert you about this.

[itman 1,804]

13 hours ago, local said:

I just gave you an example of a non-malicious item (Adobe) using svchost.exe to check for updates. The firewall should be able to alert you about this.

Create a firewall rule to monitor this service - AdobeARMservice.

Edited February 24, 2020 by itman

[local 0]

19 hours ago, itman said:

Create a firewall rule to monitor this service - AdobeARMservice.

Regardless of the rule to block AdobeARMservice,  ADOBE X still will connect to update servers using svchost.exe, which typically is allowed for Windows updates TCP 80/443