Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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!!)

  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?  This server is generally considered "very secure" as its name suggests.  No hard data on this claim.
  3. Hacking into the lsstlnx VM
    1. 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

  1. Ask vendors to send MD5 checksum via a separate channel than FTP.  Response: ask them to send it via email in their announcement message
  2. 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

  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 dwell do not allow for the type of permissions that would allow for a convincing separation between the two vendor's data
    5. The dropbox paradigm does not allow for vendors to manage its data once at SLAC, i.e., to replace faulty data files.

...