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. 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? 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. 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.) 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. If a network service is in maintenance mode, for one reason or another, what impact does that have on the firewall rules? 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.) And... That's all for now. Cheers, Darren
