Firewall Port Rule

[dan231 0]

Question on firewall rules:

 

If I want to allow port XYZ access only from internal IP 1.1.1.1, do I add that IP on the local IP or the remote IP page of the rule?

or, what would be the best option for this?

 

Thanks!

[itman 1,659]

To begin, IP address 1.1.1.1 is not an internal local subnet address. Do you mean 192.168.xxx.xxxx for example?

[dan231 0]

1.1.1.1 is just a place holder. 

[itman 1,659]

4 hours ago, dan231 said:

If I want to allow port XYZ access only from internal IP 1.1.1.1, do I add that IP on the local IP or the remote IP page of the rule?

Assuming you are referring to an inbound traffic restriction, you would specify the IP address in the Remote firewall rule section. This will only allow inbound traffic from the IP address to a port specified in Local firewall rule section.

Note: the Eset firewall ruleset is executed from top to bottom. If there is an existing firewall rule; default or user created, that references the Local port specified and that rule is prior to the rule being created, that inbound traffic will be allowed. Likewise, an existing application based rule that does not explicitly reference any local ports will allow inbound traffic to the above specific Local port if the app sends outbound traffic from that port.

Edited June 27, 2020 by itman

[dan231 0]

What is the purpose of the local IP section?

[itman 1,659]

2 hours ago, dan231 said:

What is the purpose of the local IP section?

Normal Internet network traffic is outbound. For example, some app requests requests a remote connection. For example, a browser HTTPS connection uses remote port 443. The local random port chosen by the app for this communication is in the Ephemeral port range:

Quote

Microsoft Windows

As of Windows Vista and Windows Server 2008, Windows now uses a large range (49152-65535) by default, according to Microsoft Knowledgebase Article 929851. That same article also shows how you can change the range if desired, but the default range is now sufficient for most servers.

https://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html

Once the app network traffic is received at the remote destination, it in turn sends outbound traffic from its local port 443 to the Ephemeral local port on your device that was previously assigned by the app. In other words, you receive this remote initiated network communication as inbound network traffic.

Normally one will not worry about settings in the Local firewall rule section. If you refer to Eset's default firewall rules, settings for the Local section are predominately specified for protocols reserved for local subnet use.

Edited June 27, 2020 by itman

[dan231 0]

So, I would then also put the allow ports in The remote section as well?

[itman 1,659]

7 minutes ago, dan231 said:

So, I would then also put the allow ports in The remote section as well?

Please specifically explain what your are trying to monitor via Eset firewall rule/s.

[dan231 0]

It’s all internal traffic for patching.   Patch server is 1.1.1.1. Port is 123.  I want to allow incoming traffic to and from the patch server for this port. 

[itman 1,659]

First note that port 123 is used by Windows for time synchronization: http://www.tcp-udp-ports.com/port-123.htm . Next note that Eset has a default firewall rule to allow this activity; i.e. protocol UDP, remote and local port 123, for application, svchost.exe.

The above said, your rule would be coded as:

Direction - Both

Protocol - TCP & UDP

Local - Application - whatever you are using for this patch activity. Port - 123

Remote - Port - 123. IP address - IP address of the server.

The above rule will allow all inbound and outbound TCP/UDP traffic on port 123 to and from the patch server by whatever process; i.e. .exe, performing the patching activity.

Note that this rule must exist on every client device where patching activity is being performed.

If patching activity is being run from the server, eliminate any application reference in the client firewall rules. Also note that with Direction of "Both" being specified on the client rules, the clients have access to the server via port 123. If this is not desired, change the Direction to "In" on the client rule. This will allow the server to access the clients but prevent the clients from accessing the server.

          

Edited June 27, 2020 by itman

[itman 1,659]

Thinking about this a bit more and assuming client device patching is originating from the server, no Eset firewall rules need to be created on the client devices. By default and assuming their Eset firewall filtering mode is set to Automatic, all outbound traffic from the client devices is allowed.

Creating non-application based outbound traffic from the clients to the server is a security risk. If a client was infected, the attacker could can access to the server via port 123.

[dan231 0]

Thanks.  The port needs to be added to both the local and remote tabs?

[itman 1,659]

3 hours ago, dan231 said:

Thanks.  The port needs to be added to both the local and remote tabs?

It depends on where and what app is initiating the communication.

If the patching app runs on the server and it is using port 123 to send outbound traffic to the clients, then the Local port 123 needs to be specified on the client firewall rule. The Direction rule setting is In,

If the patching app runs on the client and it is using port 123 to send outbound traffic to the server, then remote port 123 needs to be specified assuming the server expects to receive inbound traffic from the clients using port 123. The Direction rule setting is Out.

If continuous inbound and outbound traffic between clients and server is desired, then best to specify port 123 both in Local and Remote rule setting.

The bottom line here it is the app that controls port assignments. In normal outbound traffic, a random port is selected for Local use and a specific port/s for Remote use. An inbound firewall is not needed in most cases since most network traffic is stateful. In other words when the inbound traffic response is had from a previous outbound request, it will use the same Local port assigned from the outbound request. Now if the server initiates the patching activity on the clients, the clients must specify a specific Local port; e.g. 123, since that inbound communication is not stateful; i.e. it did not originate from the client.

My advice is set up the firewall rule on one client device and test server patching to that device. Adjust client firewall rule settings as needed until you achieve successful  patching on that device with resultant response back to server of this state if so desired.

Finally and important is all my statements to date assume all devices involved in patching activities reside within the local network.

If you are attempting to patch a client device external to the local network, you have to employ the appropriate network protocol to do so; e.g. RDP, or preferably to use a VPN. If RDP is used, the Eset firewall has default rules in place to handle that activity. In this instance, the server IP address would have to be added to the Eset firewall Trusted Zone of each external client device. Also, use of port 123 is N/A if RDP is used.

Additionally, RDP is the preferred server to client access method within local networks,

Edited June 28, 2020 by itman