On Monday 08 April 2002 05:45, Brian J. Murrell wrote: > > Only within the limitations of what the UPnP device accepts. > > But that is the question. If apps are just asking for mappings on > the UPnP device (i.e. listen TCP port 456) how can the device > impose any limitiations. There is nothing security wise for it to > determine what it should allow and what it should deny.
By the same way as you firewalling policy knows to allow the user to go out on port 80. You have a policy saying that users X & Y are allowed to punch such holes for port 456 under certain given conditions. UPnP is just the tool, not the policy on how it may be used. > > Not unless there is a fingerprint of this application of some > > sort no. However, in most cases I expect applications to be > > easily fingerprinted. > > You are more optimistic than I. :-) I am optimistic that applications can be fingerprinted, which is sufficient to be able to say that users are not allowed to use application X. I am very pessimistic on a trojan not being able to spoof such fingerprints. > > UPnP port forwarding as such do not guarantee that you can > > differentiate the applications, or that the you can trust > > whatever the applications claim to be. But due to the richness of > > information in the protocols involved you are extremely likely to > > make rules differentiating these applications. > > Perhaps. But that point, perhaps you have already have implemented > a conntracking/natting helper. Connection tracking helpers is many times simpler to implement than nat helpers. And here I am not talking about the payload protocols, but the fingerprinting of what the requesting application is claiming to be. Regards Henrik
