Securing FTP on the Internet

File transfer security is important when transferring files across the Internet. One of the often overlooked areas, when addressing layered security, is file transfer security. Some companies (including Internet Service Providers) seldom make the switch, in a timely manner, to replace File Transfer Protocol (FTP) clients with a secured solution such as Secure FTP (SFTP) and a Secure Shell (SSH2) Server. Other companies replace Telnet servers with SSH servers, but do not address file transfer security. Then there are companies that implement SFTP with an SSH2 Server, and overlook users that utilize FTP clients for file transfers in other areas. This article provides the answers that you will need to configure and operate an SFTP client (SecureFX) with an SSH2 Server (WinSSHD) –securely.

When was the last time that confidential data was delivered over a standard non-secure transfer program, such as an FTP client, in your company or over the Internet?

Companies sending sensitive files over a network – unencrypted and unprotected – may find it more difficult to establish secure transfers and an overall sense of ‘real’ data security. File transfers that use the standard File Transfer Protocol (FTP) are susceptible to eavesdroppers, and can greatly benefit from the high level encryption ciphers and security that SSH2 protocol offers. By implementing an SFTP client with an SSH2 Server organizations can expect to achieve an effective level of file transfer security.

Transferring files (manually or automatically) can be done without security, however, with the availability of SSH2 – and the ease of setup of an SFTP client and an SSH2 server – confidential file transfers no longer have to be exposed to unwanted network solicitors. Let’s begin to secure your file transfers by configuring an SFTP client and SSH2 server. In this case we’ll use SecureFX by Vandyke Software (www.vandyke.com), and WinSSHD Server by Bitvise Products (www.bitvise.com).

NOTE: It is important to note that the hands-on tips included in this article (as with other articles I have written) have been fully tested in a live production environment that supports many users and file transfer requirements.

The SecureFX client requires SSH2 (I’ll describe SSH2 later) utilizes an interface similar to Windows Explorer, is quickly configurable with password authentication and public key support, and works very well with WinSSHD Server to establish a ‘real’ sense of security moving forward. A 30-day evaluation copy of SecureFX is available and can be downloaded at http://www.vandyke.com/download/securefx/index.html.

If budget constraint is an important issue, then check out www.openssh.org for free SSH clients, such as WinSCP (secure copy with PuTTY) and Secure iExplorer GPL (another Explorer-like interface), for the Windows platform. However, keep in mind that some free clients – as is the case with some third-party clients – may only be compatible with SSH1 and not SSH2 protocol. SSH2 provides improvements over SSH1 and both versions protect sensitive data in file transfers by utilizing strong cryptography that is difficult to hack. Although SSH is typically used to address the security issues of telnet, remote shell (rsh), and remote login (rlogin), standard non-secure transfer programs can benefit from SSH2.

The combination of password and public key authentication (private / public key pair) using digital signatures – per account or shared key among trusted hosts – enable host-to-host encrypted connections over an insecure infrastructure, such as the Internet. However, depending on the size of the organization, it is important to plan ahead and determine the number of public keys that will be supported by the SSH2 server. For example, WinSSHD Server can be configured to require 1) a password or key, and 2) a password and key combination for authentication. But rather than generate a key from every host and then register the key on the WinSSHD Server, you can copy the private / public key pair and distribute the key pair to a group of trusted hosts. Unlike the private key, which is stored on the host side only, the public key is uploaded to the WinSSHD Server, and is stored on both the host, and on the server; the server acknowledges the public key, once uploaded and assigned to a specific login account. If supporting both password and key authentication, the client must be configured to match the authentication set on the WinSSHD Server.

SecureFX (SFTP Client)

