Hi Darren, Thanks for the valuable comments. See my responses inline. -tony
Darren Reed wrote: > Tony, > > Looking through the design...looks pretty good... > > - while there is mention of enable/disable for various services, > no mention is made of refresh/reload. You'll need to ensure > that your design encompasses handling both of these actions > on network services as well as network/ipfilter. Mention of > this seems worthwhile. > refresh/reload can have several semantics, one of which is activate a service's configuration change which can be a change in service's firewall policy. In the current implementation, refreshing a services causes its rules to be unloaded and regenerate. See Partial Update section which should probably be clearer. > I don't understand this at the top of section 3: > > "Firewall policies comprising a mode and two lists of > network sources, strings, are stored as SMF properties." > > I think this is meant to be "of a mode", but what is a mode? > It could be clearer. Basically, a firewall setting is policy value and if applicable, a list of network sources. The available values for a policy are "none", "deny_all_except", and "allow_all_except" - if policy is "none", we allow all incoming traffic and don't use any list. - if policy is "deny_all_except", we deny *all* incoming traffic by default and only allow network identities specified in the "deny_except_list" property. - if policy is "allow_all_except", we allow *all* incoming traffic by default and only deny network identities specified in the "allow_except_list" property > The tree for allow/deny with exceptions is only 2 deep. > I'm not sure this is enough and needs at least another layer. > Or maybe I'm not putting the pieces together right... > For example, if I set my global policy to "deny_all_except", > I might then specify 129.146/16 in the default allow "except" > list but may wish to put holes in that for, for example, > blocking traffic from Tony's desktop. A really neat scenario. Essentially, we want to block all but allow from 129.146/16, except specific host(s) on that 129.146/16 network. In this case, we would configure use both the Global Default and Global Override layers to get the desired behavior. - Global Default policy is set to "deny_all_except" and specifiy 129.146/16 in the "deny_except_list" - Global Override policy is set to "allow_all_except" and specify unwanted hosts on 129.146/16 network in the "allow_except_list" Having another layer for each firewall configuration as you suggested is a good option but I'm concerned about the more complex user model, deny all but allow some, except a few. The current implementation while not flawless(can't apply the above scenario to a service), is a simpler model and would satisfy most use cases, in my opinion. > I'm also not clear on > what the name is for the network service attribute that > defines the policy to use (but I'm probably missing something.) > If you refer to the firewall_context/name and inetd/name properties, they are IANA names that are used to obtain a service's port and protocol information through getservbyname(3SOCKET). > With respect to FTP (and possibly other services), it can > be of benefit to configure the NAT part of IPFilter to > assist with the security. IPFilter has an in-kernel proxy > that can examine the FTP protocol and open the exact > ports required. (The FTP data port = FTP command port -1.) > If this isn't on the drawing board for the first pass through > then it needs to be somewhere for a revisit. And perhaps > more importantly, there are security provisions within the > proxy that guard the FTP server from being used as an > attack vehicle. > Definitely. I'll put this on my list and follow up with you offline. > If a network service is in maintenance mode, for one > reason or another, what impact does that have on the > firewall rules? > Currently, active rules for a service aren't affected if the service goes into maintenance mode. Essentially, a service's firewall shouldn't be affected by the service's operating mode(maintenance or degraded). The other approach is to remove the active rules but that has a potential issue where a service may have been deleted and its ipf_method is now missing. Since a service's rules are completely independent of other services' rules, either solution would not impact firewall rules outside the service in maintenance mode. > For RPC services, given you are querying rpcbind to > access port number information, is there any merit in > also storing that retrieved information back in the > running profile of the RPC service in a volatile field? > (This is possibly outside the scope of this project.) > I'm not sure I understand the benefit of caching port information given that some RPC services have dynamic ports. Would you clarify?
