Okay, enough talk.
Let's watch this conversation in action on the live network.
I'll start this demo with a very brief explanation of very secure FTP daemon,
or vsftpd.
This is the FTP server used for most of this course.
It's easily installed using the Linux command shown in orange.
Let's peak at the config file.
We will be making small modifications to this file throughout the
course to enable more features as they become relevant.
Initially,
the only modifications I made to the defaults are highlighted in orange.
These commands allow FTP clients to drop into their home directories,
then into a directory named ftp after login.
In case you want to follow along, I'll provide the vsftpd package version.
If you are on another version, there might be some minor differences.
Let's quickly verify that the FTP server is running and operational.
Okay, this looks good.
Let's check out the client next.
The client program is called lftp.
The version I'm using is already shown.
You can install it using the command in orange,
and I recommend you do, as it's a great FTP client.
FTP clients tend to be interactive, kind of like a remote shell.
Because I value your time and don't want to waste it by typing,
I'll be using premade scripts instead.
These are included in the course files.
Let's examine our FTP active mode download script.
These are lftp shell commands.
The first command enables debugging to level 5,
which is a moderate level of detail.
This reveals what is happening from an FTP signaling perspective,
almost like a high-level packet capture.
Next, I am explicitly setting an FTP option to disable passive mode.
We'll cover passive mode in the next module,
and disabling it implies we are using FTP active mode.
It's time to log in.
I've created a standard Linux user on the FTP server
named ftpuser with a password of ftppass.
Lftp uses the open command with the -u option to specify
these parameters separated by a comma.
At the end, the IP address or host name of the FTP server is supplied,
which is 10.2 .5 .5.
The word get is commonly used by many FTP clients to download files,
and in this case we are downloading R1's configuration file.
This file exists in the FTP user's home directory under the ftp subdirectory.
If you recall from the FTP server configuration,
this is where the FTP client is dropped off after login.
Last, I'm sending the ls command just for fun.
I want to illustrate that FTP does more than just transferring files.
You can change directories, list directory contents,
change permissions, and much more.
I don't focus on these minor features, but I do want to illustrate one example.
Note that we do not have R1.cfg available locally yet.
We can pass the script into lftp using the -f option.
This will run the script and download R1.cfg to the
client's current working directory.
See how fast that was?
Let's scroll up and review what happened,
keeping in mind that I'll dig even deeper in future
clips when using packet captures.
First, the client connects to 10.2 .5 .5 on port 21,
and the server replies with its version information.
Next,
the client issues the FEAT command and gets several replies from the server,
indicating the list of capabilities that it supports.
Following that, the user logs in,
entering into a dialog with the server to supply both username and password.
There are several intermediate commands here,
each of which I'll discuss more in the packet capture.
Let's move on to the port command.
This is where the client tells the server what TCP port to use.
I'll explain what the mysterious 148,
3 actually means once we drill into the packet capture.
The client uses the RETR command to download the file R1.cfg.
The server opens a new TCP session to the client sourced from TCP port 20.
The file is transferred without issue.
The client sends another port command and the server opens up
another FTP data session for the sole purpose of returning the
directory listing via the list command.
Whether FTP is transferring files or ASCII data,
the same connectivity actions occur.
This output looks similar to just running ls on the FTP server locally.
Let's see what is inside the R1.cfg file.
Looks good to me.
I keep these demonstration files small,
both to save time and to simplify the packet captures, although much larger files can be transferred.