CSE 451: Operating Systems Winter 2012 Synchronization Mark Zbikowski Gary Kimura.
1 CSE 451 Section March 2 Distributed Systems & Security.
-
Upload
easter-atkins -
Category
Documents
-
view
217 -
download
0
Transcript of 1 CSE 451 Section March 2 Distributed Systems & Security.
CSE 451
Section March 2
Distributed Systems & Security
Overview
• Project feedback• Questions on project 3• Distributed systems• System Security
Project 2 feedback
• Need to bullet proof OS– Can’t assume resources won’t run out: file IDs,
address space IDs– Shouldn’t use any parameter without validation
• Including buffer sizes
– Need to test corner cases:• Running out of file Ids• Running out of physical memory• Loading programs too large for physical memory
• Writeups: generally good– Add introduction/conclusion– Add hints for next quarter
Questions on project 3
• I need to meet with every group this week
Distributed Systems
• People have talked about it since the 70s – why aren’t there more?– The web– File / print servers– Databases– Clusters
• It’s really hard…– Machines fail– Messages get lost– Machines get corrupted
Distributed System Impossibilities
• Attacking Generals Problem:– Deciding to attack – if both attack, win, if one
attacks, lose. Can only send messengers that may be killed or subverted
Attacking Generals
• It is impossible with a fixed maximum # of messages– You can never tell if your acknowledgement was
heard– Suppose you had a protocol that took no more than
12 messages, but messages could get lost. • The last message could get lost• Ergo, you didn’t need the last message
– If messages always get delivered, but one general is faulty (may die during decision making), you still can’t do it
• This is important: consider transactions
Byzantine Generals Problem
• Have multiple general trying to decide to attack. One or more may be traitors. Can they agree to attack?
Transactions
• Distributed transactions use “two phase commit”– First phase: ask participants to vote– If all vote “commit”, send out commit message. If
any vote “abort”, send abort message.– After vote to commit, participant changes must
survive crashes– To continue after failure, reboot and ask what the
vote was, or ask other participants to vote on what the decision was.
• It is impossible to survive partitions (machines disconnected from other participants) and not “block”
Distributed systems
• These kinds of results make things hard– Message get lost, and you don’t know where
(on a request or reply)– Messages get delivered out of order– Messages can take a long time to get
delivered– A very slow machine may appear dead– Failures occur in a distributed system that
don’t occur on a single machine, so distribution isn’t invisible
Security
• Security is also hard in a distributed system– How do you prove who you are?– How do you determine what someone
is allowed to do?– How do you secure your system
against attackers?
Proving who you are
• This is Authentication– On a single computer, just store passwords
in a file– On a distributed system, you don’t want to
send passwords over the network: they could be “sniffed”
• Three general approaches:– Secret key encryption– Public key encryption– Hardware
Secret Key Authentication
• Each person has a key that is secret but known to the service.
• Challenge response style:– S->A: random number– A->S {random number}Ka
• Kerberos style: use “tickets”
Kerberos
• Keys are only shared with a key distribution center.
• To authenticate:– A ->KDC: A,B,time– KDC->A {B,time,k}Ka, {A,time,k}Kb– A->B {A,time,k}kb, {time}k– B->A {time}k– A->B
Public Key Encryption
• Public keys: (asymmetric encryption)– One key encrypts, one key decrypts– One key kept private, the other key is
public– To “sign” a message: encrypt with
private key– To “seal” a message: encrypt with
public key of recipient
Public Key Authentication
• Uses certificates:– A->KDC: A,B– KDC->A: (PKB,B) skdc : a certificate– A->B: (na, A)PKB– B->KDC: B, A– KDC->B: (PKA,A)skdc– B->A: (na, nb)pka– A->B: (nb) pkb
What are you allowed to do?
• Two approaches:– ACLs: have a list on each object of who is
allowed access, and how much– Capabilities: get a ticket from someone that
gives you access, and present the ticket
• Both are used:– In NT: ACLs stored on all objects, used to
grant a Handle to the object– The Handle is a capability: the ACL isn’t
checked during access (e.g. read/write)
What are the common methods of attack?
• Local exploits• Network Exploits• Root Kits
Intrusion Tools
• Port Scanners (SATAN)– Remotely scan a range of addresses– Report on available services
• NFS, NIS, Sendmail, TFTP, RSH, X, FTP
– Report any known security holes– Can be detected (Courtney, Gabriel)
• Monitor traffic with TCPDUMP
Intrusion Tools (2)
• Host-based scanners (Cops, Tiger))– Checks for known local problems
• Insecure configurations (ACLs, Passwords)
• Known bugs in services• Signs of intrusion (modified binaries)
Remote Exploits
• Used to penetrate a machine with no local access (no existing account)
• Drives deployment of firewalls• Services that perform operations based
on unsecured user requests present vulnerabilities
• Examples:– Sendmail– IP spoofing (for authentication by IP address
only)
Local Exploits
• Goal: gain unauthorized privileges for an existing account
• Getting an account:– Social engineering (asking people for
passwords)– Trading passwords– Sniffing traffic
• Exploits derived from bugs that execution of hostile commands at a privileged level– Eg. Scripts running with SUID– Cracking passwords
Physical Exploits
• Attach machine to network & sniff• Reboot machine with floppy• Remove hard drive• Walk up to logged-on machine• Modifying hardware, or convincing
others to modify hardware
What are the exploits?
• Domain errors – exposing data (e.g. passwords in pagefile)
• Validation errors – not validating parameters (e.g. finger exploit)
• Serialization – checking access asynchronously (e.g. allowing object to change after access check)
• Authentication / Authorization errors – e.g SUID bit
• Boundary condition violation – exhausting a resource (e.g. subst DOS)
• Exploitable logic errors
Attack Process
• Reconnaissance– DNS zone transfer – copies DNS database– Search newsgroups for email addresses –
learn patterns
• Probe– Port scan using SATAN – often logged– Distributed port scan – many clients scan
same host– Check services for known vulnerabilities
Attack Process (2)
• Attack the vulnerability– Attack code can be executed on the
host in untrusted account
• Find local exploit with COPS / TIGER– Become root
Attack Process (3)
• Stealth– Modify logs to hide signs of attack– Replace binary files with modified versions that
don’t report attack• Eg. modify PS, netstat to not report process &
connections• Ensure future unlogged access
• Listening– Sniffers - monitor local network traffic– Snoopers - monitor local I/o (keystrokes, etc.) to
learn more accounts & passwords
• Spread attack to related hosts
What next
• Machines are used for future attacks:– Tribe Flood Network– Trin00
• Hackers remotely control a large network of computers, use them to coordinate attacks– Port scanning– Denial of service