Versions Compared


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


  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