Working With Solaris IP Filter Rule Sets
To manage your firewall, you use Solaris IP Filter to specify rule
sets that you use to filter your network traffic. You can create the
following types of rule sets:
Additionally, you can create address pools to reference groups of IP addresses. You
can then use these pools later in a rule set. The address
pools help to speed up rule processing. Address pools also make managing large
groups of addresses easier.
Using Solaris IP Filter's Packet Filtering Feature
You set up packet filtering by using packet filtering rule sets. Use the
ipf command to work with packet filtering rule sets. For more information on
the ipf command, see the ipf(1M) command.
You can create packet filtering rules either at the command line, using the
ipf command, or in a packet filtering configuration file. If you want the
packet filtering rules to be loaded at boot time, create a configuration file
called /etc/ipf/ipf.conf in which to put packet filtering rules. If you do not
want the packet filtering rules loaded at boot time, put the ipf.conf file
in a location of your choice, and manually activate packet filtering by using
the ipf command.
You can maintain two sets of packet filtering rule sets with Solaris IP
Filter, the active rule set and the inactive rule set. In most
cases, you work with the active rule set. However, the ipf -I command enables you
to apply the command action to the inactive rule list. The inactive rule
list is not used by Solaris IP Filter unless you select it.
The inactive rule list provides you with a place to store rules without
affecting active packet filtering.
Solaris IP Filter processes the rules in the rules list from the
beginning of the configured rules list to the end of the rules list
before passing or blocking a packet. Solaris IP Filter maintains a flag that
determines whether it will or will not pass a packet. It goes through
the entire rule set and determines whether to pass or block the packet
based on the last matching rule.
There are two exceptions to this process. The first exception is if the
packet matches a rule containing the quick keyword. If a rule includes the
quick keyword, the action for that rule is taken, and no subsequent rules
are checked. The second exception is if the packet matches a rule containing
the group keyword. If a packet matches a group, only rules tagged with
the group are checked.
Configuring Packet Filtering Rules
Use the following syntax to create packet filtering rules:
action [in|out] option keyword, keyword...
Each rule begins with an action. Solaris IP Filter applies the action to the packet if the packet matches the rule. The following list includes the commonly used actions applied to a packet.
- block
Prevents the packet from passing through the filter.
- pass
Allows the packet through the filter.
- log
Logs the packet but does not determine if the packet is blocked or passed. Use the ipmon command to view the log.
- count
Includes the packet in the filter statistics. Use the ipfstat command to view the statistics.
- skip number
Makes the filter skip over number filtering rules.
- auth
Requests that packet authentication be performed by a user program that validates packet information. The program determines whether the packet is passed or blocked.
- preauth
Requests that the filter look at a pre-authenticated list to determine what to do with the packet.
Following the action, the next word must be either in or out. Your choice determines whether the packet filtering rule is applied to an incoming packet or to an outgoing packet.
Next, you can choose from a list of options. If you use more than one option, they must be in the order shown here.
- log
Logs the packet if the rule is the last matching rule. Use the ipmon command to view the log.
- quick
Executes the rule containing the quick option if there is a packet match. All further rule checking stops.
- on interface-name
Applies the rule only if the packet is moving in or out of the specified interface.
- dup-to interface-name
Copies the packet and sends the duplicate out on interface-name to an optionally specified IP address.
- to interface-name
Moves the packet to an outbound queue on interface-name.
After specifying the options, you can choose from a variety of keywords that determine whether the packet matches the rule. The following keywords must be used in the order shown here.
Note - By default, any packet that does not match any rule in the configuration file is passed through the filter.
- tos
Filters the packet based on the type-of-service value expressed as either a hexadecimal or a decimal integer.
- ttl
Matches the packet based on its time-to-live value. The time-to-live value stored in a packet indicates the length of time a packet can be on the network before being discarded.
- proto
Matches a specific protocol. You can use any of the protocol names specified in the /etc/protocols file, or use a decimal number to represent the protocol. The keyword tcp/udp can be used to match either a TCP or a UDP packet.
- from/to/all/any
Matches any or all of the following: the source IP address, the destination IP address, and the port number. The all keyword is used to accept packets from all sources and to all destinations.
- with
Matches specified attributes associated with the packet. Insert either the word not or the word no in front of the keyword in order to match the packet only if the option is not present.
- flags
Used for TCP to filter based on TCP flags that are set. For more information on the TCP flags, see the ipf(4) man page.
- icmp-type
Filters according to ICMP type. This keyword is used only when the proto option is set to icmp and is not used if the flags option is used.
- keep keep-options
Determines the information that is kept for a packet. The keep-options available include the state option and the frags option. The state option keeps information about the session and can be kept on TCP, UDP, and ICMP packets. The frags option keeps information on packet fragments and applies the information to later fragments. The keep-options allow matching packets to pass without going through the access control list.
- head number
Creates a new group for filtering rules, which is denoted by the number number.
- group number
Adds the rule to group number number instead of the default group. All filtering rules are placed in group 0 if no other group is specified.
The following example illustrates how to put together the packet filtering rule syntax
to create a rule. To block incoming traffic from the IP address
192.168.0.0/16, you would include the following rule in the rule list:
block in quick from 192.168.0.0/16 to any
For the complete grammar and syntax used to write packet filtering rules, see
the ipf(4) man page. For tasks associated with packet filtering, see Managing Packet Filtering Rule Sets for Solaris IP Filter. For
an explanation of the IP address scheme (192.168.0.0/16) shown in the example, see Chapter 2, Planning an IPv4 Addressing Scheme (Tasks.
Using Solaris IP Filter's NAT Feature
NAT sets up mapping rules that translate source and destination IP addresses into
other Internet or intranet addresses. These rules modify the source and destination addresses
of incoming or outgoing IP packets and send the packets on. You can
also use NAT to redirect traffic from one port to another port. NAT
maintains the integrity of the packet during any modification or redirection done on
the packet.
Use the ipnat command to work with NAT rule lists. For more information
on the ipnat command, see the ipnat(1M) command.
You can create NAT rules either at the command line, using the
ipnat command, or in a NAT configuration file. NAT configuration rules reside in
the ipnat.conf file. If you want the NAT rules to be loaded at
boot time, create a file called /etc/ipf/ipnat.conf in which to put NAT rules.
If you do not want the NAT rules loaded at boot time, put
the ipnat.conf file in a location of your choice, and manually activate packet
filtering with the ipnat command.
Configuring NAT Rules
Use the following syntax to create NAT rules:
command interface-name parameters
Each rule begins with one of the following commands:
- map
Maps one IP address or network to another IP address or network in an unregulated round-robin process.
- rdr
Redirects packets from one IP address and port pair to another IP address and port pair.
- bimap
Establishes a bidirectional NAT between an external IP address and an internal IP address.
- map-block
Establishes static IP address-based translation. This command is based on an algorithm that forces addresses to be translated into a destination range.
Following the command, the next word is the interface name, such as hme0.
Next, you can choose from a variety of parameters, which determine the NAT configuration. Some of the parameters include:
- ipmask
Designates the network mask.
- dstipmask
Designates the address that ipmask is translated to.
- mapport
Designates tcp, udp, or tcp/udp protocols, along with a range of port numbers.
The following example illustrates how to put together the NAT rule syntax together
to create a NAT rule. To rewrite a packet that goes out
on the de0 device with a source address of 192.168.1.0/24 and to externally
show its source address as 10.1.0.0/16, you would include the following rule in
the NAT rule set:
map de0 192.168.1.0/24 -> 10.1.0.0/16
For the complete grammar and syntax used to write NAT rules, see
the ipnat(4) man page.
Using Solaris IP Filter's Address Pools Feature
Address pools establish a single reference that is used to name a
group of address/netmask pairs. Address pools provide processes to reduce the time needed to
match IP addresses with rules. Address pools also make managing large groups
of addresses easier.
Address pool configuration rules reside in the ippool.conf file. If you want the
address pool rules to be loaded at boot time, create a file called
/etc/ipf/ippool.conf in which to put address pool rules. If you do not want
the address pool rules loaded at boot time, put the ippool.conf file in
a location of your choice, and manually activate packet filtering with the ippool
command.
Configuring Address Pools
Use the following syntax to create an address pool:
table role = role-name type = storage-format number = reference-number
- table
Defines the reference for the multiple addresses.
- role
Specifies the role of the pool in Solaris IP Filter. At this time, the only role you can reference is ipf.
- type
Specifies the storage format for the pool.
- number
Specifies the reference number that is used by the filtering rule.
For example, to reference the group of addresses 10.1.1.1 and 10.1.1.2, and the network
192.16.1.0 as pool number 13, you would include the following rule in the address
pool configuration file:
table role = ipf type = tree number = 13
{ 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24 };Then, to reference pool number 13 in a filtering rule, you would construct
the rule similar to the following example:
pass in from pool/13 to any
Note that you must load the pool file before loading the rules
file that contains a reference to the pool. If you do not, the
pool is undefined, as shown in the following output:
# ipfstat -io
empty list for ipfilter(out)
block in from pool/13(!) to any
Even if you add the pool later, the addition of the pool
does not update the kernel rule set. You also need to reload the
rules file that references the pool.
For the complete grammar and syntax used to write packet filtering rules, see
the ippool(4) man page.
