RPC being blocked in Trusted Zone, but don't know why

[JoeC 2]

I spent the better part of the day trying to figure out why only some RPC is blocked and some is not. I can view services on a remote computer, and view event logs. No problem. I cannot run tasklist, though. I get "RPC server is unavailable". This started a couple of weeks ago. Prior to today, I was using the base "Antivirus - Balanced" policy with no modifications. I have used tasklist from time to time over the past couple of months for remote troubleshooting with no trouble. Then suddenly, it started giving that RPC unavailable error. I confirmed the ESET firewall is the culprit.

Today, I added our IP range as the Trusted Zone and locked the filtering mode to Automatic (policy-based cut off all network connection, so that was bad) and confirmed that Allow incoming RPC communication in the Trusted Zone is enabled under Allowed Services. That should be working, but it's not.

The only way I've gotten it to work is by adding a specific firewall rule for Winmgmt as a local service. However, if I do that from ECA, then Firewall rules are locked (which is not a bad thing, except I don't want to do that at this moment.) Right now, I don't have this rule in place. I will put it in as a last resort, but I think with the Trusted Zone and Allow incoming RPC, it should be working. I'm more concerned that it WAS working a few weeks ago, but now it's not. Is there anything else I should be looking at?

We're on Product Version 7.2.2055.0.

[itman 1,659]

In Eset Firewall section, opened up the Services section. Verify that "Allow incoming RPC communication in the Trusted zone" is enabled.

Edited June 16, 2020 by itman

[JoeC 2]

Yes, it is enabled both in the firewall section of the policy, and within ESET on the client. This is why I think it SHOULD be working. I disabled that, then re-enabled that in case it needed to rewrite a setting, but that had no effect.

[itman 1,659]

Refer to the below screen shot. On the device having issues, verify that RPC start up settings are as shown. Note: the screen shown is from a Win 10 device:

Edited June 17, 2020 by itman

[JoeC 2]

That was the first thing I did when I got the RPC unavailable error message. And, as I stated, other RPC stuff is working (connecting to another computer in event viewer and services), but not tasklist. It's like tasklist is doing something different, though all of them require RPC to be enabled. Once I create an ESET firewall rule to allow Winmgmt as a local service, it works. But I didn't have to have a rule a few weeks ago when tasklist was working fine. And that's what's confusing me. I noticed this issue about two weeks ago, but have been too busy to address it. My next move is to start looking at Windows updates in the past month or so to see if there's anything in those that may have cause this odd behavior. Or maybe it's an ESET bug. I don't know.

[itman 1,659]

Temporarily disable the Winmgmt firewall rule you created.

Then open Eset Network protection and check Network Wizard for any blocked connections. This might shed some light on what is being blocked by the Eset firewall.

[JoeC 2]

For Windows Instrument Management (svchost.exe), it simply says "No usable rule found". I'm not certain the port is useful here as I understand RPC Port Mapper uses a random port in a rather large range. Reading up on RPC in ESET, the Allow incoming RPC works with the MS RPC service and the RPC/DCOM service. As I understand it, the initial connection will tell which RPC port to actually use, and then ESET would allow that communication. And it is, for some RPC things, like event viewer, services, remote desktop, etc., but not for tasklist. That's what's baffling me. 

I know the local service rule for Winmgmt works. It seems like something that shouldn't need to be done if Allow incoming RPC from Trusted Zone is enabled. But if that's what I have to do, so be it.

Oh, and thanks for helping me out. I appreciate it.

 

Edited June 17, 2020 by JoeC

[itman 1,659]

Below is a screen shot of the default Eset firewall rules when the corresponding RPC service setting is enabled. Eset firewall rules are parsed in top to bottom fashion. As such, the Allow incoming RPC requests rule will be executed first.

Since the default application specified is svchost.exe, it appears what RPC communication is occuring within your local network, it is not sending network traffic to port 135 from a Trusted Zone IP address.

 

 

Edited June 17, 2020 by itman

[JoeC 2]

Yes, that's what mine shows. In the troubleshooter, it shows TCP in on port 11146. My understanding of RPC is that first port 135 is connected, and the portmapper gives the calling app the real port number, which is randomized to some large range. In my case, it appears for tasklist, the port is 11146. What's strange is that's not in the normal dynamic port range, either low or high. However, DCOM, which WMI uses, can have pretty much any port between 1024 and 65535. DCOM uses RPC as a transport, so starts out on port 135. At least that's my understanding. I'm no expert in this. I have a suspicion that this is more of a DCOM/WMI issue than an RPC issue, and perhaps previously, we just got lucky that the DCOM port was randomly assigned into the normal RPC range. When I get more time, I may try to limit the DCOM port range on the server I'm using for tasklist, if I can figure out how to do that. Fortunately, it's a sandbox server, so anything I do there won't affect anyone else.

So, yeah, I'm reversing my opinion that this is an ESET issue, and thinking it's more of a DCOM/WMI issue on my end.

