FTP

FTP content

FTP vs CD

Submitted by Mirjana on Sun, 02/13/2011 - 13:07

The majority of companies exchange essential and non-essential files using FTP (File Transfer Protocol), which has inherent security risks.

The reason FTP has been used in all of these applications is because of its availability -- FTP exists for all operating systems from mainframes down to PCs and it is routinely included in many commercial and open source applications.

Wide availability is a liability

However, this wide availability is also a liability. Because FTP is supported on numerous systems, there is a greater knowledge of the protocol, its operation, and implementations. For example, some companies never change the default passwords of FTP software so their FTP servers are subject to easy manipulation. Careless processes and human error provide an unintentional open door to malicious users who frequently hack into FTP servers and steal data.

In fact, the Sterling Commerce MFT solutions, which Connect:Direct is part of, have never been breached. This ensures information will be protected when a company does business electronically.

Maintaining and patching problem

Since FTP is available on many platforms, many operating systems and with many applications, companies must be particularly vigilant to ensure that security is airtight for all of the impacted servers and applications. They must respond quickly to any newly discovered vulnerabilities and make certain that they are rapidly patched. Since a company may not have control over all of the systems that come into play and might not be able to ensure that all systems meet security mandates, hackers have multiple points of attack to compromise data on scattered FTP servers.

Connect:Direct as a proprietary protocol is not so publicaly known and easy to hack at all.

Encryption and security

Another vulnerability of FTP is that alone it does not provide encryption. Files are sent as is and the content and FTP usernames and passwords are transmitted in clear text, all of which can be intercepted by someone eavesdropping on a communications link.

As security concerns are not a part of the FTP model and a client must supply an ID and password upon opening the connection to the server, this security information is transmitted in open text.

The Connect: products offer multiple choices, ranging from securing FTP traffic to robust security, that allow the data movement operation to fit naturally within enterprise security policies. If support of FTP traffic is required, the data flow can be encrypted. If higher security levels are required, proxy-based security, coupled with authentication and configurable encryption, can be implemented within the Connect: deployment.

The Connect:Direct Secure+ Option for Windows application provides enhanced security for Connect:Direct and is available as a separate component. It uses cryptography to secure data during transmission.

Cryptography provides information security as follows:

Authentication verifies that the entity on the other end of a communications link is the intended recipient of a transmission.
Non-repudiation provides undeniable proof of origin of transmitted data.
Data integrity ensures that information is not altered during transmission.
Data confidentiality ensures that data remains private during transmission.

Management, tracking, logging and auditing

Furthermore, as FTP use grows, management, tracking and auditing burdens also grow. Most often, file transfers are part of a larger workflow where completion of a task is predicated on the receipt of a file and then some action being taken on the information in that file. Lacking suitable tracking and auditing tools, an IT manager or corporate executive would be hard pressed to determine whether a transaction was completed or why one failed.

The statistics file stores information about all events that take place within the Connect:Direct server for a specific period of time. Each record within the statistics file consists of fields that contain general information about the record and a field that contains the statistics or audit information to log.

Handling movement workload (Queuing and scheduling capabilities)

FTP provides no way to control critical data movement or balance it against lower-priority work that can impact processing windows. Massive, unmanaged data movement can delay and slow critical deliveries. FTP places all control in the hands of the client, and the first job usually wins. FTP also lacks the ability to create an enforceable policy for workload execution. Over time, this frequently results in chaos.

Connect:Direct gives each process a work-queue priority and a session class. Priorities are used to determine when processes run, and session classes are used to reserve transmission channels for critical transfers. These can be set up and enforced in accordance with business requirements. Users’ requests are always accepted, but the actual operation of the request is scheduled according to the business policy that drives the priority and class structure.

This accomplishes the goals of the user as well as those of the business.

Without queuing, scheduling and management capabilities, it is impossible to control the data movement workload.

As Connect:Direct Processes are submitted, they are placed in one of the four TCQ logical queues: Execution, Wait, Timer, and Hold. As sessions are available, the TCQ releases Processes to begin execution according to the Process class and priority.

Connect:Direct Processes could be scheduled to execute in the future.

Notification

In addition to consistent management, organizations need a structured level of notification that enables real-time adjustments to the data movement infrastructure. The enterprise requirements for notification are:

Instantaneous notification of critical exception and error conditions
Flexibility in the routing of notifications
Integration of data movement notification with the Enterprise Systems Management (ESM) structure
Historical logging of data movement activities

Connect: answers all these requirements by providing notification and logging as a natural part of the data movement operation. Notification can be routed, using a variety of platform capabilities, to operation and monitoring staff. Alerts represented by SNMP traps can be directed to ESM systems for proactive action at the network level. And all Connect: activity, including finely grained operational detail, is logged continuously.

FTP provides none of these capabilities. It is very difficult, if not impossible, to determine previous FTP activity. Any action that is required must be performed by the client/user. This makes for an inconsistent and unresponsive data movement infrastructure. Therefore, the cost associated with the use of FTP must include the inherent delays in exception discovery.

Connect:Direct for Windows provides two notification methods:

NT Broadcast—NT Broadcast notification is performed using the Windows net send command.
SMTP—E-Mail notification is performed using Simple Mail Transfer Protocol (SMTP) notification, a simple ASCII protocol.

Recovery

FTP does not provide an automated way to recover from network errors. Any outage that occurs with FTP operations must first be discovered and then handled manually. This generally means restarting the failed operation from the beginning.

The costs associated with FTP recovery are:

Retransmission due to networking resource failure. On average, FTP will need to retransmit half the overall data movement volume per failure. Connect: recovers the network connection and requires no retransmission.
During a network-resource failure, FTP use requires discovery of the failure. This delay in restart represents cost. Connect: will automatically sense network failures and retry the operation. In most cases the recovery will be automatic. In the case of a permanent outage, notification is provided to enable rapid resolution.

Several facilities are provided for Connect:Direct process recovery after a system malfunction. The purpose of Process recovery is to resume execution as quickly as possible and to minimize redundant data transmission after a system failure. The following Connect:Direct facilities are available to enable Process recovery:

Process step restart
Automatic session retry
Checkpoint/restart – resume for check point
Intelligent session restart -permits a session retry on only the first Process (others ar eplaced in Timer queue) submitted
Short-term and long-term retry – restart in specific time periods

Automation

Through the use of scripting, scheduling, and application integration, automation can ensure that proven business processes can continue to be successful by eliminating human error. With processes that require human interaction, errors and unintended activity can be introduced into a process flow. Many times such an error will not be discovered until much time has passed.

The cost involved with the lack of FTP automation include:

Operations that complete successfully but are not usable since there is no way to validate user selected (or defaulted) options.
No central control of scheduled activities. Clients can initiate FTP activity regardless of its importance or impact on schedule.

Connect:Direct File Agent provides monitoring and detection capabilities that enhance the

automation you accomplish with Connect:Direct Processes.

FTP vs HTTP

Submitted by Mirjana on Sun, 02/13/2011 - 12:58

Differences in general:

FTP	HTTP
FTP is file transfer protocol, so it is optimised for transmitting files	HTTP is hypertext transfer protocol, so it is optimised for transmitting hypertext, i.e. web pages.
FTP does a lot more packet verification. That means it's somewhat slower for a given size file, but the file is more likely to get through in one piece because, for a binary application file, for example, one lost packet is as good as losing the whole thing.	HTTP was designed to be fast, but not solid. Who cares if you lose a few packets here and there anyway?
FTP, is a protocol used to upload files from a workstation to a FTP server or download files from a FTP server to a workstation.	HTTP, is a protocol used to transfer files from a Web server onto a browser in order to view a Web page that is on the Internet. Unlike FTP, where entire files are transferred from one device to another and copied into memory, HTTP only transfers the contents of a web page into a browser for viewing
When ftp appears in a URL it means that the user is connecting to a file server and not a Web server	When http appears in a URL it means that the user is connecting to a Web server and not a file server
Statefull protocol and requires fewer round trips for communication.	Stateless protocol – only request response
FTP is a two-way system as files are transferred back and forth between server and workstation.	HTTP is a one-way system as files are transported only from the server onto the workstation’s browser.
FTP puts less load on the network for smaller transfers
For transfers of large amounts of data, both are comparable
With ftp, clients can do a directory listing and get time stamps and file sizes.	Directory listing is not usually possible with Web connections, because that information is hidden from the user
Can be tied to specific user accounts and require user authentication – PROS
Can allow anonymous access if desired – PROS
Easy target for hackers – CONS

