Finishing from last time...

NFS Performance

Example of a modern NFS system:

In this outline:

• Each controller is basically just a regular machine on the network, designed to control the RAID arrays and actually run the NFS daemon.
• The goal is to have no single point of failure (i.e. this is why there are multiple controllers, RAID storage, multiple ethernet backbone lines, etc.).
• Each UPS is a "uninterruptible power supply"—so-called because it contains within it a failsafe mechanism similar to a rechargeable battery. Of course, no power supply is truly uninterruptible, so redundancy is employed here too.

Modern performance statistics for Sun ZFS Storage 7420:

Its performance characteristics are as follows:

Where...

• Load is the number of NFS operations per second (in thousands). An NFS operation is, e.g., a read, write, lookup, etc.
• T is the response time of the file server

Security

NFS Security

• Imagine an NFS request, e.g. LOOKUP(dfh, "name")
  • What happens if the request is to "/home/eggert/mail"—and so needs to be rejected?
• We can't rely on the client for security
  • The client can go bad
  • An attacker can become root on the client (very bad!)

• The original NFS protocol had the client include in its request to the server its user ID. This would identify the user to the server.

  • Of course, if an attacker forged that user ID (which it could do easily), you've got a security problem.
  • A small change was made for this: user ID 0 (the user ID for root) is now treated by NFS servers as not meaning root, but instead meaning the special user "nobody". *"nobody" is a user defined in the passwd file, but nobody has no special permissions whatsoever (in otherwords, "nobody" can only read a file if it's world-readable/write to a file if it's world-writable).
  • This means that any client attempting to identify itself as root would instead be treated as having no rights.
  • Really though, this change is for preventing non-malicious but mis-configured clients more than to prevent clients attempting to launch any sort of serious attack.
  • Another problem this caused was that different servers on the network could potentially have different user IDs for the same username—thereby a client would make a request to the server using the only correct user ID that it knew, but the server would interpret that ID as being for a different user and the client would be misidentified.

• NFS needed to defend itself against other problems too:

  • Packet sniffing/packet injection
  • This is where, for example, an evil demon is placed on the network in between the client and the server that intercepts/alters the packets as they are going across the network. This may happen for example by an attacker taking over a router somewhere along the route between the client and the network.
  • Packets can also be spoofed/faked.
  • Servers can go bad.

• To attempt to solve these kinds of issues, a secure version of NFS was made called NFSv4, which...

  • identifies users using names (not ID numbers)
  • provides more ACLs (access control lists), etc. to allow for better access control
  • provides authentication of clients and servers
  • encrypts data
• Unfortunately, NFSv4 may be too slow or costly for some applications.
  • Many NFS installations just use NFSv3 within a "walled garden" and substitute NFSv4's security with physical security of the server.

Examples of Security Issues

• Recent: "Flame" virus
• March 2012: DDoS (distributed denial of service) attack on BBC website by Iranian Supreme Council of Virtual Space
  • Part of a continuing effort on the part of the Iranian government to control information flow (at least within Iran)

So, how does one defend against attacks on security?

Consider how we think about security in the real world.

• There are two major kinds of attacks in the real world: force and fraud
• In the virtual world, however, fraud is more important. Attacks are so easy to to the insecure nature and complexity of the Internet and computer systems in general that force is rendered unnecessary—fraud suffices.

The main goals of virtual attackers fall under three major types of virtual attacks:

