Solaris host-based firewall Truong Q. Nguyen (Tony Nguyen) 09/08/2008 1. Introduction Currently, Solaris has IPfilter which allows user to set up system and service firewall policies. The project delivers a framework to simplify system and services IPfilter configuration. IPfilter uses a set of ipf rules from which it determines whether an IP packet should be allowed in or out of the system. Although ipf rule syntax is fairly simple and straightforward, it still demands good understanding of networking and security concepts, a non-trivial learning curve for 'casual' Solaris users. Moreover, the task of creating and testing ipf rules are mostly manual and can become a management burden in systems where large number of rules are used. Instead of manually construct and specify ipf rules, the proposed framework allows users to express system and services' firewall policies which it uses to generates a set of IPfilter rules to enforce the desired behavior. Essentially, users specify system and service firewall policies that allow or disallow network traffic from certain hosts, subnets, and interface(s). The policies can be translated into a set of active ipf rules to enforce the specified firewall policies. Existing firewall tools, fwbuilder being a good example, may provide highly customized configuration but have other drawbacks. Our proposed solution which targets casual OpenSolaris users, has clear advantages. - Very simple user model. While FirewallBuilder is able to produce highly customized configurations, it requires good understanding of firewall concept and knowledge of the system networking configuration. Setting up FirewallBuilder requires specifying a path, a file, local address, create objects for each service, *configure* firewall for the objects, compile, and run. Our firewall only requires setting policy by changing properties and enable service(s). - Well-integrated with Solaris - Supports IPfilter configuration generated by other tools. Our framework should satisfy the needs of most casual users. However, advanced users can always use tools such as FirewallBuilder to generate IPfilter rules that can be consumed by the proposed framework. 2. Scope Our goal is to provide casual OpenSolaris users and developers a simple way to harden their systems. System administrators can certainly use the firewall framework but may find some deficiencies such as inability to synchronize policies across a group of Solaris systems. The propose project is NOT a firewall configuration tool but an IPfilter-based firewall framework that allows high-level firewall policies and translates those policies to IPfilter rules. Generic firewall construction tools, if possible, should use the proposed framework to configure IPfilter for Solaris machines. The proposed framework isn't a full IPfilter configuration tool, thus it won't generate every possible IPfilter configuration. However, users can specified a custom ipf rule set to be used if the framework can't provide the desired IPfilter configuration. 3. Design Model: The proposed firewall framework provides a simple mechanism to restrict incoming network traffic to a Solaris machine. Network traffic is normally from remote servers and clients to local clients and servers(local network services), respectively. Other types of network traffic include broadcasts and ICMP messages. The goal of any firewall is to block unwanted incoming network traffic and/or restrict access to certain source(s) while allow local client programs to work seamlessly. A three layer approach with different precedence levels helps us achieve the desired behaviors. Global Default - default system-wide policy. This policy is automatically inherited by all services unless services modify their firewall policy. Network Services - higher precedence than Global Default. A service's policy allows/disallows traffic to its specific ports, regardless of Global Default policy. Global Override - another system-wide policy that takes precedence over the needs of specific services in Network Services layer. Global Override | | Network Services | | Global Default A firewall policy includes a firewall mode and an optional set of network sources. Network sources are IP addresses, subnets, and local network interfaces, from which a system can receive incoming traffic. The basic set of firewall modes are: None - no firewall, allow all incoming traffic Deny - allow all incoming traffic but deny from specified source(s) Allow - deny all incoming traffic but allow from specified source(s) Layers in Detail: The first system-wide layer, Global Default, defines a firewall policy that applies to *any* incoming traffic, e.g. allowing or blocking all traffic from an IP address. This makes it simple to have a policy that blocks all incoming traffic or all incoming traffic from unwanted source(s). The Network Services layer contains firewall policies for local programs that provide service to remote clients, e.g. telnetd, sshd, and httpd. Each of these programs, a network service, has its own firewall policy that controls access to its service. Initially, a service's policy is set to inherit Global Default policy, a "Use Global Default" mode. This makes it simple to set a single policy, at the Global Default layer, that can be inherited by all services. When a service's policy is different from Global Default policy, the service's policy has higher precedence. If Global Default policy is set to block all traffic from a subnet, the SSH service could be configured to allow access from certain hosts in that subnet. The set of all policies for all network services comprises the Network Service layer. The second system-wide layer, Global Override, has a firewall policy that also applies to any incoming network traffic. This policy has highest precedence and overrides policies in other layers, specifically overriding the needs of network services. The example is when it's desirable block known malicious source(s) regardless of services' policies. User Interaction: This framework leverages IPfilter functionality and is only active when svc:/network/ipfilter is enabled. Similarly, a network service's firewall policy is only active when that service is enabled. A system with an active firewall has IPfilter rules for each running/enabled network service and for system-wide policy(s) with firewall mode other than "None". User's enabling and disabling action for a service corresponds to firewall policy activation and deactivation for that service. A user changes firewall settings by modifying a service and/or system-wide firewall policy. The firewall framework composes of policy configuration and a mechanism to generate ipfilter rules from the policy and applying those rules to get the desired IPfilter configuration. A quick breakdown of the design: - system-wide policy(s) are stored in network/ipfilter - network services' policies are stored in each SMF service - activate firewall by enabling network/ipfilter - activate/deactivate per-service firewall policy by enabling/disabling that network service - changing a system-wide or per-service firewall policy results in an update to the system's firewall rules Availability and observability: Misconfigured service firewall policies will result in service unavailability, service in maintenance state. However, a misconfigured system-wide policy will place only network/ipfilter in maintenance. Essentially, the desired behaviors are 1. If a service firewall policy is misconfigured, the service is placed in maintenance and svcs -x will give reason that the service is placed in maintenance by request of network/ipfilter and suggests user to look into network/ipfilter for specific errors. 2. If a system-wide policy is misconfigured, network/ipfilter is placed in maintenance and network services are allowed to continue running. This behavior is consistent with existing behavior where misconfigured network/ipfilter doesn't affect running services. The alternative is stopping and placing all network services in maintenance. However, this is a significant change to existing behavior and offlining services that don't have "require" dependency is a violation of SMF usage model. 4. Configuration See the new svc.ipfd.1m 5. IPv6 support The proposed architecture fully supports IPv6 which comprises of allowing policy configuration to store IPv6 addresses and pools and separately generating and loading IPv6 rules. Providing IPv6 addresses and pools support in policy configuration can be done by additional type specifiers such as: IPv6 host: host6:IP "host6:2001:db8:3c4d::1a2b" IPv6 subnet: network6:IP/netmask "network6:2001:db8:3c4d::/48" IPv6 ippool: pool6:pool number "pool6:66" A service whose policy specifies IPv6 addresses would generate an additional IPv6 rules file which will be loaded using "ipf -6". However, IPv6 support is not provided at the initial integration. The rationale for this lack of support is twofold. This proposed framework is the enabling technology for the Services Firewall Panel, to be delivered in Visual Panel Project for OpenSolaris 2008.11. The Visual Panels project aims to simply Solaris management for casual Solaris users and a host-based firewall functionality, though lacking IPv6 support, is still a positive step toward that goal. The second reason for not having IPv6 at initial integration is the testing effort required for IPv6 functionality. While the work to support IPv6 is not too challenging, the additional testing places a heavy burden on our schedule thus the proposed incremental integrations. We are committed to support IPv6 and plan to have a follow-on putback in a couple of months to add IPv6 support. 6. Upgrade handling For machines with existing ipf.conf, it's necessary to preserve that setting upon upgrade by configuring the system-wide default policy to "custom" and specify ipf.conf in the custom_policy_file property. 7. Exported Interfaces Service static configuration property group and properties: firewall_context/name Committed firewall_context/isrpc Committed firewall_context/ipf_method Committed Service firewall configuration property groups and properties: firewall_config/policy Committed firewall_config/apply_to Committed firewall_config/exceptions Committed Global Default policy property groups and properties: firewall_config_default/policy Committed firewall_config_default/apply_to Committed firewall_config_default/exceptions Committed firewall_config_default/custom_policy_file Committed firewall_config_default/open_ports Committed Global Override policy property groups and properties: firewall_config_override/policy Committed firewall_config_override/apply_to Committed firewall_config_override/exceptions Committed FMRIs for system-wide policies: svc:/network/ipfilter:default Committed 8. Imported Interfaces SMF properties: inetd/name inetd/isrpc restarter_actions/properties libnsl(3LIB) libsocket(3LIB) 9. A new /usr/lib/servinfo utility, project private binary, which uses getservbyname(3SOCKET) and rpcbind(3NSL) to get protocol and port information for a named service or RPC program number. This utility provides the framework a convenient way to obtain service's listening ports. /usr/lib/servinfo [-R] [-Ppl] [-tu[6]] -s service_name 10. Documentation changes The SMF FAQ on opensolaris.org will be updated to contain a how-to for both users and service developers. svc.ipfd.1m(new) System Administration Commands svc.ipfd(1M) NAME svc.ipfd - IPfilter firewall monitoring daemon SYNOPSIS /lib/svc/bin/svc.ipfd svc:/network/ipfilter:default DESCRIPTION svc.ipfd monitors actions to services with firewall configuration and initiates update services' IPfilter configuration. The daemon allows us to react to changes in system's firewall configuration in an incremental fashion, at per service level. A service's firewall policy is activated when it's enabled, deactivated when it's disabled, and updated when its configuration property group is modified. svc.ipfd monitors SMF repository for these actions and invokes IPfilter rule generation process to carry out the service's firewall policy. Environment Variables and Context This daemon is started by the network/ipfilter service either through the start or refresh method. Thus, the daemon inherits the environment variables and credentials from the method and runs as root with all zone privileges. FIREWALL STATIC CONFIGURATION Static definition describing service's network resource configuration that is used to generate service specific ipf rules. A new per service "firewall_context" property group contains a service's static definition, similar to "inetd" property group in inetd managed services. - firewall_context/name, IANA name or RPC name for non-inetd service, equivalent to inetd/name property - firewall_context/isrpc, a boolean property where a "true" value indicates an RPC service, equivalent to inetd/isrpc property. For RPC services, the value of firewall_context/name is not an IANA name but is either an RPC program number or name, see rpc(4). Additionally, some services may require a mechanism to generate and supply their own ipf rules. An optional property ipf_method, provides a mechanism to allow custom rule generation. - firewall_context/ipf_method, a command, normally a script that generates ipf rules for a service. The framework does not generate rules for services with this property definition but expect these services to provide their own rules. A service's ipf_method specifies a command that takes an additional argument, its own fmri and generates the service's firewall rules and output the rules to stdout. To generate rules for a service with ipf_method property, the framework execs the command specified in ipf_method, passing the service fmri as the additional argument and stores the rules for that service by redirecting the command output, the rules, to the service's rule file. Because an ipf_method is exec'ed from the context of either network/ipfilter start or refresh method process, it inherits the execution context and runs as root. Administrative Privilege The service static configuration, is delivered by service developer and and not intended to be modified by users. These properties are only modified upon installation of an updated service definition. FIREWALL POLICY CONFIGURATION A per service property group, firewall_config, stores the services' firewall policy configuration. Since network/ipfilter:default is responsible for two firewall policies, Global Default and Global Override system-wide policies as explained in ipfilter(5), it has two property groups, firewall_config_default and firewall_config_override, to store the respective sytem-wide policies. Below are the properties, their possible values and correspoding semantics: policy "none" policy mode - no access restriction. For a global policy, this mode allows all incoming traffic. For a service policy, this mode allows all incoming traffic to its service. "deny" policy mode: more restrictive than "none". This mode allows incoming traffic from all sources except those specified in the "apply_to" property. "allow" policy mode: most restrictive mode. This mode blocks incoming traffic from all sources except those specified in the "apply_to" property. apply_to A multi-value property listing network entities to enforce the chosen policy mode. Entities listed in apply_to property will be denied if policy is "deny" and allowed if policy is "allow". The syntax for possible values are: host: host:IP "host:192.168.84.14" subnet: network:IP/netmask "network:129.168.1.5/24" ippool: pool:pool number "pool:77" interface: if:interface_name "if:e1000g0" exceptions A multi-value property listing network entities to be excluded from the "apply_to" list. For example, when deny policy is applied to a subnet, exceptions can be made to some hosts in that subnet by specifying them in the "exceptions" property. This property has the same value syntax as "apply_to" property. For individual network services only: firewall_config/policy A service's policy can also be set to "use_global". Services with "use_global" policy mode inherits the Global Default firewall policy. For the Global Default only: firewall_config_default/policy - can also be set to "custom" Global Default policy, firewall_config property group in svc:/network/ipfilter:default, can also be set to "custom". Users can set policy to "custom" to use prepopulated IPfilter configuration, e.g. existing IPfilter configuration or custom configurations that can't be provided by the framework. This Global Default only policy mode allows users to supply a text file containing the complete set of ipf rules. When "custom" mode is selected, the specified set of ipf rules is *complete* and the framework will not generate ipf rules from configured firewall policies. firewall_config_default/custom_policy_file A file path to be used when Global Default policy is set to "custom". The file contains a set of ipf rules which provide the desired IPfiler configuration. For example, users with existing ipf rules in /etc/ipf/ipf.conf can excute the following commands to use the existing rules: 1. Set custom policy #svccfg -s ipfilter:default setprop \ firewall_config_default/policy = astring: "custom" 2. Specify custom file #svccfg -s ipfilter:default setprop \ firewall_config_default/custom_policy_file = astring: \ "/etc/ipf/ipf.conf" 3. Refresh configuration #svcadm refresh ipfilter:default firewall_config_default/open_ports Non-service program requiring allowance of its incoming traffic can request the firewall to allow traffic to its communication ports. This multi-value property property contains protocol and port(s) tuple in the form "{tcp | udp}:{PORT | PORT-PORT}" Initially, the system-wide policies are set to "none" and network services' policies are set to "use_global". Enabling network/ipfilter activates the firewall with an empty set of ipfilter rules, since system-wide policy is "none" and all services inherit that policy. To configure a more restrictive policy, use svccfg(1M) to modify network services and system-wide policies. Administrative Privilege User configures firewall policy by modifying the service's firewall_config property group. A new authorization "solaris.smf.value.firewall.config" is created to allow delgation of firewall administration privilege to users. The Service Operator users will need this new authorization to be able to configuration firewall policy. FIREWALL AVAILABILITY During boot, firewall is configured for enabled services prior to starting of those services thus services are protected on boot. While the system is running, administrative actions such as service restarting, enabling and refreshing may cause a brief service vulnerability during which the service runs while its firewall is being configured. svc.ipfd monitors service's start/stop events and configures or unconfigures service's firewall at the same time that SMF is starting or stopping the service. Since the two operations are simultaneous, there's a possible window of exposure (less than a second) if the service is started before its firewall configuration completed. RPC services typically listen on ephemeral ports which are not known until the services are actually running. Thus RPC services are subjected to similar exposure since their firewall are not configured until the services are running. DEVELOPER DOCUMENTATION Services providing remote capabilities are encouraged to participate in the firewall framework to control network access to the service. While framework integration isn't mandatory, remote access to services that are not integrated in the framework may not function correctly when a system-wide policy is configured. Integrating a service into the framework is as straightforward as defining two additional property groups and their corresponding properties in the service manifest. IPfilter rules are generated when user enables the service. In the non-trivial case of custom rule generation where a shell script is required, there are existing scripts that can be used as examples. The additional property groups, firewall_config and firewall_context stores firewall policy configuration and provides static firewall definition, respectively. Below is a summary of new property groups and properties and their appropriate default values. Firewall policy configuration: firewall_config See FIREWALL POLICY CONFIGURATION section for more information. Access to is protected by a new authorization definition and a user-defined property type. The new authorization should be assigned to the property group value_authorization property such as Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_configuration" as the property type. firewall_config/policy This property's initial value should be "use_global" since services, by default, inherit the Global Default firewall policy. firewall_config/apply_to An empty property, this property has no initial value. firewall_config/exceptions An empty property, this property has no initial value. Firewall static definition: firewall_context See FIREWALL STATIC CONFIGURATION section for more information. Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_definition" as the property type. firewall_context/name Service with well-known, IANA defined port which can be obtained by getservbyname(3SOCKET), the service's IANA name is stored in this property. For RPC services, the RPC program number is stored in this property. firewall_context/isrpc For RPC services, this property should be created with its value set to "true" firewall_context/ipf_method In general, the specified firewall policy is used to generate IPfilter rules to the service's communication port, derived from firewall_context/name property. Services which don't have IANA defined ports and are not RPC services, will need to generate their own IPfilter rules. Services that generate their own rules may choose not to have firewall_context/name and firewall_context/isrpc properties. See the following services svc:/network/ftp:default svc:/network/nfs/server:default svc:/network/ntp:default and others with existing ipf_method for guidance. ATTRIBUTES See attributes(5) for descriptions of the following attributes: System Administration Commands svc.ipfd(1M) ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu SUNWipfr | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| SEE ALSO ipfilter(5), ipf(4), rpc(4), svcs(1), svcprop(1), svcadm(1M), svccfg(1M), attributes(5), smf(5) --- /tmp/ipfilter.5.orig Fri Sep 12 14:27:32 2008 +++ /home/tn143363/vpanels/firewall/ipfilter.5 Fri Sep 12 14:03:21 2008 @@ -19,6 +19,118 @@ See ipf(1M) for a procedure to enable and activate the IP Filter feature. +HOST-BASED FIREWALL + To simplify IPfilter configuration management, a firewall framework is + created to allow users to configure IPfilter by expressing firewall policy + at system and service level. Given the user defined firewall policy, the + framework generates a set of IPfilter rules to enforce the desired system + behavior. Users specify system and service firewall policies that allow or + deny network traffic from certain hosts, subnets, and interface(s). The + policies are translated into a set of active ipf rules to enforce the + specified firewall policies. + + Note - + + Users can still specify their own ipf rule file if they choose not to + take advantage of the framework. See svc.ipf(1M) and ipf(4). + + Model + + This section describes the host-based firewall framework. See svc.ipfd(1M) + for details on how to configure firewall policies. + + A three layer approach with different precedence levels helps us achieve + the desired behaviors. + + Global Default - default system-wide firewall policy. This policy is + automatically inherited by all services unless services modify their + firewall policy. + + Network Services - higher precedence than Global Default. A service's + policy allows/disallows traffic to its specific ports, regardless of + Global Default policy. + + Global Override - another system-wide policy that takes precedence over + the needs of specific services in Network Services layer. + + Global Override + | + | + Network Services + | + | + Global Default + + A firewall policy includes a firewall mode and an optional set of network + sources. Network sources are IP addresses, subnets, and local network + interfaces, from which a system can receive incoming traffic. The basic set + of firewall modes are: + + None - no firewall, allow all incoming traffic + + Deny - allow all incoming traffic but deny from specified source(s) + + Allow - deny all incoming traffic but allow from specified source(s) + + Layers in Detail + + The first system-wide layer, Global Default, defines a firewall policy + that applies to *any* incoming traffic, e.g. allowing or blocking all + traffic from an IP address. This makes it simple to have a policy that + blocks all incoming traffic or all incoming traffic from unwanted source(s). + + The Network Services layer contains firewall policies for local programs + that provide service to remote clients, e.g. telnetd, sshd, and httpd. + Each of these programs, a network service, has its own firewall policy + that controls access to its service. Initially, a service's policy is set + to inherit Global Default policy, a "Use Global Default" mode. This makes + it simple to set a single policy, at the Global Default layer, that can be + inherited by all services. + + When a service's policy is different from Global Default policy, the + service's policy has higher precedence. If Global Default policy is set + to block all traffic from a subnet, the SSH service could be configured to + allow access from certain hosts in that subnet. The set of all policies + for all network services comprises the Network Service layer. + + The second sytem-wide layer, Global Override, has a firewall policy that + also applies to any incoming network traffic. This policy has highest + precedence and overrides policies in the other layers, specifically + overriding the needs of network services. The example is when it's + desirable block known malicious source(s) regardless of services' + policies. + + User Interaction + + This framework leverages IPfilter functionality and is active only when + svc:/network/ipfilter is enabled and inactive when network/ipfilter is + disabled. Similarly, a network service's firewall policy is only active + when that service is enabled and inactive when the service is disabled. A + system with an active firewall has IPfilter rules for each running/enabled + network service and system-wide policy(s) whose firewall mode isn't "None." + User configures firewall by setting the system-wide policies and policy + for each network service. See svc.ipfd(1M) on how to configure a firewall + policy. + + The firewall framework composes of policy configuration and a mechanism to + generate ipfilter rules from the policy and applying those rules to get + the desired IPfilter configuration. A quick summary of the design and user + interaction: + + - system-wide policy(s) are stored in network/ipfilter + + - network services' policies are stored in each SMF service + + - user activates firewall by enabling network/ipfilter, see ipf(1M) + + - user activates/deactivate a service's firewall by enabling/disabling + that network service + + - changes to system-wide or per-service firewall policy results in an + update to the system's firewall rules + @@ -30,6 +137,15 @@ NOTES - In the current release of the Solaris operating system, IP - Filter startup configuration files are stored in /etc/ipf. + The nfsd service is managed by the service management facil- + ity, smf(5), under the service identifier: + svc:/network/ipfilter:default. + + Administrative actions on this service, such as enabling, + disabling, or requesting restart, can be performed using + svcadm(1M). The service's status can be queried using the + svcs(1) command. + + In the current release of the Solaris operating system, IP + Filter startup configuration files are stored in /etc/ipf. --- /tmp/ipf1m.orig Thu Oct 2 17:27:25 2008 +++ ipf.1m Thu Oct 2 17:30:37 2008 @@ -46,7 +46,8 @@ ment rights profile (see rbac(5)) or become superuser. - 2. Create a packet filtering rule set. See ipf(4). + 2. Configure system and services' firewall policies. + See svc.ipfd(1M) and ipf(4). 3. (Optional) Create a network address translation (NAT) configuration file. See ipnat.conf(4). @@ -84,35 +85,38 @@ - To re-enable packet filtering after it has been temporarily - disabled either reboot the machine or perform the following - series of commands: + disabled either reboot the machine or run the following + command: - 1. Enable Solaris IP Filter: + # svcadm enable network/ipfilter - # ipf -E + which essentially executes the following ipf commands: + 1. Enable Solaris IP Filter: + # ipf -E - # ipf -E + which essentially executes the following ipf commands: + 1. Enable Solaris IP Filter: + # ipf -E - 2. Activate packet filtering: + 2. Load ippools: - # ipf -f + # ippool -f + See ippool(1M) + 3. Activate packet filtering: - 3. (Optional) Activate NAT: + # ipf -f - ipnat -f + 4. (Optional) Activate NAT: + # ipnat -f - See ipnat(1M). + See ipnat(1M). Note - - If you reboot your system, the packet filtering rules in - the /etc/ipf/ipf.conf file and the /etc/ipf/ipnat.conf - file are activated. + If you reboot your system, the IPfilter configuration is + automatically activated.