[UPnP-SDK-discuss] UPNP Server/Application Gateway for Linux
Brian J. Murrell
Sun, 7 Apr 2002 05:58:27 -0400
Content-Type: text/plain; charset=us-ascii
On Sun, Apr 07, 2002 at 11:13:58AM +0200, Andre Breiler wrote:
> Yes it does since the UPnP thread started.
Good, it's not just me.
> Yes this is one aspect but here is an other.
> It's used for NAT in first place with the side effect of added security
I think I disagree. Security (access mitigation) as always been
there, NAT as kinda "grown on", through a historical path of
MASQUERADING in 2.2, and heck I don't even recall what it was on 2.0.
I know ipfwadm but forget it's core functionality.
> Under that condition it makes perfectly sense to me to have UPnP support.
If you are building a "access provider" and not a "firewall", yes, but
I guess what I am asking is don't more netfilter boxes go in for
security than access provision?
> And please keep in mind that most NAT helpers are doing the same (opening
> paths to the box behind the FW).
I think the lowest common denominator of the argument is whether
netfilter is a NAT device or a security device. I suppose to me, it's
a security device. I guess to you it's a service provision device.
> Yes but you are using it for other things (logging, application level
> filtering) too.
True, but _my_ goal for all of those is security.
> As I understand it from the discussion so far the plan is that you are
> able to overwrite/restrict the port range which will be opened.
Why provide the service if you are not going to fulfill the requests?
If a UPnP request comes in for 5 ports, you can't really only give 3
and say "deal with it" to the application. You need to either service
the request or not.
> So it won't be worse than the helpers like FTP, H323, IRC.
Oh yes it is! FTP, H323 and IRC are all defined protocols and
netfilter provides the channels needed to communicate based in _it's_
knowlege of what they are going to be used for. From what I hear
about UPnP here, it is simply a way for a machine behind the security
device to poke whatever holes it wants in the security blanket.
I don't think the UPnP client says to the server "I want one TCP
channel for the FTP back channel", but rather says "give me one TCP
channel", or "give me 10 TCP channels" or "give me 65535 TCP
> ... (rant about insecure OSs deleted)
But the rant is relevant because the basis of the rant is a primary
reason for the security device.
> Yes if we (as security admin) are happy with this.
Right! I for one would not be happy giving closed source software
(i.e. not available for security review) "unmitigated" access to
poking holes in the security blanket.
There is nothing stopping a trojan, spread by e-mail virii from making
a UPnP request and making the machine a zombie sitting in wait for
instructions from it's "master". With protocol aware conntracking,
this is more difficult. A trojan could mask itself as a supported
protocol which allows port "listening" but it would take substantial
effort for the trojan to mask another protocol enough for this to
Brian J. Murrell
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----