NFS Servers and Security

CS111 Lecture 17 (December 2, 2013)

by Henry Li

NFS servers have a lot of disks/flash.

• + lots more space
• + parallelism
• - complexity
• - reliability

RAID: Redundant Array of Independent Disks

Ex: 10 TB drive $2000 and 1TB drive $100

RAID 0

• concatenation (1 big drive, concatenated from little ones)
• striping. assumption: locality of reference (reliability problem)
  • + seek in parallel
  • - possibly lose data blocks from many files

RAID 1

• mirroring
  • + attacks reliability problem
  • + 2x read throughput
  • - 2x storage cost

RAID 4

• concatenated data with a parity drive (N total drives)
  • + use XOR to restore blocks
  • + cheaper than RAID 1
    • extra cost is 1/(N-1) compared to no parity
    • total cost is 1 + 1/(N-1)
  • - complexity
  • - parity drive is I/O bottleneck on writing
  • - writes more expensive (like RAID 1) and because extra reads

Assume that (1) we're notified of write failures, (2) we're notified of read failures, (3) little light goes on, (4) disk replaced quickly (relative term: 1 hour - never), (5) during replacement, run in degraded mode, (6) after replacement: rebuild the drive (few hours).

RAID 5

• RAID 4 with striping
  • RAID 4 > RAID 5 because easier to add new drive

NFS Security

Examples of security threats:

• clients spoofing themselves as other users
• client has user 1010 accesses files (not really, it's just a laptop)
• server spoofing (clients are fooled
• DoS attack on server
• man-in-the-middle

Many security problems are like this. Example:

• Supreme Council of Virtual Space
  • reports to the Supreme Leader
  • controls "all" information flow in Iran
  • launched a DoS attack on BBC
  • jammed satellites

3 kinds of attacks

• attack against integrity
  • Goal: tampering with victim's data
• attack against privacy
  • Goal: unauthorized information release
• attack against service
  • Goal: denial of service

Goals in defense

• Deny unauthorized access (defends against privacy and integrity attacks)
  • not natural to test for
• Allow authorized access (defends against privacy and integrity attacks)
  • natural to test for
• Be able to handle lots of "bogus" requests (defends against service attacks)
  • relatively easy to test

Threat modeling and classification

• insiders
• social engineering
• network attacks
  • buffer overruns
  • SQL injection
  • Drive-by download (DBD)
• device attacks (ie. virus on USB flash drive)

Kerchkoff's design principle (for cryptographic systems)

Minimize what needs to be kept secret. Assume bad guys will learn your design (or any global key).

General functions needed for almost any security mechanism

• Authentication (e.g. password)
• Integrity (e.g. checksum)
• Authorization (e.g. access control list [ACL])
• Auditing (e.g. logs)
• Efficiency
• Correctness

Authentication

• prevent masquerading
• external: outsider trying to get in
  • password
  • key (physical)
  • biological
• internal: insider trying to access components
  • used id in process memory via virtualization or via network

Cryptographic authentication

• e.g. Unix password file
• SHA1(x) = c
  • knowing c gives you almost no information about x
• cryptographic checksum of password