The following example if based around FTPing from a MS-Windows client (where
the webpages are written prior to uploading) to a UNIX based web-server.
Please note that in some situations the FTPD deamon may not allow the sending of the
data to a separate IP address (in ProFTPD -
use the AllowForeignAddress on directive - but
this is not the thing to enable on an Anonymous FTP account area as then the server could be
used for hacker bounce scanning by people logging anonymously into the system).
Work is still on-going into the naunces of this as many FTP client/server
combinations can behave quite erratically(?)
Relevant pages:
Information on new FTP specifications (not implemented in many FTPD servers yet):
SafeTP operates by installing a transparent proxy in the Windows networking stack which detects outgoing FTP connections from any windows FTP client, and silently secures them using modern cryptographic techniques (the server must also support SafeTP in order for a secure connection to be succesfully established). SafeTP is 100% compatible with existing (insecure) FTP servers, and will operate in an insecure mode if the server does not yet support the SafeTP protocol. One key feature of the SafeTP client proxy is that it was designed to be completely transparent to the client FTP application. This way, users can reap the benefits of FTP security, while continuing to use their existing FTP software."
Something to keep in mindAttempting to tunnel the data port as well can be problematic with some systemsDate: Mon, 22 Nov 1999 16:56:22 +0000 (GMT) From: The Flying Hamster [[email protected]] cc: [email protected] Subject: Re: [ProFTPD] sniffable passwords on linux and freebsd3.3-stable On Mon, 22 Nov 1999, Leho Kraav wrote: > On Mon, 22 Nov 1999 12:16:33 +0100 (MET), you -> about "Re: [ProFTPD] sniffable > passwords on linux and freebsd3.3-stable": > > >The only caveat is that this only works for ftp clients that support > >ftp-sessions over *one port only*. If I don't mix it up that's called > >passive ftp, where active ftp opens one port for control and one for data. > > AFAIK, that is incorrect. FTP works over two ports, in passive and in active > mode. Passive mode is when the FTP server is set to listen for the client to > specify the data connection port, so that the firewalls would let the data > through on that port. In normal operation, FTP server sends the client > information on what port to listen to. [few minutes reading later...] Passive Mode connections work the same way as normal (Active Mode) connections, except the data connection is also made from the client to the server ie made to port ftp-data (20). This avoids the problem of incoming data connections being blocked by the firewall by making both connections from the client. What it boils down to is Active control channel, port 21 data channel, server specifies random port. Passive control channel, port 21 data channel, port 20 I guess it's doc time :) Mark -- This is a sig, it's not a smart sig or an AI sig, but it's a sig to replace the sig that died during the death of data... the sig is dead, long live the sig |
Install teraterm for Windows (easy to do and it runs via a setup program)
Install the tssh secureshell plugin for Teraterm. (download the zip file and extract the files into the teraterm directory)
|
Install teraterm for Windows (easy to do and it runs via a setup program)
Install the tssh secureshell plugin for Teraterm. (download the zip file and extract the files into the teraterm directory)
|
This might be a good time to customise teraterm and have the screen
font, size, list of machines you commonly connect to, etc that can make
you happy. Select setup, save setup to save these as the defaults.
(it is also possible to manually edit the teraterm.ini file in the
teraterm executable directory if you wish)
|
Now to setup the Port Forwarding that allows FTP to go
via the Secure Shell port.
Go into the Setup, SSH Forwarding whereby you should see the following window ready to have the relevant information inserted into it.
|
Now we want to tell it to forward/tunnel the ftp control port (port 21) (using
connecting to the www.ccp14.ac.uk server as an example) by
adding the ftp control port and the machine we wish to ftp to in
the Forward Local Port (port 21) area of the window.
This gives the following SSH Forwarding setup that we should save as a Teraterm default by doing Setup, Save Setup and select the teraterm.ini file.
|
Now go into your favourite Windows FTP client (in this case WS_FTP)
and setup a new "secure" login. The machine you are logging into is
127.0.0.1 (localhost). Don't worry if this seems a bit weird,
once you are logged in via Secureteraterm, Teraterm will handle everything.
Also tell the FTP client to work in passive mode. If you do not do this, you will still be able to log in, but not transfer data. Also, the FTP server that you secure login to will be under the impression that you are logging in from itself. Thus check that the host-allow/host-deny will allow ftp logins from itself! (sounds silly but this can be left out in the FTP Deamon configuration)
|
Now use the SecureShell function in teraterm to Secure Login to the
FTP server you wish to transfer files to/from.
Run your FTP program - and you should now be happily secure FTPing data without the ability to sniff the password. Providing your network policy allows this, use a sniffer to check that the FTP connection is going via the secure channel. The following Sniffit for Windows is a good program to use to check this (using sniffit -i (interactive mode)).
If you have problems connecting, checking the FTPD server logs can be a good first start in trouble shooting. It could be the setup is correct but you have used the wrong password. |
Some of this may be non-optimal so be a bit wary and shop around a bit.
This is working quite nicely for me at the moment but could give problems
if the "random" ports you use could be in use by other programs such as
the web-browser(?). Going into a DOS prompt and typing netstat
can tell you what ports are being used at the current time. Again, this
webpage is no substitute for thinking for yourself.
|
Now to setup the Port Forwarding that allows FTP to go
via the Secure Shell port.
Go into the Setup, SSH Forwarding whereby you should see the following window ready to have the relevant information inserted into it.
|
Now we want to tell it to forward/tunnel the ftp local control via a
user definable port. In theory, something above Port 1024 (though I could be thinking
in UNIX mode here - where as Windows does not care that much?) (in this case, a random number, say
1227). In Forward Local Port, manually type 1227.
If you wish, you can also add in other FTP servers that you wish to secure shell into using a different port. (e.g., to doobry.ccp14.ac.uk via port 1228). This gives the following SSH Forwarding setup that we should save as a Teraterm default by doing Setup, Save Setup and select the teraterm.ini file.
|
Now go into your favourite Windows FTP client (in this case WS_FTP)
and setup a new "secure" login. The machine you are logging into is
127.0.0.1 (localhost). Don't worry if this seems a bit weird,
once you are logged in via Secureteraterm, Teraterm will handle everything.
Also tell the FTP client to work in passive mode and the port you are using. In the following case we are using port 1227. If you do not do this, you will still be able to log in, but not transfer data. Also, the FTP server that you secure login to will be under the impression that you are logging in from itself. Thus check that the host-allow/host-deny will allow ftp logins from itself! (sounds silly but this can be left out in the FTP Deamon configuration)
|
Now use the SecureShell function in teraterm to Secure Login to the
FTP server you wish to transfer files to/from.
Run your FTP program - and you should now be happily secure FTPing data without the ability to sniff the password. Providing your network policy allows this, use a sniffer to check that the FTP connection is going via the secure channel. The following Sniffit for Windows is a good program to use to check this (using sniffit -i (interactive mode)).
If you have problems connecting, checking the FTPD server logs can be a good first start in trouble shooting. It could be the setup is correct but you have used the wrong password. |
From: "Christopher Spry"
Possible solution to the above: use method 2 described above. |