|
Style Cleanup Required |
|
Needs Updating |
Introduction
This project is a deamon that emulates Microsoft's Internet Connection Service (ICS). It implements the UPnP Internet Gateway Device specification (IGD) and allows UPnP aware clients, such as MSN Messenger to work properly from behind a NAT firewall.
Repository Installation
Install
sudo apt-get install linux-igd
Note:
- Ubuntu 7.04 reportably works
- Ubuntu 7.10 has Broken packages
- Ubuntu 8.04 this package has been removed from the repository
Configuration
To edit the configuration file
sudo nano -w /etc/default/upnpd
Edit your internal and external interfaces
Manual Install
Installation
First of all you will need the Intel Linux UPnP SDK which can be downloaded from sourceforge here:
Untar the Intel UPnP SDK, but before you compile and install, you will need to make one change for Windows Messenger to work properly. Under the upnpsdk tree, the file src/ssdp/ssdplib.c, on line 406, the following line needs to be changed from:
SelfAddr.sin_addr.s_addr = inet_addr(SSDP_IP);
to:
SelfAddr.sin_addr.s_addr = htonl(INADDR_ANY);
Next download and untar the Linux IGD. Now just run "make" and "make install" in the Linux IGD directory. This will copy the program files into /usr/bin/ and the configuration files into /etc/linuxigd.
Also, you will need to make sure you have a route in your routing table for the multicast address. The following line should work:
route add -net 239.0.0.0 netmask 255.0.0.0 int_if
Just replace int_if with the name of your internal interface (i.e., route add -net 239.0.0.0 netmask 255.0.0.0 eth1)
NOTE: the file has /usr/sbin/iptables as the location of the iptables executable. If yours is different, either add a symbolic link here for it, or just change the references in gateway.h for the variable IPTABLES.
Starting the daemon
To run, type:
upnpd <extif> <intif>
Where <extif> and <intif> are the names of your external interface and internal interface respectively. The daemon will fork into the background and begin running. Debug messages go to /var/log/debug and Error messages go to /var/log/messages. Upon successful start up, the last line you should see in /var/log/debug is Advertisements Sent. This means the program is loaded and the upnp service is initialized. Any other problems would most likely be due to your existing firewall rules or routes. See the README included with this distribution for more information on the details of running the daemon.
Stopping the daemon
To stop the upnpd process the easiest way is to run:
killall upnpd
at a shell prompt. Also, it may be killed by doing:
kill <process_id>
where process_id is the inital process id of the program. However, since there are many of them, it's usually just easiest to run killall. This will cause all portmappings to be closed cleanly and advertisements to be sent to clients telling them the daemon is no longer available.
Portmapping notes
NOTE: This program only creates DNAT (portmap) entries in you firewall on the external interface (public ip). Any other firewall code must be set to allow basically all tcp and udp through the FORWARD chain to your client machines, and the client machines must be able to contact the firewall using tcp and udp through the firewall's INPUT chain on it internal interface.
We will be adding some checks to see if FORWARD has a default policy of DROP or REJECT, however placing rules once we determine this is a bit tricky. At the moment there is no real way to check to see if a packet matching this rule will pass through any additional rules that may be located above it. Also, we will probably need to check for any rules below as well. Hopefully we can get this implemented soon.
In the meantime, please be aware of this fact, and if you are seeing Advertisements sent in the /var/log/debug file (or whatever you have syslog set to log DEBUG level messages to), but you are not seeing AddPortMaps, your firewall configuration is most likely the problem, or it could be the following problem.
UPnP works with the 239.0.0.0/255.0.0.0 multicast addresses. Windows Messenger may also send request to a Unicast address, and thus the reason for the patch to the UPnP source code for this to work. Nevertheless, to add a route in your box for the multicast address, just use the following command, replaceing <int_if> with the interface name of your inside interface name (i.e., eth0).
route add -net 239.0.0.0 netmask 255.0.0.0 <int_if>
That's it, you'll want to make sure your iptables rules aren't blocking this as well. Iptables has great strengths, but one of its weaknesses is no usespace api at the moment to help with us intelligently adding rules. So most of getting this to work requires you understanding how UPnP works, and being able to adjust your firewall rules to this. The above should get you started, however. It's rather simple.
Security notes
There are many opponents against UPnP. However, we feel that Open Source is all about giving people choices, and letting intelligent people make intelligent decisions about its use. A lot of us really NEED this daemon, and can live with the consequences because we are simply connecting a home network to the internet through one ip, and we would have had the windows machines (or whatever internet device) connected directly in the first place. That being said, here we go:
UPnP version 1.0, on which this program is based, is inherently flawed. As with alot of Microsoft supported software, there was a lot of theory put out there, but no code. What appears to have happened is that in Microsoft's first UPnP implementation they weren't concerned with security or any advanced controls. Simply all they wanted was connectivity. So we are stuck with this for now. The UPnP server, by itself, does no security checking. If it recieves a UPnP request to add a portmapping for some ip address inside the firewall, it just does it. This program will attempt to verify the source ip contained in the UPnP request against the source ip of the actual packet, but as always, these can be forged. The UPnP server makes no attempt to verify this connection with the caller, and therefore it just assumes that whoever asked is the person really wanting it. Theoretically this could open up ports on some other box than the caller to the outside world, and this is where intelligent decision making comes in. If you restrict the ability of this to happen with iptables rules, then this becomes a non-issue, and only the machines that iptables allows to have stuff go to will be allowed. But sure, everyone can come up with some way to get around this so listen. We are going to try to do the best we can to place source ip verification, config files that say which machines can request portmappings, and which machines can recieve portmappings, and any other things that come along.
Authors
- schweitzereffect (Ubuntu fourm)
References