



                            SafeFire Firewall

                               Version 1.2

              Copyright (C) 1999-2004 Link Guard Solutions Ltd.

                      PACKET FILTER GUIDE AND REFERENCE



Contents

    1. Introduction
    2. General concepts
    3. Packet filter configuration
    4. Rule definition syntax



1. Introduction

    This document describes Packet Filter feature of SafeFire Firewall.

    Short introduction into TCP/IP presented below should be considered
    as a starting point and further reading of more complete sources
    is highly recommended.

    Background of Transmission Control Protocol / Internet Protocol is
    very simple: all information transferred through the network is
    presented in form of packets. Every packet has a header i.e. special
    part of packet which is like envelope contains information about
    source and destination points as well as other useful information.
    Each packet belongs to one of the predefined protocol types. Protocol
    can be considered as a set of rules and conditions required to transfer
    particular type of information. Between numerous defined protocols most
    often used are:

        TCP
        UDP
        ICMP

    Packet of each of these protocol types may contain additional fields
    in header, specific for each protocol.

    TCP protocol is used for reliable transfers of streams of information
    with control of integrity and establishing a connection between
    communication points. Most Internet services uses this protocol: HTTP,
    FTP, SMTP, NNTP, etc.

    UDP protocol is used for transfers of individual packets of information
    without guaranteed delivering of packet and without establishing a
    connection between communication points. UDP is used for Domain Name
    Service (DNS) Internet service.

    ICMP protocol is used for special purposes such as check of link
    integrity (PING utility), getting information about a way in which
    packet will be delivered (TRACEROUTE utility), informing some host
    that particular packet can't be delivered because destination is not
    reachable and others.

    As was said packet of each type contains IP header and (probably)
    additional protocol header.

    IP header contains among others following fields which is interesting
    for purposes of protection of internal network with SafeFire's Packet
    Filter:

        IP address of source (sender) of the packet
        IP address of destination (receiver) of the packet
        "Packet is fragmented" flag

    TCP header contain (among others) following fields:

        Source port
        Destination port
        TCP flags

    UDP header contain (among others) following fields:

        Source port
        Destination port


    A few words about source and destination "ports". Implementation
    of TCP/IP should have a way to determine a connection to which
    belongs each received packet.
    Another purpose of the port numbers is to allow applications to
    establish connection to so called "well known" services. In other
    words, HTTP, FTP, SMTP, NNTP, etc. servers wait for incoming
    connections on predefined ports. For example for most HTTP servers
    port 80 is used.


2. General Concepts

    The packet filter is one of the main facilities for protection of an
    internal network from illegal access.

    The main idea of the packet filter is quite simple. Each packet, which
    is going through packet filter has some specific information located in
    the packet header. packet filter compares this information with so
    called 'rules' contained in special database. Each rule specifies set
    of matching parameters and declares an action (permit or deny).
    When an exact match is found the declared action is performed.

    Set of matching parameters can include:

        Source address and source mask
        Destination address and destination mask
        Protocol type : IP, TCP, UDP, ICMP. IP means ALL packets.
        Direction (incoming, outgoing or both)
        Port number (only TCP and UDP packets)
        Special options (flags) for TCP packets

    One can also use external plugins to filter packets. If this case the
    SafeFire Firewall would not analyze these parameters and just call
    appropriate plugin function to determine whether to pass or drop the
    packet. To find more details about external plugins, see External Plugins
    Guide And Reference book.


