Date: Tue, 12 Jun 2001 15:34:23 -0700 From: "Crist Clark" <crist.clark@globalstar.com> To: Evren Yurtesen <yurtesen@ispro.net.tr> Cc: "Antoine Beaupre (LMC)" <Antoine.Beaupre@ericsson.ca>, "Thomas T. Veldhouse" <veldy@veldy.net>, Jason DiCioccio <Jason.DiCioccio@Epylon.com>, freebsd-security@FreeBSD.ORG Subject: Re: IPFW almost works now. Message-ID: <3B2698EF.BD7EF0DB@globalstar.com> References: <Pine.BSF.4.33.0106130001350.63354-100000@finland.ispro.net.tr>
next in thread | previous in thread | raw e-mail | index | archive | help
Evren Yurtesen wrote:
>
> If you use passive FTP then it shouldnt be needed actually
> because the client connects to server all the time and the server is in
> passive mode.
> so the server doesnt need to connect to the client so voila =)
PASV is easy for firewalling if you are a client. PASV sucks for firewalling
if you are the server (which is the original poster's case). The reverse
is true for PORT (active FTP).
At the server, if you are doing PASV, you need to somehow allow the incoming
connections from the client in. They can come into just about any port.
So, you are left with two options,
(a) Open up a whole slew of ports on your server to incoming connections
from the outside world.
(b) Have some sort of proxy reconfigure the firewall when the PASV
command comes over.
Option (a) is easy to implement but defeats the purpose of a firewall.
Option (b) is not easy.
Someone said the problem with FTP is that it uses a separate data connection.
This in and of itself is not the problem. The problem with FTP is,
FTP passes information about how it is going to use lower layer protocols,
TCP/IP, in the application layer.
Thus, to actually do (b), you need some proxy application that watches the
application data for FTP and then reconfigures your TCP/IP stack accordingly.
A firewall, ususally purely a network and transport layer beast, needs some
help with this. Surprised no one has built a really lightweight divert(4)-based
daemon to do this for ipfw(8) (note that natd(8) has an ftp proxy built in
as does ipf(8))... maybe something useful to do with my commit bit. ;)
This problem is not unique to FTP, but FTP is _the_ application that
causes the most trouble because of this.
To the original poster, also keep in mind that firewalls at the other
end of your connection could be making trouble for you too. You can use
tcpdump(8) and firewall logging to see if traffic is getting to your
FTP server at all.
--
Crist J. Clark Network Security Engineer
crist.clark@globalstar.com Globalstar, L.P.
(408) 933-4387 FAX: (408) 933-4926
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above. If
the reader of this e-mail is not the intended recipient, or the employee
or agent responsible to deliver it to the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this
e-mail in error, please contact postmaster@globalstar.com
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?3B2698EF.BD7EF0DB>