Bugtraq mailing list archives
AltaVista Firewall for UNIX
From: sarah () ilo dec com (Sarah Keating)
Date: Tue, 3 Dec 1996 11:54:52 +0000
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 ---------------------------------------------------------------
Current thread:
- Vulnrability in test-cgi... Apropos of Nothing (Nov 30)
- denial of service attack on login NuNO (Dec 01)
- Re: Vulnrability in test-cgi... Roger Espel Llima (Dec 01)
- Little feature/bug in RedHat Linux Antti Andreimann (Dec 01)
- Users can modify routing in AIX 4.1 Dave Roberts (Dec 02)
- Re: Users can modify routing in AIX 4.1 Troy Bollinger (Dec 02)
- <Possible follow-ups>
- Re: Vulnrability in test-cgi... Jesus Altuve (Dec 02)
- Re: Vulnrability in test-cgi... Joe Zbiciak (Dec 02)
- /bin/ksh sparc code Kichang Yang (Dec 03)
- AltaVista Firewall for UNIX Sarah Keating (Dec 03)