Transcript Document

CS 5950/6030 Network Security
Class 33 (W, 11/16/05)
Leszek Lilien
Department of Computer Science
Western Michigan University
Based on Security in Computing. Third Edition by Pfleeger and Pfleeger.
Using some slides (as indicated) courtesy of:
Prof. Aaron Striegel — at U. of Notre Dame
Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. Washington
Prof. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The Netherlands
Slides not created by the above authors are © by Leszek T. Lilien, 2005
Requests to use original slides for non-profit purposes will be gladly granted upon a written request.
© by Leszek T. Lilien, 2005
7. Security in Networks
...
7.2. Threats in Networks
...
7.3. Networks Security Controls
...
d) Encryption
i.
Link encryption vs. end-to-end (e2e) encryption
ii. Virtual private network (VPN)
iii. PKI and certificates
iv. SSH protocol
v. SSL protocol (a.k.a. TLS protocol)
vi. IPsec protocol suite—PART 1
Class
32
e)
f)
2
vi. IPsec protocol suite—PART 2
vii. Signed code
viii. Encrypted e-mail
Message content integrity controls
i.
Error correcting codes
ii. Cryptographic checksum
Strong authentication
i.
One-time passwords
ii. Challenge-response systems
iii. Digital distributed authentication
iv. Kerberos
IPsec protocol suite (7)
ISAKMP (Internet Security Association Key Management
Protocol) = key mgmt protocol for IPsec


In IPsec, ISAKMP implemented via IKE (ISAKMP Key
Exchange)

IKE properties
 Provides ways to agree on protocols, cipher and
authentication algorithms, keys



3
Key mgmt is always a critical element in crypto apps
ISAKMP is simple, flexible, scalable
Distinct key for each IPsec security association (SA)



© by Leszek T. Lilien, 2005
E.g., agree as follows: protocol = EPS, cipher = triple DES;
authentication alg. = SHA-1; key used for session
Provides ways to manage protocols, cipher and
authentication algorithms, keys
Uses key exchange protocol based on DiffieHellman scheme
vii. Signed code
4
© by Leszek T. Lilien, 2005

Problem: malicious active code
 E.g., malicious code on a web site for downloads

Partial solution: code signed by TTP (trusted third party)
 TTP appends digital signature to piece of code
 PKI can be used by prospective code users to validate
signature

Still code security not guaranteed
 E.g., March 2001 mistake of Verisign (CA)
 Erronously issued two code-signing certificates to
impostors masquerading as Microsoft employees
 Verisign detected mistake after almost 2 months
 Customers who didn’t validate certificate (by checking
Verisign’s certificate revocation list) could still trust bad
certificates
[---SKIP---] viii. Encrypted e-mail

E-mail msgs – like a postard that everybody who handles it
between S and R can read
People use envelopes for confidentiality (C in C-I-A)
We can „envelope” e-mail msgs by encrypting them

Encryption protects C and can protect I

Encryption is easy, establishing good key mgmt is difficult

2 basic key mgmt approaches:
1) Hierarchical certificate-based PKI solution

E.g., S/MIME
2) Use of flat, individual-to-individual key exchange


5
E.g., PGP
E-mail security (incl. PGP and S/MIME) will be discussed
soon
© by Leszek T. Lilien, 2005
[---SKIP---] e) Msg content integrity
controls (1)
© by Leszek T. Lilien, 2005
Content integrity verification provided „for free” with
encryption


Since can’t perform meaningful data modification w/o decrypting it
But attacker can modify encrypted data to make it useless



6
E.g., changing a bit of data in packet
Threats to msg content integrity
1) Malicious modification that changes content
in a meaningful way
2) Nonmalicious modification that changes content
in a way that is not necessarily meaningful
3) Malicious modification that changes content
in a way that is not meaningful
NOTE: Different cases than in text!
Encryption can solve the toughest case: Case (1)
above
EASIER
TO
PREVENT
OR
DETECT
f) Strong authentication

Networked environments as well as both ends of
communication need authentication

Strong authentication controls include:
i.
ii.
iii.
One-time passwords
Challenge-response systems
Digital distributed authentication
iv. Kerberos authentication system
7 © by Leszek T. Lilien, 2005
End of Class 32
8 © by Leszek T. Lilien, 2005
© by Leszek T. Lilien, 2005
Class
32
Class
33
9
7. Security in Networks
...
7.3. Networks Security Controls
...
d)
Encryption
...
vi. IPsec protocol suite—PART 2
vii. Signed code / viii. Encrypted e-mail
e)
Message content integrity controls
i.
Error correcting codes / ii. Cryptographic checksum
f)
Strong authentication
i.
One-time passwords
ii. Challenge-response systems
iii. Digital distributed authentication
iv. Kerberos
g)
Access controls
i. ACLs on routers
ii. Firewalls
h) Intrusion Detection Systems: alarms and alerts
i)
Honeypots
j)
Traffic flow security
k) Review of network security controls
[UPDATED] Kerberos authentication system (5)

