[UPnP-SDK-discuss] UPNP Server/Application Gateway for Linux
Sun, 7 Apr 2002 15:33:23 +0200
On Sunday 07 April 2002 11:58, Brian J. Murrell wrote:
> 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?
A firewall who gives no access is very effective, but not likely to
make you very famous as it also inhibits any communication to take
> > 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
netfilter is both. Depends on how you use it.
> > Yes but you are using it for other things (logging, application
> > level filtering) too.
> True, but _my_ goal for all of those is security.
And yet allow users to connect computers you do not trust to the
network? And surf the web or read email on those?
I would say you have other higher priority goals than security. There
is always a balance to be found between security and functionality.
> 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.
This is what you define when defining a security policy. Only
applications fitting the security policy can be used by your users.
> 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
So is IRC DCC more or less.
> 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
> But the rant is relevant because the basis of the rant is a primary
> reason for the security device.
To me the basis of the rant is to show that you have other priorities
than maximum security, or else you would not allow those OS:es to be
connected to your network.
Providing UPnP is about providing a security capability to your
users, as is providing the ability to run desktops with insecure
What you provide is based on your security policy. If your policy do
not allow insecure OS:es or the use of UPnP then it is not allowed.
The point of providing an UPnP service is that you can make a more
flexible policy, allowing use of various kinds of protocols without
having to have each of these protocols fully understood by your
Obviously you need a policy defining the conditions on when/why/how
UPnP may be used. Any sane security gateway administrator would not
give unlimited UPnP permissions to all users with no sanity checking.
This policy needs to find where a reasonable balance between security
and functionality for your organisation.
From a security perspective it is somewhat limited if the application
needs to tell what the port is to be used for, as unless your
security gateway recognises the data format of all possible protocols
nothing stops a trojan to simply spoof the reason.
> > 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.
Then don't. The choice is yours.
> 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".
As is commonly done with IRC today. In fact, IRC is close to
unbeatable for this use as it disconnects the "master" from the
zombies making it a lot harder to track who the "master" is..