[itman 1,659]

I forgot to mention this.

Be careful about adding IP addresses to Eset's Trusted Zone. Any IP addresses added there will also apply to any Eset firewall rule where Trusted Zone is referenced. As such, a security vulnerability could be created. You are better served creating a new Zone, adding IP addresses to that Zone, and referencing the Zone by name in any custom firewall rule created. Note: there was a bug in Eset retail versions in this regard preventing a new Zone being created. Supposedly, it has been fixed. Don't know if this bug and fix also apply to Endpoint versions. Alternatively, IP addresses can be specified individually in any Eset custom firewall rule created.

Edited June 17, 2020 by itman

[JoeC 2]

Thanks for that heads up.

[itman 1,659]

Use also might want to review this article: https://serverfault.com/questions/393674/what-is-the-sequence-of-windows-rpc-ports-135-137-139-and-higher-ports-what .

Other ones of interest:

https://support.microsoft.com/en-us/help/154596/how-to-configure-rpc-dynamic-port-allocation-to-work-with-firewalls

https://support.microsoft.com/en-us/help/908472/how-to-configure-rpc-to-use-certain-ports-and-how-to-help-secure-those

https://support.microsoft.com/en-us/help/832017/service-overview-and-network-port-requirements-for-windows

 

[itman 1,659]

Another possible blocking source is the Win Firewall. The Eset firewall will revert by default to any existing Win firewall rules for inbound network traffic unless specifically blocked by an existing Eset firewall rule.

As shown in the below screen shot, Win firewall inbound RPC rules are not enabled by default on my Win 10 x(64) build:

 

 

[JoeC 2]

Thanks for those links.

When I turn off the ESET firewall, it works fine, so that's not it. Besides, I have ESET to set to not evaluate Windows Firewall rules. I looked at this possibility early on.

Edited June 18, 2020 by JoeC

[itman 1,659]

1 hour ago, JoeC said:

When I turn off the ESET firewall, it works fine, so that's not it. Besides, I have ESET to set to not evaluate Windows Firewall rules. I looked at this possibility early on.

Looks like you missed my point.

The Win firewall appears to have default RPC rules in place for what your trying to accomplish. For example, the rule I posted in the screen shot that specifies "RPC Endpoint Mapper" for local port which I believe handles the RPC dynamic port assignment issue. Here's Microsoft's write-up on this: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/create-inbound-rules-to-support-rpc

Quote

To allow inbound remote procedure call (RPC) network traffic, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console to create two firewall rules. The first rule allows incoming network packets on TCP port 135 to the RPC Endpoint Mapper service. The incoming traffic consists of requests to communicate with a specified network service. The RPC Endpoint Mapper replies with a dynamically-assigned port number that the client must use to communicate with the service. The second rule allows the network traffic that is sent to the dynamically-assigned port number. Using the two rules configured as described in this topic helps to protect your device by allowing network traffic only from devices that have received RPC dynamic port redirection and to only those TCP port numbers assigned by the RPC Endpoint Mapper.

The important point to note is in regards to the second rule/s stated. That rule must specify:

Quote

In the Customize Service Settings dialog box, click Apply to this service, and then select the service that you want to allow. If the service does not appear in the list, then click Apply to service with this service short name, and then type the short name of the service in the text box.

This article gets into how RPC dynamic port allocation works: https://www.itprotoday.com/security/rpc-dynamic-port-allocation . Note: this an old article and obviously the dynamic port range allocation has changed.

The problem with the Eset default firewall rules is they appear to only facilitate standard RPC traffic; i.e. inbound port 135. Also I don't see anyway the Eset firewall can securely handle something like dynamic port assignment. That is open and closing of ports on demand.

Edited June 18, 2020 by itman

[JoeC 2]

Oh, I see what you're saying. Yes, that does work. In my case, I only needed to add a single rule for the RPC Endpoint Mapper. The caveat here is I have to enable the functionality in ESET to evaluation Windows Firewall rules. Otherwise, it won't work. I'll consider this as a possible solution. Not sure I want to touch Windows Firewall rules on every desktop, not knowing which ones have and haven't been hardened. But it's definitely a consideration. Thanks for that!

Edited June 18, 2020 by JoeC

[itman 1,659]

Use of Win Firewall is a "double edged sword." It can and has been hacked since the rules are stored in clear text in the registry. On the other hand, Win 10 is a different OS animal and Microsoft sends a lot of unstateful network traffic to it.

Appears Eset has abandoned updating its firewall rules and is instead deferring to the Win 10 firewall in this regard. Hence, the need to keep the default Eset firewall setting to use Win firewall inbound rules enabled.

What really is needed is for Eset to provide self-protection for the Win firewall rules. Problem is apps will update Win firewall rules as needed. Eset HIPS doesn't have the sophistication to monitor for this type of activity.

Edited June 18, 2020 by itman