HTTP may be less secure than FTP depending on which software you use for your HTTP server and which platform on which you are running the HTTP server and how you configure it

Differences in details

Both protocols are used for uploads and downloads on the internet, for text and for binary, both over TCP/IP. But there are a lot of differences in the details:

1.	Age		FTP appeared roughly ten years before HTTP was invented. FTP was the one and only protocol back then.
2.	Upload	FTP	Both protocols offer uploads. FTP has an "append" command
2.	Upload	HTTP	HTTP is more of a "here's data coming now you deal with it" approach. It could be worth noticing that WebDAV is a protocol on top of HTTP that provides "filesystem-like" abilities
3.	ASCII/binary	FTP	FTP has a notion of file format so it can transfer data as ASCII or binary (and more) where. FTP thus also allows text conversions when ASCII files are sent between systems of different sorts
3.	ASCII/binary	HTTP	HTTP always sends things binary. HTTP provides meta-data with files, Content-Type, which clients use but FTP has no such thing. The meta data can thus be used by clients to intrepret the contents accordingly
4.	Headers	FTP	FTP does not send headers. When sending small files, the headers can be a significant part of the amount of actual data tranffered - CONS
4.	Headers	HTTP	Transfers with HTTP always also include a set of headers that send meta data HTTP headers contain info about things such as last modified date, character encoding, server name and version and more - PROS
5.	Pipelining	FTP	Something related, although not similar, is FTP's support for requesting multiple files to get transferred in parallel using the same control connection. That's of course using new TCP connections for each transfer so it'll get different performance metrics
5.	Pipelining	HTTP	HTTP supports pipelining. It means that a client can ask for the next transfer already before the previous one has ended, which thus allows multiple documents to get sent without a round-trip delay between the documents, and TCP packets are thus optimized for transfer speed.
6.	FTP Command Response	FTP	FTP involves the client sending commands to which the server responds. A single transfer can involve quite a series of commands. This of course has a negative impact since there's a round-trip delay for each command Reretriving a single FTP file can easily get up to 10 round-trips - CONS
6.	FTP Command Response	HTTP	HTTP transfers are primarily just one request and one response (for each document)
7.	Two connections	FTP	One of the biggest hurdles about FTP in real life is its use of two connections. It uses a first primary connection to send control commands on, and when it sends or receives data, it opens a second TCP stream for that purpose - CONS
7.	Two connections	HTTP	Uses only one connection for request and response
8.	Active Passive	FTP	FTP opens the second connection in an active or passive mode, which basically says which end that initiates it. IT's a client decision to try either way.
8.	Active Passive	HTTP	There is no active/passive option in HTTP
9.	Firewall and NATs	FTP & HTTP	FTP's use of two connections, where the second one use dynamic port numbers and can go in either direction, gives the firewall admins grief and firewalls really have to "understand" FTP at the application protocol layer to work really well. This also means that if both parties are behind NATs, you cannot use FTP!
10.	Encrypted Control Connections	FTP & HTTP	Since firewalls need to understand FTP to be able to open ports for the secondary connection etc, there's a huge problem with encrypted FTP (FTP-SSL or FTPS) since then the control connection is sent encrypted and the firewall(s) cannot interpret the commands that deal with creating the second connection. Also, the FTPS standard took a very long time to "hit it" so there exist a range of hybrid versions out in the wild.
11.	Authentication	FTP & HTTP	FTP and HTTP have a different set of authentication methods documented. While both protocols offer basically plain-text user and password by default, there are several commonly used authentication methods for HTTP that isn't sending the password as plain text, but there aren't as many (non-kerberos) options available for FTP.
12.	Download	FTP & HTTP	Both protocols offer support for download. Both protocols used to have problems with file sizes larger than 2GB but those are history for modern clients and servers on modern operating systems
13.	Ranges/ Resume	FTP & HTTP	Both FTP and HTTP support resumed transfers in both directions, but HTTP supports more advanced byte ranges
14.	Persistent Connections	FTP	FTP must create a new connection for each new data transfer.
14.	Persistent Connections	HTTP	For HTTP communication, a client can maintain a single connection to a server and just keep using that for any amount of transfers.
15.	Chunked Encoding	HTTP	HTTP has a means of sending data which has an unknown size at the start of the transfer, but still not have to use close of the connection to signal the end of the data. This is done by "chunked encoding", which simply sends a stream of [size-of-data][data] blocks over the wire. Another obvious benefit with chunked encoding compared to plain closing of the connection is the ability to detect premature connection shutdowns.
16.	Compression	FTP	FTP offers an official "built-in" run length encoding that compresses the amount of data to send, but not by a great deal on ordinary binary data. It has also traditionally been done for FTP using various "hackish" approaches that were never in any FTP spec.
16.	Compression	HTTP	HTTP provides a way for the client and server to negotiate and use (different) compression for the sent data. The gzip algorithm being the perhaps most compact one.
19.	Name based Virtual hosting	FTP	In FTP, you cannot do name based virtual hosting at all.
19.	Name based Virtual hosting	HTTP	Using HTTP, you can easily host many sites on the same server and they are all differentiated by their names.
20.	Dir Listing	FTP	One area in which FTP stands out somewhat is that it is a protocol that is directly on file level. It means that FTP has for example commands for listing dir contents of the remote server However, the FTP spec authors lived in a different age so the commands for listing directory contents (LIST and NLST) don't have a specified output format so it's a pain to write programs to parse the output. Latter specs (RFC3659) have addressed this with new commands, but they are not widely implemented or supported by neither servers nor clients.
20.	Dir Listing	HTTP	HTTP does not have a concept of listing dir content
22.	Proxy	FTP	FTP has always been used over proxies as well, but that was never standardized and was always done in lots of different ad-hoc approaches.
22.	Proxy	HTTP	One of the biggest selling points for HTTP over FTP is its support for proxies, already built-in into the protocol from day 1. The support is so successful and well used that lots of other protocols can be sent over HTTP these days just for its ability to go through proxies.
23.	Transfer speed	FTP	What makes FTP faster: No added meta-data in the sent files, just the raw binary Never chunked encoding "overhead"
23.	Transfer speed	HTTP	What makes HTTP faster: reusing existing persistent connections make better TCP performance pipelining makes asking for multiple files from the same server faster (automatic) compression makes less data get sent no command/response flow minimizes extra round-trips

