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 place. > > 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. 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 > blanket. 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 > channels". > > 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 OS:es. 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 security gateway. 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.. Regards Henrik
