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 > sometimes. 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 channels". > ... (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 work. b. -- Brian J. Murrell
msg00580/pgp00000.pgp
Description: PGP signature
