Page History

...

1. Hacking into a vendor account
   1. Possible consequences
      1. loss or corruption of vendor data
      2. use of storage for illicit purposes
      3. interruption of vendor data deliveries
      4. load on "u2" server (currently wain006)
   2. Possible mitigations
      1. configure vsftpd to recognize only certain IP addresses to log in
      2. vendors must agree with the level of security and the risk
      3. monitor disk usage with ganglia and look for abnormalities
      4. configure vsftpd for secure userid/pwd transfer, e.g., tls
2. Hacking into the vsftp server
   1. Is this likely?
3. Hacking into the lsstlnx VM
   1. Probably independent Independent of vsftp and, therefore, no different from other VMs at SLAC with externally visible ports

Why Existing FTP Service is Unacceptable

1. Non-anonymous (s)FTP requires a SLAC unix account and that has been deemed unacceptable by LSST project team
2. Anonymous FTP server suffers from several shortcomings:
   1. The server software cannot restart an interrupted data transfer
   2. The AFS-backed store is possibly not scalable to the hundreds of GB needed
   3. The 3-day dwell period is too risky for the data
   4. The AFS permissions combined with the 3-day swell do not allow for the type of permissions that would allow for a convincing separation between the two vendor's data
   5. The dropbox does not allow for vendor management of its data at SLAC

...