On Monday 08 April 2002 00:28, Brian J. Murrell wrote: > Right! But my impression is that you have no idea which > application is requesting the access through the UPnP server. A > security policy of "allow whatever the clients ask for" is no > security policy at all, and unless the firewall/UPnP server knows > which application each request is for (without having to resort to > trusing the application asking to tell it truthfully) then how do > you implement a security policy around this?
The UPnP server do not officially know the application no, but in each portmap request there is at least a connection description / comment describing the use connection, and due to the leverage ontop of HTTP there should also be a User-Agent header. The use and format and of both is up to the application. > Right, and a good reason to disallow it, but in contrast, and IRC > DCC has to go along with an IRC usage. If a trojan wants to > emulate the IRC protocol then yes it will get it's port open but > that's an amount of work to go to get a trojan listening on the > network. So is it to discover the UPnP device, send UPnP portmap request etc.. Further, if your UPnP device (i.e. the NAT:ing firewall) requires authentication then it is not likely a trojan gets very far unless it can persuade the user to provide the needed credentials. > But it's not a choice of "various" protocols. From my > understanding, once you turn on UPnP, any application that knows > how to ask the server can have whatever access (listening ports, > sending port, any numbers of these) it wants gets it. Only within the limitations of what the UPnP device accepts. > So if a single UPnP using application has been determined to > have a vulnerability, there is no way to disable the use of that > one application without disabling all UPnP enabled apps. Not unless there is a fingerprint of this application of some sort no. However, in most cases I expect applications to be easily fingerprinted. > But if you firewall understands the protocols, you can choose which > applications are allowed access and which are not. And in such case you do not have a need for UPnP port forwarding. > So UPnP allows one to differentiate applications making requests > for access? I.e. Messenger is allowed but NetMeeting is not? How > does the UPnP server know which application on a machine is making > the requests for ports? 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. Note to anyone looking for specs: The relevant part of the UPnP specs is WANIP/PPPConnection, specifically the sections relating to NAT portmapping. This specifies how a client can request portmappings to be set up on a UPnP WAN device, allowing connections to be forwarded to the client. This is specifically designed for NAT devices, and not general firewalling. The UPnP NAT portmapping protocol is overly simple in nature, and very limited capabilities. It is not likely to scale to more than a handful of concurrent clients, or to get IETF acceptance I hope.. but interesting none the less. Regards Henrik
