Transcript PPT

CSE 451
Section
March 2
Distributed Systems & Security
1
Overview
•
•
•
•
Project feedback
Questions on project 3
Distributed systems
System Security
2
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
3
– Add hints for next quarter
Questions on project 3
• I need to meet with every group this
week
4
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
5
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
6
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
7
Byzantine Generals Problem
• Have multiple general trying to decide to attack.
One or more may be traitors. Can they agree to
attack?
8
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”
9
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
10
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?
11
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
12
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”
13
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
14
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
15
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
16
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)
17
What are the common methods
of attack?
• Local exploits
• Network Exploits
• Root Kits
18
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
19
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)
20
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)
21
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 22
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
23
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
24
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
25
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
26
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
27
• 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
28