Date: Thu, 22 Jun 2000 23:32:55 -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: <200006230633.e5N6Xci97623@cwsys.cwsent.com> In-Reply-To: Your message of "Thu, 22 Jun 2000 21:39:46 PDT." <20000622213946.F489@dialin-client.earthlink.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20000622213946.F489@dialin-client.earthlink.net>, "Crist J. Clark" writes: > On Thu, Jun 22, 2000 at 06:50:46AM -0700, Cy Schubert - ITSD Open Systems Gro > up wrote: > > In message <20000621145255.I214@dialin-client.earthlink.net>, "Crist J. Cl > ark" writes: > > > > > > Having a rule like, > > > > > > ipfw add 2350 pass tcp from any 20 to x.x.x.x port_high1-port_high2 > > > > > > Is not really too much of a risk (I don't remember what the range of > > > valid ports is). Make sure you don't have anything you are not > > > comfortable with listening in that range. The rule to allow the > > > initial ftp connection is much, much more risky than the above. > > > > I vehemently disagree. It is a high risk because an attacker can > > connect to services running on ports >= 1024, e.g. Oracle. Even if > > you're not running any services >= 1024, it is trivial to scan your > > network to get a picture of what it looks like to plan a strategy of > > attack. IMO too much risk. > > How can can an attacker scan the network when the high ports are only > open for this one host? An attacker won't be able to scan the low ports but will be able to determine which IP addresses (hosts) are on the inside. If an attacker scans ports >= 1024 he'll easily discover services running on those ports. Think about it: ipfw add allow tcp from any 20 to any 1024-65535 in allows port 20 to initiate connects to any non-privileged port on your network like X and some Kerberos services. > > > > Actually, this would be a good place for keep-state to work. I'm kinda > > > surprised that no one has added a keep-state method for FTP. It'd just > > > be, > > > > > > ipfw add 2350 pass tcp from any to x.x.x.x 21 setup keep-state ftp > > > > > > Right? Creating a dynamic rule that passes traffic from 20 to > > > x.x.x.x. From how I understand keep-state to work (and it is minimal, > > > sorry), it should not be too difficult to do? > > > > Agreed, under IPFW this cannot be done. > > 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. > > > Ideally this functionality should be in natd. > > natd(8) does have some functionality for dealing with ftp. I remember > looking over the code a month or two ago... heck if I can remember > what it does now. Just looked at the code myself. Natd supports (client side) passive FTP -- no special code required to do that. To support PORT FTP you need a firewall with an FTP application proxy like IP Filter. IPFW isn't nearly as functional as IP Filter, except for some neat features like divert sockets, custom placement of where the state table can be checked in your ruleset, and its hooks into dummynet. 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?200006230633.e5N6Xci97623>