• against privacy (unauthorized release of information)
• against integrity (tampering with others' information)
• against service (denial of service)

The main goals of those defending against virtual attacks are twofold:

• Disallow unauthorized access/reading/changing, but...
• Allow authorized access

(After all, the most secure computer in the world is a concrete brick.)

Note: it's harder to test negative goals (i.e. disallowing) than positive goals (i.e. allowing). This is because users will "cooperate" with you for positive goals by e.g. complaining when they don't have access to something they are supposed to be able to access, but will usually not cooperate when the converse is true...

Threat Modeling & Classifications

It's usually a mistake to say "I'll just add some passwords".

A threat model can be thought of as a "use case for bad guys" in that it models what type of attacks a malicious user might launch on a system.

Here are some prominent threat models, in rough order of general importance:

• Insiders
  • This is what happens when e.g. your own accountant develops a gambling problem
  • Insiders may be modeled as an authentication issue or an authorization issue.
  • Can be defended against with proper auditing
• Social engineering
  • Example: Kevin Mitnick broke into phone systems by climbing up phone polls dressed as a phone repairman and calling a nearby office building impersonating a phone technician. He would claim to be attempting to fix the phone system but say that he did not have the password he needed to do his job. The people in the office would often look out their window upon hearing this, see the "repairman" present on the phone poll, and assume that Mitnick's request was valid and give him the password.
• Network attacks
  • Drive-by downloads: unintended downloads embedded in e.g. specially-designed/corrupted images inside an "eye candy" website designed to attract attention and mouse clicks
  • Virus
  • Denial of service attacks
• Device attacks (e.g. writing to the MBR of a flash drive)
• And there are others...

Note: you won't be able to defend against all types of attacks, so prioritize.

Big Six General Features Needed for Any Security Mechanism

• Authentication (making sure someone is who they say they are)
• Integrity (making sure that your data is what you think it is—e.g. with a checksum)
• Authorization (making sure someone is allowed to do what they are trying to do)
• Auditing (this is the best defense against insider attacks)
• Correctness—in many ways more important in security (incorrectness generally ⇒ insecurity)
• Efficiency—of practical consideration: if the system is too slow, nobody will use it no matter how secure it is

How to Authenticate

The principle is the human being that is the primary motivation for whatever operation is being attempted. Here are three basic techniques for authenticating a principle's request:

• Based on something the principle knows (e.g. a password)
• Based on something the principle has (e.g. RSA SecurID)
  • The RSA SecurID is an example of a physical device kept on the principle's person that generates an effectively random number every minute based on some deterministic but secret algorithm. The same algorithm is kept secret also within the area the principle wants to authenticate themself into, and at any given minute the principle can provide the value on their keychain and it should match the secret value stored within the area they are trying to enter. The system there can then use the match to identify the principle.
• Based on who the principle is (e.g. biometrics, fingerprinting, retina scanning)

All of these approaches are imperfect:

• Passwords can be guessed/snooped
• Physical devices can be lost/stolen
• Identities can be faked (even physical identities—e.g. fingerprinting can be faked by using social engineering to obtain an imprint of the real user's fingerprint)
• Human errors such as forgotten credentials and loss of data as well as fake negatives are also problems for all these systems.

Also, all of these have bootstrapping problems: at some point, an underlying system must be trusted—that underlying system is usually more simple/primitive/direct (hopefully more secure) than the overlying system—such as e.g. physically meeting the principle to give them their initial password.

Authentication in an OS

There are two main types of authentication that must be done within an OS.

• The first is external authentication.
  • This is the authentication that must be done upon a new user attempting to enter the walls of the system.
  • The general with external authentication is that it is not done very frequently and as such can be slow/expensive in order to boost security.
• The second is internal authentication
  • This is the authentication of users within the walls of the system—after they have passed external authentication.
  • This type of authentication has to be fast and cheap. Example: a read(fd, buf, bufsize) should fail if e.g. the file is open for writing only.
  • Within the process descriptor structure within the kernel, a simple integer might be stored (called user ID) that reflects the slow external verification that the user requesting the read passed through in order to authenticate as themself. Checking an integer is just a single memory-load, so this operation is cheap.
    • (Side note: on Linux, you can actually change this number using the setuid syscall—if you're root, that is, otherwise this syscall would be a gaping security hole)
    • Also observe that this internal authorization must be done within the kernel—otherwise it would be a gaping security hole.

Network Authentication Building Blocks

Cryptographic hash functions (e.g. SHA-1)

• SHA1(message) = a 160-bit, very mathematically difficult to reverse hash of the message contents

Idea: knowing the hash doesn't help you compute the message.

Symmetric encryption (e.g. triple-DES)

• sender, recipient share a secret key K.

• For a message M:

  Given	Can easily get
  M, K	{M}K
  {M}K, K	M

  
  

  Given	Very hard to get
  {M}K(but not K)	M
  {M}K(but not K)	K

• Symmetric encryption is pretty fast!

• But, it suffers from a bootstrapping problem—how does the secret key get from the sender to the recipient in the first place?

Asymmetric encryption (e.g. RSA)

• SLOW, but solves bootstrapping problem

• Uses two keys—a private key P and a public key K. The public key is used to encrypt a message, and the private key is used to decrypt it. Public keys are public—they are to be spread around and made known—but private keys must be kept completely secret or the entire system is pointless.

• For a message M:

  Given	Can easily get
  M, P	{M}P
  {M}P, P	M

  
  

  Given	Very hard to get
  {M}P, P	M
  {M}P, P	K
  P	K

Example: Alice sends a message to Bob:

Say A is 192.168.2.3:97.

• A → B {"I'm Alice"}
• B → A {OK}

Bob now knows that 192.168.2.3:97 is Alice and can do business accordingly for now. But, say, later...

• 192.168.2.3:97 → B {"I'm Alice"}

Bob can't know whether or not the message is faked!

Nonce—a random integer generated by (say) Bob.

• A → B {"I'm Alice"}
• B → A {Nonce}^K
• A → B {Nonce + 1. Transfer the money and meet me under the bridge at 0300.}^K

Bob can then arrange for the nonce to time out so that if an attacker records and replays the message, Bob can request the requester reply to a new nonce.

HMAC: Hashed Message Authentication Code

SHA1((k^pad1) . SHA1((k^pas2) . M))
Where ^ is bitwise XOR and . is bit-string concatenation.