From owner-freebsd-ipfw Fri Jun 23 19:27:52 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from emu.prod.itd.earthlink.net (emu.prod.itd.earthlink.net [207.217.121.31]) by hub.freebsd.org (Postfix) with ESMTP id 4CA4E37BADF for ; Fri, 23 Jun 2000 19:27:48 -0700 (PDT) (envelope-from cjc@earthlink.net) Received: from dialin-client.earthlink.net (pool0278.cvx20-bradley.dialup.earthlink.net [209.179.251.23]) by emu.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id TAA07124; Fri, 23 Jun 2000 19:27:44 -0700 (PDT) Received: (from cjc@localhost) by dialin-client.earthlink.net (8.9.3/8.9.3) id TAA00512; Fri, 23 Jun 2000 19:26:17 -0700 (PDT) Date: Fri, 23 Jun 2000 19:25:46 -0700 From: "Crist J. Clark" To: Cy Schubert - ITSD Open Systems Group Cc: Jennifer Ulrich , freebsd-ipfw@FreeBSD.ORG Subject: Re: allowing passive ftp through ipfw Message-ID: <20000623192546.A481@dialin-client.earthlink.net> Reply-To: cjclark@alum.mit.edu References: <20000622213946.F489@dialin-client.earthlink.net> <200006230633.e5N6Xci97623@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006230633.e5N6Xci97623@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Thu, Jun 22, 2000 at 11:32:55PM -0700 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jun 22, 2000 at 11:32:55PM -0700, Cy Schubert - ITSD Open Systems Group wrote: > 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 Group wrote: > > > In message <20000621145255.I214@dialin-client.earthlink.net>, "Crist J. Clark" 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. I agree that _that_ is a dangerous rule, but we were discussing, ipfw add allow tcp from any 20 to x.x.x.x 1024-65535 To the one ftp server, 'x.x.x.x,' and NOT 'any.' You can only directly scan that one host. > > > > 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. 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. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message