Date: Fri, 23 Jun 2000 20:41:45 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: cjclark@alum.mit.edu Cc: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, Jennifer Ulrich <pixie_styxx@hotmail.com>, freebsd-ipfw@FreeBSD.ORG Subject: Re: allowing passive ftp through ipfw Message-ID: <200006240342.e5O3gXr14008@cwsys.cwsent.com> In-Reply-To: Your message of "Fri, 23 Jun 2000 19:25:46 PDT." <20000623192546.A481@dialin-client.earthlink.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20000623192546.A481@dialin-client.earthlink.net>, "Crist J. Clark" writes: [getting too long, trimmed] > > > As ipfw(8) is currently implemented? Or is this something that cannot > > > (or should not) be done with ipfw? > > > > IPFW does not support an FTP application proxy, period. Take a look > > for yourself. > > I know it does not proxy and would not ever want ipfw to actually > modify packets. I just wonder about a dynamic rule that opens the high > ports of a machine to source port 20 when a keep-state is triggered > for a incoming setup to port 21 of that machine. I know it does not do > this now, > > keep-state [method] > Upon a match, the firewall will create a dynamic rule, > whose default behaviour is to matching bidirectional > traffic between source and destination IP/port using the > same protocol... > [snip] > The actual behaviour can be modified by specifying a dif > - > ferent method, although at the moment only the default > one is specified. > > Notice "at the moment." I am saying is there a reason one could not or > should not code in another 'method' to do PORT ftp. One could code another method to do PORT FTP. I think that this method should be put into natd, as NAT and application proxies, like an FTP proxy is especially useful when used with NAT. A PORT FTP proxy would only satisfy the requirements of performing PORT FTP for a client behind a firewall. A passive FTP proxy would also need to be built for an FTP server behind a firewall -- similar issues of an FTP server with passive FTP behind a firewall as an FTP client using PORT FTP behind a firewall. This is what IP Filter does in proxying FTP for FTP servers and clients, solving similar problems but in reverse. Also when writing an FTP proxy one must keep in mind the exploit of statefull firewalls FTP proxies by tricking an FTP server or client (depending on the context) into producing a message that would be interpreted by the proxy to open up arbitrary holes in the firewall which would be used to access arbitrary ports on the FTP server or client (once again depending on the context). See the BUGTRAQ archives from March or April for more details. I think the discussions were entitled FW-1 vulnerability and FTP ALG vulnerability. The vulnerabilities discussed affected many (all?) known statefull firewalls at the time. For an example what is needed to plug the FTP ALG vulnerability, e.g. to keep in mind when writing an FTP proxy, take a look at the diffs between IP Filter 3.3.11 and 3.3.12, and subsequently 3.4.x where stricter criteria are used to make sure that an FTP session is kosher before allowing FTP proxy. It's all pretty cool stuff, especially considering all the work that goes into building software like this. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006240342.e5O3gXr14008>