FTP - Active & Passive Mode

It gives more reason to update, if someone reads n comments on the blog. So updating the blog henceforth with the useful links i find.

Read below to know the difference between the Active FTP and Passive FTP :

FTP Basics :

FTP is a TCP based service exclusively. There is no UDP component to 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.

Active FTP:

In active mode FTP 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.

From the server-side firewall's standpoint, to support active mode FTP the following communication channels need to be opened:

* FTP server's port 21 from anywhere (Client initiates connection)
* FTP server's port 21 to ports > 1023 (Server responds to client's control port)
* FTP server's port 20 to ports > 1023 (Server initiates data connection to client's data port)
* FTP server's port 20 from ports > 1023 (Client sends ACKs to server's data port)

The main problem with active mode FTP actually falls on the client side. The FTP client doesn't make the actual connection to the data port of the server--it simply tells the server what port it is listening on and the server connects back to the specified port on the client. From the client side firewall this appears to be an outside system initiating a connection to an internal client--something that is usually blocked.


Passive FTP:

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. 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.

From the server-side firewall's standpoint, to support passive mode FTP the following communication channels need to be opened:

* FTP server's port 21 from anywhere (Client initiates connection)
* FTP server's port 21 to ports > 1023 (Server responds to client's control port)
* FTP server's ports > 1023 from anywhere (Client initiates data connection to random port specified by server)
* FTP server's ports > 1023 to remote ports > 1023 (Server sends ACKs (and data) to client's data port)

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. Fortunately, many FTP daemons, including the popular WU-FTPD allow the administrator to specify a range of ports which the FTP server will use.

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.

For examples please follow the link::

http://slacksite.com/other/ftp.html

Protocol RFC : http://www.faqs.org/rfcs/rfc959.html

What exactly is TCP Splicing

I will put down my own words for the TCP Splice sometime later, when I have more time to give it a thought. For now, I have a good link which explaing about it for any Web Proxy device.

http://www2002.org/CDROM/refereed/627/

Diff between SSH SSL

SSH (Secure Shell) and SSL (Secure Sockets Layer) can both be used to secure communications across the Internet. This page tries to explain the differences between the two in easily understood terms.

SSL was designed to secure web sessions; it can do more, but that's the original intent.

SSH was designed to replace telnet and FTP; it can do more, but that's the original intent.

SSL is a drop-in with a number of uses. It front-ends HTTP to give you HTTPS. It can also do this for POP3, SMTP, IMAP, and just about any other well-behaved TCP application. It's real easy for most programmers who are creating network applications from scratch to just grab an SSL implementation and bundle it with their app to provide encryption when communicating across the network via TCP.

SSH is a swiss-army-knife designed to do a lot of different things, most of which revolve around setting up a secure tunnel between hosts. Some implementations of SSH rely on SSL libraries - this is because SSH and SSL use many of the same encryption algorithms (i.e. TripleDES).

SSH is not based on SSL in the sense that HTTPS is based on SSL. SSH does much more than SSL, and they don't talk to each other - the two are different protocols, but have some overlap in how they accomplish similiar goals.

SSL by itself gives you nothing - just a handshake and encryption. You need an application to drive SSL to get real work done.

SSH by itself does a whole lot of useful stuff that allows users to perform real work. Two aspects of SSH are the console login (telnet replacement) and secure file transfers (ftp replacement), but you also get an ability to tunnel (secure) additional applications, enabling a user to run HTTP, FTP, POP3, and just about anything else THROUGH an SSH tunnel.

Without interesting traffic from an application, SSL does nothing. Without interesting traffic from an application, SSH brings up an encrypted tunnel between two hosts which allows you to get real work done through an interactive login shell, file transfers, etc.

Last comment: HTTPS does not extend SSL, it uses SSL to do HTTP securely. SSH does much more than SSL, and you can tunnel HTTPS through it! Just because both SSL and SSH can do TripleDES doesn't mean one is based on the other.

http://www.rpatrick.com/tech/ssh-ssl/

http://www.webopedia.com/TERM/S/SSL.html
a protocol

http://www.webopedia.com/TERM/S/SSH.html
a program for remote login

http://www.webopedia.com/TERM/T/TLS.html
a protocol