File Transfer Protocol ( FTP ) is the default network protocol used for computer file transfers between clients and servers on a computer network.
FTP is built on a client-server model architecture and uses separate controls and data connections between clients and servers. FTP users can authenticate themselves with clear sign-text protocols, usually in the form of usernames and passwords, but may connect anonymously if the server is configured to allow it. For secure transmission that protects usernames and passwords, and encrypts content, FTP is often secured with SSL/TLS (FTPS) or replaced with SSH File Transfer Protocol (SFTP).
The first FTP client application is a command line program developed before the operating system has a graphical user interface, and is still shipped with most Windows, Unix, and Linux operating systems. Many FTP clients and automation utilities have since been developed for desktops, servers, mobile devices, and hardware, and FTP has been incorporated into productivity applications, such as web page editors.
Video File Transfer Protocol
Sejarah server FTP
The original specification for File Transfer Protocol was written by Abhay Bhushan and published as RFC 114 on April 16, 1971. Until 1980, FTP used NCP, the predecessor of TCP/IP. The protocol was subsequently replaced by versions of TCP/IP, RFC 765 (June 1980) and RFC 959 (October 1985), the current specification. Some proposed standards change RFC 959, for example RFC 1579 (February 1994) allows Firewall-Friendly FTP (passive mode), RFC 2228 (June 1997) proposes a security extension, RFC 2428 (September 1998) adds support for IPv6 and defines a new type of mode passive. FTP has two modes: (active mode, data transfer, using TCP port 20) and (control, command, mode using TCP port 21).
Maps File Transfer Protocol
Protocol overview
Communication and data transfer
FTP can run in the active or passive mode, which determines how data connections are made. In either case, the client creates a TCP control connection from random, usually not special, port N to the FTP server command port 21.
- In active mode, the client starts listening to incoming data connections from the server on port M. This sends the FTP PORT M command to inform the server of which port is being listened to. The server then starts the data channel to the client from its port 20, the FTP server data port.
- In situations where the client is behind a firewall and can not accept incoming TCP connections, passive mode can be used. In this mode, the client uses a control connection to send a PASV command to the server and then receives the server's IP address and server port number from the server, which the client then uses to open the data connection from the changing client port to the server's IP address and server port number be accepted.
Both modes were updated in September 1998 to support IPv6. Further changes were introduced to passive mode at the time, updating it to extended passive mode .
The server responds via a control connection with a three-digit status code in ASCII with an optional text message. For example, "200" (or "200 OK") means the last command succeeded. The numbers show the code for the response and optional text represents human readable explanations or requests (e.g. & Lt; Requires account to save file & gt;). The transfer of data files that are in progress through the data connection can be canceled using an interrupt message sent through the control connection.
When transferring data over a network, four data representations can be used:
- ASCII mode: Used for text. The data is converted, if required, from the sender's host character representation to "8-bit ASCII" before transmission, and (again, if necessary) to the host's host character representation. As a result, this mode is not appropriate for files that contain data other than plain text.
- Image mode (commonly called Binary mode): The sending machine sends each file byte by byte, and the recipient saves bytestream upon receipt. (Support image mode has been recommended for all FTP implementations).
- EBCDIC mode: Used for plain text between hosts using the EBCDIC character set.
- Local mode: Allows two computers with the same settings to send data in proprietary format without the need to convert to ASCII.
For text files, format controls and different note structure options are provided. These features are designed to facilitate files containing Telnet or ASA.
Data transfer can be done in one of three modes:
- Streaming mode: Data is sent as a continuous stream, freeing FTP from performing any processing. Instead, all processes are submitted to TCP. No end-of-file indicator is required unless the data is divided into recording.
- Block mode: FTP breaks data into blocks (blocks headers, byte counts, and data fields) and then passes them to TCP.
- Compressed mode: Data is compressed using a simple algorithm (usually a path length encoding).
Some FTP software also implements DEFLATE-based compression mode, sometimes called "Mode Z" after commands that allow it. This mode is described in the Internet Draft, but not standardized.
Sign in
FTP login uses a normal username and password scheme to grant access. The username is sent to the server using the USER command, and the password is sent using the PASS command. This sequence is unencrypted "on the wire", so it may be vulnerable to network sniff attacks. If the information provided by the client is received by the server, the server will send a speech to the client and the session will start. If the server supports it, the user can sign in without providing login credentials, but the same server can authorize only limited access to the session.
Anonymous FTP
A host that provides FTP services can provide anonymous FTP access. Users typically sign in to the service with an anonymous account (lowercase and case sensitive on some FTP servers) when prompted for a username. Although users are usually asked to send their email address instead of a password, no verification is actually performed on the data provided. Many FTP hosts that aim to provide software updates will allow anonymous login.
NAT and firewall traversal
FTP usually transfers the data by requesting the server to connect back to the client, after the PORT command is sent by the client. This is problematic for NAT and firewall, which does not allow connections from the Internet to internal hosts. For NAT, an additional complication is that the IP address representation and port number in the PORT command refer to the host's internal IP address and port instead of the public IP address and NAT port.
There are two approaches to solving this problem. One is that FTP clients and FTP servers use the PASV command, which causes the data connection to be created from the FTP client to the server. It is widely used by modern FTP clients. Another approach is for NAT to change the values ​​of the PORT command, using an application-level gateway for this purpose.
Differences from HTTP
HTTP basically fixes bugs in FTP that make it uncomfortable to use for many small ephemeral transfers as they are typical on web pages.
FTP has stateful connection control which maintains the current working directory and other flags, and each transfer requires a secondary connection through which data is transferred. In "passive" mode this secondary connection is from client to server, while in default "active" mode, this connection from server to client. The role reversal is clear when in active mode, and random port number for all transfers, is why NAT firewalls and gateways have difficulty with FTP. HTTP is a stateless and multiplex control and data via a single connection from client to server on the famous port number, which trivially passes through the NAT gateway and is simple for managed firewalls.
Setting up the FTP control connection is pretty slow because the post delays send all the required commands and wait for the response, so it is customary to open the control connection and leave it open for some file transfers rather than drop and re-rearrange the session each time. Instead, HTTP initially dropped the connection after each transfer because it was so cheap. While HTTP then gains the ability to reuse TCP connections for multiple transfers, the conceptual model is still an independent query rather than a session.
When FTP transfers over a data connection, the control connection is idle. If the transfer is too long, the firewall or NAT may decide that the control connection is off and stop tracking it, effectively disconnecting and confusing downloads. A single HTTP connection is only idle between requests and it's normal and it is expected that the connection will be deleted after the time-out.
Web browser support
The most common web browsers can retrieve files that are hosted on an FTP server, although they may not support protocol extensions like FTPS. When FTP - not HTTP - URLs are provided, content that can be accessed on a remote server is presented in a manner similar to that used for other web content. A full-featured FTP client can be run in Firefox in the form of an extension named FireFTP.
Syntax
The FTP URL syntax is described in RFC 1738, fetching the form: ftp://[user [: password] @] host [: port]/url-path (the caged parts are optional).
For example, the URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txt represents the myfile.txt file from the mydile directory on the public server.ftp-servers.example.com as an FTP resource. The ftp://user001: secretpassword@private.ftp-servers.example.com/mydirectory/myfile.txt URL adds a user name and password specification that should be used to access this resource.
More details on specifying usernames and passwords can be found in the browser documentation (for example, Firefox and Internet Explorer). By default, most web browsers use passive mode (PASV), which is easier to traverse the end user's firewall.
Some variations already exist in how different browsers treat street resolution in cases where there is a non-root home directory for the user.
Security
FTP is not designed to be a secure protocol, and has many security flaws. In May 1999, the author RFC 2577 noted vulnerabilities to the following problems:
- Brute force attack
- FTP bounce attack
- Package retrieval
- Port steals (guesses next open port and seizes a valid connection)
- Spoofing attack
- Enumeration of usernames
FTP does not encrypt its traffic; all transmissions are in clear text, and user names, passwords, commands, and data can be read by anyone who can do packet sniffing on the network. This problem is common to many Internet Protocol specifications (such as SMTP, Telnet, POP and IMAP) designed prior to the creation of encryption mechanisms such as TLS or SSL.
Common solutions to this problem include:
- Use a secure version of an insecure protocol, for example, FTPS, not FTP and TelnetS, not Telnet.
- Uses different and more secure protocols that can handle jobs, e.g. SSH File Transfer Protocol or Secure Copy Protocol.
- Use secure tunnels like Secure Shell (SSH) or virtual private network (VPN).
FTP over SSH
FTP over SSH is a normal FTP session tunneling practice over a Secure Shell connection. Because FTP uses multiple TCP connections (unusual for TCP/IP protocols still in use), it is very difficult to tunnel SSH. With many SSH clients, trying to set the tunnel for the control channel (the initial client-to-server connection on port 21) will only protect that channel; when data is transferred, FTP software on both ends creates a new TCP connection (data channel) and thus has no protection of confidentiality or integrity.
Otherwise, SSH client software needs to have special knowledge of the FTP protocol, to monitor and rewrite FTP channel control messages and open new packet packages independently for FTP data channels. Software packages that support this mode include:
- Tectia ConnectSecure (Win/Linux/Unix) from SSH Communication Security software
Derivatives
FTPS
Explicit FTPS is an extension for the FTP standard that allows clients to request an encrypted FTP session. This is done by sending the command "AUTH TLS". The server has the option to allow or deny connections that do not ask for TLS. This protocol extension is defined in RFC 4217. Implicit FTPS is an outdated standard for FTP requiring the use of SSL or TLS connections. It was specified to use a different port than the regular FTP.
SSH File Transfer Protocol
The SSH file transfer protocol (chronologically the second of two abbreviated SFTP protocols) transfers files and has the same set of commands for the user, but uses the Secure Shell (SSH) protocol to transfer files. Unlike FTP, it encrypts both commands and data, preventing passwords and sensitive information from being transmitted openly over the network. Can not operate with FTP software.
Trivial File Transfer Protocol
Trivial File Transfer Protocol (TFTP) is a simple FTP key-step that allows clients to get files from or put files to a remote host. One of the main uses is in the early stages of booting from a local area network, because TFTP is very easy to implement. TFTP lacks security and most of the advanced features offered by the more powerful file transfer protocols such as File Transfer Protocol. TFTP was first standardized in 1981 and the current specification for protocols can be found in RFC 1350.
Simple File Transfer Protocol
Simple File Transfer Protocol (the first protocol abbreviated as SFTP), as defined by RFC 913, is proposed as a file transfer protocol (unsecured) with the level of complexity between TFTP and FTP. It was never widely accepted on the Internet, and is now assigned Historical status by the IETF. It runs through port 115, and often receives SFTP initialism. It has a command set of 11 commands and supports three types of data transmission: ASCII, binary and continuous. For systems with word sizes that are multiples of 8 bits, binary and continuous implementations are the same. This protocol also supports login with user ID and password, hierarchical folder and file management (including rename , delete , upload , download , download by overwriting , and download by adding ).
FTP command
FTP reply code
Below is a summary of the FTP reply code that can be returned by the FTP server. These codes have been standardized in RFC 959 by IETF. The reply code is a three-digit value. The first digit is used to indicate one of three possible outcomes - success, failure, or to indicate an incomplete error or replies:
- 2yzÃ, - Success replies
- 4yz or 5yz - Reply failed
- 1yz or 3yz - Incomplete Error or Answer
The second digit defines the error type:
- x0z - Syntax. This reply refers to a syntax error.
- x1z - Information. Reply to an information request.
- x2z - Connection. Replies refers to control and data connections.
- x3z - Authentication and accounting. Replies for login and accounting procedures.
- x4z - Not specified.
- x5z - The file system. This reply passes the status code from the file server system.
The third digit of the reply code is used to provide additional details for each category specified by the second digit.
FTP Server
Some popular open source FTP server implementations are:
- FileZilla Server (Windows)
- Pure-FTPd (Unix)
- VsFTPd (Unix)
- ProFTPd (Unix)
- CrushFTP (Mac, Win, Linux)
- Rumpus (Mac)
- WingFTP (Mac, Win)
See also
References
Further reading
- RFCÃ, 697 - CWD FTP Commands. July 1975.
- RFCÃ, 959 - (Standard) File Transfer Protocol (FTP). J. Postel, J. Reynolds. October 1985.
- RFCÃ, 1579 - (Informational) Firewall-Friendly FTP. February 1994.
- RFCÃ, 1635 - (Informational) How to Use Anonymous FTP. May 1994.
- RFCÃ, 1639 - More FTP Operations from Large Address Record (FOOBAR). June 1994.
- RFCÃ, 1738 - Uniform Resource Locators (URL). December 1994.
- RFCÃ, 2228 - (Standard Proposal) FTP Security Extension. October 1997.
- RFCÃ, 2389 - (Standard Proposal) Features a negotiation mechanism for File Transfer Protocol. August 1998.
- RFC 2428 - (Standard Proposal) Extensions for IPv6, NAT, and Extended passive modes. September 1998.
- RFCÃ, 2577 - (Information) FTP Security Considerations. May 1999.
- RFCÃ, 2640 - (Standard Proposal) Internationalization of File Transfer Protocols. July 1999.
- RFCÃ, 3659 - (Standard Proposal) Extension to FTP. P. Hethmon. March 2007.
- RFCÃ, 5797 - (Standard Proposal) FTP Command and Extension Registry. March 2010.
- RFC 7151 - (Standard Proposal) File Transfer Protocol HOST Command for Virtual Host. March 2014.
- FTP and Registry Commands IANA Extensions - The official registry of FTP Commands and Extensions
External links
- Communication Network/File Transfer Protocol in Wikibooks
- FTP Server Online Tester Authentication, encryption, modes, and connectivity.
Source of the article : Wikipedia
0 Comments