Consider changing the default SSH2 port 22 to a unique port (refer tohttp://www.iana.org/assignments/port-numbers for a 5 digit port number) on the SFTP client and SSH2 server. Create a new session by going to File>Connect and then selecting the New Session Wizard. Choose SFTP for Protocol, enter the Host IP address of the WinSSHD Server, and replace port 22 with a unique port.

Next, enter the username and password created on the WinSSHD Server – the username is an account that exists locally on the server. The Initial Directory and other connection settings can be overwritten by the configuration set on the WinSSHD Server. Right-click on the newly created session and select Properties.

Next, confirm that Protocol, Hostname, Port, and Username reflect your input. (Note that password is set for primary authentication; secondary authentication is set to none, by default. We will revisit this section later on.) Go to Category>Site>SSH2 Options and confirm that “None” is NOT selected for Cipher or MAC. Now, double-click on the new session to authenticate to the WinSSHD Server using password. Upon contacting the server, you will receive a New Host Key message box. Click on the Accept & Save button to accept the host key (e.g., MD5 hash fingerprint) from the server.

At this time, you should be able to log in using password authentication. If you receive an error: “Unable to authenticate using any of the configured authentication methods,” it is most likely due to the setting “PWD and Key” in WinSSHD Server (see below) – in which case, you will need to change the SFTP client authentication to “Password and Key”, to match the authentication requirements of the server. Now let’s create the public-key that will be copied up to the WinSSHD Server. To generate a new public / private key pair, go to Tools>Create Public Key to launch the Key Generation Wizard. Select DSA For Key type, enter a Passphrase, and then select 1024 bits (minimum recommended strength) for Key length. Next, move the mouse around to create random input for the key generation process. Name the private key and note the default location for both keys (the public key has the suffix .pub):

C:Documents and Settings<username>Application DataVanDykeSecureFX<FILE>

Use the key as global public key. The public key is now available and can be copied up to the WinSSHD Server; only the public key will need to be copied to the server, the private key will be stored on the SFTP client (host). If the public key will be shared, then copy the key pair and store the files in the above path on the other hosts. Instead of generating a key next time, go to Category>General>Options>SSH2 and then load the public key (do not attempt to load the private key, this key has to be present with the public key in the same folder.) If the public key will not be shared, then generate a public key on each host and then assign the key on the WinSSHD Server to the user account. After you have copied the public key to the WinSSHD Server and assigned the key to an account, go back to File>Connect and select Properties on the recently created session. In Site, change the Secondary Authentication from none to Public Key, and click on the Properties button. Select the newly created public key (that was previously copied up to the WinSSHD Server). Make sure that you have stored the public key in the appropriate folder on both the SFTP host and the WinSSHD Server. WinSSHD Server In WinSSHD Control Panel, click on the Edit/View Settings button in the Settings tab, and change the default SSH2 port 22 to a unique port (refer to http://www.iana.org/assignments/port-numbers for a 5 digit port number). Next, go to Settings>Access Control>Template and set the following:

Permit Remote Administration = No Map Remote Home Directory = No Permit Terminal Shell = No Terminal Shell = C:Program FilesBitvise WinSSHDsftps.exe Initial Directory = C:<unique folder name> Permit Exec Requests = No Permit C2S Port Forwarding = No Permit S2C Port Forwarding = No

Drop down to the Accounts section and deny “all others” from authenticating to WinSSHD. Enter a local Win2K/NT account, and change the Authentication Type to “PWD and Key”. Except for SFTP, everything else on the account should be set to no. Click on the Keys field for the account that will use the public key (the one created on the SecureFX client), and import the key.

Stop and Start the WinSSHD service.

Note: Use caution when using PuTTY as there have been reported bugs, such as no limits on socket buffering and issues with SCP.

Congratulations! You have configured an SFTP client and an SSH2 server.

Original page here

proftpd – setting up a quick ftp server

This was created off of:

yum -y install proftpd.x86_64

echo “/bin/false” >> /etc/shells

cd /home
sudo mkdir FTP-shared
sudo useradd userftp -p your_password -d /home/FTP-shared -s /bin/false
sudo passwd userftp
cd /home/FTP-shared/
sudo mkdir download
sudo mkdir upload
cd /home
sudo chmod 755 FTP-shared
cd FTP-shared
sudo chmod 755 download
sudo chmod 777 upload
cp /etc/proftpd.conf /etc/proftpd.conf.orig
vi /etc/proftpd.conf
  • # To really apply changes reload proftpd after modifications.
    AllowOverwrite on
    AuthAliasOnly on
    
    # Choose here the user alias you want !!!!
    UserAlias sauron userftp
    
    ServerName			"ChezFrodon"
    ServerType 			standalone
    DeferWelcome			on
    
    MultilineRFC2228 on
    DefaultServer			on
    ShowSymlinks			off
    
    TimeoutNoTransfer 600
    TimeoutStalled 100
    TimeoutIdle 2200
    
    DisplayChdir                    .message
    ListOptions                	"-l"
    
    RequireValidShell 		off
    
    TimeoutLogin 20
    
    RootLogin 			off
    
    # It's better for debug to create log files ;-)
    ExtendedLog 			/var/log/ftp.log
    TransferLog 			/var/log/xferlog
    SystemLog			/var/log/syslog.log
    
    #DenyFilter			\*.*/
    
    # I don't choose to use /etc/ftpusers file (set inside the users you want to ban, not useful for me)
    UseFtpUsers off
    
    # Allow to restart a download
    AllowStoreRestart		on
    
    # Port 21 is the standard FTP port, so you may prefer to use another port for security reasons (choose here the port you want)
    Port				1980
    
    # To prevent DoS attacks, set the maximum number of child processes
    # to 30.  If you need to allow more than 30 concurrent connections
    # at once, simply increase this value.  Note that this ONLY works
    # in standalone mode, in inetd mode you should use an inetd server
    # that allows you to limit maximum number of processes per service
    # (such as xinetd)
    MaxInstances 8
    
    # Set the user and group that the server normally runs at.
    User                  nobody
    Group                 nobody
    
    # Umask 022 is a good standard umask to prevent new files and dirs
    # (second parm) from being group and world writable.
    Umask				022	022
    
    PersistentPasswd		off
    
    MaxClients 8
    MaxClientsPerHost 8
    MaxClientsPerUser 8
    MaxHostsPerUser 8
    
    # Display a message after a successful login
    AccessGrantMsg "welcome !!!"
    # This message is displayed for each access good or not
    ServerIdent                  on       "you're at home"
    
    # Lock all the users in home directory, ***** really important *****
    DefaultRoot ~
    
    MaxLoginAttempts    5
    
    #VALID LOGINS
    <Limit LOGIN>
    AllowUser userftp
    DenyALL
    </Limit>
    
    <Directory /home/FTP-shared>
    Umask 022 022
    AllowOverwrite off
    	<Limit MKD STOR DELE XMKD RNRF RNTO RMD XRMD>
    	DenyAll
    	</Limit>
    </Directory>
    
    <Directory /home/FTP-shared/download/*>
    Umask 022 022
    AllowOverwrite off
    	<Limit MKD STOR DELE XMKD RNEF RNTO RMD XRMD>
    	DenyAll
    	</Limit>
    </Directory>
    
    <Directory /home/FTP-shared/upload/>
    Umask 022 022
    AllowOverwrite on
    	<Limit READ RMD DELE>
          	DenyAll
        	</Limit>
    
        	<Limit STOR CWD MKD>
          	AllowAll
        	</Limit>
    </Directory>

You can do a syntax check with the following:

proftpd -td5