[3730] in bugtraq
AltaVista Firewall for UNIX
daemon@ATHENA.MIT.EDU (Sarah Keating)
Tue Dec 3 13:48:29 1996
Date: Tue, 3 Dec 1996 11:54:52 +0000
Reply-To: Sarah Keating <sarah@ilo.dec.com>
From: Sarah Keating <sarah@ilo.dec.com>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
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
---------------------------------------------------------------
