...
- LSST operated advanced FTP service
- vsftp server software: very secure; high performance; restartable transfers; virtual ftp-only accounts
- installed and running on LSST service VM (VM is "SCS Standard")
- access to /nfs/farm/g/lsst/u2
- New lsst-ftp account 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 virtual vsftp accounts for Vendors A and B.
- This FTP area would be considered a "vendor playpen" from which copies would be archived to permanent LSST storage
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 mitigations
- configure vsftpd to recognize only certain IP addresses to log in
- vendors must agree with the level of security and the risk
- monitor disk usage with ganglia and look for abnormalities
- configure vsftpd for secure userid/pwd transfer, e.g., tls
- Possible consequences
- Hacking into the vsftp server
- Is this likely? This server is generally considered "very secure" as its name suggests. No hard data on this claim.
- Hacking into the lsstlnx VM
- Independent of vsftp and, therefore, no different from other VMs at SLAC with externally visible ports. Server restricts login to a small set of authorized SLAC users.
Suggestions from the Cyber Security Group
- Ask vendors to send MD5 checksum via a separate channel than FTP. Response: ask them to send it via email in their announcement message
- Employ and IP filter (or virtual IP addresses), preferred would be to add this filter to the perimeter router. Response: request sent to net-admin
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 dwell do not allow for the type of permissions that would allow for a convincing separation between the two vendor's data
- The dropbox paradigm does not allow for vendors to manage its data once at SLAC, i.e., to replace faulty data files.
...