AltaVista Firewall for UNIX

[sarah () ilo dec com (Sarah Keating)]

On Tue, 26 Nov 1996, Peter Dieth (pd () netlanders net) posted a note
in the BUGTRAQ mailing list relating to the Digital Firewall for UNIX
V2.0.
This note raised a few issues concerning the security of the AltaVista
Firewall for UNIX, formerly known as the Digital Firewall for UNIX.
It also gave the notion that Peter was able to "snoop thru" the
AltaVista Firewall for UNIX.
I'm afraid Peter's choice of words are likely to give the wrong
impression in that someone could interpret this as saying that Peter
had managed to "break through" the firewall. This is clearly not the
case - what Peter was simply doing was reviewing the configuration of
a firewall to get a better understanding of how it functions. Peter
clearly had direct root access to the firewall system to do this.

Please note that this is an activity we would encourage any firewall
administrator to do as we believe that it is an important element of
the security of such an installation that the operator understands how
it operates, what it can and what it cannot do.



1.. How does the AltaVista Firewall for UNIX control the flow of
IP          packets.
    Is there a connection with this and transparent proxying?

2.. What is the definition of the following iprsetup switches :
    a.. ipfirewall
    b.. ipcheckredirects
    c.. ipsrcroute

3.. Is there a weakness in the screend or networking code regarding
    IP Fragmentation. Does performance of the firewall disimprove
    when sending many IP Fragments to it?

4.. Are patches available for the AltaVista Firewall for UNIX to
    address both "SYN Flood" and "Ping" attacks?


The AltaVista Firewall engineering team's response to these questions :


1.. There are two ways of preventing packets going through a firewall

    a) Switch ipforwarding and ipgatewaying off,
    b) Use a packet screen such as screend (with ipforwarding switched
       on).

    The AltaVista Firewall for UNIX uses the 2nd option - that is
    ipforwarding is switched ON.
    This is the case whether transparent proxying is enabled or
    disabled, that is, there is no direct connection between IP
    forwarding and transparent proxying.


2.. The iprsetup utility shipped with the firewall product adds extra
    switches to control the following kernel parameters:

    ipfirewall:
    when set to 1 instructs the kernel that it is configured as a
    firewall.


    ipcheckredirects
    when set to 1 instructs the kernel to check and ignore
    icmp redirects that are attempts to spoof the firewall into
    redirecting traffic to a new gateway where that gateway would
    be reached via another interface on the firewall. It also instructs
    the kernel to check and ignore icmp redirects if the new gateway is
    not directly reachable.
    Requires ipfirewall=1.


    ipsrcroute:
    when set to 0 instructs the kernel to drop source-routed packets
    altogether if they are strictly denied. Requires ipfirewall=1.

    This table shows the values defined for each kernel parameter
    when the iprsetup command is executed with the undocumented
    switches
    (e.g. # iprsetup -f1)


                       -f1          -f2          -f3

   ipforwarding         1            1            1
   ipgateway            1            1            1
   ipfirewall           1            1            1
   ipchkredirects       1            0            1
   ipsrcroute           0            1            1

   For normal firewall operations the switch "-f1" is used.

   The above information will be documented in the iprsetup man page
   in the next release of the product.



3..No, there is no weakness in the screend or networking code
   regarding ip frags. As described above, all packets (fragmented
   or not) are passed to screend for a decision on whether they will
   be forwarded.

   The following text describes how screend handles IP fragmentation:

   IP Datagrams may contain up to 64K bytes of data. Virtually all
   networking technologies require packets to be smaller than this
   (for example, the Ethernet limits packets to about 1500 bytes),
   and in an internetwork it is likely  that different subnetworks
   will have different "Maximum Transmission Units"  (MTUs).
   This means that when a router forwards an IP packet, it may find
   that the packet is too big to transmit on the outgoing link.

   In an attempt to make the MTU issue transparent to the application,
   IP systems can "fragment" packets that are too large to send in one
   piece.
   Each fragment has a copy of the original IP header (more or
   less), but only  the first fragment of a TCP or UDP packet
   contains the higer level protocol header. Thus, screend cannot
   look at subsequent fragments in isolation to extract their TCP
   or UDP ports.

   To get around this problem, screend keeps track of a number of
   recently-received "first fragments" which do not contain the
   TCP and UDP headers. When a non-first fragment arrives,
screend          checks to see if it has already seen the first
fragment; if so,
   it forwards or rejects the  new fragment according to the
   information in the first fragment.

   This works only when fragments of a packet arrive in order at the
   system where screend is running; this is likely to happen, given
   current Internet  practices, but it is not guaranteed. Also, if
   the volume of fragmented packets is too high, screend may loose
   track of them.
   Finally, if packets can follow two or more paths that do not
   converge before (or at) a single screend-equipped
router,the             fragment-matching algorithm will not work. (That
means that in           principle you cannot put two screend-equipped
routers in parallel,       unless you don't need to support fragmented
datagrams.  However,         since most existing routers do not support
split-path routing, in        practice this has not been a problem).


   The firewall may seem to get slower when sending IP Fragments to it.
   This is clearly the case where some packets are being dropped and
   therefore the TCP/IP connection setup time increases. Hence
   the slowdown.


4.. Patch(es) are available for the AltaVista Firewall product that
    address both the "SYN Flood" and "Ping" attacks. You can obtain
    these patches from:

    http://www.service.digital.com/html/patch_service.html

    or via ftp from:

    ftp://www.service.digital.com/patches/public/ping/dfwu






---------------------------------------------------------------
Sarah Keating                                    +353 91 754644
sarah () ilo dec com                                 DTN: 822-4644
AltaVista Internet Software, Galway, Ireland
---------------------------------------------------------------