FTP vs SFTP

Submitted by Mirjana on Sun, 02/13/2011 - 11:59

SFTP does not have anything common with FTP

SFTP, or secure FTP, is a program that uses SSH to transfer files. Unlike standard FTP, it encrypts both commands and data, preventing passwords and sensitive information from being transmitted in the clear over the network. It is functionally similar to FTP, but because it uses a different protocol, you can't use a standard FTP client to talk to an SFTP server, nor can you connect to an FTP server with a client that supports only SFTP.

SFTP is most often confused with FTPS and vice-versa. However, unlike FTP and FTPS these protocols are not at all related. SFTP is actually a sub-system of the SSH (Secure Shell) protocol and typically runs on port 22. Unlike FTP/S, SFTP does not have the concept of separate command and data channels. Instead both data and commands are transferred in specially formatted packets via a single connection. Furthermore, unlike FTPS explicit SSL, SFTP encrypts the entire session and does not offer the ability to switch between unencrypted and encrypted mode.

Encryption methods for SFTP and FTPS

Both FTPS and SFTP use a combination of asymmetric algorithm (RSA, DSA), symmetric algorithm (DES/3DES, AES, Twhofish etc.) and a key-exchange algorithm.

For authentication FTPS (to be more precise, SSL/TLS protocol under FTP) uses X.509 certificates, while SFTP (SSH protocol) uses SSH keys.

X.509 certificates include the public key and certain information about the certificate owner. This information lets the other side verify the integrity of the certificate itself and authenticity of the certificate owner. Verification can be done both by computer and to some extent by the human. X.509 certificate has an associated private key, which is usually stored separately from the certificate for security reasons.

