• Do not allow forwards to certain machines on the inside network (blacklisting).
• Only allow forwards to certain machines on the inside network (whitelisting).
• Only allow UPnP requests from authorized machines on the inside network
(whitelisting).
• Do not allow UPnP requests from unauthorized machines on the inside net-
work (blacklisting).
The adaptions given above will not take away all problems – a trojaned machine
which is allowed to make UPnP requests can still have ports forwarded to itself
and thus open up the network for outsiders – and it will certainly require more
configuration than zero, and in some cases it will make the device not UPnP com-
pliant (although the UPnP specifications are unclear about when a device is really
compliant). However, the adaptions will take away a part of the threats that are
described in this paper, without having to make changes to current implementations
and sacrificing any usability.
9 IETF Zeroconf
A protocol similar to UPnP was developed by the IETF and is called “Zeroconf”[9].
It was developed to provide ad-hoc networking and various services, in a similar way
as UPnP. The protocol originated from within Apple. It has recently picked up a
bit of support from vendors. Apple is heavily pushing its own Zeroconf implemen-
tation called “Bonjour” (formerly known as “Rendezvous”). The GNOME project
is thinking about adding a Zeroconf implementation to the GNOME desktop envi-
ronment, while KDE already implemented a large part of Zeroconf for KDE 3.4.
Zeroconf also uses auto-addressing, but it works a bit differently. The precise work-
ings are beyond the scope of this paper. Like with UPnP portmapings can be done.
This is done via the NAT-PMP protocol. The NAT-PMP protocol does not allow a
device to ask port mappings for another device. However, a possible hole exists in
the protocol. The protocol defines that if a portmapping is requested for a certain
port and protocol (TCP or UDP), the NAT gateway has to reserve the companion
port for the other protocol for the client as well. This has not been tested, due to
lack of devices to test with.
10 Convenience versus security
The real issue with UPnP and related technologies, such as IETF Zeroconf, is that
its basic concepts are orthogonal to network security. With UPnP and Zeroconf
devices on a network are peers that organize the network themselves using auto-
addressing and auto-configuration, without needing an administrator to configure
anything: there is in fact zero configuration needed.
It is by definition impossible to implement security in this model without sacrific-
ing the “zero” property, because every way of enforcing even the slightest form of
security requires configuration. For example, if a trust relationship has to be set
up between two devices, at least one of the devices has to be configured: a router
has to allow traffic on the network from the other device, or a public key has to be
added from one device to another.
Kommentare zu diesen Handbüchern