CS 5950/6030 Network Security Class 33 (W, 11/16/05) Leszek Lilien Department of Computer Science...

CS 5950/6030 Network SecurityClass 33 (W, 11/16/05)

Leszek LilienDepartment 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. WashingtonProf. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The

Netherlands

Slides not created by the above authors are © by Leszek T. Lilien, 2005Requests to use original slides for non-profit purposes will be gladly granted upon a written

request.

2

7. Security in Networks...

7.2. Threats in Networks...

7.3. Networks Security Controls...

d) Encryptioni. Link encryption vs. end-to-end (e2e) encryptionii. Virtual private network (VPN)iii. PKI and certificatesiv. SSH protocolv. SSL protocol (a.k.a. TLS protocol)vi. IPsec protocol suite—PART 1

vi. IPsec protocol suite—PART 2vii. Signed codeviii. Encrypted e-mail

e) Message content integrity controlsi. Error correcting codesii. Cryptographic checksum

f) Strong authenticationi. One-time passwordsii. Challenge-response systemsiii. Digital distributed authenticationiv. Kerberos

© by Leszek T. Lilien, 2005

Class 32

3

IPsec protocol suite (7) ISAKMP (Internet Security Association Key

Management Protocol) = key mgmt protocol for IPsec Key mgmt is always a critical element in crypto apps

ISAKMP is simple, flexible, scalable Distinct key for each IPsec security association (SA)

In IPsec, ISAKMP implemented via IKE (ISAKMP Key Exchange)

IKE properties Provides ways to agree on protocols, cipher and

authentication algorithms, keys 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 Diffie-

Hellman scheme


4

vii. Signed code 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


5

[---SKIP---] viii. Encrypted e-mail E-mail msgs – like a postard that everybody who

handles it between S and R can readPeople 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 E.g., PGP

E-mail security (incl. PGP and S/MIME) will be discussed soon


6

[---SKIP---] e) Msg content integrity controls (1)

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 E.g., changing a bit of data in packet

Threats to msg content integrity1) Malicious modification that changes content

in a meaningful way2) 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


EASIERTO PREVENTOR DETECT

7

f) Strong authentication Networked environments as well as both ends of

communication need authentication

Strong authentication controls include:i. One-time passwordsii. Challenge-response systemsiii. Digital distributed authentication

iv. Kerberos authentication system


8

End of Class 32


9

7. Security in Networks...

7.3. Networks Security Controls...

d) Encryption...

vi. IPsec protocol suite—PART 2vii. Signed code / viii. Encrypted e-mail

e) Message content integrity controlsi. Error correcting codes / ii. Cryptographic checksum

f) Strong authenticationi. One-time passwordsii. Challenge-response systemsiii. Digital distributed authenticationiv. Kerberos

g) Access controlsi. ACLs on routersii. Firewalls

h) Intrusion Detection Systems: alarms and alertsi) Honeypotsj) Traffic flow securityk) Review of network security controls


Class 32

Class 33

10

[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


11

[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


12

[UPDATED] Kerberos authentication system (7) Strengths of Kerberos – cont.2

5) Provides mutual authentication Service user can be assured of any server’s

authenti-city by requesting an authenticating response from S

6) Uses public key technology for key exchange


13

[REPEATED] Kerberos authentication system (8)

Weaknesses of Kerberos system1) Requires continuous availability of trusted ticket-

granting server (T-GS)2) Server S’ authenticity requires trust between T-GS

& S3) Requires timely transactions (too quick ticket

expiration will result in rejecting legitimate requests)4) Subverted workstation can replay user pwds5) Pwd guessing works (attacker can send initial —Step 1—

authentication request to Kerberos server, receive response, try to decrypt response by guessing at pwd)

6) 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)


14

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 router2) Firewalls


15

Access controls (2)

1) ACLs on routers (ACL = Access Control List) Router directs traffic:

To subnetworks it controlsOR To other routers (for delivery to other

subnetworks)

Routers convert external (network-wide)IP address to internal (subnetwork-wide) MAC address

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 threatsBUT...


16

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 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


17

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)

If attacker sends many datagrams with the same (repeated) forged address, router with ACL can detect & block themOtherwise (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


18

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 filteringAND auditingAND 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)


19

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

E.g.: Can detect reconaissance & alert sysadmin or secadmin, raise alarm, thus preventing „real” attack

OR Can detect that attack has already occurred & raise alarm,

starting system recovery actions IDS is a.k.a. IPS = intrusion protection system

A marketing gimmick?

IDS can be Layer 3 of layered network protection To be discussed in detail soon


20

i) Honeypots Honeypot – system built as a bait attracting attackers

Once attackers take the bait: They are observed to learn how they

behave/operate New attacks / Prefered targets / ...

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 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


21

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)© by Leszek T. Lilien, 2005

22

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


Send packet to Z

Send packet to Y

Onion-like packet sent by W to X

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

23

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 But X does not know if W is source or intermediate host,

does not know if Y is destination or intermediate host Y knows that packet came from X & should be

forwarded to Z 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/destinationThey only know host that forwarded packet to them &know host to which they should forward packet


24

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-mailWe 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© by Leszek T. Lilien, 2005

25

End of Class 32


CS 5950/6030 Network Security Class 33 (W, 11/16/05) Leszek Lilien Department of Computer Science...

Documents

Transcript of CS 5950/6030 Network Security Class 33 (W, 11/16/05) Leszek Lilien Department of Computer Science...