SSH key contains only a public key (the associated private key is stored separately). It doesn't contain any information about the owner of the key. Neither it contains information that lets one reliably validate the integrity and authenticity. Some SSH software implementations use X.509 certificates for authentication, but in fact they don't validate the whole certificate chain - only the public key is used (which makes such authentication incomplete and similar to SSH key authentication).

SFTP vs FTPS, what to choose

While FTP is very popular, it has certain disadvantages that make it harder to use. The major drawbacks are:

· lack of the uniform format for directory listing (this problem has been partially solved by introducing MLST command, but it's not supported by some servers) and

· presence of the secondary connection (DATA connection).

· Security in FTP is provided by employing SSL/TLS protocol for channel encryption. The secured version of FTP is called FTPS.

As usually, the answer depends on what your goals and requirements are. In general, SFTP is technologically superior to FTPS. Of course, it's a good idea to implement support for both protocols, but they are different in concepts, in supported commands and in many other things.

It's a good idea to use FTPS when you have a server that needs to be accessed from personal devices (smartphones, PDAs etc.) or from some specific operating systems which have FTP support but don't have SSH / SFTP clients. If you are building a custom security solution, SFTP is probably the better option.

As for the client side, the requirements are defined by the server(s) that you plan to connect to. When connecting to Internet servers, SFTP is more popular because it's supported by Linux and UNIX servers by default.

For private host-to-host transfer you can use both SFTP and FTPS. For FTPS you would need to search for a free FTPS client and server software or purchase a license for commercial one. For SFTP support you can install OpenSSH package, which provides free client and server software.

SFTP and FTPS – pros and cons

SFTP
Pros	Cons
Good standards background which strictly defines most (if not all) aspects of operations	The communication is binary and can't be logged "as is" for human reading
Only one connection (no need for DATA connection)	SSH keys are harder to manage and validate
The connection is always secured	The standards define certain things as optional or recommended, which leads to certain compatibility problems between different software titles from different vendors
The directory listing is uniform and machine-readable	No server-to-server copy and recursive directory removal operations
The protocol includes operations for permission and attribute manipulation, file locking and more functionality	No built-in SSH/SFTP support in VCL and .NET frameworks

FTPS
Pros	Cons
Widely known and used	Doesn't have a uniform directory listing format
The communication can be read and understood by the human	Requires a secondary DATA channel, which makes it hard to use behind the firewalls
Provides services for server-to-server file transfer	Doesn't define a standard for file name character sets (encodings)
SSL/TLS has good authentication mechanisms (X.509 certificate features)	Not all FTP servers support SSL/TLS
TP and SSL/TLS support is built into many internet communication frameworks	Doesn't have a standard way to get and change file and directory attributes

FTP protocol security

Submitted by Mirjana on Sun, 02/13/2011 - 09:16

The original FTP specification is an unsecure method of transferring files because there is no method specified for transferring data in an encrypted fashion. This means that under most network configurations, user names, passwords, FTP commands and transferred files can be captured by anyone on the same network using a packet sniffer.

This is a problem common to many Internet protocol specifications written prior to the creation of SSL, such as HTTP, SMTP and Telnet. The common solution to this problem is to use either SFTP (SSH File Transfer Protocol), or FTPS (FTP over SSL), which adds SSL or TLS encryption to FTP.

Just to make things more complicated, FTPS is available in two forms known as FTPS Implicit SSL and FTPS Explicit SSL.

FTPS Implicit SSL

In implicit SSL mode a required SSL session is established between client and server before any data is exchanged. In other words, the use of SSL is implied because any attempt made by a non-SSL client would automatically be refused by the server. Typically FTPS implicit SSL services run on port 990.

FTPS Explicit SSL

In explicit SSL mode the client can optionally switch from unencrypted mode to SSL. This is useful in that the server can support both unencrypted FTP and encrypted FTPS sessions on a single port, typically port 21. In an explicit SSL session the client first establishes an unencrypted connection to FTP service. Prior to sending user credentials, the client then requests that the server switch the command channel to an SSL encrypted channel using the client AUTH TLS or AUTH SSL commands. Upon successful setup of the SSL channel the client then sends user credentials to the FTP server. These credentials along with any other commands sent to server during the FTP session are automatically encrypted by the SSL channel.

Risks when using the FTP protocol

Using the FTP protocol is regarded to be very unsafe because a password must always be entered for the transfer. The password is subsequently transmitted over the Internet without encryption. Despite the fact that FTP is one of the oldest and most widely used Internet protocols, there are security risks when using it. These include:

· A user's name and password are transferred in clear text when logging on and can therefore be easily recognized.

· When using an FTP connection, the transferred data could "stray" to a remote computer and not arrive at their intended destination. Third parties can then download data from the remote system to their own computers, or existing data can be viewed and edited. This presents a significant risk, particularly when transferring company confidential information.

· FTP can also be used to determine the passwords of individual users, since the password is transferred in clear text when logging on. As a result, even those with unauthorized access to this network can record the password information.

It is therefore advisable to use SFTP connections to ensure that data is securely transferred. This data transfer protocol encrypts the connection between your computer and the FTP server. Data is then transferred to your computer over an encrypted connection (SSH-Tunnel).

FTP protocol security

Submitted by Mirjana on Sun, 02/13/2011 - 09:16

Just to make things more complicated, FTPS is available in two forms known as FTPS Implicit SSL and FTPS Explicit SSL.

FTPS Implicit SSL

FTPS Explicit SSL

Risks when using the FTP protocol

· A user's name and password are transferred in clear text when logging on and can therefore be easily recognized.

FTP active passive - which one to use?

Submitted by Mirjana on Sun, 02/13/2011 - 09:11

This depends largely on the FTP server capabilities and configuration.

Does the server support passive connection?

From the client perspective the first question you need to ask yourself is if the server support passive connections. There are some FTP servers, especially those running on older mainframe systems that do not support passive connections.

Is passive mode enabled in the server side?

It's also possible that while the server supports passive connections the server may have this feature disabled. This is usually due to an aggressive firewall policy on the server side that disallows passive connections. Naturally, if the server doesn't support/allow passive connections then you will be forced to use active mode.

How to check if the server allows passive connection?

The easiest way to test whether a server supports passive mode is to simply connect using passive mode and perform a directory listing to see what happens. If you get back a directory listing without error then the server supports passive mode. If however you get an error like "500 PASV command not supported" or "500 PASV command disabled" then you will need to use an active connection.

What should be a default mode?

In general you should always default to using a passive connection when possible. It is much more firewall-friendly to clients than active mode given that most Internet users today are behind firewalls using NAT software.

From the perspective of an FTP server administrator you should make it as easy as possible for your clients to connect. This means enabling passive mode on your server so that clients who are behind a firewall or router that uses NAT software, can connect easily.

Which one is beneficial to the FTP server admin?

Active FTP is beneficial to the FTP server admin, but detrimental to the client side admin. The FTP server attempts to make connections to random high ports on the client, which would almost certainly be blocked by a firewall on the client side.

Which one is beneficial to the FTP client admin?

Passive FTP is beneficial to the client, but detrimental to the FTP server admin. The client will make both connections to the server, but one of them will be to a random high port, which would almost certainly be blocked by a firewall on the server side.

FTP active passive modes

Submitted by Mirjana on Sun, 02/13/2011 - 03:52

The questions how to deal with firewalls and other Internet connectivity issues is mainly based on the difference between active and passive FTP.

FTP is an unusual service, in that it utilizes two ports, a data port and a command port (also known as the control port). Traditionally these are port 21 for the command port and port 20 for the data port. The confusion begins when we find that depending on the mode, the data port is not always on port 20.

Active (Non – Passive) Mode

In active mode the client is responsible for opening the listening port and telling the server what IP/port to connect to in order to perform the transfer. To start an active transfer the client sends the PORT command along with arguments telling the server what client-side listening IP/port the server should connect to in order to perform the transfer. Once the transfer is complete the port is closed by the client.

Steps in active FTP mode:

the client connects from a random unprivileged port (N > 1023) to the FTP server's command port, port 21
then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server
the server will then connect back to the client's specified data port from its local data port, which is port 20.

Passive Mode

In passive mode the server is responsible for opening the listening port and telling the client what server-side listening IP/port to connect to in order to perform the transfer. The server then responds with the IP address and port that the client should connect to in order to perform the transfer. Once the transfer is complete the port is closed by the server.

Who initiates connections?

In order to resolve the issue of the server initiating the connection to the client a passive method for FTP connections was developed. PASV command is used by the client to tell the server it is in passive mode.

Client initiates command as well as data connections.

In passive mode FTP the client initiates both connections to the server, solving the problem of firewalls filtering the incoming data port connection to the client from the server.

Steps in passive FTP mode:

when opening an FTP connection, the client opens two random unprivileged ports locally N > 1023 and N+1
the first port contacts the server on port 21, but instead of then issuing a PORT command and allowing the server to connect back to its data port, the client will issue the PASV command
the result of this is that the server then opens a random unprivileged port (P > 1023) and sends the PORT P command back to the client.
the client then initiates the connection from port N+1 to port P on the server to transfer data.

Some problems with passive mode

While passive mode FTP solves many of the problems from the client side, it opens up a whole range of problems on the server side.

The biggest issue is the need to allow any remote connection to high numbered ports on the server.

The second issue involves supporting and troubleshooting clients which do (or do not) support passive mode. As an example, the command line FTP utility provided with Solaris does not support passive mode, necessitating a third-party FTP client, such as ncftp.

With the massive popularity of the World Wide Web, many people prefer to use their web browser as an FTP client. Most browsers only support passive mode when accessing ftp:// URLs. This can either be good or bad depending on what the servers and firewalls are configured to support.

FTP protocol

Submitted by Mirjana on Sun, 02/13/2011 - 03:39

FTP protocol basics

FTP stands for ‘File Transfer Protocol’ and it is an Internet service designed to establish a connection to a particular Internet server, so that users are able to transfer files (download) to their computer or to transfer (upload) their files to the server.

Client applications were originally interactive command-line tools with a standardized command syntax, but graphical user interfaces have been developed for all desktop operating systems in use today. FTP is also often used as an application component to automatically transfer files for program internal functions.

The FTP protocol also includes commands that can be used to execute operations on a remote computer; e.g., to show folder contents, change directories, create folders or delete files.

FTP as client/server protocol

FTP is based on the client/server model for communications between computers. In this model, a computer called a server runs a program that "serves" data to other computers. The other computers run client programs that request information and process the replies that the server sends.

Usually FTP servers listen on the well-known port number 21 for incoming connections from clients. A connection to this port from the FTP client forms the control stream on which commands are passed to the FTP server and responses are collected. FTP uses out-of-band control; it opens dedicated data connections on other port numbers. The parameters for the data streams depend on the specifically requested transport mode.

FTP command and data channels

The FTP protocol consists of two channels, the command channel and the data channel. These channels are responsible for exchanging commands and data in an FTP client session.

Command channel

The command channel is responsible for handling/accepting simple commands between FTP server and client.

The command channel is also responsible for sending replies back to the FTP client in response to client commands.

Command channel typically runs on port 21 for standard FTP and encrypted FTP that uses explicit SSL. Command port 990 is used for encrypted implicit SSL connection.

The USER and PASS commands used for authenticating an FTP user are examples of commands that are exchanged on the command channel. The command channel remains open until the client sends the QUIT command to disconnect or the server forcibly disconnects the client.

Data channel

The data channel runs on temporary random ports listening on the server (passive mode) or on the client (active mode) and are responsible for exchanging data in the form of file transfers and directory listings. The LIST command used for getting a FTP server directory listing is an example of a command that opens a data channel. Unlike the command channel which remains alive during the entire FTP session, the data channel automatically shuts down once the transfer of data is complete.

The port on which the data channel is performed and additionally whether the client or server is responsible for opening this port depends on the data transfer mode used. There are two data transfer modes available in FTP. These data transfer modes are known as passive and active a.k.a non-passive.

Donate via PayPal

Select amount

About donation

As you all know I've been doing this for over a decade and have never asked for anything from anybody. I do not have any sponsors; and all the time and money I've invested over the years has been accumulating. Now I request, if you can, please show your appreciation to the site by making a small donation for servers and site maintenance.

World of Integration

FTP

FTP vs CD

FTP vs HTTP

FTP vs SFTP

FTP protocol security

FTP protocol security

FTP active passive - which one to use?

FTP active passive modes

FTP protocol

About donation

Library

Main Menu

User login

Tell a friend

New forum topics