...
- LSST operated advanced FTP service
- vsftp server software: very secure, high performance, restartable transfers, private ftp-only accounts
- installed and running on LSST service VM (VM is "SCS Standard")
- New FTP server is configured to have ownership privs on a single NFS partition: /nfs/farm/g/lsst/u2 (which will be a short-term buffer from which a permanent archive will be made)
- Individual vsftp accounts for Vendors A and B.
Potential Security Issues and Mitigations (not complete!!)
- Hacking into a vendor account
- Possible consequences
- loss or corruption of vendor data
- use of storage for illicit purposes
- interruption of vendor data deliveries
- load on "u2" server (currently wain006)
- Possible consequences
- Hacking into the vsftp server
- Is this likely?
- Hacking into the lsstlnx VM
- Probably independent of vsftp and, therefore, no different from other VMs at SLAC
Why Existing FTP Service is Unacceptable
- Non-anonymous (s)FTP requires a SLAC unix account and that has been deemed unacceptable by LSST project team
- Anonymous FTP server suffers from several shortcomings:
- The server software cannot restart an interrupted data transfer
- The AFS-backed store is possibly not scalable to the hundreds of GB needed
- The 3-day dwell period is too risky for the data
- The AFS permissions combined with the 3-day swell do not allow for the type of permissions that would allow a convincing separation between the two vendor's data
- The dropbox does not allow for vendor management of its data at SLAC
...