• 06Nov
    Author: ned Categories: Security Comments: 0

    It’s kooky that some organizations are still using FTP for exchanging sensitive files.  Almost every security standard (and plain common sense) requires using encrypted data transfer, and with a great free solution in OpenSSH and WinSCP, there really is no excuse for FTP.

    This solution provides the following important security features:

    • Strong user authentication with DSA keys (almost two-factor authentication)
    • Complete segregation between users (using a chrooted jail)
    • Detailed activity logging
    • Uses time and industry-tested open source OpenSSH server software
    • Familiar “drag-n-drop” user interface thanks to WinSCP

    Read on for four easy steps to make it happen:

    1. Update your Linux server

    You’ll need a Linux system, ideally one that is dedicated to this task.  It should be protected by a network firewall, ideally located in a DMZ.  Access to the server should be limited to trusted IP addresses, if possible.

    Be sure to patch and harden this system!  At a minimum, make sure you’re running the latest versions of zlib, openssl, and openssh.  As of this posting, you should be at least at OpenSSL 0.9.8i and OpenSSH 4.7.  I usually build OpenSSH from source, so I can customize the SSH server’s version string to something like “OpenSSH_5.1-atrust”.  Do this by editing version.h.

    2. Configure OpenSSH for Chrooted Secure FTP

    Create a Unix group for all users who will be restricted to SFTP only (groupadd sftponly).  Then, harden the OpenSSH configuration file as normal (disable protocol 1, disable root login, setup a banner, configure logging, StrictModes, etc).  If you have a “Subsystem sftp” line, make sure it’s commented out:

    # Subsystem sftp /usr/libexec/sftp-server

    Now, add a line for the internal SFTP handler:

    Subsystem sftp internal-sftp

    Add configuration limiting restricting users in the sftponly group to SFTP:

    Match group sftponly
    	ChrootDirectory %h
    	X11Forwarding no
    	AllowTcpForwarding no
    	ForceCommand internal-sftp

    It is also important to increase the default logging level and turn off “last login time”.

    PrintLastLog no
    LogLevel VERBOSE

    Require DSA keys for additional security.  Rather than storing keys in home directories, we’ll store them in a more secure location:

    PasswordAuthentication no
    AuthorizedKeysFile      /etc/ssh/users/%u/authorized_keys2

    Note that in this setup all SSH keys will need to be managed by user with root privileges.  If you’d like certain users to be able to manage their own keys, make a soft link from their /etc/ssh/users/USERNAME directory to /home/USERNAME/.ssh, providing them access to their authorized_keys2 file.

    Restart OpenSSH so your config changes take effect.

    3. Setup a user

    First, create a Putty SSH DSA keypair – you’ll need to this step on a Windows box.  Download PuTTYGen and use it to generate a new “SSH-2 DSA” keypair.  Save both the private and public keys for later – you’ll need them both – make sure you keep track of which is the private key (ending in .ppk) and which is the public key.  Be sure to set a strong passphrase!

    Back on the Linux server, create the new user’s account.  Add a new user that is a member of the sftponly group and as their shell set to /bin/false (so they can’t login interactively).  In these examples, the new user’s name is Elvis:

    sudo useradd -g sftponly -s /bin/false -d /home/elvis elvis
    sudo chown root /home/elvis

    Their home directory has to be owned by root for the chroot stuff to work – if you want them to have write permissions, you’ll need to create a subdirectory and give them write permissions:

    sudo mkdir /home/elvis/upload
    sudo chown elvis /home/elvis/upload

    Upload the user’s SSH DSA public key to the server (save it to say /tmp/userpublickey). Once it’s on the server, import it into OpenSSH format and set file/folder permissions correctly.  Getting the permissions right is important:

    sudo mkdir -m /etc/ssh/users/elvis
    sudo ssh-keygen -i -f /tmp/userpublickey > /etc/ssh/users/elvis/authorized_keys2
    rm /tmp/userpublickey
    sudo chown -R elvis /etc/ssh/users/elvis
    sudo chmod -R 700 /etc/ssh/users/elvis

    Test, test, test! Test logins, downloads and uploads. Make sure the chroot is working and that you can’t see the rest of the filesystem when logged in via SFTP. Check that successful and unsuccessful logins are being written to a log file. Document your configuration.

    Be sure to setup a different user for each human being or automated process that will be uploading or downloading files – no sharing!

    4. Help the user get up and running

    You will need to send the private key file (id_dsa) to the user and tell them their passphrase over the phone.  The user will need to save their private key file to their local computer, download and install WinSCP, and configure their WinSCP session.  Your directions to the user might look something like:

    Hi Elvis, 
    
    The server we'll be using for exchanging large files is ready.  You'll need to follow
    these instructions to set up your access the first time.  Don't hesitate to give me
    a call if you run into any problems!
    
    a) You'll need to save the "elvis-key.ppk" file to your hard drive
    b) Download and install "WinScp" from here:
    
    http://winscp.net/download/winscp417setup.exe
    
    c) Launch WinSCP, click "New" to create a new session, enter:
            Host name: secure.barkingseal.com
            User name: elvis
    d) Click on "Private key file", select the "elvis-key.ppk" file.
    e) Click Login.
    f) The first time you login, you'll get a warning about the "server's host key".  It's
    safe to click "Yes".
    g) You'll be promped to enter your passphrase (left this on your voicemail).
    h) Once you're logged in, you can upload and download files by dragging them to/from
    the WinSCP window.

    That’s it!  You’re ready to securely exchange some files!  Remember to audit your activity logs regularly and disable user accounts when they’re no longer needed.

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Technorati] [StumbleUpon]

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.