Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up Universal Plug and Play

From bering-uClibc
Jump to: navigation, search
Advanced Topics - Setting Up Universal Plug and Play
Prev Bering-uClibc 5.x - User Guide Next


This material copied directly from http://leaf.sourceforge.net/doc/bucu-upnpd.html - needs to be checked/updated for Bering-uClibc 5.x!

Overview of UPnP

Universal Plug and Play is intended to automate the installation and configuration of a small network as much as possible. This means that UPnP capable devices can join and leave a network without any effort of a network administrator.

The upnpd.lrp Package provides Internet Gateway Device services to the network. It is a port of the linux-igd project and UPnP SDK project to the LEAF environment. The firewall will advertise itself as an Internet Gatewayto all UPnP control points (clients). The clients can query the firewall to learn more about its status (bandwidth, traffic statistics), but one of the most useful features is the ability for client applications to request NAT/firewall traversal.

While many common applications running on the Internet are simple client requests which are NAT and firewall friendly (e.g. http), some applications require the host behind the NAT/firewall device to receive inbound sessions. Common examples of this include direct connect features for instant messaging/multimedia conferencing (e.g. AIM, MSN, Y! Messenger). Other examples include peer-to-peer applications like Bittorrent and Gnutella. In each of these cases, the clients act as temporary servers, but these clients may be desktop machines that are assigned dynamic addresses and use dynamic port assignment. Hand configured DNAT and FORWARD rules on the firewall don't work well in such an environment.

For more information on UPnP, search the Intel and Microsoft websites for descriptions of UPnP. Alcatel has provided a good overview of the internals of the UPnP protocol and how it works with their SOHO routers, the basic concepts are similar and can be used to understand this implementation.

Warning: The Universal Plug-n-Play IGD protocol assumes that the devices on the inside of your firewall are trusted, -and- that there is only one exterior interface that requires NAT traversal. This is the common case in small offices and homes. Most SOHO routers shipped today support UPnP because it is such a useful feature. However, a malicious or compromised control point (client on your internal network) can potentially open up a hole in your firewall from the Internet to any port on any machine on your internal network. Additionally, this particular implementation has not undergone rigorous security testing and may be vulnerable to buffer overflows, allowing a malicious control point to gain unauthorized access to the firewall. It is imperative that only trusted hosts be allowed to interact with the UPnP services running on the firewall.

This implementation of UPnP IGD services assumes that there is a single UPnP client network (internal network) and a single external (Internet) connection. While it will run on a multi-port firewall, only one internal interface should be allowed to interact with the UPnP daemon. If you wish to use this on a firewall with multiple interfaces with different security policies, it is your responsibility to insure that your firewall policy does not allow a UPnP client on one interface to open up a hole in your firewall to a host on another interface.

Firewalling UPnP

The UPnP server does not require, and should not be allowed any access to or from any network other than the internal client network. For UPnP to operate, your firewall must allow the following:

Protocol/Port Destination Remarks
UDP 1900 fw to/from local SSDP announcements
TCP 49152 fw from local HTTP/XML mini-server
TCP any port fw to local HTTP/XML queries of other UPnP devices
UDP any port fw to local respond to remote SSDP requests

Additionally, both UPnP on the router and on your control-point clients generate SSDP packets which are multicast to 239.255.255.250. Both also send and listen to IGMP join messages on 224.0.0.22. You must have a route covering these multicast groups pointing towards your internal network or the announcements will be sent towards your default route, which is almost always not what you want. The UPnP wrapper scripts provided in this package will set up a multicast route for you, or you can specify what you want in /etc/default/upnpd.

When a client requests NAT traversal, rules will be created in the forwardUPnP FORWARDING table and UPnP PREROUTING table. This is not the default behavior for UPnP -- it normally writes directly to FORWARDING and PREROUTING.

Important: If you are not integrating with Shorewall as described in this document, you will want to change the configuration in /etc/upnpd.conf.

Installation

  • load the upnpd.lrp Package
  • edit /etc/default/upnpd to specify your external and internal network interfaces and to disable/modify multicast route generation
  • edit /etc/upnpd.conf to describe your bandwidth available upstream and downstream (optional)
  • install and configure shorwall.lrp if you have not already done so (Shorewall is suggested, not required)

Shorewall integration

Proper integration with your firewall policy can be a complex matter requiring local thought. This example should be reviewed for your local conditions and is a good starting place.

Shorewall uses the ipt_owner.o kernel Module for UPnP support. ipt_owner.o can be found in the Bering-uClibc kernel Modules tarball. Add it to /lib/modules and make sure it is loaded in /etc/modules at system startup. If you see an error message when Shorewall runs trying to add an iptables rule with the --cmd-owner option, ipt_owner.o is not loaded.

Specify in /etc/shorewall/interfaces which interface is your upstream interface (your Internet interface) which will receive inbound connection requests after UPnP has authorized them. Add the "upnp" option to that interface.

Example:

net   ppp0   -    upnp,tcpflags,blacklist,routefilter,norfc1918,nosmurfs

Apply the UPnP specific rules in your shorewall rules file. In this example, loc is your internal network zone where UPnP clients are located, net is the upstream network (Internet):

forwardUPnP     net     loc  # dynamic rules inserted here
allowinUPnP     loc     fw   # allow from control points
allowoutUPnP    fw      loc  # allow communication to control points



Prev Up Next