Transcript Network Security - University of St. Thomas

CISC 370 - Class Today
• A few things back
– Ch 12-13 problems back Wednesday
• A look at network security
–
–
–
–
Security process
Authentication
Network crytpography
Firewalls
4/3/2016
R. Smith - University of St Thomas - Minnesota
1
Making security decisions
• Do you always lock:
– A car door
– A room door
– A house door
• If not always, what decides
otherwise?
Spring 2009
R. Smith - University of St Thomas - Minnesota
2
Decision Making Strategies
• Rule based
– I’m told that’s what we do, and I follow that rule (Passwords)
• Relativistic
– My friend does it, so I do, too.
– My neighbor has a fence and locks his front door. Me, too.
– We all use super-strong Kryptonite bike locks
• “Security Theater”, hunter’s dilemma
• MAD - Deterrence
• Rational
– We look at the risks and choose security measures accordingly
– If an incident occurs, it should prove cheaper than the longterm cost of protecting against it
– Reassess risks as part of the “life cycle” of the asset
Spring 2009
R. Smith - University of St Thomas - Minnesota
3
Decision making in a life cycle
• Identify your practical goals
– What “real” things do you want to accomplish?
– What risks interfere with them?
• Choose the security that fits
– What weaknesses exist?
– What security measures might work?
– What are the trade-offs against goals?
• Measure success
– Monitor for attacks or other failures
– Recover from problems
– Reassess goals and trade-offs
Spring 2009
R. Smith - University of St Thomas - Minnesota
4
The Security Process
1. Identify your assets
•
What assets and capabilities do you require?
2. Analyze the risks of attack
•
•
What can happen to damage your assets?
What is the likelihood of damage?
3. Establish your security policy
•
•
Trade off of risks, cost of damage, cost of protection
Identify the protections you intend to use
4. Implement your defenses
5. Monitor your defenses
6. Recover from attacks
Spring 2009
R. Smith - University of St Thomas - Minnesota
5
Threats & Vulnerabilities
Defense,
Safeguard, or
“Countermeasure”
Vulnerability
Threat
Asset
An attempt to steal or harm the asset is an attack
Spring 2009
R. Smith - University of St Thomas - Minnesota
6
Simple risk analysis: your PC
• Threats?
– Who, why?
• Vulnerabilities?
– What bad can happen?
– What allows the badness to happen?
• Can we just lock it up?
– Put it in a room
– Put a lock on the door.
– Don’t share the key
• Does this work?
Spring 2009
R. Smith - University of St Thomas - Minnesota
7
Extreme Workstation Security
Does this achieve our goals?
Spring 2009
R. Smith - University of St Thomas - Minnesota
8
The Network Security Problem
• Protection is usually local
• Network data travels to remote locations
March 2005
R. Smith - University of St Thomas - Minnesota
9
Risk: Eavesdropping
• An established social tradition (“party lines”)
March 2005
R. Smith - University of St Thomas - Minnesota
10
Risk: Forgery
• Who really sent the message?
March 2005
R. Smith - University of St Thomas - Minnesota
11
Risk: Replay
• If a message worked once, why not again,
• and again?
March 2005
R. Smith - University of St Thomas - Minnesota
12
How do we fix this?
• Again, it depends on policy
– What are we really trying to achieve (“the big picture”)
– What are the real risks to that big picture?
• Practical networking choices
– Should/must the users control the defenses?
• Can/should they choose what gets protected?
– Can we isolate the users in a safe but restrictive “bubble”?
• If not, what access do they need to the ‘outside’?
– What external, secure connections do we need?
• Are they ad-hoc, or can we anticipate them?
• Risk Assessment
– Which threats matter: eavesdropping, forgery, replay?
March 2005
R. Smith - University of St Thomas - Minnesota
13
Deciding on Protection
• Policy: what protections we need
–
–
–
–
If possible, identify defensive perimeters
Identify other defenses to reduce impact of risks
Balance against how we use the asset
Balance against cost of protection
Spring 2009
R. Smith - University of St Thomas - Minnesota
14
Security Technologies
• Authentication
• Encryption – applied to protocols
• Firewalls (did those)
4/3/2016
R. Smith - University of St Thomas - Minnesota
15
Authentication
• Associates some computing behavior to a
particular user name
• Not Identification – a separate problem
– We don’t figure out who the user “really” is
– We don’t find other names for a user
• Not Access Control – a separate problem
– We don’t figure out what the user should be able to do
– Some systems grant broad access permissions to
authenticated users, but that’s not an authentication issue
4/3/2016
R. Smith - University of St Thomas - Minnesota
16
Just bits on a wire…
Cover art from
Authentication: From
Passwords to Public Keys
by Richard E. Smith © 2002,
Addison Wesley.
Illustration by Peter Steiner,
The Cartoon Bank. Used by
permission.
4/3/2016
R. Smith - University of St Thomas - Minnesota
17
Authentication “Factors”
My Pin is ...
Something you know
• Password or PIN
Something you are
• Personal trait
Something you have
• Key or Token
Traditional parallel terms:
Something you know, are, have
4/3/2016
R. Smith - University of St Thomas - Minnesota
18
The Password Tradition
• 1963: passwords implemented as a computeroriented substitute for student lockers at MIT
– Easy to implement and operate
– Originators never thought of it as a strong mechanism
Passwords capture an essential truth:
The best way to authenticate someone is by
proving ownership of a personalized secret
(We’ll call it the base secret here)
4/3/2016
R. Smith - University of St Thomas - Minnesota
19
The Password Tradition
• Passwords: the essence of computer authentication:
Verifies the ownership of a personal secret
(the base secret)
• Attack: Steal the password file from the hard drive
From Authentication © 2002. Used by permission
4/3/2016
R. Smith - University of St Thomas - Minnesota
20
Password Hashing
From Authentication © 2002. Used by permission
• Can’t retrieve passwords by stealing the file
– Can only replace a forgotten password
• Use a cryptographic one way hash function
4/3/2016
R. Smith - University of St Thomas - Minnesota
21
Password Ping-Pong
Attacks
??
Network Sniffing
Defenses
One-Time Passwords
Password Tokens
Password Sharing
Memory Protection
Keystroke Sniffing
Help Desk Restrictions
Social Engineering
Guess Detection
Guessing
Steal the Password File
4/3/2016
Password Hashing
Passwords
R. Smith - University of St Thomas - Minnesota
22
Guessing Attacks
• Interactive Attacks
– Classic Examples: Searches for written passwords, PIN
guessing
– PIN guessing is limited to trial-and-error attempts to use a
server
• Limited to server’s speed, and failures can be detected
• Off-Line Attacks
– Classic Example - “Dictionary Attack”
– Make a list of likely passwords, intercept information about
users’ passwords, match the list match against the intercepted
information
– Most powerful attack - fast and hard to detect
4/3/2016
R. Smith - University of St Thomas - Minnesota
23
Attack: Off-line with Dictionary
From Authentication © 2002. Used by permission
4/3/2016
R. Smith - University of St Thomas - Minnesota
24
Computing Average Attack Space
V = S / (2L)
• S = Number of likely permutations of the
base secret
• L = Fraction of population that uses one of the
likely base secrets
• V = number of trial-and-error attempts needed to
achieve a 50% chance of selecting the actual base
secret
4/3/2016
R. Smith - University of St Thomas - Minnesota
25
Password Strength
• Resisting a brute force guessing attack
– Estimate the average number of attempts required to succeed
– Attacker makes a list of possible passwords and tries them all
• # passwords in the list
• % chance that someone chooses from that list
• How many attempts to achieve 50-50 chance of success
– Call this the Average Attack Space
• An Ideal Example
– People choose completely random strings of characters
– 96 characters to choose from, 8 characters long
8
45
– 96 presents an average attack space of about 2
4/3/2016
R. Smith - University of St Thomas - Minnesota
26
Guessable Passwords
Year
%
Guessed
Internet Worm
1988
~50%
Klein’s Study
1990
24.2%
Spafford’s Study
1992
20%
CERT Incident IN-1998-03
1998
25.6%
Cambridge study by Yan, et al.
2000
35%
Incident
4/3/2016
R. Smith - University of St Thomas - Minnesota
27
Passwords in Practice
• The Rule for Strong Passwords:
The password must be impossible to memorize
and never written down
• The Result of this Rule
– look under some mouse pads and find ---
From Authentication © 2002. Used by permission
4/3/2016
R. Smith - University of St Thomas - Minnesota
28
Strength in Practice
Example
Random 8-character
password
Dictionary Attack
Mouse Pad Search
Practical Off-Line Attacks
4/3/2016
Type of
Attack
Interactive
Average
Attack
Space
245
Off-Line
215 to 223
Interactive
21 to 24
Off-Line
240 to 263
R. Smith - University of St Thomas - Minnesota
29
Sharing Trumps Password Strength
A secret is something you tell people
one at a time
- Anonymous
• Passwords are easy for people to share
• There is no way to tell if a password has been
shared (unless something bad happens)
• The only solution is to use something else
– Biometrics or Hardware Authentication Tokens
4/3/2016
R. Smith - University of St Thomas - Minnesota
30
Sniffing Trumps Password Strength
From Authentication © 2002. Used by permission
4/3/2016
R. Smith - University of St Thomas - Minnesota
31
Sniffing and Passwords
• Passwords safest when only used internally
– E.g., passwords never leave the physical premises
– Potential attackers have physical access to computers already
• Passwords too-often unprotected on networks
– Internet protocols: HTTP, FTP, Telnet, POP, IMAP
– Even when protection is possible, ISPs don’t always support it
• Solution: use encryption techniques
– Challenge Response Passwords
– Encryption
• Uses strong, separate encryption keys to prevent sniffing
– Token-based One Time Passwords (discussed later)
4/3/2016
R. Smith - University of St Thomas - Minnesota
32
Password Summary
• Passwords make poor base secrets
– Too hard to control, too easy to share or lose
A password is an office cabinet lock
– Best in internal environments with low threat
– OK when external environment is restricted
• Network traffic protected with separately keyed encryption
• Trial-and-error guessing can be detected on server
• Passwords are tricky and unreliable
– If you make them hard to handle, you open yourself to social
engineering attacks
4/3/2016
R. Smith - University of St Thomas - Minnesota
33
Authentication Tokens
From Authentication © 2002. Used by permission
• There are also “soft” tokens
– Most tokens also provided in software implementations
– “Public key” products often handle the private key with
software-only mechanisms
4/3/2016
R. Smith - University of St Thomas - Minnesota
34
Tokens: Things you have
Benefits
• Hard to attack - uses a
stronger secret than you
get in a typical password
• Hard to forge - must
often hack the hardware
• Hard to share - usually
stored in hardware
4/3/2016
Problems
• Expensive - must buy
hardware and/or special
authentication software
• Can be lost or stolen
• Risk of hardware failure
R. Smith - University of St Thomas - Minnesota
35
Hardware Tokens
From Authentication © 2002. Used by permission
• Resist copying and other attacks by storing the base
secret in a tamper-resistant package.
4/3/2016
R. Smith - University of St Thomas - Minnesota
36
One-Time Password Tokens
From Authentication © 2002. Used by permission
Attacker can’t reuse the sniffed password
4/3/2016
R. Smith - University of St Thomas - Minnesota
37
Challenge Response
• Earliest product (SafeWord) adapted from a
copy protection scheme in a 1980s video game
• Interactive Challenge Response
– First implemented in calculator-sized tokens
• SafeWord, WatchWord, SNK, ActivCard, ANSI X9.9
– Software implementation: S/Key for Unix
• Embedded Challenge Response
– Client performs the challenge response processing
automatically
– Microsoft LANMAN, NTLM, MS-CHAP in Windows
– Kerberos provides a similar capability
4/3/2016
R. Smith - University of St Thomas - Minnesota
38
Interactive Challenge
From Authentication © 2002. Used by permission
• Requires a calculator (hardware or software)
• Base secret is embedded in the calculator
• Authenticates the owner of the base secret
4/3/2016
R. Smith - University of St Thomas - Minnesota
39
Embedded Challenge
From Authentication © 2002. Used by permission
• Login client handles challenge automatically
(DEC, Novell)
• The password is the base secret
4/3/2016
R. Smith - University of St Thomas - Minnesota
40
Blocking the Sniffers
• Interactive Challenges: Strong but Hard to Use
– Can store a large base secret in the token
– But, user must transcribe the challenge and the response
– Rarely used today
• Embedded Challenges: Popular but weaker
– Handles the challenge response computation automatically
– But… Attackers can perform off-line dictionary attacks
• Encryption protocols are even better
– SSL for Web, FTP, E-mail; IPSEC for everything else
– Uses a separate, strong secret to block password sniffing
– Prevents off-line attacks, forces detectable interactive attacks
4/3/2016
R. Smith - University of St Thomas - Minnesota
41
Tokens Resist Attacks
Off-Line
Average
Attack
Space
215 to 223
One-Time Password Token
Interactive
219 to 223
One-Time Password Token
Off-Line
254 to 263
Smart Card with Public Key
Off-Line
263 to 2116
Example
Password
4/3/2016
Type of
Attack
R. Smith - University of St Thomas - Minnesota
42
Biometrics: Things you are
From Authentication © 2002. Used by permission
Also hand, voice, face, eyes
4/3/2016
R. Smith - University of St Thomas - Minnesota
43
Biometrics don’t work on networks
• Once the bits leave the biometric reader, we
can’t tell if they’re legitimate or not
– Maybe they were replayed from an earlier visit
– Maybe they were constructed from a stolen image
• The biometric pattern acts like a base secret
– But, Cathy’s biometrics are not base secrets
• Cathy leaves artifacts of her voice, fingerprints, and
appearance wherever she goes
• Cathy can’t change them if someone makes a copy
– Also, Cathy’s privacy is jeopardized if the biometric signatures
and patterns must be handled by many systems and devices
4/3/2016
R. Smith - University of St Thomas - Minnesota
44
Network Encryption
• We get different
results by putting
cryptography in
different places
in the protocol
architecture
Application
TCP/UDP Layer
IP Layer
Protocol
Stack
Link Layer
Device Driver
March 2005
R. Smith - University of St Thomas - Minnesota
45
The Encryption Process
• Convert plaintext to ciphertext with a key
March 2005
R. Smith - University of St Thomas - Minnesota
46
Cryptanalysis
• Known ciphertext attack
– a.k.a. ciphertext-only attack – classic attack
– Newspaper cryptograms
– You have ciphertext, no plaintext
• Known plaintext attack
– You have some plaintext for some intercepted ciphertext
– The attack used against ENIGMA to reduce the problem
March 2005
R. Smith - University of St Thomas - Minnesota
47
Security and the Protocol Stack
Classic layer-oriented
examples of crypto
protocols
• Application: PGP
PGP
Application
SSL
TCP/UDP Layer
– encrypts application data
• Trans->App: SSL
– encrypts the connection
Protocol
Stack
• IP Layer: IPSEC
– encrypts routable packets
• Link Layer: WEP/WPA
– encrypts LAN packets
March 2005
R. Smith - University of St Thomas - Minnesota
IPSEC
IP Layer
Link Layer
Device Driver
WEP/WPA
48
How Crypto works in the stack
• “Above” a crypto layer
– Data is assumed to be in plaintext form
• “At” a crypto layer
–
–
–
–
We convert between plaintext and ciphertext
We have access to some keys
We generate some plaintext headers
Some header info may be encrypted or protected otherwise
• “Below” the crypto layer
– New network headers are added in plaintext
March 2005
R. Smith - University of St Thomas - Minnesota
49
How it works Geographically
• Application layer encryption
– “End to end security” – routable, and inaccessible to others
– Defeats intermediate virus scans, intrusion detection
– Applied at the discretion of the end user (usually)
• Socket layer encryption
– Application-application security – similar to application layer
– Often applied automatically under control of the server
– Sometimes it is a user-level option
• IPSEC – IP Security Protocols
– Internet layer security – protects routable packets, per-packet
– Protects all Internet application traffic equally
– Often a substitute for inter-site leased lines
March 2005
R. Smith - University of St Thomas - Minnesota
50
Diagramming the Crypto
• Elements
–
–
–
–
Protocol stack elements
Where the crypto goes
What is encrypted
What is plaintext
March 2005
R. Smith - University of St Thomas - Minnesota
51
IP Security Protocol – IPSEC
• Security protection that’s IP routable
• We authenticate the IP addresses
• We encrypt everything inside the IP header
March 2005
R. Smith - University of St Thomas - Minnesota
52
Separate Headers
• AH – Authentication Header
– Keeps the packet intact
• ESP – Encapsulating Security Payload
– A ‘generic’ security format, originally just for encryption
– Now does both encryption and authentication
March 2005
R. Smith - University of St Thomas - Minnesota
53
Authentication Header – ‘AH’
• Protects unchanging bits of the IP header
• “SPI” – Security Parameter Index
– Identifies the keying and hash algorithm to use
March 2005
R. Smith - University of St Thomas - Minnesota
54
Encapsulating Security Payload- ESP
(8 bit bytes)
SPI
Sequence Number
Payload Data
(variable)
Padding (variable)
Pad Length
Next Header
Integrity Check
(variable)
• Modern style, including integrity protection
– Internal format still depends on the crypto used
– SPI picks the crypto format; the format determines variables
• Main problem: how long is the integrity check?
• May be length = 0, especially if the crypto does it already
March 2005
R. Smith - University of St Thomas - Minnesota
55
Secret Key Management
• Two elements
– How do you assign individual keys
– How do you update keys
• Assignment – how many keys do we need?
– “One Big Cryptonet”
– Pairwise user-user
– Pairwise user-server (“key distribution center)
• Updating – given the assignment strategies
– Manual
– Automatic
March 2005
R. Smith - University of St Thomas - Minnesota
56
Automatic key updating
• How do we get the new key?
– Internal update
• use a ‘pseudo random number generator’
• “Forward secrecy” problem
– Random update
• Use a new, randomly generated key
• Share with the cryptonet
• How do we transmit random keys?
– Chained update
• Send it using the existing crypto key
• “Forward secrecy” problem
– KEK-based update
• Use a separate “key encrypting key”
• Data is only sent with “data keys” or “session keys”
• Only use KEK to send newly generated session
March 2005
R. Smith - University of St Thomas - Minnesota
57
Key Distribution Center (KDC)
• Each user has a unique personal key
– Contacts KDC to get a session key
– KDC sends keys encrypted with users’ personal keys
• Example
– Bob wants to talk to Alice
– Bob contacts KDC, says “I want to talk to Alice”
– KDC sends two copies of the session key
• One encrypted with Bob’s personal key
• One encrypted with Alice’s personal key
• This is the basis of Kerberos
– Encrypted keys are called “tickets”
March 2005
R. Smith - University of St Thomas - Minnesota
58
Public Key Encryption
• Uses a pair of keys: the Private Key and the
Public Key
• Usually, one key of the pair decrypts what
the other key encrypts, and vice versa
• “Asymmetric Encryption”
Clear
Text
March 2005
Private
Key
Public
Key
Encryption
Procedure
Cipher
Text
Decryption
Procedure
R. Smith - University of St Thomas - Minnesota
Clear
Text
59
Public Key Protocols/Applications
• IPSEC: used for key exchange
– “Diffie Hellman” public key technique
– Produce temporary public/private keys
– Use the security to set up IPSEC security associations (SPIs)
• SSL: protects Web, FTP, e-mail, shell (SSH)..
– Usually RSA public key technique
– Uses a web server’s public key to set up a shared secret
– Uses regular crypto to protect the actual data transfers
• PGP, PEM, S/MIME: protect files and e-mail
–
–
–
–
Usually RSA public key technique
Encrypt a file with regular (symmetric) crypto
Encrypt the key with recipients’ public keys
“Sign” the message with author’s private key
4/3/2016
R. Smith - University of St Thomas - Minnesota
60
Firewall objectives
• Provide outbound Internet access
• Restrict/forbid inbound connections
• Detect and block malicious traffic
March 2005
R. Smith - University of St Thomas - Minnesota
61
Types of firewall traffic control
• Service control (allow specific protocols)
– Block unauthorized protocols
– Permit authorized ones
– Actually very hard to do
• Direction control (in/out)
– Allow outbound browsing
– Restrict access to internal servers
• User control (source/destination)
– User authorization, or perhaps subnet filtering
• Behavior control
– bandwidth, application specific cases
– Look in e-mail for malware
– Filter access to Web sites (China, Saudi, …)
March 2005
R. Smith - University of St Thomas - Minnesota
62
Types of Firewall Filtering
Packet Filtering: based on packet header (Unsophisticated)
IP Header
TCP Data
Circuit Filtering: restricts connections (Common)
TCP Header
Application Data
+ Connection state
Application Proxy: restricts based on general policy (Refined)
Appl. Header
User Data
+ Connection state + application state
Oct 2001
63
Firewalls in Different Strengths
INTERNET
Application
IP
TCP/UDP
Link
IP
Packet Filter
• Control Based on Source /
Destination Internet
Addresses
TCP/UDP
IP
Link
Link
Application Gateway
• Control Based on Application
Type and Content
Circuit Gateway
• Hides Internal Network Details
Oct 2001
64
Proxies . . . . for the Application Gateway
M. A. Proxy
Proxies are small ( less than 2000 lines of code),
“minimal and modular”
Oct 2001
65
Proxies . . . for the Application Gateway.
User’s requests
CLIENT
Oct 2001
M. A. Proxy
SERVER
66
Proxies . . . for the Application Gateway.
User’s requests
forwarded
User’s requests
Application
output
CLIENT
Oct 2001
M. A. Proxy
SERVER
67
Proxies . . . for the Application Gateway.
CLIENT
User’s requests
User’s requests
forwarded
Application
output forwarded
Application
output
M. A. Proxy
SERVER
Logs maintained
Oct 2001
68
Internet Firewall
Application Level Gateway
Ethernet Card
Private
Network
http proxy
Public
nntp proxy
Network
smtp proxy
ftp proxy
telnet proxy
rlogin proxy
snmp proxy
X11 proxy
Ethernet Card
Router
Oct 2001
Audit
Logs
69
Issues with using Firewalls
• All firewalls are NOT created equal
– Type and rigor of controls
– OS security
• Correct configuration is critical for any Firewall
– Many attacks exploit insecure default configurations
• Firewalls, even when functioning correctly,
open BIG holes in the security perimeter
– World-Wide Web (HTTP)
– Active content (Java, Java-Script, ActiveX)
Oct 2001
70
Summary
• Lots of technology
• An ongoing arms race between attackers and
defenders
• Always something new
4/3/2016
R. Smith - University of St Thomas - Minnesota
71
Creative Commons License
This work is licensed under the Creative
Commons Attribution-Share Alike 3.0 United
States License. To view a copy of this license,
visit http://creativecommons.org/licenses/bysa/3.0/us/ or send a letter to Creative
Commons, 171 Second Street, Suite 300, San
Francisco, California, 94105, USA.
4/3/2016
R. Smith - University of St Thomas - Minnesota
72