Strengths of Kerberos:
1) No pwds communicated over network
 Pwd sent by user to Kerberos server only once & sent
outside the network (e.g., in a letter)


User’s pwd is not sent from user’s workstation when it
initiates a session
User’s pwd stored only at Kerberos server
2) Provides crypto protection against spoofing (e.g.,
masquearding, session hijacking, MITM)


Each access request mediated by a ticket-granting
service (T-GS)
T-GS knows user’s identity based on authentication
performed initially by the server
10 © by Leszek T. Lilien, 2005
[UPDATED] Kerberos authentication system (6)

Strengths of Kerberos – cont.1
3) Limits period of ticket validity (this disables some long-term
attacks—e.g., brute force cryptanalysis)


Tickets contain timestamps used by servers to
determine ticket’s validity
Ticket validity period limits duration of „window of
opportunity” for attacker
4) Prevents replay attacks
 Each user’s request stamped with time of request
 Servers compare timestamps of requests w/ current
time, accept requests only if they are close enough to
current time
 Time-checking prevents most replay attacks

Since presentation of tickets by attackers will be delayed
more than presentation of tickets by legitimate users
11 © by Leszek T. Lilien, 2005
[UPDATED] Kerberos authentication system (7)

Strengths of Kerberos – cont.2
5) Provides mutual authentication
 Service user can be assured of any server’s authenticity by requesting an authenticating response from S
6) Uses public key technology for key exchange
12 © by Leszek T. Lilien, 2005
[REPEATED] Kerberos authentication system (8)

Weaknesses of Kerberos system
1) Requires continuous availability of trusted ticketgranting server (T-GS)
2) Server S’ authenticity requires trust between T-GS & S
3) Requires timely transactions (too quick ticket expiration will
result in rejecting legitimate requests)
4) Subverted workstation can replay user pwds
5) Pwd guessing works (attacker can send initial —Step 1—
6)
authentication request to Kerberos server, receive response, try to
decrypt response by guessing at pwd)
Kerberos does not scale well (due to system size might need
> 1 KS and/or T-GS server; coordination and security problems if
more than one KS and/or more than one T-GS is needed; cf. Fig.
7-32, p.450)
7) Use of Kerberos requires compatibility of all apps in a
given computing environment (to date few apps are
compatible with Kerberos; modifying apps to make them
compatible is not feasible)
13 © by Leszek T. Lilien, 2005
g) Access controls (1)


Before user is allowed access to network resources, must
know:

Who needs access => authentication

What and how will be accessed => access controls
Access controls include:
1) ACLs (Access Control Lists) on router
2) Firewalls
14 © by Leszek T. Lilien, 2005
Access controls (2)
1) ACLs on routers (ACL = Access Control List)

Router directs traffic:

To subnetworks it controls
OR

To other routers (for delivery to other subnetworks)

Routers convert external (network-wide)IP address to
internal (subnetwork-wide) MAC address



15
Recall that MAC address is unique physical address of device’s
NIC—network interface card
Can put ACL on a router to deny access to particular
host D from particular host S

E.g., to prevent spam (flooding) of D with packets from
S, router can delete all packets from S to D
It’s OK if router uses ACLs in a limiteded way

Use sparingly: only for specific & known threats
BUT...
© by Leszek T. Lilien, 2005
Access controls (3)

... Problems with putting too many ACLs on routers:
(i) Packet-checking overhead for router

Router must check each packet against each ACL –
a lot of work
=> degraded performance


More ACLs on router => more work
Routers are already busy just routing all packets
ingoing/outgoing to/from their subnets
(ii) Logging overhead for router

To be able to detect spam, router must log source
addresses of packets


16 © by Leszek T. Lilien, 2005
Then can analyze to see which source addresses produce
floods
Routers are designed to do only essential work —
anything else is inefficient => logging on router is
inefficient => adds workload
Access controls (4)

... Problems with putting too many ACLs on routers-CONT.
(iii) Inability of router to detect all spams

Because source addresses in datagrams (UDP
packets) can be easily forged (by attacker using UDP
protocol)

