On Tuesday 09 April 2002 01:18, Henrik Nordstrom wrote: > But this thread is about how we can provide UPnP port mapping within > iptables/netfilter in a sensible manner, not how poor the reality of > Internet security actually is when you do not trust your clients at > all. I say providing UPnP with a adequate level of security for the > scope where UPnP is useful is entirely possible.
I had the sense that Brian was only arguing against UPnP because of his security fears. But you are right, back to topic... > From what have been told by Brian Murrel about his network I don't > think UPnP is anything he should or need to be running. The scope of > UPnP port mapping is relatively small networks with a NAT gateway and > no internal routers. For anything outside this scope the protocol is > highly unsuitable by design. As a rule of thumb one can say that if > you have a NAT:ed network where it is likely more than one client at > a time needs to run the same application requiring inverse-NAT for > incoming connections then UPnP is likely not the tool for the job. > > If you don't have a NAT:ed network, then UPnP port mapping plays no > role. I browsed the spec and you are right. The aspect of UPnP which we are talking about have the goal to control those little hardware boxes which brings a few PCs over a dialup connection with NAT to the internet. If i understand the spec correct, a UPnP deamon have also to provide control over your ppp-deamon. The main aspect of the spec is configuring and controling your dialup connection and the posibility to configure port-forwarding is additional. At this commands is mentioned that the deamon also have to configure the firewall, if one is implemented :-), according to forwared ports. If i'm not wrong ctnetlink will provide what a UPnP deamon needs to support this port-farwding requests. Port reservation isn't really a problem because the only case when a UPnP deamon can reject such port-forwading request is, when the same tuple of external IP, port and destination IP and port is used by another internal host. Even if all ports on the NAT-Device are occupied the deamon isn't allowed to reject such a request.... My comment: great spec, very realistic ;-))) I would say much fun for the programmers of an UPnP deamon for linux. To be serious: security isn't an aspect of the spec. So if you follow the spec it will end in a deamon which serves every request it's receiving (the nightmare not only of Brian Murrel :-). But with the information you get with a request it will be hard to deceide how to process with it. Also it should definatly be implemented with a minimal ruleset to add at least a minimum of security. Regards Nils Ohlmeier
