From owner-freebsd-security Thu Dec 21 3:11:28 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 21 03:11:24 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from pps.de (mail.pps.de [217.13.200.134]) by hub.freebsd.org (Postfix) with ESMTP id 5661437B400 for ; Thu, 21 Dec 2000 03:11:23 -0800 (PST) Received: from jung7.pps.de (jung7.pps.de [192.9.200.17]) by pps.de (8.9.3/8.9.3) with ESMTP id MAA04672; Thu, 21 Dec 2000 12:26:56 +0100 (CET) (envelope-from petros@pps.de) Received: from jung9.pps.de by jung7.pps.de (8.9.3+Sun/ZRZ-Sol2) id MAA00666; Thu, 21 Dec 2000 12:08:33 +0100 (MET) Received: from jung9 by jung9.pps.de (8.9.1b+Sun/ZRZ-Sol2) id MAA04895; Thu, 21 Dec 2000 12:08:33 +0100 (MET) Message-Id: <200012211108.MAA04895@jung9.pps.de> Date: Thu, 21 Dec 2000 12:08:33 +0100 (MET) From: Peter Ross Reply-To: Peter Ross Subject: Re: FTP and firewall To: fschapachnik@vianetworks.com.ar Cc: freebsd-security@FreeBSD.ORG MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: c3qqiSQL/5QdgtSxFS0pqA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Fernando Schapachnik wrote: > man ipf, and check: > > http://www.obfuscation.org/ipf/ipf-howto.txt > > ipfilter can do this in a much safer way than what I suggested there. I did: > The good news is that your FTP server gets to decide > which ports get assigned to passive sessions. This means > that instead of opening all ports above 1023, you can allo- > cate ports 15001-19999 as ftp ports and only open that range > of your firewall up. In wu-ftpd, this is done with the pas- > sive ports option in ftpaccess. Please see the man page on > ftpaccess for details in wu-ftpd configuration. On the > ipfilter side, all we need do is setup corresponding rules: > > pass in quick proto tcp from any to 20.20.20.20/32 port 15000 >< 20000 flags S keep state > pass out proto tcp all keep state > .. > While FTP server support is still less than perfect in IPF, In march you wrote: > What I have done is to configure FTPd to use ports between 40000 and > 44999 (wu-ftpd allows it to be done easily; don't know others) and then: > > allow tcp from any to my_ip 40000-44999 in setup > > It's not the best, but still better than nothing. In the same thread Paul Hart wrote (I quote it again): > On Wed, 29 Mar 2000, Alan Batie wrote: > > > To do active mode ftp properly, ipfw would need to parse the contents > > of the packets on the ftp control channel and dynamically allow the > > corresponding incoming connection. There's no indication that this > > parsing capability is present. > > I know we're talking about IPFW here, but hasn't IP Filter (also included > with FreeBSD) been supporting this very operation for quite a while now? Sorry, but http://www.obfuscation.org/ipf/ipf-howto.txt says nothing about "parsing capability". All what I find is: > If even this solution doesn't satisfy you, you can always > hack IPF support into your FTP server, or FTP server support > into IPF. I suggested: > ftp_passive_range="49152-65535" # FreeBSD ftpd listens here > > natd_flags="-redirect_port tcp ${intern_ftp_ip}:${ftp_passive_range} > ${ftp_passive_range}" > > ipfw add allow tcp from any to ${extern_ip} ${ftp_passive_range} setup via > ${extern_if} > ipfw add allow tcp from any to ${intern_ftp_ip} {ftp_passive_range} setup via > ${extern_if} > ipfw add allow tcp from any to ${intern_ftp_ip} {ftp_passive_range} setup via > ${intern_if} In principle the same, I think. But I found this discussion: On Fri, 31 Mar 2000, Vladimir Mencl wrote: > On Wed, 29 Mar 2000, Allan Saddi wrote: > > > On Wed, 29 Mar 2000, Alan Batie wrote: > > > > > ...To do active mode ftp properly, ipfw would need to parse the > > > contents of the packets on the ftp control channel and dynamically allow > > > the corresponding incoming connection. There's no indication that this > > > parsing capability is present. > > > > Interestingly enough, sometime back, Eivind Eklund added a feature to > > allow libalias(3) to "punch holes" in an ipfw-based firewall. The code is > > apparently still there. Unfortunately, it seems like neither natd nor ppp > > take advantage of this feature. (Currently, there's no way to turn it on.) > > > > It would be a seemingly trivial modification... but maybe there's some > > reason why it was never incorporated into natd/ppp? > > > The modification could be possibly "trivial", but would involve quite a > lot of implementation. > > There're many protocols, which would have to be parsed at the > application layer - ftp, talk/ntalk to name a few. > > Others might include the real audio protocols - but I do not know these > well enough. > > > A long time ago, I wrote a userland program that could "punch holes" for > incoming data connections created by outgoing talk requests. > > But to have a firewall allowing correct operation of all outgoing > "requests", you would have to explore all the protocols you wish to > support, implement a filter which would scan either UDP packets or the > TCP stream, and interact with the firewall setup. > > And also - you would have to develope some rules for selecting the > proper filter. It is clear, that a connection to port 21 is a ftp > control connection - but services might be running on arbitrary ports, > and you might wish to support access to them too. > > And furthermore, you should take some security considerations about the > effects of establishing such a firewall. By submitting a link to an ftp > site (possibly in a forged html page), an attacker might open a hole in > the firewall for himself. Yes, with a very limited range of > possibilites, but this might be considered as a security risk by some > admins. > > But still it might be better than allowing any TCP connection coming > from port 20. > > > Vladimir Mencl Rough idea: a divert of ftp control packets to a parser, which can add and delete dynamical ftp data connection rules. I'm amazed that I can't find a better solution then open the high ports but I see the problem. Thanks for the given answers - Peter Ross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message