As there are two questions about Passive vs. Active FTP mode
Passive FTP instead of Active FTP
What is the difference between active and passive FTP?
And if we kindly omit existence of FTP over SSH or FTPS (aka FTP with SSL/TLS)
What are security pros and cons of using Passive FTP?
My question comes out from experience that nearly every FTP I've came to touch with, was using Passive mode. So if it wasn't result of internal security policy, than please what is the motivation for using Passive FTP mode?
FTP is not secure, and never will be. The only reason to use passive ftp is that it works through any kind of firewall, as all connections are initiated by the client. Active FTP has the server connecting BACK to the client to initiate data transfers, which dumb firewalls will disallow, as they have no way to know that the incoming connection is related to the FTP connection and should be allowed through.
Passive FTP is easier to get through firewalls. For "active" FTP, the client has to be connectable from the internet, for passive ftp, that burden is on the server.
Related
Is ftp connection to secure server in c++ program secure with libcurl?I need to make a client program that will receive and write data to the host.
FTP is insecure, it transfers data, user names & passwords in the clear. Don't use it. Use either https, scp or sftp.
As I understand it, active and passive mode in FTP changes the port on which commands and data are sent from the client to the server which can be useful where firewalls are concerned. I think I'm also right in saying that SFTP doesn't have the same concept - but I'm not clear what nuances of the SFTP protocol make it unnecessary/undesirable to mimic that same pattern that exists in FTP.
Active/passive mode distinction in FTP protocol is needed, because in FTP, there's a separate transfer channel/connection for file transfers. And in different network setups, a different mode might be needed (though nowadays, mostly passive mode it used).
It's not useful where firewalls are concerned, it's a problem where firewalls are concerned. This concept of a separate connection on a separate port was probably not a good idea, as I do not think that this model was ever repeated again in any other similar protocol. Wikipedia FTP article mentions that FTP was designed this way because originally it was not intended to operate over TCP/IP (FTP originated in 1971).
In SFTP, there's nothing like that. All happens within one connection. So there are no problems "where firewalls are concerned".
so the case is: Client is in ftp session with server and how could i corrupt the connection so user would have to reconnect again? I'm thinking about blocking the clients ftp port, how could i accomplish that?
Simple thing to do is to add and enable a firewall rule from the Control Panel. You can even do it programmatically with the Windows Firewall API including from script.
I have setup a windows 2003 ftp server and using chilkat to connect to this ftp inside my customized application. My application is developed in VB6 with ftp support of chilkat. The application works on different places of the city and connects to my ftp. Unable to access ftp and transfer files using the customised application, from some networks like idea netsetter / bsnl. It works perfect on other networks.
Thanks in advance.
Regards,
Sam
This is likely to be a firewall issue at the client end. FTP is often blocked by firewalls.
Just as well, FTP has its problems making it a less than ideal alternative. There are better options such as SFTP or FTPS but support for those is limited in Windows and you'll have to buy both server and client pieces to use one of them.
Fewer firewalls block HTTP and HTTPS though some are finicky enough to block traffic that doesn't look like Web browsing. Stiil, your odds of success go up substantially.
An obvious choice might be to use WebDAV. IIS supports WebDAV and it is pretty easy to write simple WebDAV client logic in VB6 based on one of the many HTTP components available. I'd probably use XmlHttpRequest or WinHttpRequest for that. A search ought to turn up several VB6 classes written to wrap one of them to support WebDAV client operations. You can also buy WebDAV client libraries.
Stick to using HTTPS (which means you need a server cetificate for IIS) and you won't have passwords going over the network in the clear. Even if you use HTTP you'll be no worse off than using FTP, plus it'll work through the vast majority of firewalls except those that specifically block non-browsing HTTP requests.
This could be a firewall configuration on the Client or Server. You're not going to be able to do much about the client, but for the server it may depend on whether your doing Active or Passive FTP connections.
If you are doing Active connections, make sure ports 20 and 21 are open.
If you're doing Passive connections, you may want to check out this article about configuring the PassivePortRange in Server 2003 FTP- http://support.microsoft.com/?id=555022.
F
Is there a way to monitor the FTP port so that I can know what commands my FTP application is sending to a FTP server?
I am using a closed-source FTP client application, which is not working with a closed-source FTP application server. The client and the server are not communicating well with each other, and I would like to find out why. I wish to reverse-engineer the client to see what commends the client are sending to the sever. I used a web test tool before that allowed me to monitor the content transferring through HTTP, but I can't seem to find such tool for FTP. I appreciate it if you can help me out, thanks.
Sounds like you need a packet sniffer - assuming your network admins/company policy allows it...I have used wireshark fairly successfully before.
The core FTP commands should be visible in the packets.
You can use the Wireshark application: http://www.wireshark.org/
It should have decent parsing capabilities for FTP as well as other protocols.
Can you configure a proxy with the client? Then you could install an ftp proxy server using the logging on that to see what's going on?
There's a proxy server for Linux here: http://frox.sourceforge.net/doc/FAQ.html
Paul.
Do you have access to ftp-server logs? Its likely those commands would be logged there.
If they aren't, your next option would be to configure the server to log them, if you have access.
If thats not an option or server does not log such things, then you have to go to either packet sniffer or a proxy, as suggested by previous posters.
On Unix, tcpdump might be your friend. Maybe you should first state which OS you're targeting, though.
If you have the ability (often requiring root access) to use a packet sniffer, tcpflow sniffing the TCP control channel will show you the commands and responses going back and forth in an easy-to-read format.
If you don't have such access, tools such as ktrace and strace will allow you to see all data read and written on the socket for this connection, though it will be a little work to extract it.
If you could tell us just what tool you were using for HTTP traffic, that would allow us to look for something similar for FTP traffic.