Preparing to Configure the Oracle Solaris Firewall

Language:

This section describes the IPF to PF conversion tool, how to configure the svc:/network/firewall/pflog service for logging PF packets, and how to configure the ftp-proxy service, which enables the FTP protocol to work when NAT is performed by the firewall. You should configure the pf.conf network policy file, the logging options, and FTP handling before enabling the firewall service.

IP Filter to Packet Filter Rules Conversion Tool

To assist you in converting IPF rules to PF, the Oracle Solaris 11.4 release provides the ipf2pf service, which only runs at the first boot to a fresh BE. The service stores the obsolete IPF configuration files in the /var/firewall/legacy.ipf/conf directory. The service then converts the IPF configuration to PF. The migration process intentionally requires manual intervention to force you, the administrator, to configure and verify your network policy.

The conversion is written to the /var/firewall/legacy.ipf/conf/pf.conf file. Although the converted configuration will work, you should treat it as a suggestion. As the conversion examples illustrate, the result can be suboptimal. However, optimization can introduce errors, so consider the following when converting your IPF rules to PF:

Do not rely solely on the ipf2pf tool to create your firewall policy
Use your brain and the network policy specification
Check everything twice before altering firewall rules
Back up every step so that you can retrieve a working configuration

When you are satisfied that the PF rule set created by the ipf2pf service plus your modifications is accurate, move the resulting pf.conf file to /etc/firewall/pf.conf.

The PF rules suggested by the ipf2pf:default service instance are annotated by comments to explain the differences from IPF. The core part of the service is the /usr/bin/ipf2pf command, which performs the conversion.

The following simple examples illustrate the tool. For more complex examples, see Examples of Converting IPF Rules to PF Rules.

Example 5 Converting All IPF Configuration Files to PF

Unlike PF, IPF uses several configuration files. The ipf2pf can generate one annotated PF configuration file that combines all the IPF files:

$ pfbash ipf2pf -4 /etc/ipf/ipf.conf  -6 /etc/ipf/ipf6.conf \
      -n /etc/ipf/ipnat.conf -p /etc/ipf/ippool.conf \
      -o /var/firewall/legacy.ipf/conf/mypf.conf

Tip - If you plan to use separate configuration files similar to IPF files, add an INCLUDE statement to the PF configuration file for the main (root) rule set.

$ pfedit /etc/firewall/pf.conf
...
include "/etc/firewall/pfzones.conf"

Example 6 Simple IPF to PF Conversion of IPv4 Rules

You can try the tool on your own rule samples. Consider the following IPv4 rules:

    ## IP Filter Sample ipf.conf File
    # Stateful firewall allows everything outbound
    # and blocks everything inbound except ssh
    #
    pass out all keep state
    block in all
    pass in from any to any port = 22 keep state

When you run the ipf2pfcommand on the /etc/ipf/ipf.conf file, the command produces the following output:

$ ipf2pf -4 ipf.conf

    #
    # File was generated by ipf2pf(7) service during system upgrade. The service
    # attempted to convert your IPF rules to PF (the new firewall) rules. You
    # should check if firewall configuration here, suggested by ipf2pf, still meets
    # your network policy requirements.
    #

    #
    # Unlike IPF, PF intercepts packets on loopback by default.
    # IPF does not intercept packets bound to loopback. To turn off the
    # policy check for loopback packets, we suggest to use command
    # below:
    set skip on lo0
    #
    # PF does IP reassembly by default. It looks like your IPF
    # does not have IP reassembly enabled. Therefore the feature is
    # turned off.
    #
    set reassemble no
    # In case you change your mind and decide to enable IP reassembly
    # delete the line above. Also to improve interoperability
    # with broken IP stacks, tell PF to ignore the 'DF' flag when
    # doing reassembly. Uncommenting line below will do it:
    #

    # set reassemble yes no-df

    block drop in inet all
    #
    # IPF rule specifies either a port match or return-rst action,
    # but does not specify a protocol (TCP or UDP). PF requires a port
    # rule to include a protocol match using the 'proto' keyword.
    # ipf2pf always assumes and enters a TCP port number
    #

    pass in inet proto tcp from any to any port = 22 flags any keep state (sloppy)
    pass out inet all flags any keep state (sloppy)

For more information, see the ipf2pf(7) and firewall(7) man pages.

Using Packet Filter Logging

Logging packets is an additional SMF service in PF. To log packets, you need to enable the logging service and add log actions in your PF rules. The default logging service instance is pflog:default.