17 © by Leszek T. Lilien, 2005
If attacker sends many datagrams with the same
(repeated) forged address, router with ACL can
detect & block them
Otherwise (i.e., if attacker sends datagrams with few
repeated forged addresses), router with ACL will not
even detect being flooded
=> can not block flooding datagrams
Access controls (5)
2) Firewalls

Designed to do screening that routers can’t do efficiently

Because routers designed for routing (of course!)

Firewalls designed for access filtering
AND auditing
AND examining whole packets (not only source/destination
IP/ MAC addresses—which is what routers do)

Firewalls will be discussed in detail later (but very soon)
18 © by Leszek T. Lilien, 2005
h) Intrusion Detection Systems: alarms & alerts

Example of 2-layer network protection

Provided by router (Layer 1) AND firewall (Layer 2)

Fig. 7-33, p. 452
We can add one more layer of protection:
intrusion detection systems (IDS) = device placed within
protected network for monitoring for illegitimate actions in
order to detect attacks in progress (beginning, advanced) or
after they have occurred


OR



19
Can detect that attack has already occurred & raise alarm,
starting system recovery actions
IDS is a.k.a. IPS = intrusion protection system


E.g.: Can detect reconaissance & alert sysadmin or secadmin,
raise alarm, thus preventing „real” attack
A marketing gimmick?
IDS can be Layer 3 of layered network protection
To be discussed in detail soon
© by Leszek T. Lilien, 2005
i) Honeypots

Honeypot – system built as a bait attracting attackers

Once attackers take the bait:

They are observed to learn how they behave/operate


They are traced to catch them or scare them off


Or at least trace enough to be able to threaten them with
identifying them if they don’t stop
They are diverted from really valuable attack targets


New attacks / Prefered targets / ...
E.g., diverted to phony credit card database while real credit
card database remains obscure to them
User lessons learned (thanks to honeypots) to build better
countermeasures
20 © by Leszek T. Lilien, 2005
j) Traffic flow security (1)

Threat: attacker infering occurrence/location of some event
/ structure from intensity of encrypted network traffic
(If not encrypted, no need to infer – attacker can simply read all)

Example 1: Inference that traffic between Thinges Corp. and
bankruptcy lawyer precedes declaration of bankruptcy by Thinges

Example 2 (old): Battlefield network: Busiest network node is at
enemy’s HQs

Solution 1: Masking by steady traffic volume
 X and Y always send the same volume of encrypted
traffic between them
 If X has nothing to communicate to Y, X sends
meaningless padding packets to Y (Y behaves analogously)
21 © by Leszek T. Lilien, 2005
Traffic flow security (2)

Solution 2: Masking by onion routing
 Example: W wants to send packet to Z in a hidden way
 W wraps „real” packet to Z into packet addressed to
Y, which asks Y to send it toZ
 W wraps packet to Y into packet addressed to X,
which asks X to send it to Y
Onion-like packet sent by W to X
Send packet to Y
Send packet to Z
22 © by Leszek T. Lilien, 2005
 Full route: W  X  Y  Z
 W sends green packet to X
 X unwraps it, gets red packet
X sends red packet to Y
 Y unwraps it, gets blue packet
Y sends blue packet to z
 Z unwraps it, gets blue packet
Traffic flow security (3)

Why „onion” routing? Layers of wraps around „real”
packet to Y– like layers of an onion

Note: (Recall the full route: W  X  Y  Z )
 X knows that packet came from W & should be
forwarded to Y


Y knows that packet came from X & should be
forwarded to Z


But X does not know if W is source or intermediate host,
does not know if Y is destination or intermediate host
But Y does not know if X is source or intermediate host,
does not know if Z is destination or intermediate host
Z knows that packet came directly from Y & knows
that W is its source

Z knows that Y is just an intermediate host
=> Intermediate nodes do not know source/destination
They only know host that forwarded packet to them &
know host to which they should forward packet
23 © by Leszek T. Lilien, 2005
k) Review of network security controls


Table 7-4, p. 426 provided classification of network
vulnerabilities (during our earlier discussion of threats)
Table 7-7, p. 454 lists controls for each of these classes of
network vulnerabilities — it shows that:
 There are many great network security controls
 Most are used also in environments other than networks
(including applications and OSs)


Three of these controls are specific to networks:
 Firewalls / IDSs / encrypted e-mail
We shall discuss them in some detail next
Table 7-7 is a great reference for network security controls!
 Use it often


If you can get copyright permission from publisher, I’d advise
you to copy it and post above your desk
Otherwise, make your own notes based on it
24 © by Leszek T. Lilien, 2005
End of Class 32
25 © by Leszek T. Lilien, 2005