
Shutting down FTP services - danirod
https://kernel.org/shutting-down-ftp-services.html
======
droopybuns
This sentence struck out to me:

>>The protocol is inefficient and requires adding awkward kludges to firewalls
and load-balancing daemons

I have always been aware that ftp across firewalls can be wonky, but never
stopped to ask why.

[http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html](http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html)

>>The primary problems that the FTP poses to firewalls, NAT devices, and load-
balancing devices (all of which will simply be referred to as Ârouting
devicesÂ and not "routers" since gateway machines generally aren't
problematic) are:

>>Additional TCP/IP connections are used for data transfers;

>>Data connections may be sent to random port numbers;

>>Data connections may originate from the server to the client, as well as
originating from the client to the server;

>>Data connectionsÂ destination addresses are negotiated on the fly between
the client and server over the channel used for the control connection;

>>The control connection is idle while the data transfer takes place on the
data connection.

What a protocol.

~~~
phil21
The control/data connections are actually pretty neat, and for the era (actual
working Internet) it was a good idea that worked quite well. I understand it
looks "hacky" today - but that's largely due to far worse hacks lower down the
stack.

NAT came along, and everyone broke everything. Now you can't make up neat
protocols like this any more - everything must be user-initiated TCP or server
based. I do wonder how much development and innovation this has held back.
Even games back in the day had far more interesting network models - that were
more sustainable long-term.

NAT was likely the first major crack in the wall of the open Internet, making
it much weaker and the users more compliant than it previously was. I strongly
believe that's one of the major reasons why we have what we're left with
today.

~~~
xkxx
Thank you, guys. You prompted me to learn a bit about the protocol. I want to
share what I learned after skimming over the RFC.

A typical session looks like:

    
    
        $ telnet ftp.kernel.org 21
        Trying 149.20.4.69...
        Connected to ftp.all.kernel.org.
        Escape character is '^]'.
        220 Welcome to kernel.org
        USER anonymous
        331 Please specify the password.
        PASS
        230 Login successful.
        PASV
        227 Entering Passive Mode (149,20,4,69,119,142).
    

Then I was baffled. What does 149,20,4,69,119,142 mean? Okay, 149,20,4,69
looks like an IP address for ftp.kernel.org. But what do they want me to do
with 119,142? Turns out it's a port number divided into two octets. Basically
they are asking me to connect to port 119 * 256 + 142 = 30606.

So, on the second terminal I run:

    
    
        $ telnet 149.20.4.69 30606
        Trying 149.20.4.69...
        Connected to 149.20.4.69.
        Escape character is '^]'.
    

Back to the first one:

    
    
        LIST
        150 Here comes the directory listing.
        226 Directory send OK.
    

And I get the listing I requested, on the second terminal:

    
    
        drwxr-xr-x    9 ftp      ftp          4096 Dec 01  2011 pub
        Connection closed by foreign host.
        $
    

Instead of using PASV, you can request the FTP server to connect back to you,
with PORT. First, you need to start listening on your WAN interface (if you
have one; if you don't, you are out of luck) with `nc -l your.ip.goes.here
2560`. Then, request the server to connect by typing `PORT
your,ip,goes,here,10,0` (NB: use commas, not dots). Of course, don't forget to
replace your.ip.goes.here with your real WAN IP address.

Cheers.

~~~
droopybuns
This was cool! Thank you for sharing!

------
gumby
FTP may look crufty today but it was an excellent protocol _for its time_ ,
and offers capabilities you can't really get with any other current protocol.

Really, the problem is that NAT is a terrible idea and screws up the idea of a
fully end-to-end Internet.

~~~
KirinDave
> FTP may look crufty today but it was an excellent protocol for its time, and
> offers capabilities you can't really get with any other current protocol.

This is some weird astroturfing of the FTP protocol's goodwill, but it was
never particularly good. Even for its time it's a curiously conceited protocol
that is remarkably complicated without _doing_ very much that a similarly
intelligent RMI-style interface couldn't have worked with.

And in practice, many FTP clients basically left the control channel concept
behind and began to use it as if it were streamed RMI, opening up multiple
connections for transfers to help users deal with even 1980's network
environments.

It stands out as complicated for its time.

~~~
gtirloni
This is tangencial but I don't think gumpy's comment could be considered
"astroturfing".

[https://en.m.wikipedia.org/wiki/Astroturfing](https://en.m.wikipedia.org/wiki/Astroturfing)

------
nickpsecurity
Almost all downloads these days are over HTTP or native apps. Probably for the
better that we let FTP go. If we do a custom one, its should have benefits the
popular solution doesn't have. Maybe performance (eg Tsunami, UDT) or security
(stuff with TLS). Ton of solutions for availability with existing stuff so I
leave it off.

~~~
digi_owl
The big thing we seem to be missing (likely because "everyone" is using some
kind of _drive service) is uploading.

~~~
laumars
HTTP does support uploading. But even that aside, there are plenty of better
protocols for uploading than FTP. Eg SFTP, p2p, heck even cloud storage
services if you want something easy for the layman.

------
eps
> _while kinda neat and convenient, offering a public NFS /CIFS server was a
> Pretty Bad Idea_

\\\live.sysinternals.com\tools says Hi

~~~
noinsight
That's WebDAV, not CIFS. You can also access WebDAV paths with the UNC
notation.

------
systematical
I pretty much avoid it, even on sites that need it for wordpress you can use
SFTP instead with the use of the wp sftp plugin

------
bluedino
Why can't you run FTP on a CDN?

~~~
tinus_hn
FTP uses multiple connections that need to coordinate. It only works if these
connections are from/to the same machine which is difficult to guarantee using
a CDN.

------
digi_owl
Kinda sad, as i often fire up ftp urls when looking for tar-balls of source
releases.

------
frik
IMHO stupid decision. There are many mirrors, that will be affect. FTP has
it's place.

~~~
dsr_
Mirrors almost universally use rsync, not FTP.

~~~
frik
I mean FTP mirrors, that offer an 1:1 FTP directory mirror.

~~~
throwawayish
Literally no one does that. rsync-over-SSH is often used for this, sometimes
plain rsync, sometimes custom stuff running atop SFTP (which is a completely
different thing from FTP(S)).

------
ryanmccullagh
1998, was so long ago. I was 8 years old! The Kernel was released the year I
was born. Then, in like 2011 I first heard of Linux and downloaded Ubuntu 10.

~~~
frik
Read the whole paragraph, the 1998 was about mounting public NFS share.

Now they want to discontinue FTP. Two different things.