The following describes the overall process:

A pflog service instance creates a capture datalink. The datalink is stored as the value of the service property interface.
A packet enters PF and matches a rule with a log action.
PF sends the matched packet to the capture datalink specified by the log action. If no capture datalink is specified, PF uses the default (pflog0) capture datalink.
The pflog service instance that reads the capture datalink might attach a BPF filter to the capture link, similar to what tcpdump might do. The filter selects a subset of the packet to log. If no filter expression exists, which is the default, all packets are sent to the pflog daemon and then copied into the log.
The administrator archives the log files, refreshes the pflog service to restart the logging, and moves the log files to another system for inspection.

The log file written by the pflog daemon is in libpcap format. Oracle Solaris provides several tools that can read this format, including tshark, tcpdump, and Wireshark. For more information, see the tcpdump(8), tshark(1), and pcap (3PCAP) man pages.

Tip - For ease of configuration and debugging, name your capture datalink and log file identically by ending pflog service instance names with a number, such as pflog1 or pflog21.

Initially, packet logging uses the pflog:default service instance, which sends packets to the pflog0.pkt log file. You might want to create new service instances for packets that arrive on a particular port, or for packets that need a longer snaplen, or for debugging or other purposes. For the properties that you can specify for a pflog service instance, see the pflogd (8) man page.

To see the initial values of the default pflog service properties, run the following command on a newly-installed system:

$ svcprop -g application pflog
pflog/delay integer 60
pflog/filter astring ""
pflog/interface astring pflog0
pflog/logfile astring /var/log/firewall/pflog/pflog0.pkt
pflog/snaplen integer 160

The following examples illustrate typical log file administration tasks. For more examples, see the pflogd(8) man page.

Example 7 Creating a New pflog Service Instance

The following command creates a new instance called pflssh1 for logging packets whose source or destination is port 22.

$ pfbash pflogd -C pflssh1 port 22

The following command shows the configuration of the instance, including its log file and filter.

$ pflogd -c pflssh1
PF pflogd configuration:
        - logfile:
                /var/log/firewall/pflog/pflssh1.pkt
        - snaplen:
                160
        - interface:
                pflssh1
        - delay:
                60
        - filter:
                port 22

When a packet matches a PF rule that includes the log (to pflssh1) action and port 22, the pflogd daemon adds a log entry to the pflssh1.pkt file from the capture datalink.

For example, packets that match the following rule become entries in the pflssh1.pkt file:

pass in log (to pflssh1) proto tcp to any port 22

Note that packets from a remote host to another remote host's port 22 will be logged.

Similarly, as an example of selective filtering, packets from or to port 22 will be logged by this rule:

pass in log (to pflssh1) proto tcp from any to any

Example 8 Specifying a Log File for a pflog Service Instance

In this example, the logs of the new service instance are placed in the debug/debug0.pkt directory below the /var/log/firewall/pflog/ directory.

$ pfbash pflogd -C debug0 -f /var/log/firewall/pflog/debug/debug0.pkt

Example 9 Rotating PF Log Files

The following command archives the current log. After the administrator refreshes the service, the pflog0.pkt log file is empty and ready for new entries.

$ pfbash mv /var/log/firewall/pflog/pflog0.pkt /var/log/firewall/pflog/archive1pflog0.pkt
$ svcadm refresh pflog:default

The administrator copies the archived files to another system for inspection.

# scp /var/log/firewall/pflog/archive*.pkt username@192.0.2.44:/logs/pflogs/

Caution - Do not store packets from different pflog instances in the same log file. And, do not have more than one instance use the same capture datalink simultaneously.

Using the `ftp-proxy` Service

Without additional support, FTP transfers that pass through PF doing NAT would be broken. The ftp-proxy service provides this support. PF redirects the FTP packets to an address where the ftp-proxy service listens, which is 127.0.0.1 by default. You specify the address and port where the proxy listens for PF's redirected FTP connection attempts. The proxy negotiates the connection on behalf of the client.

The FTP proxy is transparent to the client by altering the firewall configuration at runtime according to the FTP rules that you provide. These rules, that contain the address and port where the proxy listens, follow an anchor, such as "ftp/*", in the pf.conf file.

Before enabling the service, you also ensure that the ftp-proxy service rules can be processed by PF. For the steps, see How to Make FTP Transfers Pass Through PF Doing NAT on Oracle Solaris.

Securing the Network in Oracle® Solaris 11.4