Azure Security Notes
Note: This page applies to SFTP Gateway version 2.x. Visit Here for documentation on version 3.x.
Overview
This page covers some security related topics. SFTP Gateway has some built-in controls for securing SFTP users. Beyond this, you want to follow some best practices for restricting access to specific ports on the VM. And finally, it helps to know the services and scripts that are involved with copying files to Blob.
Securing the SFTP protocol
For SFTP Gateway, here is a list of security features that are implemented:
- We rely on OpenSSH's default SFTP implementation, so traffic is encrypted in transit via OpenSSH.
- There's a few default customizations in the configuration file
/etc/ssh/sshd_config
:- One such configuration is that SFTP users are restricted to the SFTP protocol, denying them SSH access
- Another configuration is that SFTP users are chrooted into a folder nested within their Linux home directory, as an added measure to prevent traversal
- Another configuration is that SFTP users log in with key based authentication by default. This is to address issues inherent with passwords (complexity requirements, and that fact that they are sent over the wire)
- SFTP users have their default shell removed, which is another measure to prevent SSH
Securing VM ports in Azure
Other features are inherent to Azure in general, and not specific to SFTP Gateway:
- When moving files to Blob, this layer of traffic is encrypted in transit using HTTPS. This is because we use the Azure CLI, which behind the scenes uses a REST API.
- When files are stored in Blob, they are encrypted at rest by default.
- VM disks have encryption enabled by default. So, this will cover files that are stored on disk and waiting to be copied to Blob. Disk encryption is not configured via SFTP Gateway -- rather, this is configured in the Azure Portal, so remember to verify disk encryption settings during VM launch.
- As a best practice, VMs should be protected by the NSG, which acts as a host based firewall. Traffic on port 80 and 443 should be restricted to the SysAdmins who are managing users. Traffic on port 22 should be restricted to SFTP users.
- Since we're using the default OpenSSH implementation, you should consider moving SSH traffic to port 2222, and leave SFTP traffic on port 22. This way, you can further restrict port 2222 to your SysAdmins. And then leave port 22 (SFTP only) to a whiltelist of SFTP users.
Moving files to Blob and the incron service
There's a service we use called incron. This operates like cron, but instead of emitting events based on time, it emits events based on file events. When a file is saved and closed, we look for this event and use this as an indication that a file is ready to be uploaded to Blob.
The incron service triggers a script (written in Bash, but compiled) called movetos3
(the naming convention is a carry-over from our original product on AWS). The movetos3
script performs a number of checks, and then runs the following command:
az storage blob --container-name ${container} --file "${fullpath}" --name "${destinationpath}" --account-name ${accountname} --account-key ${accountkey}
Here is the Azure documentation for using the Azure CLI syntax for this command: https://docs.microsoft.com/en-us/cli/azure/storage/blob?view=azure-cli-latest
Audit logging
New with SFTP Gateway 2.001.00, SFTP audit logging is enabled by default. You can now
view SFTP related activity in the file /var/log/secure
.
VM image hardening
SFTP Gateway is a VM image on the Azure marketplace. This VM is built on a standard CentOS 7 image. This means there is no extra hardening performed on this image, such as CIS.