3. Packet filter configuration and packet rules

    Packet Filter is configured independently through appropriate section
    [filter] in configuration file. Following statement in this section
    enables packet filter:

    enable=yes

    Remaining configuration consist of set of appropriate rules:

    rule=<definition 1>
    rule=<definition 2>
    ...
    rule=<definition N>

    Each rule is written in separate line and should follow predefined syntax
    (see section Rule definition syntax).
    Each rule has statistics associated with it. These statistics includes:
        1. Number of packets matched rule
        2. Total size in K bytes of matching packets

    Every time packet matches the rule, rule statistics updated.

    By default, with no rules defined filter drops ALL packets. To allow some
    packets to pass firewall it is necessary to add some rules with 'allow',
    'accept' or 'permit' policy.

    Each rule has one of the following types:

    I) Pass
        allow   -+
        accept  -+
        permit  -+- allow packet which matches rule

        Such a rules enable particular service or protocol:

            allow icmp from any to any          - allow ICMP to pass firewall
            allow udp from any to myip 80 bidi  - allow SMTP connections

    II) Drop
        deny    -+
        drop    -+- drop packet which matches rule

        This type of rules will disable particular services that match rule.
        For example, following set of rules will enable UDP to go freely
        through firewall except one particular host:

            deny udp from 192.168.1.1 to any
            allow udp from any to any

    III) Drop and inform sender
        reject  --- drop packet and notify sender of packet that
                    destination is unreachable

        This type of the rules is almost the same as previous except that for
        each matching packet sender will receive notification that packet
        cannot pass gateway. For example:

            reject ip from any to 192.168.1.1
            allow ip from any to any

    IV) Special rules
        count      - do nothing with packet and search other matching rule
        pipe <n>   - allow the packet and send it via <n> shaper pipe
        plugin <n> - pass the packet to external plugin
        skipto <n> - go to rule number <n>

        This group contains rules with special meaning.

        The 'count' rules are convenient for collecting various statistics,
        because they do not allow packet to pass firewall but let firewall to
        look for other rule (there can be no rule that will allow packet to
        pass firewall). As mentioned above, each time when packet matches the
        'count' rule, rule statistics is updated and this information then
        can be used for other purposes, for example accounting or attack
        detection

        The 'pipe' rule will forward packet to shaper pipe. More information
        about traffic shaper can be found in Traffic Shaper Guide and
        Reference.

        The 'plugin' rule will forward packet to appropriate plugin and final
        decision about the packet will depend on the plugin.

        The 'skipto' rule allow to bypass some rules and start search for the
        matching rule starting from the specified rule number.


    TCP (and some UDP) services are bidirectional by design. This mean
    that packets should pass firewall in two directions: from host
    to client and from client to host. To make such a services work
    properly it is necessary to write packet filer rules with bidirectional
    packet exchange in mind. There are two ways to handle this case: write two
    rules for each service and handle separately incoming and outgoing
    packets or use special bidirectional rules. For example, following two
    rules will allow a connection to external SMTP servers (an internal net
    is assumed 192.168.xx.xx in this sample):

        allow tcp from 192.168.0.0:255.255.0.0 to any smtp out
        allow tcp from any smtp to 192.168.0.0:255.255.0.0 in

    NOTE: Port range for an internal net is not specified, because
          outgoing connection can have any port number and it is
          maintained by the OS/2 TCP/IP stack.

        (Following pairs of rules are another notation for the above rules:
            allow tcp from 192.168.0.0/16 to any smtp out
            allow tcp from any smtp to 192.168.0.0/16 in

            allow tcp from 192.168.0.0/16 to any 25 out
            allow tcp from any 25 to 192.168.0.0/16 in

        Note different ways to describe internal net and service port.)

    With bidirectional rule it is possible to replace above pair of rules
    with following one:

        allow tcp from any smtp to 192.168.0.0/16 bidi

    Note that 'from' and 'to' parts of rule are equivalent to
    appropriate parts of rule for incoming packets.

    It is recommended to use for such a cases bidirectional rules because
    this simplifies maintenance and reduces risk of error.

    Each rule has a number which is an identifier for add/remove
    operations. The order in which packet will be checked against rules
    also defined by this number. The rule with smaller number will be
    checked first. You can assign numbers manually or let a system
    assign numbers automatically.

    If you do not assign numbers manually, all rules will be added in order
    which they are defined in configuration file or otherwise added.

    As a part of support for configurations with dynamically assigned
    external IP address packet filter allows to use special keyword in rules
    which denotes current IP address of the interface. For example:

        allow tcp from any smtp,pop3,http,https to myip bidi

    Here 'myip' means current address of the interface.
    It is recommended to use 'myip' instead of the address even if dynamic
    assignment of the address is not used because such a notation reduces
    maintenance and minimizes risk of error.


4. Rule definition syntax

    Each rule has the following syntax:

        [<number>] action [log] [protocol] [source] [destination] [extra[,...]]

    where

        [<number>]
            optional rule number


        action

            allow   -+
            accept  -+
            permit  -+- allow packet matching rule

            deny    -+
            drop    -+- drop packet matching rule

            reject  --- drop packet and notify sender of packet that
                        destination is unreachable

            count   --- do nothing with packet and search other matching rule

            pipe <n> -- allow packet and send it via shaper pipe number <n>

            plugin <n> - pass the packet to external plugin number <n>.
                         when this action is specified there must be no other
                         parameters after plugin number <n>

            skipto <n> - go to rule number <n>


        [log]
            optional flag that tells packet filter to print some
            information about matching packet to the SYSLOG facility.


        protocol

            ip     -+
            all    -+- match all types of protocols

            tcp    --- match TCP packets only

            udp    --- match UDP packets only

            icmp   --- match ICMP packets only



        source        information about origin of the packet
        destination   information about destination of the packet

            source and destination clauses uses similar syntax:

                keyword [not] addrdef portdef

            where

                keyword

                    from --- source clause
                    to   --- destination clause


                [not]
                        optional flag that reverses meaning of source mask,
                        i.e. rule will be applied if packet has origin NOT
                        falling to address/mask specified in this rule

                addrdef
                    defines address or range of addresses of the packet

                    addrdef has the following syntax:

                        {any|ip[{/bits|:mask}]}

                    where

                        any     --- packet can have any origin

                        ip/bits -+
                        ip:mask -+- these are two forms of description
                                    of source IP address and mask

                        ip      --- is IP address written in usual dot
                                    delimited form or text 'myip' which
                                    denotes IP address of the interface on
                                    which firewall resides.

                        bits    --- specifies number of high bits in address
                                    which will be used for comparison

                        mask    --- specifies a mask with which should be done
                                    logical AND operation before comparison

                portdef
                    defines a port or a set of ports which will be
                    used for comparison

                    portdef has the following syntax:

                        [{port|port-port},[port],...]

                    where

                        port[,port] --- specify up to 10 separate ports.

                        port-port   --- specifies inclusive range of ports.

                        port        --- can be either a port number or a
                                        service name as described in the
                                        SERVICES file from the directory
                                        pointed by a ETC environment variable.

                extra

                    extra is one of following:

                        fragment --- if this flag is specified then rule
                                     will be applied only to fragments of
                                     the packets

                                     NOTE: may not be used with ports
                                           or tcpflags (see below)

                        in       --- match only incoming packets

                        out      --- match only outgoing packets

                        bidi     --- match incoming and outgoing packets

                        established --- match packets that belongs to
                                        established TCP connection

                        setup    --- match packets belongs to TCP packets
                                     used as connection setup stage

                        tcpflags [!]{syn|fin|rst|ack|psh|urg},...
                                 --- matching TCP packet should have
                                     specified bits set (reset if '!' is
                                     present)


EOF

