[lug] Ftp port specifications.

[John Starkey]

Thanks John. I'll check this out. I'm wondering though, why I've never had
this problem ftp'ing to other servers. Maybe I didn't pay attention and
just thought it was a slow authentication.

I didn't have a problem with Fetch and didn't think to check it out with
ws_ftp until a client pointed it out.

I just checked and IE for Windoze doesn't seem to hang. I guess Fetch and
IE default to non-passive?

 

On Thu, 19 Oct 2000, John Hernandez wrote:

> AFAIK, unless you use a hacked client, there's no way to force ftp
> clients to a negotiate a specific ftp-data port.  It will always grab an
> unused random high-numbered port.  This can cause a problem with strict
> packet filter configs.  If you're using ipchains with masquerading, the
> answer is to use the ip_masq_ftp.o kernel module.  If you use ipchains
> in a traditional filtering router mode (without NAT), the IPCHAINS-HOWTO
> at linuxdoc.org has some useful information.  I've pasted some of the
> pertinent info below.  I'm not sure how much of this may be dated.  I
> recall having success on 2.2.x kernels with Michael Hasenstein's
> ftp-data hack at http://www.suse.de/~mha/index-next.html and it seems
> he's kept it current for 2.2.17 kernels.
> 
> SPF: Stateful Packet Filtering
> 
> ftp://ftp.interlinx.bc.ca/pub/spf is the site of Brian Murrell's SPF
> project, which does connection tracking in userspace.
> It adds significant security for low-bandwidth sites. 
> 
> There's little documentation at present, but here's a post to the
> mailing list in which Brian answered some questions:
> 
> 
>      > I believe it does exactly what I want: Installing a temporary
>      > "backward"-rule to let packets in as a response to an
>      > outgoing request.
> 
>      Yup, that is exactly what it does.  The more protocols it
>      understands, the more "backward" rules it gets right.  Right
>      now it has support for (from memory, please excuse any errors
>      or omissions) FTP (both active and passive, in and out), some
>      RealAudio, traceroute, ICMP and basic ICQ (inbound from the ICQ
>      servers, and direct TCP connections, but alas the secondary
>      direct TCP connections for things like file transfer, etc. are
>      not there yet)
> 
>      > Is it a replacement for ipchains or a supplement?
> 
>      It is a supplement.  Think of ipchains as the engine to allow
>      and prevent packets from travelling across a Linux box.  SPF is
>      the driver, constantly monitoring traffic and telling ipchains
>      how to change it's policies to reflect the changes in traffic
>      patterns.
> 
> Michael Hasenstein's ftp-data hack
> 
> Michael Hasenstein of SuSE has written a kernel patch which adds ftp
> connection tracking to ipchains. It can currently
> be found at http://www.suse.de/~mha/patch.ftp-data-2.gz
> 
> 5.9 Future Enhancements 
> 
> Firewalling and NAT have being redesigned for 2.4. Plans and discussions
> are available on the netfilter list (see
> http://lists.samba.org). These enhancements should clear up many
> outstanding usability issues (really, firewalling
> and masquerading shouldn't be this hard), and allow growth for far more
> flexible firewalling. 
> 
> 
> John Starkey wrote:
> > 
> > Is there way, with the exception of asking all users to connect in
> > non-passive mode, to prevent ftp from being assigned to a blocked port??
> > 
> > Thanks,
> > 
> > John
> > 
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 
>