On Tuesday 09 April 2002 03:48, Brian J. Murrell wrote: > I must be missing something here because we seem be going around > and around on this issue. There are no "defined" ports that you > can discern what gets opened and what doesn't. It sounds to me > like all ports are ephemeral, which makes sense because one TCP/UDP > device is mapping ports for a whole network of clients. They can't > all ask for port 80.
You are missing the fact that UPnP portmapping is not for the ISP environment. It's intended scope is small networks. > It sounds like once a client has gotten a port, .NET acts as a > "lookup" service so that parties wishing to meet can find out what > ports their friends are on. So if client software is asking for > ephemeral (non-predictable) ports how can you use the port number > to "firewall" what they are doing? UPnP and .NET is different beasts. Don't mix the two. They serve different purposes independent of each other. The firewall has two sources of information on what the user is up to be doing a) The port numbers requested to be opened. Note that UPnP requires the application to specify exact which port it wants to be opened, it do not provide a "give me a port I can use" call. In most cases this is a 1-1 map of the ports that whould have been used if the computer was connected directly to the Internet. b) The port descriptions assigned by the application. > To put another way, an ISP could try to stop users from setting up > web servers but that is futile because as a protocol, HTTP allows > the specification of a port. Correct, and is why you have connection tracking and stateful firewalls, to be able to block "random ports" unless a proper initiation is seen. UPnP as such do not probit such firewalling. UPnP only allows the inside client to allocate port numbers on the outside. How/if/why you then firewall these ports is up to the implementation. > Well, yes, UPnP could refuse to open the requested ports but then > it's pointless. See this is the problem. Other than trusting the > client software to announce who it is, truthfully, there does not > seem to be any way to determine one access reqeust from another. How would that be pointless? You know the port number, and what the application claims it is to be used for. You know the other traffic initiated by the application announcing these ports to the other end. In many senses no different than FTP PORT. As I said before, implementing connection tracking helpers for odd protocols is a lot simpler than full payload NAT. > Oh no? So there are no "real programs" that have been designed to > tunnel through HTTP in order to circumvent firewalls?. "Real > program" developers do not give two hoots about network security as > much as they wanna provide the "ultimate user experience" and will > circumvent whatever measures they can to do so. This mainly is a social issue, not a technical. If you have users running such programs then you have a major social problem on your hands. No firewalling will help you unless combined with other actions to hunt these activities down. Please distinguish between programs run intentionally by the user, and trojans run unintentionally. > Where "THIS port" is what? Unless it's a predictable value, you > can't base access control on it. THE port the application wants to show to the outside, also carrying a description telling what the application claims the port is to be used for. > But you know that it will not be limited to environments where the > primary concern is access and not security, but will be deployed by > unknowing/security ignorant network admins when the <choose your > favourite computer-toy liking executive> of the company sees he can > use MS IM and NetMeeting (and who knows what is to come) if they > install it. And? These are not likely to have a security policy to start with, and are also likely to click on every "please click on me" button they find, leaving only a couple of hours before they computer is invaded by a trojan completely opening up their network (with or without UPnP support in the NAT gateway) if someone choose to attack them. > > For the sake of keeping this discussion on level think of UPnP as > > nothing more than NAT traversal. > > That is exactly what I am thinking of it as. But unlike > netfilter's NAT, it seems I have to take it all or leave it. I > can't choose what I will NAT for and what I won't. What makes you thing UPnP leaves you with less choice than iptables? In fact, a proper UPnP implementation would just add to the filtering capabilities you already have. > > It is the UPnP daemons responsibility to set up a policy on what > > the user may request, filters on intended uses etc, and to > > integrate this with the firewalling in a sensible manner. > > If it can be done, then hooray. I am not hopeful it has this > sophistication -- that can be trusted. I know where I want to go, and the capabilities it would give, and how to build on this to further increase security. > I think we are likely converging on parallel thoughts. "In violent > agreement" as the saying goes. :-) Perhaps. Regards Henrik
