This page covers security-related topics for SFTP Gateway 3.0.
Files are encrypted in transit and at rest at all stages, beginning with the SFTP client and ending with S3.
The SFTP protocol is implemented by a Java service. SFTP traffic is encrypted in transit.
Files are not stored on the local Linux file system. Rather, files are stored in memory, and then moved to S3. For files larger than 5 MB, these are broken up into 5 MB chunks, and uploaded to S3 in parts.
Even though the SFTP files are not stored on disk, the EBS volume is encrypted anyway when using the CloudFormation template.
The Java service moves the files to S3 using the AWS SDK. The AWS SDK uses an API that is encrypted over HTTPS.
Finally, files are encrypted at rest on S3 with the default encryption
SFTP users are chrooted. The root of their file system is restricted to a specific path, limiting which directories they can traverse. This is commonly done to prevent SFTP users from seeing each other's files.
SFTP users are chrooted by default into
/users/username/ in the default cloud connection.
The chroot directory location is configurable.
This article covers chroot directories in more detail.
SFTP users can be configured with key-based authentication or passwords.
SFTP Gateway supports multiple SSH keys per user, which can be helpful for key rotation. A second key can be rotated in, and the first key disabled. This makes it easier to roll back if necessary.
Passwords must adhere to SFTP Gateway's password policy:
- At least 8 characters
- Mixed case
- At least 1 special character
This article discusses how to override the default password policy.
Key exchange algorithms
The OpenSSH protocol uses various key exchange algorithms and encryption ciphers to secure communication with the SFTP client.
Refer to this article to configure the baseline security level for hardening SFTP encryption algorithms.
Ports and protocols
The CloudFormation template configures ingress rules for the EC2 Security Group.
22 is open to the world. Under normal circumstances, you want to avoid this
pattern. However, this is by design for SFTP Gateway 3.0.
Java provides an SFTP service on port
22, so SSH connection attempts are denied.
Also, SFTP Gateway 3.0 lets you configure an IP range allow-list at the per-user level.
The SSH protocol has been moved to TCP port
2222. This should be locked down to
the IP address range of the system administrator. To connect, remember to use the
ssh -i private.key ec2-user@ip-address -p 2222
The web ports TCP
443 should also be locked down to the IP address
range of the system administrator. SFTP Gateway 3.0 has a first-launch web experience
where you can create the first administrator account.
The CloudFormation template locks down TCP ports
an IP address range provided via CloudFormation parameter. This is an important
step for locking down administrative areas.
Web admin accounts
The first time you launch SFTP Gateway 3.0, you configure the first administrator account on the web admin portal. Once logged in, you can create SFTP users and manage cloud connections.
You can create additional web admin accounts. Each administrator should be provisioned with their own account, so that their access can be revoked if necessary.
Additional web admin accounts are created with a one-time password which must be reset after first login.
SFTP audit logs are recorded in the log file
Refer to this article for more information on logging.
Since SFTP Gateway is deployed as a Marketplace image, you alone have access, and are responsible for patching the operating system.
The AMI is built from Amazon Linux 2, so you can patch the OS by running:
sudo yum update