FTP is more difficult to secure than other protocols because it uses two connections: a control connection where the commands are sent, and a data connection for sending the data between the source and destination system. Depending on whether active or passive mode is being used, the data connection can be established from the receiver to the sender or from the sender to the receiver. There are also some interesting vulnerabilities in the FTP protocol design which are present in nearly all FTP implementations. [Note that these are problems in the protocol design, and not implementation bugs, so they can’t be fixed.]
webMethods does not include secure FTP support in the base product. The reason is simple: there’s no standard. Some people use the term “secure FTP” to mean using a secure transport like “FTP over SSL” or “FTP over SSH”. Others mean sending encrypted data over an FTP connect, like “S/MIME over FTP” or “PGP over FTP”. None of these are interoperable, and all require that both sides of the communication agree in advance on which method will be used. Further, there are even residual risks in some of these alternatives: for example, sending S/MIME over FTP protects the data, but still sends the username and password unencrypted.
webMethods discourages use of FTP for customers who are concerned about security, due to the intrinsic problems in the FTP protocol. If that’s impractical, webMethods recommends using a VPN to protect FTP traffic. VPNs are interoperable (thanks to IPsec), and can be configured to provide protection for both the data and control streams.
If this is inadequate, custom solutions can be developed, depending on the risk tradeoffs and compatibility requirements (e.g., SSL vs. SSH vs. S/MIME vs. PGP vs. a proprietary solution such as the one identified).
#Integration-Server-and-ESB#webMethods-General#webMethods