NIS problem with ephemeral ports/temp range?

“Ephemeral Ports - Temp Range

When initiating outbound requests for common remote services, your system will use ports some refer to as "ephemeral ports" or the "temp range" for the local portion of these connections. The ephemeral ports or temp range is 1024-5000. These would be the standard ports used locally for most connections to remote services. Thus your custom rule would allow local service/port 1024-5000. Most firewalls default your rules to any local service/port. Restricting the rule to the ephemeral ports or temp range for local service/port is just a means of tightening up your rule(s). It also would alert you to something using non-standard services/ports.”

When customizing rules I will restrict local service/port to the temp range where appropriate.

Last night, and I managed to repeat it again tonight, I encountered an issue while surfing where the local system went beyond the temp range 5000+. This resulted in the following:

Connections Event Log
22:37:46 Supervisor Connection: www.wilderssecurity.com(66.227.68.99): http(80) from 192.168.1.10: 4995,
22:37:46 Supervisor Connection: www.wilderssecurity.com(66.227.68.99): http(80) from 192.168.1.10: 4997,
22:38:03 Supervisor Connection: www.wilderssecurity.com(66.227.68.99): http(80) from 192.168.1.10: 4999,
22:38:05 Supervisor Connection: localhost: 4998 to localhost: 1029,
22:38:05 Supervisor Redirected Connection: localhost: 1029 from localhost: 4998,
22:38:24 Supervisor Redirected Connection: localhost: 1029 from localhost: 5000,
22:38:24 Supervisor Connection: localhost: 5000 to localhost: 1029,
22:38:24 Supervisor Connection: www.wilderssecurity.com(66.227.68.99): http(80) from 192.168.1.10: 5001,

At this point I was prompted by the firewall to allow the outbound IE connection (as it is restricted to local service/port 1024-5000) and chose to block it.

Firewall Event Log
22:38:51 Supervisor This one time, the user has chosen to "block" communications. Details:
Outbound TCP connection
Remote address,service is (www.wilderssecurity.com(66.227.68.99),http(80))
Process name is "C:\Program Files\Internet Explorer\iexplore.exe"
22:38:14 Supervisor This one time, the user has chosen to "block" communications. Details:
Outbound TCP connection
Remote address,service is (www.wilderssecurity.com(66.227.68.99),http(80))
Process name is "C:\Program Files\Internet Explorer\iexplore.exe"

Connection not made and the page would not load.

IE was closed, restarted to blank page and selected www.wildersecurity.com again from favorites. This time the firewall implicitly blocked the outbound DNS query and subsequently prompted me, as my DNS rules are also restricted to local service/port 1024-5000.

Firewall Event Log
22:49:04 Supervisor Rule "Implicit block rule" blocked (209.xxx.xxx.xxx,domain(53)). Details:
Outbound UDP packet
Local address,service is (0.0.0.0,5005)
Remote address,service is (209.xxx.xxx.xxx,domain(53))
Process name is "C:\Program Files\Internet Explorer\iexplore.exe"

- nine other entries as above followed by my choosing to block when prompted by NIS.

22:49:12 Supervisor This one time, the user has chosen to "block" communications. Details:
Outbound UDP packet
Local address,service is (0.0.0.0,5005)
Remote address,service is (209.xxx.xxx.xxx,domain(53))
Process name is "C:\Program Files\Internet Explorer\iexplore.exe"

System is W2K sp3. NIS2002 Pro v4.5 with all updates. (Just recently re-installed. Only jvmorris could hazard a guess as to how many times and different versions have been on this system –not to mention other firewalls for testing/evaluating )

Firewall Rules in place for DNS and Internet Explorer:

Rule X Permit Inbound DNS Servers
Category: NIS System Keeping
Rule in use: YES
Logging: NO
Protocol: UDP
Action: Permit
Direction: Inbound
Application: Any Application
Local Service: (1024 - 5000)
...Range Begin: 1024
.....Range End: 5000
Local Address: Any Address
Remote Service:
..........Port: 53
Remote Address: (IPGroup10)
............IP: 209.xxx.xxx.xxx
............IP: 209.xxx.xxx.xxx
............IP: 207.xxx.xxx.xxx
............IP: 207.xxx.xxx.xxx

Rule X Permit Outbound DNS Servers
Category: NIS System Keeping
Rule in use: YES
Logging: NO
Protocol: TCP or UDP
Action: Permit
Direction: Outbound
Application: Any Application
Local Service: (1024 - 5000)
...Range Begin: 1024
.....Range End: 5000
Local Address: Any Address
Remote Service:
..........Port: 53
Remote Address: (IPGroup10)
............IP: 209.xxx.xxx.xxx
............IP: 209.xxx.xxx.xxx
............IP: 207.xxx.xxx.xxx
............IP: 207.xxx.xxx.xxx

Rule X Internet Explorer HTTP
Category: Web Browsers
Rule in use: YES
Logging: NO
Protocol: TCP
Action: Permit
Direction: Outbound
Application: (Microsoft Internet Explorer)
..........Path: c:\program files\internet explorer\iexplore.exe
..........SHA1: 2f ad 6f ec 91 d2 60 e5 38 a5 62 80 4f ef 43 b6 d9 83 9c 81
........Access: Custom
Local Service: (1024 - 5000)
...Range Begin: 1024
.....Range End: 5000
Local Address: Any Address
Remote Service:
..........Port: 80
..........Port: 443
..........Port: 8080
Remote Address: Any Address

I have never encountered this issue before.

Now my question for fellow NIS users with custom rules: Have you ever encountered something similar? Could it be the transparent proxy server not rolling over/back when these dynamically assigned temp range ports reach 5000?

Question for the true techies out there: It is possible with all my testing//installing/uninstalling that there could be an issue(s) with my system . Is there anything from the system point of view that could cause this?

Regards,

CrazyM

 

Update

Trouble shooting this issue I found the following value had been added to the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value Name: MaxUserPort Data Type: REG_DWORD Value: 65534

From what I have been able to determine, this changes the Windows default for ephemeral ports (1024-5000) to 1024-65534.

I removed the value, rebooted, and did a lot of frivolous surfing to expedite the ephemeral ports incrementing their way back up to 5000 to determine if the original issue would repeat itself. It did not, so it appears this part of the problem is solved. Time will tell for certain.

As for determining what added the registry value, this still is not clear and it is unlikely I will be able to nail it down. Malware is not an issue or concern here. As noted with the testing/evaluating (tinkering ) I do, it was likely one of these applications.

Regards,

CrazyM