Date: Thu, 21 Dec 2000 12:08:33 +0100 (MET) From: Peter Ross <petros@pps.de> To: fschapachnik@vianetworks.com.ar Cc: freebsd-security@FreeBSD.ORG Subject: Re: FTP and firewall Message-ID: <200012211108.MAA04895@jung9.pps.de>
next in thread | raw e-mail | index | archive | help
Hi, Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar> 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 <hart@iserver.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012211108.MAA04895>