vistafirewallcontrol.freeforums.org

[ironicman]

Just a question regarding the port forward functionality. Do W7Firewall Control automatically detect the listening ports for an app and then port forward it via UPNP, or do I have to specify which port to be port forward for the application?

[VistaFirewallControl]

An automatic port forwarding of all the listening ports seems against the intention – to protect, not to automatically allow all the incomings required in full. Actually there is lot of listening ports and “listening” applications running on a typical system and most of them are not unconditionally safe even in local network.
So you have to specify the ports to be forwarded manually once per application manually.
W7FC just manages the port forwarding settings dynamically, i.e. the specified port forwarding is initiated on each the application start and destroyed on the application exit, so no other application can utilize the forwarded ports illegally.

[ironicman]

I know it might be a security issue, but won't a whitelist (set by users) be able to solve this, allowing some apps to be port forwarded but not other? It might even limit the number of ports being opened since some apps listen to random ports while others listen to part of a range of ports. I'm just a bit curious.

[VistaFirewallControl]

>but won't a whitelist (set by users) be able to solve

Could you please be a bit more descriptive?
The W7FC listed applications will not be portforwarded by W7FC till you explicitly set/adjust rules (Ext port parameter) for that.

Application can adjust portforwarding on its own as well. Usually it happens when the portforwaring is vitally required by the applications (P2P apps, servers etc). This can be explicitly suppressed (if required) by disabling uPnP negotiations with the router (UDP:1900).

However if an application forwards port in the router, there is no a guaranteed/direct way to trace back the application. The router keeps just “forward to IP” and port value (no application related data available principally at the router side), only enumerating the listening ports “by app” the target application can be found, the environments may vary rapidly though.

>It might even limit the number of ports being opened since some apps listen to random ports while others listen to part of a range of ports. I'm just a bit curious.

The main question for correct access permissions settings is the application trust anyway.
Regardless of the ports are random or not, there is no need to block a port the application does listen on. If the application is not listening on a port, the connection will not be established to the port even it’s not blocked by the firewall.
We can hardly imagine a situation of an application listens on portA and portB (in spite of random, range or fixed) and portA is safe to connect to but portB is not.

What kind of vulnerability you would like to avoid? Could you please clarify?

[ironicman]

"I know it might be a security issue, but won't a whitelist (set by users) be able to solve this"
This is in response to this
"Actually there is lot of listening ports and “listening” applications running on a typical system and most of them are not unconditionally safe even in local network."

"It might even limit the number of ports being opened since some apps listen to random ports while others listen to part of a range of ports. I'm just a bit curious."
I'm referring to some of the app that requires a range of ports to be opened, but in reality they only need some of the ports in the that range. By detecting which port(s) is being listened by the app, it will limit the number of ports being open via port forwarding. Instead of opening a whole range by inputting it manually, have Firewall Control detect the listening port(s) and open that port(s) only via UPnP.

Sorry if this is a bit confusing, not the best at explaining things.

[VistaFirewallControl]

Most probably there is a misunderstanding here.

Maybe an application sample would make the scenario clearer.

Anyway say an application requires A..A1….B1…B (finally A…B) port range to be opened,
but needs a A1..B1. sub-range only.
In other words you would like to set additional limitations for the application with the sub-range.

Technically there is no way to listen on a port range at once, every listening port is set by application separately (individually). Practically we hardly know an application listens on more than 2 ports at once. Although the ports may be randomized, the number of the listening ports remains the same. As the application does not listen on other ports the connection will not be established even the port was forwarded and not blocked by the firewall.

The port uPnP port forwarding specifications do not allow range forwarding, each port can be forwarded individually only. It’s not a W7FC limitation, it’s uPnP specifications.

If the mentioned application is a P2P client, in spite of a port range the app will use only two ports and will forward only those ports on its own, there is no need for W7FC assistance/protection.
If the application chooses another (randomizes) port, it makes uPnP re-forwarding on its own again perfectly without W7FC. The app itself keeps the forwarding minimal required.

If the mentioned application is a regular port-forwarding unaware (say Web) server W7FC helps significantly. But such services use one (maximum two) fixed ports, which can be configured in W7FC.

In the first case the listening port detection looks senseless, as the application does not need W7FC port forwarding making it on its own, always correctly and securely accordingly to (even randomized) listening ports.

In the second case there is no need to detect listening ports as well; the used port(s) is(are) specified/configured within the application.

Theoretically we could picture a FTP server in passive mode with a range of actually listening port, but the port range is specified in the server configuration, vitally required and anyway can not be forwarded as the range via uPnP, you will have to configure the port forwarding in the router manually without uPnP

We still can not draw a situation where information on detected listening ports could affect/improve the security. The detected results will be either predicted (known in advance) or inapplicable practically.
Have we missed something important?
Please correct us with a practical application sample.